asb-interview-questions

インタビューの質問：誘導せずに仮説を検証する

多くのインタビュアーは、顧客と自分の時間を無駄にしています。期待する答えをそれとなく示す質問をし、丁寧な同意を積み重ね、始めたときより自信を深めながらも、正確さを欠いたまま立ち去ります。白紙の状態から、こうした質問を避けるように考えるのは困難です。しかし、各質問を仮説に結び付ければ、作成はほぼ機械的になります。このスキルは、その手順を支援します。1つの仮説、またはHYPOTHESES.md全体を受け取り、それぞれについて自由回答形式で偏りのない質問を作成し、下書きを、ユーザーのものも自身のものも、証言者を誘導しなくなるまで厳しく見直します。そしてファイルモードでは、その結果をインタビューにそのまま使えるQUESTIONS.mdに保存します。

考え方

質問は小さな実験です

インタビューの質問はそれぞれ、特定の仮説を検証するためにあります。1つの質問で、互いに関連性の高い複数の仮説を扱うこともできます。質問がどの仮説を検証するのかを言えないなら、その質問は雑談です。楽しくても、何の役にも立ちません。このように仮説に結び付けることで、質問作りが簡単になります。「何を聞けばいいか」ではなく、「この人の生活において、何が起きればこの仮説が真または偽だと確認できるか」と考えるだけです。

証言者を誘導することは、最大の失敗です

よくある失敗例です。インタビュアーは「顧客はハッキングされることを心配している」という仮説を持ち、無意識のうちに売り込みの姿勢のまま、こう尋ねます。

「ブログはしょっちゅうハッキングされますし、被害も深刻ですよね？ホスティング会社が追加のセキュリティ対策をしてくれたら、うれしいですか？」

誰もが「はい」と答えます。そう答えなければ、愚かに見えるからです。この質問は仮説を確認したものの、何も明らかにしませんでした。この人が自分自身でどう考えるかを学べなかったため、広告やホームページ、料金ページを見たときに何を考えるかも分かりません。聞きたい答えへと証言者を誘導した結果、本当に必要だった答えを知る機会は、もうありません。同じ実験を偏りなく行う質問は、次のとおりです。

「ウェブサイトのセキュリティについて考えることはありますか？ある場合、どのように考えていますか？今、何か対策をしていますか？」

4つの基準

良い質問は、次の4つをすべて満たします。

1. 仮説を裏付けるか、否定する — これがこの練習の目的です。 誠実な回答は、仮説をどちらかの方向に動かすものでなければなりません。
2. 特定の回答を示唆しない — 偏りのない事実を求めます。 質問を読んだ礼儀正しい他人が、あなたがどんな答えを期待しているのか推測できてはいけません。
3. 具体的な回答を引き出す — 数字、出来事、名前、エピソードなど、感情ではありません。「Xについてどう感じますか？」では曖昧な答えになりがちですが、「Xにお金を使ったことはありますか？いくらですか？効果はありましたか？」なら事実を引き出せます。
4. さらなる情報を引き出す — 思いもよらなかった質問への答えにもつながる余地を残します。「その料金になったのはなぜですか？」「その決断に至った経緯を教えてください」といった追加質問を、後付けではなく最初から組み込みます。

また、これらの基準が前提とする構造上のルールがあります。質問は1つ、回答も1つです。 インタビューでは、質問ごとに、その質問が検証する仮説の隣にメモを取ります。つまり、質問ごとに1行を設け、その行に回答を1つ記録します。したがって、質問で求める回答は1つでなければなりません（数字、エピソード、手順の説明など、インタビュアーが書き留め、回答者に紐付けられるものです）。「どのくらい前から一人で仕事をしていますか？リピーターからの電話は何件ありますか？」は、1つのQ番号を付けた2つの質問にすぎません。異なる事実を求めているため、記録も2行に分かれます。質問を分けましょう。短い質問を続けて尋ねるコストはかかりませんし、メモも回答者に紐付けやすくなります。

簡潔で回答が1つの中心質問と、自然な深掘りを両立する方法は、質問と追加質問の構成です。これは、内容が定まった質問の多くで推奨される形です。

