WBSの作り方｜4ステップと粒度・クリティカルパス・失敗パターンを実務目線で解説
「WBSの作り方は知っている。でも実際に作ると、プロジェクトが進むうちにズレが生じて使われなくなる」——こういった経験をお持ちの方は多いでしょう。作り方の手順を知っているだけでは、機能するWBSは生まれません。
機能するWBSと形骸化するWBSの差は、タスクの「粒度」の設計と、作った後の「運用の仕組み」にあります。本記事では、WBSを4ステップで作る手順を、粒度の判断基準・クリティカルパスの考え方・バッファの設計・失敗パターン別の原因まで含めて実務目線で解説します。
WBSの基本的な意味・定義・ガントチャートとの違いについては関連記事をあわせてご参照ください。
WBS作成の前に確認すべきこと
WBSを作り始める前に、2つの前提を押さえておくことが、後の手戻りを防ぐ最短ルートになります。
ゴールと成果物を先に定義する
WBSはプロジェクトのゴールから逆算して作ります。「このプロジェクトが完了したとき、何が存在しているか」を最初に言語化することが出発点です。「システムを開発する」という動詞ではなく「本番環境で動作するシステムが納品されている状態」という名詞（状態）で定義することで、何を作ればよいかが明確になります。
あわせて「スコープ」——やることとやらないことの境界——を明確にすることも重要です。スコープが合意されていないプロジェクトでは、途中で「それもやってほしい」という追加要求が入りやすく、WBSが後から膨張します。
WBSは完璧に作ろうとしない
WBSは最初から完璧に作るものではなく、プロジェクトの進行とともに精度を上げていくものです。不確実性の高いフェーズや、詳細がまだ決まっていない部分は、粗い粒度でいったん記載しておき、詳細が確定したタイミングで分解するという進め方が実務では合理的です。最初から完璧を目指すと、WBS作成に時間がかかりすぎてプロジェクト自体が動き出せなくなります。
WBSの作り方【4ステップ】
WBSは次の4ステップで作ります。ステップの順番に意味があり、飛ばすと後の修正コストが上がります。
- 01成果物・フェーズを起点にタスクを洗い出す
- 02粒度をそろえて階層に整理する
- 03依存関係を整理してクリティカルパスを特定する
- 04担当者・工数・期日を割り当てる
ステップ1：成果物・フェーズを起点にタスクを洗い出す
最初にやることは「タスクを全部書き出す」ことです。頭の中にあるタスクをすべて付箋やスプレッドシートに並べるところから始めます。この段階では順番・階層・粒度を気にしません。まず「抜け漏れなく出す」ことに集中します。
洗い出しで漏れが生じやすいのは、準備フェーズ（キックオフ・環境構築・ヒアリング）と完了フェーズ（ドキュメント整備・引き継ぎ・振り返り）です。「開発」「テスト」という本体フェーズに意識が向きがちで、前後の作業が抜け落ちます。フェーズを「準備→実行→完了」という3ブロックで考えることで、網羅性が上がります。
洗い出しはPMが単独でやるより、関係するメンバー全員で行うほうが漏れが少なくなります。各担当者しか知らない前提条件・依存関係・暗黙のタスクがあるからです。キックオフ時に全員で付箋を使って洗い出す形式が、短時間で網羅性を高める実践的な方法です。
ステップ2：粒度をそろえて階層に整理する
洗い出したタスクを、同じ性質のものをグルーピングしながら階層構造に整理します。このとき最も判断に迷うのが「どこまで細かく分解するか」という粒度の問題です。
粒度の判断基準として実務で広く使われるものを3つ紹介します。
基準1：「1名・1週間以内で完了できる」単位
1人の担当者が5営業日以内に完了できるサイズをひとつのタスクとする考え方です。これより大きいタスクはさらに分解が必要で、これより小さいタスクはまとめられる可能性があります。週次の進捗確認で「完了・未完了」が判断できる粒度になるため、進捗管理と連動しやすくなります。
基準2：「完了の定義が一文で書ける」か確認する
各タスクに「このタスクが完了した状態とは何か」を一文で書けるかを確かめます。書けないタスクは、まだ分解が足りないか定義が曖昧な状態です。「設計を進める」は書けませんが、「機能設計書のレビュー完了・承認済みの状態」なら書けます。完了基準が明確なタスクだけで構成されたWBSは、進捗管理の信頼性が大きく上がります。
基準3：不確実性の高い部分は粒度を粗くしてよい
プロジェクト初期や、詳細が決まっていないフェーズを無理に細かく分解しても意味のある粒度にはなりません。「今わかっている範囲で書き、詳細が決まったら分解する」という進め方が合理的です。
ステップ3：依存関係を整理してクリティカルパスを特定する
タスクが出揃ったら「どのタスクが終わらないと次が始められないか」という依存関係を整理します。この依存関係を踏まえて押さえておきたい概念が「クリティカルパス」です。
クリティカルパスとは、プロジェクトの完了日を決定づける、最も時間のかかるタスクの連なりです。クリティカルパス上のタスクが1日遅れると、プロジェクト全体が1日遅れます。逆にクリティカルパス外のタスクは多少の遅れが生じても全体への影響は小さく、リソース配分や優先順位の判断材料になります。
クリティカルパスの特定は複雑な計算を必要とするプロジェクトもありますが、実務上は「このタスクが遅れると絶対にプロジェクト全体が遅れる」というタスクを感覚的に洗い出すだけでも、優先順位の判断に大きく役立ちます。WBSの段階でクリティカルパスを意識しておくと、「どのタスクに余裕がなく・どこにバッファを確保すべきか」の判断が的確になります。
ステップ4：担当者・工数・期日を割り当てる
各タスクに担当者・推定工数・期日を設定します。ここで最も重要な原則が「1タスク1担当者」です。複数名が担当に書かれているタスクは、「誰かがやる」という意識になりやすく、誰も主体的に動かないリスクが高まります。共同作業のタスクでも「最終的に責任を持つ1名」を明示することが、実行の確実性を高めます。
工数の見積もりは、担当者本人に出させることが精度を高めます。作業を知っている人が見積もるほど現実に近い数値になり、PM視点では見えないリスクや前提条件が浮かび上がります。また、見積もりに参加した担当者は計画への当事者意識が高まり、自律的な進捗管理につながります。
バッファの考え方：全タスクに積まず、まとめて後ろに置く
WBSにスケジュールを組む際、バッファ（余裕時間）の設計は見落とされがちですが、プロジェクトの遅延リスクに直接影響する重要な判断です。
なぜ各タスクにバッファを積むと失敗するのか
「念のため」で各タスクに2〜3日の余裕を持たせると、WBS全体のスケジュールが実態より大幅に長くなります。担当者は「余裕があるから」と後回しにしやすくなり、全体的な緩みが生まれます。さらに、どのタスクにどれだけのバッファが積まれているか把握できないため、全体の余裕を管理できません。
この現象は「パーキンソンの法則（仕事は与えられた時間をすべて使い切る）」として知られており、余裕を個別タスクに分散させるほどプロジェクト全体が間延びするリスクが高まります。
実務上の推奨：バッファはクリティカルパスの末尾にまとめて積む
実務で効果的とされるのは、各タスクの見積もりはやや厳しめ（楽観的な数値ではなく現実的な数値）に設定し、クリティカルパスの末尾や、特に不確実性の高いフェーズの後ろにまとめてバッファを配置する方法です。
まとめたバッファは可視化され、「今バッファをどれだけ消費しているか」をPMが管理できます。個別タスクに隠れたバッファより、はるかに管理しやすい状態になります。プロジェクトの規模にもよりますが、全体工数の10〜20%程度をバッファとして確保し、後半のフェーズに配置するのが目安として使われます。
WBS作成時のポイントと注意点
ステップを知っていても、実際の作成でつまずきやすいポイントがあります。実務でよく起きる問題を整理します。
ポイント1：同じ階層のタスクは抽象度をそろえる
同じ階層に「要件定義（2週間）」と「ミーティングの議事録作成（30分）」が並んでいるWBSは、粒度がバラバラで進捗管理の基準になりません。同じ階層のタスクは「同じ問い（何をするか）」に対する答えとして同じ抽象度で並ぶ必要があります。
確認方法として、同じ階層のタスクを横に並べて「これらは同じ性質のものか」を問いかけることが有効です。性質がバラバラであれば、分解の切り口を見直す必要があります。
ポイント2：WBSは「使う」前提で設計する
WBSを「作ること」が目的になると、完成した瞬間にその役割が終わります。WBSは週次レビューでステータスを更新し、変更が生じたら反映するという運用前提で設計する必要があります。
実務上の工夫として、WBSシートに「更新日」「ステータス（未着手・進行中・レビュー待ち・完了）」「備考（遅延理由など）」の列を最初から設けておくと、更新が習慣化しやすくなります。特に「レビュー待ち」というステータスを明示的に設けることで、承認・確認待ちによる遅延が可視化されます。
ポイント3：準備フェーズと完了フェーズを必ず含める
「開発」「テスト」という中心フェーズに意識が集中し、準備フェーズ（環境構築・キックオフ・前提確認）と完了フェーズ（ドキュメント整備・引き継ぎ・振り返り）が抜けるケースが多くあります。これらが後から追加されることで、スケジュールが圧迫されます。WBSの冒頭と末尾を意識的に確認する習慣が、このパターンを防ぎます。
WBSが機能しない失敗パターンと原因
作り方の手順を知っていても、機能しなくなるWBSには共通したパターンがあります。
失敗パターン1：タスクが大きすぎて進捗が見えない
「設計」「開発」「確認」という大きな塊のままWBSを作ると、途中経過が把握できません。「設計：80%完了」という報告をもらっても、残り20%に何日かかるかが見えません。タスクを分解する目的のひとつは「完了していない状態の中身を可視化すること」です。大きすぎるタスクがある場合、さらに一段分解することで進捗の解像度が上がります。
失敗パターン2：プロジェクトの変化にWBSが追随しない
仕様変更・スコープ追加・人員変更が起きたとき、WBSを更新せずに放置すると、WBSは実態から乖離した「古い地図」になります。やがて誰も参照しなくなります。変更が生じたら即座にWBSを更新するルールを、プロジェクト開始時点で明示しておくことが重要です。
失敗パターン3：PM一人でWBSを作ってしまう
PMが単独でWBSを作ると、各メンバーの実態が反映されません。実際に手を動かす担当者しか知らない作業や前提条件が入らず、後から「あのタスクが抜けていた」という問題が起きます。WBSの作成はキックオフで全員参加で行うか、少なくともドラフトをメンバーにレビューしてもらうプロセスを経ることが重要です。
失敗パターン4：「WBSとガントチャートを別管理」して乖離が生まれる
WBSシートとガントチャートシートを別々に管理すると、片方を更新してももう片方に反映されず、両者が乖離していきます。「WBS兼ガントチャート」として1シートで管理し、WBSの各行に日付の列を追加してバーを引く形式が、更新コストを最小化する実践的な方法です。
WBSをガントチャートに展開する際のポイント
WBSが完成したら、次のステップはガントチャートへの展開です。
依存関係を反映させてから日程を決める
ガントチャートへの展開では、ステップ3で整理した依存関係が重要な情報になります。「タスクAが完了しないとタスクBを開始できない」という依存関係を反映させることで、各タスクの開始日・終了日が論理的に決まります。依存関係を無視してスケジュールを組むと、実行不可能な計画が出来上がります。
クリティカルパスを色分けする
ガントチャートでクリティカルパス上のタスクを別色で表示すると、プロジェクト全体の中でどのタスクに集中すべきかが視覚的に把握できます。クリティカルパス外のタスクは多少のリソース移動が許容できるため、人員配置の柔軟な判断にも使えます。
マイルストーンを設定する
大きなプロジェクトでは、フェーズの節目に「マイルストーン（この時点で〇〇が完了している状態）」を設定することで、全体の進捗を管理しやすくなります。週次の進捗確認でマイルストーンに対してどの位置にいるかを確認することが、遅延の早期検知につながります。
WBSは「作る力」より「使い続ける力」が問われる
WBSの作り方は、手順として覚えることができます。しかし実務では「作れる」と「使える」のあいだに大きな差があります。粒度の判断がずれていたり、依存関係の整理が甘かったりして、プロジェクトが進むにつれてWBSが実態と乖離していく経験をお持ちの方は多いでしょう。
WBSを機能させるには、タスクの分解スキルだけでなく、チーム全体の行動を構造的に設計・調整する力が必要です。これは手順を知っているだけでは身につかず、実際の課題でWBSを作り、フィードバックを受けながら精度を上げる経験の積み重ねによって培われます。
プロジェクト管理力を鍛えるなら課題解決力強化道場へ
WBSを正しく作り、チームを動かし、プロジェクトを計画通りに進める力は、プロジェクトマネジメントの核心にあるスキルです。このスキルは「手順を知る」だけでは身につかず、実務の場で繰り返し使いながら磨かれていくものです。
課題解決力強化道場は、アクセンチュア・KPMGコンサルティング・デロイトトーマツコンサルティング・PwCコンサルティング出身の現役コンサルタントが講師を務める、少人数制・ハンズオン型の実践研修です。WBSの作成を含む計画立案・タスク設計・進捗管理の力を自社の実務課題を題材に体系的に鍛えます。毎回の個別フィードバックと研修企画者との振り返りMTGにより、「分かる」から「できる」へのギャップを埋める設計になっています。プロジェクト管理力を組織に根づかせたいとお考えであれば、ぜひご相談ください。
貴社の課題に最適な研修をご提案します
・管理職のスキルにバラつきがある
・研修が現場で活きない
・自走する人材が育たない
心当たりがあれば、まずご相談ください。
貴社の状況に最適なカリキュラムをご提案いたします。
※ご相談・お見積もりは無料です
