本文へスキップ

実験ロードマップのつくり方

実験ロードマップとは、次に回すテストを優先順位付けしたバックログです。スコアを付けることで、小さなチームが限られた実験枠を、期待値の最も高いアイデアに使えるようにします。散らばった思いつきを順位付きのキューに変え、見直しのサイクルを決め、最も難しい判断である「何を打ち切るか」を迫ります。

更新日:6分で読めます執筆 fromHello

要点

  1. 優先順位付けが最も重要になるのは、少数のテストしか回せないときです。弱いアイデアに使った枠は、それだけ強いアイデアを見送ったことを意味します。

  2. ICE(Impact × Confidence × Ease)でアイデアにスコアを付ければ、バックログを素早く順位付けできます。リーチが大きく異なるときはRICEを使います。どちらも推定であって、真実ではありません。

  3. バックログは、願望リストからではなく、ファネルの漏れている箇所とアクティベーションのアハモーメントから組み立てます。

  4. 決まったサイクルで見直し、負けたテストは予定どおり打ち切ります。ほとんどのテストは差が出ずに終わると想定してください。

優先順位付けがすべてである理由

小さなチームが回せる実験は、週に2〜3件ほどでしょう。週に10〜20件に届くのは、実験の速度が非常に速いチームだけで、トラフィックが少なければそれも難しくなります。枠がこれだけ少ないと、平凡なテストの本当のコストはテストそのものではなく、それを回すために見送った、より強いアイデアです。ロードマップがあるのは、各枠を朝会で一番声の大きい人の案ではなく、期待値の最も高いアイデアに使うためです。この順位付きのキューを持つことは、グロースPMの仕事の大きな部分を占めます。

ファネルとアハモーメントからバックログを組み立てる

願望リストから始めないでください。ファネルの漏れている箇所から始めます。訪問、登録、アクティベーション、リテンション、売上と各ステップをたどり、最も大きな離脱を書き出します。その1つひとつが、検証できる仮説です。アクティベーションのアハモーメントに最も近いステップには大きな重みを置いてください。アクティベートしないユーザーが定着することはめったにないからです。名前を付けたアハモーメントは、証明された原因ではなく、検証すべき相関として扱います。アクティベーションのシグナルはリテンションを予測しますが、それを自社の施策がもたらしたことの証明にはなりません。それぞれの漏れが、バックログの1行になります。仮説、それが動かすはずの指標、そしてどれくらい動くかの大まかな見積もりです。

ICEでアイデアにスコアを付ける

Sean Ellisが広めたICEは、各アイデアを3つの軸で1〜10点で採点します。Impact(指標をどれだけ動かせそうか)、Confidence(うまくいくとどれだけ確信しているか)、Ease(どれだけ少ない労力で済むか)です。3つを掛け合わせ、降順に並べ、上から取り組みます。正直な推測を3つするだけなので、速いのです。その速さが落とし穴でもあります。スコアは推定であって事実ではありません。512と480はほぼ同じと読み、判定とは考えないでください。数字はリストに順番を付けますが、判断を代わりにしてくれるわけではありません。

各アイデアをインパクトと労力で配置します。クイックウィン(インパクト大、労力小)が、限られた枠を最初に得ます。時間の浪費が枠を得ることはめったにありません。

リーチが異なるときはRICEを使う

2つのアイデアが届くユーザー数が大きく異なると、ICEはうまく機能しません。Intercomが考案したRICEは、Reach(リーチ)を加えてEffort(労力)で割ることでこれを解決します。計算式は(Reach × Impact × Confidence)÷ Effortです。すべての訪問者が目にするヒント表示と、設定ページの奥に埋もれた調整を、同じ土俵で採点できます。その代わり、速さを手放し、根拠を用意しなければならないリーチの見積もりを引き受けることになります。同じ注意が当てはまります。でっち上げた4つの数字を掛け合わせると、見せかけの精度が生まれかねません。入力は粗いままにし、学びに応じて見直してください。

項目ICERICE
計算式Impact × Confidence × Ease(Reach × Impact × Confidence)÷ Effort
速さ速い(1〜10点の推測を3つ)遅め(リーチの数字が必要)
向いている用途大きなバックログの素早い仕分けリーチが大きく異なるアイデア
主な落とし穴Easeが本当の労力を隠すあいまいな入力による見せかけの精度

決まったサイクルで見直し、負けたテストを打ち切る

週次か隔週で見直しの場を設け、決まったリズムで結果を読み、勝った案を採用し、残りを終わらせます。予定どおりに打ち切る規律が、キューを動かし続けます。回しっぱなしのテストは、枠を占有し続けます。ほとんどのテストは差が出ずに終わること、そしてトラフィックが少なければ多くのテストが始める前から検出力不足であることを、正直に認めてください。トラフィックが少ないときのテストで解説しているとおり、正しい判断はA/Bテストをせず、リリースして監視することである場合も少なくありません。測定する場合、きれいに結果を読むにはたいていホールドアウトグループが必要です。customer.ioのようなプラットフォームや、セルフホストのエンゲージメント基盤なら、それを確保しておけます。

FAQ

よくある質問

  • 小さなチームはいくつの実験を計画すべきですか?

    思っているより少ない数です。ほとんどの小さなチームにとって、きちんと回せるテストは週に2〜3件が現実的な上限で、強いグロースチームでも10〜20件を超えることはめったにありません。理想の枠数ではなく、実際の枠数を前提にロードマップを計画してください。

  • ICEとRICEはどちらが優れていますか?

    どちらが「優れている」ということはありません。答える問いが違います。アイデアが届くユーザー数が同程度なら、ICEで大きなバックログを素早く仕分けます。順位が変わるほどリーチが大きく異なるなら、RICEに切り替えます。どちらも推定です。スコアは判定ではなく、並べ替えの順番として扱ってください。

  • バックログの優先順位はどれくらいの頻度で見直すべきですか?

    結果を見直すのと同じサイクルです。多くのチームでは週次か隔週です。テストが終わったとき、指標が動いたとき、新しい漏れが見つかったときに採点し直します。スコアは学びとともに変わるため、一度も並べ直さないロードマップはすでに古くなっています。

  • テストが有意に届かない場合はどうすればよいですか?

    トラフィックが少なければ、それがよくあるケースです。線が動くのを期待していつまでも回し続けないでください。どれだけ待つかを最初に決め、いずれにせよ出すつもりだったバージョンをリリースし、ガードレール指標を監視します。正式なA/Bテストは、実際に結論が出るほど大きな変更か、十分にトラフィックのあるページのために取っておいてください。

fromHelloは、オープンソースのマーケティングオートメーションです。

人の行動をきっかけにメッセージを届けます。fromHello Cloudは、ウェイトリスト経由でアーリーアクセスを提供しています。

アーリーアクセス

fromHello Cloud

小さくまとまるために始めたわけではない。

fromHello Cloudのアーリーアクセスは、段階的にご案内します。 オンボーディングは伴走型です。セットアップからコンタクトの移行まで、私たちがお手伝いします。

ご利用の準備が整い次第、メールでお知らせします。スパムは送りません。

まだ登録する段階ではありませんか?GitHubで見る