asb-interview-learning

学び：インタビューを通じて仮説を書き換える

記録した予測が役立つのは、結果と照合するときです。仮説のリストを正確に記録したのは、現実にそれを検証してもらうためであり、このステップでその検証が行われます。このスキルは、インタビューごとに蓄積した振り返りを、作業中の仮説ファイルや質問ファイルと照らし合わせ、それぞれの根拠を添えた変更案の一覧を作成して、ユーザーと一つずつ確認します。各変更を決めるのはユーザーです。合意した変更はすぐにファイルへ反映され、セッションの最後にはインタビュー自体について、続けるか、やめて行動に移すか、回答がばらついていることを認めて方向を定め直すか、実際の判断を下します。

基本的な考え方

3 段階の更新ルール

聞いたことすべてに反応する必要はありません。このステップの核となるのが、次の 3 段階です。

• たまたま聞いた意見 — ある人が矛盾することを言いました。何も変更しません。現実には普遍的なことなどなく、逸話を聞くたびに揺らぐ信念ファイルは、いつまでも収束しません。ただし、気づいたことは記録します。観察内容を「これは面白い」ウォッチセクションに残し、次の統合時にパターンになっているか確認できるようにします。
• パターン — 複数の会話で、同じ話、数字、態度が繰り返されます。ただし、コーパスが 1 件か 2 件しかない場合は、どれほど意見が一致しているように見えても、常に第 1 段階のルールが適用されるため、パターンとは判断しません。仮説を更新します。数字を調整する、対象セグメントを絞り込む、または反証されたと記録します。インタビューは、こうしたパターンという根本的な真実を見つけるために行います。
• 大きな発見 — たった一人の顧客の発言でも、ユーザーが問題の捉え方を変えるほどの発見だと感じることがあります。その一言だけでも、正当に仮説を更新したり、新しい仮説を立てたりできます。判断基準は得票数ではなく、感じた衝撃です。驚きは、学びが起きているという合図です。

ウォッチセクションの名前は、科学において最も心躍る言葉は「わかった」ではなく「これは面白い」だという、昔からの言葉に由来します。気づいたものの、パターンと呼べるほどには至らないことはすべてそこに記録します。少人数のコーパスで一度、あるいは二度聞いたことも含みます。パターンに近づいている場合は、「5 人中 2 人から聞いた。優先して観察」のように重みを記します。面白いことからパターンへ、さらに仮説の変更へと進む流れは、振り返りが蓄積したところでこのスキルを再実行することで実現します。

矛盾を想定する —「パターンなし」も学びです

人によって、目標、役割、過去の経験が異なります。あるいは、違いの理由がはっきりしないこともあります。データにはばらつきがあり、仮説によっては、真でも偽でもなく、「大きくばらついている」または「ここにパターンはない」という結論に至ります。その結論を記録しましょう。パターンが存在しないと知ることで、誤った前提に基づいて何かを作るのを防げます。実際のパターンはノイズの中から際立ちます。その対比こそが発見です。

収束こそが真実の手応えです

多くのインタビューを重ねるにつれて、検証されたアイデアは自然法則のように振る舞います。尋ねる人数が増えるほど、回答が一致していきます。同じ悩み、同じく受け入れられる解決策、同じ金額です。弱いアイデアはその逆です。誰もが前向きでも、会話ごとに違う方向を指し示します。買い手も、価格も、製品も異なり、20 個の葉があって中心がないベン図のような状態です。インタビューが何かに近づいているかを判断するのは、熱意ではなく、収束と乖離です。どちらが起きているかを観察し、それをもとに最終判断を下します。

顕在化するセグメンテーション

「矛盾」が構造的な問題である場合もあります。つまり、あるタイプの顧客はある答え方をし、別のタイプは別の答え方をします。マーケティング部門はセキュリティについて考えますが、個人ブロガーはまったく考えません。顧客タイプごとに回答がまとまる場合は、セグメントを明示することを提案します。影響を受ける仮説を書き換えて、対象を明記します（「クライアントのサイトを構築するフリーランサーは料金を支払う……」対「個人事業主は……」のように、仮説を2つ、数値も2つ）。また、面談の早い段階で、面談相手がどのセグメントに属するかを判別する質問を用意し、その後のすべての回答を適切な観点に基づいて分類できるようにします。セグメントごとの主張を1つの仮説ファイルにまとめます。この段階で得られる最も価値のある知見の1つは、セグメンテーションそのものです。

