interview-me

私にインタビューする

概要

人が求めるものと、実際に欲しいものは異なります。「ダッシュボードが欲しい」と言うのは、ダッシュボードが問題を解決するからではなく、そう頼むものだからです。「もっと速くして」と言っても、目標とする数値は示されません。

この食い違いを見つけるのに最もコストがかからないのは、計画も仕様書もコードもまだ存在しない段階です。作り始めてしまうと、方針転換には実際にコストがかかり、ユーザーは間違ったものを「これで十分」と納得させようとします。その不一致は固定化されます。

このスキルは、コストが発生する前にその食い違いを解消します。他の Define フェーズのスキルは、すでに求めるものがおおむねわかっていることを前提としています。idea-refine はアイデアからバリエーションを生み出し、spec-driven-development は要件を書き出し、doubt-driven-development は計画を立てた後にその計画を厳しく検証します。Interview-me はそれらより前の段階で、ユーザーが答える前にその答えを予測できるようになるまで、最善の推測を添えて一度に一つずつ質問します。

使用するタイミング

次の場合にこのスキルを適用します。

• 依頼に、ユーザーが誰なのか、なぜそれを望むのか、成功とはどのような状態なのか、拘束力のある制約は何か、のいずれかが欠けている
• 依頼が具体的ではなく一般的で（「X を作って」「もっと速くして」など）、推測せずにその慣例的な表現を掘り下げられない
• 表面化させていない前提から始めようとしている
• 妥当な価値観が二つあり、互いに相反しているのに、ユーザーがどちらを優先するか話していない（シンプルさと柔軟性、コストと速度など）
• ユーザーが「私にインタビューして」「厳しく質問して」「始める前に、本当にこれでいいか確認して」「私の考えを厳しく検証して」と明示的に求めている

使用しない場合：

• 依頼が明確で、それだけで完結している（「この変数名を変更して」「この誤字を修正して」など）
• ユーザーが検証よりも速度を優先すると明示している
• 純粋な情報提供の依頼（「X はどのように動作するか？」「このコードは何をするか？」など）
• 機械的な操作（名前変更、書式設定、ファイルの移動）
• すでに信頼度が 95% 以上ある場合。そうではないと思い込む前に、以下の停止条件を読み直してください

読み込み時の制約

このスキルには、ユーザーが対話に応じ、すぐに返答できる環境が必要です。CI パイプライン、スケジュール実行、/loop、自律ループなど、対話できない状況では実行しないでください。そのような状況で依頼の内容が不十分な場合は、推測せず、ユーザーに確認が必要な阻害要因として伝えてください。

手順

ステップ 1：信頼度を数値で示して仮説を立てる

何かを尋ねる前に、ユーザーが何を求めているかについて、現時点での最善の解釈を一文にまとめ、正直な信頼度（0～100%）を添えてください。

HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like

この数値を示すことで、正直さが求められます。数値を高くしたのに、次に尋ねる三つの質問に対するユーザーの反応を実際には予測できないなら、その数値は誤っています。根拠を示せる信頼度から始めてください。

信頼度が約 70% 未満の場合は、同じ行に簡潔な理由を添えてください。まだ解決していないことや不足している情報を示します。これにより、インタビューで明らかにすべきことがユーザーに伝わり、数値が曖昧な合図になるのを防げます。

ステップ 2：推測を添えながら、一度に一つずつ質問する

形式：

Q: <one focused question>
GUESS: <your hypothesis for the answer, with the reasoning that produced it>

次の質問をする前に、ユーザーの反応を待ってください。

まとめてではなく、一度に一つずつ質問する理由：

• 仮説をリストに埋もれさせると、ユーザーはそれに対して反応できません
• まとめて質問すると、読み飛ばされやすく、表面的な回答になりがちです
• 三つ目の質問は最初の質問への回答によって変わることが多く、すべてを一度に尋ねると、間違った枠組みのまま話が進みます
• じっくり考えるためのユーザーの余力には限りがあります。一度に一つずつ使ってください

