WBSの作り方｜テンプレート構成と、粒度で失敗しないための基準

プロジェクトが遅れる原因の多くは、能力不足ではなく「やるべき作業が全部見えていなかった」ことにあります。WBSは、作業を漏れなく洗い出して階層に整理するための道具です。この記事では、そのまま複製して使えるWBSテンプレートの構成と作り方、そして多くの現場がつまずく「粒度」の判断基準を整理します。

WBSとは

WBSは Work Breakdown Structure の略で、日本語では「作業分解構成図」と訳されます。プロジェクトの成果物や作業を、大きな塊から小さな単位へ段階的に分解し、階層構造で表したものです。最小単位まで分解されたものを「ワークパッケージ」と呼び、これが担当割り当てと工数見積もりの単位になります。

WBSの根底にあるのは「100%ルール」という考え方です。ある階層の子要素をすべて足すと、その親要素の作業が過不足なく100%になっている状態を指します。逆に言えば、WBSに載っていない作業はプロジェクトの範囲外である、という宣言でもあります。この原則を守ると、スコープの境界が自動的にはっきりします。

ガントチャート・タスクリストとの違い

• WBS：「何をやるか」を漏れなく構造化する。時間軸は持たない。
• ガントチャート：WBSで洗い出した作業を時間軸に並べ、期間と前後関係を可視化する。
• タスクリスト：構造を持たないフラットな一覧。日々の実行管理には向くが、抜け漏れの検証はできない。

順序としては、WBSで作業を洗い出してから、それをガントチャートに落として日程を引きます。いきなりガントチャートを引き始めると、思いついた作業だけが並び、抜けたまま日程が固まってしまいます。

WBSテンプレートの列構成

ExcelやGoogleスプレッドシートで作る場合、次の11列を用意すれば実務で困ることはほぼありません。左から順に並べて、1行目を見出しにしてください。

• WBS番号：1、1.1、1.1.1 のように階層を表す通し番号。会話の中で作業を特定する共通言語になります。
• 作業名：「〜する」と動詞で終える形に統一します。名詞止めにすると、作業なのか成果物なのかが曖昧になります。
• 成果物：その作業が終わったときに手元に残るもの。ここが空欄の行は、完了判定ができない危険な作業です。
• 担当者：個人名で1名を書きます。「制作チーム」のような書き方は、誰も動かない原因になります。
• 工数（人日）：その作業にかかる実働。カレンダー上の期間とは分けて管理します。
• 開始日・終了日：日程。工数と期間が一致しないのが普通なので、両方持たせます。
• 先行タスク：この作業を始める前に終わっている必要がある作業のWBS番号。ここを埋めるとクリティカルパスが見えます。
• ステータス：未着手／進行中／レビュー中／完了／保留の5区分程度に絞ります。
• 進捗率：0／50／100の3段階で十分です。細かくすると「90%完了」が延々と続きます。
• 備考：前提条件、依存する外部要因、リスクなど。

これに加えて、発注側と受注側が混在するプロジェクトなら「担当区分（自社／委託先）」の列を足すと、役割の押し付け合いを防げます。

そのまま使えるWBSテンプレート（Webサイト制作の例）

以下の階層をそのままコピーして、自社の案件に合わせて足し引きしてください。第1階層をフェーズ、第2階層を作業グループ、第3階層をワークパッケージ（実際に担当を割り当てる単位）としています。

1. 企画・要件定義

• 1.1 現状分析（1.1.1 アクセス解析データを整理する／1.1.2 競合サイトを調査する／1.1.3 課題を整理する）
• 1.2 要件整理（1.2.1 目的とKPIを定義する／1.2.2 機能要件を一覧化する／1.2.3 非機能要件を確認する）
• 1.3 承認（1.3.1 要件定義書を作成する／1.3.2 社内決裁を取得する）

2. 設計

• 2.1 情報設計（2.1.1 サイトマップを作成する／2.1.2 ページ一覧を確定する／2.1.3 導線を設計する）
• 2.2 画面設計（2.2.1 ワイヤーフレームを作成する／2.2.2 レビューと修正を行う）
• 2.3 技術設計（2.3.1 CMS構成を設計する／2.3.2 サーバー環境を設計する）

3. 制作

• 3.1 原稿・素材（3.1.1 原稿を執筆する／3.1.2 写真を手配する／3.1.3 図版を作成する）
• 3.2 デザイン（3.2.1 トップページをデザインする／3.2.2 下層テンプレートをデザインする／3.2.3 デザインレビューを行う）
• 3.3 実装（3.3.1 テンプレートを実装する／3.3.2 CMSを構築する／3.3.3 コンテンツを流し込む）

4. テスト・公開

• 4.1 テスト（4.1.1 表示確認を行う／4.1.2 動作テストを行う／4.1.3 修正対応を行う）
• 4.2 公開準備（4.2.1 解析タグを設定する／4.2.2 リダイレクトを設定する／4.2.3 最終承認を得る）
• 4.3 公開・引き継ぎ（4.3.1 本番公開を行う／4.3.2 公開後確認を行う／4.3.3 運用マニュアルを引き渡す）

この骨格は、広告キャンペーンやイベント運営にもほぼそのまま転用できます。フェーズ名を「企画／設計／制作／実施・検証」に読み替えてください。

WBSの作り方5ステップ

ステップ1：最終成果物を定義する

何が完成すればこのプロジェクトは終わりなのかを一文で書きます。ここが曖昧なまま分解を始めると、途中で「これも必要では」という追加が止まらなくなります。

ステップ2：フェーズに分ける

第1階層は、時系列の大きな区切り（企画・設計・制作・テスト・公開）か、成果物の種類で分けます。どちらでも構いませんが、途中で軸を混ぜないことが重要です。軸が混ざると、どの枝に入れるべきか判断できない作業が出てきます。

