事業を成長させる週次「実験レビュー」のすすめ
「全社で目指すのは、一定時間内でできる実験の数の最大化です。各企画が上手く行くか分からないため、それらを実験する方法があれば、より多くの賭けができます。すなわち、本当に大事なのは、実験コストの削減です。
私達にはWeblabというグループがあり、ウェブサイトのUIで常に実験を行い、どのUIが最も効果的か、実際の使用パターンから統計データを得ています。これは私たちにとって巨大な実験室であり、これら実験コストを非常に低く抑える方法を実現するために注力してきました。そうすることで、はるかに多くの実験ができるようになるのです。」
— ジェフ・ベゾス、Amazon 創業者兼会長（2007年）
今日は、事業の成長に不可欠な「実験」について書きたいと思います。BCGで新卒入社時から「仮説→検証」のイロハを叩きこまれた私は、実験の大事さを理解しているつもりでしたが、Amazonに来てその意味を全く違う次元で体感しました。
どう体感したかというと、まず、私の所属は新規事業の新チームだったため、最初の1～2年は実験インフラが整っていない状況からスタートしました。「それ、実験してみたらいいんじゃないの？」と言われる度に、「いやぁ、それが、インフラがないから、実験1つでも何カ月も工数がかかるんだよね」「。。。」と行き詰まる会話。
UIの実験は顧客体験と売上の向上に不可欠と信じていた我々は、実現に向けたロードマップを作り、他チームの協力を得て、ボトルネックを1つ1つ解消し、上述の全社プラットフォーム（Weblab）と統合し、。。。という地道な努力を積み重ねていきました。1年も経つと、私のチームだけで5～10、事業部全体では50もの実験を同時にできるようになり、そこから加速度的に主要KPIも伸び、チームとしての学びも蓄積していきました。現在も機械学習やAIを軸としたUIの最適化が進み、それらは事業に欠かせない成長の柱となっています。
今日は、この実験プログラムの基本思想や、落とし穴、作り方につき解説します。「実験」は非常に奥深いテーマなので、後日「実践編」も書きます。ご質問・ご感想などあればぜひお寄せください。
なぜ実験が大事なのか
実験は、組織の「認識と現実のギャップ」を埋めるために不可欠な工程です。具体的には、実験をしないと、以下のような問題が起きます。
① アイデアの良し悪しが分からない：NetscapeのCEO、ジム・バークスデールは、「データがあるなら、見てみよう。意見しかないのなら、私の意見で進めよう。」と言ったそうです。事業の成功を真剣に考える人ほど、自分の考えを持つので、チーム内で意見が異なるのは自然なことです。しかし、その時に意見だけで決めてしまうと、間違ったアイデアを追う、あるいは正しいアイデアを捨てるという機会損失が発生し続けてしまいます。
② 検証しないと、学びが蓄積されない：色んな施策をやっているのに、なぜか成果に繋がらない。やることが山ほどあって、振り返る暇もない。これは意外によくあることです。施策のリリース前の検証を習慣化していないと、何が思い通りに行っていないのか深堀りされないため、学びが蓄積されず、改善の機会も見逃すことになります。
③ 事業に害を与えていることに気づかない：実験を習慣化していないチームは、導入した施策が正しいと妄信しがちです。すると、変更を段階的に加えて、期待した効果が得られなかったら元に戻す、という基本動作を怠ってしまいます。結果、よかれと思ってやっていることが、知らずのうちに事業に害を与えてしまうことになります。
かのMicrosoftも、20年前は「機能のリリース前には実験が不可欠」という概念がありませんでした。検索エンジンのBingで実験し始めたところ、半分以上の施策で効果がゼロ又はマイナスだったことが分かり、その教訓をもとに、Windowsでも個々の機能を検証してからリリースする文化へと進化していきました。（今では年間数万の実験を行っています。）
実験の進め方
実験の基本思想は、誰もが学校で一度は学んだ「科学的方法」と同じです。これを企業の活動に応用すると、下記のようなステップになります。
① 皆で定めた場所でドキュメントを作る。これは形式的なようで、大事です。自分の実験が事業の指標に影響を与える可能性も多々あるため、今どんな実験が進んでいるかチームの全員が把握できる必要があります。また、組織の学びを活用するには、「これに似た実験前やらなかったっけ？」といった問いにすぐに答えられなくてはなりません。
② 仮説を立てる。試したいアイデアが、顧客や会社のためにどう役に立つかもしれないかを説明しましょう。後々データを参照しながら、この仮説を検証していくことになります。
③ 何を変えるのかを定義する。コントロール群（Control）と介入群（Treatment）を定義します。両方のモックアップなどがもしあれば、違いが一目で分かるので効果的です。
④ 総合評価基準を決める。これは意外に難しいステップです。何の指標をどれくらい改善すれば成功なのかだけでなく、何の指標を悪化させてはいけないかを決める必要があります。例えば、SNSは広告を増やせば売上は上がりますが、それをユーザーの滞在時間等を悪化させることなく実現する必要があります。
⑤ 割り当ての単位や時間軸を決める。トラフィックの何%を実験群とするのか、それぞれの実験群にどの単位で割り当てるのか（例：ユーザー単位、セッション単位）、何日分の結果を持ってネクストステップを判断するのかを予め決めてから実行します。
レビューの進め方
チーム内で数々の実験が進む中、それらの状況や教訓をタイムリーに共有し、ネクストステップを速やかに決めていく必要があります。これはチーム毎に試行錯誤しながら決めていくことですが、基本的にはミーティングとオフライン（チャット等）の組み合わせで行うのが効果的です。
週次ミーティング
モメンタムを作るには、まずは週次（又は隔週）ミーティングから始めるのが良いでしょう。一般的な進め方は下記の通りです。
① 誰でもサインアップできるようにする。1コマ〇分とし、サインアップ形式にすることで、その時々にタイムリーに実験結果について議論できます。定例メンバーとして、結果の良し悪しを細部まで理解できるサイエンティストや事業部のリーダー達が参加できるようにすると良いでしょう。
② 結果の他、設計の議論も可。意思決定が必要な実験結果が最優先ですが、時間が許せば実験の設計に関するアドバイスを求める場としても有効です。
③ 実験結果の評価とネクストステップに重きを置く。結果を見ながら骨太な議論を行い、進め方を決めることで、タイムリーな意思決定が可能となります。
効果的なミーテイングにするためには、書式を厳守することが大事です。意思決定に必要な情報は全て書き出し、会議中にダッシュボードを引き出したりといった時間の無駄を省く必要があります。これにより、中身のある議論が生まれ、強力な学習ループが作られます。
また、このミーティングの重要性を位置づける上で、幹部の参加は重要です。ビジネスへのインパクトも大きく、示唆に富むミーティングなので、私の事業部長（Director）は必ず、事業本部長（VP）も時間の許す限り、出席していました。
オフラインレビュー（Slackチャット等）
モメンタムが出てくると、週次ミーティングでは収まりきらない量の実験や情報が共有されるようになります。ここで効果的なのが、オフラインの仕組みです。
① 実験アナウンス用スレッド：このスレッドで、どんな実験がローンチしているかを共有し、メンバー全員に可視化します。仮説、介入群、評価基準、テスト期間、参照リンク等、共有時に含めるべき情報を統一すると良いでしょう。質問やフィードバックがあれば、ここで共有できます。
② 実験結果用スレッド：実験結果の準備ができ次第、対象指標への影響や、そこから得られる示唆についての考察を共有します。ここでしばしば会話が始まり、実験から得られる示唆について議論することができます。
③ 「やっちまった！」スレッド：ここでは特に失敗事例を共有することで、組織としての学びを蓄積していきます。慣れるまでは投稿に勇気がいるので、共有したメンバーを称えるよう、幹部らで盛り上げていくことが大事です。
よくある落とし穴
最後に、実験プログラム導入時に避けたい落とし穴について触れておきます。
落とし穴① 実験の失敗を恐れる：Amazon、Microsoft、Airbnbで実験プログラムを立ち上げてきたロン・コハヴィは、どの企業でも必ず半分以上、高ければ7～8割の実験が期待した成果に繋がらないのが普通だと言います。このため、心構えとしては「8割の実験は失敗する」と考えておくのが大事だと彼は言います。この心構えを持つことで、失敗を恐れずに実験し、学びを抽出しながら高頻度で実験を繰り返す文化を作ることができます。
落とし穴② 実験前から皮算用する：「で、この実験はどれだけインパクトが出るの？」と必ず聞かれるのですが、分かっていたら実験する必要はありません。財務や優先順位付けのためにどうしても必要な場合は、なるべく保守的な値にした上で、さらに事業部のこれまでの失敗確率を加味して数字を叩くことを推奨します。
落とし穴③ 短期的な賭けばかりする：資産ポートフォリオと同様、長期的な価値の最大化には、短期的なヒットだけでなく、特大ホームランになり得る賭けも必要です。これは幹部が理解し、大きな賭けができるキャパシティを確保しなくてはなりません。
落とし穴④ 早期な意識改革を期待する：実験の大切さを理解し、それを推奨するチームになるためには忍耐が要ります。上述のMicrosoftでも、Windowsチームは、「ウチのPMは優秀だから、実験なんて要らない」と信じていたところを、サティア（現CEO）を筆頭に実験の必要性を繰り返し説いていったことで、徐々に「リリースする全てのものは実験が必要」というマインドセットに変わっていきました。
終わりに
以上、事業の成長を促す週次「実験レビュー」の進め方を解説しました。実験インフラの作り方（内製化又は外部ツール活用）や、実験工程で避けたいよくある間違いなどを今後別途棚卸ししてみたいと思います。
「人々は往々にして、革命的なアイデアとは、誰かが突然ひらめき、チームがその考えを実行し、ポン！と長期に渡る成功事業ができあがると考えがちです。しかし、そんなことはほとんど起こりません。
革新的な企業についてあまり知られていない事実の1つは、彼らが大きなアイデアの種を植え、それが顧客の共感を呼び、長期に渡り顧客にインパクトを与えるものにするためには、絶え間なく議論、再定義、微調整し、繰り返し実験しているということです。」
— アンディ・ジャシー、Amazon CEO（2022年）