相反するシグナルには「バランス」ではなく「選択」を

報告内容が二つの方向に分かれる場合、つまり「安くてシンプルなもの」を求める人もいれば、「高価格でフルサービスのもの」を求める人もいる場合、安易な統合案は「バランスを取ること」です。これはたいてい、決断を避けているだけです。本当の解決策を明確にします。

• バランスが正しいのは、両極端が本当に望ましくなく、その中間がどちらよりも優れている場合だけです。面談で得られる知見では、これはまれです。
• 選択が正しいのは、両方のシグナルが合理的でありながら矛盾している場合です。これはたいてい、セグメントが顕在化したことを意味し、どのセグメントを理想の顧客とするかが問題になります。それは、このスキルが決めることではなく、ユーザーが状況を理解したうえで決めることです。
• 上限付きの選択：一方を最大化し、もう一方をしきい値以上に保ちます。これは目標と制約であり、妥協ではありません。
• 両方を満たす――ときには、この対立から、誰も求めていなかった新しい発想が生まれます。両方のシグナルを同時に満たす新たなサービスです。たとえば、大規模なサイトには喜んで全額を支払った顧客が、些細な副次サイトにも同じ金額を払うことには不満を抱き、その答えはどちらかの価格帯ではなく、複数サイト向けのプランだったというケースがあります。競合他社はどこも提供していないものでした。このような方向性がうまくいくかを見極めるには、戦略家の問いを投げかけます。これを成立させるには、ほかに何が成り立っている必要があるか？ 発想と、それを支えると明示された一連の決定がそろって初めて戦略になります。発想だけでは願望にすぎません。

提案に相反するシグナルが関わる場合は、その対立がこれらのどの形に当てはまるかを示します。選択であれば、折衷案を示すのではなく、そうだとはっきり伝えます。

退屈になったら終了する

驚きがなくなったら、学びも終わりです。インタビューをやめて、行動を始めるときです。インタビューの魔法の回数はありません。3回では明らかに少なすぎます（広告のバリエーションを2つ試してすぐにやめるマーケターのようなものです）。10回で検証できた企業もあれば、有名な検証事例では40回、100回を超えることもあります。判断の手がかりを具体化すると、次のとおりです。

• 驚きの頻度。 最近のデブリーフでも、まだ驚き（きちんと記録されたデブリーフでは、たとえば❗を付けて示します）や新たな補足テーマが出ていますか。それとも、同じ話、同じ数字、同じ言い回しが繰り返されるようになっていますか。驚きの頻度が下がっていれば、終わりに近づいています。
• 収束。 中核となる仮説（課題、対処法、費用）は安定した結論に落ち着きつつありますか。それとも、まだ見解が分散していますか。
• さらに聞けば何かが変わりますか。 あと5回、同じような会話をしても判断がひとつも変わらないのなら、その会話をする価値はありません。
• 数字だけでは明確に判断できないときの正直さの確認：埋没コストに判断を委ねないこと（すでに予定されているインタビューは、何も学べないまま続ける理由にはなりません）。残りの期間には期限を設け、漫然と続けないこと。そして、心の奥を確かめることです。ユーザーは多くの場合、すでに答えを知っていて、それを認めたくないだけです。

可能な結論は3つあり、必ずいずれかを示します。続行（まだ驚きがある場合。残りのインタビューで何に焦点を当てるべきか、つまり未解決の仮説や、十分に話を聞けていないセグメントを明示します）。終了して行動する（収束している場合。検証済みの事実を戦略と組み合わせる準備ができています）。または方向を変える（誰もが丁寧に答えるものの、回答がばらばらで共通点がない場合。問題はインタビューではなく、アイデアや対象者にあるのかもしれません。次にすべきなのは、同じ会話をさらに重ねることではなく、別の仮説を立てるか、別の人に話を聞くことです）。「あと少しだけやって様子を見ましょう」は、このステップで退けるべき、答えにならない答えです。インタビューを続けると決めたなら、焦点と回数も示します。そして、どのセグメントを対象にするか、何を作るか、いくらにするかなど、インタビューを重ねても答えられない問いは、続行する理由にはなりません。残る課題が戦略上の選択だけなら、結論は終了して行動することです。

用語集

