SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

初学者のためのA/Bテスト入門

なぜサービス改善にA/Bテストが必要なのか?──初学者のためのA/Bテスト

初学者のためのA/Bテスト入門 第1回


  • X ポスト
  • このエントリーをはてなブックマークに追加

A/Bテスト以外のやり方との比較

 A/Bテスト以外には、例えば以下の方法があります。

  1. 同業他社Webサービスなどの類似サービスでボタンの色が違う場合のクリックされやすさを比較する
  2. 参加者を募ってデモ環境でWebサービスに触ってもらい、アンケートをとる
  3. 実際のWebサービスでボタンの色を変えて、クリックのされやすさが変更前と比べて変化するのかを見る
  4. 一部の地域のユーザーに対してだけ実際のWebサービスでボタンの色を変えてみて、クリックのされやすさに違いが出るかどうかを見る

 ここではこれらの方法の弱点とその対策を紹介することで、なぜA/Bテストが必要になってくるのかをお話します。

 一つ注意してほしいのは、これらの方法よりも、A/Bテストが常に優れているわけではありません。A/Bテストの実施コストが高い場合や原理的に難しい場合などは、上記の方法を採用することをお勧めします。しかし、以下でも説明しますが、上記の方法の弱点をA/Bテストであれば補えるため、A/Bテストが実施可能なときは実施することを推奨します。

同業他社Webサービスなどの類似サービスでボタンの色が違う場合のクリックされやすさを比較する

 そもそものお話になりますが、他社サービスのクリックされやすさのデータは往々にして手に入りません。

 この手法の利点は、もし比較可能なデータがあるなら、それらを比較するだけなので最も安上がりに実施できます。

 この手法の欠点は、類似したWebサービスが仮にあったとしても、サービスの目的(領域)やユーザーや機能や画面デザインなど違いは無数にあるはずです。さらに、クリックされやすさの違いの原因が、その無数の違いからではなくボタンの色の違いである、と言えないはずです。

 なので、実際に変更をかけたいWebサービスで(全く同じものを使う)、実際に変更をした影響(より原因らしい)を見たほうが良い、となります。ここがA/Bテストの優れる点になります。

 一方で、似たようなサービスで似たような変更の影響が、A/Bテストによって確かめられた証拠がたくさんある場合、この比較結果はかなり確からしいと言えます[1]

参加者を募り、デモ環境でWebサービスにさわってもらい、アンケートをとる

 この手法の利点は、実際に変更をかけたいWebサービスで、実際に変更をした影響を見て取れるので、先ほどの方法よりも確かです。

 この手法の欠点は、大きく2つあります。まず、実際に集まった参加者がサービスを実際に使うユーザーと比べて偏る危険性があります。例えば、忙しいビジネスパーソンや子育て世帯の方はなかなか集まりにくいです。また、アンケートも工夫をしないと偏った結果が得られてしまいます。

 有名な例だと、あるメーカーが新商品のラジオのデザインを決める際にユーザーインタビューをしたところ、参加者はありがちなデザインを「古い、だめ」、奇抜なデザインを「新しい、良い」と答えたのですが、インタビューの謝礼でどっちかのラジオを持って帰って良いと伝えるとありがちなデザインのほうを選んだ、という逸話があります。

 この例は極端かもしれませんが、アンケートの結果をそのまま信じるのは危険です。やはり実際のサービス利用状況に限りなく近い状況で行動変化が起こるか、を見たほうが良いです。ここがA/Bテストの優れる点になります。

 一方で、Webサービス上で観測できる行動以外の、生理指標や(目線の動きや血中成分変化によるストレス値の変化など)その行動に至った内面(より詳細なインタービューなど)は、実際に参加者を集めて実験しないとわかりません。新しくサービスを作るときや、機能を大きく変更したいときなど、ユーザーがどこでつまずくかをしっかりと把握したい場合は、この手の方法はより重要になってきます。

