## なぜ `/vspec:new` は多くの観点を分析するのか

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

`/vspec:new` の目的は「要件を要約する」ことではなく、後続工程で再利用できる baseline を作ることです。実装やテストに必要な制約は複数軸に散らばっており、文章中心の PRD だけでは安定したエンジニアリング入力になりにくい、という前提で設計されています。

### `/vspec:new` で使う思考法

- 代表的な思考法：境界思考、対称思考、制約思考、多様性思考  
  - [theory/thinking-modes.md](thinking-modes.md)
- ステークホルダー識別の思考法：価値連鎖/権限とデータ/例外と補償/マイルストーンから決定者とレビュー主体を特定する  
  - [theory/stakeholder-identification.md](stakeholder-identification.md)

### `/vspec:new` が抽出する主な観点（と理由）

- ロールとステークホルダー
  - 理由：RBAC、可視性、承認、データ権限はロール定義に依存する
- 用語と定義（グロッサリー）
  - 理由：口径のズレはレビュー/実装の曖昧さと手戻りの最大要因になる
- シナリオ
  - 理由：「フロー → 機能 → 画面 → データ → 受入」を貫通する背骨。分析/確認/検証に加えて、`/vspec:accept` による受入用ケース生成の入力にもなる
- フローと状態
  - 理由：境界条件や例外は状態/遷移の設計不備として表出しやすい
- 機能一覧とスコープ境界
  - 理由：見積・受入・テスト範囲の前提となり、“暗黙に全部やる” を防ぐ
- 依存関係（外部システム）
  - 理由：連携は API、信頼性、再試行/補償、障害設計に直結する
- 未解決質問（Open Questions）
  - 理由：不確実性を可視化し、意思決定を追跡可能にする

### なぜ後で足すのではダメなのか

- 後から変えるほど影響が広がる：ロール/シナリオ/用語は details/プロトタイプ/受入/実装入力に波及する
- レビューのコストが跳ね上がる：後工程の修正は連鎖手戻りになりやすい
- 品質ゲートが成立しない：QC/受入/排期は baseline に依存する

### 後続コマンドでの再利用

- `/vspec:detail`：functions/scenarios を実装可能な spec に展開
- `/vspec:verify`：details と選定スタックから実行可能プロトタイプを生成
- `/vspec:accept`：シナリオを受入用ケースに変換
- `/vspec:impl` と `/vspec:append-test`：追跡可能な成果物を前提に落地コストを下げる
