GrowthBook を導入し、A/B テストの実施をより効率化した

これまで（事前情報など）

弊社には ML エンジニアが開発した独自の A/B テストツール（詳細については差し控えます）がありました。
このツールは機能面で優れており、単純な A/B テストに加えて複数パターンへの振り分けや、同一ページ内でテストが干渉しないようにする namespace 機能を備えていました。また、振り分け比率を調整できるだけでなく、管理者や任意のユーザーに限定して適用したり、特定ユーザーを対象外にしたり、新機能をカナリアリリースする、といった運用も可能でした。

ツール導入前の課題

1 件の A/B テストを「開始〜終了」まで行うのに、多くの時間と手間が掛かっていました。
Ruby のコードにあるため、コードを変更し、ステージング環境で動作確認、コードレビュー、本番デプロイすることなりますが、ほとんどのA/Bテストはフロントエンドとセットで実施することも多く、1つのテストを実施して完了までに4回、本番デプロイする必要がありました。

• API のデプロイ
  • 実施したいA/Bテストの情報をAPIから返却する
• Frontend のデプロイ
  • A/Bテストの情報を取得し、実施したいテストに合わせて実装を行う
• Frontend のデプロイ（後片付け）
  • A/Bテスト終了後、結果が良ければ適用（または元に戻す）
• API のデプロイ（後片付け）
  • 実施したA/Bテストの情報をAPIから削除する

テストの内容にもよりますが結果として、平均5日を要していました。
（実装したら即本番デプロイではなく、弊社では基本1日1回本番デプロイしており、リリース作業の開始時刻までにプルリクエストをマージできなければ明日に回すといった状況もあって、なんだかんだで時間を要していたのもあります）

どのような状態を目指していたか

本番環境へのデプロイ頻度には制約があり、容易に変更することはできません。
そこで、これまでの A/B テスト運用で得た知見を踏まえ「API レイヤーを SaaS に置き換え、A/B テストの実施サイクルをさらに高速化する」 ことを目指しました。

• Unleash
  • https://www.getunleash.io/
• GrowthBook
  • https://www.growthbook.io/
• 自作する（サービスではないですが）
  • 既存のツールを管理画面から操作できるように作る

比較軸はただ1つ、「既存ツールと同等以上の機能を備えているか」 でした。
最終的に GrowthBook を採用しました。

主に以下3つあります。

• リードタイムを約2日短縮：API デプロイ工程が不要になり、エンジニア工数を削減
• テスト状況の可視化：実施中のテストを GUI 上で即時確認できるようになった
• 非エンジニアも閲覧可能：Readonly 権限でマーケターや PdM も状況を把握できるようになった

苦労や悩み

A/Bテストを実施する際の困りごとや混乱、ハマりポイント、また実装面でこうしておくと使いやすい。そういった経験則はすでにあったため、特に困ることなく進行していたように思います。大きな技術的ハードルはありませんでしたが、プロジェクトメンバーが本業と兼務だったため、進捗はややスローペースでした。

振り返ってみて

スローペースではあったものの、問題なく進行、推進できていたと思います。
社内に新しい SaaS を浸透させるため、以下を徹底していました。

• 役割分担：
  • 開発担当
  • ガイドライン整備・社内調整・プロジェクト進行担当（筆者）
• 社内ドキュメントの充実
• 定例 1on1 やチーム MTG での進捗共有

GrowthBook の導入により、A/B テストのリードタイムを大幅に短縮できました。
Feature Flag と Experiment を同一 UI で管理できるため、初めての方でも導入しやすいと感じています。 A/B テストの運用効率化に課題をお持ちの場合は、ぜひ検討してみてください。