Requirement Convergence

要件収束

目的

要件は、膨らんだ状態、曖昧な状態、狙う成果を外した状態で届く。能力の高いモデルはその3つをまとめて筋の通った計画に組み直し、忠実に作り上げてしまう — 求められたものが間違っていたときに、求められたとおりのものを届けることになる。

このスキルは何を作るかを収束させる。どう作るか、そして変更にどのドキュメントが必要かは、何を作るかが決まった後に定める。

収束フィールド

| フィールド | 通過条件 |

|-----------|---------|

| outcome | 観測可能な結果が1つ。それに寄与しない要件は余剰である。 |

| requirements[] | 各項目に current-state、desired-future、speculative のいずれかのラベルが付いている。speculative はこのレイヤーラベルの1つであり独立したフィールドではない。「投機的要件」とはそのラベルを持つ項目を指す。 |

| nonGoals[] | ユーザーが挙げたもの。または、除外すべきものはないとユーザーが述べたこと。 |

| cost | バンド1つと、それを決めた構造上の根拠、および残っている不明点。 |

cost は粗いバンドであり、作業計画書がスケジュールの根拠にする工数見積ではない — 要件の段階では人日を支えられない。その不明点は、大きさよりも判断上の重みを持つ。

各フィールドは自身の readiness ラベルを持つ: ready、weak、weak-but-explicit（weak だが、未解決のまま残すことにユーザーが同意した状態）。weak-but-explicit を設定できるのはユーザーだけである。該当する全フィールドが ready または weak-but-explicit になった時点で、要件は収束したとみなす。

フィールドごとの判断ルール: references/criteria.md。

ヒアリングプロトコル

聞き出す作業はユーザーとの対話を要するため、オーケストレータが担う。スコープの事実を作り出した分析の後に実行する — オーケストレータ自身は何も調査しないためである。

開始前に以下のステップを登録し、完了ごとにその根拠を記録する:

| ステップ | 行うこと | 完了の根拠 |

|---------|---------|-----------|

| 1 | 分析が出したスコープの事実を述べ、そこから要件について何が言えるかを分けて示す | 事実が、その出所となった分析出力とともに列挙されている |

| 2 | ready に達していないフィールドについて、1メッセージあたり最大2問で質問する | ready に達していないフィールドごとに1問 |

| 3 | 各回答をそのフィールドの値として記録する | 値が、ユーザーが選択した選択肢、またはユーザーが述べた言い回しになっている |

| 4 | 記録した値がまだ通過条件を満たさない場合は1度だけ聞き直し、2度目の回答のままでよいとユーザーが同意した時点でそのフィールドを weak-but-explicit とする | 記録された回答が2つ、またはそこで止めることへのユーザーの同意 |

| 5 | 記録をフィールドを判定するステップへ引き渡す | そのステップから更新された記録が返っている |

保存プロトコル

| 保持先 | 保持する内容 | 書き込む主体 |

|-------|------------|------------|

| 判定ステップの出力に含まれる収束記録 | 全フィールドとその readiness ラベル | フィールドを判定したステップ |

| PRD の 成功基準 と Future / Out of Scope | outcome、および origin を user とした nonGoals と speculative 要件 | PRD を所有するエージェント |

| Design Doc の Requirement Convergence | PRD がない場合は上と同じ内容。加えて weak-but-explicit のまま残ったフィールドは常にここへ記録する | Design Doc を所有するエージェント |

どちらのドキュメントも生成しないフローでは、記録を自身のコンテキストで次のステップへ運ぶ。

参照プロトコル（下流の消費者向け）

• プロンプトから収束記録を読む。
• nonGoals と speculative 要件を、今回の変更から除外されたものとして扱う。speculative の項目は、ユーザーが desired-future へ格上げしたときに初めて作る対象になる。
• weak-but-explicit のフィールドは、確定した判断ではなく記録された未解決の論点として扱い、作業がその解決に依存する場合はエスカレーションする。

品質チェックリスト

• [ ] 質問の前にスコープの事実を提示した
• [ ] nonGoals がユーザーから出たもの、または除外すべきものはないとユーザーが述べたものになっている
• [ ] 該当する全フィールドが ready、またはユーザーの同意による weak-but-explicit になっている

References

• references/criteria.md — フィールドごとの判断ルール、コストの入力、チャレンジの強度、手段すり替えの検出