はじめに
こんにちは takanamitoです。
この記事は連載です。今回は開発編だよ！
以前の記事についてはこちら
tech.speee.jp
tech.speee.jp
この記事では、
『エンジニアが高速A/Bテストをどう実現したのか』
を書きたいと思います。
高速A/Bテストのためにリリースissue数を80%・回数を47%増加させた
| 変化量(%) | |
|---|---|
| 平均消化issue数 | 80%↑ |
| 平均リリース回数/週 | 47%↑ |
今回の一連の『高速A/Bテストドリブンな改善フロー』を始めてから、リリース項目とその回数を増やしました。
この数の増加は単純に何か良さそうな変化ですが、チームとしては明確に意図があって起こした変化です。
これは第1回の記事にもあるように
- 「改善率よりも改善数」を優先した
- 「成功した施策からも失敗した施策からも何かを学び取る」ため
こういった理由で起こした変化でした。
エンジニアがプロダクトに貢献するためにできる大きなポイントの1つに
「実施できる施策の数を増やすこと」があると思っており、ディレクターを中心に課題出しの質は担保してもらい
エンジニア側ではその施策をひたすら実施していくことに注力しました。
エンジニアチームはどうやってそれを実現したのでしょうか？
1.バグを即検知可能な環境でリリース回数を増やした
リリース本数を増やすということは、単純に考えると バグの増加 につながります。
ですがA/Bテストをやるにあたって、監視環境を整備していたことが役立ちました。
やっていたのは大きく2つ
- Datadogでnginxの指標をグラフ化 (レスポンスタイム, ステータス)
- Sentryを使った例外の監視
これによって
- 急激な500系のレスポンスの増加
- 一部ページに重いSQLが発生した場合にレスポンスタイムの悪化
- バグによるエラーの発生
などに気付くコストが圧倒的に軽くなっていたため100%の精度ではなくても、
気付いてすぐ戻せることからガンガンリリースをしました。
また、まとめて一度にリリースするよりも、アプリケーションに対する変化量が小さく
すぐロールバックできるので、以前よりリリースに対する心理的負担が大きく減ったと思います。
2.リリース頻度が増したので1回ごとのコストを下げた
A/Bテストを始めて、徐々にリリースの頻度が増えてきました。
すると今度はリリース1回ごとの手間が気になり始めたので
以下のように減らせそうな手順を減らしました。
| Before | After | |
|---|---|---|
| コードレビュー | エンジニア全員のLGTM(承認)必須 | 1人のLGTM(承認) or ユーザーに影響しない系はレビューなし |
| ステージング確認 | ディレクターが確認 | ディレクターが確認 |
| リリースノート | リリース毎に必ず作成 | 手でコマンド叩く作業がない限り作らない |
| リリース時間 | ユーザーが少ない時間帯 | 大きめのリリース以外は出せる時にすぐ出す |
先述した監視環境があるため、リスクを小さくリリースコストを下げることができました。
とはいえ、レビューを減らすといった作業は個人の責任や負担を増やしてしまうため
チーム内で「やばそうなやつや心配なやつは積極的にレビューしてもらおう」と話していました。
3.シンプルな仕組みでA/Bテストを実施するためにsplitを導入
A/Bテストを高速に進めるにあたって役に立ったのがsplitです。
splitrb/split: The Rack Based AB testing framework
https://github.com/splitrb/split
これは@iharaに教えてもらって入れたgemで
- A/Bテストの実装
- 実施するA/Bテストの切り替え
- A/Bテストの集計/結果画面 (Redisサーバーを1台用意)
までカバーしてくれるgemです。
このgemを入れてA/Bテストを実装するだけで 集計結果は勝手に生成されるため、リリース後にディレクターが勝手に結果画面を見てSlackに共有するフローができました。
Redisの集計サーバーが死んだ場合にはA/Bテストを強制終了して
アプリケーション全体が死なないようにしてくれるあたりも安心ポイントです。
逆にファネル的な連続する数字を追いたくても、splitでは機能が提供されていないため
GoogleAnalyticsなどと併用して数字をチェックする必要があるところは気になるかもです。
やってみて感じたこと
1.エンジニアがプロダクト改善の意見を出しやすくなった
A/Bテストを始めてから起こった変化の1つです。
下記の表はA/Bテスト開始前後の施策についての比較です。
| Before | After | |
|---|---|---|
| 施策内容 | SEO対策 | A/Bテスト |
| 結果が出るまで | 数週間 | 最短1日 |
| 結果に対する感覚 | 何が効いたのかよくわからない | 理由を考えてエンジニア同士で議論できる |
SEO系の施策が多く、いくつもの施策が同時に走ったり、結果が出るまで時差があるため
仮に順位が上がったとしても「いつの」「何の施策が」「どういう理由で」効いたのかわかりにくい。という現状に悩んでいました。
対してA/Bテストを始めてからは以前のの記事にもある通り
- 1つずつ検証するようにした
- 仮説と考察を施策毎にきちんと書くようにした
など、1つ1つのテストに対し「何の数字に」「どういうインパクトがあるのか」を定義して実行し、2～3日すれば結果が出るため、即みんなで結果について話すことができました。
実際にはこんな感じで朝会やSlackで話しています。
2.とにかく数多く試していくしかない
改めて今回A/Bテストを試してみて思ったことですが
自信のある施策であまり数字が上がらなかったり、ちょっとした文言追加で大きく数字が跳ねることもあり
何度も試さないとわからないことが多いということを実感しました。
逆に何度もやってると、ユーザーがどういうものを好むのかだんだんわかってきました。
エンジニアという立場で、プロダクト改善に協力するには
仮説を検証するというプロセスをいかに早く、数多くこなせるかが重要だと思っています。
A/Bテストという手法もそうですが、エンジニアチームにとっては この改善プロセスの変化が最も大きな収穫でした。
次回予告
ここまでは
- 第1回：『成果』
- 第2回：『考え方』『施策』
- 第3回：『開発チームの貢献の仕方』
について書きました。
次回はまたまたディレクターの@cultivaから
具体的なA/Bテストの施策の考え方についてのブログを書きます。
