ユーザーインタビューで何を聞く？機能要望の背景を確かめる30分の進め方
目次
「通知を増やしてほしい」と言われたとき、追加したい通知の種類だけを聞いて終えていませんか。相手が見落としたのは何か、見落とすと誰の作業が止まるのかが分からなければ、通知を増やす案の妥当性も判断できません。
ユーザーインタビューでは、要望が生まれた具体的な出来事を聞きます。この記事で用意する成果物は、聞き取りと記録をセットにした30分の進行台本です。届いている記録の読み直し方はVOCの活用方法で扱い、ここでは記録だけでは分からない背景を本人に確かめる場面に絞ります。
- 直近の出来事を、目的・手順・困りごと・回避策の順に聞く
- 発言、実際に見た操作、聞き手の解釈を分けて残す
- 最後に認識を確かめ、次に調べることを決める
聞く前に、確かめたいことを1文にする
インタビューの目的は「通知機能の感想を集める」より、「承認依頼を見落としたとき、どの作業が止まり、今はどう補っているかを知る」のように書くと、質問を選びやすくなります。既存の問い合わせに答えがあれば読み直し、分からない点だけを台本に残してください。
相手は、その作業を実際に行った人から選びます。契約を決めた人と日々操作する人が違う場合、誰の経験を聞くのかを明確にします。話しやすい顧客だけに聞いた結果を、顧客全体の意見とは扱いません。
GOV.UKのインタビューガイドも、開かれた中立的な質問を使い、一般論より実際の出来事を聞くことを勧めています。以下の時間配分は、1つの要望を掘り下げるための本記事の提案例で、効果を保証する標準時間ではありません。複雑な業務や通訳が必要な場合などは、余裕を持った枠に調整します。
30分で、要望が生まれた場面をたどる
進行役と記録役を分けられるなら、事前に役割を決めます。質問はすべて消化する必要はありません。相手の話からすでに分かった内容は飛ばし、分からないところを掘り下げます。
| 時間の目安 | 進行役が聞くこと・伝えること | 残す内容 |
|---|---|---|
| 0〜3分 | 「今日は承認依頼を確認する作業について伺います。答えにくい質問は飛ばせます。途中で終了しても構いません」 | 調査目的、参加・記録方法への同意 |
| 3〜7分 | 「普段、どの作業を担当していますか」「直近で依頼を見落とした場面を教えてください」 | 担当業務、いつ・誰と・何をしていたか |
| 7〜17分 | 「そのとき最初に何をしましたか」「次にどうしましたか」「どこで困りましたか」 | 実際の順序、困った箇所、可能なら画面上の操作 |
| 17〜24分 | 「そのあとどう対応しましたか」「対応しなかった場合、何に影響しますか」 | 回避策、かかる手間、影響を受ける業務 |
| 24〜28分 | 「今回はどこで依頼に気づきましたか」「同じ作業で困らなかった場面はありますか」 | 気づいたきっかけ、うまくいく条件との違い |
| 28〜30分 | 「今日のお話をこう理解しました。違う点や補足はありますか」 | 認識の修正、未確認点、次の連絡についての合意 |
冒頭では、記録の用途と共有範囲も説明します。録音や録画をする場合は先に同意を得て、断られたらメモに切り替えます。画面共有を頼むときも、見せられる範囲だけで構いません。顧客名などは隠してもらい、実際の承認や送信をその場で行う必要はありません。
「いつもそうです」を、直近の1回に戻す
「いつも通知に気づきません」という答えだけでは、どこに原因があるかは分かりません。「最後に気づかなかったのは、いつの依頼でしたか」と尋ね、覚えている場面を起点にします。思い出せない部分は、無理に埋めず未確認と残します。
説明を聞いても手順がつながらない場合は、「話せる範囲で、そのときの流れを見せてもらえますか」と頼めます。ただし、その場で再現した操作と、実際の業務中に起きた操作は区別が必要です。再現で分かったことを、過去の出来事そのものとして記録しないでください。
影響の数字は、何を基にした答えかも聞く
「毎回10分ほどかかります」と言われたら、「直近の作業を振り返った目安ですか。それとも記録がありますか」と確かめます。本人の見積もりなら、そのまま自己申告として残します。
この10分は質問の例で、特定製品や顧客の実績ではありません。記録がない数字を測定値に変えたり、1回の話から月全体の損失を断定したりしないことが必要です。
答えを誘導する質問を、出来事を尋ねる質問に変える
聞き手が解決策を先に示すと、相手はその案への賛否を答える会話になります。提案を評価したい場面は別に設け、背景を聞く間は、相手が行ったことを尋ねます。
| 避けたい聞き方 | 言い換え例 |
|---|---|
| 「通知が増えたら便利ですよね？」 | 「直近の依頼には、どこで気づきましたか？」 |
| 「なぜ見落としたんですか？」 | 「依頼が来てから気づくまでを、順に教えてください」 |
| 「普段はどう使っていますか？」 | 「最後にこの作業をしたとき、最初に何をしましたか？」 |
| 「この機能があれば使いますか？」 | 「今、その作業をどう済ませていますか？」 |
| 「ほかの人も困っていますか？」 | 「一緒に作業する人から、どんな連絡を受けましたか？」 |
相手が「通知が欲しい」と話したら、その言葉はそのまま残します。聞き手の役割は、その案を否定することでも、すぐ採用することでもありません。「通知が届くと、そのあと何をできるようになりますか」と続け、達成したい作業を確かめます。
発言・観察・解釈を別の欄に記録する
以下は、架空の業務ツールと参加者を使った記録例です。アーコレや実在する顧客の機能・発言・実績を示すものではありません。
| 区分 | 記録例 |
|---|---|
| 発言 | 「依頼が来た日は外出していて、翌朝、担当者から連絡をもらって気づきました」 |
| 観察 | インタビュー中の再現では、参加者はホーム画面から一覧を開き、未処理の申請を探した。過去の見落とし場面は観察していない。 |
| 解釈・仮説 | 通知の数より、確認する場所や担当の決まり方に問題があるかもしれない。まだ原因は確定していない。 |
| 次に確かめること | 外出しなかった日の確認手順と、ほかの担当者への引き継ぎ方を聞く。 |
GOV.UKの調査分析ガイドでは、見聞きした内容を、それが何を意味するかという解釈と分けて記録しています。上の表もこの区別を使っています。発言が正確に残っていなければ、引用符で囲まず「発言の要約」と明記してください。
聞かなかったことと、聞いたが答えが分からなかったことも区別します。「影響なし」と「影響を未確認」は同じではありません。画面を見ていない回の観察欄は、無理に埋める必要はありません。
聞き終えたら、次に確かめることを1つ選ぶ
終了時には「困っていたのは、依頼の存在に気づかず承認が遅れる点だと理解しました」のように要点を返し、相手に修正してもらいます。そのうえで、追加確認の可否や連絡方法を決めます。実装や時期が未定なら、その場で約束しません。
記録役と見直すときは、元の要望、背景、仮説、未確認点をつなげて残します。通知を増やす案のほかに、確認場所を変える案が考えられても、この1回だけで優先順位は決められません。まずは違う条件で作業する人にも同じ問題が起きているか、確かめる対象を選びます。
調べた内容を計画へつなげる段階は、プロダクトロードマップの作り方で扱っています。聞き取りの時点では、具体的な出来事と解釈を分け、次の調査で何を確認するかが分かる記録を残してください。
