WBS の作り方 完全ガイド｜階層分解の 5 ステップで作業の抜け漏れをなくす
WBS（作業分解構成図）の作り方を、スコープ確認 → 成果物分解 → ワークパッケージ化 → 100% ルール検証 → WBS 辞書のベースライン化という 5 ステップで解説。成果物ベース分解の原則、ワークパッケージの粒度（8〜80 時間・1〜2 週間）、よくある失敗まで、初めて WBS を作る人でも迷わない手順としてまとめます。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
「WBS を作れと言われたが、どこから手を付ければいいのか分からない」——本記事はその悩みを 1 本で解消します。結論から言えば、WBS は『スコープを成果物で分解し、管理できる単位（ワークパッケージ）まで落とし込み、100% ルールで網羅性を検証する』という 5 ステップで作れば、初めてでも抜け漏れの少ない構造になります。なぜなら、見積もり・スケジュール・進捗・課題管理のすべてが WBS を土台に積み上がるため、ここで作業を漏れなく構造化できれば計画全体の精度が一段上がるからです。
本記事では、その 5 ステップを順に手を動かす形で解説します。WBS を「試験のプロセス」として整理したい方は「PMP スコープ管理 完全対策」、現場での粒度設計や MECE の実務は「WBS の作り方｜現場で破綻しない『分解の粒度』と MECE の実務」も併読してください。
WBS とは｜成果物を「管理できる単位」まで分解した設計図
WBS（Work Breakdown Structure＝作業分解構成図）とは、プロジェクトの成果物と作業を 階層的に分解・構造化 したものです。プロジェクト全体を頂点に、主要成果物・サブ成果物・作業へと段階的に細分化し、最下層の管理単位を ワークパッケージ と呼びます。
WBS が機能していないプロジェクトは、ほぼ確実に後半で炎上します。理由は単純で、見積もりも進捗管理もリスク管理も、すべて「作業の一覧」を前提にしているからです。逆に言えば、WBS さえ正しく組めれば、その後の計画が一気に立てやすくなります。
WBS 作成の 5 ステップ｜全体像
まず全体像を押さえましょう。本記事では、WBS 作成を次の 5 ステップに分けて解説します。
| ステップ | やること | アウトプット |
|---|---|---|
| 1 | スコープを確認する | 何を作る／作らないかの確定 |
| 2 | 主要成果物・フェーズに分解する | 第 2 階層（大きな塊） |
| 3 | ワークパッケージまで階層分解する | 管理可能な最下層 |
| 4 | 100% ルールで網羅性を検証する | 漏れ・重複ゼロの構造 |
| 5 | WBS 辞書を整備しベースライン化する | スコープベースライン |
💡 ステップ 1〜3 で「分解」し、ステップ 4 で「検証」し、ステップ 5 で「確定」する——この大きな流れを意識すると迷いません。
ステップ 1：スコープを確認する｜土台がブレると WBS もブレる
WBS は「やると決めた範囲（スコープ）」を分解する作業です。したがって出発点は、プロジェクトスコープ記述書（やること・やらないこと・成果物・受け入れ基準・除外事項を書いた文書）の確認です。ここが曖昧なまま分解を始めると、後で「この作業はスコープ内か？」という判断ができなくなります。
ステップ 2：主要成果物・フェーズに分解する｜第 2 階層を作る
次に、最終成果物を 大きな塊（主要成果物・主要フェーズ） に分解します。これが WBS の第 2 階層です。システム開発なら「要件定義」「基本設計」「詳細設計」「開発」「テスト」「移行・導入」といった単位が典型です。
この段階ではまだ細かくしすぎないのがコツです。まずは 5〜9 個程度の大きな塊で全体を覆い、各塊が「成果物（名詞）」になっているかを確認します。
| 良い第 2 階層（成果物＝名詞） | 避けたい第 2 階層（作業＝動詞） |
|---|---|
| 要件定義書 | 要件をヒアリングする |
| 基本設計書 | 設計する |
| テスト計画書・テスト結果報告書 | テストする |
ステップ 3：ワークパッケージまで階層分解する｜「8〜80 時間」を目安に
第 2 階層の各成果物を、さらに 管理可能なワークパッケージ まで分解します。ワークパッケージとは「担当者を割り当て、工数を見積もり、進捗を測れる」最小単位のことです。
ここで最も多い質問が「どこまで細かくするか」です。一般的な目安は次の 2 つです。
粒度をどう揃えるかの実務的な勘所は「現場で破綻しない『分解の粒度』と MECE の実務」で深掘りしています。
ステップ 4：100% ルールで網羅性を検証する｜漏れと重複をゼロにする
分解できたら、100% ルール で検証します。100% ルールとは「上位要素は、その配下の下位要素の合計と過不足なく一致する」という原則です。言い換えれば、子要素をすべて足すと親要素の 100% になり、漏れも重複もない（MECE である）状態を指します。
| 100% ルールが守れているか | チェック観点 |
|---|---|
| 漏れがないか | 子要素を足して親の作業を全部カバーしているか |
| 重複がないか | 同じ作業が複数の枝に登場していないか |
| スコープ外が混入していないか | WBS に無い作業＝やらない作業、と言い切れるか |
ステップ 5：WBS 辞書を整備しベースライン化する｜計画の基準線にする
最後に、各ワークパッケージの詳細を WBS 辞書 にまとめます。WBS 辞書には、識別コード・作業内容・担当組織・必要資源・コスト見積もり・受け入れ基準・前提条件などを記載します。図としての WBS だけでは情報が足りないため、辞書とセットで初めて実務に使えます。
そして「プロジェクトスコープ記述書 ＋ WBS ＋ WBS 辞書」の 3 点セットが スコープベースライン（計画の基準線）になります。以降、変更が承認されたらこのベースラインを正式に更新する、という運用に乗せれば WBS は生きた管理ツールになります。
| スコープベースラインの構成 | 役割 |
|---|---|
| プロジェクトスコープ記述書 | やること／やらないことの定義 |
| WBS | 作業を分解した構造 |
| WBS 辞書 | 各ワークパッケージの詳細情報 |
よくある失敗 5 選｜作り直しになる前に
| よくある失敗 | なぜダメか | 正しい姿 |
|---|---|---|
| 作業（動詞）で分解する | 粒度がバラつき漏れに気づけない | 成果物（名詞）で分解する |
| 組織図をそのまま WBS にする | 部署の都合で作業が抜ける | 成果物起点で組み直す |
| 粒度を細かくしすぎる | 管理コストが爆発する | 8〜80 時間／1〜2 週間に揃える |
| 一度作って更新しない | 計画と実態が乖離する | 変更承認のたびにベースライン更新 |
| WBS 辞書を作らない | 図だけでは作業内容が伝わらない | 辞書とセットで運用する |
WBS を正しく作るメリット
- 作業の抜け漏れ・重複を構造的に防げる（100% ルール）
- ワークパッケージ単位で見積もり・進捗管理ができる
- スコープベースラインとして変更管理の基準になる
- メンバー間で『やること』の認識がそろう
作らない・雑に作るリスク
- 見積もりが感覚値になり、後半で工数が破綻する
- 進捗が『やっています』しか分からず手遅れになる
- スコープクリープで予算・納期が静かに崩れる
- 担当の押し付け合いと抜け漏れが同時に起きる
よくある質問（FAQ）
Q. WBS とガントチャートは何が違いますか？ WBS は「作業を漏れなく分解した構造（What）」、ガントチャートは「その作業を時間軸に並べたスケジュール（When）」です。WBS で洗い出したワークパッケージをガントチャートに展開する、という順序が基本です。
Q. ワークパッケージはどこまで細かくすべきですか？ 担当者を一人に決められて、かつ 1〜2 週間（工数 8〜80 時間程度）で完了を確認できる粒度が目安です。プロジェクトの規模や管理サイクルに応じて調整します。
Q. 100% ルールは厳密に守らないとダメですか？ WBS の信頼性の根幹なので、原則は守ります。子要素の合計が親要素に一致しない（＝漏れか重複がある）状態は、そのまま見積もり・進捗の誤差につながります。
🛠 現場ノート：教科書に載らない PM 実務の勘所
WBS の品質は「作った瞬間」ではなく「メンバーが進捗を報告できるか」で決まります。
現場での判断の分かれ目
- 粒度は「進捗会議の頻度」から逆算する：教科書の 8〜80 時間はあくまで目安です。大規模システム刷新の PMO を務めた経験では、週次で進捗を確認する体制なら「1 週間で完了確認できる粒度」に揃えるのが運用上いちばん破綻しません。粒度と会議サイクルが合っていないと、毎回「進行中 50%」の報告が並びます。
- 最初から完璧な分解を狙わない：直近 1〜2 ヶ月は詳細に、先のフェーズは粗く作る「ローリングウェーブ」で始めて、フェーズの切れ目で詳細化する方が、大規模案件では手戻りが少なくなります。
- WBS 承認は「作業する側」に引かせる：PM が一人で分解した WBS は必ず漏れます。ワークパッケージのレベルは担当チームに書かせ、PM は 100% ルールで検証する役割分担が実務的です。
やりがちな失敗
- 「進行中 80%」が数週間続く：完了基準が曖昧なワークパッケージの典型症状です。対処は WBS 辞書に「何が出てきたら完了か（成果物と確認者）」を 1 行でも書いておくこと。
- 管理系の作業を WBS から漏らす：進捗会議・課題管理・レビュー対応などの PM 作業を積まずに見積もると、後から工数が確実に不足します。「プロジェクト管理」を第 2 階層に必ず立てるのが対処法です。
- 変更が入っても WBS を直さない：スコープ変更が口頭合意のまま進み、WBS と実態が乖離して進捗率が信用できなくなるパターン。変更管理と WBS 更新をワンセットの手続きにしておくことが唯一の対処です。
まとめ｜WBS は「成果物で分解し、100% で検証し、辞書で確定する」
WBS の作り方は、①スコープを確認し → ②主要成果物に分解し → ③ワークパッケージまで落とし込み → ④100% ルールで網羅性を検証し → ⑤WBS 辞書とセットでベースライン化する という 5 ステップに尽きます。ポイントは「作業ではなく成果物で分解する」「粒度は 8〜80 時間に揃える」「100% ルールで漏れと重複をゼロにする」の 3 つです。この型を手元に置けば、次のステップであるスケジュール作成や見積もりが一気に進めやすくなります。
注釈：
- PMP®、PMI®、PMBOK® は Project Management Institute, Inc. の登録商標です
- 本記事の用語・粒度の目安は、PMBOK® の考え方と一般的な実務慣行に基づく執筆時点（2026 年 6 月）の整理です。最適な粒度はプロジェクトの規模・性質により異なります
出典・参考情報
関連記事
- 工数見積もり手法 完全比較｜トップダウン・ボトムアップ・三点見積を使い分ける
工数見積もりが毎回外れて炎上する——その原因は「1つの手法だけで見積もっている」ことにあります。トップダウン（類推）・ボトムアップ・三点見積（PERT）・パラメトリックの4手法を、計算式・長所短所・プロジェクトのフェーズ別の使い分けまで、Webシステム開発の記入例つきで解説。過去実績を活かして精度を上げる組み合わせ運用まで、今日から使える形でまとめました。
- プロジェクトのスコープ定義書（SOW）の書き方｜業務範囲・成果物・前提・制約・除外事項を固める8項目テンプレート
「これも含まれると思っていた」という認識ズレは、スコープ定義書（SOW＝作業範囲記述書）を最初に固めることで防げます。SOWに書くべき8項目を、In-Scope／Out-of-Scope・前提条件と制約条件の書き分け・受入基準の決め方まで、Webシステム導入プロジェクトの記入サンプルつきで実務目線に解説。今日から自分で書けるテンプレートとして使えます。
- PMが知っておくべき意思決定フレームワーク10選｜RAPID・OODA・DECIDEを使い分ける
「会議で決まらない」「誰が決めるのか曖昧」を解決する意思決定フレームワークを10個厳選。RAPID・DACI・RACIで“誰が決めるか”を、意思決定マトリクス・アイゼンハワー・ペイオフで“どう選ぶか”を、OODA・PDCA・DECIDE・Cynefinで“どう回すか”を整理し、プロジェクトの現場で今日から使い分けられるよう、選び方の早見表つきで解説します。
- プロジェクトステータスレポートの書き方｜A4一枚に収める型と5つの構成要素
「作業を並べただけの進捗報告」から抜け出すためのプロジェクトステータスレポートの書き方を解説。全体ステータス（信号）・サマリー・進捗（定量＋定性）・課題とリスク・次週計画という5つの構成要素をA4一枚に収める型、緑黄赤サインの付け方、定量と定性のバランス、Webシステム導入PJの記入例、よくある失敗5選まで、初めて週次レポートを任されたPMが今日から使える形でまとめました。