WBS完全ガイド

WBS完全ガイド

この資料は、遅延を未然に防ぎ、チームを自律的に動かすための実戦書としてWBSを再定義します。 目的は「分解すること」ではなく、依存関係を可視化し、完了条件を明示し、遅延を起こさない構造を作ることです。

1. WBSとは

WBSの役割

WBS（Work Breakdown Structure）は、プロジェクトを小さな作業単位に分解し、依存関係と完了条件を明示するための設計図です。 「誰がいつまでに何を終わらせるか」を曖昧にしないことで、遅延の温床を潰します。

WBSの目的
   ├─ プロジェクトの全体像の把握
   ├─ 作業の明確化
   ├─ 見積もりの精度向上
   ├─ 進捗管理の容易化
   ├─ 依存関係の可視化
   └─ 完了条件の明確化

なぜWBSが必要か

問題のある構成（WBSなし）:

問題のある状況:
- プロジェクトの全体像が把握できない
- 作業の漏れが発生する
- 見積もりが不正確
- 進捗管理が困難
- 依存関係が不明でブロッキングが発生する
- 完了条件が曖昧で「終わる終わる詐欺」が起きる

影響:
- プロジェクトの遅延
- 予算の超過
- 品質の低下
- チームの混乱
- リリース順序が崩れる

解決: WBSによる明確な構造化

解決策:
- プロジェクトを階層的に分解
- 作業の漏れを防止
- 見積もりの精度向上
- 進捗管理の容易化
- 先行タスクを明記してブロッキングを防止
- 完了定義（DoD）で「終わり」を明文化

メリット:
- プロジェクトの全体像が把握できる
- 作業の漏れが減る
- 見積もりが正確になる
- 進捗管理が容易になる
- ブロッキングが早期に見える
- 自己申告のズレが減る

2. WBSの基本構造

WBSの階層構造

graph TD
    A[プロジェクト] --> B[フェーズ1]
    A --> C[フェーズ2]
    A --> D[フェーズ3]

    B --> E[作業1.1]
    B --> F[作業1.2]
    B --> G[作業1.3]

    E --> H[タスク1.1.1]
    E --> I[タスク1.1.2]

    F --> J[タスク1.2.1]
    F --> K[タスク1.2.2]

WBSのレベル

レベル1: プロジェクト全体
レベル2: フェーズ/マイルストーン
レベル3: 作業パッケージ
レベル4: タスク
レベル5: サブタスク（必要に応じて）

先行タスク（依存関係）の明記

各タスクに「先行タスク」を持たせ、ブロッキングを見える化します。 これがないと、最初に止まったタスクが最後まで誰にも見えません。

ID   | タスク名                 | 先行タスク
1.1  | 要件定義                 | -
1.2  | API設計                  | 1.1
1.3  | バックエンド実装         | 1.2
1.4  | フロントエンド実装       | 1.2
1.5  | 統合テスト               | 1.3, 1.4

3. WBSの線の引き方

原則1: 100%ルール

## 100%ルール

### 原則
- 親要素の作業は、子要素の作業の合計と等しくなければならない
- すべての作業が漏れなく含まれている必要がある

### 実装例

#### 正しい例

プロジェクト: ECサイト開発（100%） ├── フェーズ1: 要件定義（20%） │ ├── 要件収集（10%） │ └── 要件定義書作成（10%） ├── フェーズ2: 設計（30%） │ ├── システム設計（15%） │ └── データベース設計（15%） └── フェーズ3: 実装（50%） ├── フロントエンド実装（25%） └── バックエンド実装（25%）

#### 間違った例

プロジェクト: ECサイト開発（100%） ├── フェーズ1: 要件定義（20%） ├── フェーズ2: 設計（30%） └── フェーズ3: 実装（40%）

問題: 合計が90%で、10%が不足している

原則2: 相互排他性

## 相互排他性

### 原則
- 各作業は、他の作業と重複してはならない
- 各作業は、明確に区別できる必要がある

### 実装例

#### 正しい例

実装フェーズ ├── フロントエンド実装 │ ├── UIコンポーネント作成 │ └── API連携 └── バックエンド実装 ├── API実装 └── データベース操作

#### 間違った例

実装フェーズ ├── フロントエンド実装 │ ├── UIコンポーネント作成 │ └── API実装（重複） └── バックエンド実装 ├── API実装（重複） └── データベース操作

問題: API実装が重複している

原則3: 成果物指向

