こんにちは、ディレクターのcultivaです！
最初に
この記事は連載です。今回はディレクター編！
以前の記事についてはこちら
【第1回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話
【第2回】高速A/Bテストドリブンな改善フローの考え方と施策
【第3回】高速A/Bテストドリブンな改善フローでわずか5週でCVRを29%上げた話(開発編)
この記事で扱う話
上の記事で書きましたが、
私達のチームは高速A/Bテストドリブンな改善フローを回していくにあたって、
下記のような考え方で進めたことをお伝えしました。
- 速度！速度！速度！
- 3打数1安打ではなく、300打数30安打
- 1つずつ検証するようにした
- 仮説と考察を施策毎にきちんと書くようにした
この記事では上記を受けてディレクター側が、
この取り組みをチームで回していくために
どんな運用や工夫を行ったのかについて話したいと思います。
１、チームの方向性をすりあわせる
高速A/Bテストドリブンな改善フローを回す中で
試したい施策or試すことができる施策は無限にあります。
以前からもチームの個々がサービスを成長させるために
よかれと思って考えた行動できていましたが、
実際には、全体視点では微妙にズレていて、非効率になってしまったところがありました。
そこで、今回の新しい取り組みの中で
素早く、効率よく、検証を進めて改善フローを回していくためには、
チームの方向性を高い精度で一致させていく必要がありました。
そこで、
- サービスをどんな方向性に持って行きたいのか
- 直近ではどのページのどの指標を改善したいのか
- どんな順番で改善を進めていきたいのか
をチームに対して示して、
その方向性に向かって、チーム運営を行いました。
大枠としては、下記のような内容です。
i) サービスの長期ゴール
→■■■の市場でNo1になる
ii) そこから落ちてくるサービスの中期・短期ゴール
→既存のサービスに加えて、新しいサービスでマネタイズしつつ、□□□と△△△を増加させる
→新サービスでのスムーズな立ち上げのためには、
→既存サービスについては○○○程度のポジショニングまでは到達しておくべき
iii) そのために、直近でサービス側で達成するべき目標を示す。
→具体的には月間の訪問数がxxxぐらい、CV数が●●●ぐらい
iv) そのKPIを達成するためには…
→ページAの指標αという指標を△△△から◎◎◎まで改善する必要がある
２、改善注力ポイントに対して施策を出す
『300打数30安打』のような
大量、かつ、ある程度精度があり、
しかもサイトの本質的な価値の向上に結びつく
テストを行うためには
- アイデアの総数を確保する
- アイデアを検証していく優先順を決める
- 実装順をわかりやすくする
を行っていく必要があります。
そのために、私達のチームでは
まず、アイデアの総数を確保するために、
チームメンバーであれば誰でも書き込み可能なスプレッドシートを準備し、
そこにアイデアを書き込んでもらうようにしました。
■アイデア記入シート
次に、集まったアイデアに対しては
ディレクターが
仮説の強度/期待効果/開発工数の観点から
『検証するかしないか』
『どの順番で検証するか』を判断します。
更にそれらを開発順番に並び替えることで、
最終的には
『とにかくリストの上にある施策内容から実装して試す』
という運用にしました。
■施策リスト
3、1つずつ検証する
検証するとなると、一度に多くの内容を検証したくなりますが、
それだと、『結局、何がよかったのか』がわかりづらくなってしまいます。
しかし、1つずつ検証するとなると、
検証回数が増え、それらの管理や共有のコストが高くなります。
そこで下記のような施策が必要になります。
- 何が改善に結びついて、何が改善に結びつかなかったのかを整理する
- 検証している内容に関する数字がわかりやすいところに表示されている
私達のチームでは、
splitを使った管理画面をエンジニアに開発してもらい、
その数字を見ながら検定を行って検証を行いました。
■splitを使った管理画面で数値管理
■検定結果を確認して送客率の差分が統計的に有意な差分かどうかを検定
４、仮説と考察を施策毎に振り返って、チームに共有して、考察を残す
第2回の記事でも触れた
300打数30安打→30回改善+270学習
こちらの考え方を実際にチームで実現していくためには、
- サービスの中長期的なゴール
- そのために今達成するべきこと
- KPIとKPIを達成するためには何を改善していけばよいのか
- なぜそのKPIが重要なのか
という前提となる部分を整理した上で、
実際の運用レベルでは
- 各施策について仮説を立てる
- 結果についてチームに共有する
- チームメンバーの各人から考察を集める
というサイクルをチームで回していく必要があります。
それを行っていくために
私達のチームでは専用チャンネルや週次MTGの場を通じて、
施策結果の共有や議論を行いました。
■Slack上での様子(#専用チャンネルにて)
Slackのチャンネルは速報性と対話性に優れているので、
とにかくいち早く結果を伝えつつ、
そのままチームで考察したり、次の施策を考える上ではよい場だったと思います。
■週次MTG資料
一方、週次MTGではいくつかの施策を横断的に振り返りつつ、
じっくり考察を深めていくための場として活用しました。
この場を設けることで、Slackで瞬発的に盛り上がるだけではなく、
別の角度から施策を振り返ることができたと思います。
チームに起きた変化について。
あと、追加して、今回の高速A/Bテストドリブンな改善フローの前後での
チームの定性面の変化についてまとめておきます。
| 変化前 | 変化後 | |
|---|---|---|
| 改善アイデアを出す人 | ほぼディレクターだけ | チーム全員 |
| アイデアを出す難易度 | 難しい。アイデアは出したいけど、何に対して出せばよいのかわからない | 簡単。どのページのどの指標を改善したいのか明確 |
| チームマインド | これ本当に効果あるの？とにかく調査だ!! | 有力そうな仮説なら、後はとにかく試してみよう！ |
| 検証とそこからの学び | きちんと検証しない→学ばない | きちんと検証する→改善しなかった施策からも学ぶ |
なお、若干、個人的な所感としては、
『チームマインド：これ本当に効果あるの？とにかく調査だ!!→有力そうな仮説なら、後はとにかく試してみよう！』
という部分がけっこう大事、かつ、その後の開発にも大いに活きた変化だったと思っています。
今回の高速A/Bテストドリブンな改善が一段落した後に、
次の開発や検証を行ったりしていっていますが。
その際にも『有力そうな仮説なら、後はとにかく試してみよう！』というスタンスで比較的スムーズに進められていると思います。
そして、前提となる部分である、
『サービスの中長期的なゴール』
『そのために今達成するべきこと』
を最初にチームで共通認識をとれたことが大きいと思います。
正直、上の部分を整理するのは非常に大変だったのですが、
これらを整理しておかないと後で崩れていたかもしれないので、やっておいてよかったと感じました。
最後に
高速A/Bテストドリブンな改善フロー、というと
『xxを変えたらCTRが◯◯％向上』ですとか、
『△△を変えたらCVRが■■％向上』のような各論的な施策の話になりがちです。
そこで、今回の一連の連載では、
もうすこし上段から
『チームとして継続的に数値を改善していくためには、
どのようなスタンス・マインド・仕組みを行っていくべきか』
を中心に紹介をさせていただきました。
今回の連載を読んでいただいて、
読者の皆様の各チームが『高速A/Bテストドリブンな改善フロー』を実践していく際には
各論的な施策レベルではなく、
『スタンス・マインド・仕組み』の部分を是非各チームに取り入れていただければと思います。
連載は以上となります！ここまでお読みいただき、ありがとうございました。
