作業分解構造の作成

見積もり、割り当て、追跡が可能なワークパッケージの階層セットにプロジェクトスコープを分解します。WBSは、複雑な成果物を管理可能なコンポーネントに分解することで、工数見積もり、リソース計画、スケジュール作成の基盤を提供します。

使用タイミング

• プロジェクト憲章が承認され、スコープが定義された後
• 定義された成果物を持つクラシック/ウォーターフォールプロジェクトの計画時
• 大規模な取り組みを管理可能なワークパッケージに分割する場合
• 工数見積もりとリソース計画の基盤を確立する場合
• 必要なすべての作業の共通理解を作成する場合

入力

• 必須: 承認されたプロジェクト憲章（特にスコープと成果物のセクション）
• 必須: プロジェクト手法（クラシック/ウォーターフォール、または計画のためのWBSを使用するハイブリッド）
• 任意: 類似プロジェクトからの過去の工数データ
• 任意: チームの構成と利用可能なスキル
• 任意: 組織のWBSテンプレートまたは標準

手順

ステップ1: 憲章から成果物を抽出する

プロジェクト憲章を読みます。すべての成果物と受け入れ基準をリストアップします。それらを3〜7個のトップレベルカテゴリにグループ化します（これらがWBSレベル1の要素になります）。

期待結果： 憲章の成果物に対応するレベル1のWBS要素のリスト。

失敗時： 憲章が曖昧な場合、

draft-project-charter

に戻ってスコープを改善します。

ステップ2: ワークパッケージに分解する

各レベル1要素について、サブ要素（レベル2、レベル3）に分解します。100%ルールを適用します：子要素は親のスコープの100%を表す必要があります。ワークパッケージが以下の条件を満たした時点で分解を停止します:

• 見積もり可能（工数を人日で割り当て可能）
• 割り当て可能（1人または1チームが担当）
• 測定可能（完了/未完了の明確な基準がある）

WBSアウトラインを作成します:

# Work Breakdown Structure: [Project Name]
## Document ID: WBS-[PROJECT]-[YYYY]-[NNN]

### WBS Hierarchy

1. [Level 1: Deliverable Category A]
   1.1 [Level 2: Sub-deliverable]
      1.1.1 [Level 3: Work Package]
      1.1.2 [Level 3: Work Package]
   1.2 [Level 2: Sub-deliverable]
2. [Level 1: Deliverable Category B]
   2.1 [Level 2: Sub-deliverable]
3. [Level 1: Project Management]
   3.1 Planning
   3.2 Monitoring & Control
   3.3 Closure

WBSコード（1.1.1形式）を適用します。最大3〜5レベルの深さを確保します。常に「プロジェクト管理」ブランチを含めます。

期待結果： ユニークなWBSコードを持つ15〜50件のワークパッケージを含む完全なWBS。

失敗時： 分解が5レベルを超える場合、スコープが大きすぎます — サブプロジェクトへの分割を検討します。

ステップ3: WBS辞書を作成する

各ワークパッケージ（リーフノード）について、辞書エントリを作成します:

# WBS Dictionary: [Project Name]
## Document ID: WBS-DICT-[PROJECT]-[YYYY]-[NNN]

### WBS 1.1.1: [Work Package Name]
- **Description**: What this work package produces
- **Acceptance Criteria**: How to verify it's done
- **Responsible**: Person or role
- **Estimated Effort**: [T-shirt size or person-days]
- **Dependencies**: WBS codes this depends on
- **Assumptions**: Key assumptions for this work package

### WBS 1.1.2: [Work Package Name]
...

期待結果： すべてのリーフノードのワークパッケージに辞書エントリがある。

失敗時： 辞書エントリが欠落している場合は分解が不完全です — ステップ2に戻ります。

ステップ4: 工数を見積もる

各ワークパッケージについて、1つの見積もり方法を適用します:

• Tシャツサイジング（XS/S/M/L/XL）：初期段階の計画向け
• 人日：詳細計画向け
• 三点見積もり（楽観/最頻値/悲観）：不確実性が高い作業向け

サマリーテーブルを作成します:

## Effort Summary
| WBS Code | Work Package | Estimate | Method | Confidence |
|----------|-------------|----------|--------|------------|
| 1.1.1 | [Name] | 5 pd | person-days | High |
| 1.1.2 | [Name] | M | t-shirt | Medium |

総工数 = すべてのワークパッケージの合計。

期待結果： すべてのワークパッケージに信頼度が記述された工数見積もりがある。

失敗時： パッケージの30%超で信頼度が低い場合、SMEとの改善セッションをスケジュールします。

ステップ5: 依存関係とクリティカルパス候補を特定する

ワークパッケージ間の依存関係をマッピングします:

## Dependencies
| WBS Code | Depends On | Type | Notes |
|----------|-----------|------|-------|
| 1.2.1 | 1.1.1 | Finish-to-Start | Output of 1.1.1 is input to 1.2.1 |
| 2.1.1 | 1.1.2 | Finish-to-Start | |

依存するワークパッケージの最長チェーンを特定します — これがクリティカルパス候補です。

期待結果： 少なくとも終了-開始の関係が特定された依存関係テーブル。

失敗時： 依存関係がサイクルを形成する場合、分解にエラーがあります — ステップ2に戻ります。

ステップ6: レビューとベースライン化

WBSと辞書を最終文書にまとめます。すべてのレベルで100%ルールを検証します。ステークホルダーの承認を得ます。

期待結果： WBS.mdとWBS-DICTIONARY.mdが作成され、レビューされている。

失敗時： ステークホルダーが欠落したスコープを特定した場合、ワークパッケージを追加して再見積もりします。

バリデーション

• WBSファイルがドキュメントIDとWBSコードとともに作成されている
• 100%ルールが満たされている：すべてのレベルで子要素が親スコープを完全に表している
• すべてのリーフノードにWBS辞書エントリがある
• すべてのワークパッケージに工数見積もりがある
• 循環参照なしに依存関係が特定されている
• プロジェクト管理ブランチが含まれている
• クリティカルパス候補が特定されている
• WBSの深さが5レベルを超えていない

よくある落とし穴

• 成果物と活動の混同: WBS要素は動詞（活動）ではなく、名詞（成果物）であるべきです。「認証を実装する」ではなく「ユーザー認証モジュール」。
• 100%ルールの違反: 子要素が親スコープの100%にならない場合、作業が漏れます。
• 浅すぎるまたは深すぎる: 2レベルでは計画に対して曖昧すぎ、6レベル以上はマイクロマネジメントです。3〜5レベルを目指します。
• プロジェクト管理ブランチのスキップ: PM作業（計画、会議、報告）は工数を消費する実際の作業です。
• 分解前の見積もり: カテゴリではなくワークパッケージを見積もります。レベル1の見積もりは信頼性が低い。
• 辞書なし: 辞書なしのWBSはラベルのツリーです — 辞書が完了定義を提供します。

関連スキル

• draft-project-charter

  — WBS分解に投入するスコープと成果物を提供する

• manage-backlog

  — WBSワークパッケージを追跡用バックログアイテムに変換する

• generate-status-report

  — WBS完了率に対して進捗を報告する

• plan-sprint

  — ハイブリッドアプローチを使用する場合、WBSワークパッケージからスプリント計画を立てる

• conduct-retrospective

  — 見積もりの精度と分解の品質を見直す