数打ちゃ当たるは的外れ。成果を生み出す「ユーザー中心設計」のABテスト

デジタルトランスフォーメーション（DX）事業本部でPMをしています、九島です。

新卒でSpeeeに入社してから、約5年間グロースに取り組んでいて、中でもLPのABテストを継続してやってきました。この記事では、ABテスト初心者の方に向けて、自分の失敗や試行錯誤の過程をお伝えしながら、今一番上手くいっている「ABテストの型」を紹介します。

「サイトのABテストを任されたけど、どう考えたらいいの？」「ちょっとやってみたけど、もっと成果出すにはどうしたらいい？」とお考えのEFO担当者の方にとって、一助になれば幸いです。

ABテストとは？
1年目：200施策やってCVR上がらない
2~3年目：ユーザーニーズを掴むことが糸口に
4~5年目：行き着いたのは「ユーザー中心設計」のABテスト
まとめ

ABテストとは？

web業界にいる方なら、「ABテスト」という言葉は一度は聞いたことがあるのではないでしょうか。

ABテストとは、

A、Bのパターンを用意して結果を比較するテストのやり方
どちらがよいか？　という結果が明確に出る
様々な要素でA/Bテストを行い、結果のよかったパターンを実装していくことで、最適化していく

といったものです。

メリットは、

同時並行でパターンを試すことができるので、時間による変化を（ほとんど）無視してOK
ツールがたくさんあり、コスト低く、フットワーク軽く実施ができる

があり、一方でデメリットは、

短期では最適でも、長期に目を向けるとずれてしまいがち
検証のために、一定の流入数が必要

が挙げられます。

余談ですが、オバマ大統領が利用したのをきっかけに、ABテストは広まりました。(※参考｜オバマ大統領が簡単なテストで、６０００万ドルもの収益を上げた方法)

1年目：200施策やってCVR上がらない

僕は新卒で入社してすぐ、ABテストのプランナーになりました。

そして10ヶ月間で200施策実行し、ずっとCVRが改善しませんでした。(当時の上司、すみません。)

振り返ると、このような悪い循環にハマり、しばらく抜けられなかったのです。

「施策がなくなってきた」という方は、この循環にハマる兆候かもしれません。

はじめは順調だったが、徐々に施策がなくなっていく
「施策数」を気にして、とりあえず施策を実行してしまう
ABテストで勝っているのに、事業数字が改善しなくなり、焦る
「施策の改善幅」が高い施策をやろうとリソースを確保し実行するも、工数かかるわりに大外れ
やることがなくなる・施策がなくなる

当時、「自分はできる」「頭がいい」と思っていました。自分が考えた施策は当たるはずと思っていたからこそ、一度上手く進まなくなってからは目の前の数字を上げようと必死になり、空回りしていました。

今になって思うと、こちらの記事でWACULの垣内さんがおっしゃるとおり、ABテスト実施の目的が、「成果を上げること」でなく、「成果を証明すること」になってしまっていたようです。「ABテスト」という手段にこだわり過ぎて、ユーザーを置いてきぼりにしていたんだと反省しています。

2~3年目：ユーザーニーズを掴むことが糸口に

2年目の途中から新規事業に抜擢されました。(内心、失敗してたのに僕で良いんだろうか、、とは思いました。）

事業として立ち上げたばかりということもあり、まずはユーザーインサイトを掴むため、リスティングの広告文改善から着手しました。

「3種類の広告文を追加し、結果をみて振り返り、次の広告文を追加する」という地道な活動を毎週行い、最初の3ヶ月でユーザーのコアニーズを見つけ、残り3ヶ月で見つけた軸を深堀りました。

細かな表現の違い（「安い」or「最安値」）でも結果が大きく異なり、この経験をとおして、ユーザーニーズに手触り感を持つことができました。

3年目からは、広告文の改善によって理解したユーザーニーズを元に、LPのABテストを開始しました。

大失敗をしているので不安だったのですが、ユーザーニーズに沿って改善を続けた結果、1年目で苦戦したのが嘘のように上手くいき、CVRが開始時の3倍になりました。

当時の上司に勧められ、この一連を振り返って言語化しました。

それによって自信がつき、更にユーザーを意識した改善施策を実施して、成果を出せるようになりました。

4~5年目：行き着いたのは「ユーザー中心設計」のABテスト

4,5年目は、同時に4領域でABテストを実行しました。

立ち上げ期・成長期・安定期と異なるフェーズのLP、異なる種類のユーザーニーズでしたが、同時に実行することで抽象化した学びとなり、自分の中で上手くいくABテストの型が分かってきました。

僕が見つけた型は、

LPやEF（エントリーフォーム）をプロダクトと見たてて、そのプロダクトを磨く手段としてABテストを実施することです。

具体的には、次の3つになります。

　① ユーザーニーズを定義し、コアの提供価値を決める

　② 「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる

　③ 施策数や施策の成功数ではなく、事業の数値を結果責任として持つ

1つずつ説明できればと思います。

①ユーザーニーズを定義し、コアの提供価値を決める

LPやEFをプロダクトとして見立てるのであれば、必要なのは、「誰の・何の課題を解決するためのページなのか？」を決めることです。 ABテストを実施する前に、これを決めます。それによって、施策や判断に方向性が生まれ、局所最適なABテストを防ぐことにつながります。

例えば、このような質問に答えを持っておく必要があります。

ページに流入したときの期待値
- ユーザーが知りたい/やりたいことは何か？
- それができない（と思っている）構造は何か？
- このページで何ができると思っているか？
- そのクオリティはどんなもんだと思っているか？
流入時の期待を上回るためにできること
- ユーザーが得られるもののクオリティを高められないか？
- ユーザーが得られるものを、想起しやすくできないか？
- ユーザーが得るまでの行為を、なめらかにできないか？

②「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる

施策を作ろうとすると、どんな内容にしようか？ということに視点が及んでしまいがちです。改善しやすいフェーズであればよいのですが、その場合はユーザー理解が生まれづらく、施策が枯渇していきやすくなります。

僕は下記のフォーマットで毎回施策を作っています。

見ていただければわかるとおり、「仮説」のところがかなり肉厚で、しっかり設定できるようにしています。

## 施策について
### ざっくり内容

### 仮説
- 〇〇なので
  - （実数値や他の施策の結果）事実として
  - ↑の事実は、ユーザーの気持ちがこう動いているのだろう
- 〇〇することで
- 〇〇するのではないか
  - ユーザーの気持ちがこうなる
  - 結果、何の指標がどうなる

### リリース指標
- 上がってほしい
- 維持してほしい

### 考察にあたっての指標
- 指標①：◯◯
- 指標②：◯◯