「進捗どうですか？」「はい、大丈夫です」。 受託開発の週次定例で、こうしたやり取りが続いた末に、納期2週間前で突然「実は遅れています」と告げられた経験はないでしょうか。
進捗管理は、PMの仕事の中で最も「やっているつもり」になりやすい領域です。WBSは更新されているのに認識はずれ、課題管理表は項目が並んでいるのに意思決定はされない。気づけば毎週、進捗を確認するためだけの定例会議が繰り返されている、という現場は珍しくありません。
本記事では、新人〜中堅の受託PMが、定例で詰まらず・遅延を早期発見できるようになるための「WBS更新 → 課題抽出 → 意思決定」という3ステップの実行フローを解説します。理論ではなく、毎週の定例運営にそのまま落とし込める形で示していきます。
なぜ進捗管理は形骸化するのか
進捗管理が形骸化する受託開発の現場には、ほぼ共通したパターンがあります。
ひとつは、WBSを「最初に作って終わり」にしてしまうこと。キックオフ時に作ったタスク分解表を、誰も更新しないまま使い続け、現実のタスク粒度と合わなくなっていきます。「設計」「開発」「テスト」のような粗いタスクのままでは、進捗を「50%」「70%」としか答えられず、遅延の兆候は見えません。
もうひとつは、進捗会議が「報告会」と化していること。各メンバーが順番に「大丈夫です」「予定通りです」と読み上げるだけで、PMは「どこに引っかかっているか」を聞き出せず、課題が浮かび上がりません。
そして最大の罠が、課題管理表がただの「課題置き場」になっていることです。「○○の仕様が確定していない」「環境が用意できていない」と並んでいるのに、誰がいつまでに判断するかが書かれていない。結果、課題は溜まり続け、終盤に一気に火を噴きます。
これらは個別のミスではなく、進捗管理を「一連のサイクル」として捉えられていないことが原因です。WBS・課題・意思決定がバラバラに動くため、どれか1つが欠けるだけでフローが止まります。私自身、過去に大炎上させたプロジェクトでも、この3つが分断されていたことが根本原因でした（参考: 【実録】私がプロジェクトを大炎上させた話。失敗の解剖学から学ぶ、確実に避けるべき3つの根本原因）。
1. WBSを「事実ベース」で更新する
最初のステップは、WBSの粒度と更新ルールを見直すことです。
進捗を正しく捉えるためのWBSの条件はシンプルで、1タスクが1〜3営業日に収まるようにすること。これより大きい単位だと、「半分終わってます」が何の情報にもなりません。逆に細かすぎると更新コストが現場の負担になります。受託開発であれば、機能単位ではなく「画面 × 工程（設計、実装、テストなど）」のような切り口で並べると、ちょうど良い粒度になります。
そのうえで、毎週の定例直前に各担当が以下の3項目だけを更新します。
- 完了したタスク（実績日付）
- 着手中タスクの残工数（時間ではなく「あと何日」）
- 未着手タスクのうち、今週着手予定のもの
ポイントは、進捗率（%）を聞かないことです。％はメンバーの主観が入りやすく、楽観バイアスがかかります。「あと何日で終わるか」を残工数として答えてもらうと、現実の遅延が数字として浮かび上がります。WBSの作り方そのものに不安がある方は、【炎上を防ぐWBSの作り方】私が大炎上プロジェクトで学んだ３つの原則 も合わせて読んでください。
2. 定例会議で「課題」を抽出する
WBSが事実ベースで更新できれば、次の定例会議は驚くほど効率的になります。PMがやるべきことは、報告を聞くことではなく、ズレを起点に課題を抽出することです。
具体的には、定例会議の冒頭5分でWBSを画面共有し、PM自身が以下のような問いを投げます。
- 「先週着手予定だったが未着手のタスクは何が原因か」
- 「残工数が先週と変わっていないタスクで、止まっている要因は何か」
- 「来週着手予定のタスクで、不足している前提条件はあるか」
ここで出てくる「実は仕様が決まっていない」「○○さんからの回答待ち」「環境が間に合わない」といった声こそが、遅延の早期兆候です。これらはすべて課題管理表に積み上げ、その場で「誰が・いつまでに・何を判断するか」を決めます。
この場で意思決定までいかなくても構いません。重要なのは、課題が「置きっぱなし」にならず、必ず次の意思決定ステップへ送られるルートを作ることです。会議で議論が膠着して進まない場合の論点整理術は、会議で対立を収束させるPMの論点整理術｜決まらない議論を終わらせる5ステップ が参考になります。
3. 1サイクルの最後に「意思決定」を残す
3つ目のステップは、抽出した課題に対して、毎週必ず意思決定を行うことです。
受託開発で遅延が拡大する典型的なパターンは、課題が「相談中」「確認中」のまま2〜3週持ち越される構造にあります。これを防ぐために、PMは以下のいずれかの判断を1週間以内に下す前提で動きます。
- 自分で判断する（権限内のもの）
- 顧客に判断してもらう（仕様・優先度に関するもの）
- 上長・他部門にエスカレーションする（権限外・横断的なもの）
意思決定を持ち越すこと自体は悪くありません。問題は、「いつまでに、誰が、何を判断するか」が決まっていないことです。次回定例までに判断者と期限が決まっていれば、課題は前に進みます。
そして、下した判断は必ずWBSに反映します。「この機能はスコープアウト」「この工程は来週から開始」と決めたなら、WBSのタスクを削除・追加・順序変更する。ここまでやってはじめて、「WBS更新 → 課題抽出 → 意思決定」という一連のサイクルが閉じます。
このサイクルを毎週回す体制が定着すると、遅延は必ず2〜4週間前に表面化します。「終盤で突然遅延が判明する」現象は、サイクルが閉じていないことが原因なのです。
実行フェーズの判断軸を、進捗・課題・変更・品質の4領域でさらに体系的に学びたい場合は、実行管理の進め方講座が役立ちます。記事で示した3ステップの一段深い「判断の物差し」を持ちたい方は、実行管理の進め方を学ぶ講座を見る を参照してください。
迷ったらこの講座から始める
「進捗管理を体系的に学び直したいが、どこから手をつけるべきか分からない」という方は、以下の2講座から始めるのがおすすめです。
-
実行管理の進め方講座 本記事の3ステップを、判断軸と運用テンプレートまで含めて体系化した講座です。受託開発の実行フェーズで、進捗・課題・変更・品質をズレなく回したい方に最適です。週次サイクルを「自分のチームの型」として定着させたい段階で受講すると、効果がはっきり出ます。
-
受託開発のPM基礎講座 そもそもPMの役割やライフサイクル全体像が曖昧、という方はこちらが先です。スコープ・スケジュール・コスト・品質といった基礎概念を、受託開発の文脈で押さえ直すことで、実行管理の進め方講座の判断軸が頭に入りやすくなります。
進捗管理は、知識として知っているだけでは身につかず、毎週のサイクルを回す中ではじめて手に馴染みます。1サイクルでも早く回し始めることが、終盤の炎上を避ける最短ルートです。
まとめ
受託開発の進捗管理が形骸化するのは、PMの能力不足ではなく、WBS・課題・意思決定が分断されているからです。
この3つを「WBS更新 → 課題抽出 → 意思決定」という1つのサイクルに束ね、毎週回すこと。これだけで、定例で詰まることは減り、遅延は2〜4週間前に必ず表面化するようになります。
- WBSは1〜3営業日の粒度で、「残工数（あと何日）」を更新してもらう
- 定例会議では報告を聞くのではなく、「ズレ」から課題を抽出する
- 抽出した課題は、「誰が・いつまでに判断するか」を決め、1週間以内に意思決定する
来週の定例から、まずはWBSの粒度と「残工数で答えてもらう」ルールを試してみてください。1サイクル回すだけで、チームから上がってくる情報の解像度が変わります。そして、その手応えがついたタイミングで 実行管理の進め方を学ぶ講座を見る を体系学習に組み込むと、判断軸が一気に強化されます。