誤解を招く結果を生む、ユーザーリサーチの5つの間違い

FabricLoopチームによる · 2026年5月 · 4分で読めます

リサーチを一切しないよりも悪いユーザーリサーチがあります。自信満々でありながら間違った結論を導き出すリサーチです。リサーチをしないチームは、自分たちが仮定に基づいて動いていることを自覚しています。一方、質の悪いリサーチをしたチームは、根拠を手に入れたと思い込み、それ以上探すのをやめてしまいます。

以下の5つの間違いは、めったにない特殊なケースではありません。ほとんどのプロダクトチームで、たいてい起きていて、内部からは驚くほど気づきにくい形で現れます。

「ユーザーリサーチの目的は、自分の直感を裏づけることではありません。直感を根拠で置き換えることです。自分が間違っていたという根拠も含めて。」

5つの間違い

誤り

実際にはどう現れるか

間違い1 仮定の未来の行動について尋ねる

チームは「Xをする機能があれば使いますか？」と尋ねます。ユーザーは「はい」と答えます。チームはそれを作ります。誰も使いません。人は未来の自分に楽観的で、自分が実際に何をするかを判断するのが下手です。尋ねるのは、必ず過去の行動についてにしましょう。「最近Xに対処しなければならなかったときのことを教えてください。」

間違い2 すでにプロダクトを気に入っているユーザーだけにインタビューする

ヘビーユーザーや支持者ばかりのリサーチパネルからは、好意的で前向きな、改善を中心としたフィードバックが得られます。しかし、人がなぜ離れたのか、なぜ有料に転換しなかったのか、新しいセグメントに届くためにプロダクトに何が必要なのか、といった洞察は得られません。解約したユーザーや、使っていない人にも話を聞きましょう。耳の痛い話ですが、不可欠です。

間違い3 既存の思い込みを裏づける誘導質問

「新しいダッシュボードはどのくらい役に立ちましたか？」は誘導質問です。「最近ダッシュボードを使ったときのことを教えてください」はそうではありません。誘導質問が引き出すのは、礼儀としての同意であって、正直な評価ではありません。リサーチャーの仮説への思い入れは質問の言い回しににじみ出て、ユーザーは空気を読んで、その合図に従います。

間違い4 「何」で止まり、「なぜ」を聞かない

ユーザーが「リストを絞り込める機能が欲しい」と言いました。リサーチャーは「ユーザーはフィルタリングを求めている」とメモします。しかし、フィルタリングはニーズではなく解決策です。ユーザーは実際に何をしようとしていて、フィルタリングはどう役立つのか。「なぜ」への答えにこそデザインの洞察があり、ユーザー自身が提案したものよりも優れた解決策が見えてくることもよくあります。

間違い5 定性リサーチを定量データのように扱う

「5人中3人が分かりにくいと言った」は統計ではありません。5人から得られた、方向性を示すシグナルです。定性リサーチで分かるのは何が起きているか、そしてなぜかであって、どれくらいの人に当てはまるかは分かりません。それを数値の精度で示すと、ステークホルダーに誤った自信を与え、規模を拡大した段階で的外れなものを最適化してしまうことにつながりがちです。

これらの間違いがなくならない理由

リサーチの間違いの多くは、動機があって起きています。チームにはすでに進みたい方向があります。作りたい機能、信じている仮説、満足させたいステークホルダー。リサーチは、それを本気で検証する試みではなく、すでに下された決定を正当化するための儀式になります。

解決策は、リサーチャー個人にもっと厳密さを求めることではありません。「何を作るかを決める」役割と、「その決定に情報を提供するリサーチを実施する」役割を分けることです。機能を提案した本人がリサーチも担当すれば、確証バイアスはほぼ避けられません。

役立つルール リサーチのセッションを始める前に、どんな結果が出たら考えを変えるかを書き出してください。それを挙げられないなら、リサーチではなく、お芝居をしているだけです。自分の仮説を覆しうる結果を言葉にできるかどうかが、本物の探究と、手順を踏んだだけの確証バイアスとを分けます。

サンプルサイズについて ユーザビリティテストなら、参加者5〜8人でほとんどの問題が見つかります。それ以上は効果が急速に逓減します。課題発見のインタビューなら、通常は12〜15人で飽和に達します。大きな母集団に定量的に当てはめたい場合は、代表性のあるサンプルを使った適切な調査が必要です。10件のインタビューでは足りません。

FabricLoopが誠実なリサーチをどう支えるか インタビューの生のノート、整理した内容、そして決定を同じスレッドにまとめておけば、都合の悪い発見を黙って捨てにくくなります。根拠が決定と並んで見えていれば、その結論が学びから導かれたのか、それとも学びより先にあったのかを、チームが確かめられます。

この記事から持ち帰ってほしい10のこと

質の悪いリサーチは、しないよりも悪い。誤った自信を生み、チームがそれ以上探すのをやめさせてしまいます。
仮定の未来の行動については尋ねない。代わりに、具体的な過去の行動について尋ねましょう。
支持者ばかりのリサーチパネルからは、好意的で改善中心のフィードバックしか得られず、人が離れる理由や有料に転換しない理由についての洞察は得られません。
解約したユーザーや非ユーザーにも話を聞きましょう。耳の痛いフィードバックですが、不可欠です。
誘導質問が引き出すのは礼儀としての同意であり、正直な評価ではありません。言い回しには十分注意しましょう。
ユーザーが解決策（「フィルタリングが欲しい」）を提案したら、必ず理由を尋ねましょう。たいていの場合、答えはより良い解決策を明らかにします。
定性リサーチで分かるのは、何が起きていて、なぜかです。どれくらいの人に当てはまるかは分かりません。数値の精度で示さないようにしましょう。
リサーチの間違いの多くは、動機があって起きています。決定はすでに下され、リサーチはそれを正当化するために使われています。
機能を提案する人と、それを評価するリサーチを実施する人を分けましょう。
リサーチのセッションの前に、どんな結果が出たら考えを変えるかを書き出しましょう。書けないなら、それはリサーチではありません。