以前の連載では、チャットアプリケーションの開発および機能改善を例として、Kii Cloudの持つBaaSの機能（データ/ユーザ管理、データ分析）について解説しました。

その際に公開予定として紹介していたA/BテストをKii Cloudで正式にサポートしたため、2回に渡り解説していきます。前編となる今回は、「⁠A/Bテストとはそもそも何か」「⁠A/Bテストのポイントは何か」について触れます。

A/Bテストとは

モバイルアプリケーションを開発していると、「⁠せっかく新しい機能を追加したのに誰も使ってくれない」などの問題は、多くの開発者が経験していると思います。これらの問題は、「⁠機能を使うためのボタンが見えにくい」「⁠使い方が直感的にわかりにくい」など、利用者のユーザインターフェースに対する不満から発生している場合も少なくありません。

しかし、ユーザインターフェースのどこが原因なのかは事前にわかることはほとんどありません（そもそもユーザインターフェースが原因である、と確信できることも稀でしょう⁠）⁠。かといって、原因を探るために頻繁にユーザインターフェースを変更していては、それにユーザが嫌気を覚えアプリケーションを使わなくなってしまう、ということになりかねません。

こんなときに、一部のユーザにインターフェースを改善したテスト版のアプリを使ってもらって、これで本当に問題が解決するか試せるならばどうでしょうか? その改善により問題が解決されていれば、次回のバージョンアップで正式版としてリリースすればいいでしょう。効果がなかった場合は、テスト版に入れた修正は正式には取り入れないこととして、また改善案を考え直せば住みます。このようなプロセスを簡単にできるようにしたのがA/Bテストです。

A/Bテストは、「⁠ある2つのパターン（パターンA/パターンB）のどちらかをあらかじめ決めた確率でユーザに適用し、それによるユーザの挙動の変化を解析して選択するパターンを決定する」ものです。主にユーザインターフェース改善を目的として用います。A/Bテストは、たとえば次の内容を決定する際に用いられます。

• ボタンの色（例：購入ボタンを「赤」にするか、「⁠青」にするか）
• 見出しの内容（例：「1,000円引き」にするか、「⁠10％OFF」にするか）

ボタンの位置を例として、具体的な手順を示すと以下のようになります。

1. 開発者はボタンの色について、2つのパターンを定義する。ここでは、パターンAを「青⁠」⁠、パターンBを「赤」としたとする。
2. 各パターンをどれくらいの確率でユーザに適用するかを決定する。パターンAを「60％⁠」⁠、パターンBを「40％」としたとすると、あるユーザのアプリケーション内では60％の確率で「青」のボタンが、40％の確率で「赤」のボタンが表示される。
3. しばらくの期間、ユーザの挙動(ex. 該当ボタンのクリック数)を取得して、そのデータを分析する。
4. 分析の結果、A、Bどちらのパターンを選択するかを決定する。以降、ユーザには選択したパターンのみ適用される。パターンBを選択したとすると、選択後は全ユーザのアプリケーション内では100％の確率で「赤」のボタンが表示される。

A/Bテストを実現するためには、「⁠パターンごとのユーザデータ（＝ユーザの挙動）の収集」と「収集したデータの分析」が必要になります。第10回で解説しましたが、Kii Cloudはアプリケーション内のデータを分析する機能をサポートしており、上記2つの要件を満たしています。そのため、開発者は自分のアプリケーションで容易にA/Bテストを実施できます。また、開発者ポータルからA/Bテストの設定や結果の確認、最終的に選択するパターンの決定などを行えます。

A/Bテストで気をつけること

前述したとおり、A/Bテストがユーザインターフェースの改善を進める上で大きな助けになるでしょう。ただし、ただやみくもにA/Bテストを実施して良い結果には繋がるものではありません。A/Bテストを実施する上で開発者が常に意識しておかなければならないのは、「⁠自分はなぜA/Bテストを行うのか」=「何を目的としてユーザインターフェースを改善しようとしているのか」です。

A/Bテストをある一定期間実施した後に、パターンA/パターンBのどちらを採用するかを決定する必要があります。その際の判断基準を一般化すると以下のようになります。

（試行の内、目的を達成した回数）÷（全試行回数）

重要なのは、「⁠目的を達成するためにどのような改善方法(パターン)があるか」を考えるのは開発者の責務であり、「⁠何をもって試行したとするか/何をもって目的を達成したとするか」を決めるのもまた開発者の責務である、ということです。それは目的とするものにより、いかようにも変わりえます。Kii CloudはA/Bテストを容易に実行する環境を提供しますが、上記の責務を肩代りすることはできません。

チャットアプリケーションを例として考えてみます。チャットアプリケーションを開発したある開発者は次のように考えました。

• チャットアプリケーションに新機能としてスタンプ機能を追加した
• リリースして1ヵ月経ったが、スタンプの利用頻度が思っていたほど増えない（Kii Cloudのデータ解析機能を利用することにより確認）
• 今はあまり使われていないけれど使ってもらえれば、ユーザはもっとチャットを楽しんでくれるだろう
• どうすればユーザがこの新機能を使ってくれるだろうか。そもそもなぜあまり使われていないのだろうか

この例の場合、「⁠ユーザにもっとチャットを楽しんでもらう（＝ユーザエクスペリエンスの向上）ため、新機能（スタンプ機能）をもっと知って（使って）もらう」ことが目的となります。

その目的を達成するためにどうしたらよいか、開発者は次のような仮説を立てました。

• スタンプ機能を使うためにはまずスタンプ一覧を表示するボタンをクリックしなければならない。しかし現在の実装ではボタンが地味なため、ユーザは機能の存在に気付いてないのではないか
• 一覧表示ボタンをもっと目立つようにすることで、目的が達成できるのではないか

自分が立てた仮説が妥当であるか、ひいてはそれにより目的が達成できるかを確認するため、開発者はA/Bテストを実施することにしました。ボタンに⁠”スタンプ⁠”という文字が表示されている現実装と、ボタンにスタンプの画像を表示した改善実装を、A/Bテストのパターンとします。

ではどのようにすれば、パターンの良し悪しを判断できるでしょうか。もし、スタンプ機能を使うためには必ず一覧表示ボタンを押さなければならない作りになっているとすれば、シンプルに一覧表示ボタンのクリック率を評価尺度に使えそうです。

このようにしてA/Bテストを実行した結果、パターンBのクリック率がパターンAのそれに比べて向上したとすれば、パターンBを選択するという結論が出るでしょう。もし、パターンAとパターンBの間に顕著な差が見られなくても、特に悲嘆することはありません。開発者は、自分がたてた仮説があまり有効なものではなかったと判断して、次の仮説をたてることができるでしょう。つまり、A/Bテストは「実行すれば必ず効果が出るものではなく、自分の改善案を実施・分析してフィードバックループを素早く回すための手段」である、といえます。

まとめ

今回は、A/Bテストを実際に実施する前準備として、A/Bテストがそもそもどういったものであるか、について解説しました。簡単な概要ですが、A/Bテストを実施する意義がわかっていただければ幸いです。

次回は、前回の連載で開発したアプリケーションの改善シナリオを提示し、Kii CloudでA/Bテストを利用するための手順を解説していきます。