1.0UX TIMEShttps://uxdaystokyo.com/articles菊池 聡https://uxdaystokyo.com/articles/author/satoshi-kikuchi/rich600338<blockquote class="wp-embedded-content" data-secret="8MdyYHrX7K"><a href="https://uxdaystokyo.com/articles/a-b-testing-concept-execution/">もったいない！！！間違ったA/Bテストで、良いアイディアが没になることも！？</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/a-b-testing-concept-execution/embed/#?secret=8MdyYHrX7K" width="600" height="338" title="“もったいない！！！間違ったA/Bテストで、良いアイディアが没になることも！？” — UX TIMES" data-secret="8MdyYHrX7K" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://uxdaystokyo.com/articles/wp-includes/js/wp-embed.min.js </script> https://uxdaystokyo.com/articles/wp-content/uploads/2025/02/25.jpg1200800A/Bテストの仕方で、せっかくのコンセプトやアイディアが没扱いされることがあります。それはもったいないことです。A/Bテストのやり方次第で、それらのもったいない行動はなくなり、適切なテストを実施することができます。 コンセプトのA/Bテスト !=実行するか否か！？ 原文：https://booking.design/a-b-testing-concept-execution-b37bf4d744d Illustration by Elena Snezhinskaya（エレナ・スネジンスカヤ) 「テストをしましたが、結果は失敗でした。」 この言葉は、A/Bテストの世界ではよく見られますが、「コンセプト（アイデア）そのもの」と「コンセプトのテスト」とは、本質的に異なるという事実を見落としがちです。アイデアは時間が経つにつれて再び浮上することがあります。過去に失敗したものは「失敗作」としてラベルを貼られ、新たな機会を得ることなく埋もれてしまうことが多いです。 「それは以前に試しましたが、うまくいきませんでした。」 このような思考を放置すると悪影響を及ぼします。例えば、旅行予約サイトのBooking.comは約10年前からさまざまな実験を行っています。「すでにすべて試し尽くした」と感じることもありますが、ユーザー体験の向上余地は常に存在します。そのため、否定的な意見を聞いた際には、次のように尋ねます。 具体的に何を試したのか？ その実験はいつ行われたのか？ どのくらいの期間続けたのか？ ユーザーの行動にどのような影響を与えたのか？ 実行時の不具合や使い勝手の問題は本当にゼロだったのか？ 成功への道は一本だが、失敗の道は無数にある 十分に練られたアイデアが「失敗した」と聞いたとき、私はいくつかの質問を投げかけます。この考えは、「成功の道は狭く、失敗の可能性は無数にある」という経験に基づくものです。 多くのA/Bテストを実施してきた結果、アイデアが失敗する要因はさまざまであることが分かりました。例えば、些細な変更に見えるものが、大きな影響を及ぼすことがあります。 良いアイデアでも失敗する原因 1. 不完全な技術的実装 ページ上の他のコンテンツとの関係において、機能のサイズや配置が不適切でした。新しく追加したり再設計した要素が、ページ上の他の重要な部分の注目を奪っていないでしょうか？また、新機能のためのスペース確保が、既存の価値ある要素を犠牲にしていないでしょうか？ 大きすぎる画像、重たすぎるCSSファイル、またはパフォーマンスの悪いJSを実装していませんか？ 発生しているかもしれないエラーに注意していますか？ユーザーには「見えない」変化も、コンテンツや視覚的な変化と同様に大きな影響を与えることがあります。ウェブサイトのすべての重要な統計を慎重にチェックすることが重要です。 メインの要素の色、書体、またはフォントサイズの選択がわずかに誤っている 最も重要な情報は、人の目を引き、読みやすいものになっていますか？一見些細に思える要素、例えばセリフ体フォントの不適切な使用であっても、ユーザー体験の質を大きく左右する可能性があります。デザインにおいて、一つ一つの細部は全体の印象と使いやすさに密接に関連しています。 インターフェースに新しい要素を追加、既存要素の削除、または変更を行う際は、ユーザーの全体的な操作体験に与える影響を慎重に考慮する必要があります。 デザイナーは往々にして新機能や変更点に注力するあまり、それが既存の機能や操作性全体にどのような波及効果をもたらすかという視点を見落としがちです。 ページの読み込み時間が長くなる 機能のサイズや配置が適切でない 重要な要素の視認性を奪ってしまう 過剰なデータ読み込みや非効率なコード（画像のサイズ、CSSやJSの最適化不足） 2. タイミングの問題 時間の経過とともに自動的に消えるツールチップを導入したり、1年の特定の時期だけ関連性のあるコンテンツを追加していませんか？ 情報提示のタイミングは非常に重要です。情報を早すぎたり遅すぎたりするタイミングで表示したり、ユーザーが内容を十分に理解する時間がない場合、期待した効果とは反対の結果を招いてしまう可能性があります。 ユーザーの行動と合わないタイミングで情報を提示 季節限定のコンテンツや一時的なツールチップの導入 3. エッジケースのシナリオのバグ 使用頻度の低いブラウザーやデバイスでレンダリングの問題はありますか？タブレットでもデスクトップと同じように利用できますか？ウェブサイトが多言語の場合、適当に翻訳され、正しくローカライズされていますか？複数のエッジケースが重なると、積み重なって悪い影響を与える可能性があります。しかし、総合的なA/Bテストの枠組みを活用すれば、分析を通じて潜在的な問題点を見つけ出せます。 例えば、ユーザーエージェントやブラウザの種類、特定の国でテストが失敗する原因を理解できます。全てのユーザーがウェブサイトで良い体験を得られるべきです。データを基に問題を解決することで、成果を最大限に引き出せます。A/Bテストは、全てのユーザーに質の高い体験を保証する効果的な方法です。 核となる考えに直接関係のない変更は、その規模の大小にかかわらず、一見不要と思える変更であっても、予想外の結果を招く可能性があります。 文章の一行を変更する際に、文字を大きくしたり・小さくしたり、色を新しく追加したりしましたか？そのような複数の変更を同時に行うと、テストで検証したい本来の要素が他の要素の影響を受けて、正確な結果が得られない可能性があります。 例えば、私たちの経験では、色の変更効果を検証するテストにおいて、フォントサイズがほんの少し大きくなっただけで、本来なら安定して確認できるはずの結果が得られなくなることがありました。また、私たちの経験では、色の変更効果を検証するテストにおいて、フォントサイズがほんの少し大きくなっただけで、本来なら安定して確認できるはずの結果が得られなくなることがありました。 特定のブラウザやデバイスでの不具合 多言語サイトの翻訳やローカライズのミス 小さなエラーの積み重ねが大きな影響を与える 4. テストのノイズ 新しいフローをテスト実行していますか？それとも別のインタラクションをテストしていますか？追加または変更したコンテンツがページにすぐに表示されませんか？ ユーザーの追跡は、ユーザーが実際に視覚的な変化を目にしている場合や、異なる動作を含む要素を操作している場合に限定すべきです。テスト対象を認識していない、または操作していないユーザーまでを追跡対象とすることで、統計的なノイズが発生し、結果の信頼性が損なわれます。過剰なノイズにより、ユーザーが示そうとしている本来の意図が不明瞭となり、正確な分析の実施が困難になります。 変更点が複数あるため、どの要素が影響を与えているか不明瞭 ユーザーが実際にテスト対象を認識・操作していない場合のデータ混入 5. 適切なオーディエンスの設定 顧客の入口となるポイントと、サイトの利用履歴は、コンテンツとの関わり方に大きく影響します。最も関連性の高いユーザー層に的確にメッセージを届けられれば、重要な指標の改善につながる意味のある相互作用を生み出せる可能性が高まります。 ターゲットユーザーに適切なメッセージを届けているか ユーザー層を適切にセグメント化できているか 6. アクセス数の不足 テストは、わずかな変更点のみを体験した少人数のユーザーに限定して実施されましたか？ アクセス数の少ないウェブサイトで大きな効果を得るには、より大きく、より思い切った変更が必要です。つまり、あなたの考えは実際には効果があるかもしれませんが、数値として確認できない場合があります。変更の規模は、サイトへのアクセス数に見合ったものにする必要があります。 テスト対象者が少なすぎると、統計的な有意性が得られない 小規模サイトでは、大胆な変更が必要 7. アイデアの時期尚早 このアイデアはいつ検証しましたか？十分な期間を設けたにもかかわらず、課題は今も解決に至っていないのでしょうか？ 今日は効果が出なかったことでも、明日には成功につながるかもしれません。反対に、昨日の良い結果が、今日はむしろ進歩の妨げとなっているかもしれません。 私たちが創造するプロダクトは、その利用者と同様に、絶えず変化し成長できる存在であるべきです。 人は本来ダイナミックな存在であり、自身と周囲の世界の進化に伴って期待も変容していきます。それゆえに、私たちがデザインするプロダクトもまた、同じようにダイナミックであることが求められます。 デザイナーは常に最新の動向を把握しているため、一般の人々の感覚よりも先を行きがちです。最新のデザイントレンドやHTML、CSSの新しい手法、先進的な技術の組み合わせは、私たち専門家にとって魅力的です。しかし、実際のユーザーが心地よく感じるものと、私たちの期待はしばしば大きく異なります。 「私たちは、一般の人々が今日使えるプロダクトを創っています。」 私はいつも、この言葉を心に留めています。普通の人々が、今日使うためのプロダクトをデザインしているのだと。昨年はスワイプに慣れていなかった人も、今年はそれを目にすることを期待するかもしれません。かつてブラウザをクラッシュさせていた派手なコードは、数年後にハードウェアがより強力になるにつれて、その問題を解決できるかもしれません。 「これらは、私がデータを使ったデザイン作業でよく直面する課題の一例です。そのため、テストしている高レベルの概念を深く理解し、システムの複雑さを把握し、ソリューションをしっかり実装することが、アイデアの成功（または失敗）にとって非常に重要です。」 以前は効果がなかったが、現在では受け入れられる可能性がある 技術やユーザーの期待の変化を考慮する A/Bテストの適切な進め方 A/Bテストは慎重に設計し、仮説を明確にしたうえで行う必要があります。事前に評価指標を定めず、やみくもに試すと、誤った結果を導く可能性があります。A/Bテストを次に実施する際に、覚えておくべきポイントをご紹介します。 「コンセプトを適切に検証するためには、複雑な要素を慎重に整理することが重要です。失敗につながる可能性のある点は数多くあります。」 「テスト結果は、それが良い結果であれ、悪い結果であれ、あるいは中立的な結果であれ、同じコンセプトの次のバージョンの改善に活かすことができます。また、新たな仮説を立てるためのヒントにもなります。」 A/Bテストは、その規模の大小に関わらず、同じように慎重に実施する必要があります。適切な仮説を立てず、事前に評価指標を決めないまま、やみくもにアイデアを試すことは、誤った結果（偽陽性・偽陰性）を引き起こす確実な方法と言えます。 否定的な結果や中立的な結果が出たからといって、必ずしも『完全な否定』を意味するわけではありません。それらの結果は、『まだ方法が正しくない』あるいは『まだその時期ではない』ということを示唆している可能性があります。テストを重ねていくことで、『否定的な結果』が本当の意味での『否定』なのか、それとも別の意味を持つのかを、より正確に判断できるようになっていきます。 コンセプトと実装の違い 大手Webサイトでも、機能自体は非常に有用でありながら、デザインが洗練されていなかったり、使いづらさが目立ったりするケースがあります。そのような場面に遭遇すると、「もったいない」と思わずため息をつきたくなることもあります。優れたアイデアであっても、実装の質が低ければ、本来の可能性を発揮できずに終わってしまうことがあります。一方で、アイデアの本質的な価値が非常に高い場合、実装が完璧でなくても成功につながることがあります。 このように、アイデアと実装の関係には両面性があります。実装が不十分なために素晴らしいアイデアが埋もれてしまうこともあれば、逆に、実装が完璧でなくても、アイデアそのものの価値の高さによって成功を収めるケースもあります。 優れたデータドリブンデザイナーは、「コンセプトと実装は必ずしも一致しない」ことを理解し、テストの設計を慎重に行う必要があります。A/Bテストは単なる結果の良し悪しではなく、コンセプトを継続的に進化させるための重要なツールなのです。この記事は、2015 年 1 月に Booking.com の技術ブログに掲載されたものです。 ワークショップのご案内 3月29日（土）に、筆者のエリン・ウィーゲル氏のワークショップが開催されます。彼女のワークショップでは、A/Bテストに加え、定性・定量データを効果的に一元管理する「ユーザーエクスペリエンス・ランドスケープ」が学べます。 実践的な手法を通じて、その考えに至るまでの理論をわかりやすく解説します。感覚やデータの読み違いによってプロダクトの方向性がぶれないよう、効果的なテスト方法を学びましょう。これらのノウハウは、すぐに現場で活用できます。 マーケティング担当者はもちろん、ビジネス視点でデザインを構築するための理論的アプローチを身につけたい方にもおすすめです。即戦力を磨きたい方にとって、必ず受講すべきワークショップです。 「成長を生み出すインサイトの見つけ方—データを行動に変えるための実践ガイド」開催日時：2025年3月30日（日）9:00〜 最近の投稿