conducting-user-interviews

ユーザーインタビューの実施

対象範囲

対象となる内容

• 特定のプロダクト上の意思決定に役立つインタビュー調査の計画
• 適切な参加者の募集（必要に応じてアーリーアダプターを含む）
• 意見ではなく、具体的なストーリーや行動を引き出すインタビューの実施
• インタビューを、実行可能なインサイト、機会、次のステップにまとめること
• 迅速な追加調査のために、手軽な「顧客パネル」の習慣をつくること

使用する場合

• 「ディスカバリーインタビュー用のディスカッションガイドを作成してください。」
• 「オンボーディング／アクティベーションについて、ユーザーインタビューを8件募集して実施してください。」
• 「ユーザーが乗り換えた（または解約した）理由を理解する必要があります。乗り換えインタビューを実施してください。」
• 「インタビューをインサイトと機会にまとめるのを手伝ってください。」
• 「PMとして、来週顧客との会話を実施する必要があります。」

使用しない場合

• 主に定量的な根拠（アンケート／実験／分析データ）や統計的な信頼性が必要な場合
• 主な成果物としてタスクベースの評価を行うユーザビリティテストを実施する場合（プロトコルが異なります）
• 適切な承認やトレーニングを受けずに、高リスクの対象者やセンシティブなトピック（医療、法律、未成年者）を扱う場合
• 支援すべき意思決定がない場合（影響のない逸話を生み出すことになります）

入力

最低限必要な情報

• プロダクトと対象ユーザー／顧客セグメント（誰が、どのような利用状況で使うか）
• インタビューで情報を得るべき意思決定（例：ポジショニング、オンボーディングの再設計、ロードマップ上の注力先）
• インタビューの種類：ディスカバリー／JTBD乗り換え／解約／コンセプトテスト（または「提案してください」）
• 対象参加者（役割、行動、状況、直近性）と「インタビュー対象にしない人」
• 制約：インタビュー件数、時間枠、言語／地域、録音の可否、謝礼（ある場合）

不足情報への対応

• references/INTAKE.mdから最大5つの質問をします。
• 回答が得られない場合は、明示的な前提を置いて進め、不明点を明記します。

成果物

Markdown形式のユーザーインタビューパックを作成します（チャット内、または依頼があればファイルとして作成します）。

1. 背景の概要（目標、意思決定、仮説、制約）
2. 募集計画（チャネル、案内文、日程調整の手順）＋スクリーナー
3. インタビューガイド（台本＋質問集＋掘り下げ質問）＋同意／録音の計画
4. 記録用テンプレート＋タグ付けのルール
5. 統合レポート（テーマ、根拠、機会、提言、確信度）
6. フォローアップ計画（お礼、連絡の継続、「顧客パネル」のリスト／頻度）
7. リスク／未解決の質問／次のステップ（必ず含めます）

テンプレート：references/TEMPLATES.md

ワークフロー（8ステップ）

1) 意思決定を明確にし、インタビューの種類を選ぶ

• 入力： 背景情報＋references/INTAKE.md。
• アクション： 意思決定と、学ぶ必要があること（不明点）を明確にし、インタビューの種類（ディスカバリー、乗り換え、解約、コンセプトのいずれか）を選びます。
• 出力： 背景の概要＋調査の目的。
• 確認事項： 「このインタビューの後、何を変えるのか？」に答えられること。

2) 参加者の条件（誰を／いつ／なぜ）とサンプリング計画を定める

• 入力： 対象セグメント、プロダクトの利用状況、制約。
• アクション： 参加条件と除外条件を定めます。該当する場合は直近性（最近の乗り換え／解約／試行）を優先し、サンプル構成を決めます（例：中心的な参加者6人＋例外ケース2人）。
• 出力： 参加者のプロフィール＋サンプリング計画。
• 確認事項： 条件が人口統計上の代理指標ではなく、行動や状況に基づいていること。

3) 募集計画＋スクリーナー＋案内文を作成する

• 入力： 参加者のプロフィール、利用可能なチャネル（CRM、サポート、コミュニティ、広告、LinkedIn）。
• アクション： 案内メッセージ、スクリーナー、日程調整の手順を作成します。途中離脱が多いことを想定し、それに合わせて募集人数を計画します。
• 出力： 募集計画＋スクリーナー＋案内文。
• 確認事項： スクリーナーで「自社プロダクトへの関心」ではなく、必要なストーリー（直近性、状況、代替手段）を基準に選定できること。