## 成果物指向

### 原則
- 作業ではなく、成果物（Deliverable）で分解する
- 成果物が明確になれば、作業も明確になる

### 実装例

#### 成果物指向（推奨）

ECサイト開発 ├── 要件定義書 │ ├── 機能要件 │ └── 非機能要件 ├── 設計書 │ ├── システム設計書 │ └── データベース設計書 └── 実装成果物 ├── フロントエンドコード └── バックエンドコード

#### 作業指向（非推奨）

ECサイト開発 ├── 要件定義作業 ├── 設計作業 └── 実装作業

問題: 成果物が不明確

4. WBSの作成手順

ステップ1: プロジェクトの分解

## プロジェクトの分解

### 方法
1. プロジェクトを主要なフェーズに分解
2. 各フェーズを作業パッケージに分解
3. 各作業パッケージをタスクに分解

### 実装例

#### レベル1: プロジェクト
ECサイト開発プロジェクト

#### レベル2: フェーズ
1. 要件定義
2. 設計
3. 実装
4. テスト
5. デプロイ

#### レベル3: 作業パッケージ
要件定義
├── 要件収集
├── 要件分析
└── 要件定義書作成

ステップ2: 詳細化

## 詳細化

### 方法
1. 各作業パッケージをさらに詳細化
2. タスクレベルまで分解
3. 見積もり可能な単位まで分解
4. 先行タスク（依存関係）を明記
5. 完了定義（DoD）を設定

### 実装例

#### レベル4: タスク
要件収集
├── ステークホルダーインタビュー
├── 既存システムの調査
└── 競合他社の調査

完了定義（DoD）の設定

「終わり」を明文化しないタスクは、終わりません。

作業パッケージ: API設計
DoD:
- OpenAPIが作成されている
- レビューが完了している
- フロント/バックで契約の合意が取れている

段階的詳細化（生きたWBS）

最初から細分化しすぎると、変更に追従できなくなります。 初期は粗く、フェーズ開始時に必要な粒度まで詳細化します。

ステップ3: 検証

## 検証

### チェック項目
- [ ] 100%ルールが守られているか
- [ ] 相互排他性が保たれているか
- [ ] 成果物が明確か
- [ ] 見積もり可能な単位まで分解されているか
- [ ] 作業の漏れがないか
- [ ] 先行タスクが明記されているか
- [ ] 作業パッケージごとのDoDがあるか

5. 実践的なWBS例

ケース1: ECサイト開発プロジェクト

graph TD
    A[ECサイト開発] --> B[要件定義]
    A --> C[設計]
    A --> D[実装]
    A --> E[テスト]
    A --> F[デプロイ]

    B --> B1[要件収集]
    B --> B2[要件分析]
    B --> B3[要件定義書作成]

    C --> C1[システム設計]
    C --> C2[データベース設計]
    C --> C3[API設計]

    D --> D1[フロントエンド実装]
    D --> D2[バックエンド実装]

    D1 --> D1a[UIコンポーネント作成]
    D1 --> D1b[API連携]
    D1 --> D1c[状態管理実装]

    D2 --> D2a[認証機能実装]
    D2 --> D2b[商品管理機能実装]
    D2 --> D2c[注文機能実装]

ケース2: API開発プロジェクト

## API開発プロジェクトのWBS

### レベル1: プロジェクト
API開発プロジェクト

### レベル2: フェーズ
1. 要件定義（20%）
2. 設計（30%）
3. 実装（40%）
4. テスト（10%）

### レベル3: 作業パッケージ

#### 要件定義（20%）
- 要件収集（10%）
  - ステークホルダーインタビュー（5%）
  - 既存システムの調査（3%）
  - 競合他社の調査（2%）
- 要件分析（5%）
  - 機能要件の整理（3%）
  - 非機能要件の整理（2%）
- 要件定義書作成（5%）
  - 機能要件書作成（3%）
  - 非機能要件書作成（2%）

#### 設計（30%）
- システム設計（15%）
  - アーキテクチャ設計（8%）
  - データモデル設計（4%）
  - セキュリティ設計（3%）
- API設計（10%）
  - RESTful API設計（5%）
  - エラーハンドリング設計（3%）
  - 認証・認可設計（2%）
- データベース設計（5%）
  - テーブル設計（3%）
  - インデックス設計（2%）

