組織がユーザー調査を行わない理由と、それを変える方法
組織は、時間やコスト、否定的なフィードバックへの恐れといった言い訳を理由にユーザー調査を避け、その結果、プロダクトに関する意思決定が不適切になり、リソースを無駄にしている。
（U-Site編集部注：この記事における「ユーザー調査」には、ユーザーを調査対象とした「ユーザー理解のための調査」だけでなく、ユーザビリティテストや受容性調査のような、プロダクトやコンセプトを評価対象とした「ユーザー参加型の調査」も含まれます）
新しいプロダクトや機能を作る前に、ユーザー調査を行っていない組織が依然として多すぎる。私が調査を始めてから30年ほど経つが、人々はいまも同じ言い訳をする！
そこで、私の長年の経験に加えて、心に深い傷を負った多くのシニアユーザーリサーチャーとの議論も踏まえ、我々が「調査を多少するのが妥当だ」と提案すると、創業メンバーやリーダー、プロダクトマネージャーから返ってくる、よくある言い訳をリストアップしてみた。
「時間がない！」
この言い訳は90年代から聞き続けているが、（どういうわけか）まず間違ったものを作る時間はしっかりあるのに、その後、高額なコンサルタント（私）を雇って、それを修正させようとする人々から聞くことが多い。
これには、「エンジニアがデザインを待っている！」のような似たようなパターンもある。断言するが、ゼロから新規開発をするチームというまれな例外を除けば、そうしたエンジニアには、不適切で未調査の誰にも望まれていない機能を作らずとも、修正しなければならない技術的負債が何か月分も積み上がっているものだ。
反論例
- 間違ったものを作るほうが、それが間違っていることに気づいて（ときには複数回）作り直すことになるので、顧客が必要とし望んでいるものを理解したうえで1回目からおおむね正しいものを作るよりもはるかに長く時間がかかる。
- 調査にはそれほど時間はかからない。我々のウェブサイトには、品質を犠牲にすることなく迅速かつ効率的に行える調査手法の優れた例が多数ある。
- ユーザーニーズを満たさない新しい機能をリリースすることは時間の無駄であり、ユーザーをいら立たせる格好の方法である。
- 次に何を作るかについて会議でうんざりするほど議論するほうが、何人かのユーザーと話をして、彼らの最優先事項がビジネス目標に役立つ方法を特定するよりも、はるかに時間を食う。
- エンジニアが退屈しているなら、一緒に調査セッションに参加すればよい。そうすれば、自分たちが誰のためにプロダクトを作っているのかについて何か学べるかもしれない。
「調査は費用がかかりすぎる！」
だが、本当にそうだろうか。
そう感じる人がいるのもわからなくはない。ゼロから調査チームを立ち上げたり、高額なコンサルタントを雇ったりすると費用がかさむからだ。
この言い訳への反論は、「時間がない！」への反論とほぼ同じだ。ただし、付け加えておきたいことが2点ある。
反論例
- ユーザーの話を聞くために何人かの人にお金を払うよりも、もう一度作り直すほうが高くつく。
- 追加する最善の機能について皆が互いに大声を上げるような会議は、参加メンバー全員の給与を考慮すれば、安くはない。ユーザーセッションを何回か行ったほうが、はるかに安い費用で疑問への回答が得られる。
- ユーザーフィードバックを得るための、安価で適切な方法は非常にたくさん存在する。ユーザビリティテストは、特にリモートで行うと、支出した金額に対してどれほど多くを学べるかという点では、かなりお得と言える。既存のあるいは潜在的な顧客に数回インタビューを行ってもコストはほとんどかからない。また、自分に役立つかたちでプロダクトの改善を喜んで手伝ってくれるユーザーはたくさんいるだろう。
「人々は自分が何が欲しいかわかっていない！」
誓って言うが、もっと速い馬に関するヘンリー・フォードの偽の引用をここでもう一度聞かされたら、私は頭にきてすべてを焼き払いたくなるだろう。
問題は、人々が自分が何を望んでいるのかを知らないことではない。彼らは自分が何を望んでいるのかを正確に知っていることが多い。ユーザーは自分が「要らない」ものは明確にわかっている。そして、その答えは一般に、「適切な調査なしで作っているそれ」である。
厄介なのは、各ユーザーが欲しいものはそれぞれ微妙に違っていて、誰も他の人が何が欲しいかには興味がないということだ。また、彼らが、あなたが開発しているプロダクトの専門家であることも稀である。
ユーザーは制約を知らないし、ビジネスモデルを気にすることもない。自分が解決したい問題や自分が達成したいことを正確に伝えることはできるが、必ずしもあなたのプロダクトを使ってそれを実現する最善の方法を伝えられるわけではない。それを見つけ出すことこそが、文字どおりあなたの仕事なのだ！ 幸いなことに、ユーザー調査を適切に実施すれば、それらすべてのことを理解する助けになる。
この言い訳の別バージョンに、「彼らが求めたとおりのものを提供したのに、それは使われなかった！」がある。今もこんなことを説明しているのが信じられないが、ユーザー調査とは、人々がどんな機能を望むのかを尋ねて、その後、言われたとおりのものを作るためのものではない。
ユーザー調査とは、人々のニーズや動機、問題を理解し、プロダクトチームが、そうしたニーズや動機、要望を満たすものをどのように作るのかを見つけ出す手助けをするものだ。確かに、この作業は人々が求めるものをただ作るよりも少し大変ではある。しかし、そうすることで人々が実際に望むものを生み出すことができるのである。
反論例
- より焦点を絞った調査を提案しよう。彼らが変えるつもりのある点について知見が得られるようにするとよい。調査で何度も同じことを耳にすることがときどきあるのは、プロダクトのある小さな部分を繰り返し同じやり方で調べるからだ。
- 機能のアイデアを求めるのではなく、ユーザーが直面している問題、一般的なニーズ、または行動について尋ねよう。「何を作るべきかを教えて」から「我々が作ったものの、どこが役に立ち、どこがそうでないのかを教えて」に変えることで、調査の枠組みを変えることができ、チームは問題をより包括的に解決する方法を考えられるようになる。
- また、ヘンリー・フォードの顧客が実際により速い馬を求めていたのであれば、フォードは「馬に関して、可能なら他にも変わってほしいところはあるか」と続けて質問すれば、顧客の実際のニーズを活かす新製品の位置づけについての本当に良いアイデアを大量に得られたはずだ、ということを指摘するのもいいだろう。
「うちの子がブサイクと言われるかも！」
さて、ここで本音の言い訳が出てきた。自分が作ったものがひどいと言われるのを聞くのはつらいものだ。それはよくわかる。しかし、やるしかない。実際、もしプロセスの十分に早い段階で人々と話をすれば、そもそも不適切なものを生み出す可能性自体がはるかに低くなるので、あなたの愛しいプロダクトについてひどいことを言われるのを聞かずに済むかもしれない。
組織の学びを妨げている要因が、誰かの自尊心を傷つけるものを知ることへの恐れである場合もある。これは特に、創業者がリーダーシップを取っている企業に当てはまる。そこでは、初期のプロダクトは誰かの「✨素晴らしいアイデア✨」の結晶なので、人々がそれを素晴らしいと思わないかもしれない、ということを彼らは単に考えたくないのだ。
Just Enough Research（邦訳『最善のリサーチ』）の著者であるErika Hallは、こう言っている：
「『リサーチをする時間がない』というのは、たいてい『組織の根幹を支える神話を崩すようなことを知るリスクは冒せない』ということと同義である。実際に時間がないことが本当の理由ということは決してない。」
反論例
- 中にはあまりかわいくない子もいる。しかし、ほとんどの子はそれを乗り越えて成長するものだ。プロダクトもさらに良くなるために少し手助けが必要なこともある。しかし、そのプロダクトのどこが問題なのかわからなければ、それを改善することはできない。
- それでもだめなら、もちろん、おたくの子はかわいいですね、と伝えればよい。誰だって周りからはそう言ってほしいものだろう。ただし、実際の調査結果が出たときには、その場にはいないほうがいいかもしれない。
「すべてをA/Bテストする！」
この言い訳を使う人をからかう前に、私自身、A/Bテストは多くの状況で有用だと思っているということは言っておきたい。しかし、だからといってA/Bテストが適切な定性的調査の代わりになるわけではない。単に、同じことができるわけではないからだ。
たとえば、何かを作らないとA/Bテストはできないが、プロダクトの類がまったくない段階でも潜在的なユーザーと話をすることはできる。さらに言うと、プロダクトのアイデアすら必要ない。実際、潜在的なユーザーと話をするというのは、プロダクトの良いアイデアを思いつくための素晴らしい方法である！ 定性調査は、A/Bテストよりずっと早い段階で実施できるということだ。
A/Bテストからは、なぜ結果がそうなっているのかはわからない。ある特定の指標群において、一方の条件が他方の条件より良い結果だったかどうかは確かにわかるが、ほぼそれだけだ。
定性調査は、特定の機能またはインタラクションがうまく機能する、あるいは機能しない理由のすべてを提供してくれる。つまり、ただ当てずっぽうの推測をして、その後自分が正しかったかどうかを確認するのではなく、より良い意思決定ができる。
反論例
- 何かを作ってからうまくいかないとわかり、元に戻したり急いで修正したりする羽目になるよりも、大きな変更を行う前にフィードバックを得るほうがはるかに費用がかからない。
- A/Bテストでは、どちらのデザインのほうが良かったかがわかる一方、定性調査では、なぜそのほうが良かったのかがわかる。
- 過去のA/Bテストがもたらした影響を見るとよい。すべてをA/Bテストすることにこだわる企業では、テスト対象の2つのバージョンが適切な調査データを基にしたものでないため、実質的な効果をもたらさなかったテストが山ほど積み上がってしまうことがよくある。そこで、定性調査をいくらか実施して、A/Bテストのための仮説をより適切なものにするとよい。各バージョンを作る前に人々が何を望むのかを把握できるので、効果の出る変更を行える可能性が高くなる。
さらなる言い訳
言い訳：「間違っているとわかったとしても、やり方を変えるための予算はない」
私の返答：正直に言ってくれてありがとう！ 何も変えるつもりがないなら、時間を使って調査をするのはなぜだろうか。逆に、作っているものが間違っていると前もってわかるなら、その案を完全に諦めるだけで多くの時間を節約できる。
言い訳：「調査をするということは、すでに過労状態のたった1人のUXリサーチャーにさらに負担をかけるということだ」
私の返答：リサーチャー仲間の健康状態を気遣ってくれるのはありがたいが、そうした組織はリサーチャーを増員することを検討したのだろうか。予算が厳しいことはわかるが、ここは削るところではない。さらに詳しくは、「調査は費用がかかりすぎる！」セクションで述べたとおりである。
言い訳：「調査をすると、チームに学習性無力感が生じてしまうだろう」
私の返答：他の人にこんなことを言うような人に、どう返答すればよいのかもわからない。チームの負担を少しでも軽くするなど、とんでもないことだ、とでも言いたいのか。
言い訳：「マーケティング代理店が我々の顧客データをすべて扱っているし、彼らに質問するのは気が引けるので、調査についてしゃしゃり出ないことにしている」
私の返答：もしマーケティング代理店の領域を侵したくないなら、正直、いったい何のために彼らに金を払っているのか。冗談はさておき、関係者間の縄張り争いは深刻な問題を引き起こしうる。理想的には、誰がすべてを支配するかを巡って争うのではなく、より多くの人々がさまざまな種類の調査をすることが良いことだと考えられる文化を育てるべきだ。
言い訳：「我々には何百万人ものユーザーがいるので、ほんの一握りの意見を聞いても意味がない」
私の返答：私なら喜んでユーザー全員に聞いて回ってあげたいが、その規模の調査は少し費用がかかりすぎるかもしれない。これは、ユーザー調査を理解していない人による情けない言い訳である。サンプリングも、統計も、人々のことも、理解していないのかもしれない。
人々が調査をしない本当の理由は……
以上はすべて言い訳であり、ユーザー調査についてきちんとした知識があれば、どれもあまり有効ではない。そうした人々がなぜ間違っているのかを示すのはとても容易で、ときには、適切な調査を試してみるよう説得できることさえある。
しかし、残念ながら、調査をしない理由の中には、非常によくあるうえに、はるかに克服しにくいものが1つある。悲しいことに、多くの組織では、ユーザー調査を行うことと、社内の評価や報酬の仕組みがうまく噛み合っていないのだ。
あまりにも多くの企業、特に大企業では、ユーザーに真に有益なものを提供しても、実質的なメリットがないのが実情だ。チームが評価されるのは、新しい機能を作り、迅速にリリースし、最新のトレンドを提供することだからである。
また、プロダクトがユーザーに提供され、それがうまくいかなかったとわかるころには、開発の先頭に立っていたメンバーはすでに昇進しているか、あるいは、絶対にゲームチェンジャーになる（はずの）次の大きなものを作るためにプロジェクトを移ってしまっている。ユーザーとビジネスにとって素晴らしいものを作るために少しだけペースを落とすよう彼らを説得しようとしても、うまくいくことはない。というのも、そうしたところで、社内で評価されるわけでもないし、ほとんどの場合、その機能が失敗しても罰せられることもないからだ。
残念ながら、この言い訳にどう対応するべきかについての良いアドバイスは私も持ち合わせていない。せいぜい「さよなら」と言って、そこから去るくらいしかないだろう。
参考文献
Hall, E. 2024. Just Enough Research: 2024 Edition. Mule Books. 202 pp. ISBN 979‑8989358717.日本語訳：Hall, E. 2024. 最善のリサーチ. マイナビ出版. 248 pp. ISBN 978-4839984755.
記事で述べられている意見・見解は執筆者等のものであり、株式会社イードの公式な立場・方針を示すものではありません。