4) インタビューガイドを作成する（ストーリーを優先）

• 入力： インタビューの種類＋仮説／不明点。
• アクション： 具体的なストーリー（「前回は……」）を引き出し、誘導的な質問を避けるガイドを作成します。掘り下げる質問、話題の切り替え、時間配分を含めます。同意／録音の説明用スクリプトを追加します。
• 出力： インタビューガイド＋同意／録音の計画。
• チェック： 質問の少なくとも70％が、過去の行動や具体例について尋ねています。

5) インタビューを実施し、正確なメモを取る（PM／デザイン担当者が同席）

• 入力： ガイド、実施に必要な手配、メモのテンプレート。
• アクション： セッションを実施し、ストーリーに沿って進め、発言を逐語的に記録します。可能であれば、PMとデザイン担当者がリアルタイムで同席する（または録音を聞く）ことで、伝聞による情報の希薄化を防ぎます。
• 出力： インタビューごとの完成したメモ＋重要な引用＋その場で得られた主な気づき。
• チェック： 各インタビューから、2〜5件の「ストーリーの場面」（きっかけ → 苦労 → 回避策 → 結果）が得られています。

6) 直後にデブリーフィングを行い、証拠を標準化する

• 入力： インタビューのメモ、録音／書き起こし（ある場合）。
• アクション： 各インタビューの直後に10〜15分のデブリーフィングを行い、予想外の発見、仮説の更新、追加確認事項をまとめます。メモに一貫したタグを付けます。
• 出力： デブリーフィングの箇条書き＋タグ付けされたメモ。
• チェック： 不明確な主張は事実として扱わず、「要確認」として記録されています。

7) インタビュー全体を統合し、テーマと機会を見つける

• 入力： 各インタビューのタグ付きメモ。
• アクション： 得られた成果や苦労に基づいてまとめ、矛盾点を記録します。過度な主張を避けながら、簡易的に定量化（件数の集計）します。インサイトを、確信度を添えた機会と推奨事項に変換します。
• 出力： 統合レポート＋機会のリスト。
• チェック： 主要なインサイトには少なくとも2件のインタビューによる裏付けがあります（そうでない場合は「単発の逸話」と明記されています）。

8) 共有し、意思決定し、フォローアップを行い、品質ゲートを実施する

• 入力： ドラフトパック。
• アクション： 共有可能な報告資料を作成し、次のステップを提案して、顧客パネルを定期的に活用するための簡易的な習慣（積極的に参加するユーザー5〜10人）を整えます。references/CHECKLISTS.mdを実行し、references/RUBRIC.mdで採点します。
• 出力： 最終版のユーザーインタビューパック＋リスク／未解決の質問／次のステップ。
• チェック： 関係者が（a）主な学び、（b）意思決定への影響、（c）次に何が起きるかを自分の言葉で説明できます。

品質ゲート（必須）

• references/CHECKLISTS.mdとreferences/RUBRIC.mdを使用します。
• 必ず含める項目：リスク、未解決の質問、次のステップ。

例

例1（ディスカバリー）：「B2B製品のオンボーディングを再設計しています。新規トライアルユーザー8人を対象としたディスカバリーインタビューの募集計画とディスカッションガイドを作成してください。」
期待される内容：参加者の条件、募集案内＋スクリーナー、ディスカバリーガイド、メモのテンプレート、統合計画、すぐに実施できるパック。

例2（乗り換え／JTBD）：「スプレッドシートに案件を奪われています。チームがスプレッドシートから乗り換えるきっかけと、代わりに何を試すのかを知るため、乗り換えインタビューを実施してください。」
期待される内容：乗り換えインタビューガイド（時系列＋推進要因）、最近の出来事を重視した参加者募集条件、「推進要因／魅力／不安／習慣」を出力する統合の枠組み。

境界例：「ユーザーに欲しい機能を尋ねて、言われたものを何でも作ってください。」
対応：ストーリーに基づくインタビューへと方向を変え、意思決定の背景を明確にし、行動に基づく根拠のない機能要望インタビューを避けます。