A/Bテストの成果を向上させる「標準化」の打ち手 ― 社内ワークショップ開催レポート

A/Bテストの標準化が成果創出のカギ

そもそもなぜ「標準化」に焦点をあてたのでしょうか。

それは「標準化」が、A/Bテストを通した意思決定プロセスを効率的に、かつサイエンス視点で信頼できる結果にもとづいて実行するために重要なステップであるためです。「標準化」されていない状態、すなわち指標の選び方や分析のやり方が組織内でバラバラな状態では、設計や分析の工数が嵩むだけでなく、統計的に誤った判断を下してしまうリスクも高くなります。ひいてはA/Bテスト自体のコストがかかるばかりで改善がすすまない、という本末転倒な事態にもなりかねません。

「標準化」はそうしたリスクを回避し、組織として効率よく成果を上げていくための土台作りと言えるでしょう。特に「標準化」がその価値を発揮するのは、A/Bテストの実行回数が増え、A/Bテストを通した施策判断・改善が普及してきた組織においてです。データドリブンな土壌が耕されたタイミングだからこそ、ビジネス視点でもサイエンス視点でもよりよいA/Bテストのありかたを根付かせていく必要があります。

標準化を阻む課題とその打ち手

ワークショップでは、A/Bテストの現場で生じている課題をかき集め、分類していく作業を行いました。課題を洗い出すにあたっては以下の2種類のフレームワークを用いています。

ひとつはいわゆる「PDCA」型の分類です。施策のプロセスに沿って考えることで、実務の場面に照らし合わせた具体的な課題を見つけやすい分け方です。ふたつ目は課題の背景による分類として「組織・文化」「スキル・リテラシー」「ツール・データ」の3つの軸で考え、どの程度コントローラブルか、課題を解消するためにどういったアプローチが有効か見極めるためにも役立ちます。

ワークでは課題を洗い出したのち、その背景を考察、課題を解消するための打ち手を整理していきました。この記事では課題と打ち手の中でも特に意見の多かった「組織・文化」に関する課題と打ち手をピックアップしてお伝えいたします。施策のPDCAサイクルに始まりKPIマネジメント等ビジネス側の上流工程に携わる中で見えてきたものと言えるでしょう。

分析チームと施策チームのディスコミュニケーション

分析を担うチームと、施策立案・実行を担うチーム（PdMやマーケティング部署を想定）の連携に課題があるケースです。例えば以下のような状況があてはまります。

• 分析チームが提出する結果がわかりにくい・ほしい情報がアウトプットされない
• 施策チームに分析結果を伝えるが施策の意思決定に反映されない、信頼されていない気がする

短期的に見れば「施策をリリースしたい」施策チームと「正しい分析をしたい」分析チームでは追いかけているものが異なるため、こうしたディスコミュニケーションは起こりうることと思われます。しかし、それぞれの背景にある「効果がある施策をリリースし、売上を向上させたい・サービスを成長させたい」という思いは共通のはずです。

ひとつの打ち手として挙げられたのが、分析チームがA/Bテストの重要性を施策チームに伝える機会を設けるというものです。定例や施策に関する打合せとは別に、ふたつのチームに共通の目的は何なのか、そのために分析チームとして何ができるのかといった整理を行い、A/Bテストの価値を再定義します。ブレインパッドとしても、こういった話し合いを通じてより施策チームへの報告クオリティを高めたり、分析業務が円滑になった事例が複数存在しています。

このとき重要なのは、分析チームが分析の精度や統計手法を主語とするのではなく、施策チームのミッションに沿った伝え方をすることでしょう。A/Bテストによる判断を誤った場合にどのくらいの損失が生じ、テストによってどのくらい回避できるのかといった要素を試算し、お互いの文脈を合わせることでコミュニケーションが一歩前進します。

分析チームと施策チーム・意思決定者との目線合わせといった要素は過去の記事でも解説されております。ぜひ併せてご覧ください。

【参考】
組織の意思決定に効く！効果検証のコツと実践

技術習得が難しい・コストがかかる

A/Bテストを実行する際には以下のような問いに答えねばなりません。

• ゴールメトリクス・ガードレールメトリクスは何が適切か
• サンプルとして何人のユーザが必要で、割り当てのトリガーをどこに置くか
• 施策の採用有無はどのように判断するか

