WBSは作った後が重要｜進捗管理に使えるWBSと使えないWBSの違い

WBSを作って終わりにしていませんか？

プロジェクト計画フェーズで丁寧にWBSを作成したにもかかわらず、プロジェクトが進むにつれて誰もWBSを参照しなくなるという、受託開発PMが最もよく陥るこの「WBS作りっぱなし問題」に、心当たりはないでしょうか。

「WBSを作った時点で計画フェーズの役割は果たした」と思っていると、現場での進捗把握はメンバーからの口頭報告やチャットだけになります。遅延を察知するのが常に後手になり、気づいたときには納期まで1週間しかない、という状況になりがちです。

WBSの本来の価値は、作成フェーズではなく運用フェーズにあります。毎週WBSを更新し、遅延の兆候をデータとして把握し、リスケを冷静に判断する武器として使う。この運用サイクルを回せるかどうかが、PMとしての実力差につながります。

この記事では、WBSを進捗管理ツールとして使いこなすための実践的な3ステップと、Excelで運用するときの具体的なコツを解説します。

「使えるWBS」と「使えないWBS」の違い

まず、進捗管理に活用できるWBSと、形骸化してしまうWBSの違いを整理します。この違いを把握することが、運用改善の出発点になります。

使えないWBSの典型パターン

よく見られる形骸化WBSには、次の特徴があります。

タスクの粒度が大きすぎる。例えば「機能A開発」のように1タスクに2週間以上かかる単位になっています。
担当者が空白になっている。例えば「チーム全員でやる」ような表現になっており、誰も責任を持ちません。
実績入力欄がない。計画値だけが記載されており、現在の状況を入力する列がありません。
保管場所がわからない。プロジェクト開始時に共有されたものの、その後どこに置いたか誰も把握していません。

このような状態になると、WBSは週次定例で参照されなくなり、進捗把握はPMの肌感覚と口頭報告だけに頼ることになります。

使えるWBSの4条件

一方、進捗管理で活用できているWBSには以下の4条件が揃っています。

タスクが1〜3日で完了できる粒度に分解されている
各タスクに担当者・開始日・終了予定日が設定されている
「計画」と「実績」の列が並んでいる
チーム全員がいつでもアクセスできる共有場所に置かれている

WBSの精度は計画フェーズで決まりますが、「使えるWBS」になるかどうかは運用フェーズの設計にかかっています。WBSの作り方については【炎上を防ぐWBSの作り方】私が大炎上プロジェクトで学んだ３つの原則で詳しく解説しているので、作成フェーズから見直したい方はあわせてご覧ください。

WBSを進捗管理に活用する3ステップ

1. 毎週の実績入力をルール化する

WBSが形骸化する最大の原因は「誰も更新しない」ことです。これを防ぐためには、WBSの更新タイミングとルールを最初に決めることが不可欠です。

具体的には、週次定例の前日（たとえば毎週木曜の午前中）を「WBS更新の日」と設定し、メンバー各自が担当タスクの状況を入力するよう取り決めます。

進捗率の入力方式は、細かい数値（37%など）よりも段階方式の方が継続しやすいです。たとえば次のような4段階を使います。

値	意味
0%	未着手
30%	着手中（仕様確認・設計中）
70%	実装中（開発・実装作業中）
100%	完了（レビュー・テスト含む）

この入力ルールをキックオフ時にチームに共有し、「木曜午前中に更新する」を習慣化することで、定例に入るたびに最新のWBSを見て議論できる状態が整います。

2. 遅延タスクを視覚的に特定する

更新されたWBSを見て、どこが遅れているかを素早く把握できる仕組みを作ります。Excelの条件付き書式を使って、「計画終了日を過ぎているのに進捗が100%に達していないタスク」を赤くハイライトするだけで、一目でボトルネックが見えます。

遅延タスクを確認する際は「遅れている」という事実だけでなく、以下の3点を確認することが重要です。

① 遅延の理由は何か

技術的課題（実装難度の読み誤り）、リソース不足（担当者の多重アサイン）、仕様変更（クライアントの要求追加）など、原因によって対処法が変わります。

② 後続タスクへの影響はあるか

