WBSの作り方｜テンプレート構成と、粒度で失敗しないための基準
プロジェクトが遅れる原因の多くは、能力不足ではなく「やるべき作業が全部見えていなかった」ことにあります。WBSは、作業を漏れなく洗い出して階層に整理するための道具です。この記事では、そのまま複製して使えるWBSテンプレートの構成と作り方、そして多くの現場がつまずく「粒度」の判断基準を整理します。
WBSは Work Breakdown Structure の略で、日本語では「作業分解構成図」と訳されます。プロジェクトの成果物や作業を、大きな塊から小さな単位へ段階的に分解し、階層構造で表したものです。最小単位まで分解されたものを「ワークパッケージ」と呼び、これが担当割り当てと工数見積もりの単位になります。
WBSの根底にあるのは「100%ルール」という考え方です。ある階層の子要素をすべて足すと、その親要素の作業が過不足なく100%になっている状態を指します。逆に言えば、WBSに載っていない作業はプロジェクトの範囲外である、という宣言でもあります。この原則を守ると、スコープの境界が自動的にはっきりします。
順序としては、WBSで作業を洗い出してから、それをガントチャートに落として日程を引きます。いきなりガントチャートを引き始めると、思いついた作業だけが並び、抜けたまま日程が固まってしまいます。
ExcelやGoogleスプレッドシートで作る場合、次の11列を用意すれば実務で困ることはほぼありません。左から順に並べて、1行目を見出しにしてください。
これに加えて、発注側と受注側が混在するプロジェクトなら「担当区分（自社／委託先）」の列を足すと、役割の押し付け合いを防げます。
以下の階層をそのままコピーして、自社の案件に合わせて足し引きしてください。第1階層をフェーズ、第2階層を作業グループ、第3階層をワークパッケージ（実際に担当を割り当てる単位）としています。
この骨格は、広告キャンペーンやイベント運営にもほぼそのまま転用できます。フェーズ名を「企画／設計／制作／実施・検証」に読み替えてください。
何が完成すればこのプロジェクトは終わりなのかを一文で書きます。ここが曖昧なまま分解を始めると、途中で「これも必要では」という追加が止まらなくなります。
第1階層は、時系列の大きな区切り（企画・設計・制作・テスト・公開）か、成果物の種類で分けます。どちらでも構いませんが、途中で軸を混ぜないことが重要です。軸が混ざると、どの枝に入れるべきか判断できない作業が出てきます。
各フェーズを、担当者1人に割り当てられて工数を見積もれる単位まで分解します。分解の途中では100%ルールを意識し、「この階層の子を全部足したら親になるか」を都度確認します。ここで漏れが見つかるのが、WBSを作る最大の価値です。
最下層の行にだけ担当と工数を入れ、上位階層は合計値を表示させます。上位に直接工数を入れると二重計上になるため、集計はSUM関数に任せます。レビューや承認待ちの時間も、忘れずに行として立てておきます。
先行タスク列を埋め、どの作業が遅れると全体が遅れるか（クリティカルパス）を確認します。そのうえで開始日・終了日を入れ、ガントチャートに展開します。稼働率100%を前提にすると必ず破綻するため、7〜8割で見ておくのが現実的です。
WBSで最も多い失敗は、分解が粗すぎるか細かすぎるかのどちらかです。粗すぎれば進捗が分からず、細かすぎれば更新が追いつかず放置されます。次の4つの基準を当てはめれば、ほとんどの場合は適切な粒度に収まります。
1つのワークパッケージを、8時間以上80時間以内に収める考え方です。おおよそ1日から2週間の作業量にあたります。8時間を下回るなら細かすぎ、80時間を超えるならもう一段分解します。プロジェクト管理の現場で最も広く使われている目安です。
週次で進捗会議を開くなら、1つの作業は1〜5日程度に収めます。2週間かかる作業は、週次会議で2回続けて「進行中」としか報告できず、遅れの兆候を捉えられません。報告の間隔より作業が長い場合は、必ず中間成果物を挟んで分割します。
その作業に成果物を書けるかどうかが試金石です。「デザインを検討する」は完了を判定できませんが、「デザイン案を3案提出する」なら判定できます。成果物欄が埋まらない行は、粒度ではなく定義の問題を抱えています。
複数人にまたがる作業は、まだ分解が足りていません。1行に1人が対応するまで割ると、誰かが止まったときにその場所が即座に特定できます。逆に、同じ人が連続して行う細かい作業を別々の行に分けているなら、統合しても情報は失われません。
なお、粒度は全体で均一である必要はありません。直近のフェーズは細かく、先のフェーズは粗く置いておき、着手が近づいたら詳細化する進め方（ローリングウェーブ）が実務的です。半年先の作業を今から1日単位で刻んでも、その通りにはなりません。
作業の洗い出しと構造化はExcelやスプレッドシートが最も速く、自由度も高いため、最初のWBS作成には向いています。一方、日々の進捗更新まで表計算で回そうとすると、更新漏れとファイルの分裂が起きます。
同時編集で誰かの入力が消える、最新版がどれか分からなくなる、担当者が自分の担当行を見つけられない。こうした症状が出始めたら、プロジェクト管理ツールへの移行を検討するタイミングです。判断の目安は、関係者が5名を超えるか、案件が3つ以上並行するかどうかです。
3〜4階層が実務上の目安です。5階層を超えると、番号を追うだけで疲れて誰も見なくなります。深くしたくなったら、そのフェーズを別プロジェクトとして切り出せないかを先に検討してください。
1〜2週間で終わる案件なら、2階層20行程度の簡易版で十分です。重要なのは形式ではなく、着手前に作業を洗い出す工程を挟むこと自体です。その30分が、後半の徹夜を防ぎます。
行を追加し、増えた工数と日程への影響をその場で可視化します。WBSの価値は、追加作業が全体に与える影響を数字で示せる点にあります。「これを追加すると公開が3日後ろにずれます」と言えるかどうかで、要望の扱われ方は変わります。
作業の体感ではなく、完了したワークパッケージの数か工数で測ります。担当者の申告する進捗率は主観が入りやすいため、粒度を細かくして「完了したかどうか」の二択で積み上げるほうが、実態に近い数字になります。
WBSは、プロジェクトの作業を漏れなく分解し、担当と工数を割り当てるための構造です。本記事の列構成とサンプル階層をコピーすれば、テンプレートとしてすぐに使い始められます。
そして成否を分けるのは粒度です。8/80ルール、報告サイクルとの整合、成果物で完了を判定できること、担当が1人に決まること。この4つを当てはめて分解すれば、更新され続けるWBSになります。まずは直近の案件で、フェーズを4つ書き出すところから始めてみてください。
