実験速度

実験速度とは、組織が有効な実験を完了する割合のことで、通常は月ごとまたは四半期ごとの完了したテスト数で表されます。これは、テストプログラムがどれだけの価値を生み出すかを予測する上で最も強力な指標の一つです。その理由は単純明快です。もし、有意義な改善をもたらす実験が少数派であれば、発見される改善の数は、実行される実験の数に大きく左右されるからです。他の条件がすべて同じであれば、学習速度を2倍にすれば、重要な指標に対する複利効果もほぼ2倍になります。

速度は3つの異なる制約によって制限されており、どの制約が制限要因となっているかを特定することが、速度改善の第一歩となります。トラフィックは統計的に厳しい上限を設定します。サイトは、そのトラフィック量で対応できる以上の同時実行テストを、十分な処理能力をもって実行することはできません。生産能力は、アイデア創出、設計、構築、品質保証を網羅しており、すべてのテストにエンジニアリング作業が必要な組織では、通常これが制約要因となります。プロセスは、承認サイクル、利害関係者のレビュー、法的またはブランド上の承認、分析の所要時間を網羅しており、多くの場合、最大の隠れたコストとなります。テストは、データ収集に費やす時間よりも長い時間、キューで待機していることが多いためです。

基準を下げてスピードアップを図るのは逆効果であり、残念ながらよくあることです。業務サイクル全体を下回る実行時間、サンプルサイズ計算の省略、品質保証の放棄、重要なことよりも簡単なことばかりをテストすること、そして有意な兆候が見られた時点でテストを中止することなどは、完了した実験の数を増やす一方で、真の発見の数を減らしてしまいます。信頼性の低い方法論で四半期に40回のテストを報告するプログラムは、適切に実施された12回のテストを報告するプログラムよりも価値が低く、結果が互いに矛盾するため、組織的な混乱を招くだけです。

生産性を向上させるための手段は、テスト自体を短縮することよりも、待ち時間をなくすことに重点が置かれています。開発準備が整ったアイデアを優先順位付けしたバックログとして維持し、常に稼働可能な状態を保つこと。再利用可能なコンポーネントライブラリとテストテンプレートを確立し、開発時間を短縮すること。リスクの低い特定の種類の実験について、承認を継続的に行うことで、毎回新たな承認を必要としないようにすること。サイトの異なる領域で、重複しないテストを同時に実行すること。分析とレポート作成を自動化し、テスト終了当日に結果が利用可能になるようにすること（2週間後ではなく）。これらのどれも厳密性を損なうものではなく、実験間の期間を短縮するものです。

速度は、単独で評価するのではなく、品質指標と併せて検討する必要があります。有用な指標としては、テストが中止されることなく有効な結論に達した割合、結果に関わらず学習成果が文書化された割合、価値の高いページやフローを対象とした実験の割合、ホールドアウト法によるプログラムの累積効果の測定などが挙げられます。速度のみを表示するダッシュボードは、当然ながら、より単純なテストを実行することで最適化されてしまいます。

並行処理は、最も不用意に適用されることが多い要素であるため、特に注意が必要です。複数の実験を同時に実行すると、テストがエクスペリエンスの無関係な部分に影響を与える場合はスループットが向上しますが、テストが重複する場合は解釈不能な結果が生じます。実践的なルールとしては、各テストをそれが影響を与えるファネルのステップと対象ユーザーにマッピングし、同じステップを変更する2つのテストを同時に実行しないようにし、テストが隣接している場合は独立性を仮定するのではなく、相互作用の影響を確認することです。一部の組織では、影響を受ける領域を記録したアクティブな実験の共有カレンダーを維持することでこの問題を解決しています。これは地味な方法ですが、2つのチームが同じページに対して競合する変更を知らずにテストし、理由を理解せずに両方とも結論が出ない結果を報告するというよくある状況を防ぎます。

ほとんどの組織にとって、スピードアップへの最短ルートは新しいツールではなく、より明確な運用モデルです。つまり、誰がアイデアを生み出し、誰が優先順位を付け、誰が構築し、誰が承認し、各ステップにどれくらいの時間が許容されるかを明確にすることです。このモデルを確立することは、通常のプロセスの一部です。 成長管理 エンゲージメント、そしてその結果生じるペースは通常、パイプラインを常に満たしておくために十分な準備と十分な証拠のある仮説があることに依存しており、そこで継続的な ユーザー調査 これは、時折行われる独立したプロジェクトではなく、テストロードマップへのインプットとして位置づけられるべきものである。