目次
ユーザーリサーチとは、体系的にユーザーと接し、その行動を観察し、フィードバックを集めることで、プロダクトやビジネスの意思決定に根拠を与える仕事です。その価値はユーザーを知ること自体にあるのではなく、ある具体的な意思決定が推測に頼る部分を減らすことにあります。この記事を読むと、主なリサーチ手法がそれぞれどんな問いに答えるのかを区別でき、問いを立ててから結論を届けるまでにどんなステップを踏むのかがわかり、リサーチを始める前に答えておくべき問いのリストが手に入ります。
ユーザーリサーチとは
ユーザーリサーチが扱うのは人です。どんな人なのか、何を成し遂げたいのか、どんな状況で製品を使うのか、どんな困難にぶつかったのか、そしてどのように選択をしたのか。対象は既存ユーザーや離脱ユーザーのこともあれば、まだ製品を使ったことのない潜在ユーザーのこともあります。
日常的なユーザーフィードバックの収集とは異なります。アプリストアのレビュー、サポートの問い合わせ、営業からの伝聞はどれも価値のある手がかりですが、こうした声は自ら発信する一部の人から来ており、事前に設計されたものでもありません。ユーザーリサーチでは、まず答えたい問いを決め、次にふさわしい人と手法を選んで証拠を集め、最後に証拠を検証可能な結論にまとめます。
ユーザーリサーチが答える問いの種類
リサーチの問いの多くは、以下の5つの種類に分けられます。まず自分の問いがどの種類にあたるかを判断すれば、手法を選ぶときに間違えにくくなります。
- ユーザーは誰で、何を成し遂げたいのか：層ごとの目標、利用状況、代替手段。Jobs to be Done（Clayton Christensen）が提唱した考え方は、まさにユーザーが成し遂げたいジョブを起点にニーズを理解するものです。
- なぜそうなるのか：ユーザーはなぜ離脱するのか、なぜお金を払わないのか、なぜ競合を選んだのか。こうした問いは、インタビューで具体的な体験と理由を聞き出す必要があります。
- 問題なく使えるか：ユーザーが登録、注文、設定などの重要なタスクを自力で完了できるか、どのステップでつまずくか。
- 何人いるか、割合はどのくらいか：あるニーズや問題がユーザーの中でどのくらいの比重を占め、層によってどれだけ差があるか。
- 変更に効果があったか：新しいデザイン、文言、価格をリリースしたあと、主要な指標が本当に変化したか。
最初の2つは探索と説明にあたり、通常は定性的な手法を使います。後の2つは測定と検証にあたり、通常は定量的な手法を使います。1つのプロジェクトで、いくつかの種類の問いに順に向き合うことはよくあります。
主な手法の一覧
| 方法 | 主に答える問い | 長所 | 限界 |
|---|---|---|---|
| ユーザーインタビュー | なぜか、どのように起きたか、ユーザーが何を成し遂げたいのか | 具体的な体験や動機を深掘りでき、事前に想定していなかった問題を発見できる | サンプルが少なく、割合は推定できない。結果が質問の仕方に左右される |
| ユーザビリティテスト | ユーザーがタスクを完了できるか、どのステップでつまずくか | 実際の操作を直接見られる。Nielsen（2000）は、1回あたり約5人で大半のユーザビリティ上の問題を見つけられるとしている | 既存のデザインやプロトタイプの評価にしか向かず、作るべきかどうかには答えない |
| アンケート | 何人いるか、割合はどのくらいか、層ごとにどれだけ差があるか | サンプルが大きく、統計的な比較ができ、コストが比較的低い | 事前に想定した質問しかできない。回答は回答者の自己申告であり、実際の行動と同じとは限らない |
| フォーカスグループ | ある層の人々が、あるテーマについてどんな考えを持っているか | 一度に複数の人と接し、異なる意見がぶつかり合うのを聞ける | 発言の多い少数の人に引っ張られやすく、個人の行動の細部を知るには向かない |
| ダイアリー調査 | 一定期間の中で行動がどのように起こり、変化するか | 出来事が起きた時点に近いタイミングで記録でき、繰り返される行動や状況が見える | 期間が長く、回答者が途中で離脱しやすいため、継続的なフォローが必要 |
| 行動データ分析 | ユーザーが実際に何をしたか、どの段階で離脱したか | 全ユーザーをカバーし、自己申告ではなく実際の行動を反映する | 何が起きたかはわかっても、なぜかはわからない。トラッキングの品質に左右される |
| A/B テスト | ある変更が指標の変化をもたらしたかどうか | 因果関係を確認でき、結論をそのままリリースの判断に使える | 十分なトラフィックと時間が必要で、すでに作った案どうしの比較しかできない |
これらの手法は2つの観点で分類できます。1つは、ユーザーが何を言ったかを見るのか、何をしたかを見るのか。インタビューとアンケートは前者、行動データ分析と A/B テストは後者です。もう1つは、「なぜ」に答えるのか、「どのくらい」に答えるのか。言うこととすることはしばしば一致しないため、重要な結論はできれば両方の証拠を備えているのが望ましいです。
リサーチの基本的な流れ
- ビジネス上の問いと下すべき意思決定を明確に書きます。たとえば「オンボーディングを5ステップから3ステップに減らすべきか」。あわせて、誰がいつその決定を下すのかを確認します。
- ビジネス上の問いをいくつかの具体的なリサーチの問いに分け、それぞれがどの種類にあたるかを判断してから手法を選びます。
- リサーチの対象者を決める：どんな条件の人を探すのか、層ごとに何人必要か、どこからリクルーティングするか。
- リサーチの材料を準備する：インタビューガイド、テストのタスク、アンケートの設問、実験の設計。本番の前に小規模で一度試します。
- リサーチを実施し、その過程で元の材料を記録し、条件に合わないサンプルや明らかにおざなりなサンプルを除外します。
- 分析して結論にまとめる：各結論について、証拠がどこから来ているのか、何人に関わるのか、反対の事例があるかを示します。
- 結論を担当チームに渡し、それにもとづいてどんな変更を行うか、変更のリリース後にどのデータで検証するかを取り決めます。
リサーチの範囲は、下すべき意思決定によって決まります。どんな意思決定をするのか説明できないなら、いったん立ち止まってそれをはっきりさせてから、手法を議論します。
- このリサーチはどの意思決定を支えるものですか？誰が、遅くともいつまでに決めますか？
- このリサーチがなかったら、チームは今どう決めるでしょうか？何を根拠にしますか？
- 私たちはすでに何を知っていますか？既存のデータ、フィードバック、過去のリサーチには何がありますか？
- 一番明らかにしたい問いを3つ挙げると何ですか？それぞれどの種類にあたりますか？
- どんな結果が出たら、当初の方針を変えますか？
- どんな人を対象にリサーチしますか？どうやって見つけますか？除外すべき人はいますか？
- どの手法を使いますか？なぜその手法で上の問いに答えられるのですか？
- どれくらいのサンプル、時間、予算が必要ですか？誰が実施しますか？
- 結論を誰に渡しますか？どんな形で届けますか？
- 変更のリリース後、どの行動データや指標で結論が成り立つかを判断しますか？
- どんな個人情報を扱いますか？回答者にどう伝え、どう同意を得ますか？
いつ行うべきか、いつ不要か
リサーチを行う価値がある場合
- 意思決定のコストが高く、後戻りが難しい。たとえば新市場への参入、コアとなるフローの作り直し、価格の変更
- ユーザーについてのチーム内の見方が大きく分かれていて、どちらも証拠を出せない
- 指標に明らかな変化が出たが、理由を説明できない
- なじみのない層に向けて製品を作る。たとえば新しい地域、新しい業界、新しい年齢層
- 大きな開発リソースを投じる前に、ニーズが本当に存在するかを確かめたい
行わなくてもよい、または軽くすませてよい場合
- 変更が小さく、すぐにリリースでき、いつでも元に戻せる。先にリサーチするより、そのままリリースしてデータを見るほうが時間を節約できる
- 意思決定がすでに下されていて変わらない。この段階のリサーチはお墨付きを与えるだけになる
- 既存のデータや過去のリサーチで、すでにこの問いに答えられる
- トラフィックが十分にあり、A/B テストで複数の案を直接比較できる
- 問題そのものが技術上またはコンプライアンス上の制約で、ユーザーの意見では結果が変わらない
リサーチをしないことは、ユーザーを見ないことではありません。小さな変更でもリリース後はデータを見てフィードバックを読みます。専用のプロジェクトを立てる必要がないだけです。
よくある誤り
以下の誤りは、リサーチを始めたばかりのチームで最もよく見られるものです。多くは、問いが整理できていない、手法の選び方を誤っている、結論の使い方を誤っていることに関係しています。
よくある間違い
- 欲しい機能をユーザーに直接聞く：ユーザーは自分の体験や困りごとを語るのは得意ですが、解決策を設計するのは得意ではありません。最近問題にぶつかったときにどうしたかを聞くべきです。これについては『The Mom Test』（Rob Fitzpatrick、2013）で詳しく論じられています。
- インタビューの結果から割合を推計する：十数人の回答者のうち半数があることに言及したからといって、ユーザーの半数がそうだとはいえません。割合が必要な場合は、アンケートや行動データで検証します。
- 最もアクティブで協力的なユーザーだけを探す：その人たちの見方は、声を上げない多数派や離脱ユーザーとは違うことが多いものです。リクルーティングではリサーチの問いに基づいて条件を決め、あまり出てこない層も意識してカバーします。
- リサーチが終わってから使い道を考える：結論はたくさんあるのに、どの意思決定にも結びついていない。プロジェクトを立ち上げる時点で、結論を誰に渡し、何を決めるのに使うのかを明確にしておきます。
- 1回のリサーチを決定的な結論とみなす：ユーザーも市場も変化し、リサーチの結論にも当てはまる層と時期があります。重要な結論は、変更のリリース後にデータで再確認します。
- ユーザーが言うことだけを見て、することを見ない：自己申告と実際の行動はしばしば一致しません。可能であれば、インタビューの結論と行動データを突き合わせて見ます。
heari での進め方
heari では、ビジネス上の問いと下すべき意思決定を入力すると、AI がリサーチプランとインタビューガイドを作成します。AI はテキストまたは音声で複数のインタビューを同時に行い、回答に応じて深掘りします。レポートの各インサイトには発言の原文と反例が添えられ、人数が明記されており、1件ずつ承認・修正・却下できます。ThinkingAI Agentic Engine と連携すれば、行動にもとづいて回答者を抽出し、変更のリリース後に行動データで結論を検証できます。
よくある質問
ユーザーリサーチと市場調査は何が違いますか？
両者は重なる部分がありますが、重点が異なります。市場調査は市場規模、競争環境、ブランド認知に重点を置き、大規模なサンプルのアンケートをよく使います。ユーザーリサーチは、具体的な人がどのように製品を使い、どんな困難にぶつかり、なぜある選択をしたのかに重点を置き、インタビュー、ユーザビリティテスト、行動データをよく使います。プロダクトチームが意思決定をする際には、両方の情報が必要になることが多いです。
専任のリサーチャーがいない小さなチームでも、ユーザーリサーチはできますか？
できます。プロダクトマネージャー、デザイナー、運用担当者も、リサーチ責任者の役割を担えます。まずは目的が明確な小さなリサーチから始めます。たとえば1つの意思決定をめぐってユーザー6〜8人にインタビューする、あるいはユーザー5人に新しいフローを試してもらうといったものです。そのうえで、リクルーティングのチャネルと資料のストックを少しずつ整えていきます。大切なのは、支えたい意思決定を事前に明確にし、終わったら結論を担当者に渡すことです。
ユーザーリサーチには、ふつうどのくらいの期間がかかりますか？
手法と規模によります。1回のユーザビリティテストや十数件のインタビューなら、準備から結論が出るまでふつう1〜3週間かかり、その中でも回答者のリクルーティングに最も時間がかかることが多いです。ダイアリー調査は十分に長い利用サイクルをカバーする必要があり、A/B テストはサンプルサイズが十分になるまで待つ必要があります。時間が限られている場合は、分析やレビューを省くのではなく、リサーチの問いの範囲を絞ります。
ユーザーリサーチの結論は、どうすれば信頼できるといえますか？
信頼できる結論とは、証拠がどんな人の何人から来ているかを説明でき、元の記録までたどれ、反対の事例と適用範囲も明記されているものです。定性的な結論が示すのはどんな状況があるか、なぜ起きるかであり、定量的な結論が示すのは割合と差です。重要な結論は、変更のリリース後に行動データや実験でもう一度検証するのが望ましいです。
