エンジニアがABテストをするときに気をつけること

## はじめに
こんばんは。@posterkeisukeです。

今日で3月も終わり、明日から新年度が始まりますね。
あっという間の1年でした。働き出すってこういうことなのでしょうか。

さて本題ですが、先日ABテストに関する勉強会に参加してきました。
ちょうど、私の業務でもABテストに関わることが多いので、結構楽しみでした。

[【サポーターズCoLab勉強会】エンジニア主導でABテストをやる方法 - サポーターズCoLab](https://supporterzcolab.com/event/305/)

僕も予想外だったのですが、世間のエンジニアの方は思っていたよりもABテストというものに興味がないのか、初めて勉強会でマンツーマンレッスンを受けました笑

[mizukami2005 · GitHub](https://github.com/mizukami2005)さんありがとうございました。

私も業務で関わるまで、あまり興味がなかったのですが、エンジニアがあまり追えない数字周り（人によってはですが）に直結するところを改善するので、とても楽しい（時もあります。）
ただ、いざ改善となっても何から手を付けて良いか分からないので（あまり、そういう記事がなかったので）
私の備忘録と、世間への布教を兼ねて記事に残そうと思います。

今後、業務や興味を持ってABテストをやる際に参考になればいいと思います。

## 目次
1. ABテストとは
2. 改善する場所の特定
3. 仮説を立てる
4. おわりに

## ABテストとは
解説によると、

> A/Bテストとは、ホームページの一部のデザインや ページそのものを複数パターン用意し、それらを不規則に表示させ、どちらがより多くクリックされたか、より多く申し込みがあったかなどを検証する行為のことです。

[A/Bテストとは - Webマーケティング用語｜ferret フェレット](https://ferret-plus.com/888)

つまり、デザインの一部だけを変えて、各サービスが定めたコンバージョン率の変化をテストする手法です。

[ABテストとは — 今さら聞けないABテストの基礎中の基礎まとめ | 株式会社アッション](https://www.assion.co.jp/blog/guide-of-abtesting/)

詳しくは上の記事をご参考ください。

## 改善する場所の特定
ABテストについて、理解した上でじゃあ、どこをどういう風に改善していくのか、という疑問が残ります。

#### インパクトが大きい
- アクセス数が大きい
- コンバージョンに近い

ABテストのセオリーとして、コンバージョンに近い場所から改善するということをします。
例えば、フォームでの登録であれば「フォーム入力の送信ボタンを押す」人の数を増やす。ということです。

また、アクセス数が少ないと、検証する時間がかかってしまうのとそもそもそのテストの評価が怪しくなるので、これらは気を付けましょう。

では、それを前提でエンジニアが気にしなければいけないのかというと、

#### 開発工数がすくなくて済む
- 1日以内
- 他の機能との影響が少ない

当たり前ですが、テストをする為に工数が3日もかかるようでは、数をこなせませんので、優先度を付ける際にその施策の優先度は低くなるはずです。

意外と知られていないかもしれませんが、いくらデータに基いて施策を考えても、思ってもないような変更が当たったりするようなものです。だからこそ、自分が自社サービスのユーザーだと考えて気になる箇所は細かくても、テストしてみましょう。

## 仮説を立てる
まず、自分が自社のサービス利用者だとして、気になるポイントがいくつか出てくるかと思います。

例えば、

「このボタンって見えてないのかもしれない…」
「もしかして、この文章って迷っている…」

など、とにかくユーザー視点になって考えることです。

この仮説を立てるということが結構重要で、施策を依頼されて実装だけ行なうエンジニアの場合、
仮説を立てずに、変更を行っても失敗しても、成功してもなぜ、これが当たったのかということが分からず、納得を持って実装をできないということが起こってきます。

自分がABテストの施策出し等に携われないにしても、なぜ、この施策を行なうのか、考えた人の仮説をしっかりと聞いておきましょう。

この仮説に対して、

このボタンって見えてないのかもしれない…

- ボタンを大きくしよう
- 色を変えよう

などの施策を出してそれぞれをテストするという流れになります。
再度になりますが、できるだけ仮説が根拠に基づくものであれば、尚いいのですが、ABテストの正解を知っている人はいないので、思ってもいないような施策が当たることがあるので、サービスを作っているあなただから分かるようなことでもバンバンやってみましょう。

## 利用するツールなど
ABテストを行なうにあたって、さまざまなツールを使うことによってエンジニアの工数を減らすこともできます。

#### 信頼度チェック
[Adobe Target Sample Size Calculator](https://docs.adobe.com/content/target-microsite/testcalculator.html)

ABテストを行なうにあたって、気になるのは優位性をどのように図るのかということです。
例えば、カイ二乗検定などの手法を用いて優位性を担保してもらうこともできます。

Adobeが提供しているツールを利用すれば、もっと簡単に行うことができます。

#### ABテストツール

これらのツールを使えば、自社のサイトにjavascriptのタグを仕込むことによって、GUIでテストケースを登録するだけで簡単に振り分けることができます。

実際にエンジニアが実装しなくてもテストを行なうことができます。

- [【VWOプレミアムパートナー】世界4500社導入ヒートマップ付A/Bテストツール (VWO) | Visual Website Optimizer](https://www.assion.co.jp/lp/05/)

- [Optimizely正規代理店ギャプライズ｜No.1ABテストツール](https://optimizely.gaprise.jp/)

ただし、これらは有料なのでお金がかかります。

しかし、GoogleからABテストツールをリリースしたのです。しかも無料で使えます。

- [Website, AB Testing & Personalization Solutions - Google Optimize](https://www.google.com/analytics/optimize/)

確かに、上の二つのツールに比べれば劣るところもありますが、これで十分なサービスであればこちらを利用するのもいいでしょう。

#### 計測ツール
結局のところ、いくら施策を行っても、数値が見えていないことには始まりません。

計測ツールとしては、サービスやプロジェクトによりけりですが、おそらくどのサービスにも導入されているGoogleアナリティクスを使うのは一番利用しやすいのではないでしょうか。

もし、[BigQuery - アナリティクス データ ウェアハウス  |  Google Cloud](https://cloud.google.com/bigquery/?hl=ja)を使ってログを蓄積しているのであれば、redashや、metabaseを使って可視化するのもいいでしょう。

とにかく、なにかしらのツールを導入して、プロジェクトの全員が数値を見れる状態にしておくことが重要です。
また、それを放置していても勝手にレポートを吐き出してくれるようにしておくことができれば、よりエンジニアの工数を減らすことができます。

## おわりに
今回の記事では、エンジニアがABテストを行う際に気をつけてほしいことに関してまとめました。

全体を通して言いたいことは、なるべくエンジニアが実装しなくてもいいように仕組み化ができると、その分を施策出しや、考える時間に使うことができるということです。

自分たちで作っているサービスは自分たちで良くしていこうという気持ちを持って改善していきましょう。