リスクの切り分けとテスト文化

プロダクトが「狙った人の課題ををちゃんと解決できているのか」を確認するためにテスト(実験)する、ということを大事にしている。そしてテスト自体が自分だけではなく10Xという会社のカルチャーにもなりつつあると感じている。
 
テストというのは2つのステップでできている。
 
  1. リスクの設計 リスクを言語化し、要素を細分化、優先度を判定する
  1. リスクの検証 要素に対し可逆的な解決方法を試し、結果をフィードバックする
 
一般的に、テストや実験という言葉から想起されるのは2の検証プロセスであることが多い。
しかし多くの”科学的な”テストに対して、効果を決定づけているのは1のプロセスであることが多い。つまりリスクの扱いにテストの巧拙が現れるのだと思っている。

リスクについての認識の誤り

リスクというのは多くの日本人にとって「危険性」といった意味で多用される言葉だが、これは少し誤りがある。
リスクとは「事前に予期できる、計測可能で不確実な危険性」といったほうが適切な表現だ。
少なくともテストを生業にしている研究者や、ファイナンスに従事する人にとっての「リスク」はこちらの解釈のほうが正しく伝わるだろう。

プロダクト発明の3つのリスク

新規性のあるプロダクトというのは「こういう課題をユーザーはもっているだろう」という洞察から始まり、「こうやったらうまく解決できるのではないか」という仮説を具体的な形にして、誰かへ提供することからスタートする。
殆どの場合で、プロダクトのバージョン1は以下の3つのうち、どれか、もしくは全てを抱えている。
  1. 熱量のリスク (課題が存在しないか、誰にとっても大した課題ではない)
  1. サイズのリスク (熱のある課題は存在したが、極めて少ない人が対象となる)
  1. 解法のリスク (解決方法が適切ではない)
どれも不可避なリスクだ。

かつてはリスクをそれぞれ検証するのが難しかった

一昔前であれば、これらのリスクは「計測難易度」つまりコストが高く、扱いの難しいリスクだった。計測にコストがかかると、リスクを切り分けて対処すること自体が難しい。「リリースしたが誰も欲しがるものではなかった」というケースでとれる対策が限定的だった。
多くの場合はユーザーインタビューが用いられた。ユーザーに「なんで使わへんの?」とヒアリングして、ユーザーが言ったことを真にうけてプロダクトに反映する。
ユーザーは「本当に欲しいもの」を知らない ので、これによってプロダクトの死を早めたりした。もしくはリスク検証よりマーケティングを優先し、市場流通量がピークにきたところで誰もリテンションせず静かに終わりを迎えたりした。
こういうプロダクトの失敗はなかなか共有されることはないが、「Product Failure」などでググると多くの事例に出会える。サマリとしては「When Corporate Innovation Goes Bad — The 141 Biggest Product Failures Of All Time」などが面白い。時代や商材を超えて勉強になる。
 
💡
PS. ちなみに僕は 機能開発のためのユーザーインタビューは価値がない と思っている。他方で「自分がフォーカスした誰かの生活を知る」ために、その人の家や職場まで足を運び、観察し、話を聞き、インサイトを得ることについては非常に有意義だと思っている。目的の違いだ。

センサー時代は検証コストが激減した

現代の我々は非常に良い時代に生きている。高度なセンシング技術により、低コスト・高精度でさまざまな計測が可能になった。
かつては「正解を知りもしない誰かにヒアリングする」という手法をとっていたのが、今では「実際にプロダクトを手にとった人が、いつどう使ったのか、逆にどう使わなかったのか」について、多くのファクトデータを集めることができる。”嘘”のないフィードバックをうけ、それを元にリスクを切り分けてテストアプローチができる。
たとえば熱量のリスクについては、極めて簡易なプロトタイプをInstagramやメルカリ、Twitterで売ってみればいい。「お金を払ってまで解決したい熱量のある人」がどれだけ存在するか、リアルデータが得られる。
また、多くのプロダクトは何かしら既存のユースケースを置き換えるものだ。プロダクトが「どこの・誰の・何を」解決するものなのか定まると、サイズの上限はざっくりとだが検証できる。あとはシェアをどう取るか、の問題となり、ダブルジョパディの法則にすべてのマーケットが修練する。ある種、サイズの不確実性はほとんどないともいえる。
だからこそ「自分がどういうサイズを目指すのか、という意志」を先に定めプロダクトを創らなくてはいけない。
たとえば日本でのインスタントラーメンの消費食数はざっくり1,500万食/日らしいが、「手軽に作れる麺的な食品」というプロダクトを目指した時点で、この数値が上限となる(ただし、日清食品がマーケットの約50%を占める恐ろしい寡占市場であることも忘れず…シェア獲得の困難度が高い)。

検証が難しいのは「新規性」

