- はじめに
- この記事で得られること
- ABテスト導入前
- この章でのポイント
- 仮説から検証までのプロセス導入と大量の見立て
- 定性的な観点での優先度づけ
- 定量的な分析による優先度づけ
- この章でのポイント
- ABテストツール導入
- この章でのポイント
- 数値と想定(主観)との乖離の連続
- この章でのポイント
- 改善できる指標は何か
- この章のポイント
- チームでプロセスを高速改善
- この章のポイント
- 最後に
はじめに
まず結果としては約半年でKPIが130%成長を達成しました！
※画像は約半年間のKPI推移のグラフ
この記事では、4月からABテストによる検証環境を持たないチームにABテストを導入し、数値改善した流れを書き記してます。
まずは、チームが改善している指標の説明をします。
チームが改善している指標は「求人クリック数/流入数」であり、プロダクト全体では「求人クリック数」をKGIとして改善しています。
KPIツリーではこのような構造になっています。
チームで改善しているのは図の赤枠内の指標になります。
また本記事の「ABテスト」とは、以下の内容で記載しております。
A/Bテストとは、異なる2パターンのWebページを用意し、実際にユーザーに利用させて効果を比較するテストのこと。
この記事で得られること
この記事で得られることは、主に3つあります。
ABテスト運用についての概要・気をつけるポイント
目的に沿った改善の方法
仮説〜検証までのプロセス事例
主にはこの3つを踏まえつつ、これまでの約半年でどのような取り組みを行ったか、時系列を交えてお伝えします。
ABテスト導入前
ABテスト導入前はとにかく、競合他社のサイトを見て差分を洗い出し、施策にしようとしていました。ここではおおよそ200程度の案が出ていたと記憶しています。
ただ、ここから2つの問題に直面します。
1つ目：「どれから実施していくべきか？が分からない」
プロダクトに施策を反映していくのはタダではありません。そこには企画、要件定義やエンジニアによる開発が存在します。
限られたリソースの中で、最大の結果を出したい。となったときに何から取り組めばいいか分からない状態でした。
2つ目：「施策をどう評価していいか分からない、続けるべきか判断できない」
プロダクトに施策を反映しても、本当にKGIに寄与しているのか？続けていいのか？が評価・判断できない状態でした。
GoogleAnalyticsなどの分析ツールを使っていましたが、果たしてKGIの向上の要因となっているのか、阻害しているのかの、定量的な評価と判断ができない状態でした。
この2つの問題を解消し、再現性を持ってKGI・KPIを伸ばしていく取り組みの模索が今年の4月からはじまりました。
この章でのポイント
KPIを改善するにあたって、
施策の優先度が見えない
評価と判断を定量的にできない
という状態だった。
仮説から検証までのプロセス導入と大量の見立て
まず1つ目の問題である「施策の優先度が見えない」という問題の解消についてです。
優先度が見えない、つけづらい要因として、
施策が与えるKPIの改善が定量的に想定できていない
施策にかかるリソースが分からない
といった課題が存在しました。
また、検討するべき施策がおおよそ200程度存在していたこともあり、定性的な観点での優先度と定量的な分析による優先度づけが必要だと考えました。
定性的な観点での優先度づけ
定量的なシュミレーションを案件ごとに実施したいですが、かなりのリソースが必要だとわかりました。
具体的にはひとつの案件あたり、2〜3時間は時間を要さないとシュミレーションできませんでした。
そこで、まずは200ある施策案のうち、どこからシュミレーションするべきか？を考えるために、以下のようなKPIを更に分解した構図を作成し、施策案がどこに該当するのかの整理からはじめました。
※またこのタイミングで200ある案も一部、取捨選択しています。
※便宜上、求人クリック数をCVn、求人クリックした流入をCVss、流入をSSと記載しています。
施策の分類後、競合他社の調査を元に「どのKPIが最も乖離しているか」を分析し、優先度づけました。
これにより優先度の高いKPIの施策から検証していく。という方向性が決まり、施策ごとのシュミレーションに取り掛かれます。
定量的な分析による優先度づけ
次に定量的なシュミレーションを施策ごとに行います。施策の単位は「ボタンのデザインを変える」といったものをイメージしてください。
ひとつの施策をリリースし検証するまでに、以下のようなプロセスを作成し優先度を判断しながら進めめました。
「見立て」「仕立て」は以下のように定義しています。
見立て：効率の良い案件を生み出すためのプロセス
仕立て：見立てを「仮説検証」をするためのプロセス
プロセスをスピード感持って実施するため、テンプレートを事前に用意し進捗の可視化と振り返りの利便性を上げました。
これによって過去案件の参照や他部門への共有も行いやすくなります。
※画像は見立て・仕立て時に使用するドキュメントのテンプレート
この章でのポイント
競合分析とKPI優先度づけで、方針と大量の施策優先度を決めた
大量の施策を検証するために、テンプレート化やプロセスごとのチェック体制をつくった
ABテストツール導入
次に問題の2つ目にあたる「評価と判断を定量的にできない」状態の解消を取り組みました。
一言で言ってしまえば、ABテストを実施できるツールを導入したという結果ですが、導入にあたっていくつか検討しました。
細かい数値部分については、取り組んでいるKPIや、どれだけの精度を求められるかといった事情もあり、一概に何が最も正しいか言及できないので割愛します。
まず導入にあたって「テスト結果によって、変更をするべき。施策を採用するべき」という基準を設けました。
合わせて、検証するときに見ておくべき指標やテスト実施での運用を以下のように定めました。
同時並行実施の基準
- スピードを最優先。結果に影響が出ないと判断できるところまでで並行実施
検証期間
- 期限を設ける。シュミレーション時に検証期間も計算しておく。検証期間が長くかかるケースはリターン自体も少ないと判断
モニタリング観点の明確化
- KGI・KPIは必ずモニタリング & 中間指標もウォッチする
成功基準
- KPIの結果で判断する。KPIが変動しない結果では中間指標で判断
有意差ありの基準
- 一般的な水準で実施
大まかな検討・ルール化した項目が上記になります。
実際にABテストを運用しKPIを大きく改善している有識者に入ってもらい、議論を重ねた上で細かい数値や基準を制定しました。
基準を設けた上で、いよいよABテストツールを使った検討をはじめました。
【余談】ツールは何がいいの？といった点がありますが、
精度が担保できる
作業がしやすい
検証結果の分析が行いやすい
といった点を踏まえて、複数ツールを検討(できるならば一度運用してみる)することが好ましいと後になって気づき、ツールの再検討を現在実施しています。
この章でのポイント
施策の結果について評価・判断を定量的に行えるよう、ルールを決めた上で運用を開始した
数値と想定(主観)との乖離の連続
ABテストを開始してみると、「いける！かなり改善するはず！」と思っていた施策がことごとくオリジナルに負けたり、また、「そこまで上がらないだろう」と思っていた施策が大きな改善になる。といった事象が発生しました。
分析を進めることでわかったのが、要因としてKGIが「求人クリック」であることが大きいのでは。という結論に至ってます。
プロダクトの種類やフェーズによって理由は様々ですが、一般的に求人は応募というマッチングを生み出すために作られると考えます。
ただし、僕らのプロダクトとフェーズでは「求人クリック」を最大化しようという設計なので、自分たちがプロダクトを触って感じるユーザー目線での目論見が外れるといったことが多々起きました。
そこでテーマ別に結果を集計したり、検証の数を増やしていくことで改善する施策の共通項や傾向を見出して、案件創出にフィードバックしていきました。
※画像は傾向を掴むためのテーマまとめの一例
この章でのポイント
定性的に分析・想定していた有効であろう施策も、定量的に検証すると目論見と大きく外れることが多々発生した
改善できる指標は何か
傾向がつかめてくると、次は限られた期間でより多くの成果・改善を求めていきます。
改善できる指標を探すために、ABテストの活動を定量化しました。
※ここでの「成功」はABテストの結果、オリジナルよりKPIが良くなった場合を指す
まずは自分たちの行動でコントロールできる指標が何かから見ていきました。
成功率や案件あたりの改善数値はABテストしてみないと分からないので、「検証案件数」が自分たちでコントロールできると考えました。
検証案件数を分解すると、このような組み合わせで計算できることがわかります。
ページあたりの検証案件数が、自分たちの行動で最大化できる部分だと考え、先に記載した見立て→仕立てのプロセスをどれだけ多く、より速く実施できるか？を各工程ごとに検討しました。
結果としてABテストを本格的に実施する前に計画していた1週間あたりの案件数より、現在は約3倍ほどの施策を実施できる状態になりました。
いま振り返ってみて、「定量的に測れる指標を設けたこと」と「立場・役割関係なく、課題を可視化し解決にチャレンジできたこと」が良かったです。
定量的な指標を設けたことで、誰もが課題を特定できるようになり、また「誰が言ったか」ではなく、「何を言ったか」といった観点で客観的に議論・検討できる流れができました。
また、施策数が増えてくることにより、これまでABテストをしないと分からなかった成功率と相関性のある指標も見えてきました。
具体的には1本のABテストで要するパターンの数と、成功率の相関性を発見でき要件作成時にパターンの最低推奨数を組み込んだことで成功率UPに繋がりました。
(※パターン数は、ABテストなら1パターン。ABCテストなら2パターンといった数値)
まとめると、自分たちがコントロールできる数値を最大化した結果、更に行動ベースで改善できる指標が出てきたといった副次的な効果も得られました。
※図は多くの施策を実施したことで発見した指標の一例
このように指標の分解、分析からプロセス内でのルール化などを行い、KPIの最大化が徐々に上手く回り始めて、かつ再現性を持って実施できるようになりました。
そして、更に改善するスピード・確度を高めた要素としてゲーム感覚を持てたことも大きかったと考えます。
例えばですが、リリースした案件が採用される率を「打率」や、KPIに対して大きく改善した案件を「ホームラン」「ツーベースヒット」などと社内のユビキタス言語のような表現を設けました。
結果、自分たちの成果がゲーム感覚で実感できるようになったため、共有しやすく、「次もホームランを目指そう」といった具合に、小さな目標や成果を掲げやすいことも大きかったと感じます。
この章のポイント
再現性を持ってKPIを改善するために、以下の取り組みが効果的だった。
定量的に示せる指標を見つける
指標を分解して自分たちでコントロールできるところを見つける
社内言語を用いて、ゲーム感覚で数値の改善に取り組む
チームでプロセスを高速改善
ここまで記載したことは誰かひとりによって推し進められた訳ではなく、前章で記載した指標の可視化・分解 → 課題の洗い出し → 課題の解決が、チームとしてかなりの速度で進んだことが要因でした。
振り返ってみれば、以下のような要素が良かったと考えています。
1週間で区切って振り返り・軌道修正をしたので、プロセスの高速改善が可能だった
Miroで議論した（発言だとどうしても偏りがでるが、付箋だと意見を述べやすい、全員参加しやすい）
定量的な指標を毎週全員で振り返り・確認し、共通の目標が明示化され、自分ごととして議論できるようになった
短いスパンでの分析と、全員が当事者意識を持ったアウトプットにより、結果としてチーム単位でのプロセスの高速改善に繋がりました。
またチーム結成当初に比べて、時間を経るごとに、出てくる課題の種類がよりプロセス改善の内容になっていく様子からも、チームの成熟が進んでいることも感じました。
結果として、課題に即時対応・軌道修正ができる体制とプロセスを手に入れることができ、さらに、1ヶ月先までの取り組みと得られるであろう成果の予測が立てられるまでになりました。
この章のポイント
プロセスの高速改善には、短いスパンでの振り返りが有効
Miroを使うことで偏りの無い発言と議論が実現
共通の目標を明示化することが、チーム全員の自分ごと化の手助けに
最後に
振り返ってみれば、約半年でKPIを130%以上成長させることができました！
恐らくこの半年間は怒涛の日々だったとチーム全員が感じているのではないでしょうか。
最初に決めた多くのことは、今となってみればほとんどが変わった・新たにルール化された項目ばかりです。
これまでを書き出してみても、一人でできることは限られており、目的や共通課題をチーム全員ですり合わせたからこそ、多くのアイディアや実行が果たせました。
また、最初に出した施策は200ありましたが、多くが実施されず、代わりにABテストを重ねる上で更に多くの施策案が生まれました。
そして、実際にABテストができた施策数も200を超えるところまできています。1週間で多い週では6本ABテストを実施しています。
"早く行きたければ一人で行け、遠くへ行きたければみんなで行け" （If you want to go fast, go alone. If you want to go far, go together.）
ということわざがありますが、まさにその通りだと痛感する半年でした。
まだまだ多くの改善や取り組みが必要なフェーズですが、この半年で学んだことを更にブラッシュアップして、プロダクトとしてより遠くにいけるよう引き続き頑張ります。
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。
