create-work-breakdown-structure

作業分解構成（WBS）の作成

プロジェクトのスコープを、見積もり、割り当て、進捗管理ができる階層的な作業パッケージに分解します。WBS は、複雑な成果物を管理しやすい構成要素に分解することで、工数の見積もり、リソース計画、スケジュール作成の基盤となります。

使用するタイミング

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

入力

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

手順

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

プロジェクト憲章を読みます。すべての成果物と受け入れ基準を一覧にします。それらを 3～7 個の最上位カテゴリに分類します（これらが WBS レベル 1 の要素になります）。

期待される結果： 憲章の成果物に対応する WBS レベル 1 の要素の一覧。

失敗した場合： 憲章が曖昧であれば、draft-project-charter に戻ってスコープを明確にします。

ステップ 2：作業パッケージに分解する

各レベル 1 の要素をサブ要素（レベル 2、レベル 3）に分解します。100％ルールを適用します。子要素は親のスコープの 100％を表す必要があります。作業パッケージが次の条件を満たしたら、分解を終了します。

• 見積もり可能（人日単位で工数を割り当てられる）
• 割り当て可能（担当する個人またはチームが 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：工数を見積もる

各作業パッケージに、次の見積もり方法のいずれかを適用します。

• 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 ファイルを作成し、レビュー済みであること。

失敗した場合： ステークホルダーがスコープの抜けを指摘した場合は、作業パッケージを追加して再見積もりします。

検証

• ドキュメント ID と WBS コードを含む 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 — 見積もりの精度と分解の品質を振り返ります