WBSがあるのに遅延するのはなぜ?形骸化を防ぐ週次更新のコツ
キックオフのときにWBSはちゃんと作った。ガントチャートも引いて、関係者に配った。それなのに、気づけば納期の2週間前に「間に合いません」の一言が飛び出す──。こうした場面で振り返ると、原因がWBSそのものの出来にあるとは限りません。よくあるのは、初日に作ったWBSがそのまま止まっていて、現場で実際に動いている作業と別物になっているパターンです。WBSがあるのに遅延するのは、WBSが「無い」からではなく「生きていない」から、と言い換えられます。
この記事では、WBSを持っているプロジェクトがそれでも遅れる5つの原因と、形骸化を見分けるサインを整理したうえで、「週次更新」を無理なく回すコツ──更新する項目と順序、所要時間の目安、直近だけ細かく持つ考え方──をまとめます。作り方そのものはWBSの作り方5ステップに譲り、ここでは「作った後」に絞ります。
WBSがあっても遅延が止まらない5つの原因
WBSは、プロジェクトの範囲を成果物や作業へ階層的に分解した一覧です(PMIの定義では「成果物指向の階層的分解」)。つまりWBSが示すのは「何をやるか」であって、「いつ・誰が・どの順で」までは含みません。この性質を押さえると、「WBSがあるのに遅れる」理由が見えてきます。
| 原因 | 現場で起きていること | 見分け方 |
|---|---|---|
| 1. 作業一覧で止まっている | タスク名は並んでいるが、工数・担当・先行タスクが空欄。順序と負荷が読めず、遅れの波及も追えない | 「この行が1週間遅れたら終了日はどれだけ動く?」に即答できない |
| 2. 粒度が粗すぎる | 1行が2〜3週間の塊。途中の遅れが行の中に隠れ、期日当日に初めて表面化する | 進捗率が「30%→30%→80%」のように週をまたいで動かない行がある |
| 3. 更新の主体と曜日が未定 | 誰がいつ更新するか決めておらず、初日のスナップショットのまま放置される | 最終更新日がキックオフ日、または2週間以上前 |
| 4. 進捗が感覚値 | 「だいたい7割」の自己申告が並び、予定との差が数字として出てこない | 90%前後で止まる行が複数ある(90%症候群) |
| 5. 動く条件が無い | 遅れが見えても「もう少し様子を見よう」で先送りされ、判断が締め切り直前に集中する | 「何日ずれたら再計画するか」を言語化していない |
5つのうち1と2はWBSの作りの問題、3〜5は運用の問題です。作りの問題は一度直せば済みますが、運用の問題は仕組みにしない限り毎週再発します。この記事の主題は後者です(粒度の目安はWBSはどこまで細かく分解すべき?を参照)。
形骸化したWBSのサイン──セルフチェック
「うちのWBSは形骸化していないか」の判定は、思いのほか難しいものです。作った本人は「あるつもり」でいますし、メンバーも面と向かって「見ていません」とは言いません。そこで、主観を挟まずに確かめられる項目を挙げます。2つ以上当てはまるようなら、WBSは実務から離れ始めていると考えてよいでしょう。
- 最終更新日が2週間以上前、または更新した人が誰か分からない
- 実際には終わっている作業が、WBS上では「未着手」のまま残っている
- いま手を動かしている作業が、WBSのどの行にも対応していない(行が無い)
- 先週と今週で、進捗率が1行も変わっていない
- 週次の打ち合わせで、誰もWBSのファイルを開かずに口頭で状況を確認している
- 終了予定日を聞かれると、WBSではなく担当者の記憶で答えている
※「WBSに無い作業」は、追加作業の発生自体ではなく、それが書き足されていないことが問題です。
共通しているのは、WBSが「参照される場面」を失っていることです。形骸化を防ぐには、更新を義務として課すより先に、毎週WBSを開かざるを得ない場面を設計するのが近道です。
形骸化を防ぐ週次更新のコツ──何を・どの順で・何分で
週に一度、曜日と時間を決めて更新する──やること自体は単純ですが、続けるのは簡単ではありません。続かない一因は、更新の中身が決まっておらず、毎回「何を直せばいいんだっけ」から始まるところにあります。そこで、項目と順序を先に固定します。
更新の5項目と順序
| 順 | 更新項目 | やること | 目安 |
|---|---|---|---|
| ① | 完了・進捗 | 先週着手した行の進捗率を更新し、終わった行を完了にする | 3分 |
| ② | 追加・削除 | 新しく発生した作業を行として足し、不要になった行を消す。直近に入ってきた粗い行はここで分解する | 3分 |
| ③ | 工数のずれ | 「思ったより重い」行の残工数を書き換える。見積もりの言い訳ではなく現時点の見込みとして | 3分 |
| ④ | 先行タスク・担当 | 順序の変更や担当の入れ替えがあれば反映する | 2分 |
| ⑤ | 再計算と確認 | スケジュールを引き直し、完了予定日が先週から何日動いたかを見る | 2〜4分 |
順序に意味があります。①②で「行の集合」を実態に合わせ、③④で「各行の中身」を直し、最後に⑤で「全体への影響」を確かめます。この順なら、更新の途中で終了日が何度も動いて混乱することが減ります。所要は合計15分前後が目安で、これを大きく超えるなら粒度が細かすぎるか、更新の間隔が空きすぎているサインです。
担当者は「自分の行だけ」、取りまとめ役は「⑤だけ」
更新を一人に集中させると、その人が忙しい週に止まります。各担当者が自分の行の①〜③を金曜の退勤前などに済ませ、取りまとめ役は月曜の朝に④⑤だけを行う、という分担にすると、どちらの負担も数分で収まります。
直近は細かく、先は粗く(ローリングウェーブ)
形骸化のもう一つの温床は、「最初に全期間を細かく書き切ろうとした」WBSです。3か月先の作業を1日単位まで刻んでも、そこに至るまでに前提が変わり、書き直しの量に耐えられなくなります。プロジェクトマネジメントの分野では、直近の作業は詳細に、先の作業は大まかに計画し、進むにつれて先の部分を詳細化していく考え方を「ローリングウェーブ計画」と呼びます。週次更新に組み込むなら、「今週から2〜3週先までは1行が数日以内になるまで分解し、それより先は成果物単位の行1本で置く」というルールが実用的です。週次の②で直近の粗い行を分解していけば、毎回全体を見直す必要はありません。
週次で見る「3つの問い」と、動く条件を先に決めておく
更新が済んだら、確認の場では表を眺めるのではなく、次の3つの問いに答える形にすると議論が締まります。
- 先週着手する予定だった行は、予定どおり始まったか ──「終わったか」より先に「始まったか」を見ます。着手の遅れは、その先の遅れの最も早い予告です。
- 今週始まる行の前提はそろっているか ── 先行タスクの完了、必要な情報や承認、担当者の稼働(休み予定を含む)を確かめます。
- 完了予定日は先週から何日動いたか、原因はどの行か ── ここで初めて全体の話をします。
そして、3つ目の答えに対して「どうなったら動くか」を先に決めておきます。たとえば「完了予定日が3営業日以上後ろへ動いたら、その週のうちに範囲か体制の見直しを議題にする」「同じ行が2週続けて『遅れ』なら分割して原因を特定する」といった条件です。条件が無いと、判断は「もう少し様子を見る」に流れ、締め切り直前に選択肢の無い状態で決断を迫られます。工程全体にバッファを1本立てている場合は、その残量の減り方も同じように条件化できます(→工数見積もりのバッファは何割が目安?)。進捗率の刻みや予実差の見方は進捗の予実管理入門で扱っています。
更新を軽くする仕組み──手で引き直さない
ここまでの運用が続くかどうかは、⑤の「再計算」がどれだけ軽いかに大きく左右されます。表計算で線表を手で引いていると、1行の工数を変えるたびに後続の日付をすべて動かすことになり、この面倒さで更新が止まるのが典型的な形骸化の入り口です。工数や順序を書き換えれば終了日が引き直される仕組みがあれば、週次更新は「入力して、完了予定日の変化を読む」だけになります。
進捗%を更新して「⚡ 自動スケジュール」を押すだけ。完了予定日と遅れの行が毎週見える。無料・登録不要。
WBSプランナーは、タスク表に工数・先行タスク(WBS番号で指定)・担当・優先度を入れると、依存関係→優先度→表の並び順という決まったルールでスケジュールを引き直し、完了予定日を表示します。進捗%を入力すると「状態」列が未着手・進行中・完了に自動で切り替わり、「進捗(予実)」タブでは予定進捗率・実績進捗率・今日時点の予実差・完了予定日のサマリーと、予定と実績の推移(Sカーブ)、タスク別の予定・実績バーが見られます。タスク別のバッジは予定との差が5ポイントを超えると「遅れ」または「先行」、範囲内なら「順調」と表示されるので、週次確認の材料がそのまま出てきます。入力内容はブラウザ内に自動保存され、サーバーへは送られません。
週次更新に当てはめると、①はタスク表の「進捗%」欄、②は「＋ タスクを追加」と削除ボタン、③は「工数」欄、④は「先行」欄と「担当」欄、⑤は「⚡ 自動スケジュール」ボタン、という対応です。工数が0の末端タスクは計算対象外として表の上に注意が出るので、工数欄を空にしたままの行にも気づけます。更新後の状態を「⬇ CSV出力」で週ごとに保存しておけば、完了予定日の変化を後から追えます。「⬆ CSV取込」で読み戻せるのはこの出力形式のCSVなので、引き継ぎや別の端末での復元に使えます。
まとめ
WBSがあるのに遅延するのは、WBSが無いからではなく、初日のまま止まって実態と離れてしまうからです。原因は、作業一覧で止まっている・粒度が粗い・更新の主体と曜日が未定・進捗が感覚値・動く条件が無い、の5つに整理でき、後ろの3つは仕組みにしない限り繰り返します。
週次更新は、完了・進捗→追加・削除→工数のずれ→先行タスク・担当→再計算、の順で15分前後を目安に回し、担当者は自分の行だけ、取りまとめ役は再計算だけ、と分担して軽く保ちます。直近2〜3週だけを細かく持てば書き直しの量も抑えられます。まずは次の週次会議で、WBSのファイルを全員で開くところから始めてみてください。
※本記事は、WBSの標準的な定義(PMIによる成果物指向の階層的分解、ローリングウェーブ計画)と、2026年8月時点で一般に紹介されているプロジェクト管理の実務をもとに整理したものです。更新の頻度・所要時間・「動く条件」の数値はいずれも目安であり、プロジェクトの規模や体制によって適切な値は異なります。