ROI【🔏機密ファイル】 No. X051 | TPSの7つのムダとは何か

悪い例:
- 注文100個なのに120個作る
- 来月の分まで今月作ってしまう
- 「ついでに」余分に作る
- 機械の稼働率を上げるため余計に作る

結果:
- 余剰在庫の発生
- 倉庫スペース圧迫
- 資金の固定化
- 陳腐化リスク

悪い例:
- 使われない機能を実装
- 将来必要かもしれない機能を先に作る
- 完璧な設計ドキュメントを作り込む
- ユーザーが求めていない高度な実装

結果:
- 開発工数の浪費
- メンテナンスコスト増
- リリース遅延
- 本当に必要な機能への時間不足

悪い例:
- 反応がない層にも一律にメール送信
- 読まれないホワイトペーパーを大量作成
- 効果測定前に大量のコンテンツ制作
- ターゲット不明確なまま広告拡大

結果:
- コンテンツ制作コストの無駄
- 顧客の情報疲れ
- ブランドイメージ低下
- 効果的施策への投資不足

心理的要因:
- 「せっかく作るなら」の心理
- 稼働率100%が良いという誤解
- 余裕を持ちたい不安
- 停止することへの抵抗

組織的要因:
- 作った量で評価される
- 機械・人材の遊びを許容しない文化
- 需要予測の不正確さ
- 部分最適の追求

ジャストインタイム:
- 必要なものを
- 必要なときに
- 必要な分だけ

具体的実装:
- かんばん方式（後工程が引き取る）
- 小ロット生産
- 需要の平準化
- プル型生産（押し込みではなく引き取り）

悪い例:
- 前工程の遅れで作業者が待機
- 機械の故障で生産ライン停止
- 承認待ちで作業が進まない
- 材料が届かず手待ち

結果:
- 人件費の浪費
- 納期遅延
- 生産性の低下
- モチベーション低下

悪い例:
- コードレビュー待ちで開発停止
- 仕様確定待ちでエンジニア待機
- デプロイ承認待ちで次の開発進まず
- QAチームの確認待ち

結果:
- 開発速度の低下
- コンテキストスイッチによる非効率
- リードタイム増加
- 開発者のフラストレーション

悪い例:
- 上司の承認待ちで業務停止
- 他部署からの回答待ち
- 会議開始時刻まで待機
- システムの処理完了待ち

結果:
- 時間の浪費
- 複数タスクの並行作業で集中力低下
- 納期遅延
- 顧客への価値提供遅れ

標準作業:
- 作業時間の均一化
- ボトルネック工程の特定・改善
- 多能工化（待ち時間に別作業）

自働化（ニンベンの付いた自動化）:
- 異常があれば自動停止
- 人は異常対応に専念
- 機械に任せられることは機械に

悪い例:
- 工場内での長距離移動
- 倉庫と工場が離れている
- 複数回の積み替え
- 遠回りの配置

結果:
- 運搬コスト
- 時間の浪費
- 破損・紛失リスク
- リードタイム増加

悪い例:
- 複数ツール間でのデータコピペ
- 手動でのファイル転送
- メールでのファイル共有
- 情報の重複入力

結果:
- 時間の浪費
- ヒューマンエラー
- 情報の分散
- バージョン管理の混乱

悪い例:
- 紙の書類を各部署に回覧
- 承認印のための移動
- 会議室への移動時間
- 離れた場所への資料取りに行く

結果:
- 移動時間の浪費
- 書類紛失リスク
- プロセス遅延
- 本質的作業の時間減少

レイアウト改善:
- U字型ライン（移動距離最小化）
- ワークステーション最適配置
- 必要なものを手の届く範囲に

一個流し:
- 大量運搬ではなく1個ずつ
- バッチサイズの縮小
- 中間在庫の削減

悪い例:
- 顧客が求めない精度での加工
- 見えない部分の過剰な仕上げ
- 不要な検査工程
- 過剰なスペック

結果:
- 加工時間の増加
- コスト上昇
- 納期遅延
- 価格競争力低下

悪い例:
- ユーザーが使わない高度な機能実装
- 過剰な抽象化・設計パターン適用
- 必要以上のパフォーマンス最適化
- 読まれない詳細ドキュメント作成

結果:
- 開発時間の浪費
- 複雑性の増大
- メンテナンスコスト増
- 本質的価値への集中不足

❌ 品質を下げることではない
✅ 顧客が求める品質に正確に合わせること

キーポイント:
- 80点で十分なところを100点にしない
- 顧客価値に直結しない作業の排除
- [MVP](/behind_case_files/articles/X036_MVP)の思想
- 完璧主義の罠回避

悪い例:
- 「念のため」の過剰在庫
- 倉庫に眠る材料
- 完成品の大量ストック
- デッドストック

結果:
- 倉庫コスト
- 資金の固定化
- 陳腐化・劣化リスク
- 問題の隠蔽（在庫があるから気づかない）

悪い例:
- 未リリースの完成機能
- 使われないコードの蓄積
- 実装済み未テスト機能
- バックログの肥大化

結果:
- メンテナンスコスト
- 統合時の問題発覚遅れ
- 陳腐化（市場変化で不要に）
- フィードバックの遅延

ジャストインタイム:
- 在庫ゼロが理想
- 1個流し生産
- 後工程引き取り

在庫が隠す問題の顕在化:
- 在庫削減 → 問題が見える
- 問題解決 → さらに在庫削減
- 継続的改善サイクル

