プロダクトの仮説検証のQCD、あるいは安物買いの銭失いについて

これは LAPRAS アドベントカレンダー の7日目の記事です。
たまにはプロダクトマネジメントの記事も書かねばということで書きます。

今回はプロダクトの仮説検証について普段考えていることを、自身の失敗談なども踏まえながら書いてゆきます。

プロダクトの仮説検証の重要性

プロダクト開発というのは仮説検証の連続であり、その重要性は言うまでもありません。

プロダクト開発は「ユーザーに使われ、満足してもらい、売り上げを上ることで、最終的に目指すべきビジョンを達成するため」に行っているわけですから、それを実行する上で最も不確実性の高いユーザーのニーズや市場の仕組みを把握することが何よりも重要になります。そのため、これらの不確実性をコントロールしてプロダクトを積み上げていくためには、科学的な実験と検証のサイクル、すなわち仮説検証のプロセスが非常に重要というわけです。

極論すれば、法令対応やリファクタリングなど直接的にユーザー価値を目的としない開発などの例外を除き、プロダクト開発のほぼ全ては仮説検証であると言っても過言ではありません。

一言でプロダクトの仮説検証と言っても、ユーザーのペイン・ゲインに対する仮説検証、ソリューションに対する仮説検証、市場性に対する仮説検証などその対象は多岐に渡りますが、今回はこれらの仮説検証の全てに共通して意識すべきこととして、「なんのために仮説検証を行うのか」を考察することから、仮説検証のQCDについて考えてみようと思います。

なんのために仮説検証を行うか？

前述の通り、プロダクト開発において仮説検証を行う目的は「不確実性の高いユーザーのニーズや市場の仕組みを把握すること」にあります。

では、なぜ「ユーザーのニーズや市場の仕組みを把握する」ことが必要なのでしょうか？
それは言うまでもなくプロダクト開発をするためですが、より正確に言うと、プロダクト開発における戦略的・戦術的な意思決定を行うためにあります。すなわち、プロダクトの仮説検証とはプロダクトにおける意思決定を行うためにあり、逆に、意思決定に寄与しない仮説検証に意味はありません。

このことを、「インテリジェンス」という言葉を使って考えましょう。
「インテリジェンス」とは、外交や政治の分野でよく「インフォメーション」と対比される言葉で、インフォメーションが「単なる情報」を表すのに対し、インテリジェンスはインフォメーションを加工・分析することで得られる、判断・行動のために必要な知識を意味します。
(インフォメーションとインテリジェンスの区別については例えば こちら を参照してください)

仮説検証がプロダクトにおける意思決定を行うためにあるのであるとすれば、仮説検証とは単なるインフォメーションを得る活動ではなく、意思決定に寄与するインテリジェンスを得る活動であると捉えるべきと考えられます。

プロダクトにおける仮説検証の代表的な手法としてA/Bテストが広く使われています。A/Bテストは、仮説検証における検証の段階に広く適用可能なフレームワークとして非常に有用なプラクティスですが、その一方で「A/Bテストが仮説検証の全てである」という考えは危険です。
A/Bテストはあくまでも検証のための一手法であり、「A案がB案よりも優れている」というインフォメーションから、仮説の正しさと間違っていたポイント、さらにはその先のアクションに変容をもたらすインテリジェンスを引き出すところまでをもって仮説検証と捉える必要があります。

仮説検証のQCD

上記の考え方をもとにしたとき、仮説検証に求められる要件とは何でしょうか？ここでは、QCD(Quality=質、Cost=コスト、Delivery=納期)のトレードオフの観点から見ていきます。

仮説検証のQuality(質)とは、仮説検証がどれほど効果的であるかを意味します。ここで、仮説検証が意思決定に寄与するインテリジェンスを得るための活動であるとするならば、仮説検証のQualityは、これが意思決定に対して与えた影響の大きさによって評価されるべきものです。(もちろん、その意思決定が正しかったかどうかも事後的に検証する必要がありますが)
逆に言えば、仮説検証を繰り返しても、それがプロダクト開発における意思決定に変化を与えなかったら意味が無いということです。

次に、仮説検証のCostとは、仮説検証にかかる開発工数や外注費、マーケティング費用などの総コストです。同じQuality と Delivery ならばコストが安いに越したことはないですが、仮説検証を急ぐばかりにプロダクトに大きな技術的・UX的な負債を残してしまうということが無いように、これらの負債も含めた総コストを加味して仮説検証を設計しなければなりません。

最後に、仮説検証のDelivery(納期)とは、仮説検証の完了までにかかる時間のことです。仮説検証の成果が「意思決定に寄与すること」にあるとするならば、仮説検証のDelivery とは単にA/Bテストが完了するまでの時間ではなく、仮説検証がその後の意思決定に影響を与えるまでの時間で評価すべきです。

このように考えると、プロダクトの仮説検証に求められることとは「組織の判断や行動に対して、いかに大きな影響を、いかに素早く、いかに低コストで得るか」という点に集約されます。

このようなQCDのトレードオフについて、例えば製造業の文脈では「定められたコストと納期の中で、いかに質の高い製品を作るか」という構図で語られることが多いですが、プロダクトの仮説検証の場合は状況が異なります。