• デブリーフ — このスキルが扱う、会話ごとの記録です。Q番号（H番号に対応）にひも付けた簡潔な回答と、番号の付いていない知見の補足で構成され、インタビューごとに1つのファイルを作成します。
• 注力する — デブリーフで裏付けられた仮説です。検証済みとして記録し、行動に移す際に力を入れる価値があります。
• 調整する — 主張の種類は維持し、数字、しきい値、またはセグメントを修正します。
• 否定された — 現実が「違う」と示しました。否定された考えも知見のひとつなので、仮説はファイルに残して印を付けます。番号は再利用しません。
• これは面白い — パターンとして扱うには不十分な観察事項を記録するセクションです。気づいたことを記録しますが、まだ行動には移しません。
• 変更履歴 — 作業ファイルの末尾に、変更ごとに1行記載します。現在のファイルが信頼できるものであることを示す記録です。

統合する際の心構え

気の利いた表現より、明快さを

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

参照先を言い換えて補足し、番号だけを示さない

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

あなたが提案し、ユーザーが決めます

この作業の価値の半分は、ユーザー自身が考え抜くことにあります。「なるほど」という気づきは、矛盾についてのメモを読むことからではなく、矛盾に向き合うことから生まれます。そのため、このスキルが変更をまとめて適用することはありません。変更は一つずつ提案し、根拠を示して説明し、ユーザーが受け入れた場合にのみ適用します（ユーザーが調整した内容があれば、それも反映します。これはユーザー自身の信念を記録するファイルです）。ただし、決めることは、何でもそのまま通すことではありません。まとめてうなずく（「いいよ、9件全部適用して」）場合は断り、ユーザーが強い反証に反して仮説を維持する場合は、一度だけ根拠を説明してもらいます。「7人中5人が反対のことを言っています。彼らが知らない何をあなたは知っていますか？」と尋ね、その後でユーザーの判断を記録します。証拠をどう評価するかとは異なる結論であっても、ユーザーが本当に信じていることはファイルに記録し、証拠が示したことはログに記録します。

すべての提案に根拠を引用します

引用のない提案は意見にすぎません。それぞれの提案では、根拠となるデブリーフィングファイルを挙げ、判断に関わる文言を引用します。「2026-06-30-dana.md:『移行を任せられるなら、明日にでも切り替えます』」のように示すことで、ユーザーは要約ではなく証拠を評価できます。市場の第一人者としてフラグ付けされた資料は、市場についての証拠としてはほとんど重視せず、その発言者についての証拠としては全面的に重視します。同じ割引は、デブリーフィングでフラグ付けされなかった、第一人者らしい言い回しの資料にも適用します。「たいていの人は……するでしょう」というのは、誰が記録したものであっても伝聞です。水増しは禁物です。ある仮説に触れているデブリーフィングが2件だけなら、2件だと伝え、各層に判断を委ねます。

1回のやり取りにつき提案は1件

最初の動きは小さくします。何を読んだか、前回の統合以降に新しいデブリーフィングが何件あるか、各カテゴリーのキューの状況を1行ずつ示し、その後に最初の提案をします。最初のメッセージに提案を含めても構いません。完成した提案が1件あれば十分な出発点ですが、2件では壁になります。その後は厳密に、1回のやり取りにつき提案は1件です。提示し、決定し、適用し、記録してから、次に進みます。一つひとつに反応できないユーザーは、支援されているのではなく、見せ物にされています。ユーザーが急ぐよう求めた場合は、手順の形式を短くします（証拠の提示を簡潔にし、確認を早めます）。ただし、構成は変えません。全行程の後に、適用した変更をまとめた差分を渡すのは、心遣いとして適切です。まとめてレビューするのは問題ありませんが、まとめて決定することは決して認められません。

番号は固定し、ログは必須です

他の成果物がこれらの番号を参照するため、ユーザーがどれほど強く求めても、この仕組みは変更できません。

