53施策を並行管理する：WBS駆動のAIプロジェクト管理

個人開発でも施策数が50を超えると、「何がどこまで進んでいるか」を頭で管理するのは不可能になります。現在、3つのエンジン（データ処理エンジンA・データ処理エンジンB・データ処理エンジンC）にまたがる53のアクティブ施策と58の計画施策を並行管理しています。

本記事では、WBS（Work Breakdown Structure、作業分解構成図）をMarkdownで管理し、Claude Codeのコンテキストとして活用するプロジェクト管理の手法を記録します。

なぜTrelloやJiraではなくMarkdownか

AIとの相性

Claude Codeは.wbs/CURRENT.mdをコンテキストとして読み込めます。TrelloやJiraのAPIを叩くよりも、Markdownファイルを直接読む方がはるかに高速で正確です。

1
プロンプト:
2
@.wbs/CURRENT.md NEW-11の依存関係と現在のステータスを確認してください。

AIが即座に「NEW-11はENG-A-ADD-A2のGO判定に依存しており、現在Pre環境でDry-Run中」と回答できます。

バージョン管理

MarkdownならGitで履歴管理できます。「3週間前の計画と今の計画の差分」がgit diffで確認できます。JiraやTrelloではこの差分追跡が難しいです。

単一ファイルの一覧性

53の施策を1ファイルで俯瞰できます。ツールのUI画面を行ったり来たりする必要がありません。

WBSの構成

ファイル構成

1
.wbs/
2
  CURRENT.md     ← 正式版（約600行）

セクション構成

1
# data-processing v3.8.31 WBS
2

3
## 実行中プロジェクト（53件）
4

5
### データ処理エンジンA（22件）
6
| ID | 施策名 | ステータス | 依存 | 期限 |
7
|---|---|---|---|---|
8
| NEW-30 | バッチサイズ自動調整 | Practice中 | - | 04-22 |
9
| NEW-31 | 高確率局面閾値緩和 | Dry-Run中 | NEW-29 | 04-01 |
10
...
11

12
### データ処理エンジンB（15件）
13
...
14

15
### データ処理エンジンC（8件）
10 collapsed lines
16
...
17

18
### システム基盤（8件）
19
...
20

21
## 計画中プロジェクト（58件）
22
...
23

24
## 完了済みプロジェクト（40件+）
25
...

施策のライフサイクル

1
計画中 → 実行中（実装） → Dry-Run中 → Practice中 → 本番稼働 → 完了
2
                                ↓
3
                          NO-GO → 凍結/破棄

ステータス	意味
計画中	設計前。WBSに登録済み
実行中	実装〜テスト中
Dry-Run中	Pre環境で検証中。実際の処理は実行しない
Practice中	本番環境で最小リソースで実運用
本番稼働	通常リソースで運用
完了	検証終了。WBSの完了セクションに移動
凍結	統計的にNO-GO判定。将来再検討の可能性あり

依存関係の管理

施策間の依存

施策には前提条件（依存関係）があります。

1
| ID | 施策名 | 依存 |
2
|---|---|---|
3
| NEW-31 | 高確率局面閾値緩和 | NEW-29（感度分析完了が前提） |
4
| RNG-B1 | レンジ専用トリガー | RNG-A4（レジーム判定基盤が前提） |
5
| ENG-C-B1 | メトリクス異常検知 | ENG-C-T1〜T3（基盤構築が前提） |

依存が解決されていない施策を実装しようとすると、AIに「依存先のNEW-29がまだ完了していません」と警告させます。

Go/No-Go依存

「この施策のGo判定が出るまで、次の施策に進んではいけない」というゲートもあります。

1
NEW-11（トレーリングストップ）:
2
  Go/No-Go判定: 2026-04-01
3
  判定基準: 30処理以上, Wilson下限 > 40%
4
  依存施策: ENG-A-ADD-A2のGO後に有効化

AIとの連携パターン

