ユーザーインタビューについて、プロダクトマネージャーであればやったことがない人はおそらくいないし、その重要性を知らない方もいないと思います。ただ、僕自身累計600回以上インタビューを実施してきましたが、すべてを網羅的にこなすのは正直なところ簡単ではありません。インタビューの設計や質問づくり、リクルーティング、バイアスへの対策など、意識すべきことは多岐にわたります。
だからこそ今回はあえて、もし「ユーザーインタビューでたった1つだけ、これだけは外せない」という視点を考えてみました。
結論から言うと、僕は「コンテクスト(文脈)を徹底的に深掘りすること」だと思います。
ユーザーが製品を使う背景や目的、そのときの環境や気持ちなどを徹底的に、ファクトベースで把握する。そこさえ押さえていれば、たとえ他の項目に多少の不備があっても大きくは外しません。逆に、この文脈を見逃すと、いくらUIや機能面を細かくヒアリングしても、根本的な課題を見つけにくくなります。
なぜ「コンテクスト」が肝心なのか?
ユーザーインタビューは、つい「UIの不満点」や「欲しい機能の要望」を聞き取る場になりがち(わかりやすいし報告しやすいですしね)。
ただ、それだけでは本当に解くべき課題にアプローチできません。なぜなら、ユーザーが抱える課題はしばしば、機能の表層を超えた「背景」や「業務フロー」そのものに潜んでいるからです。
たとえば「操作がわかりにくい」という表現だけを鵜呑みにすると、UIの色やボタン配置を見直すだけで終わってしまうかもしれません。しかし、実はユーザーの勤務形態やチーム内フローが複雑で、システムを使う段階にたどり着くまでに余計なステップが多いから「わかりにくい」と感じている可能性もあります。そこまで踏み込んで聞かなければ、根本解決につながる施策を打ち出せません。
ファクトを掘りながらコンテクストまでふみこむからこそ、ユーザーインタビューは価値を生むプロセスとして成立するのです。
コンテクスト深掘りの具体的アプローチ
文脈を知るためには、単にユーザーに「使い勝手はどうですか?」と尋ねるだけでは不十分。
必要なのは
- いつ
- どのような場面で
- どのくらいの頻度で
- 直近はいつ
- どんな体制で
- どんな心理状態で
使っているか?を事実ベースで聞き出すことです。僕がよく行う方法は、ユーザーの1日の流れや、作業の前後関係を追って尋ねるやり方です。
具体的には「午前中にこの機能を使うことが多いですか? その前後でどんな作業をしていますか?」のように聞き、業務全体の構造を把握するようにします。あるいは、実際の使用画面を共有してもらい、画面遷移や参照している資料を一緒に見せてもらうと、ユーザーがどんな文脈で機能を使っているかがよくわかります。こうすることで、「使う目的」「業務プロセス」「心理状態」といったコンテクストが明確に浮かび上がります。
観察とログ分析も活用する
また、さらにコンテクストを深く理解するうえでは、観察やログ分析も有効。
ユーザーが置かれている環境(オフィス、在宅、外出先など)によって、システムへのアクセス方法や端末が変わってくるかもしれませんし、チーム内の承認フローが絡むかもしれません。可能であれば現場を訪問し、ユーザーの実際の動作を目視する「Contextual Inquiry(コンテクスチュアルインクワイア)」を取り入れるのも手です。
オンラインサービスであれば「ログ分析→ユーザーインタビュー」のフローがおすすめです。ユーザーがどの機能を頻繁に使い、どこで離脱しているのかを定量データでつかんだ上で、インタビューで「どんな背景があって、そこで操作を止めたのか」を深堀りします。数字と会話をセットにすると、ユーザーの文脈がより明確になります。

表面ニーズと裏タスクを区別する
さらに、文脈を把握すると、「表面上のニーズ」と「本当に解決したいこと」が別物であるケースが見つかりやすくなります。ユーザーは「この機能がほしい」と言いつつ、実はその機能は単なる手段であって、本音では「めんどうな社内手続きを自動化したい」「エラー対応が多発して疲弊したくない」といった別の問題が潜んでいるかもしれません。
「裏タスク」とも呼ばれるようなユーザーの本質的ニーズを掘り起こすと、提供すべきプロダクトの方向性がガラリと変わることもあります。そこで大切なのが、
- その要望はどういう状況を想定しているのか?
- 実際に困ったエピソードがあるのか?
などを問いかける姿勢です。こうして裏に隠れている課題を引き出すことで、ユーザーが本当に求めている価値を見極めることができます。