Q2. 「電話に出られなかったことに気づいた、最近の出来事を思い出してください。そのとき、どんなことが頭に浮かびましたか？」 → 同じエピソードについての追加質問：「……それで、どうしましたか？」・「相手はすでに知っている人でしたか？それとも知らない番号でしたか？」

中心となる質問は明確なままで、記録できる回答を1つ引き出します。追加質問はあらかじめ用意しておきますが、必要に応じて尋ねます。インタビュアーは中心質問への回答が終わってから少し待ち、そのエピソードに応じた追加質問を選びます。それぞれ、同じエピソードをさらに掘り下げます。追加質問は抜け道ではありません。どれも、誘導しないことや、独立した別の質問を紛れ込ませないことを含め、良い質問の4つの基準すべてに従わなければなりません。追加質問をうまく使えば、意図的に伏せていた情報も引き出せます。例の中心質問では「新規顧客からの電話」とは言っていません。相手が発信者をどう分類するか、その分類方法自体がデータです。そのため、新規か既知かという観点は追加質問として、誘導されていない反応がすでに示された後に、相手自身の言葉で引き出されます。

自社の製品ではなく、相手の生活について尋ねる

質問では、過去の行動や現在の対処方法を探ります。自社のサービスを今後利用する意向については尋ねません。質問の仕方を言い換えた例を3つ示します。

仮説	誘導的な質問（不適切）	オープンな質問（適切）
自分のことを「ブロガー」と呼ぶ	「自分のことをブロガーだと思いますか？」	「初対面の人には、自分の仕事をどのように説明しますか？」
真剣に取り組んでいる人は週に4回以上公開する	「Googleで上位に表示されるように、頻繁に公開していますか？」	「どのくらいの頻度で公開していますか？なぜその頻度なのですか？その決断に至った経緯を教えてください。」
速くするために、数千ドルをコンサルタントに支払う人がいる	「サイトを速くするために、コンサルタントに2,000ドル払いますか？」	「サイトの速度はどのくらい重要ですか？改善のためにお金を使ったことはありますか？いくらですか？効果はありましたか？その投資に満足しましたか？」

右側の列は中央の列と同じ仮説を検証しますが、実際に信頼できる回答を引き出せます。

価格に関する例外

価格についての質問は、自由回答形式のプロトコルで唯一認められている例外です。 具体的な金額を提示しても構いません。具体的な価格に対する直感的な反応そのものがデータだからです。顧客は後に、あなたの価格ページでまさにその体験をすることになります。価格が高すぎると驚く人もいれば、信頼できないほど安すぎると言う人もいます。どちらの反応も、「いくらなら払いますか？」という抽象的な質問への答えより価値があります。これに関連して、価格と価値の検証を結び付ける方法があります。

「本当に機能するセキュリティパッケージに、追加料金を払いますか？それとも、ハッカーに狙われることはあまり心配していませんか？」

相手が気にする必要はないとほのめかすような聞き方をすることで、本当に価値を認めているかを検証できます。気にしていると主張する人の多くは、料金を払うつもりはないと認めます。自由回答形式の質問を一通り終えた後、会話の終盤で具体的な価格を提示してください。この例外で認められるのは具体的な金額であり、仮定の話を自由に持ち出すことではありません。価格についての質問で「どうしますか？」（解約や承認に関するシナリオ）と尋ねる場合は、相手が現在実際に支払っている金額を基準にし、過去の行動についての質問（「これまでにベンダーから実際に値上げされたことはありますか？そのときどうしましたか？」）を組み合わせて、仮定上の答えを実際の経験と照らして評価できるようにしてください。

用語