推測を添える理由：

• ユーザーは、ゼロから答えを考えるより、間違った推測に反応するほうが素早く対応できます
• 目に見える形で間違い得る仮説を示すことで、自分の考えに責任を持つことになり、正直さを保てます
• インタビューで明らかにするのは、あなた自身の前提だからです

ここでのリスクは、ユーザーが気を遣って、あなたの推測に同意してしまうことです。間違っていても構わないという姿勢をはっきり示し、ときにはユーザーが反論してくると予想される方向にあえて推測して、そうならないようにしてください。

ステップ 3：「望んでいること」と「望むべきだと思っていること」を聞き分ける

最も危険な回答は、ユーザーが本当に望んでいることではなく、思慮深い回答がどのように聞こえるかを語っている場合です。次のような点に注意してください。

• 具体性のないベストプラクティスの話に当てはめた回答（「スケーラブルにしたい」「クリーンアーキテクチャにしたい」など）
• 慣例に委ねる回答（「ほとんどのアプリと同じやり方」「標準的なアプローチ」など）
• 「たぶんそうすべきだと思います」「そうすることになっていると思います」「優れたエンジニアリングの実践ではそうなっています」のような言い回し
• 目標としてのバズワード — 具体的な成果ではなく、「モダン」「スケーラブル」「堅牢」が答えになっている場合

こうした回答があったら、次の質問をします。

「誰にも説明する必要がないとしたら、本当はどうしたいですか？」

この一つの質問が、それまでの五つの質問よりも役立つことはよくあります。

ステップ 4：ユーザー自身の言葉で意図を言い換える

確信が持てたら、ユーザーが何を望んでいると理解したかを書いて返します。簡潔に（5～8行）、できるだけユーザーの言葉を使い、行ごとに確認や修正ができる形にします。

Here's what I now think you want:

- Outcome:      <one line>
- User:         <one line — who benefits>
- Why now:      <one line — what changed>
- Success:      <one line — how we know it worked>
- Constraint:   <one line — the binding limit>
- Out of scope: <one line — what we're explicitly not doing>

Yes / no / refine?

「対象外」を含めることは必須です。認識のずれの半分は、何を作らないかについての暗黙の意見の不一致です。

ステップ 5：確認する — 「お任せします」ではなく、明確な「はい」

次に進む条件は、明確な「はい」です。次の回答は「はい」ではありません。

• 「最善だと思うようにしてください。」→ ユーザーは判断を委ねているため、確信度も95％には達していません。具体的な選択肢を二つ示して、選んでもらう形で聞き直します。
• 「よさそうです。」→ 曖昧です。「何か修正したい点はありますか？」と尋ねます。沈黙は確認ではありません。
• 「いいですね、始めましょう。」→ 丁寧に会話を終わらせようとしているだけで、賛同ではないことがよくあります。同じように聞き返します。
• 沈黙のあとに「では始めましょう。」→ ユーザーは認識をすり合わせたのではなく、質問への回答を諦めています。立ち止まり、何か見落としていないか尋ねます。

ユーザーが修正したら、その内容を反映して言い直します。明確な「はい」が得られるまで繰り返します。

ステップ 6：最終ターンと停止ルール（重要）

ユーザーが意図の記述を明確な「はい」で確認したら：

1. 確認済みの意図の記述を提示します。
2. 次のステップの選択肢を提示します（docs/intent/[topic].md への保存、spec-driven-development を使った仕様書の作成、または仕様書作成後のタスク計画への移行を提案します）。
3. そのターンをただちに終了します。 このターンではツールを呼び出したり、後続作業を始めたりしてはいけません。次のステップを選べるよう、ユーザーに操作を戻します。

95％の確信に達したら停止する

次の質問に「はい」と答えられたら、完了です。

これから尋ねる三つの質問に対するユーザーの反応を予測できますか？

