「ユーザーインタビューで聞き取った情報はどれもファクトとして扱って良いのだろうか？」と疑問に感じた経験はないでしょうか？多くのプロダクトマネージャーがユーザーと話していると、ユーザー自身が事実と主観的な感想や思い込みを区別しきれず、結果的に感想、事実、インサイトなどが混乱して開発チームに伝わることがあります。
本記事では、プロダクト開発でしばしば混在しがちな「ユーザーのファクト」と「ファクトではないもの」を区別する方法を解説します。特にユーザーインタビューにおいては、受け取った発言をどう整理し、どこまでを事実情報として扱うのかがプロダクトの方向性を決定づけます。最後まで読んでいただくと、今日からユーザーインタビューの設計や分析、そしてチーム内の情報共有に役立つコツがつかめるはずです。
ユーザーのファクトとは何か？定義と重要性
まずは「ファクト(事実情報：客観的かつ検証可能な情報)」とは何かを定義しておきます。ユーザーインタビューにおけるファクトは、ユーザーが実際に経験した行動や数字、データで裏付けられた事象などを指します。例えば、「◯◯という機能を使って月に5本のレポートを作成しています」のように、ユーザー本人が客観的事実を具体的に述べている場合はファクトとなります。
一方、「普段からレポート作成は大変なんですよね」という発言は一見ファクトに聞こえますが、そのままでは曖昧です。
- 何がどれだけ大変なのか
- どれくらいの頻度で困っているのか
- どのプロセスで時間がかかっているのか
――これらを定量化・明確化しない限り、単なる主観的表現に留まる可能性があります。インタビューの初期段階ではもちろんこうした主観的な声も拾いますが、プロダクトの意思決定をする際は、「それがどのように証明できる事実か？」を絶えず意識する必要があります。
例えばHRテックの新機能開発で、ユーザーの「求人の入力作業が多くて手間」という声を聞いたとき、それはファクトでしょうか？
答えはNOです。ここを深ぼって、実際に画面遷移と作業時間をユーザーに測定してもらうと、作業自体は1分程度で終わり、みたいなことが普通にあります。さらにヒアリングで深掘ると、ユーザーにとっての「手間」は求人情報の入力そのものではなく、別ツールの情報整理との往復が面倒だった！など。つまり、「求人入力で時間がかかる」というのは実際には主観的な感覚であり、「異なるツールをまたいで操作するプロセスが多い」というのが真のファクト、というわけです。
ファクトではないもの：よくある3つのパターン
1. ユーザーの解釈・推測
ユーザーは自分が観察した現象や自分の経験をもとに、あくまで推測で語ることが多々あります。
例えば「新しいUIが分かりづらいから、たぶんエンゲージメントが下がっていると思うんですよね」という発言は、あくまでユーザーの解釈であって、そのUIが原因でエンゲージメントが下がっているという事実が証明されているわけではありません。
こうした「解釈・推測」をそのままプロダクト機能の意思決定につなげてしまうと、ユーザーの思い込みをベースにした設計ミスを招きかねません。解釈が出てきたときは、追加質問や定量データで検証して「実態はどうか？」を改めて確認します。
2. ユーザーの希望・要望
「こんな機能があったらいいのに」「この部分、もっと自動化してほしい」といったユーザーの要望も、一見すると“改善策”を示すようで有用に思えます。
もちろん無視して良いわけではありません。しかし、ユーザーの口から出てくる改善策・要望は、本質的な課題解決ではなく表面的な案にとどまることがよくあります。
例えばユーザーが「承認フローを増やして細かく権限管理してほしい」と要望していても、実際には「承認漏れを防ぐために不正利用がないか常に見張っておきたい」だけかもしれません。そこを深堀りしなければ「承認フローを増やす」こと自体が目的化し、本来の課題が置き去りになってしまいます。
3. 社会的望ましさやバイアスがかかった発言
「こう言ったら良い印象を持ってもらえるはず」という心理が働き、社会的に望ましい発言をするケースも少なくありません。特にユーザーはインタビュアー（プロダクト提供側）に悪い印象を与えたくない、あるいは協力している姿勢を見せたい、という無意識のバイアスがかかりがちです。
例えば「この機能自体はとても使いやすいですね」と好意的に評価する一方で、実際の利用ログを見るとほとんど使っていない、という事例があります。こうした場合、「使っているシーンをもう少し詳しく教えてください」などと深堀りしながら、本音と事実を探る必要があります。
関連するインタビュー時のバイアスや誘導尋問を防ぐ方法としては、【2025年】ユーザーインタビューで起こるバイアスを徹底攻略！ こちらの記事も参照ください。
なぜプロダクトマネージャーはファクトとそれ以外を混在させてしまうのか
プロダクトマネージャーがユーザーからの情報を鵜呑みにしてしまう理由には、いくつかの背景があります。
- プロダクトの方向性を急いで決めないといけない
- 新機能リリース直後で緊急のユーザーの声が飛び込んでき
こういった場面などで、検証を十分にせずにユーザーの意見を「ファクト」として扱ってしまうケースが起きがちです。
また、PdM自身が「こうあるべき」という仮説を強く持ちすぎている場合も要注意。ユーザーの発言のうち、自分の仮説を裏付けるような部分だけを抜き出してファクト扱いしてしまう“確証バイアス”も、混乱の原因になります。
例えば、ユーザーが「UIが複雑だ」と訴えたので、急いでUIを総リニューアルしたところ、実際にはユーザーは複雑な業務フローを抱えており、UIの問題よりもアカウント管理のワークフローが根本原因だった、などなど。要するに「UIが複雑」という声をファクトとして早合点し、深堀りや検証を怠ったまま大掛かりな改修をしてしまったのです。
ファクトを見極めるための具体的アプローチ
1. 「5回のなぜ(5 Whys)」で真の原因を探る
「5回のなぜ」では、ユーザーの発言をそのまま鵜呑みにせず、「なぜそれが起きているのか」を繰り返し問いかけます。
例えば「求人入力が面倒」と言われたら、
- 「なぜ面倒なのか」
- 「なぜそこで時間がかかるのか」
と問うことで、最終的にどの業務プロセスが問題かを特定していきます。1回の“なぜ”で十分でなければ、2回、3回と重ねて深堀りすることで、本当に解決すべき問題を浮き彫りにします。
ただ、注意点として「なぜ？」を本当に5回繰り返すと尋問になるので、以下のように「なぜ？」以外の質問の手札を持っておきましょう。
- 「どこが面倒なのか？」
- 「いつ面倒だと感じたのか？」
- 「逆に同じようなことを実行するが面倒ではないことは何か？」
2. 行動ログや画面録画、エスノグラフィー調査を活用する
エスノグラフィー調査(ユーザーの現場を観察して定性的データを得る手法)のように、実際の利用現場を見せてもらうと「ユーザーが語る大変さ」と「実際に起きている行動」のギャップがはっきりします。
例えばユーザーが「担当者とのメールのやり取りが面倒」と言っていた場合でも、現場を観察すると実際には「そもそも担当者が複数いて誰に送るか分からない」ことが問題だったりします。ログデータだけでは見えない操作フローや、現場の雰囲気を把握できるのがエスノグラフィー調査の強みです。詳しくは、インタビューより”深い”ファクトを「エスノグラフィー調査」でゲットするを参考にしてください。
3. ログ分析と併用して検証する
ユーザーインタビューだけでなく、ログ分析や行動データを組み合わせて検証するのも有効です。
ユーザーが「週3回使っています」と言っていても、ログを確認すると月に1回程度しか使っていない、ということはよくあります。ログから見える事実を対比させることで、ユーザーインタビューでの発言の真偽を見極めるきっかけになります。
ファクト収集のためのユーザーインタビュー設計：カテゴリー別の例
では、ユーザーインタビューで「ファクト」と「ファクトではないもの」を混同せずに把握するには、事前にどんなアプローチをとるべきか。ここでは、以下のカテゴリー別に具体例を示します。
- カテゴリーA：利用状況の事実
- 質問例：「週に何回、どのようなタイミングで本システムにログインしていますか？」
- 確認手段：ログイン履歴、使用時間のデータ
- 注意点：主観的な回数認識と実際のログイン記録が食い違うことがあるので要検証
- カテゴリーB：操作フローの事実
- 質問例：「申請を承認するときは、どの画面からどのボタンをクリックし、何分くらいかかりますか？」
- 確認手段：画面録画、クリック数のトラッキング
- 注意点：「時間がかかる」との主観と実際の操作手順数や所要時間が違うケースが多い
- カテゴリーC：ユーザーの解釈・感情
- 質問例：「“面倒”というのは、具体的にどの部分をどう感じていますか？」
- 確認手段：深堀り質問で裏付け、同様の発言が他ユーザーにも見られるか
- 注意点：あくまで感情はファクトではないが、複数のユーザーが共通して感じている場合は優先度の高い課題の兆し
- カテゴリーD：外部環境や他ツールとの兼ね合い
- 質問例：「他のシステムやツールを同時に使うシーンはありますか？それぞれの連携はどうなっていますか？」
- 確認手段：使用しているツールの一覧、連携状況の画面確認
- 注意点：「自社サービス内では解決不能」な課題も見つかる。事実確認が必要
事前にこういったカテゴリで質問を整理しておくと、インタビュー中に「これはファクトか」「これはただの感情や推測か」を把握しやすくなります。
チーム内でファクトを共有・管理するコツ
ユーザーインタビューで得たファクトを、プロダクトマネージャー個人の頭の中だけに留めず、チーム全員が共有しスムーズに活用する仕組みを作ることも重要です。僕が実践している方法としては、以下の3つがあります。
- インタビューのメモは「事実情報」と「感想・推測」を分けて書く
- 同じドキュメントにまとめるときも「◯月◯日Aさんインタビュー」の項目を「Fact」「Interpretation」「Hypothesis」の3つのセクションで切り分けて記載。
- 関連記事：ユーザーインタビューのメモを「極める」 – ファクトを徹底収集してインサイトを最大化
- ログや観察データを紐づける
- 言葉だけでなく、「実際にこの日時に操作ログがある」という証拠をリンクしておく。タスク管理ツールやリサーチデータベースなどでURLを貼り付ける形が多い
- インタビューレポートを短サイクルでチームに共有
- 実施直後に5〜10分だけで良いので、スクラムミーティングやSlackで「今回のインタビューで判明したファクト3つ」をシンプルに共有。
- その上で不明点や仮説をチームメンバーと議論する
「ファクトの徹底収集」から未来を妄想する
ファクトを徹底的に拾うことは、あくまでスタートライン。プロダクトマネージャーの役割は、ユーザーインタビューやログから得た事実情報をもとに、将来のユーザーニーズを予測し、機能設計や体験価値を最大化することにあります。言い換えれば、事実情報がなければ未来を「正しく妄想」することが難しいのです。
この点については、“顧客は未来を語れない”から、徹底的にファクトを集めてPdMが未来を妄想する という記事で詳しく解説しています。まだご覧になっていない方は、あわせてチェックしてみてください。
今日から実践できるアクション
- インタビュー設計で「事実情報」を引き出す質問を増やす
– 例：「週に何回ログインして、どの画面で何をクリックしていますか？」と具体的に聞く。 - ログや観察をセットで実施する
– 行動ログや画面の録画、エスノグラフィーなど複数のアプローチで事実を検証する。 - インタビューのメモを「Fact」「Interpretation」「Hypothesis」に分類
– 見返したときに、どの情報が事実ベースか判別しやすくなる。 - チームで短サイクル共有
– インタビュー直後にSlackや定例で「判明した事実3つ」を簡潔にシェアして、全員で事実を起点とした課題解決を検討する。
Q&A
- Q1. ユーザーが思い込みを語っているかどうかを見極めるには？
- A1. 一番の近道はログや実際の作業観察と付き合わせることです。また、ユーザーが何かを断言した際に「なぜそう思うのか？」「具体的にいつ、どこで？」と聞き返すことで言質を確認すると、思い込みなのか事実なのかが見えやすくなります。
- Q2. インタビュー中に「本音」を引き出すコツは？
- A2. ユーザーが話しやすい環境や、プライドや評価を気にしなくて良い雰囲気を作ることです。さらに「もう少し詳しく教えてください」「それはどんな状況ですか？」とオープンエンドで継続的に深堀りします。バイアスを最小化するテクニックとしては、こちらの記事も参考にどうぞ。
- Q3. 事実情報を取り違えたまま開発を進めてしまうとどうなる？
- A3. 典型的には「ユーザーが本当に必要としていない機能」を作り込んでしまったり、「問題の原因を誤認したUI改修」で余分な工数をかけたりします。ファクトの再確認と短いフィードバックサイクルこそが、開発リスクの低減策です。
参考情報
- Rob Fitzpatrick (2013) The Mom Test：ユーザーインタビューにおける正しい質問の仕方と、表面上の回答に惑わされないための実践ノウハウ
- Hans Rosling, Anna Rosling Rönnlund, Ola Rosling (2018) Factfulness：人が思い込みやバイアスにどのようにとらわれやすいかを多数のデータとともに紹介
- Marty Cagan (2008) INSPIRED：ユーザーの本当の課題を見つける重要性と、イノベーティブなプロダクト開発プロセスについて
- Nielsen Norman Group (2019) “How to Conduct a User Interview”：ユーザーインタビューの計画・実施時に注意すべきポイントや質問設計のガイドライン
- ユーザーインタビューの目的・設計・やり方・分析まで完全ガイド
コメント