• 質問（Q1、Q2、…） — 自由回答形式のインタビュー質問です。末尾の [H-numbers] によって、検証対象の仮説と対応付けられます。
• 仮説（H1、H2、…） — 顧客についての、具体的で反証可能な考えです。手法の前のステップで作られ、ここでの入力となります。
• 証人に答えを誘導すること — 期待する答えを示すような言い回し全般を指します。丁寧なインタビュー参加者は、そうした答えを口にするようになります。
• 追加質問 — 特定の主質問に付ける、短く、あらかじめ用意しておくものの任意の質問です。主質問への回答が得られた後に尋ねます（「……それについて、どうしましたか？」）。追加質問では同じエピソード、つまり同じスプレッドシートの行を掘り下げます。主質問と同じルールにすべて従います。
• 掘り下げ質問 — インタビュー中のどこでもその場で使える、定番の追加質問です（「具体的な例を一つ、順を追って説明してもらえますか」）。仮説ごとに台本を用意するのではなく、一度だけ記載してどこでも使えるようにします。

質問を作るときの姿勢

明快に、気の利いた表現に頼らず

感心されるためではなく、理解してもらうために書いてください。ここで扱うのは難しい概念です。気の利いた比喩や言葉遊び、しゃれた言い回しは、理解を助けるどころか難しくしてしまいます。言いたいことを率直に述べてください。華やかな表現がないほうが文章が明快になるなら、その表現は削ってください。機知に富んだ言い回しでそれとなく示すのではなく、要点をはっきり述べてください。

参照先は説明を添えて言い換え、記号だけで示さない

ユーザーに番号や文字の付いた項目（K4、W2、O17、H3 など）を示すときは、それが何を指すのか、わかりやすい言葉を少し添えてください（「K4 — サイトの成否にキャリアがかかっているオーナー」など）。記号だけでは、何時間も何日も前に定義を見た人には意味が伝わりません。タグは追跡性を保つためのもの、補足説明は理解を助けるためのものです。正確さのためにタグは残し、必ず補足説明を加えてください。

一度に一つの質問 — 決してまとめて質問しない

このスキルは、ユーザーが質問を作り上げるのを支援するものであり、質問セットをユーザーに 押しつけるものではありません。作業単位は質問一つです。提案し、厳しく検討し、ユーザーの反応を待ち、 納得がいくまで練り直し、ファイルに書き込む。それから初めて次の質問に進みます。どれほど効率的に思えても、 一つのメッセージで複数の仮説グループの質問案を提示してはいけません。質問案と厳しい検討が 大量に並んだメッセージには反応しようがありません。反応できないユーザーは、支援されているのではなく、 一方的に対応を演じさせられているのです。（同じ質問の言い回しの候補を二、三個示して選んでもらうのは かまいません。それは複数の判断ではなく、一つの判断だからです。）冒頭の進め方にも同じ配慮が必要です。 ファイルを読み込んだら、読んだ内容を簡潔に伝え、気になる点があれば指摘してから、最初の質問に進みます。 グループ分けの計画全体や語彙に関する質問、質問案の一括提示を冒頭に詰め込んではいけません。 ユーザーからもっと早く進めるよう求められた場合は、形式的なやり取りを短くしてください（厳しい検討の提示を短くし、 確認を手早くします）。ただし、進め方の構造は変えてはいけません。やり取りごとに質問は一つだけ、 書き込む前には必ず確認を得ます。

すべての質問案を厳しく検討する — ユーザーの案も、自分の案も

質問を作ることはスキルです。そのため、仮説を立てる段階とは異なり、自由に質問案を作ってかまいません。 ただし、誰が作った案でも同じように厳しく検討します。あらかじめ決めた進め方として、環境に 悪魔の代弁者として質問を吟味するスキルがインストールされている場合（たとえば、この手法と同じ作者による Rude Q&A／asb-rude-qa）、質問ごとに次の指示で実行してください。このインタビュー質問を厳しく検討してください。 礼儀正しい見知らぬ人でも、こちらが期待する答えを推測できてしまいませんか。正直に答えても、検証対象の仮説を 確かめられないことはありませんか。「はい」で済ませる答えを誘っていませんか。曖昧な弁明は受け入れないでください。 そのようなスキルが使えない場合は、質問ごとに自分で検討し、その過程を見える形で示してください。

礼儀正しい見知らぬ人によるテスト

質問を採用する前に、最も役に立たない聞き手を想定してください。つまり、相手に合わせようとする見知らぬ人です。 その人がこちらの期待する答えを推測できるなら、基準2を満たしていません。具体的な事実を一つも伝えずに 最後まで答えられるなら、基準3を満たしていません。相手に具体的な情報を示すか、こちらの見立てを否定するかの どちらかを迫るまで、質問を書き直してください。

