要件収束
目的
要件は、膨らんだ状態、曖昧な状態、狙う成果を外した状態で届く。能力の高いモデルはその3つをまとめて筋の通った計画に組み直し、忠実に作り上げてしまう — 求められたものが間違っていたときに、求められたとおりのものを届けることになる。
このスキルは何を作るかを収束させる。どう作るか、そして変更にどのドキュメントが必要かは、何を作るかが決まった後に定める。
収束フィールド
| フィールド | 通過条件 |
|---|---|
outcome | 観測可能な結果が1つ。それに寄与しない要件は不要である。 |
requirements[] | 作る対象に関わる各項目に current-state または desired-future のラベルが付いている。 |
nonGoals[] | ユーザーが挙げたもの。または、除外すべきものはないとユーザーが述べたこと。 |
cost | 区分1つと、それを決めた構造上の根拠、および残っている不明点。 |
cost はおおまかな区分であり、作業計画書がスケジュールの根拠にする工数見積ではない — 要件の段階では人日を裏付けられない。残っている不明点は、規模そのものよりも判断に影響する。
分類は、アナライザが言い換えたものではなく、保持しているユーザー自身の文言から行う。評価を求める文言、推測的なアイデアを述べる文言、実装手段を提案する文言は、収束中は判断のための候補としてのみ扱う。requirements[] や後続作業で参照されるドキュメントに入れるのは、ユーザーが明示的に採用したものだけとする。
各フィールドは自身の readiness ラベルを持つ: ready、weak、weak-but-explicit（weak だが、未解決のまま残すことにユーザーが同意した状態）。weak-but-explicit を設定できるのはユーザーだけである。該当する全フィールドが ready または weak-but-explicit になった時点で、要件は収束したとみなす。
フィールドごとの判断ルール: references/criteria.md。
ヒアリングプロトコル
利用可能なスコープとコストのエビデンスを、聞き出す作業と判定の両方に用いる。質問するのは、リポジトリからは答えられないプロダクト上の選択だけとする。requirements[] と除外事項のヒアリングは、ユーザーが依頼した機能から組み立てる。分析中に見つかった隣接する機能はどちらにも含めないので、ユーザーは依頼していない機能を却下する必要がない。スコープとコストを再分析するのは、回答が分析対象または必要なスコープエビデンスを変える場合に限る。
開始前に以下のステップを登録し、完了ごとにその根拠を記録する:
| ステップ | 行うこと | 完了の根拠 |
|---|---|---|
| 1 | 利用可能なスコープの事実を述べ、そこから要件について何が言えるかを分けて示す | 事実が、その分析エビデンスとともに列挙されている |
| 2 | ready に達していないフィールドについて、1メッセージあたり最大2問で質問する | ready に達していないフィールドごとに1問 |
| 3 | 各回答をそのフィールドの値として記録する | 値が、ユーザーが明示的に選んだ選択肢、またはユーザー自身が述べた言い回しになっている |
| 4 | 記録した値がまだ通過条件を満たさない場合は1度だけ聞き直し、2度目の回答のままでよいとユーザーが同意した時点でそのフィールドを weak-but-explicit とする | 記録された回答が2つ、またはそこで止めることへのユーザーの同意 |
| 5 | 各フィールドを通過条件に照らして判定し、記録を完成させる | 全フィールドにラベルが付いた収束記録 |
保存プロトコル
| 保持先 | 保持する内容 |
|---|---|
| 現在の収束記録 | 全フィールドとその readiness ラベル |
PRD の 成功基準 と Out of Scope | outcome、およびユーザーが挙げた nonGoals |
Design Doc の Requirement Convergence | PRD がない場合は上と同じ内容。加えて weak-but-explicit のまま残ったフィールドは常にここへ記録する |
どちらのドキュメントも生成しない場合は、現在のコンテキストに記録を保持する。
参照プロトコル
- プロンプトから収束記録を読む。
nonGoalsは今回の変更から除外し、desired-future要件を作る対象として扱う。採用されていない評価依頼、推測的なアイデア、指定された実装手段、エージェントが提案した機能は実装作業を生まない。評価した選択肢を判断の履歴として残せるのは、承認済みADRがそれを扱う場合だけである。weak-but-explicitのフィールドは、確定した判断ではなく記録された未解決の論点として扱い、作業がその解決に依存する場合はエスカレーションする。
品質チェックリスト
- 質問の前にスコープの事実を提示した
-
nonGoalsがユーザーから出たもの、または除外すべきものはないとユーザーが述べたものになっている - 該当する全フィールドが
ready、またはユーザーの同意によるweak-but-explicitになっている
References
- references/criteria.md — フィールドごとの判断ルール、コストの入力、チャレンジの強度、手段すり替えの検出
