---
name: sdd-plan
description: 作りたい機能を具体的な質問で掘り下げ、要件・設計・実装タスク・検証方法をそろえる。「計画を立てたい」「仕様を詰めたい」「質問して整理して」「グリリングして」と依頼されたときに使う。コードの実装や完成判定は別工程で行う。
---

# SDD計画・仕様の掘り下げ

利用者と完成条件をはっきりさせ、実装と検証に使える仕様を作ります。説明と質問には日本語を使い、ユーザーが別の言語を指定した場合はそれに従います。専門用語を使う場合は、その場で意味を短く説明します。

## 1. 現状と対象を確かめる

1. プロジェクトの指示、既存仕様、関連コード、テスト、起動方法を読みます。調べられる事実は先に調べ、既存の決定を同じ理由で聞き直しません。
2. 誰が、どの場面で、何をできるようにしたいのかを整理します。今回作る範囲、対象外、守る制約、現在の動作、要望の根拠を分けます。
3. 依頼から確定できない条件は未決定として残します。製品の動作が変わる選択と、既存の方針で決められる実装手段を区別します。

## 2. 具体的な質問で決める

回答によって動作が変わる点を洗い出します。対象者、操作、保存する情報、権限、失敗時の動作、既存機能との互換性、必要な費用など、今回の範囲に関係するものを扱います。

1. 今の情報で答えられる質問を、話題ごとに番号を付けてまとめて聞きます。各質問は一つの判断に絞り、具体的な操作場面、選択肢、利用者への影響、根拠のある推奨案を示します。
2. 例えば「保存に失敗したとき、入力内容を残して再試行できるようにしますか」のように聞きます。「どう作りますか」だけの質問や、仕様書を開かなければ答えられない質問は避けます。
3. 回答を待ちながら、回答に依存しない調査や仕様の整理を進めます。回答が必要な動作を推測で確定しません。
4. 回答によって新しく判断できる点が出た場合は、次の質問群としてまとめます。決まった内容とその根拠を記録し、依存する設計に反映します。
5. ユーザーから選択を任されている場合は、その範囲で判断します。今回の実装に必要な選択がそろったら質問を終え、決まった動作を短く確認します。すでに明示された承認を再度求める必要はありません。

## 3. 要件・設計・タスクを作る

既存の保存場所と形式を優先します。決まりがなければ、機能ごとに`specs/<機能名>/`へ次の3ファイルを作ります。既存文書を更新するときは、無関係な要件や未コミットの変更を保持します。

| ファイル | 書く内容 |
| --- | --- |
| `requirements.md` | 目的、範囲、対象外、要件ID、観察できる受け入れ条件、未決定事項 |
| `design.md` | 要件を実現する責務の分担、データと状態、画面・API・外部サービスの接続、失敗時の処理、必要な移行と運用 |
| `tasks.md` | 実行順、依存関係、関連する要件ID、完成を確かめる方法、必要なリリース作業 |

要件には`REQ-001`のような安定したIDを付けます。受け入れ条件には、操作前の状態、利用者の操作、期待する結果を書きます。成功時に加え、入力不備、権限不足、通信失敗など、要件に関係する失敗時の結果も定めます。性能や料金の数値は資料やユーザーの回答に根拠がある場合にだけ書きます。

設計では、各要件をどこで実現するかを示します。扱う情報に応じて認証、個人情報、保存期間、同時操作、取り消し、後片付けを検討します。関係のない項目を増やさず、未確認の外部サービス仕様は公式資料で確かめます。

タスクは、利用者の操作から結果までをつなげて検証できる単位に分けます。ファイルを作るだけのタスクを完成条件にせず、実装と必要なテストを対応させます。デプロイが範囲に含まれる場合は、移行、公開後の動作確認、問題が起きたときの戻し方も含めます。

`tasks.md`に次の対応表を置き、現在の義務を複数の文書へ重複して書かないようにします。

| 要件ID・受け入れ条件 | 設計の該当箇所 | 実装タスク | 検証方法・必要な環境 |
| --- | --- | --- | --- |
| 各条件を1行ずつ記載 | 責務や接続先 | タスクの参照 | テスト、画面操作、保存結果など |

## 4. 実装に進めるか点検する

依頼内容と3ファイルを比べ、条件の矛盾、抜けた失敗時の動作、実装不能な前提、要件に対応しないタスク、検証できない完成条件を確認します。各受け入れ条件を要件から設計、タスク、検証まで追える状態にします。

不明点や問題があれば、影響する動作と解消方法を示します。体裁が整っただけで実装可能とは判定しません。未承認の機能削除や対象範囲の拡大、仮の応答や認証回避による完成条件を加えません。

最後に、作成・更新したファイル、決まった動作、未決定事項、最初に実装するタスクを示します。計画だけの依頼ではコードを変更しません。実装も依頼されており、必要な判断がそろっていれば、その権限の範囲で実装へ進みます。