| name | backend-work-planner |
| description | docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。 |
Work Planner
実装着手前に、コードを書かずに 計画書を作る。計画書は docs/work/ に置く。
出力先と命名
docs/work/
└── YYYYMMDD_<feature-snake_case>.md
- 日付は作業開始日（JST の今日）
- 同日複数ある場合は
_01, _02 を末尾付与
- ファイル名は英数字とアンダースコアのみ
実行手順
1. 入力確認
以下を順に確認:
- 仕様の所在:
docs/spec/ に対応する spec があるか
- ない場合 →
backend-spec-creator を先に使うことを提案
- 簡易な仕様で十分なら、口頭要件から進めてもよい（その旨を work 冒頭に明記）
- 目的と完了条件: 何が実装されれば完了か
- 制約: 締切、互換性維持、他チームとの依存
- スコープ: 今回やる / やらない
2. 既存コードベース調査
docs/spec/ と該当する既存実装の場所を特定- 類似機能を
Glob / Grep で探し、参照すべき既存パターン を 1-3 個ピックアップ
- 依存関係（呼び出し元、呼び出し先、データフロー）を確認
3. Phase 分解
原則:
- 1 Phase = 独立してレビュー可能な塊
- Phase 間に明確な依存順序（下から上）
- Phase あたり 30-90 分 が目安
- 並列化可能な Phase を明記する
典型的な構成:
| Phase | 内容 |
|---|
| 0 | 仕様確認・前提整理 |
| 1 | 設計（データモデル、API / IF 定義） |
| 2 | 自動生成・雛形作成（該当する場合） |
| 3..N | 実装（層別 or 機能別に並列化可能） |
| N+1 | テスト |
| N+2 | 統合検証・PR 準備 |
4. テスト戦略
Phase 分解と同時に、以下を決める:
- どの層にテストを書くか（unit / integration / e2e）
- 既存テスト基盤の活用方針
- カバレッジ目標（無理に数値を置かない。「〇〇の振る舞いを網羅」程度で可）
5. リスク列挙
- 技術的リスク（未知の API、性能、互換性）
- 運用的リスク（データ移行、ロールバック手順）
- スケジュール的リスク（依存タスクの遅延）
「リスクなし」は書かない。本当にない場合はセクションごと省略する。
6. 計画書テンプレート
# <機能名> 実装計画
- **作成日**: YYYY-MM-DD
- **仕様書**: [docs/spec/<name>-spec.md](../spec/<name>-spec.md) ※ない場合は省略
- **完了条件**: <done definition>
## 1. 基本情報
### 目的
<なぜやるか>
### スコープ
- 含む: ...
- 含まない: ...
### 制約
- <期限 / 互換性 / 他依存>
## 2. 現状分析
### 関連する既存コード
- `<path>` — <役割>
### 類似パターン（参考）
- `<path>` — <何を参考にするか>
### 依存関係
- 上流: <このコードを呼ぶもの>
- 下流: <このコードが呼ぶもの>
## 3. 設計方針
### 採用するパターン
<類似実装のどれを踏襲するか / 新規パターンを入れる理由>
### データモデル
<新規 / 変更するエンティティ>
### インターフェース
<外部公開される API / 関数シグネチャの概要>
## 4. Phase 分解
### Phase 0: <タイトル>
- **目的**: ...
- **成果物**: ...
- **検証**: ...
- **所要時間**: <見積>
- **依存**: <先行 Phase>
### Phase 1: ...
（必要数だけ）
## 5. 並列化計画
Phase 0 ─┐
├─ Phase 3 (実装 A)
Phase 1 ─┤
├─ Phase 4 (実装 B)
Phase 2 ─┘
↓
Phase 5 (統合)
## 6. テスト戦略
- <層ごとの方針>
- <既存テスト資産の活用>
- <最低限満たすべき振る舞いの列挙>
## 7. リスクと対策
| リスク | 影響 | 対策 |
| --- | --- | --- |
| <内容> | 高/中/低 | <mitigation> |
## 8. ロールバック戦略
<本番デプロイ後に戻せる設計になっているか。feature flag、DB migration を破壊的にしない分割(NOT NULL 化を 2 段階に分けるなど)、down が必要なら手書きで添付>
## 9. オープン課題
- [ ] <未決定事項>
## 10. 参考資料
- <spec, 類似実装, 外部ドキュメント>
7. レビューと承認
計画書をユーザーに提示:
docs/work/YYYYMMDD_<feature>.md を作成しました。
特に確認していただきたい点:
- Phase 分解の粒度（N 個で問題ないか）
- 並列化の依存関係
- リスク XX への対策案
この計画で着手してよろしいですか？
承認を得るまで実装に入らない。
やらないこと
- 実装コードを書き始める（計画書のみを作る）
- 仕様策定まで踏み込む（仕様が曖昧なら
backend-spec-creator に戻す）
- 計画書を一人で書き切って投げつける（分解案・リスクはユーザーに確認する）
関連