パターン1: 施策開始時のコンテキスト読み込み

1
プロンプト:
2
NEW-11 施策開始。
3
@.wbs/CURRENT.md から施策内容を確認し、
4
@CLAUDE.md のルールに従って作業を開始してください。

AIがWBSを読み、施策の目的・依存・影響範囲を把握してから作業を始めます。

パターン2: ステータス更新

1
プロンプト:
2
NEW-11の実装が完了し、Pre環境にデプロイしました。
3
WBSのステータスを「実行中」から「Dry-Run中」に更新してください。
4
Go/No-Go判定日: 2026-04-01

AIがWBSファイルを更新し、ステータス変更をコミットします。

パターン3: 影響範囲の確認

1
プロンプト:
2
RNG-A4のレジーム判定基盤を変更します。
3
@.wbs/CURRENT.md でRNG-A4に依存している施策を全て列挙してください。

AIが依存関係を逆引きし、影響を受ける施策を一覧化します。

パターン4: 進捗サマリー

1
プロンプト:
2
@.wbs/CURRENT.md から、今週完了した施策と
3
来週のGo/No-Go判定予定をサマリーしてください。

週次の進捗レビューをAIに依頼できます。

完了施策のドキュメント管理

施策が完了したら、ドキュメントを.tmp/から.docs/に移動します。

1
施策完了時の移動:
2
  .tmp/requirements.md  → _engineA/.docs/340_requirements.md
3
  .tmp/design.md        → _engineA/.docs/341_design.md
4
  .tmp/test_design.md   → _engineA/.docs/342_test_design.md

.docs/の連番（NNN_）管理により、施策の実装順序が追跡可能になります。現在、データ処理エンジンAだけで100以上のドキュメントが蓄積されています。

WBS運用の教訓

失敗1: WBSとCLAUDE.mdの乖離

WBSを更新したがCLAUDE.mdの参照情報を更新し忘れ、AIが古い情報を参照して作業を進めたことがあります。

対策: WBSとCLAUDE.mdの変更は全ブランチに即時同期するルールを設けました。

失敗2: 計画施策の過剰増殖

「いつかやりたい」施策を計画中に追加し続けた結果、58件に膨れ上がりました。計画中の施策が多すぎると、優先順位の判断が困難になります。

対策: 四半期ごとに計画中施策をレビューし、6ヶ月以内に着手しないものは「アイデア」セクションに移動します。

失敗3: 施策粒度のばらつき

「エンジンA基盤構築（T1〜T4）」と「Slack通知フォーマット修正」が同じ粒度でWBSに並んでいました。

対策: 大きな施策はサブタスク（B3〜B7のように）に分解し、1施策 = 1〜2週間で完了できる粒度に統一します。

学んだこと

1. WBSはMarkdownが最適

AIが直接読み書きできる、Gitで差分追跡できる、1ファイルで俯瞰できる。この3点でMarkdownが他のツールを上回ります。

2. 依存関係の管理がボトルネック

50施策を超えると、依存関係の把握が最大の課題になります。WBSに依存列を明示し、AIに逆引きさせることで管理負荷を下げました。

3. ステータス遷移を明確にする

「実装中」「テスト中」「レビュー中」といった曖昧なステータスではなく、「計画→実行→Dry-Run→Practice→本番→完了」という明確なライフサイクルを定義します。

まとめ

WBS駆動のプロジェクト管理で重要なのは以下の3点です。

Markdown WBSをAIコンテキストに: @.wbs/CURRENT.mdで施策の目的・依存・ステータスを即座に参照
施策ライフサイクルの明確化: 計画→実行→Dry-Run→Practice→本番→完了の6段階で進捗を管理
全ブランチ即時同期: WBSとCLAUDE.mdの変更は全環境に反映。古い情報でAIが作業することを防止

53施策の並行管理は、AIをプロジェクト管理アシスタントとして使うことで初めて可能になりました。