「はい」なら、認識は共有できています。質問を終え、内容を言い換えて提示します。「いいえ」なら、まだ終わりではありません。次の質問をします。

これは感覚的な判断ではなく、確認可能なテストです。また、下限もあります。何度かやり取りを重ねても反応を予測できない場合、それは質問し続ける理由ではなく、依頼内容に関する情報です。いったん止めて、ユーザーにこう伝えます。「X 個質問しましたが、まだ反応を予測できません。根本的な何かが欠けているようです。いったん立ち戻りますか？」

出力

このスキルの出力は、確認済みの意図の記述です。つまり、ステップ 4 で言い換えた内容をステップ 5 で明確な「はい」によって確認したものです。これが成果物です。仕様書、計画、タスクリストは後続の成果物であり、このスキルが作成する意図をもとに作られます。

ユーザーが意図を保存しておきたい場合（複数回のセッションにわたるプロジェクトや、別の共同作業者への引き継ぎなど）は、docs/intent/[topic].md への保存を提案します。保存するのは、ユーザーが確認した場合に限ります。

例

簡単な比較です。

interview-me を使わない場合：

User:  build me a dashboard for our metrics
Agent: <starts proposing chart libraries and layouts>

エージェントは、対象ユーザー、指標、「チーム向け」の意味、成功の定義を推測しています。これらはいずれも明示されていません。どの仮定も、あとからユーザーに「そういう意味ではありません」と言われる可能性があります。

interview-me を使う場合：

User: build me a dashboard for our metrics

Agent:
HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" came to mind because that's the conventional answer.
CONFIDENCE: ~30% — missing: who it's for, what "metrics" are, and what success looks like

Q:     When you say "how are we doing?", who's asking — you alone, the engineering team in standup, or up the chain (e.g., your manager, an exec, a board)?
GUESS: engineering team in standup, because "we" usually scopes that way and standups are where this question gets asked. If it's for execs the metrics and the framing change a lot.

User: It's actually for me. I keep losing track of which experiments are running and what their early signal looks like.

Agent:
Updated read: not a team dashboard at all. It's a personal experiment tracker. Confidence: ~60% — still missing: what "early signal" means and what done looks like.

Q:     Is the gap that you don't know which experiments exist, or that you can't see their results in one place?
GUESS: the second one. You have a list of experiments somewhere, but their results live in five different tools, and reconciling them by hand is what you're tired of.

User: First one actually. I literally don't have a list. They're spread across different docs.

Agent: <continues>

二つ質問した時点で、エージェントは本当の依頼が「ダッシュボード」ではなく「リスト」だと突き止めました。成果物も、範囲も、作業内容も異なります。ダッシュボードを作っていたら、間違いでした。

他のスキルとの連携

• idea-refine：後続のスキルです。確認した意図が「Xを実現したいけれど、範囲をどう決めればよいかわからない」であれば、明確になった意図をもとに案を出すため、idea-refine に引き継ぎます。
• spec-driven-development：後続のスキルです。確認した意図が具体的（「Y人のユーザー向けに、成功基準ZでXを実現したい」など）であれば、内容を書き起こすため、spec-driven-development に引き継ぎます。
• planning-and-task-breakdown：このスキルから見ると、仕様の後に続く2段階先のスキルです。
• doubt-driven-development：タイムライン上では反対側に位置します。Interview-me は意思決定前に意図を抽出し、doubt-driven は意思決定後に成果物をレビューします。どちらも認識のずれを見つけますが、タイミングが異なります。
• source-driven-development：直交するスキルです。Interview-me はユーザーが何を望んでいるかを明確にし、SDD はフレームワークに関する事実を検証します。両者は競合しません。

よくある自己正当化

