A/Bテストに頼るべきでない判断に、次の二つがあると思う:
■サービスの思想的に、設計的に、あるいは倫理や法律的に正しいかどうか、についてはカバーしてくれない。
例えばパスワードが簡単すぎたら警告を出す会員登録フォームと、文句言わずに受け付ける登録フォームとを比べたら、たぶん後者の方が登録率はよくなるわけですよ。あるいは、でかい広告と小さい広告を比べたら、クリック率は単純に面積に比例して大きくなる。
A/Bテストは、人間の本能的な、あるいはとても正直な反応をさらけだす仕組みだ。しかし人間の反射的な行動って、利己的だったり、後で大きな間違いにつながったりもしがち。人間が、深い考え無しに行動することで起こしがちな間違いは、そのままA/Bテストが起こしがちな間違いでもある。
■A/Bテストの結果には、長期的な展望は加味されない。
ソーシャルネットワークからの流入が重要になるだろうとか、モバイル端末からのアクセスが増えるだろうとか、後から考えれば2〜3年前から明らかだったよね、と思うような長期的な変化って色々ある。でもA/Bテストは、現在の状況を前提とした実験であって、ゲームのルールがまったく変わってしまった未来のシミュレーションをするには不向きだ。
実際、そういう長期的な見通しのもと、A/Bテストの結果の逆を行く判断が下される現場を見たこともある。
とあるサービスで、数年先の変化を見越しての大きな変更が試みられたのだけど、A/Bテストの結果は芳しくなかった。だけど結局、テストの結果に関わらずその変更は断行された。
■決断の責任から逃げるためにA/Bテストに頼るべきではない
上の例は、A/Bテストの結果を無視したわけではなくて、「A/Bテストの結果と、A/Bテストには現れない別のファクターとを付き合わせて検討した結果、テスト単体とは違う結論に至った」のだと思う。
A/Bテスト導入のスタンスには、大きく分けて以下の二つがあると思う。
個人的には後者 2 のスタンスはあまり好きではない。
A/Bテストには、客観的な結論が下せるという利点がある一方、決断の重責から逃れるためにテストに判断を丸投げする、という悪癖も招きがちだ。
例えばボタンを右に置くか左に置くかなんてA/Bテストで決めることじゃないよね。ボタンの配置にはきちんとしたポリシーなり一貫性なりがあるべきで、ボタンが右にあったら押すけど左にあったら押さないようなふわふわしたユーザーのためにそんな手間をかけてどうするのか。
A/Bテストは判断の一要素であるべきで、最終的に全ての判断材料を見渡して、全責任を背負って判断を下せるリーダーがプロジェクトには必要だと、僕は最近思う。
■A/Bテストを遺伝的アルゴリズムのように使って、自律的に進化していくアプリケーションフレームワークって実現可能なのかな?
上記 2 のスタンスが好きではない理由のひとつには、その用法に本当に適したA/Bテストフレームワークを僕が見たことがないから、というのもあるかもしれない。
遺伝的アルゴリズムみたいに、ひたすらランダムなバリアントを生成し、ユーザの反応が良かったものだけが勝ち進んで行く、みたいな運用はラディカルで面白いとおもう。でも現実には、僕がいままで見たことのあるA/Bテストのアプリケーションフレームワークって
みたいな泥臭いインプリメンテーションがほとんどで、バリエーションが増えるたびに技術的負債が増えてエンジニアのモチベーションが下がる仕組みなので、遺伝的アルゴリズムに必要な高い回転率 & 柔軟性に対応するのは無理がある。
この方針を追求するなら、A/Bテストの仕組みが最初から組み込まれたアプリケーションフレームワークを一から作る必要があるんじゃないかな。
それはそれで面白そう。作成者の意思のまったく介在しないUIってどうなるのか興味はある。(限りなくギャグに近いものに収束するような気もする。)
- 「正しさ」に基づく判断
- 長期的な判断
■サービスの思想的に、設計的に、あるいは倫理や法律的に正しいかどうか、についてはカバーしてくれない。
例えばパスワードが簡単すぎたら警告を出す会員登録フォームと、文句言わずに受け付ける登録フォームとを比べたら、たぶん後者の方が登録率はよくなるわけですよ。あるいは、でかい広告と小さい広告を比べたら、クリック率は単純に面積に比例して大きくなる。
A/Bテストは、人間の本能的な、あるいはとても正直な反応をさらけだす仕組みだ。しかし人間の反射的な行動って、利己的だったり、後で大きな間違いにつながったりもしがち。人間が、深い考え無しに行動することで起こしがちな間違いは、そのままA/Bテストが起こしがちな間違いでもある。
■A/Bテストの結果には、長期的な展望は加味されない。
ソーシャルネットワークからの流入が重要になるだろうとか、モバイル端末からのアクセスが増えるだろうとか、後から考えれば2〜3年前から明らかだったよね、と思うような長期的な変化って色々ある。でもA/Bテストは、現在の状況を前提とした実験であって、ゲームのルールがまったく変わってしまった未来のシミュレーションをするには不向きだ。
実際、そういう長期的な見通しのもと、A/Bテストの結果の逆を行く判断が下される現場を見たこともある。
とあるサービスで、数年先の変化を見越しての大きな変更が試みられたのだけど、A/Bテストの結果は芳しくなかった。だけど結局、テストの結果に関わらずその変更は断行された。
■決断の責任から逃げるためにA/Bテストに頼るべきではない
上の例は、A/Bテストの結果を無視したわけではなくて、「A/Bテストの結果と、A/Bテストには現れない別のファクターとを付き合わせて検討した結果、テスト単体とは違う結論に至った」のだと思う。
A/Bテスト導入のスタンスには、大きく分けて以下の二つがあると思う。
- 導入したい新機能/変更があるが、それが既存のユーザエクスペリエンスを損ねることがないか確認したい。(→ A/Bテストの結果が悪くなければ基本GO)
- 既存の枠にとらわれず、さまざまな選択肢をユーザに与えてみて、支持される方向性を発見したい。(→A/Bテストの結果が特に良い場合だけGO)
個人的には後者 2 のスタンスはあまり好きではない。
A/Bテストには、客観的な結論が下せるという利点がある一方、決断の重責から逃れるためにテストに判断を丸投げする、という悪癖も招きがちだ。
例えばボタンを右に置くか左に置くかなんてA/Bテストで決めることじゃないよね。ボタンの配置にはきちんとしたポリシーなり一貫性なりがあるべきで、ボタンが右にあったら押すけど左にあったら押さないようなふわふわしたユーザーのためにそんな手間をかけてどうするのか。
A/Bテストは判断の一要素であるべきで、最終的に全ての判断材料を見渡して、全責任を背負って判断を下せるリーダーがプロジェクトには必要だと、僕は最近思う。
■A/Bテストを遺伝的アルゴリズムのように使って、自律的に進化していくアプリケーションフレームワークって実現可能なのかな?
上記 2 のスタンスが好きではない理由のひとつには、その用法に本当に適したA/Bテストフレームワークを僕が見たことがないから、というのもあるかもしれない。
遺伝的アルゴリズムみたいに、ひたすらランダムなバリアントを生成し、ユーザの反応が良かったものだけが勝ち進んで行く、みたいな運用はラディカルで面白いとおもう。でも現実には、僕がいままで見たことのあるA/Bテストのアプリケーションフレームワークって
if (トリートメント側なら)
これを見せる
else (コントロール側なら)
あれを見せる
みたいな泥臭いインプリメンテーションがほとんどで、バリエーションが増えるたびに技術的負債が増えてエンジニアのモチベーションが下がる仕組みなので、遺伝的アルゴリズムに必要な高い回転率 & 柔軟性に対応するのは無理がある。
この方針を追求するなら、A/Bテストの仕組みが最初から組み込まれたアプリケーションフレームワークを一から作る必要があるんじゃないかな。
それはそれで面白そう。作成者の意思のまったく介在しないUIってどうなるのか興味はある。(限りなくギャグに近いものに収束するような気もする。)