• 仮説または質問の番号は、反証された項目や廃止された項目であっても、絶対に振り直したり、再利用したりしません。主張の対象を保った書き換え（番号の調整、表現の明確化、条件の範囲設定）は、同じ番号の項目をその場で編集し、変更内容はログに残します。主張の対象となる人物や物事を変える書き換え（セグメントの分割、別の行為者への変更）は、以前の番号を「記載どおりでは反証済み」または「記載どおりでは置き換え済み」として廃止し、新しい主張には新しい番号を割り当てます。
• 反証された仮説は、印を付け、現実が示したことを1行添えて、ファイルに残します。削除すると、学びまで消えてしまいます。
• 適用した変更はすべて、変更したファイルの末尾に1行の変更ログを記録します。日付、変更内容、簡単な理由を記載します。統合作業が完了したら、対象となったデブリーフィングを記録する実行ログを1行残します。これにより、次の実行時に新しいものが分かり、作業の途中でセッションが終了してもファイルだけで再開できます。

新しい仮説には新しい質問が必要です

質問がなければ、次のインタビューで仮説を検証できません。 新しい仮説を採用したとき（または既存の仮説の対象を新しいセグメントに変更したとき）は必ず、すぐにそのインタビュー質問を作成してください。質問作成のステップと同じ品質基準を守ります。自由回答式であること、仮説を肯定または否定できること、特定の回答をほのめかさないこと（礼儀正しい見知らぬ人が、あなたの期待する回答を推測できないこと）、感想ではなく具体的な内容（数字、出来事、エピソード）を引き出すこと、尋ねていない情報も話せるよう促すこと、そして一つの質問に一つの回答であること。ユーザーがどれほど急いでいても、誘導質問は決して記録しません。記録すれば、この手法が防ごうとしている誤った検証結果を作り出してしまうからです。この手法の作者による質問作成スキル（例：Interview Questions / asb-interview-questions）がインストールされている場合は、質問をその場で作成する代わりに、新しい仮説に対してそのスキルを呼び出してください。そうでなければ、ここに記した基準を自ら確認しながら作成してください。新しい仮説とその質問は、一つの提案として扱います。つまり、一つの判断、一つのログ行（「Added H19 (+ Q31)」）です。新しい質問には新しい Q 番号と [H] タグを割り当て、インタビューの順序に沿った位置に質問ファイルへ追加します（Q 番号は識別子であり、配置順ではありません。価格に関する質問は終盤に置きます）。または、配置位置を明記して末尾に追加し、そのファイル独自の変更履歴にも記録します。

読み取り専用の目標

GOALS.md はコンテキストとして参照するものであり、ここでは編集しません。新しい仮説を目標に対応させる必要はありません。興味深い流れがあれば、どこへでもたどってください。目標に対応していない仮説も有効な仮説であり、[G] タグを付けずに記載するだけです。学びによって目標が本当に疑問視される場合（「誤った判断について尋ねている」など）は、そのことをはっきり伝え、目標のステップを別途見直すようユーザーに伝えてください。目標の変更は仮説や質問にも波及します。これは意図的に行う作業であり、統合の副次的な結果として生じるものではありません。

このスキルの使い方

フェーズ A — 取り込み

不足しているものだけを確認しながら読み取ります。

1. 作業ファイル：仮説リスト（H1、H2、…と [G] タグを含む。一般的には HYPOTHESES.md）と質問リスト（Q1、Q2、…と [H] タグを含む。一般的には QUESTIONS.md）、および利用可能であればコンテキスト用の目標ファイル。
2. デブリーフ：インタビューごとのファイルをまとめたディレクトリ（一般的には質問リストと同じ場所にある interviews/）。各ファイルでは、一つの会話の回答を Q 番号に対応付け、補足事項も記録します。デブリーフファイルがないインタビューについては、貼り付けられたメモを受け付けます。まず正式に記録することも提案してください。会話ごとに簡潔なファイルを作り、回答を質問に対応付け、その他の内容は補足事項として記録します。この手法の作者によるデブリーフ記録スキル（例：Interview Debrief / asb-interview-debrief）がインストールされている場合は、会話ごとにそのスキルを呼び出してください。そうでなければ、統合を始める前に、同じ形式の簡潔な記録をその場で作成してください。
3. 変更履歴：仮説ファイルの末尾にある変更履歴を確認し、直近の統合実行行を見つけて、それ以降に追加されたデブリーフを特定します。9 件のデブリーフを対象に統合しても、そのうち 7 件がすでに反映済みなら、実質的には既存の判断に新しい 2 件を照らし合わせた統合です。その旨を伝えてください。

