みなさんこんにちは！機械学習チームのたかぱいです。
半年ほど前からA/Bテストの標準化に取り組んでいたので、本日はその背景やプロセスについてご紹介しようと思います。
尚、以下メルカリさんの事例を参考にさせていただいています（この場を借りて御礼申し上げます。ありがとうございます！）
標準化に取り組んだ背景
コネヒトでは日常的にさまざまなチームでA/Bテストが行われていました。
しかし、以下のような課題があると感じていました。
- A/Bテストに関する知識にバラつきがある
- チームごとにA/Bテストのドキュメントの書体が異なるので、読み解くのにコストがかかる
- 「どのような実験」が「どのくらいの期間行われていたか（いるか）」という情報が一目で把握できない
etc...
上記のような課題は時間が経てば経つほど負債が大きくなると判断し、一度テコ入れした方が良いと思い、標準化に取り組みました。（後述する書籍の日本語版が発売になったことも大きなトリガーでした）
ここで言う「標準化」 is 何？
標準化によって得たい効果は、以下のようなものを想定していました。
- 実験計画書のテンプレートをつくり、レビュー文化も導入することで、人依存による実験設計・検証品質の分散を減らす
- 書体が揃うことで過去のドキュメントを読み解くコストが下がる
- いつ、どんなものが誰によって検証されたかを振り返りやすく・見やすくする
- 実験文化そのものの醸成を促す
- 他のチームでどんな実験をやっていて、どんなメトリクスが使われているのかを共有知とする
- 過去に何がうまくいって、何がうまくいかなかったのかを振り返ることができる
- 未来へKnowledgeリレーを繋いでいきたい
そのため、まずは誰でも使える標準化テンプレートを作成し、それに沿って実験を行うフローにアップデートしようと考えました。
以降で、標準化プロセスでポイントだと感じた以下２点について紹介できればと思います。
- さまざまな職種の方と輪読会を行い、A/Bテストに対する視座を揃える
- 先んじて活用事例を作成し、今後社内で行われる実験で利用するイメージを沸かせる
最終的に作成したテンプレートは冒頭で述べたメルカリさんのテンプレートに若干アレンジを加えたものになりました。（最後にサンプルを載せています）
1. さまざまな職種の方と輪読会を行い、A/Bテストに対する視座を揃える
まず最初に行ったことは、いろんな職種の方を交えて輪読会をしました。
読んだ本は界隈で有名な A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは という書籍です。
社内slackで参加者の募集を行い、ML、インフラ、サーバーサイド、ネイティブエンジニアやPdMといったいろいろな専門性を持った方々に参加していただきました。
個人的にはPdMを含めた様々な職種の方に参加してもらえたのはとても良かったなと思っています。
例えば、本を読んでいく中で「インフラでこの辺の数値って計測できるんですか？」といった議論や、「ネイティブでこの辺のログって取得できるんですか？」といった議論をその場で行うことができました。
また、PdMにも参加してもらったので「今のコネヒトだとこの辺の検証はどうやっているのか」や「この辺注意した方が良いよね」といった共通認知を取ることもできました。
本を読み終えたあとは、輪読会で議論した内容をもとにテンプレートに落とし込み、関係者にレビューしてもらいブラッシュアップしていきました。
2. 先んじて活用事例を作成し、今後社内で行われる実験で利用するイメージを沸かせる
無事にテンプレートが作成できても、実際に使うまでにはハードルがあると思います。
そのため、機械学習のプロジェクトで過去に行ったABテストをこのテンプレートに落とし込み、いくつかサンプルを作成しました。
これにより少しでも活用イメージを沸かせてもらい、「自分も使ってみようかな」というアクションを促しました。
作成したテンプレート
冒頭で紹介したメルカリさんの事例にあるように、「Background」「Test setting」「Metrics Details」「Action plan」という項目は、細部は異なりますが概ね同じ項目を採用しました。
大きな差分としては「Result」という項目を追加しています。
この項目は、実験が終了した後に記載する項目で、実験が複数のメトリクスにどの程度の影響を与えたかを記録しておく項目です。
数値が改善した理由（成功した理由）や、数値に変化がなかった or 改悪した理由（失敗した理由）などの考察も記入します。
ここの記載内容をもとに、A/Bテストの成功 or 失敗を判断し、事前に決めておいたAction plan**に則ってNext actionに移行します。
Resultは以下のような項目でテンプレート化しました。
# Result ## OEC metricsの結果 - hoge ## Guardrail metricsの結果 - hoge ## Debugging metricsの結果 - hoge ## 考察 - hoge ## Next action - hoge
この項目を追加した意図としては、実験計画書とその実験の結果や得られた知見をセットで記録しておくことで、後から振り返りやすくしたい、という想いがあります。
標準化に取り組んでどうだったか？
運用を始めて半年ほど経過しましたが、このテンプレートを使って数十件の実験計画書が作成されています。
実験計画書を作成する際も項目に沿って埋めるだけで良くなったので、準備コストは削減できているなぁと感じています。
また「こんな検証してるんだな〜」ということも分かりやすくなり、各チームの簡易的な活動の可視化にもなっていると感じています。
最後に
前提として、実験の成功率は高くないと思っています。
BingやGoogleでも、アイデアの成功率は約10％〜20％程度、Slackでも30％程度しかポジティブな結果を得られないことが公開されています。
つまり、70％以上は失敗するわけですが「失敗=負け」だとは思っていません。失敗から何も学べない状況こそが本当の敗北だと思っています。
そうならないためにも、失敗前提で標準的なプロセスに則ってサイクルを簡単に回していける仕組みを作っていくはとても大切だと思います。
実験計画書を溜めておくことによるメリットを享受できるのはもう少し先になると思いますが、確実に未来へ資産を残していけていると思うので、形骸化しないように今後もブラッシュアップしていこうと思います！
We Are Hiring !!
コネヒトでは一緒に働く仲間を募集しています！
もしご興味があれば、カジュアルにお話しさせてください！
