Spotifyでの大規模な実験

A/Bテストの試行回数を増やして同時に多数の実験をしたい場合、自分たちのプロセスとプラットフォームに適応する必要があり、これは、文化にも影響を及ぼす可能性がある。こう主張するのは、SpotifyのBen Dressler氏だ。制御された実験でプロダクトの研究をすることで実際に顧客がどのようにプロダクトを使っているかについてのアイディアをぶつけ、これらのアイディアがユーザーの振る舞いに影響を与えるかどうかをチェックできる。

多くの場合、ユーザーが複数のA/Bテストに同時に参加するのは問題ない。ランダムな割り当てによってテストグループをまたがる影響は一様になるからだ。しかし、あるユーザーに衝突する実験を生成する場合、これは問題になる。例えば、あるテストで白いテキストを提供し、別のテストで白い背景を提供する場合だ、とDressler氏は言う。

Dressler氏はGOTO Berlin 2016でbuilding a culture of experimentation at Spotifyと題して講演をした。InfoQはこのカンファレンスの内容をインタビューや要約、記事でカバーしている。

InfoQは講演のあと、氏にインタビューし、なぜ企業は実験をするべきなのか、どのようにしてA/Bテストをスケールさせるのか、A/Bテストに対する疑念にどのように対処するのかについて話を聞いた。

InfoQ: なぜ企業は実験をするべきなのでしょうか。

Ben Dressler: ほとんどの企業や組織がある種の結果に影響を与えようとしています。Spotifyのようなプロダクト駆動の組織では、その結果とは、多くの顧客の、購入や利用継続などのアクションに基づいたメトリクスです。そして、従業員は最高の結果を出すための多くのアイディアを持っています。顧客についての定量的定性的データを集めることは、何が鍵となる振る舞いを引き起こすのかについての理解を改善する素晴らしい方法です。しかし、制御された実験がなければ、例えば、ある機能を追加するという行動が顧客の行動を変えるのかどうか、それとも、単に相関があるだけで、追加でこの機能にリソースを追加しても見返りがないかどうかを判別できません。

A/Bテストはウェブサイトの詳細を最適化するためのツールになるという評価があります。しかし、A/Bテストは根本的には、アイディアを現実にぶつけるためのツールであり、そのアイディアが思った通りに機能しているかどうかをチェックします。

InfoQ: A/Bをどのようにスケールさせることができますか。

Dressler: A/Bテストの回数を増やすことは、いくつかの条件に依存します。どのくらい高速にA/Bテストを回したいのか、1ユーザー当たりどのくらいのテストをするか。ユーザーのサイズは事前に決まっているのが普通です。従って、ユーザーひとり当たりのテスト回数を増やし、回す速度もより高速にしたくなるでしょう。この段階で起きる課題は、チームのオーバーヘッドです。技術的なオーバーヘッドとプロセスに関するオーバーヘッドがあり、プロセスを十分に合理的にしないと解消しません。アプリがあり、すべての変更をハードコードしなければならないとしたら、アプリのリリースサイクルのボトルネックになるでしょう。エンジニアとデザイナーは完全に磨かれていないテストを出荷するという考えを受け入れる必要があるかもしれません。いくつかのチームが陣頭指揮をとって、プラットフォームとプロセスにどのような変更をすることですべてのチームに展開できるのかを明らかにするという方法は、よいアイディアです。

ユーザーひとり当たりのテストを増やすと衝突する可能性があり、ユーザー体験を壊してしまうかもしれません。あるチームがすべてのフォントを白に変更し、別のチームが背景を白に変更してしまったら、このふたつのテストに出会ったユーザーはプロダクトを使えません。これに対する解決策はいくつかあるのですが、多くの場合は、ひとりのユーザーが複数のテストに参加するのは問題ありません。ランダムにユーザーをテストグループに割り当てているので、すべてのテストグループの中に多くの影響を受けるユーザーがいます。A/Bテストはグループ間の違いだけに注目するので、仮にすべてのユーザーが影響を受けても、結果はおかしくはなりません。

InfoQ: 実験の例を教えてください。

Dressler: 少し前に、私たちは研究の中にあるいくつかのパターンを見出しました。その結果、Spotifyのナビゲーションによって私たちは機会損失をしているかもしれないという考えに至ったのです。アプリのナビゲーションをシンプルにすることによって、新しいユーザーに対してSpotifyでできることについてのより良いアイディアを与えることができるのではないか、それによって、彼らがこのプラットフォームに止まり続ける機会が増えるのではないか、と考えました。

このような場合、従来の常識では、デザインのスプリントを開始し、いくつかのユーザーテストを実施して、最終的には結果がどうなろうと試験的にリリースしてみます。私たちの場合は、デザイナーがいくつかの調査を行い、すぐに第一段階のA/Bテストを開始しました。ひとつはナビゲーションのUI(UIだけ)を変更したテストであり、もうひとつは情報アーキテクチャ(カテゴリのラベルと構造)を変えたテストです。このふたつのテストは磨き上げられたものではありません。より多くの顧客向けに触ってもらうように意図したものではありません。このテストによってユーザーの振る舞いが変化したかどうかの指標を得るためのテストです。大きな変更をしてもクリックスルー率が変わらなければ、このアイディアにこれ以上のリソースを追加するつもりはありませんでした。しかし、結果を見ると、いくつかのテストグループでユーザーの振る舞いが良い方向へ変わっていたのがわかりました。そこで、この方向で確信を深めるために、少ないサンプルでのユーザーで異なるデザインのプロトタイプでテストをして、ばらつきを排除して、素早く情報を集めました。そのあと、従来のA/Bテストを使った最適化を行い、最終的にユーザーにリリースするバージョンに到達しました。

InfoQ: A/Bテストに対して懐疑的な人にはどのように話せばいいでしょうか。

Dressler: まず、実験を行うという方法は良い方法である、ということを言いたいと思います。複雑なエンジニアリングと高度な統計が合わさると簡単にミスを犯してしまいます。開発プロセスとデータ収集の弱点は多くのバリエーションを構築し統計的テストを行うときに、増大します。A/Bテストはプロダクトの調査をする上で強力な力をもっています。特別な専門性が必要で、プロセスと文化を変えてしまう可能性を持っています。変化は軋轢を生み出します。

とはいえ、実験は強力でいくつかのクリックを排除するという以上の可能性を持っています。適切に準備して賢い実験を実行すれば、間違ったアイディアに多くのリソースを注ぎ込むことを避け、早めに需要な情報を集めたり、多くの小さなアイディアをテストして、効果があるものを取り上げることでボトムアップのイノベーションを実現できます。スピードについては次のように考えれば十分です。時速200マイルで走ったとしても間違った方向に向かっていれば速いとはいえません。

私はすべての人にその手で実験をしてみることをお薦めします。間違った実験は完璧ではない計測に対して、科学は対処方法を用意してくれています。テストを再試して同じ結果になるかどうか確かめること。各自の作業をレビューするコミュニティを形成し、実践と基礎になる方法を繰り返すこと。そしてもっとも重要なのは、絶対的に確実な方法はないということに自覚的になること。不確実な情報に基づいて意思決定をすることはプロダクトマネージャにとっては普通の仕事です。実験はこの仕事を手助けするツール以上のものではありません。