「A/Bテスト」と「実験の文化」で
データを競争優位に変える

2014.04.21

実験から実践へ

実験を成長につなげていくための、有用なヒントをいくつか紹介しよう（詳細は、こちらの英文記事を参照）。

1. チームは小規模にとどめる
テストを行うためには、3～4人程度のチームでよい。その構成は、エンジニア、デザイナーまたはフロントエンド開発者、事業または製品責任者とする。デザイナーは反復的な思考に基づいてテストを実施できる必要がある。製品責任者は毎回のテストを分析できなくてはならない。テストの結果を得るために別の部署に頼るのを避けるためだ。

2. 1つの指標をテストする際に、多くの指標を参照する
ある指標をテストしても、その変動結果で必ずしもすべてが説明されるわけではない。多くの優秀な人々が、A/Bテストの結果に惑わされてきた。本当にどのような変化が起こったかを把握するためには、さまざまな測定指標を見る必要があり、それでも判定を間違えることはあるだろう。テストが失敗しても、諦めてはいけない。何が起こったのかを理解し（実際に動いた指標を見つけるなど）、それを今後の反復に活かそう。

3. 「平均的な顧客層」は追求しない
顧客の平均に対してテストを実施しても、うまくいかない場合が多い。「新規顧客vs既存顧客」のように、特定の顧客セグメントを選ぼう。また、特定の地域、言語、あるいはユーザーのペルソナで区切るといい場合もある。平均値にとらわれずさまざまなセグメントを掘り下げることで、初めてそうした洞察を得ることができるだろう。

4. 小さな変更をテストする
何カ月も費やして設計したテストが失敗すれば、それだけ時間が無駄になる。設計に長い時間を費やす必要のあるテストは、そもそもやり方が間違っている。仮説に基づいて最小限の力でつくれるテストを見つけよう。1度に1つの変数がベストだ。

5. アイデアを再テストする
テストは、季節の違いで失敗することもあるし、ほんの小さなニュアンスを1つ見逃したせいで失敗することもある。だからといって、そのテストを葬り去ってはならない。実行したテストのバックログを保持し、そのいくつかを後で再実行してみよう。驚くような発見があるかもしれない。

6.パフォーマンスを忘れず意識する
設計と最適化のプロセスに、パフォーマンステストを含める。ページを読み込む時間のわずかな増加だけで、優れたデザインの効果が阻害される場合がある。他のテストと一緒に、ページの重さや読み込み速度もテストすること。私はこれまで、成功すべきテストがパフォーマンスの問題だけで失敗するのを見てきた。

テストの実施に関する詳細は、このスライドを参照してほしい。

HBR.ORG原文：A/B Testing and the Benefits of an Experimentation Culture February 5, 2014