プロダクトの仮説検証には落とし穴がある

プロダクトの開発や運営は、仮説検証と課題解決の連続です。

「使いにくい」
「わかりにくい」
「もっとこうしてほしい」
「気付かなかった」

こういったユーザの声、あるいは、声として届いてはいないけど潜在的に生まれてしまっている不満に対して、問題を特定したり、解決策を考えて提供したり、情報の提供方法を工夫したりして体験価値を向上させていく。結果として数値が付いてきて事業成果が生まれてくる。

そんな事業活動の中心には、常に仮説検証があります。プロダクトの機能企画やUIデザイン改善も、何となくやっているのではなくて仮説検証ありきで存在するといっても過言ではありません。

今日は、そんなプロダクトの仮説検証をやっていくうえで気を付けなければいけない落とし穴について書きたいと思います。

はじめに

仮説検証の話をする上で、プロダクト改善がロジックベースで行われていることが前提となります。

プロダクトの機能やデザインをロジックベースで捉える考え方として、情報設計（Information Architecture: IA）を基礎に価値を積み上げていくデザインの話をこちらの記事で紹介しているので、「IAって何」という方は良かったら読んでみてください。

　＊　＊　＊

仮説検証の落とし穴

さて本題ですが、プロダクト仮説検証には落とし穴があります。

それは

結果の解釈が難しい

ということです。

仮説自体はロジックベースで定義できるものが大半だと思いますし、社内のプロダクトチーム間もロジックベースで会話をしていると思いますが、ユーザさんは違います。

プロダクトチームは、↓のような内容を考慮して仮説検証を進める必要があります。

・ユーザが見るのはUIだけ（IAは見えない）
・VDやインタラクションが結果に与える影響が大きい
・ユーザがアプリを使うときの状況まではわからない

ユーザフィードバックや数値が手に入ったとして、その結果がどういう意味を持つか判断するためには、人間の解釈を必要とします。

（ポジティブな結果）
　→  IAが良い？VDが良いだけ？

（ネガティブ結果）
　→  IAが悪い？VDが悪いだけ？

ここの解釈によって、仮説検証結果として社内に蓄積されていく知見の内容も、次にとるべきアクションも大きく変わってきます。

「誤検知」と向き合う

結果の解釈を行うときに、どんなパターンがあるか図にしてみました

例えば今回、普段よりも良い結果が得られたとしましょう。

このときに意識すべきなのは、「我々は解釈を間違う可能性がある」ということです。

「本当はA~Dのどれなのか」
　　vs.
「我々がA~Dのどれだと解釈したか」

普段よりも良い結果が得られたとしても、実は季節的な理由であがっただけだったり、とあるインフルエンサーが取り上げてくれたという特需のおかげだったりで、実際はIAもVDも影響なしというケース（D）も全然ありえます。

また、1番避けたいシナリオとして、本当はB（IAは良くないがビジュアルデザインのおかげでごまかせてしまった）なのに、A,C（IAが良かった）と誤認してしまうケースにも注意が必要です。

こういった「真実」×「解釈」のマッチングにはそれぞれ名前が付いているのでご紹介します。

覚えにくく感じるかもしれませんが、こんな風に考えていただけるといいかと思います。

・True/False: 正解か誤検知か
・Positive/Negative: 結果として陽性に解釈したのか陰性に解釈したのか

ちなみに、統計の世界では誤検知について↓のような呼び方をしたりもします。

・False-Positive（誤検出）：Type I Error
・False-Negative（見逃し）：Type II Error

最悪のケースはどちらでしょう

意思決定をする際に、最悪のケースを確定させておくことは非常に重要です。迷っていて手掛かりが少ないときに、最悪のケースを避けるような意思決定を考えることができるからです。

さて、誤検知してしまうにしても、False-PositiveとFalse-Negativeでは、どちらの方が「まだマシ」なのでしょうか。

犯罪捜査とかの文脈でよく言われる「疑わしきは罰せず」とかは、False-Positiveを極力避けるためのポリシーです。安易に逮捕して無罪の人の人生を破壊してしまう事例が増えてしまうよりは、引き続き調査を続けて検挙までのリードタイムが延びる方が良いという考えですね。

逆に妊娠検査薬とかであれば、False-Negativeを極力避けるように設計されるかと思います。「陽性だったけど病院行ったり再検査したら大丈夫だった」というシナリオの方が、「見逃しで安心しちゃって取り返しがつかなくなった」というシナリオよりマシですよね。

さて、プロダクト運営についてはどうでしょうか。

僕としては、False-Negativeが最も避けるべきケースだと思いますが、チーム運営のやり方に依存するので、1番大事なのはチーム内で事前によく話し合っておくことかと思います。

たとえば、「False-Negativeを極力避ける代わりにFalse-Positiveが一定確率で起きても仕方ない」と考えるなら、「既に支持された仮説を疑い直す」という主旨の提案に対してオープンでないといけませんし、逆のケースなら「既に否定された仮説を疑い直す」という提案にオープンでないといけません。

この辺は、「そもそも仮説が支持されるとはどういうことか」という内容に踏み込んでいくことになるのですが、そのあたりはいずれ別途記事にしたいと思います。

仮説検証のことを考えてデザインする

仮説検証は奥が深い　ということは伝わったかなと思うのですが、どうすればいいのかという話も少し書ければいいなと思います。

まず、リリース初期は特にIA検証に注力すべきなので、標準的なVDにしておくと吉です。

OSやサービス領域ごとに標準的なUIがあります。それに寄せておくことで、VDに引っ張られることなく検証を進めやすくなるでしょう。

最後に、「反証不可能な仮説のことは考えちゃダメ」ということも大事かなと思います。

自分が検証したいと思っている仮説について「こういう条件のもとで、こういう結果が出たら、間違っているということがわかる」という文章が書けるかどうか試してみてください。これが書けないものは、いくらそれっぽいUIを作って数値を分析しても結論が出せません。

そういう類の仮説は、考えたり検証するものではなく、信じるものなのかなと思います。もはやプロダクトのコンセプトだったり、思想だったり、ビジョンだったりなのかなと。

仮説検証とデザインが大切と言われて久しいですが、こういった話も行われるようになるといいなあと思いました。この辺で終わります。

それでは。