UXリサーチは、ただの調査報告で終わらず有用なデータになるまでこだわろう。
たしか且つ有用なリサーチ結果のための概念的手順
UXリサーチのおおまかな手順
UXリサーチの大まかな手順は、およそ下記の順番に当てはめることが出来ます。
- 仮説定義・発見
- 調査
- 分析・インサイト発掘
- 分析結果を多角的に確認
- 発掘したインサイトやニーズの再現性・強さの確認
この内、ビジネスにとってもっとも重要なのは5です。ですが様々な要因でそこまでリサーチ行動が行われず、4…あるいは3くらいまでの調査結果を単純にレポートしている現場もあります（過去の自分への次回も込めて）。
そういったレポートの内容は「こういう風に調べたらこういうデータとインサイトが見つかったので、こういう風に使えると思います」という性質のものです。
もちろんこれでもリサーチャーから見ると十分ビジネスにヒントを与える材料ですが、ビジネス視点ではいくつかの点で見落としがあり、不安に思われることがあります。
せっかくなのでもう一歩踏み込んで、UXリサーチがより実感を持って重宝されるようになるといいなと思います。
そこで今回は、しっかり上記の5までやりきることについて考えてみます（1〜3については触れません）。
分析結果を確認する好奇心
リサーチ結果は、1度のリサーチや単一の方法で行われただけでは信頼性に大きな不安があります。
例えば顧客にユーザーインタビューを行ったとして、その発話や分析結果の中にその発話者の嘘が紛れ込んでいる可能性は捨てきれませんよね？
あるいは、アンケートを行ったとして、注目した分析結果が回答者のテキトーな回答から成り立っていないとは限りませんよね。
こういった「本当かな？嘘じゃないかな？」というポイントに関心を持ちそれを確認する好奇心は、リサーチ結果を活用して成果を上げる方針において重要な素養です。
分析結果を確認する とはどういうことか？
リサーチ結果を確認する方策としてまずシンプルでよく行われるのは、多角的に確認するというやり方です。
例えばアンケートの分析結果でインサイトらしきものが見つかったなら、追加アンケートやヒアリングでより確度の高い情報へ仕上げたり、
インタビューの結果見つかったJobs to be Doneを行動観察やプロトタイプを使ったユーザーテストで確認したりといった具合です。
1つのデータだけを信用することは重大なバイアスによる意思決定ミスにつながるため、こうやって避けていくわけです。これはUXリサーチに限ったことではなくマーケティング・リサーチの世界でも同じことが言えますよね。
リサーチャーたるもの「このアンケートではこういう結果が出たんだからこれが正しいんだ」といった気持ちはバイアスであるという自覚を持って、思い込みを積極的に捨てていきます。
この方針に従うならば、リサーチャーやリサーチチームの行動方針は、「単一の各リサーチは基本的にキャンペーンでしかなく複数のキャンペーンを連ねた戦役的リサーチ行動こそがビジネスに対し価値がある」という風になっていきます。
発掘したインサイトやニーズへの責任
さて、上記の内容は、冒頭で示した内4にあたります。しかしこれだけでは、いくつかの見落としをはらんでいる可能性が小さくありません。
それは、リサーチ結果の有用性の欠如という可能性です。
例えば、
「そういうインサイトがあるのは分かったけど、これはユーザーはお金を払って解決したいと思うくらい強いインサイトなの？（ちゃんとビジネスになるの？・成果につながるの？)」
「思っていたようなJobs to be Doneが発見できなかったけど、それは解決不要だからなの？それともニーズへの自覚や課金の機会が無かっただけなの？」
といった疑問への解をリサーチ結果が持っていないことがあります。これはUXリサーチを行う上で放置していい可能性ではありません。
なぜなら、
- この確認が出来なければ、新しいソリューションや新しい市場について、それがビジネスになるのかボランティアにしかならないのか分からない
- そしてUXリサーチはアカデミックな行動ではなくビジネスのための行動だから です
UXリサーチでは、誰よりもユーザーへの理解と共感を持たなければならないのと同じくらい、誰よりもリサーチ結果がビジネスにもたらす成果への責任を果たさねばなりません。
比較として、アカデミックな世界であれば「Limitation」といって、このリサーチ結果はあれこれという条件のもとで行われたものでありどれそれを保証するものではありません、といった注釈をしたりします。
でも、同じことを事業付けのUXリサーチャーが言ってしまうと責任逃れに見えてかなり頼りないですよね。
客観的にはUXリサーチャーという職能や職種に求めるべき責任ではありませんが、リサーチャーの主観や心がけとしては持っておくべきこだわりです。
インサイトやニーズの再現性・強さを確認する とはどういうことか？
では、そうした可能性を払拭するリサーチ行動としてはどういうものが考えられるでしょうか。
こちらもやり方は色々考えられますが、よく知られている方法論としてはPoCアプローチやMVPアプローチがあります。
PoCとは、Proof of Conceptの略で、「概念実証」という意味です。新しい概念や理論、原理、アイディアの実証を目的とした、試作開発の前段階における検証やデモンストレーションを指します。(中略）
M2M、AI（人工知能）など「新しい概念」に基づいたサービス提供においては、付加価値やサービス、ソリューションの仕様を検証・実証する際に、重要なプロセスとなります。
── 引用：キーエンス実用最小限の製品（じつようさいしょうげんのせいひん、Minimum Viable Product、MVP）は、初期の顧客を満足させ、将来の製品開発に役立つ有効なフィードバックや実証を得られる機能を備えた製品のバージョンを指す
── 引用：Wikipedia
どちらも著名な概念なのでここまでお読みいただいている方ならば各々の解釈があると思いますが、
1つ言えることは、どちらも「Limitation」の先の世界を見ているということ。そしてその方法としてリリースしてフィードバックを得る行動を取っているということです。
既存の世界での行動を調べたら、これから作る世界を作ってみてその世界での行動を調べるのです。アンケートをとったりユーザーインタビューするだけがリサーチではないんですね。
この方針で、前述の疑問それぞれを例にどんなことができるか考えてみましょう。
「これはユーザーがお金を払って解決したいと思うくらい強いインサイトなの？」と言われたら
これは難しい問題ですよね。
これに対しては、
例えば実際にモノや契約を売るという方法でリサーチを行います。
例えばプロダクト開発やIoT開発などでは、クラウドファンディングをテストマーケティングとして活用し、コンセプトとモックの段階でどのくらい購入されるか検証するケースがたくさんあります。
あるいはSaaS企業に多く見られるのは、
はじめは特定の数社にERPとしてプロダクト開発・運用を提供し、彼らのニーズを検証・把握し、その結果をもとにSaaSとして開発を進めるという方法です。
「めぼしいJobs to be Doneが発見できなかったけど、それは解決不要だからなの？ニーズへの自覚や機会が無かっただけなの？」と言われたら
これはもっと難しい問題です。
「Jobs to be Done」は、観測できればそれだけで半分以上ニーズの確認は完了するのですが、これはその正反対のケースです。
ニーズは本当に無いのか？という問いと同義なので、半ば悪魔の証明とも言えます。
しかし深いドメイン知識に依った成功体験があったり1つのソリューション案へ執着しがちな企業やチームでは高確率で発生します。無視すればそういった現場でのUXリサーチへの信頼は失われてしまうでしょう。
ここでも出来ることは、やはり作ることです。
リーンキャンバスやストーリーマップを作って、クリティカルな要素を重視したMVP（あるいはバッチサイズ）を定義してリリースします。
便宜上MVPとは言いましたが、ニーズの検証がリサーチの主眼なので、必ずしもViableである必要はありません。むしろとにかく壊す前提で作る方針が適しています。
例えばtoBの新ソリューションであれば、ホワイトペーパーLPという手段はいい選択肢かもしれません。あるいはITプロダクトであれば、あちこちでハードコーディングされたハリボテプロダクトだってアリです。
先達としてはSpotifyやAirbnb、あるいは数年前にムーブメントになったクリプト系のプロダクトなど、ニーズがあるのかよく分からないような新しい市場を開拓したプロダクトたちもこのようなアプローチから生まれています。
まとめ
UXリサーチをよりビジネスにとって有用にするためには、単一のリサーチ結果を過度に信用せず、好奇心を持って多角的・戦役的にリサーチ行動を進めましょう。
また、リサーチはアンケートをとったりインタビューするだけとは限りません。ビジネスへの有用性への責任感を果たすために、PoCやMVPの概念をもとに作ったり売ったりすることもリサーチ手段の1つです。
ニュースレターへ移行のお知らせ
当ブログは別媒体へ移設・移行されました。新たにニュースレターとして運営いたしております。フォロワーの皆さまにおかれましては、下記から無料購読くださいますと、引き続き情報を入手できます。
移設先のメディア：https://uxman2020.substack.com/