実際のWebサービスでボタンの色を変えて、クリックのされやすさが変更前と比べて変化するかを見る

 この手法の利点は、実際のWebサービスを変更するため、サービスを実際に使うユーザーのWebサービス上の行動変化を直接測ることができます。

 この手法の欠点は、この方法だと変更前と変更後の時期が違う点です。ユーザーの行動が(1)平日土日などの週内での変動(2)給料日前後などの月内での変動(3)春夏秋冬などの年内での変動(4)景気変化などのより長期的な変動(5)政策変更の直前直後、など時期によって異なる場合、ボタンの色の変更が原因でユーザー行動が変わったのか時期の違いなのかの見極めが難しくなります。

 実際にボタンの色の変更でクリックされやすさが、本当は10%弱上昇していたとしても(これがうれしい改善幅だとしても)、時期の変動に紛れてしまってわからなくなってしまいます。なので、変更前と変更後は同じ時期で比較できたほうが望ましいです。そこで同じ時期に部分的に変更した場合と、変更しなかった場合を比較する方法を考えます。ここがA/Bテストの優れる点になります。

 一方で、時期をわけないとテストが難しいケースもありえます。例えば、地域の防犯のために警察のヘリコプターが上空を巡回する、といったアイデアの場合を考えます。部分的にヘリコプターを飛ばす、といったことが難しいため、アイデアが本当に有効かを試すために時期で分けての実験にならざるを得ません。

 この場合でもヘリコプターを飛ばす時期と飛ばさない時期を交互に何回も繰り返すことで、時期の違いの影響を軽減させるといった工夫で、アイデアを評価することは可能です。ただし、時期を分けなくて済むなら分けないほうが良いです。

一部の地域のユーザーだけ実際のWebサービスでボタンの色を変えて、クリックのされやすさに違いが出るかを見る

 この手法の利点は、実際のサービス、実際のユーザー、実際の行動、同じ時期での比較がそろっています。問題になるのは地域によってユーザーが違うか、といった点です。ボタンの色の感じ方が地域によって違う可能性は低いかもしれませんが、例えば豪華と感じる色が日本では黒に対して白という国もある、といった具合に可能性はゼロとは言えません。

 この手法の欠点は、変えるユーザーと変えないユーザーで同じようなユーザーの集団になる分け方をすることです。実は医学の世界でも重要な問題になっています。医学なのでボタンの色ではなく病気の治療法が正しいかを評価したいというモチベーションです。文字通り死活問題です。できる限り確かなことを言わないといけません。

 しかし、同じ治療法でも患者の年齢や性別、過去の疾病歴、生活習慣などによって、治療効果が異なる可能性は大いにあり得ます。治療方法間の比較をするために、この無数の要因が同じになるように、患者の条件をそろえるのは至難の業です。

 そこで当時の統計学者が考え出した方法は、完全にランダムに治療方法を割り当てることでした。患者の無数の要因と関係ない割り当てを行えば、各割り当てで無数の要因が最終的に同じくらいのバランスになるはずだ、という考えです。

 このランダムな割り当てによる実験のことをランダム化標本実験、英語ではRandomized Controlled Trial(RCTと略されます)と呼びます。現代でも新薬や治療方法の検証の医学分野や、それ以外の自然科学の分野で幅広く使われている方法です。A/Bテストは、このRCTの考え方に基づいて作られています。

 一方で、「最終的に同じくらいのバランスになるはず」とみなすためには、実験参加者が大勢必要なので、実験参加者が少数の場合はランダムでなく、重要そうな要因を注意深く選んでバランスをとる方法のほうが良い場合があります。一般にインターネットで公開しているWebサービスであれば日々大勢のユーザーが訪問するため、第2回で紹介する極端な外れ値ユーザーを除けば、ランダムな割り当てが有効です。

 ここまでA/Bテストの「なぜ」を構成する要素の多くを述べてきました。上で述べた工夫点を盛り込んだものがA/Bテストです。

 [1]専門用語ではメタアナリシスといいます。適切に分析されたメタアナリシスは、単一のA/Bテストよりも信頼できるとされています。GoodUI.orgというWebサービスでは実際に行われたA/Bテストの結果を集約しており、大変参考になります。

次のページ
A/Bテストのやり方

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
初学者のためのA/Bテスト入門連載記事一覧
この記事の著者

大杉 直也(オオスギ ナオヤ)

 2005年、千葉大学文学部に飛び入学(高校は中退)。2009年、奈良先端科学技術大学院大学情報科学科に入学(博士前期課程、理学修士)。2011年、東京大学大学院総合文化研究科に入学(博士後期課程、単位取得満期退学)ならびに理化学研究所脳科学総合研究センターで大学院リサーチ・アソシエイトに採用。研究...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/17656 2023/06/05 15:28

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング