こんにちは、ディレクターのcultivaです！
はじめに
この記事は連載物です。以前の記事についてはこちら。 tech.speee.jp
この記事では、
『私達が高速A/Bテストをどんな考え方で行ったのか』
『私達が実際にどんなA/Bテストの施策を行ったのか』
を書きたいと思います。
そもそもなんでA/Bテストを始めることにしたのか
私達のチームではそもそもA/Bテストをやっていませんでした・・・
当時は施策を投入し、全体指標を見て「たぶん良い感じ」とか
「効果が出るまでしばらくモニタリング」などの会話をしていました。
その時はPDCAを回しているつもりだったのですが、
今から考えてみると改善効果を理解できておらず、
本当の意味でのPDCAには全くなっていなかったと思います。
その結果、
最初のうちは調子よく成長していたサービスの成長速度にちょっとずつ陰りを感じるようになりました。
このままではいけないと思い、
A/Bテストを取り入れて本当の意味でのPDCAを行う改善フローを学習しつつ、
サービスにとって本質的な指標の改善を行うことにしました。
とはいえ、そもそもやったことがなかった取り組みなので、初歩の初歩から始めることにしました。
よって、A/Bテストドリブンな進め方、の第一歩は「まずA/Bテストすること」からでした。
実際にやってみて、改めてA/Bテストをオススメする4つの理由
A/Bテストドリブンでやってみたことのメリットを振り返ってみました。
想定通りだったことと体験して今振り返ってみてわかったことがあります。
1.結果がはっきりわかるため、迷わず前に進める。
（当たり前ですが）オリジナルとその施策の比較が明確に出るので、迷うことなく判断できます。
逆にやらないと、本当によかったのか判断できません。（外的要因をすべて考慮することは困難です）
2.テストすることで、判断スピードが上がり、結果プロダクト改善サイクルが高速になる
同条件で外的要因を排除した状態での比較になるので、結果分析が不要になります。
解釈も人によってぶれないので、報告時にもぶれません。
逆にやらないと、速いようで結果的に分析に時間がかかり、もやっとした結論になります。
3.あくまでテストと割り切れることで、開発スピードも上がる
A/Bテスト時に改善がされなくても切り戻せばよいです。
ちなみに、これが本番リリースだとそうはいきません。
さらに今では「あるテーマを評価するための最小限のA/Bテスト実装」を意図的に行って、
テスト工数を最小限にとどめるようにしていて、良い結果が出たらきちんと実装する、というステップを踏むこともあります。
4.一つ一つテストすることで「何をするとユーザーがどう動く」が明確にわかり、経験となり、次につながる
一つ一つ分けてテストをすることで、どんなことをするとユーザーがどう動くのははっきりわかり、ユーザー行動の理解が深まります。 その結果、では次どうするか、につながって、案件の精度が上がる、かつ案件が連想ゲーム的にすぐ出てくるようになります。 複数混ぜて行うと、何をするとユーザーがどう動くのかがわからず、次以降に何もつながりません。
A/Bテストの進め方
A/Bテストは下記のような感じで進めていきました。
1.3打数1安打ではなく、300打数30安打
それぞれを改善率ベースで
3打数1安打 →3割3分3厘
300打数30安打→1割
と考えるのではなく、改善数ベースで
3打数1安打 →1回改善
300打数30安打→30回改善
と考えて、『改善数』を積み重ねることを目指しました。
更にいうと、想定通りにいかなかったことも、きちんと振り返れば、
『こんな風に見せるとユーザーはこんな反応を見せる』という学びになるので、
実際には、
300打数30安打→30回改善+270学習
こんな感じの考え方で進めました。
※ちなみに、『最低限の改善率』の目安としては『改善率は20%でOK』という感じにしました。
2.速度！速度！速度！
上述の通りで改善数を重要視することにしましたので、
とにかく速く施策を試して、小さくとも改善数を積み重ねることにしました。
あと、私達にとってが『高速A/Bテストドリブンな改善フロー』が初めての挑戦だったので、
その意味でも、とにかくこのフロー自体に慣れるために、施策を積み重ねることに注力しました。
3.仮説と考察を施策毎にきちんと書くようにした
『成功した施策からも失敗した施策からも何かを学び取る』ために、
仮説立てと考察については毎回書くことにこだわりました。
考察については
改善した施策は『仮説があたったとして、更にどんな内容をで改善していくべきか』
改善しなかった施策からは、『そこからの学び』や『新しい仮説を立てること』
を書くことにしました。
正直にいって、仮説立てや考察自体の精度も低い状態のスタートになりましたが、
それらを改善フローを回していく中で改善をしていくことにしました。
4.1つずつ検証するようにした
複数同時に検証してしまうことで『結局何がよかったのか、悪かったのか、よくわからない』という状態になることを防ぐことを考えました。 そこで同時に複数箇所を改善するのではなく、1つずつ地道に改善を重ねるようにしました。
改善した施策(ほんの一部を抜粋)
1.求人情報の表示レイアウトの改善
仮説
仕事探す時、ユーザーが一番気になるのは企業名と地域名なのではないか。
検証結果
考察
やはり、仮説通りに企業名と地域名はユーザーにとって重要な情報。
なので、この2つの情報はユーザーから見てわかりやすい箇所に配置するべき。
他ページでも同様に試してみるべき。
2.募集要項をなくす
仮説
募集要項はユーザーにとって重要度が低いのではないか
＋
求人一覧が縦長に冗長化傾向であるので、コンパクトに収めたい
検証結果
考察
求人一覧ページを見る段階（求人同士を比較する段階）では、
求人の募集要項の重要度はやっぱり低そう。
+
募集要項を消したことに伴って求人一覧ページの一覧性が上がるので、
求人一覧ページ内でユーザーが興味のある求人が見つかる確立が上がったとも考えられそう。
次回予告
ここまでは
第1回：『成果』
第2回：『考え方』『施策』
について書きました。
次回以降の記事では
『高速A/Bテストドリブンな改善フローをどうやって実現したのか』
について、エンジニア・ディレクターそれぞれがどんな取り組みを行ったのかを書きます。