ステップ3：ワークパッケージまで分解する

各フェーズを、担当者1人に割り当てられて工数を見積もれる単位まで分解します。分解の途中では100%ルールを意識し、「この階層の子を全部足したら親になるか」を都度確認します。ここで漏れが見つかるのが、WBSを作る最大の価値です。

ステップ4：担当と工数を割り当てる

最下層の行にだけ担当と工数を入れ、上位階層は合計値を表示させます。上位に直接工数を入れると二重計上になるため、集計はSUM関数に任せます。レビューや承認待ちの時間も、忘れずに行として立てておきます。

ステップ5：依存関係を引いて日程に落とす

先行タスク列を埋め、どの作業が遅れると全体が遅れるか（クリティカルパス）を確認します。そのうえで開始日・終了日を入れ、ガントチャートに展開します。稼働率100%を前提にすると必ず破綻するため、7〜8割で見ておくのが現実的です。

粒度で失敗しないための4つの基準

WBSで最も多い失敗は、分解が粗すぎるか細かすぎるかのどちらかです。粗すぎれば進捗が分からず、細かすぎれば更新が追いつかず放置されます。次の4つの基準を当てはめれば、ほとんどの場合は適切な粒度に収まります。

基準1：8/80ルール

1つのワークパッケージを、8時間以上80時間以内に収める考え方です。おおよそ1日から2週間の作業量にあたります。8時間を下回るなら細かすぎ、80時間を超えるならもう一段分解します。プロジェクト管理の現場で最も広く使われている目安です。

基準2：報告サイクルに合わせる

週次で進捗会議を開くなら、1つの作業は1〜5日程度に収めます。2週間かかる作業は、週次会議で2回続けて「進行中」としか報告できず、遅れの兆候を捉えられません。報告の間隔より作業が長い場合は、必ず中間成果物を挟んで分割します。

基準3：完了が客観的に判定できるか

その作業に成果物を書けるかどうかが試金石です。「デザインを検討する」は完了を判定できませんが、「デザイン案を3案提出する」なら判定できます。成果物欄が埋まらない行は、粒度ではなく定義の問題を抱えています。

基準4：担当が1人に決まるか

複数人にまたがる作業は、まだ分解が足りていません。1行に1人が対応するまで割ると、誰かが止まったときにその場所が即座に特定できます。逆に、同じ人が連続して行う細かい作業を別々の行に分けているなら、統合しても情報は失われません。

なお、粒度は全体で均一である必要はありません。直近のフェーズは細かく、先のフェーズは粗く置いておき、着手が近づいたら詳細化する進め方（ローリングウェーブ）が実務的です。半年先の作業を今から1日単位で刻んでも、その通りにはなりません。

WBSでよくある失敗

• レビュー・承認待ちを行にしていない：実作業だけを並べると、実際には最も日程を食う待ち時間が消えます。確認や決裁も作業として立てます。
• 自社側の作業が載っていない：原稿支給や素材提供の遅れは、外注案件が遅れる代表的な原因です。発注側のタスクも同じWBSに載せます。
• 作った後に更新されない：更新の担当者と頻度（週1回、定例前など）を決めておかないと、初週で止まります。
• バッファを各タスクに埋め込む：個別に余裕を持たせると、その余裕は必ず使い切られます。フェーズ末にまとめて置くほうが機能します。
• 1人で作ってしまう：実作業者が入らないWBSは、必ず工数が甘くなります。分解の段階から担当者を巻き込みます。

Excelとツール、どちらで管理するか

作業の洗い出しと構造化はExcelやスプレッドシートが最も速く、自由度も高いため、最初のWBS作成には向いています。一方、日々の進捗更新まで表計算で回そうとすると、更新漏れとファイルの分裂が起きます。

同時編集で誰かの入力が消える、最新版がどれか分からなくなる、担当者が自分の担当行を見つけられない。こうした症状が出始めたら、プロジェクト管理ツールへの移行を検討するタイミングです。判断の目安は、関係者が5名を超えるか、案件が3つ以上並行するかどうかです。

WBSに関するよくある質問

階層は何段まで作るべきですか

3〜4階層が実務上の目安です。5階層を超えると、番号を追うだけで疲れて誰も見なくなります。深くしたくなったら、そのフェーズを別プロジェクトとして切り出せないかを先に検討してください。

小規模な案件でもWBSは必要ですか

1〜2週間で終わる案件なら、2階層20行程度の簡易版で十分です。重要なのは形式ではなく、着手前に作業を洗い出す工程を挟むこと自体です。その30分が、後半の徹夜を防ぎます。

途中で作業が増えたらどうしますか

行を追加し、増えた工数と日程への影響をその場で可視化します。WBSの価値は、追加作業が全体に与える影響を数字で示せる点にあります。「これを追加すると公開が3日後ろにずれます」と言えるかどうかで、要望の扱われ方は変わります。

進捗率は何で測るべきですか

作業の体感ではなく、完了したワークパッケージの数か工数で測ります。担当者の申告する進捗率は主観が入りやすいため、粒度を細かくして「完了したかどうか」の二択で積み上げるほうが、実態に近い数字になります。

まとめ

WBSは、プロジェクトの作業を漏れなく分解し、担当と工数を割り当てるための構造です。本記事の列構成とサンプル階層をコピーすれば、テンプレートとしてすぐに使い始められます。

そして成否を分けるのは粒度です。8/80ルール、報告サイクルとの整合、成果物で完了を判定できること、担当が1人に決まること。この4つを当てはめて分解すれば、更新され続けるWBSになります。まずは直近の案件で、フェーズを4つ書き出すところから始めてみてください。