基準：デブリーフが 0 件なら、作業はありません。インタビューの実施に戻るよう伝えてください。デブリーフが 1 件または 2 件なら、作業を進めますが、この段階ではパターンに関する主張はできないことを明言してください。ここから得られるのは新たな気づきと「これは面白い」という項目に限られ、更新ルールの第 1 段階に従って説明します。この段階では、最終判定は原則として「継続」になりますが、それでも判定を示し、次のインタビューで何を検証すべきかを伝えてください。

フェーズ B — 全体を精査する（静かに）

何かを提案する前に、すべてを精査します。

• すべてのデブリーフをすべての仮説と照合します。どのセルが仮説を支持し、反証し、調整し、あるいは何も示していないかを確認します。グルがフラグを付けた内容は、それに応じて重み付けします。支持はあるもののパターンとしての深さに達していない仮説には、現状維持、深さ未検証という明確な扱いがあります。手を加えず、提案キューの形式でその旨を示し、次のインタビューで焦点にするかどうかは判定に委ねます。
• 繰り返し現れるテーマ（パターン候補）、単独で興味を引く項目（「これは面白い」候補）、そして新たな気づきの候補（ユーザーが❗を付けたもの、または仮説の捉え方を変えるもの）について、すべての追記セクションを確認します。
• 既存の「これは面白い」セクションを確認します。保留中の項目がパターンになったものはあるでしょうか。昇格候補を確認します。
• セグメントのスキャン：回答は識別可能な顧客タイプごとにまとまっていますか。
• 質問のパフォーマンス：一貫して何も得られない質問（廃止するか、質問番号はそのままにして文面をその場で変更し、以前の文面で何ができなかったかをログに記録します）、仮説が確定した質問（廃止してインタビュー時間を空けます）、新しい仮説に新しい質問が必要なギャップを確認します。
• 停止シグナルのスキャン：日付順に並べたデブリーフ全体の驚きの頻度と、主要な金銭・痛み・対処の仮説に関する収束または乖離を確認します。

提案キューは次の順に作成します。まず、最も強い根拠がある仮説の判定、次に「これは面白い」の昇格と追加、次に新しい仮説（それぞれ新しい質問を伴う）、その後に質問の編集、そして常に最後に停止か継続かの判定を置きます。この判定には、それまでに決定したすべてを反映します。提案された判定に対する反対意見がひとつでもあれば、同じ提案の一部として「これは面白い」に保留します。これは一つの決定であり、二つではありません。

フェーズ C — キューを一つずつ確認する

各提案について、簡潔なやり取りを一度行います。

1. 主張：どの階層か（パターン／新たな気づき／面白いものとして保留）、どのような変更を提案するかを、ファイルに記載する正確な文言で示します。調整の場合は、変更前と変更後を示します。
2. 根拠：デブリーフのファイルと引用、支持する意見と反対する意見の数、グルによる割り引きを記載します。
3. 決定：承認、調整、または却下。承認または調整の場合は、直ちにファイルへ反映し、ログ行を追加します。却下の場合は次へ進みます。ユーザーの判断を優先しますが、反対の根拠は次回に備えてデブリーフで確認できる状態にしておきます。

変更を反映する際のファイル操作：

**H2.** Freelancers discover hosting through peer recommendation, not
search.
    ✓ VALIDATED 2026-07-09: 8 of 9 debriefs, no contradictions.    [G5]

**H3.** Freelancers building client sites will pay up to 6× their
current hosting cost for managed speed and support — but not 10×.    [G6]

**H7.** ~~All customers worry about security breaches.~~
    ✗ DISPROVED 2026-07-09: without a personally experienced incident,
    security was worth $0/mo to 6 of 7 interviewees.    [G4]

## That's funny

- Heard once (2026-07-02-marco.md): keeps a spare "junk" site just for
  testing plugins — might be a real workflow. Watching.

## Change log

- 2026-07-09: H2 validated — 8/9 debriefs.
- 2026-07-09: H3 tuned from "$50/mo" to "up to 6×, not 10×" — pattern
  across 5 debriefs.
- 2026-07-09: H7 marked disproved — 6 of 7 with no incident wouldn't pay.
- 2026-07-09: That's funny — marco's spare "junk" site, heard once.
- 2026-07-09: Added H19 (+ Q31) from repeated addenda theme: migration
  fear blocks switching.
- 2026-07-09: Synthesis run over interviews/ — 9 debriefs through
  2026-07-08 (list: …). Verdict: continue, focus H12/H19, ~5 more
  freelancer interviews.