#### 実装（40%）
- バックエンド実装（25%）
  - 認証機能実装（5%）
  - ユーザー管理機能実装（5%）
  - 商品管理機能実装（8%）
  - 注文機能実装（7%）
- フロントエンド実装（15%）
  - UIコンポーネント作成（5%）
  - API連携（5%）
  - 状態管理実装（3%）
  - ルーティング実装（2%）

#### テスト（10%）
- 単体テスト（5%）
  - バックエンドテスト（3%）
  - フロントエンドテスト（2%）
- 統合テスト（3%）
  - APIテスト（2%）
  - E2Eテスト（1%）
- テストレビュー（2%）

6. WBSの線の引き方の実践例

パターン1: 機能別の分解

## 機能別の分解

### 実装例
ECサイト開発
├── ユーザー管理機能
│   ├── ユーザー登録
│   ├── ユーザー認証
│   └── ユーザー情報管理
├── 商品管理機能
│   ├── 商品一覧
│   ├── 商品詳細
│   └── 商品検索
└── 注文管理機能
    ├── カート機能
    ├── 注文作成
    └── 注文履歴

パターン2: フェーズ別の分解

## フェーズ別の分解

### 実装例
ECサイト開発
├── 要件定義フェーズ
│   ├── 要件収集
│   ├── 要件分析
│   └── 要件定義書作成
├── 設計フェーズ
│   ├── システム設計
│   ├── API設計
│   └── データベース設計
├── 実装フェーズ
│   ├── バックエンド実装
│   └── フロントエンド実装
└── テストフェーズ
    ├── 単体テスト
    └── 統合テスト

パターン3: コンポーネント別の分解

## コンポーネント別の分解

### 実装例
ECサイト開発
├── フロントエンド
│   ├── ユーザーインターフェース
│   ├── 状態管理
│   └── API連携
├── バックエンド
│   ├── API実装
│   ├── ビジネスロジック
│   └── データアクセス
└── インフラ
    ├── サーバー構築
    ├── データベース構築
    └── CI/CD構築

7. WBSの作成ツール

Mermaidを使用したWBS

graph TD
    A[ECサイト開発] --> B[要件定義]
    A --> C[設計]
    A --> D[実装]
    A --> E[テスト]

    B --> B1[要件収集]
    B --> B2[要件分析]
    B --> B3[要件定義書作成]

    C --> C1[システム設計]
    C --> C2[API設計]
    C --> C3[データベース設計]

    D --> D1[バックエンド実装]
    D --> D2[フロントエンド実装]

    D1 --> D1a[認証機能]
    D1 --> D1b[商品管理機能]
    D1 --> D1c[注文機能]

    D2 --> D2a[UIコンポーネント]
    D2 --> D2b[API連携]
    D2 --> D2c[状態管理]

表形式のWBS

ID	作業名	親ID	見積もり	先行タスク	DoD	担当者	状態
1.0	ECサイト開発	-	100%	-	本番稼働	PM	進行中
1.1	要件定義	1.0	20%	-	仕様合意	BA	完了
1.1.1	要件収集	1.1	10%	-	要件一覧確定	BA	完了
1.1.2	要件分析	1.1	5%	1.1.1	影響分析完了	BA	完了
1.1.3	要件定義書作成	1.1	5%	1.1.2	合意済み	BA	完了
1.2	設計	1.0	30%	1.1	設計レビュー完了	アーキテクト	進行中
1.2.1	システム設計	1.2	15%	1.1.3	ADR承認	アーキテクト	完了
1.2.2	API設計	1.2	10%	1.1.3	OpenAPI承認	アーキテクト	進行中
1.2.3	データベース設計	1.2	5%	1.1.3	ERD承認	アーキテクト	未着手
1.3	実装	1.0	40%	1.2	主要機能完了	エンジニア	未着手
1.3.1	バックエンド実装	1.3	25%	1.2.2, 1.2.3	APIテスト合格	バックエンド	未着手
1.3.2	フロントエンド実装	1.3	15%	1.2.2	主要画面完成	フロントエンド	未着手
1.4	テスト	1.0	10%	1.3	品質基準達成	QA	未着手
1.4.1	単体テスト	1.4	5%	1.3.1, 1.3.2	カバレッジ基準達成	エンジニア	未着手
1.4.2	統合テスト	1.4	3%	1.4.1	E2E合格	QA	未着手
1.4.3	テストレビュー	1.4	2%	1.4.2	レビュー完了	QA	未着手

8. 実務でのベストプラクティス