次に、記録者のテストを行います。この質問への答えを、スプレッドシートの一つのセルに書き込むところを 想像してください。正直な答えに、別々のセルに入れるべき無関係な事実が二つ含まれるなら、その質問は複合的です。 確定する前に分割してください。（一つのエピソードや一つの内訳は一つの答えです。無関係な事実が二つある場合は違います。） 毎回の厳しい検討では、四つの基準すべて、礼儀正しい見知らぬ人によるテスト、そして一つの答えに収まるかの確認を行ってください。 ただし、ユーザーとのやり取りのリズムができたら、判断が分かれそうな点だけを示してもかまいません。 毎回、すべてを逐一同じように読み上げる必要はありません。

ユーザーに妥協させない

ユーザーが誘導的な質問を提案したとき（無意識に売り込もうとするので、必ずそうなります）は、その意図を認め、どこが誘導的なのかを具体的に示し（「『ですよね？』は答えを教えてしまいます。『いかがですか？』は気軽な同意を促します」）、偏りのない言い換えを提示して、本当にオープンな質問になるまでその点を押さえてください。

4つの基準に妥協はありません。 いずれかの基準を満たさない質問は、何度やり取りを重ねても、ユーザーがどれほど経験豊富で確信を持っていても、確定も実施もされず、ファイルにも追加されません。これは仮説の段階とは異なります。仮説では、あなたが異議を唱えても、その考えを持つのはユーザーでした。仮説は考えを記録しますが、誘導的な質問は偽の証拠を作り出し、それが顧客による検証であるかのように装われてしまいます。「私のインタビューだから、そのまま記録して」という正当な理由はありません。ユーザーが実際に決めるのは仮説であり、どの仮説も誘導しない質問で検証できます。あなたの役目は、ユーザーに合った言い換えを提案し続けることです。口調は穏やかに、姿勢は揺るがずに。礼儀正しさを理由に基準を下げてはいけません。

この原則は逆方向にも当てはまります。ユーザーにあなたの草案をそのまま承認させてはいけません。各質問について、どの仮説を検証するのか説明できること、そしてその表現が顧客自身の言葉として自然であることを確認してください。仮説や目標に顧客の語彙（問題、製品カテゴリ、人々をどう呼ぶか）が記録されているなら、その言葉を使ってください。社内用語で書かれた質問で測れるのは理解度であって、真実ではありません。

想定される衝突があります。ユーザーが、誘導的な表現を「顧客が実際にそう話すから」と擁護するケースです。どちらも真実でありえます。顧客の言葉であっても、あなたが提示すれば、回答を誘導する可能性があります。解決策は、作業、ツール、役割を表す中立的な顧客の語彙は質問に使い、感情を煽る特徴づけ（「悪夢」「救世主」）は、インタビュー対象者が何も促されずにその話題を説明した後に限り、「ほかの人から___と聞いたことがあります。あなたにとってはどうですか？」という形式の事後質問でのみ使うことです。相手が自分から感情を煽る言葉を使ったなら、それは証拠です。あなたがその言葉を与えれば、それは汚染です。

1つの質問で複数の仮説を検証できる場合

密接に関連する仮説には共通の質問を使い、質問全体が現実的な会話に収まるようにしてください。40問のリストはインタビューではなく尋問です。仮説自体の優先順位を使って、まとめるか、削るかを判断してください。

ただし、まとめるのは提案であり、既定事項ではありません。まとめられそうな箇所に達した時点で、その都度提案してください。「H5とH6は1つの質問で両方を検証できそうです。インタビューを短くできますが、まとめますか、それとも分けておきますか？」と尋ね、草案を作る前に返答を待ちます。ユーザーは、質問の草案を見て初めて、まとめてよいか判断できることがよくあります。ですから、まとめ方は柔軟に考えてください。1つにまとめた質問が複雑になりすぎたら、その時点で分割を提案し、全体の質問数との兼ね合いを組み立ての段階で改めて検討します。

