フレームワーク活用ガイドひとことで言うと#
プロジェクトの成果物を階層的に分解し、最下層の作業パッケージまで落とし込む構造図。「何を作るか」を漏れなく定義することで、見積もり・スケジュール・進捗管理の土台になる。プロジェクト管理の最も基本的なツールの一つ。
押さえておきたい用語#
- ワークパッケージ（Work Package）
- WBSの最下層の要素で、1人またはチームに割り当て可能な作業単位のこと。見積もり・管理の最小単位にあたる。
- 100%ルール
- WBSの各階層が、上位要素の作業を100%カバーしなければならないという原則を指す。漏れも重複もあってはならない。
- 成果物志向（Deliverable-Oriented）
- WBSは「作業」ではなく**「何が出来上がるか（成果物）」**を基準に分解する考え方である。
- WBS辞書（WBS Dictionary）
- 各ワークパッケージの**詳細情報（担当・期間・コスト・受入基準）**を記述した補足文書。
WBSの全体像#
こんな悩みに効く#
- プロジェクト途中で「この作業、計画に入ってなかった」と発覚する
- 見積もりの精度が低く、いつもスケジュールが遅れる
- チームメンバーが「自分の担当範囲」を正確に把握していない
基本の使い方#
「このプロジェクトで何が出来上がるか」を明確にする。
- 「Webアプリケーション」「研修プログラム」「新店舗」など成果物で定義する
- 「開発する」「構築する」のような動詞ではなく名詞で記述する
- スコープ外の項目も明記しておくと認識のズレを防げる
最終成果物をLevel 1→Level 2→…と段階的に分解していく。
- Level 1: 大きな成果物群（要件定義書、システム、テスト報告書 など）
- Level 2: 構成要素（画面設計、DB設計、バッチ処理 など）
- Level 3以降: さらに細分化し、ワークパッケージに到達するまで分解
- 分解の目安: 1ワークパッケージが 8〜80時間 の作業量に収まる
各レベルの要素を合計すると、上位レベルの100%になっているか確認する。
- 漏れ: 「テスト」の下に「単体テスト」と「結合テスト」はあるが「受入テスト」がない → 追加
- 重複: 「画面設計」と「UI/UXデザイン」が別々に存在 → 統合する
- チーム全員でレビューすると見落としが減る
各ワークパッケージに対して担当・期間・コスト・受入基準を記述する。
- 担当者: 誰がやるか（チーム・個人名）
- 期間: 見積もり工数と期間
- 受入基準: 「完了」と判断する条件
- この情報がスケジュール作成と進捗管理の基盤になる
具体例#
従業員15名のWeb制作会社が、クライアント（製造業・従業員200名）のコーポレートサイトリニューアルを受注。総工数 320時間、期間3か月のプロジェクト。
WBSのLevel 1:
- プロジェクト管理（40h）
- 要件定義・設計（80h）
- コンテンツ制作（60h）
- フロントエンド開発（80h）
- CMS構築（40h）
- テスト・公開（20h）
Level 2の例（2. 要件定義・設計）:
- 2.1 ヒアリング・現状分析（20h）
- 2.2 サイトマップ作成（10h）
- 2.3 ワイヤーフレーム設計（25h）
- 2.4 デザインカンプ作成（25h）
WBSなしで進めていた前回のプロジェクトでは「サーバー移行作業」が計画から抜けており、納期直前に 2週間 の遅延が発生していた。WBS導入後は100%ルールで漏れを事前に検出できるようになり、納期遅延は ゼロ になった。
従業員80名のBtoB SaaS企業。ダッシュボード機能の新規開発（エンジニア5名・デザイナー1名・PM1名）のWBSを作成。
PM がドラフトを作り、チーム全員でレビューした結果、以下の漏れが発覚:
- データ移行: 既存のレポート機能のデータをダッシュボードに移行する作業（約 40時間）
- 権限設計: ダッシュボードの閲覧権限をロール別に設定する作業（約 16時間）
この2つが抜けていたら、開発終盤で発覚し 1スプリント（2週間） の遅延につながるところだった。
WBSのワークパッケージ数は 47個。各パッケージをJiraのチケットに変換し、スプリントプランニングに直結させた。開発は予定通り 8週間 で完了。
人口8万人の市が市庁舎の建替え（総事業費 45億円、工期4年）のWBSを策定。
Level 1は6つの大分類:
- 基本構想・基本計画
- 基本設計
- 実施設計
- 建設工事
- 移転・引越し
- 旧庁舎解体
Level 2以降の分解で市民説明会（3回開催）と議会報告（8回）がワークパッケージとして明示された。過去の自治体建替え事例では、これらの「ソフト面」の作業が計画から抜けて予算超過の原因になったケースが多い。
WBS全体のワークパッケージ数は 218個。各パッケージにコストと期間を紐づけたことで、4年間の事業費の内訳が透明化され、議会への説明資料としても活用された。最終的に事業費は計画比 +2.8% に収まった。
やりがちな失敗パターン#
- 作業（動詞）で分解してしまう — 「設計する」「テストする」ではなく「設計書」「テスト報告書」と成果物で分解する。動詞だと完了の判断が曖昧になる
- 分解が粗すぎる — 「開発」の下が何もないと見積もりも管理もできない。8〜80時間のワークパッケージまで落とす
- 100%ルールを検証しない — 分解して満足すると漏れが残る。チーム全員でレビューし「これ以外に何かあるか？」を問う
- WBSを作って放置する — WBSはプロジェクト計画の基盤。スケジュール・見積もり・進捗管理にリンクさせて初めて価値が出る
まとめ#
WBSはプロジェクトの成果物を階層的に分解し、全作業を漏れなく定義するためのツールだ。100%ルールで漏れと重複を排除し、ワークパッケージまで分解することで、見積もり・スケジュール・進捗管理の精度が格段に上がる。プロジェクトの規模を問わず、計画段階でWBSを作成する習慣がプロジェクト成功の基盤になる。