こんにちは。コンサルティング部の石山 資（たすく）です。
ABテストの提案者とコーディング担当は異なるケースが多いかと思います。
ただ、仕様書を送るだけで実際に出来上がったテストが意図したものと異なったり、
修正で手戻りが多く発生しやりとりに時間がかかってしまったりしていないでしょうか？
私も普段の業務でABテストの提案者として、よくエンジニアの方に依頼をしていますが、
依頼をはじめた当初はテストが想定と違う形で出来上がり、
何度も修正をお願いするなど非常に多く手戻りが発生していました。
参考画像：このやり取りだけで午後が過ぎました
このような苦い失敗から原因を探ったところ、問題は大きく以下の3点にあると判明しました。
- どんな目的でテストを実施するか伝えていない/伝わっていない
- レイアウトやデザインの指示が粗い（=同じ視点で会話ができていない）
- ABテストは提案者・エンジニアとの共同作品という認識に欠けている
特に、3番目は精度の高いABテストを実施するにあたり意識したい最も重要なポイントなのですが、
依頼者・実行者という役割分担の関係から認識が薄れやすい点ではないでしょうか。
本記事では手戻りを最小限に、より効果的なABテストを提案者・エンジニアの両者で
作り上げていくためのコツを前述の3要因から紐解いていきます。
記事の最後には「依頼時に気をつけたいポイント・エンジニアが最低限確認したいチェックリスト」を
Googleスプレッドシートで無料ダウンロードできますので、参考としてぜひご活用ください。
1. どんな目的でテストを実施するか伝えていない/伝わっていない
すべてのABテストには目的があります。
そのため、提案・依頼する側は何のためにテストをするのか？という意識を強く持っているかと思います。
一方で、依頼を受けるエンジニアはテストの目的が把握できないと、
あくまで１つのタスクとして処理するしかありません。
結果として、表面的な実装となり「イメージと異なるから・・」と何度も修正をお願いするという
無駄な手戻りが発生してしまいます。
修正依頼する際に改めて目的をきっちり伝えないと、修正が修正を呼ぶという泥沼にはまってしまう恐れもあります。
どんな目的のためにテストを実施するのか伝わりきらなければ、
仕様書や口頭で伝えた内容をただコーディングするしかないのです。
そのため、依頼者の頭の中で「こうしてくれるだろう」となんとなく思っていることは
当然汲み取ってはもらえず結果出来上がりが異なる、という事態になってしまいます。
目的をしっかりすりあわせることで、「ここはこうすればいいな」という
エンジニア目線から柔軟な実装が可能になります。
多くの場合、サイト構造の理解はエンジニアのほうが深いため、目的をしっかり伝えきることで
依頼者が意図したものをよりよい形で実装していただける可能性が高いです。
「なぜ実装するか、どんなことを検証したくて実施するのか」を伝えないと意欲がわかず、
目的にあわせて柔軟なコーディングはできません。
職人さんに頼むような形で、目的をまずしっかり伝えきるところから始めましょう。
2. レイアウトやデザインの指示が粗い
1つ目の点よりもミクロな要因として、依頼に際して指示が粗い点にあります。
私の失敗を例にとってみましょう。
以下のようなテストを依頼しました。
ここでの問題は、コンテンツを移動した際に「間隔はどのくらいあけるのか」
「移動するコンテンツと本来は一緒に移動すべき関連コンテンツはどう処理するのか」
「移動した場合のフォントサイズやフォントカラーはどうするのか」と
諸々の指示が抜けている点にあります。
結果、本来であればコンテンツを移動してすぐ済むはずの実装で何度も手戻りが発生してしまいました。
前提として、依頼者はマーケティング担当者、実装担当者はエンジニアと業務内容が異なるため、
コミュニケーション時の共通言語・視点にはズレがあります。
依頼者はおおまかなイメージのもと「文章を追加して」「コンテンツを移動して」と
サイトを閲覧するユーザー目線で依頼する場合が多いかと思いますが、
実装者は「文章をどれくらいのフォントサイズでどれくらいの行間を開けて追加するのか」
「コンテンツを移動した場合に発生する空白はどう処理するか」というコーディング視点で考えているため、お互いの目線の高さが大きく異なってしまいます。
必然的に、実装者は「ここはどう処理すればいいのだろうか・・・？」と
もやもやを抱えたまま実装し、一方で依頼者は「イメージと違うんだけど・・・」
と出来上がりに不満をもつ結果となってしまいます。
手戻りなくスムーズに実装を進めるには、依頼者がコーディング担当者に歩み寄り、
目線を落とし共通言語で依頼する必要があると考えます。
テストの目的はもちろん伝えた上で、どういったレイアウト・デザインにしていくのかと
細かくすりあわせすることが手戻りをなくす秘訣です。
3. ABテストは提案者・エンジニアとの共同作品という認識に欠けている
最後に一番お伝えしたい点は、ABテストは関わる人々の共同作品であるという認識です。
テストを実施する目的や勝敗の基準となるKPIをきちんと設定できるのは依頼者でしょう。
ただし実装にあたって、Webサイトの構造上こうしたほうがいいじゃないか？という有益なアドバイスができ、精度の高いテストへと昇華させてくれるのはエンジニアならではのスキルでしょう。
ABテストを行うにあたり、テストでの変更点以外の要因に結果が左右されてしまうのは絶対に避けなければなりません。
そもそもテストを実施した意味がなくなってしまい、実施した期間分の機会損失が発生してしまいます。
そうならないためにも、依頼者は依頼者の領域で、
コーディング担当者はコーディング担当者の領域で互いに意見を出し合い、
1つの作品として作り上げていく意識をもつことを強くオススメします。
4. まとめ
本記事のポイントをまとめます。
- 手戻りをなくすため、テストの目的をきちんと理解してもらえるまで伝える
- 共通言語が異なることを認識し、同じ視点で会話ができるよう依頼者が歩み寄る
- テストは依頼者とエンジニア担当者の共同作品と心得る
最後に、下記記載のリンクより実装にあたって最低限確認したいチェックリストと、
依頼時に気をつけたいポイントをまとめたGoogleスプレッドシートを無料でダウンロードできます。
こちらを参考により早くより精度の高いABテストを行い、効果的なサイト改善ができれば嬉しいです。
