## 計画と見積：要件分解・見積・排期（`/vspec:plan`）

[English](../../en-US/theory/planning.md) | [中文](../../zh-CN/theory/planning.md) | [日本語](../../ja-JP/theory/planning.md)

`/vspec:plan` は「なんとなく日付を決める」ための機能ではありません。要件の口径が収束し、主要な漏れ/矛盾が可視化された後に、作業を分解し、ストーリーポイントで見積り、イテレーションに積み込んで、レビューしやすいストーリーマップとして出力します。

### 前提条件と出力

- 前提（通常は hard gate）：`/vspec:detail` で実装可能粒度の仕様が揃っており、`/vspec:qc` による品質ゲートを通過している
- 出力：
  - `/specs/plan/plan_estimate.md`：機能一覧に紐づくストーリーポイント（SP）見積
  - `/specs/plan/plan_story_map.json`：ストーリーマップのデータ（構造化・再利用可能）
  - `/specs/plan/plan_schedule.html`：ストーリーマップの HTML テンプレート（JSON を読み込み表示）

### 要件分解：シナリオの背骨から「デリバリー切片」へ

分解の価値は、納品可能性・検証可能性・追跡可能性を保つことにあります。

- シナリオを背骨にする：「フロー → 機能 → 画面/API → データ/ルール → 受入」を一本につなぎ、画面/メニュー単位の分解だけに偏らない
- 縦切りを最小単位にする：まずは P0 の主経路を end-to-end で閉じる（早期にデモ/検証できる）
- 依存とリスクで分ける：外部依存が不確実なら、内部だけで進められる切片（モデル/UI/フロー/モック）を先に配置し、実連携は後続スプリントに回して阻害要因を明示する
- サイズ制約で強制分割する：追跡やレビューが破綻する大きさのカードは分割し続ける（例：各カードを SP<=13 に収める）

### 見積：ストーリーポイントで積載する

visual-spec の見積は、相対コストと不確実性を SP で表し、排期の積載単位として使います。

- スケールを統一する：同種の作業を一貫した基準で見積る
- 不確実性を明示する：依存・口径・リソースなどの不確定要素はリスクとして残す
- 過大カードを避ける：大きすぎるカードはリスクを隠すため、分割して追跡可能にする

### 排期：見積表をイテレーション計画に変える

排期は意思決定のための成果物であり、目標・容量・依存・リスクが一枚で見えることが重要です。

- スプリント目標で束ねる：各スプリントが「何を届け、何を検証できるか」を明確にする
- 容量で積載する：Velocity（または推定容量）にバッファをかけ、未知・受入・リリースの余白を確保する
- 制約で順序付ける：主経路を優先し、直列依存と並行制約を守る
- 受入ループを計画に含める：テスト/受入/リリースウィンドウは計画の一部として扱う

### ストーリーマップを HTML にする理由

ストーリーマップの主目的は「横断的なレビュー」であり、HTML はテキスト表よりレビュー入口として適しています。

- 2 次元で見える：スプリント × モジュールで範囲と網羅性が一目で分かる
- レビューの摩擦が低い：ブラウザで開いて関係者全員で確認できる
- 反復が速い：カード上で見積と阻害要因を提示でき、文書間の往復を減らせる

### JSON + HTML テンプレート（読み込み表示）にする理由

`/vspec:plan` は「計画データ」と「表示」を分離し、更新コストと差分ノイズを下げます。

- データが再利用できる：JSON はエクスポートやダッシュボード連携に向く
- UI を進化させやすい：テンプレート側で検索/フィルタ/リスク強調などを追加してもデータ構造を変えなくてよい
- 変更が追いやすい：計画の調整は主に JSON に集約され、レンダリングは安定する
