WBSで進捗管理する方法｜遅延タスクの見える化とリスケ判断の実務手順

「WBSは作った。でも、プロジェクトが始まったら誰も見ていない」

プロジェクト計画フェーズでWBSを作ったものの、実行フェーズに入ると、結局チャット、口頭報告、週次定例の雰囲気だけで進捗を追っている。

この状態に心当たりはないでしょうか。

WBSは、作成して終わりの計画資料ではありません。

本来は、毎週の進捗確認、遅延タスクの発見、リスケ判断、関係者への説明に使うための管理ツールです。

しかし、現場では次のようなことがよく起こります。

WBSが作成時点のまま更新されていない
担当者や実績日が空欄のままになっている
進捗率が人によってバラバラに入力される
遅延タスクがどれか一目で分からない
どの遅延が全体納期に影響するのか分からない
定例会議でWBSを見ず、口頭報告だけで終わっている

この状態では、WBSはプロジェクトを前に進める道具ではなく、単なる計画書の添付資料になってしまいます。

この記事では、WBSを進捗管理に使うための実務手順を、PM向けに解説します。

この記事で分かること

この記事では、次の内容を扱います。

分かること	内容
使えるWBSと使えないWBSの違い	進捗管理に使えるWBSの条件が分かる
WBSに必要な列構成	計画・実績・担当・進捗率・遅延理由をどう持つか
進捗率の入力ルール	0%、30%、70%、100%などの使い方が分かる
遅延タスクの見つけ方	条件付き書式や確認観点を整理できる
リスケ判断の基準	どの遅延で再計画を検討すべきか分かる
週次定例での使い方	WBSを会議資料ではなく判断材料にできる

WBSの作成前提を整理したい場合は、AIでWBSを作る前の準備も参考になります。

AIでWBSのたたき台を作る方法は、AIでWBSを作成するプロンプト例で解説しています。

この記事では、WBSを作った後に、どう進捗管理へつなげるかに絞ります。

WBSを作って終わりにすると何が起きるか

WBSを作っただけで運用しないと、プロジェクトでは次のような問題が起きます。

計画時点ではタスクが整理されている
↓
実行フェーズで誰も更新しない
↓
進捗確認が口頭報告になる
↓
遅延の兆候が見えない
↓
後続タスクへの影響に気づくのが遅れる
↓
納期直前にリカバリー不能な遅延として表面化する

特に危険なのは、PMが「なんとなく遅れている気がする」と感じているだけで、数字やタスク単位で説明できない状態です。

この状態では、上司や顧客に報告するときも、

少し遅れています
なんとか巻き返します
確認中です

という曖昧な説明になりがちです。

一方、WBSが進捗管理に使えていれば、次のように説明できます。

要件定義フェーズのうち、業務ヒアリング結果整理が2営業日遅れています。
ただし、後続の基本設計開始までは3営業日のバッファがあるため、現時点では全体納期への影響はありません。
今週金曜までに整理を完了し、来週月曜の設計開始時点で再確認します。

この違いが、PMとしての説明力の差になります。

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

まず、進捗管理に使えるWBSと、使えないWBSの違いを整理します。

観点	使えないWBS	使えるWBS
タスク粒度	「開発」「テスト」など大きすぎる	担当者が見積・実行できる単位になっている
担当者	空欄またはチーム全体	責任者が1名に決まっている
日付	計画終了日だけ	計画開始・終了、実績開始・終了がある
進捗	口頭報告だけ	進捗率やステータスが入力される
遅延理由	記録されない	備考・課題欄に残る
更新頻度	作成時だけ	毎週更新される
会議利用	定例で見ない	定例の判断材料になる

WBSは、見た目が細かいだけでは意味がありません。

進捗管理に使うには、少なくとも「誰が」「いつまでに」「何を完了するか」「今どうなっているか」が分かる必要があります。

WBS進捗管理に必要な基本列

ExcelやGoogleスプレッドシートでWBSを管理する場合、まず列構成を標準化します。

おすすめの基本列は次の通りです。

列名	用途
WBSコード	タスクの階層や親子関係を示す
フェーズ	要件定義、設計、開発、テストなど
タスク名	作業内容を書く
成果物	そのタスクで作るものを書く
担当者	責任者を1名に決める
計画開始日	当初計画の開始日
計画終了日	当初計画の終了日
実績開始日	実際に着手した日
実績終了日	実際に完了した日
進捗率	0%、30%、70%、100%など
ステータス	未着手、進行中、レビュー中、完了、保留など
遅延理由	遅れている場合の理由
後続影響	後続タスクへの影響有無
メモ	課題、リスク、確認事項

最初から列を増やしすぎると、更新されなくなります。

最低限は、次の8列でも構いません。

タスク名
担当者
計画開始日
計画終了日
実績開始日
実績終了日
進捗率
備考

ただし、PMとして遅延判断をしたいなら、できれば「成果物」「遅延理由」「後続影響」は持っておくと便利です。

進捗率は細かくしすぎない

WBS運用でよくある失敗が、進捗率を細かく入力させることです。