熱量やサイズは工夫次第で検証できる現代。
残された本当に検証が難しいリスクというのは「新規性の高い解法が本当にユーザーにとって従来の方法より10倍良いものなのか」という点だ。解法のリスクの中でも、新規性だけはいまでも検証が難しい。
全く新しい解法は混乱を生み、既存に類似した解法は退屈だ。その中間にある、ベストバランスの解法が「発明」となる。
そして、最近ではAB Testという使い古された手法こそ、この新規性の検証に最適だと考えるようになった。

AB Testの誤謬(ごびゅう)

AB Testについてググると、「静的なWebページ(LP)において、訪問したユーザーが資料請求ボタンをクリックする比率(CTR)を高めるために、ボタン文言や色のテストを行う」的な説明が上位に来るが、これは誤解を招くと思っている。
 
 
AB Testの本質的な特徴は以下の3点だ。
  • テストグループを限定できること
  • バイアス排除
  • 可逆的であること
この特徴を最大限活かすには、「既存のファネルのレートを数%ずつ積み上げるような改善」ではなく、「破壊的な効果が見込める、新規性の検証」にこそAB Testという手法は向いている。ポジティブにも、ネガティブにも10xな影響を及ぼしうる施策を可逆的に行うことができる。

ストーリー達成度を検証する

AB Testは既存のプロダクトに対して(コントロールグループ)、テストグループをチャレンジさせるものだ。チャレンジの粒度はテスト設計者の意図によるが、最終的にはユーザーがプロダクトを通じてストーリーを完遂することができたかどうかを検証するようにしている。
  • フリマであれば「売り買いを継続的に行う」
  • メディアであれば「継続的にコンテンツを検索をする、消費する」
  • コミュニティであれば「他のユーザーと継続的にインタラクションする」
本質的にプロダクトにとって最も重要な指標にインパクトがあるのかどうか。それを検証のフォーカスに入れておくべきだ。
多くのプロダクトにとって、複数の数値の間の因果を完全に解き明かすのは不可能に近い。「このボタンのCTRが伸びれば継続率が伸びる」といった相関図が得られたとしてもそれが因果であることの証明は非常に難しい。
AB Testによって生み出された差分を正確に計測しつつ、ストーリーの達成度を常に検証フォーカスに入れる。

AB Testのコスト

どういったコストか。大きく3つあると考えている。
1つは組織におけるリソース配分コスト。大胆な実験だけに、多くのプロダクトリソースを割く訳にはいかない。日頃の積み重ねと、振り切った実験は表裏一体だ。どちらが最後に花開くかわからない。故にリソースの配分が難しく、この意思決定自体がコストを要する。
もう1つは獲得コスト。テストにおいて「統計学的に有意」といえるだけの母集団を確保するにはユーザーの流量が必要であり、この獲得にコストがかかる(有り余るオーガニック流量や広告宣伝費があればこのコストは無視できる)。
最後は実装コスト。精緻にグループをコントロールし、分析できるようにログを吐く実装が必要。Firebase AB Testingはこの問題を簡易に解消できるツールだが、β版ゆえかログの部分欠損も観測される。有料ツールは金も実装コストも掛かり、スクラッチのテスト基盤ならなおの実装コストがかかる。
もしログ分析に長けた人間がいない場合、さらに分析コストがかかってくる。検証が十分に可能なログ設計をし、集計・分析し、認知バイアスのかからないよう結論を言語化する。

10XにおけるAB Test

現在社内では大きなプロジェクトを同時に2つ進めている。
  1. 6ヶ月近い期間をかけて開発を進めている新規プロダクト
  1. 既存プロダクトの大胆な実験
このうち、2に対してはプロダクトが解決できていないリスクを事細かにリストアップし、優先度をつけ、その中でも「破壊的」と事前に推測されるものについては積極的にAB Testを行っている。AB Test基盤の導入・活用が進み、大胆な実験を毎週のように実施できる環境が整ってきた。
未だに分析コストは自分自身が負担しているが、クエリリサイクルも進みだいぶ楽になってきた。 (今日も始めのタスクは昨日スタートしたAB Testの分析クエリをダッシュボードに登録しておく仕事になりそうだ。)
AB Testを通じて「ストーリーの検証」をしようと思うと、結果指標が判断できるまでに最低10日程度の時間がかかる。そして複数のテストを同時に走らせることのリスクも検討しなくてはいけない。基本的にはお互いに疎なテスト以外は同時に実施しないようにするか、テストグループのコントロールが必要となる。必然、テストには多くの時間を要する。
 
しかし本質的なスピードはこの実験の精度を欠いていては生まれない。設計も実施も適当なテスト、一切の学びにつながらないことは大学院時代によく学んだ。科学的であることを放棄しない、かならず1つのテストから複数の学びを得ることが我々の今のカルチャーにもなっている。

>> JOIN US