「これは面白い」セクションと変更ログは仮説ファイルに置きます（初回使用時に作成し、ファイルの末尾に置き、ログを最後にします）。質問ファイルには、質問の編集用に独自の変更ログセクションを設けます。確認作業が中断された場合でも、適用済みの変更とログ行はすでにディスクに保存されています。新しいセッションでは再度全体を精査し、未決定のものだけを見つけます。記憶するのはファイルであり、チャットではありません。ログを信頼してください。ログに記録された決定は確定済みです。再度尋ねたり、蒸し返したりしてはいけません。再開後に確認作業が完了したら、中断前の分も含め、確認したすべてのデブリーフを網羅する実行行を一つだけ記入します。

フェーズ D — 結論

すべての一連の作業の最後に、テーブルに並んだ証拠をもとに、継続するか終了するかを判断してください。判断材料には、意外な発見の頻度の推移、収束または乖離、さらにインタビューを重ねることで何が変わり得るかを含めます。次の3つの結論のいずれかを提示してください。焦点とおおよその件数を明示して継続する、終了して行動に移す、または方向を修正する。ユーザーが流されてしまわないよう、声に出して決断を確定させてください。確定した条件（焦点、件数、日付）はラン行に記録します。継続する場合は、次のインタビューで検証すべき仮説と、質問リストを絞って時間内に収める必要があるかどうかを明示してください。また、ループの回し方も説明します。新しい会話ごとにデブリーフを記録に追加し（インストールされていれば、Interview Debrief／asb-interview-debrief などのデブリーフスキルを使用）、その後、再びこの統合を実行します。終了する場合は、仮説ファイルで検証済みの事実が、次に何をするかを判断するための素材になります。これらの事実を戦略と組み合わせることが、ユーザーの次の仕事であり、このスキルの範囲外です。何をすべきかだけでなく、どう進めるかも伝えてください。自然な次の一歩は、全社で活用できる調査結果レポートにすべての内容をまとめることです。この手法の作成者によるレポートスキルがインストールされていれば（たとえば Interview Report／asb-interview-report）、その名前を挙げてください。「見つかったことをまとめるには、asb-interview-report を実行してください。」方向を修正する場合は、乖離から示唆される見誤りの種類（課題の誤り、対象者の誤り、伝え方の誤り）を示し、正直な次の一歩は仮説、あるいはアイデアそのものを見直すことであって、同じインタビューをさらに予定することではないと伝えてください。

拒否する条件

• 「全部まとめて更新してください。」 一括処理は断ってください。ユーザーが個別に検討していない変更を9件適用すると、ユーザー自身が信じていない信念ファイルができてしまいます。学びが生まれるのは、こうして一つずつ吟味する過程です。一度に一つずつ進めるのは儀式ではなく、この取り組みの本質です。
• デブリーフの代わりに生のトランスクリプトを使うこと。 生のトランスクリプトをそのまま統合すると、記録の規律（マッピング、逐語的な語彙、グルフラグ）が気づかないうちに省略されます。インテークの手順に従い、まず会話ごとに一つずつデブリーフするよう提案してから、統合してください。
• 1件または2件のインタビューからパターンを主張すること。 そのような主張は段階設定で禁じられています。どの段階でも、発見事項や「面白いですね」という保留は可能ですが、「顧客はXだと考えている」とは言えません。
• 証拠を超えて「どの仮説が正しいですか？」と尋ねること。 このスキルが評価するのはデブリーフの内容であり、市場に対する独自の見解から裁定することではありません。デブリーフに記載がなければ、正直な答えは「未検証」です。
• 目標の編集。 意図的にこの範囲から外しています。矛盾があれば指摘し、目標設定の手順を案内してください。
• 「では、何を作ればいいですか？」 このステップの結論は検証済みの事実であり、プロダクト戦略ではありません。その事実をどう活用するか――価格設定、ポジショニング、プロダクトの施策と組み合わせること――は、ユーザーが次に取り組む課題です。統合セッションがいつの間にかプロダクトロードマップの策定に変わってしまったら、証拠から離れてしまっています。
• シミュレーションした証拠。 ロールプレイやAIが生成した「インタビュー」のデブリーフは、市場についての証拠ではありません。実際のインタビューとあわせて統合することは断ってください。