ユーザーインタビューの設計と実施

前提 — インタビューで確認できること、できないこと

ユーザーインタビューは「なぜその行動を取ったか」の背景と文脈を知る手段であり、「何を作れば売れるか」を直接教えてくれる手段ではありません。回答者は自分の将来の行動を正確に予測できないため、「もし〜な機能があったら使いますか」という仮想質問への回答は、実際の利用意向とほとんど相関しないことがユーザーリサーチの実務では広く指摘されています。インタビューが強いのは、すでに起きた具体的な出来事の再構成です。逆に、価格に対する反応や機能の優先順位づけのように「量」を測る必要がある問いには、インタビューは不向きです。そこはサーベイやログ分析に任せます。

手順

1. リクルーティングの基準を先に決める

誰に聞くかを曖昧にしたまま声をかけると、示唆がばらつきます。基準は「属性」ではなく「行動」で決めます。たとえば「直近30日以内に類似の課題を自力で解決しようとした人」のように、実際の行動歴で絞り込みます。人数は、1回のラウンドで5〜8人程度に留め、パターンが見え始めた時点でいったん統合に入るという進め方が、質的リサーチの実務でよく採られます。Nielsen Norman Groupのユーザビリティ調査の経験則でも、少人数の反復ラウンドが1回の大規模調査より効率的だとされています。ただし対象セグメントが複数にまたがる場合は、セグメントごとに最低3〜5人を確保しないと、声の大きい1人の意見が全体の結論を歪めます。

2. 誘導しない質問を設計する

質問は「未来・仮定・意見」ではなく「過去・具体・行動」を軸に組み立てます。

NG: この機能があったら使いますか？
NG: 〇〇についてどう思いますか？
OK: 直近でその課題に直面したのはいつですか。そのとき何をしましたか。
OK: そのとき、他に検討した方法はありましたか。なぜそれを選ばなかったのですか。

「どう思いますか」型の質問は回答者に評論家の立場を与えてしまい、社交的に望ましい答えを引き出しやすくなります。一方、「そのとき何をしましたか」型は記憶にある具体的な出来事を語らせるため、脚色が入りにくくなります。

3. 実施 — 話すのは回答者、インタビュアーは掘る

1時間のセッションなら、インタビュアーの発話は合計10分以内に収めるのが目安です。相手が答えに詰まっても3秒待つ、曖昧な言葉が出たら「具体的には」と一段掘る、この2つだけでも脱線と一般論化をかなり防げます。共同でメモを取る担当を分けると、進行役は聞くことに集中できます。

4. 統合 — メモを示唆に変換する

セッション直後、記憶が新しいうちに「発言」と「解釈」を分けてメモを整理します。複数セッションの発言を並べ、同じ課題の言い換えをグルーピングし、繰り返し出てくる文脈だけを示唆として採用します。1人しか言っていない発言は「仮説候補」に留め、次のラウンドで確認します。

適用例 — インタビューガイドのテンプレート

導入（3分）: 目的説明、録音の同意確認
ウォームアップ（5分）: 直近の業務・利用文脈を確認
本題（35分）:
  - 直近でその課題に直面した具体的な場面を教えてください
  - そのとき最初に何をしましたか
  - 他に検討した選択肢はありましたか。選ばなかった理由は
  - 誰かに相談しましたか。誰に、なぜその人に
  - 結果として何が起きましたか。今も同じ方法を使っていますか
クロージング（5分）: 聞き漏らしの確認、紹介依頼

本題の質問は5問前後に絞ります。多すぎるガイドは質問を読み上げる作業になり、深掘りの余地を奪います。

確認 — できあがったものを検証する

統合した示唆が「複数の回答者から独立に出てきたか」「具体的な出来事に基づいているか」の2点を満たしているかを確認します。片方でも欠けていれば、それは示唆ではなく仮説として扱い、次のインタビューラウンドか行動データで裏付けを取ります。

つまずきやすい点

もっとも多い失敗は、質問票を作った本人が無意識に「期待する答え」へ誘導することです。「これは便利だと思いませんか」のような同意を求める言い回しは、たとえ一度しか使わなくても回答の方向性を変えます。もう一つの落とし穴は、社内の誰かの意見を検証したいという動機でインタビューを組むケースです。この場合、都合の良い発言だけを拾い上げてしまいがちです。インタビューは仮説を証明する場ではなく、仮説を壊せる場として設計するべきです。ただし、少人数の質的インタビューだけで意思決定を確定させるのも危険です。定量データと組み合わせて、方向性の確認と規模の確認を分業させる必要があります。

次に読む

収集した発言をJobs to be Doneの形式に整理する方法はJobs to be Doneフレームワークの正しい使い方で扱っています。単発の調査で終わらせず、週次で継続的にユーザーと接点を持つ仕組みは継続的ディスカバリーとオポチュニティ・ソリューション・ツリーで解説しています。