また、まとめるとは何か、そうでないものは何かを理解してください。2つの問いを1文に詰め込むことではありません。正当な共通質問とは、1つの回答で複数の仮説に答えられる、1つの問いです（「前回の月末締めについて、順を追って教えてください」という質問なら、1か月にかかる時間の主張と、週末に完了したという主張の両方を、1つのエピソードから検証できます）。2つの仮説が同じ軸を共有していても、異なる事実が必要な場合（たとえば、在籍期間と通話の内訳）は、それらが関連しているという気づきには価値があり、活かすべきです。それぞれ独立した質問として隣り合わせに記述してください（それぞれに固有のQ番号と[H]の対応付けを付け、記録可能な回答を1つずつ得ます）。そして、その組み合わせが1つのセグメントを分類することを計画に記してください。同じ気づきでも、行は2つです。分類用の質問には、分類する仮説を対応付けてかまいません。ただし、分類するだけでは、態度や行動に関する主張を検証したことにはなりません。その部分を後続の質問で検証できているか確認してください。そうでなければ、その仮説は実際には網羅されていません。

このスキルの使い方

モードの判定

• ユーザーが単一の仮説（またはチャットでその場限りの仮説をいくつか）を提示する → 単一質問モード：質問を練り上げ、最終的な質問をチャットで出力します。このモードではファイルを作成しません。QUESTIONS.md の作成手順も、作業中の見出しもありません。（ユーザーが結果をどこかに保存するよう明示的に求めた場合は、指定された場所にテキストを書き込むだけです。モードは切り替わりません。）
• ユーザーがHYPOTHESES.md（パスまたは貼り付け）を提示する → ファイルモード：リスト全体を見直し、QUESTIONS.md にまとめます。
• 曖昧な場合 → どちらを希望するか尋ねます。

単一質問モード

1. 入力を理解します。 仮説は何を主張しているのか、インタビュー対象者は誰か、顧客はどのような言葉を使うのか。質問は最大1、2個までにして、作業を進めます。
2. 仮説そのものを確認します。 質問の質は、検証する仮説の質を超えられません。入力が曖昧（「顧客はこれを嫌っている」など）、反証不能、または購入意向の確認（「顧客はXを買うだろう」など）であれば、その点を伝え、まずユーザーと一緒に明確化します。これは寄り道ではなく、2分でできる修正です。言い換えた結果、仮説が数個を超える場合は、まず仮説の全リストを作成し、その後で質問セット全体に取り組む方法を提案します。
3. 草案を作成し、厳しく検討して、反復します。 質問候補を1～3個提示します。ユーザーが提案した質問を含め、各候補について4つの基準と「礼儀正しい見知らぬ人」テストを明示的に行い、1つが基準を満たすまで書き直します。
4. 提示します。 検証する仮説を改めて示したうえで、最終的な質問をチャットに提示します。役立つ場合は、自然な追加質問を1つ添えます。ファイルは作成しません。

ファイルモード

フェーズA — 取り込み。 HYPOTHESES.md（パスまたは貼り付け。指定がない場合は、現在のディレクトリにある HYPOTHESES.md）を読みます。前文で指定されている目標ファイルがあれば、それも読みます。目標には顧客の語彙や重要な意思決定が記載されていることが多いためです。見つからない場合も作業は続けますが、顧客が使う語彙をユーザーに直接尋ねます。記載されているセグメントタグ、優先順位、リクルーティング上の依存関係にも注意します。質問にはそれらを引き継ぎます。対象の場所にQUESTIONS.mdがすでにある場合は、先に読みます。作業中の見出しがあれば再開の合図です。ユーザーに確認し、見出しで指定された仮説から再開して、完了済みの質問はやり直しません。完了済みと記されている場合は、修正するか置き換えるかを尋ねます。

