(6ページ目)

ユーザー ✕ 検証

に関する学び

---

原因分析はどう進める？ 原因の分析にあたっては、まずプロセスごとに分解し、確認することが大切だと感じました。特に「what／where／why／how」を意識し、まず「where」から入念に分析することで、その後の「why」や「how」の解像度が高まると理解しています。 A/Bテストってどうやる？ また、A/Bテストが有効な手法であることを学びました。その際、検証する「要素」は極力少なくし、その他の条件は共通とすることで、スコープを狭めることが重要だと感じました。実際にアプリ上でプッシュ通知とバナーを用いたA/Bテストを実施した経験から、振り返ると「キーメッセージ」に差が生じてしまった点が課題として残りました。 ログイン改善は何が？ さらに、アプリのログイン率向上を図るため、ログインに至るフローを細かく分解し、原因の追究を行いたいと考えています。特に、パスワード設定の箇所で離脱するユーザーが多いという仮説に基づき、検証からスタートする予定です。その後の改善策として、ユーザーインタビューやUIテストの実施を検討しています。

共感ってどう大切？ 共感の大切さが一番印象に残りました。ユーザーの動作や発言に注目し、彼らの立場から本質的な課題を捉える観察力が必要だと感じました。また、誰がどのような状況でどんな課題に直面しているのかを明確にし、仮説に基づいた解決策を提供することの重要性も実感しました。 営業はどう変わる？ BtoB向けの営業プロセスでは、自社商品やサービスの提供に留まらず、まずユーザーの課題を把握することが基本です。ユーザーの課題を観察し、仮説を立てながら顧客との検証を繰り返すことで、まだ気づかれていない本質的な問題にも気付くことができ、その結果、より効果的な営業活動（インサイト営業）につなげることができると感じました。 課題共有は必要？ また、商談前に課題を共有する活動の重要性も印象に残りました。普段の業務においては、顧客サーベイやチームでのブレインストーミングを通じ、ユーザー視点の仮説を多々収集しています。その後、実際の検証結果をもとに、各メンバーが顧客との面談時の特性や仮説の内容を共有し、より質の高い対応策の検討へとつなげています。

データの見せ方は？ 分析の基本は比較であり、どのデータをどのように加工するとわかりやすいかを考えながら進めることが重要です。データにはさまざまな種類があり、それぞれに応じた加工やグラフの見せ方があります。データ分析を始めるにあたっては、「目的」の確認や「仮説」の設定とその検証が欠かせません。 オンライン離脱はなぜ？ 私たちのチームでは、お客様に対して紙の手続きではなく、ウェブサイトでのオンライン手続きを推奨しています。しかし、オンライン手続きを行っているお客様がどの段階で離脱しているのか、また、紙を取り寄せるお客様の属性や動機がどのようなものかを理解し、分析する必要があります。 改善点の見極めは？ 具体的には、オンラインで離脱しているページやそのユーザーの属性、さらに紙手続きを行っている方々の属性や動機に関するデータを収集し、オンライン手続き率を向上させるためのボトルネックを特定することが目指すべきゴールです。仮説を立てながら慎重にデータを分析し、検証するプロセスを通じて、この課題に取り組んでいきたいと思っています。

どうやって原因究明？ 原因を特定するためには、分析対象を複数のプロセスに分解し、各段階で明確な問題箇所を探ることが重要です。人の行動に即したプロセス設定を行うと、問題の箇所が特定された後の改善策の検討もスムーズに進むことが分かりました。 なぜ事前に決定すべき？ また、What、Where、Why、Howといった基本的なステップと同様に、プロセスの設定も仮説検証に入る前に決め、その内容を関係者間でしっかりとすり合わせる必要があります。たとえば観光客の減少の原因を探る場合、ユーザーがどのように情報を収集し観光地を選んでいるかというプロセスと、現状で手に入っているデータがどの段階で取得されたものかを突き合わせることが求められます。 データ整理の要点は？ さらに現状分析においては、最初に幅広いデータを集めることが大切です。各データが持つ性質や項目、定義について周知するとともに、ファネルに沿ってデータの分類や分析を進め、必要なデータの補完を行うといった段階的な準備が成功の鍵となります。

AI回答の信頼は？ 生成AIの回答について、最終的な確認作業や責任はユーザー自身が担うべきだと感じています。そのため、回答をそのまま受け入れるのではなく、批判的に見直す必要があると考えます。 仮説の根拠は何？ また、自身の仮説を補強するためのリサーチなどに利用する場合は、単に回答を求めるだけでなく、回答の根拠がどこにあるのかを明示させるなど、原文と照らし合わせながら確認することが重要だと思います。 議事録作成のコツは？ 議事録の作成など、文章のドラフト作成には実用的な面があり、実際に利用している同僚もいます。私自身は会議の内容を自分の頭に定着させる目的で、できるだけ自分で文章を作成するよう心がけていますが、ドラフト部分を生成してもらう手法も有効だと感じています。 エビデンスはどう確認？ 今後も、「この仮説はこういった検証が必要なのではないか」といった相談や、エビデンスの収集の一助として利用していきたいと考えています。

A/Bテストの条件は？ A/Bテストを行う際には、条件を揃えることや分析対象を明確にすること、そして仮説に基づいた比較検証のポイントを絞ることの重要性を確認できました。また、課題解決に向けた顧客心理に着目したテキストや、ユーザーが行動しやすい要素が重要であると実感しました。 ファネル分析の重要性は？ 日々のウェブマーケティング業務において、今回の課題事例から多方面で役立つ考え方を学ぶことができました。特にファネル分析は不可欠であり、全体のマーケティング戦略を踏まえた上で確実に設定し、日々の分析に活用していきたいと感じています。 新たな仮説はどう導く？ 今後は、売り上げ向上を目指すサイト改善や広告のA/Bテストにこれらの知見を活かしていくとともに、単一のデータに頼るのではなく、関連する複数のデータを俯瞰的に捉え、そこから新たな仮説を導き出す取り組みを深めていきたいと思います。

多様な視点が見えた？ 同じテーマについて多様な視点が存在することを学びました。ユーザー目線で現状の仕組みが本当に適切かどうか検証する過程で、各メンバーが異なる観点から意見を述べるのが非常に印象的でした。また、デザイン思考に関しても、参加者それぞれの想いが交わり、ディスカッションが盛り上がった点がとても興味深かったです。 現状をどう問い直す？ 現状に疑問を持つことの重要性を実感しました。従来の方法や制度がただ続いている理由だけで運用されている場合、それをユーザー目線で見直し、より使いやすい形に改善する必要があります。まずは現行制度の確認と再検討を行い、実際に受けた問い合わせや相談内容を反映させながら問題定義を進めることが大切です。さらに、可能な範囲で改善策を検討し、ロジックツリーなどの手法を用いて試行錯誤を重ねるプロセスが印象に残りました。