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 の信頼性の根幹なので、原則は守ります。子要素の合計が親要素に一致しない（＝漏れか重複がある）状態は、そのまま見積もり・進捗の誤差につながります。
まとめ｜WBS は「成果物で分解し、100% で検証し、辞書で確定する」
WBS の作り方は、①スコープを確認し → ②主要成果物に分解し → ③ワークパッケージまで落とし込み → ④100% ルールで網羅性を検証し → ⑤WBS 辞書とセットでベースライン化する という 5 ステップに尽きます。ポイントは「作業ではなく成果物で分解する」「粒度は 8〜80 時間に揃える」「100% ルールで漏れと重複をゼロにする」の 3 つです。この型を手元に置けば、次のステップであるスケジュール作成や見積もりが一気に進めやすくなります。
注釈：
- PMP®、PMI®、PMBOK® は Project Management Institute, Inc. の登録商標です
- 本記事の用語・粒度の目安は、PMBOK® の考え方と一般的な実務慣行に基づく執筆時点（2026 年 6 月）の整理です。最適な粒度はプロジェクトの規模・性質により異なります
出典・参考情報
関連記事
- ステークホルダーマネジメント完全ガイド｜権力・関心度マトリクスで関係者を動かす4ステップ
プロジェクトの成否を分けるステークホルダーマネジメントを「特定 → 分析 → 関与 → 監視」の4ステップで実務目線で解説。権力・関心度マトリクス（Power/Interestグリッド）の4象限別コミュニケーション戦略、ステークホルダー登録簿の作り方、関与度評価マトリクス（不認識〜指導の5段階）で現在と望ましい関与度のギャップを埋める方法まで、初めて関係者調整を任された PM が今日から使える手順書としてまとめました。
- リスクマネジメントの手順｜識別・分析・対応・監視の4ステップで進める
プロジェクトのリスクマネジメントを「識別 → 分析 → 対応 → 監視」の4ステップで実務目線で解説。リスク登録簿（リスクレジスター）の作り方、確率影響マトリクスを使った定性・定量分析、脅威への4戦略（回避・転嫁・軽減・受容）と好機への4戦略、監視サイクルの回し方まで、初めてリスク管理を任された PM が今日から使える手順書としてまとめました。
- EVM（アーンドバリューマネジメント）の計算｜SV・CV・SPI・CPI を例題でマスター
アーンドバリューマネジメント（EVM）の計算方法を、1つの例題を最後まで追いながら解説。PV・EV・AC の3値から SV・CV（差異）と SPI・CPI（効率指数）を求め、さらに EAC・ETC・VAC・TCPI で完成時のコストと工期を予測します。計算式の丸暗記ではなく「差なら引き算・効率なら割り算」という原理で、PMP® と情報処理 PM 試験の計算問題を確実に取れる形にまとめました。
- クリティカルパスの計算方法｜PERT 図と最早・最遅で最短工期を求める
クリティカルパスの計算方法を、具体的なネットワーク図（PERT 図・アローダイアグラム）を使って手順で解説。フォワードパスで最早（ES／EF）、バックワードパスで最遅（LS／LF）を求め、トータルフロートがゼロの経路＝クリティカルパスを特定します。トータルフロートとフリーフロートの違い、計算の落とし穴まで、例題で手を動かして理解できる形でまとめました。