自己正当化	実態
「依頼は十分明確だ」	今すぐユーザーが望む結果を1文で書けないなら、依頼は明確ではありません。判断する前にステップ1を実行してください。
「質問しすぎると相手の時間を無駄にする」	4～6個の的を絞った質問に費やす時間はわずかです。間違ったものを作るために費やす時間は膨大で、そのコストを負担するのはユーザーです。
「作りながら考えればいい」	コードができた後の切り替えコストは、今の10倍です。実装中に要件を探ると、手戻りが発生します。
「『あなたの好きなように』と言われたので、自分で決めればいい」	「あなたの好きなように」は委任であって、決定ではありません。具体的な選択肢を2つ示して、選んでもらう形で再度尋ねてください。
「選べるように、いくつか選択肢を提示すべきだ」	ユーザーが望むものを把握していて、トレードオフから選ぶ場合は、選択肢が役立ちます。まだ望むものがわからない場合は、選択肢を並べると探索範囲が広がります。質問をすれば、範囲を絞れます。
「自分の推測を添えると、相手を誘導してしまう」	誘導することが目的です。ゼロから考えてもらうより、案に反応してもらうほうが早く進みます。リスクは誘導ではなく、相手に迎合することです。明らかに間違っている可能性も受け入れる姿勢を示して、リスクを抑えてください。
「十分話した。もう理解できた」	試してみてください。次の3つの質問に対する相手の反応を予測できますか？できないなら、まだ理解できていません。
「ユーザーが『はい』と言ったので、これで終わりだ」	曖昧に言い直した後や、自由回答式の「よさそうですか？」の後に得た「はい」は、表面的な同意にすぎません。具体的に言い直して、もう一度確認してください。

危険信号

• 1つのメッセージで質問が3つ以上ある：質問をまとめているだけで、インタビューになっていません
• 仮説を添えずに質問する：調査をしているだけで、仮説を示していません
• 「一番よいと思うようにして」という回答を最終回答として受け入れる
• ユーザーが言い直しの内容を明示的に確認する前に、仕様、計画、タスクリストを作成する
• 意図の確認後、ターンを終えずにすぐツールを呼び出したり、後続の作業を始めたりする
• 「実際には何を望んでいますか？」ではなく、「ベストプラクティスは何ですか？」という形で質問する
• ユーザーが「スケーラブル」「クリーン」「モダン」といった洗練されているように聞こえる回答をし、それが本当に望んでいることなのか掘り下げずに受け入れる
• ユーザーの確信が目に見えて高まらないまま、3ラウンド以上続く：質問が的外れです。一歩戻って、問いの立て方を変えてください
• 理由を添えずに確信度を約70％未満とする：何が不足しているかわからなければ、ユーザーはその差を埋められません
• ユーザーが確認する前に意図のドキュメントを保存する（そのドキュメント自体が、ユーザーがしていない同意を示唆します）
• 言い直しで「対象外」の項目を省く（対象外について意見が食い違ったままになると、認識のずれが生じます）

検証

interview-me の適用後：

• 最初のターンで、確信度の数値を添えた明確な仮説が提示されていた
• 約70％未満の確信度の数値にはすべて、1行の理由（未解決の点や不足している点）が添えられていた
• 質問は1つずつ尋ねられ、それぞれにエージェントの推測が添えられていた
• ユーザーが洗練度や慣例を示すような回答をした場合、「正当化する必要がないとしたら、実際には何を望みますか？」という質問が少なくとも1回行われていた
• 具体的な内容（成果／ユーザー／なぜ今か／成功の定義／制約／対象外）がユーザーに伝え返されていた
• ユーザーが「あなたの好きにして」「よさそう」などの曖昧な返答や沈黙ではなく、明示的な「はい」で内容を承認していた
• 停止時点で、エージェントが次に尋ねる3つの質問への反応を予測できていた
• 明示的な承認を受けた後、ツールを呼び出したり後続作業を始めたりせず、直ちにターンを終了していた
• 後続スキル（idea-refine、spec-driven-development）への引き継ぎは、元の曖昧な依頼ではなく、確認済みの意図に沿ったものとして説明されていた