フレームワーク活用ガイドひとことで言うと#
トヨタ生産方式の「ムダ排除」と「流れの最適化」をプロジェクトマネジメントに応用し、価値を生まない作業を徹底的に取り除く手法。必要なものを、必要なときに、必要なだけ届けることを目指す。
押さえておきたい用語#
- ムダ（Waste / Muda）
- 顧客にとって価値を生まない活動すべて。待ち時間、手戻り、過剰ドキュメントなど7つのムダに分類される。
- バリューストリーム（Value Stream）
- 要求の発生から成果物の納品まで、価値が流れる一連のプロセスを指す。
- プル型（Pull System）
- 後工程が必要とするタイミングで前工程が作業を開始する方式。過剰生産を防ぐ仕組みである。
- ラストプランナーシステム（Last Planner System）
- 実際に作業を行う担当者（ラストプランナー）が短期計画を立てる手法。建設業界で発展した。
- リードタイム
- 作業の依頼から完了までの総所要時間のこと。待ち時間を含む点がサイクルタイムとの違い。
リーンプロジェクトデリバリーの全体像#
こんな悩みに効く#
- プロジェクトの工程が長く、納品までの待ち時間が多い
- 手戻りが頻発して同じ作業を何度もやり直している
- 「とりあえず作っておく」ドキュメントやレポートが多すぎる
- チーム間の引き継ぎで情報が滞留し、ボトルネックが生まれている
基本の使い方#
具体例#
従業員18名のWeb制作会社。受注から納品まで平均 62営業日 かかっていた。顧客からの「遅い」というクレームが増え、失注も発生。
バリューストリームマッピングを実施した結果:
| 工程 | 作業時間 | 待ち時間 |
|---|---|---|
| ヒアリング・要件定義 | 3日 | 7日（社内承認待ち） |
| デザイン | 5日 | 10日（顧客フィードバック待ち） |
| コーディング | 8日 | 5日（デザイン修正待ち） |
| テスト・修正 | 4日 | 12日（顧客確認待ち） |
| 納品 | 1日 | 7日（最終承認待ち） |
正味作業時間は 21日 だが、待ち時間が 41日 もあった。プロセス効率はわずか 34%。
改善策として、顧客フィードバックの期限を契約時に合意（3営業日以内）、社内承認を週次バッチから即日Slack承認に変更、デザインとコーディングを並行作業に切り替えた。
結果、リードタイムは 62日 → 28日 に短縮。年間受注件数が 24件 → 38件 に増加し、売上は前年比 158% になった。
年商80億円のゼネコンが、マンション建設プロジェクト（総工費 12億円、工期18ヶ月）でリーンプロジェクトデリバリーを導入。従来、同規模のプロジェクトでは平均 3.2ヶ月 の工期遅延が発生していた。
ラストプランナーシステムを適用し、週次で現場の職長（ラストプランナー）が翌週の作業計画を立てるようにした。
| 指標 | 導入前 | 導入後 |
|---|---|---|
| PPC（計画達成率） | 52% | 81% |
| 工期遅延 | 3.2ヶ月 | 0.5ヶ月 |
| 手待ち時間（日平均） | 2.8時間 | 0.7時間 |
| 資材の無駄（廃棄率） | 8.3% | 3.1% |
現場の職長が「自分で立てた計画だから守る」という意識を持ったことが最大の変化だった。資材の廃棄率低下だけで 約3,700万円 のコスト削減を実現している。
シリーズAを調達した従業員25名のSaaSスタートアップ。エンジニア10名で開発しているが、機能リリースのペースが競合の半分以下だった。
バリューストリームマッピングで判明した問題:
| ムダの種類 | 具体的な内容 | 年間コスト換算 |
|---|---|---|
| 過剰生産 | 使われない管理画面を毎回作る | エンジニア工数の12% |
| 待ち | PMの仕様確認待ち（平均2.3日/件） | 年間延べ110日 |
| 手戻り | QAで差し戻し（発生率38%） | エンジニア工数の18% |
| 在庫 | レビュー待ちPR（常時15件滞留） | リードタイム+4日 |
対策として、管理画面はユーザーから要望が3件以上来てから作るルールに変更。仕様の事前合意をFigmaプロトタイプで行い、PMの確認待ちを 2.3日 → 0.5日 に短縮。PRレビューのWIP上限を3件に設定した。
6ヶ月後、機能リリースのリードタイムが 23日 → 9日 に短縮。QAでの差し戻し率は 38% → 14% に減少し、四半期あたりのリリース数が 8本 → 19本 に増えた。
やりがちな失敗パターン#
「ムダ排除」を「人員削減」と混同する — リーンは人を減らすことではなく、価値を生まない作業を減らすこと。この誤解があると現場の反発を招く。
バリューストリームマッピングを一度きりで終わらせる — プロジェクトの状況は変わる。定期的にマッピングを更新しなければ、新たなムダに気づけない。
すべてのムダを同時に排除しようとする — 一度に変えすぎると混乱する。インパクトの大きいムダから優先的に着手し、小さな改善を積み重ねるのがリーンの原則。
プル型を導入せずWIPを放置する — ムダを排除しても仕掛かりが多ければ待ち時間は減らない。WIP上限の設定はリーンの要。
現場の声を聞かずにトップダウンで押し付ける — ラストプランナーシステムが示すように、実際に手を動かす人が計画に参加しなければ改善は定着しない。
まとめ#
リーンプロジェクトデリバリーの核心は「顧客にとって価値がある作業だけに集中する」というシンプルな原則にある。バリューストリームマッピングで現状を可視化し、7つのムダを特定して排除し、プル型で仕掛かりを制御し、カイゼンで改善を止めない。この手法はIT開発・建設・製造など業種を問わず適用でき、リードタイムの短縮とコスト削減の両方を同時に実現できる点が強みである。