WBSの依存関係（前工程と後工程）を確認し、遅延が他のタスクのスタートをブロックしていないかを把握します。クリティカルパス上のタスクが遅れていれば、全体の納期に直結します。

③ リカバリーの可能性はあるか

「週末に残業する」「別メンバーをアサインする」「仕様を縮小する」など、現実的なリカバリー案があるか検討します。

この分析ができると、定例での「なぜ遅れているのか？」という詰め問いから「どうリカバリーするか」を建設的に議論するフローへと変わります。

3. リスケ判断の軸を持つ

遅延を発見したあと、PMが最も頭を悩ませるのが「今すぐリスケするか、リカバリーを目指すか」の判断です。この判断を毎回ゼロから考えると、ステークホルダーへの説明が後手になりがちです。

あらかじめ以下の判断軸を持っておくと、冷静に対処できます。

遅延状況	推奨アクション
クリティカルパス上のタスクが3営業日以上遅延	リスケを検討。遅延幅と追加コストを試算してクライアントに報告
並行タスクの遅延がバッファ（余裕工数）内に収まる	リカバリー策を立案。週次で状況をトラック
リカバリー策の実現性が不透明	まず3営業日で実態把握してから判断
複数タスクが同時に遅延・担当者がオーバーロード	スコープ縮小またはリリース分割を検討

リスケの判断はPMの責任ですが、根拠をWBSというデータで示せるかどうかが、ステークホルダーへの説明力を大きく左右します。「感覚ではなく数字で語れるPM」になるためにも、WBSを常に最新状態に保つことが基盤となります。

ExcelでWBS進捗管理するときの実践コツ

多くの受託PMはExcelやGoogleスプレッドシートでWBSを管理しています。ツールを変えずに運用精度を上げるための実践コツを3つ紹介します。

コツ① 列構成を標準化する

プロジェクトごとに列構成が変わると、ナレッジが蓄積されません。以下の8列をベース構成として固定することをおすすめします。

列名	用途
タスク名	作業内容（動詞で終わらせる）
担当者	責任者（1名に特定）
計画開始日	当初計画
計画終了日	当初計画
実績開始日	実際の着手日
実績終了日	実際の完了日
進捗率	0/30/70/100の4段階
備考	遅延理由・リスク事項

コツ② 「完了」の定義をチームで揃える

「90%完了」という報告は、PMに実態が伝わりません。プロジェクト冒頭に「コードレビュー通過＝完了」「結合テスト通過＝完了」など、フェーズごとの完了条件を明文化しておきましょう。

コツ③ 最終更新日時を記録する

ファイルの先頭行に「最終更新日: 2026-05-02」の行を設けるだけで、古いデータを参照するミスが防げます。

AIを活用してWBS作成を効率化したい場合は、AIをベテランPMに変えるWBS作成のプロンプト術を参考にしてください。プロンプトによってWBSのたたき台を短時間で作り、そこから運用設計に時間をかけるアプローチが効果的です。

まとめ

WBSの価値は計画書としての精緻さではなく、毎週の進捗管理で実際に使われることにあります。改めて、今回解説した3ステップのポイントはこちらです。

毎週の実績入力をルール化する（定例前日に担当者が更新する習慣を作る）
遅延タスクを視覚的に特定する（条件付き書式で赤くハイライトし、原因・影響・リカバリーを確認）
リスケ判断の軸を持つ（クリティカルパスの遅延を基準に、冷静に判断する）

これらを実践することで、WBSは「作って終わりの計画書」から「毎週使う進捗管理ツール」に変わります。

週次定例でのWBS活用についてより詳しく知りたい方は、進捗管理が形骸化する受託PMへ｜定例で詰まらない3ステップ実行フローもあわせてご覧ください。

WBSを計画から実行管理まで一貫して使いこなすスキルは、テックエイドの以下の講座で体系的に学べます。

PJM-103：プロジェクト計画の実務（WBS分解から計画精度を上げる手法を実践形式で習得）
PJM-104：プロジェクト実行管理（進捗管理・変更管理・課題管理の実践サイクルを習得）
IPJ-103：受託開発PM実践（クライアント折衝を含めた実務対応力を身につける）

詳細はテックエイドの講座一覧でご確認ください。現場ですぐに使えるWBS運用スキルを、実践演習を通じて習得できます。