backend-work-planner

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. 入力確認

以下を順に確認:

1. 仕様の所在: docs/spec/ に対応する spec があるか
   • ない場合 → backend-spec-creator を先に使うことを提案
   • 簡易な仕様で十分なら、口頭要件から進めてもよい（その旨を work 冒頭に明記）
2. 目的と完了条件: 何が実装されれば完了か
3. 制約: 締切、互換性維持、他チームとの依存
4. スコープ: 今回やる / やらない

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 に戻す）
• 計画書を一人で書き切って投げつける（分解案・リスクはユーザーに確認する）

関連

• backend-spec-creator — 仕様が未整備の場合に先行
• backend-dev-manager — 計画書をもとに実装オーケストレーション
• backend-refactor-planner — リファクタ専用の計画