グロース実験設計：仮説からMDEまで、そして読み出しまで
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
初めて「勝者」をリリースしてトライアル数を3%失ったのは、価格ページのCTAテストでした。3日間、240訪問、バリアントBが6.2%アップ。PMがSlackでトロフィーの絵文字を送ってきました。2週間後に週次トライアルボリュームがおかしくなり、計算をやり直したところ、元の「勝者」はずっとノイズバンドの中にありました。何もリリースしていなかったのです。感覚で作られた四半期ロードマップを除いては。
これが正直な仕事の姿です。テストではなく、騙されないことの方が重要なのです。
このガイドは、初日に誰かが渡してくれればよかったプレイブックです。実際に否定できる仮説の書き方、サンプルサイズ計算を素早く行う方法、ICEとRICEの選び方で自分に嘘をつかない方法、CFOが実際に開く読み出しの書き方です。これから1つだけ持っていくなら：テストは成果物ではありません。読み出しが成果物です。 ほとんどの四半期、それは40ではなく4つの読み出しです。
なぜほとんどのB2B実験は失敗するのか
過去数年でSaaSとPLGの会社をまたいで約60のグロース実験を監査しました。失敗パターンは5つに集まり、そのうち4つはテストが開始される前に決まっています。
1. 最初から検出力不足。 チームが8%のベースラインコンバージョンで800ユーザーに対して5日間テストを実施し、0.4パーセントポイントのリフトを見て勝者と宣言します。そのサンプルサイズの実際のMDEはベースラインに対して3パーセントポイント相対程度です。それより小さいものは統計的にコインフリップと区別できません。悪い実験を実施したのではなく、検出したかった効果を検出できない実験を実施したのです。
2. 仮説がタスクリストとして書かれている。 「価格ページで新しい見出しをテストする」。これは仮説ではありません。仮説は何が変わるか、どのくらい、誰に対して、なぜを予測します。仮説がデータで否定できないなら、テストはどんな結果が出てもストーリーを生成します。
3. ロールバック計画がない。 バリアントをリリースし、コンバージョンが4%低下し、誰もロールバックの決定を所有せず、バリアントが「もっとデータが必要」という理由でさらに6週間実施されます。もっとデータは必要ありません。事前登録された停止ルールが必要です。
4. 主要指標が事前登録されていない。 3日後に転換がフラットだがページ滞在時間が22%アップしているため、突然ページ滞在時間が指標になります。これには名前があります：HARKing（結果を見た後に仮説を立てる、Hypothesizing After Results are Known）。すべてのチームがやっています。やるチームはすべて信頼性の低い読み出しを生成します。
5. PMが3日目にチャートを確認する。 途中確認。連続テストはまさにこのために存在し、ほとんどのチームは使っていません。標準的な固定期間テストは、中間確認に基づいて決定した瞬間に統計的な保証を失います。
最初の4つは仮説テンプレートで解決されます。5つ目はサンプルサイズ計算器とダッシュボードをそのままにしておく自制心で解決されます。
仮説テンプレート
コピーします。チームの実験トラッカーに貼り付けます。誰でも使えるテンプレートにします。
実験：[短い名前、例：「価格ページのソーシャルプルーフブロック」]
問題（データで観察したこと）：
セグメントYでX行動を見ています。具体的には：
- データポイント1：[分析、サポートチケット、営業コール、定性から]
- データポイント2：[確認または三角測量]
予測される変化（誰に何をするか）：
[セグメント]に対して、[変化]を行います。なぜなら[機能すると考えるメカニズム]。
成功指標：
主要：[現在のベースライン数値付きの1つの指標]
ガードレール1：[Xより悪化してはいけない]
ガードレール2：[Yより悪化してはいけない]
MDE（行動を取る最小の効果）：
主要指標で[N%]相対リフトを検出する必要があります。
それ以下では、変化はエンジニアリングコスト/ブランドリスク/フォーカスに見合いません。
サンプルサイズと期間：
各アーム：[N]ユーザー
現在のトラフィックでの推定期間：[N週間]
ロールバック基準：
以下の場合にバリアントをすぐに終了します：
- 主要指標が[X]より悪化
- ガードレールのいずれかが48時間以上閾値を超える
- エンジニアリングがP0/P1バグを発見
決定日：[実際の日付。「十分なデータが得られたとき」ではない]
担当者：[1人]
2つの注意点。第1に、MDEのラインは希望ではありません。それはその変化をどんな場合でもリリースしない閾値です。1.5%のアクティベーションリフトがバリアントをコードに永久に保持するメンテナンスコストに見合わないなら、1.5%のリフトはMDEではありません。MDEはコストをクリアする実際の数値です。そこで正直に。
第2に、決定日はこのテンプレートの他のどの要素よりも多くのゾンビを殺します。それがないとすべてのテストが永遠に続きます。
サンプルサイズ計算：素早く行う方法
私が計画に使う計算式は、本物の統計家がやや異議を唱えるでしょうが、真実の10%以内に収まり、実際に使えるほど速いものです。
各アームのn ≈ 16 × p × (1 - p) / MDE²
ここで：
pはベースラインコンバージョン率（小数、例：8%なら0.08）MDEは絶対リフト（小数、例：8.0%→8.8%の移動は10%相対リフトで0.008）16は80%検出力と95%信頼性（両側）を組み込んでいます
以上です。ソフトウェアは不要です。実際のケースで実行してみましょう。
計算例：8%のトライアルから有料への転換
B2B SaaSで週600サインアップ。トライアルから有料への転換は8%（p = 0.08）。10%相対リフト、つまり8.0%から8.8%の絶対値（MDE = 0.008）を検出したい。
各アームのn = 16 × 0.08 × 0.92 / (0.008)²
= 16 × 0.0736 / 0.000064
= 1.1776 / 0.000064
≈ 18,400ユーザー各アーム
2アーム = 36,800ユーザー。週600サインアップがテストで50/50に分かれると、1つの実験に約6〜8週間のトラフィックが必要です。5日間ではありません。
25%相対リフト（8.0%から10.0%）を検出したい場合、計算はより友好的になります。
各アームのn = 16 × 0.08 × 0.92 / (0.02)²
= 1.1776 / 0.0004
≈ 2,944各アーム
合計約6,000ユーザー。週600件で約2週間。問題は：成熟したB2Bファネルでトライアルから有料への25%相対リフトは事実上ユニコーンです。うまくいけば年に1〜2回あります。実際の勝ちのほとんどは3〜8%相対であり、つまりテストのほとんどは日数ではなく月単位のトラフィックが必要です。
誰も聞きたくない部分：あなたのファネルは25%動かないので、実際に存在するリフトのためにテストの検出力を設定する必要があります。 これを曖昧にすると、すべてのテストがロールシャッハテストになります。
「もっと長く実施すれば」が間違いのとき
テストが1日目から検出力不足だった場合、固定期間設定のまま長く実施しても修正されません。偽陽性率を上げるだけです。実質的に途中確認をしているからです。期間の柔軟性が本当に必要なら、以下に切り替えます。
- 連続テスト（msPRT、常に有効なp値）：数学を壊さずに早期停止または延長を可能にします。Statsig、GrowthBook、Eppoはすべてネイティブにサポートしています。
- CUPED（事前実験データを使った分散削減）：事前期間シグナルが強い指標で必要サンプルサイズを30〜50%削減できます。主要なテストには有効にする価値があります。
これを手動でやろうとしないでください。プラットフォームを使います。
名前で知っておくべき一般的な診断
失敗モードに名前をつけられれば、読み出しレビューで反論できます。最もよく見る5つ：
- HARKing：結果を見た後に指標を選ぶ。起動前に主要指標とガードレールを事前登録することで解決。
- 途中確認：固定期間テストの中間確認に基づいて決定する。連続テストまたは決定日まで本当に見ないことで解決。
- 新奇効果：バリアントが新しいため2週間勝って、その後回帰する。UIの変更についてはテストを延長し、3週目以降の行動を観察することで解決。
- シンプソンのパラドックス：バリアントが全体で勝つが、ミックスが変わったためすべてのセグメントで負ける。常に読み出しを事前セグメント化することで解決（新規vs既存、プラン別、ソース別）。
- コホート指標での生存者バイアス：「4週目のリテンション」を4週目まで到達したユーザーのみで測定すると数値が膨らむ。エントリーイベントでコホートを固定することで解決。
優先順位付け：ICE vs RICE vs PIE
3つのフレームワーク、少し異なる要素、すべてが異なる形であなたに嘘をつきます。
| フレームワーク | 要素 | 最適な用途 | 壊れるところ |
|---|---|---|---|
| ICE | 影響×信頼性×容易さ（各1〜10） | 2〜5人のチーム、ナプキン計算 | 主観的。著者が自分のアイデアをスコアリング。「容易さ」はたいてい間違い。 |
| RICE | （リーチ×影響×信頼性）/工数 | 10人以上のチーム、セグメント横断のポートフォリオ | 「リーチ」はファネルステージ間のトラフィック差を隠す。工数も自己スコアリング。 |
| PIE | ポテンシャル×重要性×容易さ（各1〜10） | CROが多い、ページレベルの最適化 | ページトラフィックから「ポテンシャル」を推定できると前提とする。B2Bではほぼ常に間違い。 |
正直な評価：ICEは2人チームには問題ないが、20人チームには嘘をつきます。 チームが全員すべてのドキュメントを読む程度の小ささなら、ICEはとにかくするであろう会話を書き留める方法に過ぎません。チームがICEスコアがステークホルダーが読む唯一の成果物になるほど大きくなると、すべてのPMがそれをゲームします。
3つすべての罠：自分の実験をスコアリングしています。 担当者は自分のアイデアの信頼性を過大評価します。エンジニアは他の人の容易さを過小評価します。スコアが組織の政治の代理指標になります。
私が大規模で代わりに実施すること：数字なしの信頼性×リーチの2×2マトリックス。右上（高信頼性、高リーチ）は今すぐリリース。左上（高信頼性、狭リーチ）は安ければリリース。右下（低信頼性、広リーチ）は有料リサーチ投資になります。期待リフトではなく学習価値に基づいてテストに資金を提供します。左下は終了。週次、グロース責任者がマーカーを持って30分のミーティングでレビュー。
数字ではありません。正直な会話を強制する仕掛けです。
WIP制限：同時実験は3〜5つ
500名未満のほとんどのB2Bチームにとって、適切な同時実験数は3〜5つです。 それ以上だと自分のトラフィックを食い合い、交互作用効果が追跡不能になり、チームが実際に読み出しに注意を払えなくなります。制約はエンジニアリング速度ではありません。トラフィックと注意力です。
読み出しドキュメント（これが実際の成果物）
リリース、終了、結論不明のすべてのテストは1ページの読み出しを得ます。ダッシュボードではありません。ドキュメントです。同じフォルダに永久に保存します。
読み出し：[実験名]
期間：[開始]→[終了]
担当者：[名前]
状態：リリース済み / 終了 / 結論不明
実施したこと
バリアントBは[ページ/フロー]で[X]を[Y]に変更しました。[セグメント]に対して、[日付]から[日付]まで。
測定したこと
主要：[指標]。コントロール[N]、バリアント[N]、差分[+X% / -Y%]、p = [N]、CI [N, N]
ガードレール1：[指標]。フラット/超過
ガードレール2：[指標]。フラット/超過
サンプル：[各アームN]。[MDE]%相対リフトの検出力あり
学んだこと
- 結果の解釈を2〜3文で。「大成功」はNG。「トライアルから有料への転換が+4.2%（CI 1.1〜7.3%）、事前登録MDE4%以内なのでリリース」はOK。
- セグメント別：[効果が最も強かった/弱かった場所]
- 異常：[新奇シグナル？ガードレールのノイズ？データ品質？]
次に何をするか
- バリアントのリリース/ホールドアウト計画
- 後続テスト（最大2つ）
- エンジニアリング、プロダクト、デザインが注目すべきこと
私たちが___について間違っていたこと
1文。入る前に信じていたがデータが否定した（または確認を拒否した）こと。
「間違っていたこと」の行が秘密兵器です。3つのことを行います。
- チームの信頼を構築します。リーダーたちは、損失をパッケージして勝ちとして提示していないことを確認できます。
- 学びを複利的に積み上げます。1年で「間違っていたこと」が30以上あり、パターンが見えてきます（「価格ページの変更の影響を過大評価し続けている」）。
- 将来の信頼性スコアを調整します。事前情報が鋭くなります。
完了したテストの少なくとも60%で「間違っていた」行がない場合、安全なことだけをテストしているか、歴史を書き直しているかのどちらかです。両方とも悪いことです。
仮説バックログの出所
テストパイプラインはチームが構造的にアイデアを生成する方法がないと枯渇します。信頼できる5つのソース（シグナルの高さの降順）：
- ファネル差異：セグメントXが同じステップでセグメントYの半分の転換率です。理由を把握します。最大の、最も守れる勝ちはここにあります。
- 定性インタビュー：録音・文字起こしされた5名の離脱顧客。そのうち3名から同じ摩擦を聞くことになります。その摩擦が次の仮説です。
- 営業コールの録音：Gong/Chorusは金鉱です。「こうできたら」「混乱したこと」を検索します。それぞれが事前組み込みの信頼性を持つ仮説です。
- サポートチケット：同じアイデア、ファネルの低い部分。トピック別にクラスタリングします。最大のクラスターは2週間のエンジニアリング修正であることが多く、直近の6つのテスト合計よりもアクティベーションを向上させます。
- 競合分析：有用ですが危険です。新奇性を過大評価します。デフォルトで低信頼性としてタグ付けします。
優先順位付けキューに入る前に各アイデアを仮説テンプレートでスコアリングします。問題セクションを2つの実際のデータポイントで埋められない場合、アイデアは準備できていません。推測です。調査のために送り返します。
ゾンビ実験の廃棄
すべてのグロースチームには存在します。誰も所有しないフラグの後ろに誰も覚えていないバリアントにトラフィックを提供し続けているテスト、誰も監査しないページにあるもの。3つのルール：
- 90日ルール。 読み出しなしで90日以上稼働しているテストは、次の四半期レビューでデフォルト終了されます。「もっとデータを待っている」という例外はありません。テストが有意差に達するのに4ヶ月必要なら、起動時から検出力不足であり、正しい答えは停止して再設計することです。
- 四半期廃棄レビュー。 四半期に1回、実験プラットフォームのすべてのアクティブフラグを監査します。それぞれを担当者と読み出しドキュメントに対応付けます。孤立したものはすべてコントロールに戻し、フラグはコードベースから削除します。
- 「まだトラフィックを提供中」監査。 すべての実験対象URLのリストを取得し、プラットフォームのアクティブテストと照合します。すべてのギャップは設定バグかゾンビのどちらかです。両方修正します。
この監査を正直に実施するチームは、「アクティブ」なテストの30〜40%が無駄であることを発見します。廃棄することでトラフィックと注意力を本当に学習できるテストのために解放します。
グロースICの実際の仕事
始めた場所で締めます。ICの仕事はより多くのテストをリリースすることではありません。より多くの学びをリリースすることです。ほとんどの四半期、それは40の投げやりではなく、4つのよく設計された、適切な検出力の、正直な読み出しのテストです。
良い実験の実践は外からは遅く見えます。チームは30ではなく3つのテストを実施しています。読み出しの半分が「間違っていた」と言っています。途中確認を擁護するPMが押し戻されています。CFOが実際に読み出しドキュメントを開いてガードレール指標について質問しています。
それが仕事の機能している状態です。Slackのトロフィーは後から来て、数学が本物だったので本物です。
あわせて読む
Principal Product Marketing Strategist