35%
47%
62%
90%

のような数値は、一見正確に見えます。

しかし、実際には担当者の感覚に依存しやすく、PMが判断しにくくなります。

現場運用では、次のような段階方式の方が使いやすいです。

進捗率	意味	入力基準
0%	未着手	まだ作業を開始していない
30%	着手中	調査、確認、設計、実装に着手している
70%	実体作業はほぼ完了	レビュー、確認、テスト待ち
100%	完了	完了条件を満たしている

重要なのは、100%の定義です。

たとえば、開発タスクなら、

コードを書き終えた

ではなく、

レビューが完了し、必要なテストが通り、次工程へ渡せる状態

を100%にする方が安全です。

完了条件をタスクごとに決める

WBS進捗管理では、「完了」の定義が揃っていないと、進捗率が信用できません。

よくある失敗は、担当者によって100%の意味が違うことです。

タスク	悪い完了定義	良い完了定義
設計書作成	書き終えた	レビュー指摘を反映し、承認された
実装	コードを書いた	レビュー完了・単体テスト完了
テスト	一通り確認した	テスト仕様書に沿って実施し、結果を記録した
顧客確認	メールした	顧客から承認または指摘を受領した
リリース準備	手順を考えた	手順書・切り戻し手順・確認担当が決まった

WBSに成果物列を入れると、完了条件をそろえやすくなります。

「何を作れば終わりか」が見えるからです。

毎週の更新ルールを決める

WBSが形骸化する最大の理由は、誰も更新しないことです。

更新されないWBSは、すぐに現実とズレます。

そのため、プロジェクト開始時に更新ルールを決めておきます。

たとえば、次のようにします。

毎週木曜午前中までに、各担当者が自分のタスクを更新する
PMは木曜午後に遅延タスクと後続影響を確認する
金曜の週次定例で、WBSを見ながらリカバリー方針を決める

このように、更新タイミングと会議での使い方をセットにすると、WBSが運用されやすくなります。

更新時に担当者が入力する項目

メンバーに入力してもらう項目は、多すぎない方がよいです。

最低限、次の4つで十分です。

入力項目	内容
進捗率	0%、30%、70%、100%
実績開始日	着手した日
実績終了日	完了した日
備考	遅延理由、困っていること、確認待ち

この4項目だけでも、PMはかなり状況を把握しやすくなります。

WBS・スケジュール管理を実務で使える形にしたい方へ
WBSは作って終わりではなく、進捗管理、遅延検知、リスケ判断に使って初めて価値が出ます。
WBS分解から工数見積、スケジュール管理、遅延時の判断まで体系的に学びたい方は、関連講座も確認してください。
WBS・スケジュール管理の講師クーポン対象講座を見る

遅延タスクを見える化する

WBSを更新しても、遅延タスクが見えにくいと意味がありません。

ExcelやGoogleスプレッドシートを使う場合は、条件付き書式で次のようなタスクを色付けします。

計画終了日を過ぎている
かつ
進捗率が100%ではない

これだけでも、遅延タスクを見つけやすくなります。

さらに、次の条件も色分けできると便利です。

条件	表示
計画終了日超過・未完了	赤
計画終了日まで2営業日以内・進捗70%未満	黄
実績開始日が未入力のまま計画開始日を過ぎている	オレンジ
後続影響あり	赤太字または別列で強調
担当者未設定	グレー

重要なのは、見た目を派手にすることではありません。

PMが週次定例前に「どこを見るべきか」をすぐ判断できる状態にすることです。

遅延タスクを確認するときの3つの質問

遅延タスクを見つけたら、PMは次の3つを確認します。

質問	確認すること
なぜ遅れているのか	技術課題、仕様未確定、レビュー待ち、リソース不足など
何に影響するのか	後続タスク、顧客確認、リリース日、他チーム作業
どうリカバリーするのか	担当変更、並行作業、スコープ調整、期限再設定など

ここで注意したいのは、遅延理由を「担当者の頑張り不足」にしないことです。

遅延の背景には、次のような構造的な原因があることが多いです。

タスクの粒度が大きすぎた
完了条件が曖昧だった
前提となる仕様が決まっていなかった
レビュー担当者の稼働が不足していた
後続タスクとの依存関係が見えていなかった
見積時にリスクを過小評価していた

WBSは、担当者を責めるための表ではありません。

遅延を早く見つけ、チームでリカバリーするための道具です。

リスケ判断の基準を持つ

遅延を見つけたあと、PMが悩むのが「リカバリーするか、リスケするか」です。

この判断を毎回感覚で行うと、報告や顧客説明が遅れます。

あらかじめ判断基準を持っておくと、冷静に対応できます。

状況	判断	PMがやること
非クリティカルなタスクが1〜2日遅延	リカバリー可能性を確認	担当者と対応策を決める
クリティカルパス上のタスクが3営業日以上遅延	リスケ検討	影響範囲と代替案を整理する
後続タスクの開始が止まっている	早急に調整	並行作業・順序変更・支援投入を検討する
複数タスクが同時に遅延	計画見直し	スコープ、体制、納期の再検討を行う
リカバリー策の実現性が不明	期限付きで確認	2〜3営業日で実態把握し判断する
顧客作業待ちで止まっている	顧客調整	確認期限と影響を伝える