チーム合意を得やすい「コンテクストの共有」
また、PMやUXリサーチャーがインタビューを行うときにUIや仕様の細部に目が向きがちで、ユーザーがサービスを利用する環境や状況まで踏み込めていないことがあります。しかし、ユーザーがどういう背景で使っているかをチームで共有すると、施策の優先度や方向性が明確になりやすいです。
たとえば「出社直後、複数のWebツールを立ち上げながら、同時進行でメールチェックもしているので集中できない」という文脈を共有すると、単なるUI改修だけでなく「集中度が落ちているタイミングでの通知を減らす」「シングルサインオンでログインを簡易化する」といった施策を立案できます。具体的なシーンを元に議論するため、ステークホルダーへの説得力も高まります。
組織でコンテクスト重視を浸透させる仕組み
コンテクストを重視したインタビューを実践するためには、個々人の意識づけだけでなく、組織での仕組みづくりが大切です。
たとえば、インタビューガイドに「文脈に関する質問」を必須項目として入れ、インタビュー後のレポートにも「周囲の業務状況」「前後で利用しているツール」といった項目をまとめる欄を用意します。
チーム全員がこれを当たり前の流れとして実施すれば、プロダクト開発の初期段階から深いインサイトを共有しやすくなります。ヒアリングの運営を組織として標準化する方法は「ユーザーヒアリングを組織に根付かせる4つの仕組み」でも解説しています。時間やリソースに限りがある中でも、コンテクストに焦点を当てるだけで、インタビューの質は大きく変わります。

参考情報
・Beyer, H., & Holtzblatt, K. (1997). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann.
・Norman, D. A. (2013). The Design of Everyday Things (Revised and Expanded). MIT Press.
・Rogers, Y., Sharp, H., & Preece, J. (2011). Interaction Design: Beyond Human-Computer Interaction. Wiley.
・Brown, T. (2009). Change by Design. Harper Business.
今日から実践できるアクション
- 時系列で聞く:インタビューで「利用の前後」「一日の流れ」を尋ね、文脈を明確にする。
- ログデータを事前に確認:アクセス頻度や滞在時間などを把握し、利用シーンを想像した上でヒアリングする。
- 観察の導入:可能なら現場や画面を見せてもらい、実際の操作や周辺環境をチェックする。
- 裏タスクを疑う:ユーザーが表面上の機能要望を言ったとき、その真意や隠れた問題も掘り起こす。
- チームで共有:録画やノートをチームに公開し、コンテクストを全員で理解した上で施策議論をする。
Q&A
Q1. コンテクストを深掘りしている間に、話が横道に逸れてしまいそうです。
A. 多少の脱線はむしろ歓迎です。ユーザーが思わぬ本音を話すきっかけになります。大筋を外さない程度に寄り添い、適宜話を戻しながら進めると効果的です。
Q2. 時間が限られているときもコンテクストを聞く余裕は必要ですか?
A. 可能な範囲で聞くべきです。特に前後の行動や並行している業務を確認するだけでも、課題の大枠が見えてきます。ショートカットはせず、最低限の確認時間を確保しましょう。
Q3. 既に長年使っているユーザーだと、文脈を変えにくいのではないでしょうか?
A. 長期利用者ほど「慣れ」や「諦め」が生じている場合があります。そこでこそ文脈を詳しく聞き出し、前後の作業負荷や他のツールの使い方などを深堀りすると、新しい発見があります。
Q4. コンテクストを追っても最終的にUIや機能改善の話になる気がしますが、それでいいのでしょうか?
A. 問題ありません。コンテクストを理解したうえで機能改善に着地するのであれば、より根本的・本質的なアプローチができます。見た目や操作感だけを変えるのではなく、業務全体の流れに対するソリューション設計が可能になります。
コメント