WBS の作り方｜現場で破綻しない『分解の粒度』と MECE の実務

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

WBS（Work Breakdown Structure）が機能していないプロジェクトは、ほぼ確実に後半で炎上します。 理由は単純で、見積もり・スケジュール・進捗・課題のすべてが WBS を土台に積み上がるから。逆に言えば、WBS の粒度と網羅性さえ正しく設計できれば、計画の精度は一段上がります。本記事は、現場で破綻しない WBS の作り方を「型」として整理します。スコープの考え方はスコープ管理も併読を。

この記事の要点

• 🧩 WBS は作業（動詞）でなく成果物（名詞）で分解するのが原則
• ✅ 100% ルール：子要素の合計＝親要素。漏れも重複もゼロ（MECE）
• 📏 最下層（ワークパッケージ）は1〜2 週間・80 時間以内を目安に
• 🎯 コントロールアカウントで進捗・コストの管理単位を決める
• ⚠️ 「組織図ベース」「タスクの羅列」は WBS ではない

1. WBS は『成果物』で分解する

ありがちな失敗が、WBS をタスク（作業）の箇条書きにしてしまうこと。これだと粒度がバラバラになり、抜け漏れに気づけません。

正：要件定義書 → 基本設計書 → 詳細設計書 …（成果物＝名詞） 誤：ヒアリングする → 設計する → レビューする …（作業＝動詞）

成果物ベースで分解すると、「この成果物は誰がいつ作るか」「完成の定義は何か」が一意に決まり、見積もりと検収条件が明確になります。

2. 100% ルール（MECE の担保）

WBS の品質は 100% ルール で測れます。

レビュー時は「この階層の子を全部足したら、親の仕事を本当に全部カバーしているか？」と問い続けます。多くの炎上は、この問いを省いたときのスコープ漏れから始まります。

3. 粒度の目安（ワークパッケージ）

分解しすぎても管理コストが増え、粗すぎても進捗が見えません。実務の目安は次のとおり。

観点	目安
期間	1〜2 週間で完了する大きさ
工数	概ね 80 時間以内（8/80 ルール）
担当	1 人または 1 チームに割り当てられる
完了判定	「できた/できてない」が明確に言える

報告サイクル（週次なら1〜2週間粒度）に粒度を合わせると、進捗が素直に上がってきます。

4. コントロールアカウントで管理単位を決める

ワークパッケージを束ねたコントロールアカウントが、進捗・コストの管理点になります。ここを起点にEVM（出来高管理）を回すと、進捗と予算を1枚で監視できます。WBS は EVM・スケジュール・課題管理すべての土台になる、という意識が重要です。

5. よくある失敗と回避

まとめ

• WBS は成果物（名詞）で分解し、各階層で100% ルールを守る
• 最下層は1〜2 週間・80 時間を目安にそろえる
• コントロールアカウントで進捗・コストの管理単位を決める
• 「組織図」「タスク羅列」「その他の箱」は破綻の三大サイン

WBS は計画書の一部ではなく、プロジェクト管理全体の背骨です。ここを丁寧に作ることが、後半の安定に直結します。