リスケは、PMが一人で抱えるものではありません。

WBSを使って遅延の根拠を見える化し、関係者と合意するための判断材料にします。

週次定例でWBSを使う進め方

WBSは、更新して終わりではありません。

週次定例で使って初めて意味があります。

おすすめの進め方は次の通りです。

1. 完了タスクを確認する
2. 遅延タスクを確認する
3. 後続影響があるタスクを確認する
4. 今週判断が必要なタスクを確認する
5. リカバリー策・担当・期限を決める
6. 次回までの更新ルールを確認する

会議では、すべてのタスクを1行ずつ読み上げる必要はありません。

見るべきなのは、次の3種類です。

見るべきタスク	理由
遅延しているタスク	リカバリーが必要だから
後続影響があるタスク	全体納期に影響する可能性があるから
今週判断が必要なタスク	PM・顧客・上司の意思決定が必要だから

WBSを定例の中心に置くと、会議が単なる報告会から、判断と調整の場に変わります。

PMが週次定例前に見るべきWBSチェックリスト

週次定例の前に、PMは次の項目を確認します。

チェック項目	確認すること
未更新タスク	担当者が更新していないタスクはないか
計画終了日超過	期限を過ぎて未完了のタスクはないか
未着手遅延	計画開始日を過ぎても未着手のタスクはないか
70%停滞	70%のまま長く止まっているタスクはないか
後続影響	遅延が次工程に影響していないか
担当者偏り	特定メンバーにタスクが集中していないか
顧客待ち	顧客確認や承認待ちで止まっていないか
リスク化	課題管理表やリスク管理表に転記すべきものはないか

WBSだけで全てを管理する必要はありません。

遅延理由が大きくなったものは課題管理表へ、将来影響が出そうなものはリスク管理表へ移します。

AIを使ってWBS進捗管理を支援する

WBS進捗管理でも、AIは補助的に使えます。

たとえば、週次更新後のWBSをもとに、次のような依頼ができます。

以下のWBS進捗状況を確認し、PMが週次定例で確認すべきタスクを整理してください。

# 見てほしい観点

1. 計画終了日を過ぎている未完了タスク
2. 後続タスクに影響しそうな遅延
3. 担当者にタスクが集中している箇所
4. 70%のまま停滞しているタスク
5. 顧客確認待ちで止まっているタスク
6. 課題管理表に転記すべき事項

# 出力形式

| 優先度 | タスク | 状況 | 確認すべきこと | 推奨アクション |
|---|---|---|---|---|

# WBS
ここにWBSの内容を貼り付ける

ただし、機密情報や個人情報をそのままAIに入力しないように注意してください。

AIは、進捗会議のアジェンダ作成や遅延タスクの整理には便利です。

一方で、リスケ判断、顧客報告、スコープ変更の合意はPMが責任を持って行う必要があります。

よくある質問

WBSの進捗率は何%刻みがよいですか？

実務では、0%、30%、70%、100%のような粗い段階方式がおすすめです。

細かい数値は正確に見えますが、担当者ごとの感覚差が大きくなります。

重要なのは、100%の定義をチームで揃えることです。

WBSは毎日更新すべきですか？

小規模案件や短期案件であれば、毎日更新が有効な場合もあります。

ただし、多くのプロジェクトでは、週次更新から始める方が現実的です。

まずは「週次定例前に必ず更新する」ルールを定着させることを優先しましょう。

WBSと課題管理表は分けるべきですか？

分けた方が管理しやすいです。

WBSはタスクの計画と進捗を管理する表です。

一方、課題管理表は、解決すべき問題、判断待ち、関係者調整事項を管理する表です。

WBS上で遅延理由やブロッカーを見つけたら、必要に応じて課題管理表へ転記します。

WBSが大きくなりすぎた場合はどうすればよいですか？

全タスクを同じ粒度で追う必要はありません。

PMが週次で見るのは、遅延、後続影響、判断待ち、顧客確認が関係するタスクを中心にします。

詳細タスクはチーム内で管理し、PM用WBSでは管理粒度を少し上げる方法もあります。

まとめ

WBSは、作って終わりの計画書ではありません。

毎週更新し、遅延を見つけ、後続影響を確認し、リスケ判断や顧客説明に使って初めて価値が出ます。

重要なのは、次の流れです。

WBSを作る
↓
担当者・計画日・成果物を入れる
↓
毎週の更新ルールを決める
↓
遅延タスクを見える化する
↓
後続影響を確認する
↓
リカバリーまたはリスケを判断する
↓
週次定例で合意する

PMに必要なのは、WBSをきれいに作ることだけではありません。

WBSを使って、プロジェクトの状態を説明し、チームとリカバリー策を決め、関係者と合意することです。

進捗管理に使えるWBSを運用できるようになると、PMの報告、判断、調整の質が大きく変わります。