悪い例:
- 工具を探す動作
- 振り返る・かがむ動作
- 持ち替える動作
- 不自然な姿勢での作業

結果:
- 時間の浪費
- 疲労の蓄積
- 労災リスク
- 生産性低下

悪い例:
- マウスとキーボードの往復
- 複数画面間の視線移動
- 資料を探す時間
- コピペの繰り返し

結果:
- 微小な時間ロスの蓄積
- 集中力の低下
- 身体的疲労
- ミスの増加

動作経済の原則:
- 両手を同時に使う
- 動作は対称的に
- 最短距離で
- リズミカルに

5S活動:
- 整理（不要なものを捨てる）
- 整頓（必要なものをすぐ取れる位置に）
- 清掃
- 清潔
- 躾（習慣化）

悪い例:
- 不良品の発生
- 検査での不合格
- 顧客からのクレーム対応
- リコール

結果:
- 材料・工数の二重消費
- 納期遅延
- 顧客信頼の喪失
- ブランド毀損

悪い例:
- バグの発生
- 仕様の誤解による作り直し
- テスト不十分での不具合
- 本番環境でのトラブル

結果:
- デバッグ工数
- 顧客への影響
- チームの士気低下
- 機会損失

ポカヨケ（Error-Proofing）:
- 間違えようがない仕組み
- 物理的に正しい方法でしかできない設計
- チェックリストの活用

自働化:
- 異常を検知したら即停止
- 不良を次工程に流さない
- その場で原因究明・対策

問題:
- 作業者が商品のところまで歩く
- 1日10-20km歩行
- ピッキング時間の70%が移動時間

結果:
- 低い生産性
- 作業者の疲労
- 配送時間の長さ

Kiva Robots導入（現Amazon Robotics）:
- 棚が作業者のところに来る
- 作業者は移動せず定位置でピッキング
- ロボットが最適経路で搬送

効果:
- 移動時間75%削減
- 倉庫収容能力50%増加
- 注文処理時間半減

従来:
- 商品が揃うまで梱包できない
- 梱包完了まで発送できない
- 工程間での待ち時間発生

予測的ピッキング:
- 注文確定前に商品を近くに配置
- 注文が入った瞬間に梱包開始
- 複数注文の並行処理

効果:
- 注文から発送まで数時間
- Prime会員への翌日配送実現

従来の小売:
- 店舗に大量在庫
- 売れ残りリスク
- 陳腐化

FBA（Fulfillment by Amazon）:
- 出品者の在庫をAmazon倉庫に集約
- データによる需要予測
- 地域ごとの最適在庫配置

効果:
- 在庫回転率の大幅向上
- 出品者のリスク軽減
- 配送時間の短縮

問題:
- 使われない機能の実装
- 大規模リリース

解決策:
- Squad制（小規模自律チーム）
- 小さく早くリリース
- A/Bテストで検証してから拡大

効果:
- 開発速度向上
- 失敗コスト最小化

問題:
- 承認待ちでリリース遅延
- 他チーム依存

解決策:
- 自律的デプロイ権限
- マイクロサービス化
- Continuous Delivery

効果:
- 1日100回以上のデプロイ
- 機能追加速度の劇的向上

問題:
- 本番でのバグ発見
- 大規模障害

解決策:
- 自動テスト充実
- カナリアリリース
- 即座のロールバック機構

効果:
- 障害の影響範囲最小化
- 安心して高速リリース

同じ生産台数で:
- 在庫: 他社の1/10
- 生産リードタイム: 他社の1/2
- 不良率: 他社の1/5
- 工場面積: 他社の2/3

結果:
- 圧倒的な利益率
- 価格競争力
- 市場シェア拡大

在庫が多い状態:
- 問題があっても在庫でカバー
- 問題が隠れたまま
- 根本原因不明

在庫削減後:
- 問題が即座に顕在化
- すぐに対処
- 継続的改善

在庫削減:
- 固定資産減少
- 現金の確保
- 投資余力の創出

リードタイム短縮:
- 回転率向上
- キャッシュサイクル改善

小ロット生産:
- 需要変化への即応
- 多品種対応
- カスタマイズ容易

結果:
- 市場適応力
- 競争優位性

❌ 間違った適用:
「ムダ排除のためにコスト削減」
→ 価値創造の削減

✅ 正しい理解:
「価値創造のためにムダ排除」
→ 顧客価値が最優先

問題:
- サプライチェーン寸断時の脆弱性
- 需要急増への対応不可
- 災害・パンデミックでの供給停止

対策:
- リスク分析とのバランス
- 戦略的在庫の保持
- サプライヤー多様化

初期フェーズ:
- まず実現（効率無視）
- 手作業でも良い
- 100回コピペも許容

成熟フェーズ:
- ボトルネック特定後
- 7つのムダで改善
- 段階的効率化

重要: タイミングを間違えない

手法だけ導入しても失敗:
- カンバン方式導入
- しかし押し込み生産継続
- 形だけのTPS

成功の鍵:
- 全員参加の改善文化
- 現場の自律性
- トップのコミットメント

Lean Software Development:
- 作りすぎのムダ → MVP、段階リリース
- 手待ちのムダ → CI/CD、自動化
- 不良のムダ → TDD、自動テスト

Growth Hacking:
- 作りすぎのムダ → 小規模実験
- 加工のムダ → シンプルなLP
- 在庫のムダ → コンテンツの即公開

病院運営:
- 手待ちのムダ → 予約システム最適化
- 運搬のムダ → 電子カルテ
- 動作のムダ → 動線設計改善