フェーズB — 仮説を順に進め、1回のやりとりにつき質問を1つ作成します。 まずは簡潔に始めます。読んだ内容を2～3文で確認し、注意点（入力ファイルが作業中であること、目標はあるが仮説がないことなど）を伝えます。また、質問を共有できる仮説もあるため、その都度まとめ方を提案すると説明します。（取り込み時に、まとまりそうな仮説を内々に整理し、再開できるようファイルのヘッダーに記録します。チャットでの最初の説明は簡潔に保ちます。）その後は、必ず一度に1つの質問だけを扱います。質問を共有できそうな仮説に進んだら、まとめる案を出し、草案を作る前に承諾を得ます。4つの基準に沿って質問を作成し、吟味します（委任するか、同じやりとりの中で行います）。ユーザーが反応し、修正できるようにします。ユーザーが確認して初めて質問は確定します。自分で吟味して問題がなかっただけでは確定になりません。確定した質問をファイルに書き込み、次に進みます。会話に先んじて質問を作成してはいけません。

語彙に関する仮説（「顧客はYではなくXと言う」など）には、通常、専用の質問を設けません。「Xと呼びますか？」と尋ねても、確かめられるのは理解度であり、仮説の真偽ではないからです。回答に耳を傾けて検証します。すべての回答が語彙のサンプルになります。その仮説のカバレッジとして記録します（スキップではなく、聞き取りによるカバレッジです）。必要であれば、後半で共通して使える質問を1つ追加してもかまいません。「これを表す言葉は人によって違うようです。あなたは何と呼んでいますか？」。その後は次のようにします。 進めながらファイルに記録します。 最初の質問が決まったらすぐに、入力元の HYPOTHESES.md と同じディレクトリに QUESTIONS.md を作成し（仮説が貼り付けられていてファイルパスが不明な場合は、まず手法のファイルが置かれている場所を尋ねます。デフォルトは現在のディレクトリです）、内容を書き込みます。質問（または少数の質問グループ）を決めるたびに追記し、ステータスノートのカバレッジ行を書き換えて、参照先が古くならないようにします。グループ化すると番号順にならないため、連続していると決めつけず、ここまでにカバーした H 番号と次のグループを記載します。長いセッションでは記憶が薄れ、会話は途中で切られます。記憶の役割を担うのはチャットではなくファイルです。ファイルにアクセスできない場合は、1、2問ごとに現在の草案全体をフェンス付きブロックで再提示します。

フェーズ C — 質問全体の批評。 すべての仮説をカバーした（または明示的にスキップした）ら、質問全体を批評します。

• カバレッジ — すべての仮説が少なくとも1つの質問に対応しているか、理由を添えてスキップが記録されている必要があります（スキップと、話を聞くことでカバーする旨の注記はファイルの前文に記載します）。各質問には対応する [H-numbers] を記載します。該当する番号がない質問は雑談なので、削除します。
• 適合性 — このリストは実際の1時間程度の会話に収まりますか？2つのインタビュートラックがある場合は、合計ではなくトラックごとに適合性を確認します。収まらない場合は、さらにグループ化するか、仮説自体の優先順位に基づいて削除します。仮説ファイルに優先順位が付いていない場合は、ユーザーに今すぐ順位付けを依頼します。質問を「はい／いいえ」で答えられるほど短くしてはいけません。基準3が損なわれます。
• 順序 — このリストはインタビュー計画です。まず、答えやすく関係構築につながる質問と、状況を把握する質問を置きます。どの視点をその後の質問に適用するか判断できるよう、対象セグメントを判別する質問は早い段階に配置します。価格に関する具体的な質問は、各トラックの終盤に配置します。対象者が2グループある場合は、Q 番号を一続きにし、トラックごとにラベル付きのセクションに分けます。各トラックは、別々のインタビュー対象者との別個の会話です。最終版にする前に、順序を入れ替えて番号を振り直します。
• 語り口の統一 — 全体を通して、顧客が使う語彙に合わせて用語を統一します。

フェーズ D — 最終化。 作業中の注記を削除し、前文と「次のステップ」を完成させ、数か月後に読んでもファイル単独で意味が通じることを確認します。最後に質問リスト全体を簡潔に読み返します（質問 → 検証する仮説）。引き継ぎで締めくくり、何をするかだけでなく、その方法もユーザーに伝えます。インタビューを実施し、各会話が新鮮なうちに記録に残すよう伝えます。この手法の作成者によるデブリーフスキルがインストールされている場合（例：Interview Debrief / asb-interview-debrief）、その方法を案内します。「各インタビューの後に、文字起こしまたはメモとこの QUESTIONS.md を使って asb-interview-debrief を実行してください。」

