design-interviewlisted

# 設計インタビュー ユーザーの設計書・計画を、実装に入る前に徹底的に問い詰め、認識のズレをなくす。 ## 進め方 **大原則(no-guess)**: 設計書の空欄・曖昧箇所を、もっともらしい内容で 勝手に埋めない。埋める内容は必ずユーザーへの質問から得る。 ユーザーが「お任せする」と明示した場合のみ、推奨案を提示して確認を取ってから 記入する(確認なしの記入は禁止)。 1. 作業スコープ直下に CONTEXT.md があれば先に読み、用語の解釈をそれに合わせる。 2. 対象の設計書(通常は docs/drafts/ 配下)を読み込む。指定がなければ、直近の 会話や docs/drafts/ の中から対象を確認する。 3. 決定木を1枝ずつ辿る。各分岐で、未確定な判断を1つ特定する。 4. 未確定な判断を探すとき、以下の曖昧性タクソノミーを網羅の基準にする。 全カテゴリについて「設計書に答えが書いてあるか」を確認し、 書かれていないカテゴリから質問を作る。 | カテゴリ | 必ず確認すること | |----------|-----------------| | 境界値 | 空・ゼロ・最大・重複・NaN/Inf の入力のときの挙動 | | 例外系 | 処理が失敗したとき何をするか(リトライ / スキップ / 停止 / ログのみ) | | 状態・順序 | 途中で中断されたらどうなるか。2回実行されたら(冪等性)。実行順序の前提 | | データ | 入力の形状・型・値域・欠損の扱い。出力の形式 | | 非機能 | 速度・メモリの許容値。「速く」「軽く」は必ず数値化する | | スコープ境界 | やらないこと(non-goals)。この設計書が解決しない問題の明文化 | 研究系の設計書(実験・モデル変更を含む)では、さらに以下も確認する。 | カテゴリ | 必ず確認すること | |----------|-----------------| | 仮説 | この変更で何がどう良くなると考えているか(1文) | | 変数 | 変えるもの(独立変数)と測るもの(従属変数) | | ベースライン | 何と比較するか。比較条件は揃っているか | | 成功基準 | 数値でいくつ以上/以下なら成功か(例: MAE がベースライン比 0.5 以上改善) | | 再現性 | seed・データ分���・環境の固定方法 | 設計書の規模上あきらかに該当しないカテゴリは「(N/A: 理由)」と記録して次へ進んで よい(全カテゴリへの機械的な質問はしない。spec-checklist の規模に応じた判定と同じ基準)。 5. 質問は必ず1問ずつ出す。複数の質問を同時に出さない。 6. 各質問には、こちらの推奨案を添える(例:「Aが良いと考えます、理由は〜」)。 7. コードや既存ドキュメントを読めば答えが分かる質問は、ユーザーに聞かず 先に調査する。 8. ユーザーの回答を待ってから次の質問に進む。 9. すべての分岐が解消されたら、決定内容を設計書(docs/drafts/配下)に反映して 更新する。このとき「## 受け入れ条件」セクションを必須で生成する(無ければ新規作成、 あれば決定事項を反映して更新)。全ての決定を、以下の6列を持つ Markdown テーブルの 検証可能な要件に変換する(このテーブルなしでは P