UXリサーチを活用して、仮説検証プロセスを改善した話（前編）
はじめまして。メルカリ Analytics チームでアナリスト兼リサーチャーをしている@tsugutoと申します。
今回のブログでは、私が分析を担当しているSeller Experience チームで取り組んでいる「UXリサーチを活用して、仮説検証プロセスを改善した話」について、2回に分けて紹介します。1回目は、取り組みの全体像について、2回目で具体的な事例を記載できればと思います。少し長いですが、お読みいただけると嬉しいです。
Seller Experience チームについて
メルカリでは、PdM / Designer / Engineer / Analystでチームを組み、日々プロダクト（メルカリアプリ）の改善に取り組んでいます。私が担当している Seller Experience チームでも、全員でコミュニケーションを取りながら、機能の開発・改善に取り組んでいます。Seller Experience チームは名前の通り、販売体験の改善を目指したチームになっており、最終的には販売数（出品数）の最大化を目標に日々お客さまの体験の改善に取り組んでいます。
メルカリの他のチームと同様に、私達のチームも体験の改善を目指して分析〜新しい機能の開発を行っていますが、リサーチの活用と仮説検証のアプローチが他のチームとは若干異なっており、今回はその話ができればと思います。
取り組みの全体像：概要と目指していること
Seller Experience チームで行っている取り組みは以下の図のようなイメージになります。これまでは、「Analyze（ログ分析→施策立案）→Test Features（A/Bテスト）」の流れで進めておりました。一方で、今現在行っている取り組みでは全体を4つのステップに分けて進めております。
1. Analyze : 最もインパクトのあるターゲットを選定する
2. UX Research : ターゲットのインサイトを把握し、仮説を構築する（優先順位をつける）
3. Rapidly Test Basic Hypotheses : 2で立てた仮説を検証するための小さな実験を行う
4. Test Features : 3で検証できた仮説に基づき、開発を伴う実験を行う（この実験でクリアした機能を開発する）
次に、なぜアプローチを変更したのか当時の課題に沿って説明したいと思います。
取り組みの背景：課題と目的
上述の通り、Seller Experience チームではこれまで「Analyze（ログ分析→施策立案）→Test Features（A/Bテスト）」という2つのステップでプロダクト改善に取り組んでおりました。この2つのステップにおいて生じていた課題についてお話します。
Analyzeのステップで生じていた課題
ここでの分析は、仮説ベースでの機能や画面の分析が主でした。例えば、「（分析仮説）出品回数が少ない人は、バーコード機能を使えていない→（実装のアイデア）出品画面でバーコード機能をもっと目立たせてはどうか」といったものです。
こうした分析は、機能の立案には直接的でスムーズなものの、お客さまの出品という体験の全体像やその時に生じる意識については、フォーカスしてきれていませんでした。そして、機能や画面に分析をフォーカスした場合、それ以外の範囲（例：実は配送周りの体験が最も重要だった）については重要であろうと重要でなかろうとこぼれ落ちてしまいます。
また、ログ分析では事実（出品経験頻度が少ない人は多い人に比べ、バーコード機能を使っていない）はわかるものの、なぜ使わないのかはわからないままでした。また、出品したことがない人の出品に関する行動はログには落ちていません。仮に初出品という体験を考えた際には、出品画面に来た後よりも来る前の行動や意識が重要なのではないかと考えておりました。そのため、ログだけでは捉えきれないお客さまの多面的な実態とインサイトを掴む必要がありました。
Test Featuresのステップで生じていた課題
次に、Test Featuresのステップで生じていた課題についてご説明します。
これまでも新しい機能を立案／テストする際は、分析結果を元に提案や議論をして進めておりました。例えば先程のバーコードの例で「出品回数が少ない人は多い人に比べ、バーコード機能を使っていない」という結果が出たとします。この場合、以下の通りそれぞれ別の施策と要因が考えられ、どれが重要か（効果的か）はわかりません。
機能自体の認知向上 : 機能自体を知らない
機能の詳細の認知向上 : 機能は知っているが、何が出品できるのか知らない
機能の拡張 : 何が出品できるのか知っていて、不十分だと感じている
こうしたケースでは議論の上、試す機能を決めていきます。実際にはもう少し詳細に分析をするので対象は絞れるものの、いずれにしても「考えられる要因別に作って検証する」という流れになります。結果として、分析を行えば行うほど、試したい機能は増加します。また分析のテーマ（対象機能や画面）が異なる場合、分析間の優先順位は明確にはつけられません。結果として、「分析領域 × 分析を踏まえたアイデア」の数だけ試したい機能は増加し、開発工数が上がっていきました。
ステップ全体を通じて生じていた課題
「分析→機能検証」という流れが独立に並列しているような状況になっていました。Analystそれぞれがテーマを考え分析を行い、全員で分析を踏まえた機能の立案・検証を行っていたため、チームとしての目標は一つであっても、分析テーマごとに独立して進んでいるような状態でした。結果として、チーム全体の目標に対する知見や取り組んだことが統合されておりませんでした。
解決のために考えたこと
こうした課題を踏まえ、Seller Experienceチームでは下記のGoalを設定しました。
【全体を捉える】個々に独立したテーマではなく、お客さまの体験全体を整理し理解する
【仮説を洗練させる】分析や議論で得られる仮説の精度を高め、優先順位をつける
【効率よく検証する】開発を大きく伴わない最小単位でのテストを行うことで、効率よく仮説を検証していく
【知見をまとめる】上記で得た知見をテーマごとに整理し、蓄積する
上記Goalを達成するために、以下のイメージように分断されていた分析と検証を整理しなおし、先述した4つのステップでPJを進めるようにしました。
取り組みの詳細：各ステップについて
この後、詳細に説明する3つのステップについて整理した図が以下になります。3つのステップで行うことをシンプルに表現すると「マーケットの分析から有望なターゲットを決め（1. Analyze）、ターゲットの行動につながるドライバーを明らかにし（2.UXR）、コストをかけずに検証する（3.Rapidly Test）」になります。
次に、改めて各ステップで取り組んでいることをご説明します。
1.Analyze
このステップでは、「販売数（出品数）の最大化」というチームの目標に対して、何に取り組むのが最も効果的かを明らかにします。この問の論点として、「1. 何に取り組むか」「2. 最も効果的か」があります。Seller Experienceチームでは上記の論点に対して、セグメントとコンバージョンで整理をしています。以下の図のようにお客さまをSellに関わる経験でセグメント化し、セグメント間の移動をコンバージョンとします（論点1）。そして、どの移動が最も出品回数／GMVへのリフトが大きいかをシミュレーションします（論点2）。
「Analyze」のステップで決めた、セグメントとコンバージョンに次のステップ以降では集中し、どうしたらコンバージョンを起こせるかについて明らかにしていきます。（以降、未出品者→出品者を例に説明していきます）
2.UX Research
このステップでは、ステップ1で設定したセグメント間のコンバージョンに至る要因を幅広く把握し、検証が可能な仮説構築を目指しています。
このステップは2つのフェーズで構成されています。第一は、デプス インタビューを中心にした発散フェーズ。第二に、アンケートを中心にした収束フェーズになります。コンバージョンに至る要因を幅広く把握するために、'Fogg Behavior Model' を参考にしました。このモデルは、ユーザーのアクションを起こさせるためには、Motivation / Ability / Trigger（以下 M/A/T）が必要だという立場に立っております。このモデルを参考にしつつ、インタビューとアンケートでコンバージョン要因の網羅と優先順位付けに取り組んでいます。
インタビューでは、出品を経験したお客さま／していないお客さま双方に対して、M/A/Tについて聞きます。このフェーズでは発散が目的なので、個別具体のエピソードを重視して深堀りを行います。
アンケートでは、インタビューで得たエピソードや気持ちをアンケートで聴取可能な粒度に抽象化／統合します。ここで重要なのは、次のステップで行う検証において検証可能な粒度の仮説が構築できる調査票を作成することです。アンケートは、インタビューと同様に出品を経験したお客さま／していないお客さま双方を対象とします。そして、両者を比較した際の差の大きさに着目し「1. どの領域が最も大事なのか」「2. その領域において重要な項目はなにか」を明らかにします。
3.Rapidly Test Basic Hypotheses
アンケートの結果から、重点領域と領域内における重要な項目がわかった後は、検証のための実験設計を行います。
例えば、「領域（M/A/T）」では、Abilityが最も重要（差分が大きい）で、Abilityの中でも「配送料の理解」が重要ということがアンケートでわかったとします。このステップでは、UX Research(以下 UXR)でわかった「Abilityの中の ”配送料の理解” があればコンバージョン（未出品→出品）にする」という仮説を検証するための実験を行います。
ここで意識するのは、仮説検証のための実験を如何に ”数多くスピーディーに回す” かです。このステップでの目的は、UXRで得たコンバージョンにつながる仮説（要因）を検証し、次のステップで行う機能開発を伴う実験につなげることです。したがって、このステップでは施策のインパクトよりも「仮説の検証」が主目的になります。先程の例ですと、「Abilityの中の ”配送料の理解” があればコンバージョン（未出品→出品）する」という仮説を検証するために、開発を伴わない通知を使った実験を行います。その上で、効果が検出できた仮説を次のステップであるTest Featuresへ持っていきます。ここで重要なのは、
効果が確かめられた手段（= 通知）をTest Featuresのステップに持っていくのではなく、効果が確かめられた仮説（= “配送料の理解” があればコンバージョンする）を持っていくということです。もちろん、良い手段であれば、それを拡大して行うこともありますが、このステップの目的は「仮説の検証」になるので、インパクトを考慮した機能の開発や実験は次のステップで考えます。
また、仮説の検証の際には、ログで取得できるKPIの他に意識指標もKPIとして定めています。理由としては、仮説（= “配送料の理解” があればコンバージョンする）には、「1. 配送料について理解する」「2. 理解したらコンバージョンする」という2つの要素が含まれているからです。したがって、アンケートとログを使い、1と2双方の仮説の検証をこのステップでは行います。
Test Features
最後のステップでは前のステップで検証できた仮説に基づき、機能の開発と検証を行います。前のステップですでに、仮説（= “配送料の理解” があればコンバージョンする）は検証済みであるので、このステップでは”機能”にフォーカスします。どういう機能であれば最もインパクトが出せるのかを中心に議論を行います。例えば、前のステップで仮説（= “配送料の理解” があればコンバージョンする）の検証を通知で行った場合、同じメッセージをもっと多くのお客さまが見る画面で出せばインパクトが出せるのではないかといった議論を行い、実装する機能を決めていきます。そして、実験を行いリリースへと向かいます。
全体を通じた知見の蓄積
全体を通じて得た知見は、以下の図のように「コンバージョン(Target) - Insight(Motivation / Ability / Trigger) - Hypothesis - Experiment Result」でまとめてConfluenceに蓄積しています。整理しておくことで、仮説の検証や新しいメンバーが入った際のオンボーディングがスムーズになっています。
取り組みのまとめ：効果と課題
最後に、こうした取り組みによって生じた効果と課題について振り返ります。
全体を通じて得た効果としては、以下3点があげられます。
分析を多面的・計画的に行えたことで、コンバージョンにつながる仮説の網羅性が上がり、優先順位もつけられた
検証を効率的に行うことで「ファクト・筋の良い仮説・筋の悪い仮説」を切り分けられ、施策のROIが上がった
情報の整理が進み、PJ進行がスムーズになった
一方で新たな課題も見えてきました。現時点で感じている主な課題は以下です。
仮説検証ステップにおける実験設計のための、施策立案が大変（ステップ2と3）
- UXRによって「なにがコンバージョンに効きそう」かはわかるものの、検証するためには、お客さまに対して施策を行う必要があります
- しかし、施策の立案はまだまだ個々人のアイデアによるところが多いのが現状です
仮説検証における施策と仮説の切り分け（ステップ3）
- ステップ3で仮説検証を行い効果が検出されなかった際に、「仮説が誤っていた」のか「施策が十分でなかったのか」の切り分けが困難になっています
- 例えば、「”配送料の理解” を促す通知を送る」実験を行い効果が出なかった場合に、その理由が「”配送料の理解” が理解されても出品につながらない（仮説の誤り）」なのか、「”配送料の理解” が促しきれていなかった（施策が不十分）」なのかを切り分けるのが難しく、十分な検証がしきれていないケースがあります
以上のとおり、効果が出た部分もあるものの課題も多く、まだまだ改善が必要だと考えています。
最後に
ここまでお読みいただき、ありがとうございます。最後に次次回の予告をさせてください。今回は、チームで取り組んでいる内容の全体像についてでしたが、このブログの次次回では、実際に開発につながった例を元にどのように取り組んだかの詳細について紹介できればと考えております。またご覧いただけると幸いです。
▼採用情報サイト・関連記事はこちらから
▼Analytics teamに関する他のオススメ記事
・「他人の目」ではなく「自分のやりたいこと」に集中できる場を求めて メルカリAnalytics新卒メンバーの所感
・アナリスト歴3ヶ月目と3年目のメンバーそれぞれが考える、楽しさの軸とキャリアプラン
・メルカリAnalyticsチームのミッション・ロールモデルを策定した狙い マネージャーが語る“変遷”と“今
この記事が気に入ったらサポートをしてみませんか？