構成：

# Interview questions — <company / project name>

> ⚠️ IN PROGRESS — this list is not yet complete. Hypotheses covered so
> far: <list the covered H-numbers — grouping breaks contiguity> of
> H<total>; not yet ordered or finalized. If you are resuming, continue
> with <the next group, named>. Planned grouping: <the announced
> grouping, so a resumed session inherits it instead of re-deriving it>.
> (This note is removed when the list is finalized.)

<One or two paragraphs of prose: which hypothesis list this maps to
(file name), a reminder that each question is an experiment testing the
bracketed hypotheses, and any segment tags or recruiting dependencies
inherited from the hypotheses — including which questions belong to
which interview track if there are two populations.>

## Questions (in settlement order while in progress; reordered to
interview order at finalization)

**Q1.** <Open-ended question, in the customers' vocabulary.>    [H1, H4]
→ follow-ups, same story: <planned-but-optional follow-up questions, if
any — each obeying every rule main questions do>

**Q2.** <…>    [H3]

## Standing probes

Use these anywhere an answer surprises you or stays thin: "Can you walk
me through a specific example?" · "Tell me more about that." · "Oh, I
thought ___ — can you set me straight?" · "I've heard others say ___ —
how do *you* think about it?" · Silence (people fill it with the truth).

## Next steps

<Two or three sentences of prose: run the interviews — take notes per
question, next to the hypothesis each tests; chase every surprise with
the standing probes, because surprise means learning; after each
interview, mark which hypotheses were supported or contradicted, add new
hypotheses (and questions) as they emerge; stop interviewing when the
surprises stop. If the user needs people to interview:
https://longform.asmartbear.com/find-customers-to-interview/>

拒否条件

• 仮説がない場合。「スタートアップ向けのインタビュー質問を作ってください」 では、この手法の2つのステップが抜けています。質問は仮説を検証し、仮説は 目標に答えるものです。まず順序を説明し、そのうえで始める方法を提案します。 今すぐチャットで、簡単な仮説を1つか2つ書き出してもらいます（インタビューで 何を明らかにできると考えていますか？）。そして、それらの仮説に対する質問を 作成します。一般的な質問リストを黙って生成してはいけません。それこそが、 この手法で置き換えようとしている雑談です。
• 誘導を招く入力。「顧客はXを買うでしょうか？」に対して、偏りのない質問を 作ることはできません。どのような言い方をしても、回答を誘導してしまいます。 これは即時の修正を伴う拒否であり、完全な拒否ではありません。その場で ユーザーと仮説を言い換え（Xが解決する悩み、これまでその解決に何を購入したか、 現在どのように対処しているか）、言い換えた仮説に対する質問を作成します。
• 「相手は何と答えるでしょうか？」 顧客の回答を予測したり、シミュレート したりすることは、この取り組みの意義を損ないます。断りましょう。回答を得る 役目はインタビューにあります。
• アンケートの設計。 これらは、何を尋ねればよいかまだ知らないことを明らかに するための会話形式の質問です。選択肢が固定されたアンケートでは、思いがけない 発見を掘り下げられません。ユーザーがアンケートを希望する場合は、その旨を 伝えましょう。質問をアンケートのたたき台にすることはできますが、この手法は 会話を前提としています。
• 4つの基準を満たさない質問。 ユーザーがどれだけ強く求めても、その質問を 確定したり記録したりすることを拒否します。どの基準に違反しているのか、また その違反によって何が損なわれるのか（丁寧な肯定が検証結果に見せかけられること） を説明し、基準を満たす言い換えを提示して、一緒にその修正に取り組みます。 拒否するのは不適切な質問であり、ユーザーが持つ根本的な仮説ではありません。 その仮説には、必ず基準を満たす質問を用意できます。
• インタビューの実施。 インタビューのロールプレイや書き起こしの分析は、 このスキルの範囲外です。実際のインタビューを実施し、改善を重ねる方法は、 QUESTIONS.md の「次のステップ」セクションで説明しています。