インタビューガイドが真価を発揮するのは、会話がまさに面白くなってきた瞬間です。参加者から思いがけない課題が飛び出したときでも、準備のあるリサーチャーならその話を深掘りしつつ、まだ聞けていないトピックを把握しておけます。準備がないと、最後に耳にした細かな話題ばかりを追ってしまったり、会話の流れに合わなくなった質問リストに逆戻りしてしまいがちです。

ガイドとは、リサーチの目的やトピック、導入の質問、想定される深掘りの問い、そして当日の進行手順などをまとめた実践的なドキュメントです。半構造化インタビューにおいては、一言一句を縛る台本ではなく、自然な対話を支える道しるべとなります。

リサーチの目的を、相手が答えやすい質問に落とし込む

「リサーチの問い」はチームのものですが、「インタビューの質問」は参加者に伝わらなければ意味がありません。「なぜ利用が進まないのか？」は事業側にとっては有用な出発点かもしれませんが、ユーザーに分析を求めてしまっています。最後にその製品を使おうとしたときの状況を尋ねるほうが、具体的で話しやすくなります。

たとえば、ある架空のチームが「ユーザーがレポート作成を途中でやめてしまう理由」を知りたいとします。ガイドの構成としては、直近でレポートを作ったときの状況から始め、必要だった情報、試した手順、途中で入った割り込み、そしてその後の流れなどを探っていくとよいでしょう。こうしたトピックを扱うことで、UIだけが原因だと決めつけることなく、離脱の背景を探ることができます。

GOV.UKのリサーチ計画に関するガイダンスでは、リサーチの目的とセッションのトピックを結びつけています。ガイドに何を含めるか判断する際も、このつながりを意識してください。そのリサーチの目的に寄与しない質問であれば、本当に今回のセッションで時間を使うべきか見直してみましょう。

実践的なガイドの簡単な例

先ほどのレポート作成のリサーチであれば、導入部分でセッションの目的を説明し、録画・録音の同意を確認し、参加者の普段の役割を把握します。最初の質問は、「誰かのためにレポートを作成する必要があった直近の経験について教えてください」といったものが考えられます。

「作業の開始」というトピックでは、誰がそのレポートを必要としていたか、どんな情報が求められたか、最初にどこを確認したかなどを深掘りできます。「作業の完了」では、確認が必要だったこと、進行の妨げになったもの、完成と判断した基準などを尋ねられるでしょう。最後のトピックでは、提出後に修正や追加のリクエストがあったかなど、その後の展開をカバーします。

ガイドでは、こうした任意の深掘りと必須のトピックを区別しておくべきです。割り込みについてすでに対話の中で話してくれた参加者に対して、ドキュメントを埋めるためだけに同じ質問を繰り返す必要はありません。また、評価基準やリサーチャー用のメモは、参加者に投げかける質問文とは分けて記載しておきましょう。

言葉選びと質問の順序が会話を左右する

質問は、1つの明確な意図に絞り、相手が経験していないかもしれないことを前提にしないほうが答えやすくなります。「エクスポートのどこにストレスを感じましたか？」と聞くと不満があった前提になってしまいますが、「エクスポートはどうでしたか？」と聞けば、何事もなくスムーズだったケースも拾えます。そのうえで、参加者が実際に話してくれた内容に合わせて具体的に深掘りしていけばよいのです。

質問の順序も重要です。既存の業務について聞く前に新機能の提案を見せてしまうと、参加者の使う言葉や強調する課題に偏りが出てしまいます。両方を扱う必要がある場合は、現在の体験のヒアリングから提案の評価へと明確に切り替え、分析時に両者を区別できるようにしましょう。

ガイドのパイロットテストを行い、変更履歴を残す

質問を声に出して読んでみたら、対象者に近い人と模擬セッションを行ってみてください。質問の意図が伝わるか、トピックの順序に違和感がないか、最も重要な内容に十分な時間を残せているかを確認します。パイロットテストは、リサーチの問いをさらに絞り込むべきだと気づく良い機会にもなります。

内容を大きく変更した場合は日付とともに記録し、どのセッションでどのバージョンを使ったかをメモしておきましょう。リサーチの途中で新たな問いかけを追加した場合、それ以降の回答は、全員が同じ条件で話す機会を持っていたものとしては扱えません。この記録はユーザーインタビューを分析する際のエビデンスの一部となり、参加者が何を語ったかだけでなく、その発言がどのように引き出されたのかをチームが説明する際にも役立ちます。