失敗をコントロールしながら仮説検証を繰り返す
事業全体の方程式をとらえ、観測ができる環境ができあがったら、次は仮説検証を繰り返して事業を成長させていくことになる。課題となるKPIに対して、複数の仮説検証プランがある場合は、実施後に予測される数値の上昇率や、かかるコストを加味して決めていく。
仮説検証について石垣氏は、「売上が2％上昇すると思って実施した計画の結果がマイナスになることもあります。予測値と実測値のずれを検知して改善していくことが初期の仮説検証では大事になってきます。このフェーズで大事なのは、質よりも量。ですから、実施のためにはいくつも承認が必要だとか、失敗したらどうするとかの懸念によって計画が遅れたり、実施されなかったりするのはもったいないです。正しい指標で正しく失敗すると自然と予測値と実績値があうようになってきます。失敗を許容していくことも大事なので、社内の許可をとるのではなく、ユーザーという指針を頼りにしながら学習していくのが重要なのです」と助言した。
検証に失敗はつきものなので、事業構造を理解したうえで、失敗できる範囲を明確にして仮説検証を繰り返していくとよい。石垣氏は「DMM.comのユーザーは3500万人くらいいます。全員を対象に何か検証をして失敗した際のダメージは計り知れないですが、1万人を対象にした検証なら影響はわずかです。このように、分析可能なサンプル数を確保しながら、失敗のコントロールができる範囲でたくさんのA/Bテストを実施して改善をしています」と説明した。
A/Bテストを実施する際、統計誤差を無くし、評価の正確性を測るため、必ず同じバリエーションを比較するA/Aテストが必要となる。また、事業に大きな影響を与えないように、変更を加えたパターンについては適切な範囲で展開する必要がある。なお、A/Bテストは万能な検証方法ではなく、例えば、ユーザーインターフェースの刷新によるリブランディングなど、大きな変更を伴う場合は測定が難しい場合もある。
仮説検証のプロセスは、BMLループで作っていく。学習から仮説をたて（Learn→Idea）、プロダクトを作り（Build→Product）、計測し（Product→Measure）、データを取得（Measure→Data）、そしてデータから学習をする（Data→Learn）と進むサイクルだ。
ユーザーの行動から学習していくという面では、ログを取得する計測の部分と、得られたログを解析したデータが重要となる。石垣氏は「生のログデータでは、分析が難しいので、グラフ化するなど統計学的な観点でデータを可視化して判断します。そのため、どんなログを取得するかという設計が必要です。そして、仮説・検証ごとにダッシュボードを作って観察していきます」と述べた。
仮説検証が失敗する例として、必要なログ設計ができていない、仮説に対して複数の機能をつけてしまう、計測するサンプル数が足りないなどがある。例えば、比較テストをした片方に、他を圧倒するヘビーユーザーが紛れ込んでいた場合、その影響によって正しく評価できない。異常値を区別できるようにしなければならない。また2つの仮説を同時に満たすような検証では、変化の要因が捉えにくいので、1つの検証サイクルで、1つの仮説としたほうがよい。
