技術本部 研究開発部の小松です。社内/社外向けのアプリケーション開発や、社内のデータ活用促進、学術研究に取り組んでいます。
本稿では、Sansan社内でデータに基づく意思決定を浸透させるために、A/Bテストの活用を推進しようとしている取り組みについて書きます。「しようとしている」という表現からわかるように、他のテック企業と比べるとSansanでのA/Bテストの活用はまだ定着しているとは言えません。A/Bテストに関する私たちの試行錯誤の過程を公開していくことで、読者の方からフィードバックを得たいという試みです。今後、A/Bテストに関する技術的な記事を発信していく予定ですので、ご期待ください。
なぜA/Bテストを推進するか
なぜA/Bテストを推進するかという筆者なりの回答は、以下の2点です。
- 成功確率のコントロールが難しいことを前提とすると、成功を引き当てるためには多くの実験が必要となる。その実験を検証する方法として最も信頼できるのがA/Bテストだから。
- 組織全体のデータ活用レベルを向上させ、A/Bテストの回数を通じてそのレベルを把握できるようにしたいから。
前者の成功を引き当てるために試行を増やすしかないという点、その検証方法としてA/Bテストがゴールドスタンダードであるという点は、各所で書かれていると思いますので割愛します。ここでは後者の点を、Sansanの実態に即して書いてみます。
Sansanでは全社横断データ基盤の誕生に伴い、データ活用も広がっています。全社横断データ基盤のプロジェクトの詳細は以下をご覧ください。
筆者はこのデータ基盤が社内に誕生して以来、利用者として活用してきました。特に最近、データ基盤に連携されるデータの質と量が向上し、そこからビジネスに貢献する機会が増えています。しかし、データを活用したビジネス価値の創造はまだまだこれからです。データ活用によるビジネス貢献を志してSansanに入社した筆者にとって、今のSansanは大変面白いフェーズにあると感じています。
そのような中で、組織にデータ活用が真に定着した状態は何かと考えました。その状態を定義することで、理想状態と現段階のギャップを把握でき、データ活用をより進めるためのアクションにつなげられると考えました。筆者がA/Bテストのプロジェクトに携わっていたこともあって、注目したのがA/Bテストの実施回数です。A/Bテストの回数を組織のデータ活用度合いの代理変数として使うアイデアは、Kohavi, Tang, and Xu (2020) にある組織の Experimentation Maturity Model に基づいています。Experimentation Maturity Model では、組織の状態を以下の4つのフェーズに分けています。
- Crawl Phase: 実験回数が年間10回以下
- Walk Phase: 実験回数が年間50回以下
- Run Phase: 実験回数が年250回以下
- Fly Phase: 実験回数が年1,000回以上
この Fly Phase に到達すれば、組織にデータドリブンな文化が根付いたと言えるでしょう。A/Bテストの回数以外にも、組織のデータ活用の度合いを計測する指標は他にも考えられますが、A/Bテストの実施にはデータ分析のリテラシーやデータ基盤、そしてリーダーシップが必要です。筆者はこれを、データ活用の総合格闘技のようなものと考えています。だからこそ、目標として設定するのにふさわしいと考えました。
なお、筆者が把握する限りでは、Sansanの2022年6月から2023年5月までの期間におけるA/Bテスト実施回数は合計31回でした。従って、上のモデルでいうと Walk Phase にあたります。まずは年間100回、そして将来は年間1,000回のA/Bテストを実施できる組織になることを目指します。目標が定まると、それに向けて何をすべきかという議論ができます。特にその目標設定が高いと力技で押し通すことが難しくなり、非連続な変化を求められます。
A/Bテストの浸透は難しい？
野心的な目標を立てたは良いものの、A/Bテストを推進することは大変です。過去にも社内でA/Bテストを試みたものの、定着に至らなかった例もあります。なぜなのか考えると、A/Bテストを実施するのにかかるコストが見合わないことが主な理由だったと考えられます。プロダクトへの実装やデータ基盤の整備、データ分析人材の確保など、A/Bテストの実施には多くのコストがかかります。A/Bテストが有用であると組織内での合意を得るためには、A/Bテストのビジネス価値を示すエビデンスが必要です。
A/Bテストが良いと訴求するだけでは効果が薄く、小さな成功体験があるとA/Bテストを行う機運が高まるように筆者は感じています。逆に言うと頓挫したA/Bテストプロジェクトは、当事者間でA/Bテストの成功体験が共有されなかったものがほとんどのように思います。Microsoftの以下の記事でも、A/Bテストを前進させるためには、初期段階で実施するA/Bテストを賢く選ぶべきと書かれています。
弊社がカスタマーサクセスと実施しているA/Bテストについても初期段階の成功を特に意識していました。その点は以下の本に書かれていますので、よろしければご覧ください。
『あの会社はなぜ、経済学を使うのか？ 先進企業５社の事例でわかる「ビジネスの確実性と再現性を上げる」方法』
A/Bテストを実施するリターンが不透明であり、微小な効果しか得られない場合、その実施意義が問われる可能性があります。Amazonのような巨大なビジネスでは、微小な差であっても莫大な利益を生むため、微小の効果量であっても検知しようとするインセンティブは高いと考えられます。ただし、弊社のようなBtoB SaaSでは、0.1%の利用率の差が認められたとしても、そのビジネスインパクトは如何程か？という問いはありそうです。
A/Bテストの実施がペイしないというのが、それを推進するうえで障壁となりそうだと書きました。この課題に対して、筆者はまだ明確な解決策を見いだしていません。例えば、長期的な視点を持ち、A/BテストがKPIのベースラインを向上させることを示すことが重要なのかもしれません。
ということを書いていた矢先、素晴らしい本が出版されました。
実務者がより良い意思決定を行うために効果検証について知るべきことが、この本には丁寧に書かれています。意思決定と探索的分析のつながり、A/Bテストと観察データ分析の役割について詳しく説明されています。特に、第6章「おわりに 実務における課題と展望」で述べられている「A/Bテストはしなくてよい？」というTipsは示唆に富んでいます。A/Bテストの実施に伴うコストを考慮し、誤った意思決定がもたらす影響の大きさに応じてA/Bテストを実施するかどうかを決定すべきではないかという提案は、A/Bテストをどのような場合に推進すべきかについての一つの指針となりそうです。
加えて、筆者がこれまでのA/Bテストの整理で欠いていたと思う点は、観察データ分析の重要性です。観察データに基づく探索的データ分析は、筆者もこれまで多く実施してきました。それは仮説の探索範囲を狭め、より良い意思決定を行うために不可欠です。A/Bテストと観察データ分析は相互補完的な関係にあります。組織により良い意思決定が定着したかを測る指標としてふさわしいのは、A/Bテストの回数だけではなく、A/Bテストと観察データ分析の両方を組み合わせた効果検証の回数であるべきかもしれません。
目標達成のために、関係者と目線をあわせる
A/Bテストの推進することの難しさを認識しつつも、その推進を目指すと決めました。そして、その目標をまずは年間100回、そして長期では年間1,000回を目指すことにしました。その目標達成に向け、まず研究開発部のデータ活用に携わる研究員・エンジニアと目線合わせをしました。A/Bテストの回数目標達成のためには多くの人の協力が必要不可欠です。まず身近なところからA/Bテストへの理解者を増やすことが、この目線合わせの狙いでした。関係者が一堂に会した場で、なぜA/Bテストを推進するのが大事かを筆者なりに言語化したものを伝え、そして目標達成のために何が必要かを整理しました。具体的には、成功を増やすために実験回数 = A/Bテストの回数を増やすことが大事だとして、そのA/Bテストの回数をどのように増やすべきかを要素分解して整理しました。
A/Bテストを実施できるチャネル数が短期的には変化しないと仮定すると、A/Bテストの回数を増やすためには実行のリードタイムを短縮することが重要です。A/Bテストの実行プロセスをPlan, Do, Check, Action の4つに分け、現状実施しているA/BテストのAsIsとToBeを整理しました。その中で、特に結果を可視化し確認するCheckの部分がA/Bテスト実行フローのボトルネックとなっていると仮説を立てました。これは筆者がA/Bテストの分析で特に感じることです。必要なデータをSQLで集計し、PythonまたはRで分析し、結果を可視化してドキュメントにまとめるプロセスは、手作業に依存する箇所があり、一貫したパイプラインとして確立できていません。このあたりは、この課題は、私たちがA/Bテストの推進に際し大いに参考にしているメルカリさんの以下の記事と共通していると考えています。
関係者を集めた議論を通じて、A/Bテストの結果を可視化し共有することにかかる時間を短縮することが、他の改善ポイントと比較して現時点で最も費用対効果が高いと結論付けました。そして、分析結果の可視化を自動化する取り組みを現在進めています。こちらは別途記事にして公開予定です。
終わりに
以上、A/Bテストを推進しようとしている話を書きました。言語化してみると、A/Bテストを社内で推進するには課題しかないと改めて感じました。その格闘する過程を今後も発信する予定です。本稿の内容に関するコメントはもちろん、本稿で触れた課題解決に取り組みたいと思う方のご応募をお待ちしています。
References
- Fabijan, A., Dmitriev, P., Olsson, H. H., & Bosch, J. (2017, May). The Evolution of Continuous Experimentation in Software Product Development: From Data to a Data-driven Organization at Scale. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE) (pp. 770-780). IEEE.
- Kohavi, R., Tang, D., & Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.
