第10章 インタビューで未知を見つける
第9章では、小規模で広告経由の顧客に初期設定未完了が多いという差を見つけました。しかし、数字だけでは理由が分かりません。設定手順が難しいのか、始める時間がないのか、期待した機能がなかったのか、契約した人と使う人が違うのか。理由を決めつけて施策を作ると、間違った問題を解くことになります。
インタビューは、相手の経験、行動の経過、判断、制約、言葉を知る方法です。まだ想定していない論点を見つけ、既存の仮説を具体化できます。一方で、何人かが語った内容から、顧客全体の割合や施策の因果効果を推定する方法ではありません。
インタビューの価値は、賛否を数えることではなく、具体的な経験から仮説と選択肢を更新することにあります。
今回の意思決定は、「初期設定未完了の顧客へ、どの手動支援を試すか」です。インタビューでは、未完了になるまでの出来事、顧客が試した対処、社内の役割、支援を受ける制約を確認します。
本章でいう調査は、事業上の意思決定を支える顧客調査です。学術研究、法令上の調査、倫理審査が必要な研究の手続を代替するものではありません。また、参加者 ID、人数、発言、観察は、方法を説明するための仮想例です。実在案件の記録ではありません。
意思決定と未知を定める
↓
異なる経験を持つ対象者を選ぶ
↓
同意と安全な記録方法を決める
↓
具体的な過去の行動を聞く
↓
発言・解釈・示唆を分けて分析する
↓
仮説、追加調査、試行設計へ戻す
小さく取り消し可能な判断なら、20 分程度の設計から始められます。
- 今回の意思決定と、まだ分からないことを 1 つ書く
- 反対の経験を持つ対象者を含める
- 目的、記録、利用範囲を説明し、同意を確認する
- 直近の出来事、止まった点、試した対処、変えにくい制約を聞く
- 発言と質問者の解釈を別の欄へ記録する
- 仮説の更新と次の行動を 1 つ決める
録音しない場合は、相手の許可を得て要点を記録し、面談直後に発言、行動、解釈、未確認を分けて補います。重要な引用を正確に再現できない場合は、かぎ括弧付きの直接引用として使いません。
目的、対象者、説明文、質問、記録方法を一度に確認したい場合は、付録 D「インタビューガイドテンプレート」を使えます。毎回同じ質問票を作るためではなく、今回の意思決定に対して、聞くべき経験と聞いてはいけない誘導が分かれているかを見るために使います。
10.1 インタビューで分かることを限定する
インタビューを始める前に、問いがこの方法に向いているかを確認します。
| インタビューで確かめやすい | 別の方法が必要 |
|---|---|
| 何が起き、どう対処したか | 何% の顧客に起きるか |
| どの言葉や画面をどう理解したか | 施策が成果を何ポイント変えたか |
| 誰が関わり、何が制約だったか | 市場全体の規模 |
| 想定外の行動や代替手段 | 実際の操作時間の正確な計測 |
| 仮説の候補と例外条件 | 将来の購入意思の確実な予測 |
「この支援を使いたいですか」と聞けば、好意的な回答を得られるかもしれません。しかし、回答には礼儀、期待、質問者との関係、想像上の条件が混ざります。将来の意思より、直近の具体的な出来事と、すでに取った行動を聞きます。
インタビューだけで結論を出す必要もありません。ログで起きたことを見つけ、インタビューで理由の候補を探し、小さな試行で支援の実行可能性と結果を確かめます。方法ごとの役割を組み合わせます。
10.2 研究課題を一文にする
「顧客の課題を知る」のような広い目的では、何を聞き、いつ終えるかが決まりません。意思決定、未知、必要な経験をつなぎます。
小規模・広告経由の顧客へ試す初期支援を選ぶため、契約から 14 日以内に設定を完了できなかった過程と、顧客自身では変えにくかった障害を明らかにする。
この研究課題から、次の学習目標を置きます。
- 契約前に何を期待していたか
- 最初に誰が、いつ、何をしようとしたか
- どの時点で止まり、何を試したか
- 社内外の誰が判断や作業に関わったか
- どの障害が支援で変えられ、どれは変えられないか
- 支援を受ける時間、権限、情報上の制約は何か
学習目標は、質問文そのものではありません。「期待を教えてください」と抽象的に尋ねるのではなく、契約を検討した時点の出来事をたどります。
既存仮説も記録します。
| 仮説 | 確認したい観察 | 反対なら変えること |
|---|---|---|
| 手順が分からず止まる | 画面や用語を理解できなかった具体的場面 | 画面共有支援を候補にする |
| 時間がなく後回しにする | 優先順位が下がった出来事と未実施の理由 | 面談ではなく短い代行・リマインドを検討 |
| 権限がなく完了できない | 管理者や他部署への依頼で止まった経過 | 支援対象者と招待手順を変える |
この表は仮説を証明するためではありません。質問者が自分の思い込みを認識し、反対の経験を探すために使います。
10.3 平均的な人ではなく、必要な経験を選ぶ
インタビューの対象者は、顧客全体を統計的に代表する標本とは限りません。意思決定に関わる異なる経験を意図的に選びます。
今回なら、次のような対比が必要です。
| 経験 | 含める理由 |
|---|---|
| 設定未完了で継続中 | 現在の障害と対処を知る |
| 設定未完了で解約 | 解約へ至る経過と不可逆な障害を知る |
| 一度止まったが完了 | 何が再開を可能にしたか知る |
| 早期に完了 | 未完了群との違いと反例を知る |
| 支援を断った | 支援を受けにくい条件を知る |
都合のよい参加者だけを集めません。営業担当が関係のよい顧客だけを選ぶと、強い不満、解約、利用しなかった経験が欠けます。募集経路、参加・不参加条件、断った人数を記録します。
募集前に、次を表へ置きます。
| 項目 | 決めること |
|---|---|
| 対象条件 | 必要な経験、契約時期、役割 |
| 除外条件 | 利害関係、重複参加、今回の問いと異なる経験 |
| 枠 | 未完了・解約・再開・完了など、必要な対比と人数の開始目安 |
| 経路 | 顧客一覧、サポート、解約記録など。営業推薦だけにしない |
| 連絡 | 誰の名義で、何を伝え、回答を誰が管理するか |
| 謝礼 | 金額、支払条件、参加しなくても不利益がないこと |
| 日程 | 実施期間、欠席時の補充、追加募集の判断日 |
募集担当、インタビュー担当、営業・サポート担当の役割を分けます。参加の可否や発言内容を、契約更新や担当者評価へ不必要に共有しません。
最初から「10 人聞けば十分」とは決められません。対象の多様性、問いの狭さ、1 回の情報量、意思決定のリスクで必要数は変わります。最初の数件を行い、重要な対比が欠けていないか、新しい論点が増えているかを確認して追加します。
新しいテーマが出なくなることを飽和と呼ぶことがありますが、同じ種類の人に同じ聞き方をしただけでも、見かけ上の飽和は起きます。「もう新しい話がない」ではなく、どの対象群と問いの範囲で、新しい意思決定上の論点が増えなくなったかを記します。
10.4 参加者への説明と同意を設計する
インタビューは、話を聞ければよい作業ではありません。参加者が目的、記録、利用、断る権利を理解したうえで参加できるようにします。
開始前に、少なくとも次を説明します。
- 誰が、何の目的で行うか
- 所要時間と、行うこと
- 参加は任意で、途中でも断れること
- 録音、録画、文字起こしの有無
- 誰が記録へアクセスするか
- どの成果物へ、どの粒度で使うか
- 保存期間と削除方法
- AI や外部サービスを使うか
- 撤回を申し出られる範囲、期限、連絡先
「匿名化します」という一言だけでは不十分です。企業名を消しても、業種、役職、地域、出来事の組み合わせから本人や会社を推測できる場合があります。報告で引用する範囲と、再識別の危険を説明します。
本章では、氏名を参加者 ID に置き換え、別に対応表を保持する処理を仮名化と呼びます。対応表を使って本人へ戻れるため、個人情報として管理します。合理的な手段で本人を再識別できない状態にする匿名化とは分けます。具体的な法的定義と必要な処理は法域によって異なるため、適用される法令、契約、組織の専門手続を確認します。
撤回できる範囲は、実際の運用に合わせます。仮名化された個別記録と参加者を対応できる段階では除外できても、再識別できない形へ匿名化・集計した後は、特定の参加者分だけを取り除けない場合があります。「いつでもすべて削除できる」と一律に約束せず、どの時点まで何を撤回できるかを事前に伝えます。
参加者が取引先や従業員の場合、形式上は任意でも断りにくいことがあります。営業評価、人事評価、契約条件に影響しないことを伝え、担当者から離れた募集・実施方法を検討します。謝礼を出す場合も、参加を断れないほど過大にしません。
医療、未成年者、研究倫理審査が必要な調査など、特別な法令・倫理要件がある領域では、一般的な事業インタビューの手順だけで進めません。組織の法務、倫理、専門手続を確認します。
顧客は、インタビューをサポート、営業交渉、要望受付と受け取ることがあります。冒頭で、今回その場で解決・約束できることと、できないことを説明します。緊急の障害や契約上の問題が出た場合は、同意を得て担当窓口へ引き渡します。共有した範囲、担当者、対応期限を記録し、参加者へ連絡方法を伝えます。発言した要望が必ず実装されるとは約束しません。
10.5 質問票を会話の経路として作る
質問票は、同じ文を順番どおり読み上げる台本ではありません。必要な領域を漏らさず、相手の経験に沿って深掘りするための経路です。
今回の 45 分の構成例です。
| 時間 | 内容 | 目的 |
|---|---|---|
| 0〜5 分 | 目的、同意、関係づくり | 安心して断り、話せる状態を作る |
| 5〜10 分 | 役割と利用状況 | 発言の文脈を知る |
| 10〜30 分 | 契約から停止までを時系列で再現 | 出来事、行動、障害を具体化 |
| 30〜38 分 | 対処、他者、代替手段 | 制約と未観測の選択肢を知る |
| 38〜43 分 | 支援案への反応と条件 | 試行設計の制約を確認 |
| 43〜45 分 | 言い残し、利用範囲の再確認 | 未知と同意を確認 |
本番前に、同僚または対象に近い協力者と試行します。予定時間に収まるか、専門用語が伝わるか、答えにくい順序になっていないか、誘導や二重質問がないかを確認します。試行で質問を変えた場合も、版と変更理由を残します。
実施前には、質問者自身の立場も記録します。所属、製品への関与、期待する仮説、参加者との関係、答えを期待している方向です。実施後には、どの発言へ強く反応したか、聞かなかった反対例はないかを振り返ります。質問者は透明な観測装置ではなく、会話と解釈へ影響する当事者です。
質問は、広い出来事から具体的な場面へ進めます。
最初に設定しようとした日のことを、覚えている範囲で教えてください。
その直前に何がありましたか。
誰が一緒にいましたか。
最初に何を開きましたか。
そこで何をしようとしましたか。
次に何をしましたか。
そのとき、どのような情報があれば進められましたか。
「なぜ完了しなかったのですか」と一度だけ聞くと、後から整えた理由が返りやすくなります。時系列、画面、会話、判断、試した対処をたどり、理由を出来事の中で具体化します。
10.6 誘導せず、具体性を上げる
誘導質問は、期待する答えや評価を質問の中へ含めます。
| 避けたい質問 | 問題 | 聞き直し |
|---|---|---|
| 設定画面は分かりにくかったですか | 分かりにくいと期待している | 設定画面を開いたとき、何をしましたか |
| サポートがあれば完了できましたか | 仮想の賛同を求める | 困ったとき、誰に何を頼みましたか |
| この機能は便利ですよね | 肯定しにくい関係を作る | この機能を最後に使った場面を教えてください |
| A と B ならどちらがよいですか | 他の選択肢を消す | その場面で、どのような助けが必要でしたか |
| なぜもっと早く連絡しなかったのですか | 相手を責める前提がある | 連絡を考えたのはいつで、何が起きましたか |
深掘りは、問い詰めることではありません。曖昧な言葉を、観察可能な出来事へ近づけます。
- 「大変だった」とは、何にどのくらい時間がかかったか
- 「みんな」とは、誰を指すか
- 「いつも」とは、直近ではいつ起きたか
- 「使えなかった」とは、どこまで進み、何が起きたか
- 「必要」とは、なければ何ができないか
沈黙をすぐ別の質問で埋めません。相手が思い出し、言葉を選ぶ時間を待ちます。質問者が理解した内容を短く言い返し、「こういう理解で合っていますか」と確認します。ただし、質問者の解釈を相手の言葉として記録しません。
10.7 役割を分けて記録する
可能なら、進行役と記録役を分けます。進行役が話を聞きながら詳細な記録まで行うと、相手の表情、沈黙、矛盾、次の深掘りを逃しやすくなります。
クライアントや営業担当が観察する場合は、参加者へ同席者と目的を説明し、同意を得ます。観察者は途中で評価、反論、販売説明をせず、裏側のチャットで進行役へ誘導を送り続けません。質問候補は記録し、進行役が会話の流れと参加者の安全を見て判断します。録音・記録へのアクセスも、説明した範囲に限定します。
記録には、少なくとも次を区別します。
| 種類 | 記録例 |
|---|---|
| 発言 | 「管理者権限を頼む相手が分からなかった」 |
| 行動 | 社内チャットで 2 人に質問し、3 日待った |
| 文脈 | 契約者と実際の設定担当が別部署 |
| 観察 | 同意を得て画面共有した際、権限依頼の画面で 20 秒沈黙した |
| 質問者の解釈 | 権限より、依頼先の不明確さが障害かもしれない |
| 未確認 | 誰が正式な管理者か、本人も確認できていない |
発言と観察も、事実全体ではありません。参加者が覚えて語ったこと、インタビュー場面で観察したことです。ログや実際の画面と食い違う場合、どちらかを直ちに誤りと決めず、認識と記録の差を調べます。
インタビュー直後に 15 分程度で、事実、驚き、反対証拠、次回深掘りする点を短く記録します。複数件を終えてから記憶でまとめると、最近の強い発言だけが残りやすくなります。質問を追加・修正した場合は、版、変更日、理由、どの参加者から適用したかを残し、全員へ同じ質問をしたように扱いません。
10.8 発言、解釈、示唆を分けて分析する
印象に残る一言を、そのまま顧客課題や提案に変えません。発言から示唆までの推論をたどれる形にします。
まず、証拠側を記録します。
| ID | 発言・観察 | 文脈 |
|---|---|---|
| P3 | 管理者を誰に頼むか分からず 3 日停止 | 契約者と設定担当が別部署 |
| P7 | 画面共有の時間を取れない | 月末の経理担当 |
| P9 | ヘルプを読んで自力で完了 | 社内に管理者が同席 |
同じ ID で、判断側を記録します。
| ID | 解釈候補 | 反対・別解釈 | 意思決定への示唆 |
|---|---|---|---|
| P3 | 依頼先の特定が障害 | 単に優先度が低かった可能性 | 面談前に役割確認を送る |
| P7 | 同期面談が制約になる | 月初なら参加できる可能性 | 非同期支援も試す |
| P9 | 画面説明より権限準備が重要 | IT 経験の差かもしれない | 完了者の条件も追加確認 |
分析は、次の順で進めます。
- 各記録を読み、出来事、行動、障害、対処、結果へ印を付ける
- 似た内容をまとめる前に、反対の経験と例外を残す
- 対象者ごとの時系列を比較する
- 既存仮説を支持、反証、修正、新規に分ける
- 各解釈の根拠となる参加者 ID へ戻れるようにする
- 意思決定を変える示唆だけを要約する
複数人で分析する場合は、簡単なコードブックを作ります。
| 項目 | 例 |
|---|---|
| コード名 | 依頼先不明 |
| 定義 | 必要な権限を持つ人・部署を特定できず作業が止まる |
| 含める | 誰に頼むか探した、別部署への連絡先が不明 |
| 含めない | 依頼先は分かるが返答が遅い |
| 変更履歴 | v2 で「返答待ち」から分離。P7 の分析後 |
コードは客観的な正解ではなく、記録を同じ観点で比較するための分析規則です。新しい事例で定義を変えたら、以前の記録にも戻り、必要な範囲で付け直します。
発言回数だけで重要度を決めません。1 人しか語っていなくても、重大な安全問題や、試行を実行不能にする制約なら先に扱います。反対に、多くの人が好意的でも、具体的な行動や結果に結びつかない賛同は弱い証拠です。
引用は説明を具体化しますが、参加者全体を代表する証明ではありません。刺激的な一文だけを選ばず、文脈、対象者属性、反対例、何人に見られた論点かを必要な範囲で示します。公開・共有時は同意と再識別リスクを再確認します。
重要な推奨を支える解釈は、必要に応じて別の担当者が原記録、コード定義、反対例、参加者 ID をたどります。解釈が一致すること自体を目的にせず、どの証拠と前提から違いが生じたかを話し合い、採用した説明と残る異論を記録します。
10.9 AI は整理を助けても、意味を確定しない
AI は、質問案の批評、文字起こし、記録の整形、初期コードの候補、発言箇所の探索、反対例の検索に使えます。大量の記録を同じ観点で見直す補助になります。
質問票のレビューでは、答えを作らせるより、誘導と前提を指摘させます。
研究課題:
初期設定未完了までの過程と、顧客自身では変えにくかった障害を知る。
依頼:
1. 質問に含まれる誘導、評価、仮定を指摘する
2. 一度に複数のことを聞く質問を分ける
3. 将来の意向を、直近の具体的行動を聞く形へ直す
4. 仮説に反する経験を聞く質問を提案する
5. センシティブで答えにくい質問を示す
文字起こしは、固有名詞、専門用語、数字、否定、話者を誤ることがあります。「できた」と「できなかった」の誤認は解釈を逆にします。重要な引用と判断根拠は録音へ戻り、前後の文脈を確認します。自動要約だけを分析対象にせず、原記録へ戻れる状態を保ちます。
AI が複数の発言を、存在しない「典型的な顧客の声」へ統合することがあります。テーマ名は候補として受け取り、どの参加者のどの箇所が支えるか、反対例があるかを人が確認します。出力に参加者 ID と該当箇所を付けさせ、確認できない要約は採用しません。
個人情報、顧客の機密、健康・労務・財務などのセンシティブな内容を外部 AI へ入力する前に、利用目的、契約、保存場所、学習利用、アクセス権、越境移転、削除方法を確認します。承認された環境がなければ、AI を使わないか、個人を特定できない最小限の抜粋で代替します。
個人データの保護は、名前を置換するだけでは終わりません。分析に不要な属性を収集しない、早い段階で識別情報を分離して仮名化する、対応表へのアクセスを限定する、報告時に属性を集約する、必要なら再識別できない形へ匿名化する、といった工程全体で扱います。
参考資料の ICO は英国の監督機関です。本章では、目的に必要なデータだけを扱う考え方を参照しています。日本を含む実案件では、対象者、保管場所、委託先に適用される法令と契約を別途確認します。
10.10 インタビューを終え、意思決定へ戻す
「何人聞いたら終わりか」だけで終了を決めません。次を確認します。
- 意思決定に必要な主要な経験の対比を含んでいる
- 既存仮説を支持する例と反対例を確認した
- 新しいインタビューで、行動を変える論点が増えなくなった
- 重要な不一致と未確認事項を説明できる
- 次はログ、追加対象者、小規模試行のどれで確かめるか決まった
- 時間、参加者負担、予算の上限に達した
興味深くても今回の選択を変えない論点は、将来のどの意思決定へ使うか、担当と再検討時期が決まる場合だけ別の調査候補へ移します。それ以外は今回の範囲外として閉じます。
今回の結果は、次のように意思決定へ戻せます。
| 学んだこと | 証拠と限界 | 仮説の更新 | 次の行動 |
|---|---|---|---|
| 依頼先不明で止まる事例が複数 | 未完了 4 人。企業構造に偏り | 画面理解だけでなく役割が障害 | 面談前に権限確認を送る |
| 同期面談を取れない人がいる | 月末担当 2 人 | 面談のみでは対象を失う | 非同期支援も比較する |
| 完了者は管理者と同席 | 完了者 2 人。IT 経験も高い | 権限準備が候補、因果は未確定 | 募集時に管理者同席可否を記録 |
| 支援への好意的反応 | 仮想質問への回答 | 利用率の証拠にはしない | 実際の参加率を試行で測る |
インタビュー結果から「顧客はこう思っている」と一般化しません。「今回の対象者では、どの状況で何が起き、どの仮説が生まれたか」を示します。試行する支援、対象条件、停止条件、次に測る数字へ変換して初めて、意思決定へ役立ちます。
考えてみる問い
最近聞いた顧客の要望を一つ選び、その人が要望を持つ前に何をし、どこで止まり、何を試したかを書き出してください。要望の言葉と、観察できる障害は同じでしょうか。
インタビューは、顧客の内面を直接読む方法ではありません。語られた経験を文脈の中で聞き、質問者の解釈を分離し、反対例と未確認事項を残すことで、数字だけでは見えなかった仮説を作る方法です。
調査とデータの部では、必要情報、外部資料、数字、インタビューを扱いました。次の第4部では、これらの証拠を使って顧客、課題、市場、競合、自社を理解し、事業上の選択肢を組み立てます。第11章では、顧客、利用者、購入者、意思決定者を分け、顧客課題の仮説を作ります。
参考資料
最終確認日: 2026 年 7 月 15 日。本章の研究課題、対象者の対比、質問、分析表、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。
- GOV.UK Service Manual ― Using in-depth interviews ― インタビューが向く目的、質問、実施方法を確認
- GOV.UK Service Manual ― Find user research participants ― 対象条件、募集、同意、謝礼の考慮点を確認
- GOV.UK Service Manual ― Analyse a research session ― セッション直後の記録とチーム分析を確認
- Information Commissioner's Office ― Data protection principles ― データ最小化を含む個人データ取扱いの原則を確認