WBSとは？プロジェクトを成功に導く作業分解の技術
WBS（Work Breakdown Structure）はプロジェクトの全作業を階層的に分解する手法です。定義、構成要素、作成手順、活用場面、注意点までを体系的に解説します。
WBSとは
WBS（Work Breakdown Structure）は、プロジェクトの成果物や作業を階層的に分解し、ツリー構造で可視化する手法です。日本語では「作業分解構成図」と訳されます。
もともとは米国国防総省が1960年代にミサイル開発プロジェクトで導入した手法で、現在ではPMBOK（Project Management Body of Knowledge）においてスコープ管理の中核プロセスとして位置づけられています。プロジェクトの「何をやるか」を定義する起点であり、スケジュール・コスト・リソース計画のすべてがWBSを基盤として組み立てられます。
構成要素
WBSは上位から下位に向かって段階的に分解される階層構造を持ちます。
| 階層 | 名称 | 説明 |
|---|---|---|
| レベル0 | プロジェクト | プロジェクト全体を表すルートノード |
| レベル1 | フェーズ / 大項目 | プロジェクトの主要な区分（企画、設計、テストなど） |
| レベル2 | タスク | フェーズを構成する作業単位 |
| レベル3 | ワークパッケージ | 見積り・管理可能な最小の成果物単位 |
最下層の「ワークパッケージ（WP）」が管理の最小単位です。WPは担当者が明確で、工数と期間を見積もれる粒度まで分解します。WPよりさらに細かいアクティビティ（個別作業）への分解は、スケジュール作成の段階で行います。
WBSとガントチャートの違い
WBSは「何をやるか」を構造的に分解するもので、時間軸は持ちません。一方、ガントチャートはWBSで分解した作業を時間軸上に配置し、スケジュールとして可視化するものです。
| 観点 | WBS | ガントチャート |
|---|---|---|
| 目的 | 作業範囲の定義・分解 | スケジュールの可視化 |
| 構造 | ツリー（階層構造） | 横棒グラフ（時間軸） |
| 表現するもの | 成果物と作業の関係 | 作業の順序・期間・依存関係 |
| 作成順序 | 先に作成 | WBSをもとに作成 |
実務ではExcelやMicrosoft Projectで「WBS番号付きのガントチャート」として一体化されることが多いため混同されがちですが、本来は別のツールです。WBSで分解 → ガントチャートでスケジュール化、という流れで使います。
100%ルール
WBSの最も重要な原則は「100%ルール」です。上位要素の作業範囲は、下位要素の合計と完全に一致しなければなりません。つまり、各階層で漏れもダブりもない状態（MECE）が求められます。
実践的な使い方
ステップ1: 成果物を定義する
プロジェクトの最終成果物を明確にします。「Webサイトのリニューアル」「新サービスの立ち上げ」など、プロジェクトが完了した時点で何が出来上がっているかを言語化します。
ステップ2: 大項目に分解する
成果物をフェーズや主要カテゴリに分解します。分解の軸はプロジェクトの性質に応じて選びます。
- 時系列型: 企画 → 設計 → 開発 → テスト → リリース
- 成果物型: フロントエンド / バックエンド / インフラ / ドキュメント
- 機能型: ユーザー管理 / 決済機能 / レポート機能
ステップ3: ワークパッケージまで分解する
各大項目をさらに細分化し、見積り可能な粒度まで落とし込みます。分解の目安は以下です。
- 1つのWPが1〜2週間程度の作業量に収まること
- 担当者を1名（またはチーム）割り当てられること
- 完了条件が明確に定義できること
ステップ4: WBS辞書を作成する
各WPに対して、作業内容・担当者・成果物・完了条件を記述した「WBS辞書」を作成します。WBSのツリー図だけでは伝わらない詳細情報を補完する役割を持ちます。
| 項目 | 内容 |
|---|---|
| WP番号 | 1.2.1 |
| WP名 | UI設計 |
| 担当者 | デザインチーム |
| 成果物 | ワイヤーフレーム、デザインカンプ |
| 完了条件 | クライアントの承認を得ること |
| 想定工数 | 40時間 |
活用場面
- スコープ管理: プロジェクトの作業範囲を明確にし、スコープクリープ（範囲の肥大化）を防ぎます
- 見積りの精度向上: WPレベルまで分解することで、ボトムアップの精緻な見積りが可能になります
- 進捗管理の基盤: WPごとの完了状況を追跡することで、プロジェクト全体の進捗を定量的に把握できます
- コミュニケーションツール: チーム内やクライアントとの間で「何をやるのか」の共通認識を形成します
- リスク特定: 分解の過程で、曖昧な領域や技術的リスクが浮かび上がります
注意点
分解しすぎない
WPを細かくしすぎると管理コストが膨大になります。「これ以上分解しても管理上の価値がない」と判断できるラインで止めることが重要です。目安として、1つのWPが数時間の作業になっていたら細かすぎると考えてよいでしょう。
「どうやるか」ではなく「何を作るか」で分解する
WBSはあくまで成果物ベースの構造です。「会議を行う」「レビューする」といったプロセスや行為ではなく、「要件定義書」「設計書」「テスト結果報告書」のように成果物を軸に分解します。
一人で作らない
WBSはプロジェクトの全体像を定義するものです。PMが一人で作成すると、専門領域の作業が漏れるリスクがあります。実務の知見を持つメンバーを巻き込み、チームで作成することで100%ルールに近づけます。
最初から完璧を目指さない
プロジェクト初期は不確実性が高く、詳細な分解が難しい領域もあります。その場合は「ローリングウェーブ計画法」を採用し、直近のフェーズは詳細に、先のフェーズは大枠で定義しておき、段階的に詳細化する方法が有効です。
まとめ
WBSはプロジェクトマネジメントの土台となるツールです。スケジュール、コスト、品質、リソースのすべての計画がWBSを起点に組み立てられます。100%ルールとMECEの原則を意識しながら、チームで段階的に作り上げていくことが成功の鍵です。
参考資料
- プロジェクトマネジメントとは何か？未経験者でもわかる基礎からの進め方 - GLOBIS知見録（WBSを含むプロジェクト管理の基礎を体系的に解説）
- プロジェクト計画と予算管理の基礎スキル - GLOBIS知見録（WBS作成を起点とした計画策定と予算管理の実務スキル）
- プロジェクトマネジメント入門 概要編 - GLOBIS知見録（PMBOKに基づくプロジェクトマネジメントの全体像を解説）
- The Four Phases of Project Management - Harvard Business Review（プロジェクト管理の4フェーズにおける計画・実行の基本）