むかーしむかし、旅行会社にいたことがありました。

そこの旅行会社に「A/Bテスト回す隊」みたいな部署がありまして、そこで1年間ひたすらテスト回すのをやってました。そこで学んだことを書きます。

やってたのは、だいたい下の画像の感じ。

目標は「実施月○本・年間で1億うん千万の利益貢献」、みたいな感じで持ってる部署です。

画像引用↓
https://travel.watch.impress.co.jp/docs/news/1058208.html

実装のとこはサイトの共通パーツやシステムに関わるような本格的なやつはデザイナーさんやエンジニアさんにお願いしてましたが、簡単なものは自分たちでやってました。

エンジニアさん・デザイナーさんへの依頼は意図を明確にして、具体的に

 「ここの文字もっと目立つ方がいいんじゃない？」じゃなくて、「お客さんに伝えたい優先順位はここが1番、ここが2番、ここが3番」の方が良かったり。
「ここのボタン押したとき」じゃなくて「このボタンを押して、この画面が出るまでの間に」みたいな。

意図を明確に伝えて、なるべく詳細な言葉で伝えるようにすると、初回のアウトプットにズレが出づらいです。
(デザインに関してはデザインカンプみたいの作る場合もあれば、上のように希望だけ伝えて何パターンか作ってもらうこともありました)

私が依頼するときに伝えてたのはだいたいこんな内容（内容は適当に考えたやつです）

テストの目的まで伝えておくと、「実はこっちが課題なんじゃないの？」とか「昔やったアレと似てるけどアレは上手くいかなかったよね…」みたいに話が広がったりアドバイスがもらえることもあります。

ビジネスサイドには細かい数字まで伝えると次につながるブレストに広がる

で、テストが終わるとビジネスサイド(各サービスの担当者)に結果をフィードバックします。
この時、「A案はCVR＊＊%とB案はCVR☆☆%でこっちが良かったです」だけだとあんまり次に繋がる声が出てきません。
「CVRはA案でした。しかしフォーム遷移率はB案が高く、フォーム2ページ目で離脱してました」とかまで言えると結構改善に繋がる案が出てきます。「B案は購入意欲を喚起しやすかったけど、●●という注意事項を理解しづらいUIになってたのかも」とか。

ここまで伝えるためには、事前の仮説設計で指標が細分化してあることと、結果分析のために数値が事前に取れるようになってることが大事です。

そのためにも、アナリティクスツールとの連携がしてあるのが重要かなと思います。

テストスケジュールは関係各所に共有しておくべき

私がやってたときは商品ごとのキャンペーンと、会社全体のキャンペーンがあり、そのキャンペーンのコンテンツ作成部隊が別にいました。
なので、たとえば「トップページで“夏休みキャンペーン”への導線を強化する」みたいなテストをやってる途中で「ある日会社行ったらトップページに“ハワイのホテル値下げキャンペーン”のバナーが出てる」みたいなことがあり得るような体制でした。

A/Bテストでは可能な限り、テスト中に他の要素の変更がある状態は排除したいもの。なので、「テストに影響ありそうなサイトUIの変更があるか」を関係各所と常に共有し合うべきです。

システムやjs・jQueryくらいまでの開発言語は理解しておくとはやい

これは出来ればレベルの話ですが、そもそもエンジニアさんはA/Bテストが仕事ではありません。通常業務の片手間にやってくれてます。
なので業務負担はなるべく減らすべきですし、タイミングによってはスケジュール通りにお願いできるとは限りません。

そのためにも簡単なjsで済むようなテストは自分でコード組めると進行が早いです。ただし、プログラミングは素人が簡単に手を出せるもんではありません。

ので、私は自分でコード書いた場合でもレビューしてもらうのと「明日からテスト始めます。何かエラー上がったらすぐに止めるので教えてください」というのは必ずお願いしてました。

あと、先に書いたように「ボタンをクリックしたとき」と言っても実は「前の画面が出る前に出したいのか、後に出したいのか」とか「クリックだけでいいの？マウス乗せたときの動きはどうするの？」とか細かい指定が必要な場合があります。
見た目の話だけでなく、システムや外部APIとの兼ね合いで決まることも多いので、ここは細かく詰める必要がある場合があります。

別に細かい話ができる必要はないのですが、「ユーザーの名前を表示したい」より、「ユーザーの名前が表示したいから、このAPIから返ってくるnameの中身使いたいんですけど」とかって話ができると
①「名前ってどうやって取るの？入力させるの？システムから取るの？」って考えなくてすむ
②「お、コイツちょっとは分かるんじゃん」と思ってもらえればコミュニケーション取りやすくなってラッキー
とかがあるので良いかもしれません。

あと、そもそも技術マターでテストできる/できないの判断がつくようになると、テスト設計のときにちょっとだけ無駄な作業が減るかも（せっかく考えたのに「できない」となるケースが潰せるので）

社内コミュニケーションがテストの半分である

とくに仮説出しとかは各部署の声をいろいろ聞くのが大事なので、「声を出してもらえる関係づくり」もテスト成功につながる重要なファクターです。
なので、そういう関係を作るのがテスト担当者の重要な仕事だなーと思ってます。

気が向いたら後編書くおっおー。