エンジニアの市川と申します。
LIFULL HOME'S の売買領域の開発を担当しています。
さて、さっそくではありますが、読者の皆さんは普段ABテストを実施しているでしょうか。
私たちの開発しているLIFULL HOME'Sでも、日々多くのABテストが実施されています。
ABテストの実施によって市場学習回数を増やし、より良いプロダクトを作り上げることが目的です。
その中で私たちエンジニアが貢献できる点といえば、市場学習のスピードを上げることです。
LIFULL HOME'Sでは長年ABテストを実施してきていますが、いくつかの問題がありました。
今回はその問題と、どのように解決に向けて動いたのかという点について紹介します。
※LIFULL HOME'SでのABテストにつきましては、以下のリンクをご参照ください。
A/Bテストは事前準備で決まる！？LIFULLのA/Bテスト事前設計の取り組み｜LIFULL Product Growth
ABテストにまつわる問題
ABテストを実施する1サイクルの期間が長い
まず、1点目の問題としては、ABテストを1回実施するまでの期間が長いことでした。
LIFULL HOME'Sのプロダクトには、独自のABテストの仕組みが実装されています。
そのABテストの仕組みを使うと下記のような手順と、期間がかかります。
gantt
axisFormat %m/%d
title 従来のABテスト
section ABテスト実装
ABテストの設定情報を設定ファイルに追記 :active, des1, 01/01,1d
各パターンの挙動を実装 :active, des2, after des1, 3d
テスト :active, des3, after des2, 1d
リリース :active, des4, after des3, 1d
計測期間 :active, des5, after des4, 7d
section Bパターン100%適用対応
設定ファイルに記載されている比率を修正 :crit, des6, after des5,1d
テスト :crit, des7, after des6, 1d
リリース :crit, des8, after des7, 1d
Aパターン50%, Bパターン50%で設定し、計測期間が1週間という短めの例です。
ABテストを実装し、Bパターンに有意差ありと判断した場合は、なるべく早くBパターンを100%にしたいです。
しかし、設定ファイルの比率を書き換えるだけでもプロダクトコードのリリースが発生するため、最短でも翌日のリリースとなってしまいます。
1日とはいえ、LIFULL HOME'Sのトラフィックを考えるとなるべく即時反映させたいです。
各マイクロサービスを開発する度にABのテストの仕組みが必要になる
2点目の問題です。
弊社ではLIFULL HOME'Sというプロダクトをメインに開発・運用していますが、このプロダクトはいくつかのマイクロサービスに分かれています。
そして、各サービスにABテストの仕組みが実装されています。
例：LIFULL HOME'S 賃貸基盤刷新におけるABテスト実施システムの構築 - LIFULL Creators Blog
graph TD
A("ABテスト")
B("ABテスト")
C("※ABテスト")
D("ABテスト")
L --- S
L --- R
L --- M
subgraph L["LIFULL HOME'S"]
A
end
subgraph R["賃貸"]
B
end
subgraph S["売買"]
C
end
subgraph M["マイページ"]
D
end
今後もプロダクトの成長に伴い、新たにマイクロサービスが生まれる可能性はあります。
その度にABテストの仕組みを実装していてはコストが高いです。
現に売買領域のアーキテクチャリプレイスのプロジェクトでは、新しくマイクロサービス化されたアプリケーションが存在しますが、初期段階ではABテストの仕組みを実装していませんでした。
※突貫的に外部サービスを利用し、画面の表示要素を差し替えてABテストを行っていた時期もありましたが、開発体験の良いものではありませんでした。
解決のための取り組み
共通のABテスト基盤の開発
前述した問題を解消するために、各マイクロサービス共通で利用できるpackageを開発しました。
弊社で基盤刷新を目的としたマイクロサービスのアプリケーションは、Node.jsを利用するよう統一化が図られています。
従って、npm packageとしてABテストの仕組みを提供すれば各アプリケーションで利用可能になります。
graph TD 売買-->ABテスト 賃貸-.->ABテスト マイページ-.->ABテスト
現在は売買のアプリケーションでのみ利用している状況ですが、ゆくゆくは統一していきたいと考えています。
設定情報の独立化
また、ABテストの設定情報に関しては、従来のアプリケーション内のファイルに追加する方法ではなく、独立したリポジトリで管理するようにしました。
graph TD
A(ABテスト package) -->|read| S[(S3)]
R[GitHub ab setting repository] -->|upload| S
R -->|PR merge| R
ABテストの設定情報を管理するためのGitHub repositoryを用意し、PRをマージするとその設定情報がS3にアップロードされるような仕組みです。
S3にアップロードされると、その設定情報がアプリケーション側に即時適用されます。
このように独立化させることで、本プロダクトへの影響を気にすることなくレビューや承認が行えるほか、プロダクト側のリリースフローに乗せる必要がなくなります。
結果的に、Bパターン採用の意思決定をしてから早ければ数分で100%適用を実現できます。
gantt
axisFormat %m/%d
title 現在のABテスト
section ABテスト実装
ABテストの設定情報を設定ファイルに追記 :active, des1, 01/01,1d
各パターンの挙動を実装 :active, des2, after des1, 3d
テスト :active, des3, after des2, 1d
リリース :active, des4, after des3, 1d
計測期間 :active, des5, after des4, 7d
section Bパターン100%適用対応
設定ファイルに記載されている比率を修正 :crit, des6, after des5,1d
まとめ
今回は共通のABテストの仕組みについて紹介しました。
この共通のABテスト基盤を通して、開発プロセスの効率化を図り、よりすばやく市場のニーズに応えるプロダクトを提供できるようになりました。
まだ導入フェーズですので、作ったものを最大限生かせるように働きかけていこうと思います。
ともに良いプロダクト作りをしてくれる仲間を募集しています。