パターン1: WBSの粒度管理

## WBSの粒度

### 適切な粒度
- **レベル1-2**: プロジェクト全体、フェーズ（粗い粒度）
- **レベル3-4**: 作業パッケージ、タスク（中程度の粒度）
- **レベル5以下**: サブタスク（細かい粒度、必要に応じて）

### 実装例

#### 適切な粒度

レベル1: ECサイト開発 レベル2: 実装フェーズ レベル3: バックエンド実装 レベル4: 認証機能実装 レベル5: JWTトークン実装（必要に応じて）

#### 不適切な粒度

レベル1: ECサイト開発 レベル2: 実装フェーズ レベル3: バックエンド実装 レベル4: 認証機能実装 レベル5: JWTトークン実装 レベル6: トークン生成処理 レベル7: トークン検証処理 レベル8: トークン更新処理

問題: 細かすぎる

パターン2: 段階的詳細化（Rolling Wave）

## 段階的詳細化

### 原則
- **初期は粗く**: 主要フェーズまでで止める
- **手前は細かく**: 直近2〜4週間の作業だけ詳細化する
- **後ろは粗く**: 先の作業は仮置きに留める

### 更新タイミング
- **フェーズ開始時**: 詳細化
- **進捗に応じて**: 直近の作業のみ精緻化
- **変更時**: 依存関係とDoDを再調整

パターン3: WBSとスケジュールの連携

## WBSとスケジュールの連携

### ガントチャートとの連携
- WBSの各作業をガントチャートに反映
- 先行タスクを線でつなぎ、ブロッキングを見える化
- マイルストーンを設定

### 実装例

#### ガントチャート

タスク名	開始日	終了日	期間
要件定義	2024-01-01	2024-01-05	5日
設計	2024-01-06	2024-01-12	7日
実装	2024-01-13	2024-02-02	21日
テスト	2024-02-03	2024-02-07	5日

パターン4: WBSとかんばんリストの連携

## WBSとかんばんリストの連携

### 連携方針
- WBSは「構造」と「依存関係」を管理
- かんばんは「日々の流れ」と「現在の詰まり」を管理

### 連携方法
- WBSの作業パッケージをかんばんのエピックにする
- タスクをかんばんのカードに落とす
- 先行タスクが未完了のカードは着手禁止にする

9. よくある問題と解決策

問題1: WBSが複雑になりすぎる

原因:

• 細かく分解しすぎている
• 階層が深すぎる

解決策:

## WBSの簡素化

### 方法
1. 不要な階層を削除
2. 関連する作業を統合
3. 適切な粒度を維持

### 実装例

#### 複雑なWBS（改善前）

実装 ├── バックエンド実装 │ ├── 認証機能実装 │ │ ├── JWTトークン実装 │ │ │ ├── トークン生成 │ │ │ └── トークン検証 │ │ └── 認証ミドルウェア実装 │ └── ユーザー管理機能実装 └── フロントエンド実装

#### 簡素化したWBS（改善後）

実装 ├── バックエンド実装 │ ├── 認証機能実装 │ └── ユーザー管理機能実装 └── フロントエンド実装

問題2: 作業の漏れ

原因:

• WBSの作成が不十分
• 100%ルールが守られていない

解決策:

## 作業の漏れ防止

### 方法
1. 100%ルールの徹底
2. チーム全体でのレビュー
3. 過去のプロジェクトの参照
4. チェックリストの使用

### チェックリスト
- [ ] すべてのフェーズが含まれているか
- [ ] すべての機能が含まれているか
- [ ] テストが含まれているか
- [ ] ドキュメント作成が含まれているか
- [ ] デプロイが含まれているか

### 問題3: WBSが更新されない

**原因:**
- 更新の責任者が不明確
- 更新のプロセスがない

**解決策:**
```markdown
## WBSの更新プロセス

### 方法
1. 更新の責任者を明確にする
2. 定期的な更新をスケジュールする
3. 変更時の更新を義務付ける
4. 更新履歴を記録する

### 実装例

#### 更新スケジュール
- **週次**: 進捗に応じた更新
- **フェーズ開始時**: 詳細化
- **変更時**: 即座に更新

#### 更新履歴
- 日付: 2024-01-15
- 変更内容: 認証機能の実装を追加
- 変更理由: 要件の追加
- 変更者: プロジェクトマネージャー

これで、WBSの基礎知識と実務での使い方を理解できるようになりました。