プロダクト開発においては、ある時点の意思決定がそれ以降のすべての行動に影響を与えるため、意思決定が遅れることは、その間に行われたすべての行動が水泡に帰す可能性を孕んでいます。こうなってしまうと、いくら仮説検証自体に掛かったコストが小さくとも、それとは比べ物にならないほどの時間とコストを失ってしまうことになります。
つまり、プロダクトの仮説検証において重要なのは、それによって意思決定に影響を与えるまでの時間(Delivery)と、その影響の大きさ(Quality)であり、これらを得るために必要なコストを支払う姿勢が大変重要になります。

以下では、LAPRASにおける自分の失敗談(脚色しています)をもとに、この考え方を実践していきます。

事例: 安物買いの銭失い

いま、とあるWebサービスにおいて、あるセグメントのサイト訪問からのユーザー登録率(登録CVR)が低いことが課題となっていタとします。

定性調査の結果、これらのセグメントは「サイトに対する信頼感が低い」という仮説が立ち、その解決策として2つの案が挙がりました。

【松】セグメント専用の信頼感を醸成するランディングページを設ける
【竹】ユーザー登録ページに不信感を払拭する説明と画像を追加する

松案は「信頼感が低い」という仮説を検証する上で効果が大きいと思われますが、新しいランディングページを用意するためコストと時間がかかります。一方、竹案はこれだけで効果が上がるかは微妙なものの、画像素材を用意して差し替えるだけのため、開発にコストも時間もあまりかからないメリットがありました。

当時、これらの案について次のようなQCDの評価を行いました。

竹案は見込める効果が少ない代わりに、開発コストと期間が非常に短いため、「素早く仮説検証を行う」という観点から「まずは竹案で仮説を検証し、もしもこれで効果がありそうだったら自信を持って松案を進める」という判断をしました。

しかしながら、竹案の実装を早々に終えて2週間のA/Bテストを行ったところ、「竹案では効果なし」という結果が出てしまいました。
特に困ったことには、竹案で効果が出なかった原因が、そもそもの「信頼感が低い」という仮説が間違っていたのか、それとも竹案では不十分だったのか、どちらなのかの判断がつかなかったのです。
結局、竹案の結果から「信頼感が低い」という仮説を捨てきることができず、松案も実施することになりました。

結果として、竹案は「成功しても失敗しても松案を実施する」ということとなり、「意思決定に寄与する」という意味では全く無意味な検証となってしまいました。
竹案の開発に掛かったコストと期間は大したことがありませんでしたが、その後のA/Bテストや「松案も実行する」という判断を行うまでに掛かった時間はそれなりに大きなものでした。特に、竹案では見込める効果が小さいため、A/Bテストで結果を出すためにはより多くのサンプルが必要となり、効果の有無を判断できるまでにより長い期間がかかってしまいました。

当初「コストが安いから」という理由で選んだ竹案でしたが、結局、仮説検証において意味のない「安物買いの銭失い」になってしまったのでした。

何がいけなかったか？

では、なぜこのようなことが起こったのでしょうか？
それは、仮説検証のQCDを考える上で「その後の意思決定に寄与するインテリジェンスを得る」という視点が不足していたためでした。

まず、竹案の検証は、うまくいってもいかなくても結局は松案を実施することになる「意思決定に寄与しない検証」でした。つまり、「意思決定に与える寄与の大きさ」という前述の評価に照らすと、竹案の仮説検証としてのQualityはほぼ無に等しいものでした。
一方で、松案は効果が無かった場合にはきっぱりと仮説を諦めることができるため、意思決定に対して大きな影響を与えるものでした。

このように、仮説検証を行う上では「結果によってどのようにその後の判断・行動が変わるか」を予め考えて設計する必要があります。
そのためには、うまくいったときよりもむしろ「うまくいかなかったときにどうするのか(諦めきれるのか)」をよくよく考える必要があります。
特に、チームでの開発においてステークホルダーが多くなるにつれて一度立てた仮説を捨てることは難しくなるため、「どのような状態になったら仮説を棄却できるか」の目線を予め揃えておくことが重要です。

また、仮説検証のDelivery(納期)について、当時は竹案の実装にかかる期間だけを考慮に入れていましたが、実際には「意思決定に要する時間」で考える必要がありました。
開発だけでなく検証にかかる時間まで考慮に入れる必要があったことに加え、竹案だけではどのみち意思決定に至らないがために、その後松案を開発・検証する期間も要する結果となってしまったのでした。

以上のように、当初考えていたQCDでは、「意思決定に寄与するか」というインテリジェンスの視点が掛けており、単なるインフォメーションを得るために仮説検証を行ってしまったという点が問題でした。

このような結果を避けるためには、仮説検証を設計する段階で「意思決定に寄与するか」というインテリジェンスの観点から下図のような正しいQCDの分析を行い、多少コストを掛けてでも最初から松案を選択する必要があったと考えられます。

まとめ

今回は、プロダクト開発における仮説検証について、「いかに意思決定に寄与するインテリジェンスを得るか」という視点から、QCDの要件を考えてみました。

仮説検証における Quality や Delivery は、単にその「効果の大きさ」や「開発期間の長さ」ではなく「意思決定に与える影響の大きさ」「意思決定に影響を与えるまでの期間」で評価する必要があることを述べました。

また、意思決定に対して素早く大きな影響を与えるために、必要なコストを支払うことが肝要であり、さもなくば「安物外の銭失い」になってしまうので注意が必要です。