これにはビジネスとデータサイエンスを横断した理解が求められ、施策・分析両チームのスキルが必要です。しかし、プロセス全体を通して関わる人数を増やせば両者の工数を圧迫するだけでなく、施策のリリースに時間を要し、結果的に生産性を低下させてしまいかねません。

対する打ち手として、A/Bテストの各プロセスを型化・テンプレート化し、工程の標準化・効率化を図る取り組みが有効となります。例えばA/Bテスト設計の手順書・穴埋めテンプレートを作成したり、分析プログラムを型化することで観点の抜け漏れやロジックのミスが減り、標準化に大きく貢献します。

テンプレート化に際しては、全体をリードする役割を設けることが重要です。施策・分析だけでなくエンジニアやデザイナーも含めたプロセスを描くため、組織間を横断して合意形成を行う必要があるでしょう。

またワークショップでは、施策結果のナレッジをどのように蓄積・活用していくかも話題となりました。この点については、決まった形式（テンプレート）を作成して効率化する案や、生成AIを活用してナレッジを収集する案が出されました。

とりあえずA/Bテスト vs A/Bテスト不要論

A/Bテストが普及し、当たり前のように実行されるようになった文化でもなお気をつけるべきポイントがあります。「A/Bテストのおかげでよい施策の選択ができる」という言説が独り歩きしてしまい、いわばA/Bテストの実施が施策リリースの免罪符となっている状態です。

大きく二通りの背景があると推察されます。

まずひとつ目に、施策をリリースすることが前提となっており、信頼性が劣後するケースです。A/Bテストを行うことでより確からしい選択ができるのは、一定の信頼性が確保された状態で意思決定を行う場合です。しかし設計が疎かになったり結果から都合の良い解釈をしてしまっては、上げられたはずの成果を失うリスクがあります。A/Bテストを行う目的を見直す必要があるでしょう。

ディスコミュニケーションの課題と類似する打ち手となりますが、望ましくない選択をとった場合の損失をシミュレーションし、信頼のおけるテストの実行と判断を定着させるコミュニケーションをとることとなります。

一方で、A/Bテストという取り組みを信頼するあまり、あらゆる変更をA/Bテストに任せているケースも考えられます。この場合、A/Bテスト自体に発生するコストが過剰になっていないか気を付ける必要があります。サンプルサイズが潤沢でテストがほぼ自動化されている場合はともかく、実際にはテストをすることによる機会損失があり、また人的コストもかかっている場合が多いのではないでしょうか。

本記事の主旨とは逆説的に聞こえますが、A/Bテストをせず、信念に則って施策をリリースするという選択肢も存在します。これは、A/Bテストを通した意思決定の質の向上で得られるリターンが、A/Bテストの取り組みそのものにかかるコストを下回っているような場合が該当します。

具体的には以下のようなシチュエーションが想定されます

• スピード感のある意思決定が求められ、厳密な正解よりも試行回数が重要である
• 戦略上施策の実行が既定路線であり、A/Bテストによって判断が変わるものではない^※
• ある施策による変更が軽微で、ほかにテストを優先すべき施策がある

一度立ち止まり、A/Bテストの価値がどこにあるのか、それが本当に求められている場面なのかを考えることも分析チームに求められている役割です。

※施策により売上やユーザ体験が大きく損なわれないかを確かめる分析や、施策の改善を目的とした種々の分析は有効でしょう。

3. まとめ

A/Bテストを通して成果創出のサイクルを回していくには「標準化」が重要だという立場のもと、ワークショップを通して整理された「標準化」を阻む課題とその打ち手を挙げてきました。

• 分析チームと施策チームで目線を合わせ、A/Bテストの価値について共通認識を持つこと
• 属人化回避・効率化の目的で各種プロセスを型化・テンプレート化していくこと
• 時にA/Bテスト自体の投資対効果も考慮しながら、統計的に信頼のおけるA/Bテストを行うこと

共通しているのは単に分析技術による解決が可能な課題ではなく、関係者を巻き込み組織のコミュニケーションや考え方を変えていく、地道な活動を必要とするという点でしょう。

A/Bテストは技術の研究が進み、国内外に豊富な先進事例もある中、現場で実行するには様々なハードルがあることも事実です。情報を集め理想を見据えつつ、足元の一歩を着実に進んだ先にこそ成果が生まれます。

この記事がベストプラクティスを求める皆様のお役に立てれば幸いです。