UXリサーチを活用して、仮説検証プロセスを改善した話（後編）〜メルカリの機能を事例として〜
はじめに
はじめまして。メルカリ Analytics チームでAnalyst兼リサーチャーをしている@tsugutoと申します。今回のブログでは、私が分析を担当しているSeller Experience チームで取り組んでいる「アプリのログ分析とUXリサーチ統合の試み」について、実際の事例を紹介できればと思います。前回のブログでは、取り組みの全体像について記載しているので、ご興味あればご覧いただけると嬉しいです。
振り返り：取り組みの全体像について
前回のブログでは、Seller Experience チームでの分析〜機能を実装する取り組みの全体像を紹介しました。改めて、このチームでの機能の実装までの流れは以下のとおりです。
1. Analyze : 最もインパクトのあるターゲットを選定する
2. UX Research : インサイトを理解し仮説を構築する（優先順位をつける）
3. Rapidly Test Basic Hypotheses : 仮説を検証するための小さな実験を行う
4. Test Features : 検証した仮説に基づき、開発を伴う実験を行う
今回のブログでは、上記ステップの1〜3に焦点を当てて実例に基づき、取り組みを紹介します。
※このアプローチを採用するに至った背景などは前回のブログをご覧ください
ご紹介する機能について
ご紹介する機能は以下の「実際に売られた品物の配送方法と料金を表示したコンポーネント」になります（社内では ”Subliminal Shipping Onboarding” と呼んでいました）。
この機能は、売却済み商品の詳細画面に、実際に利用された配送方法と金額を掲載するものです。以降、このコンポーネントを実装するに至った背景や実施したことをステップ1（Analyze）〜ステップ3（Rapidly Test Basic Hypotheses）の流れに沿って紹介していきます。
ステップ1 Analyze：ターゲット（セグメントとコンバージョン）の決定
このステップでは、販売数（出品数）の最大化というチームの目標に対して、何に取り組むのが最も効果的かを明らかにしました。以下の図のようにお客さまをSellに関わる経験でセグメント化し、セグメント間の移動をコンバージョンとし、どのコンバージョンがチームの目標に対して重要かを整理しました。その上で、今回は「未出品者→出品者＝初出品コンバージョン」に注力することが決定しました。理由としては、以下のとおりです。
・未出品者のボリュームが一定あったこと
・転換した場合、今後の継続によって複利的な効果が期待できること
ステップ2 UX Research：コンバージョンに必要なことはなにか
このステップでは、今回ターゲットとした「未出品者→出品者」というコンバージョンに注目し、インタビューとアンケート調査を用いて、コンバージョンに至るドライバーは何かを探索していきます。インタビューとアンケートでは、'Fogg Behavior Model' を参考に、Motivation / Ability / Trigger（以下 M/A/T）という視点でコンバージョン要因の網羅と優先順位付けに取り組みました。
インタビューでは、”最近初めて出品した人” を対象に、まず仮説の洗い出しを行いました。この取組を始めるまでもインタビューは行っていましたが、インタビューは主に未出品者の方を対象にすることが多く、出品しない理由はわかっても出品に至るドライバーがなんなのかは不明瞭な状況でした。そのため、この取組では ”最近初めて出品した人” にインタビューを行い、ドライバーを洗い出すことを目指しました。
インタビュー項目は、M / A / Tに沿って作成し、インタビューがしやすい形にアレンジしました。主にお客様に伺った内容としては以下のとおりです。
・出品するまでのこと（不用品の処分・出品へのチャレンジ）
・出品したときのこと（理由・背景・きっかけ・大変だったこと）
・これから出品したいもの（まだ出品できていない物・出品意向と理由）
出品したときのことを中心に据え、前後の文脈を理解することで、出品体験に至る要因を明らかにしていくことを目指して設計しました。結果は以下のように、Confluenceとスライドでまとめております。
Confluenceはチーム内での利用がメインなので、話した内容を細かくまとめ、インタビューごとに整理しています。スライドはチーム外への共有のためにもデザイナーの方に見やすくまとめていただいております。
次に、アンケートではインタビューで得た仮説を元に調査票を作成していきました。アンケートで目指したことは、インタビューで得た仮説の中で、未出品者 vs 出品者で比較した際に最も違いがある項目（仮説）を見つけることです。そのため、アンケートでは未出品者と直近初出品者を対象にし、同じ項目を聴取し比較するというアプローチを取りました。M / A / Tそれぞれについて、マルチアンサーとマトリックスの5スケールの設問を用意しました（以下イメージ）。
アンケートで取得したM / A / Tの有無を比較すると、MotivationとAbilityで未出品者と出品者の違いが大きいことがわかりました（以下図）。
次に（今回はAbilityに着目し）、Abilityの中で最も重要な項目（仮説）はなにかを探しに行きました。その際、アンケート結果を以下のフレームで整理し、左上の「出品者はできる」領域にプロットされる項目が重要であると考えました。このフレームは、M / A / Tの各項目を経験者が持っている課題ほど上に、未経験が持っている課題ほど右にプロットしたものです。その結果、左上に配送関連の項目が多くありました。「これらの左上にプロットされている項目は、解決すれば出品転換してくれそうな課題である」という仮説を立てました。その中でも、インタビューや過去の知見を踏まえ「配送料金」「配送方法」の課題が解決する（理解できる）と出品につながると考え、次のステップに移行しました。
ステップ3 Rapidly Test Basic Hypotheses：小さな仮説検証の積み重ね
このステップでは、ステップ2で得た「 ”配送料金” ”配送方法” の課題が解決する（理解できる）と出品につながる」という仮説の検証を目指しました。ここでは施策のインパクトよりも「仮説の検証」が主目的になります。そのため、まず簡易的にできるテストから実施していきました。
最初に、通知（お客様にメッセージを送ること）を使った実験を行いましたが、通知はView数が少ないため効果検証が困難でした。その後、いくつか場所を変えて検証していきましたが、効果はありそうだが検証しきれない状況が続きました。効果検証を行うためには、未出品者の方にそれなりに見ていただく必要がありました。そこで、どこで表示すればメッセージを最適に届けられるかを考えました。そして、以下理由（＋アイデア）から「アイテム詳細画面」に決定しました。
・（ログ分析から）未出品者も一定訪れている
・（インタビューから）出品前に出品したい物を検索している
・（PdMの意見）通知のように1回きりではなく、何度も目にすることでLearningが促されるのではないか ※このアイデアから “Subliminal” という名称が来ています
アイテム詳細画面に決めた後は、PdMを中心にデザイナーやエンジニアが冒頭で紹介したコンポーネントを実装し、改めてテストを行いました。
テストでは、ビジネスKPIと言われるログで取得できる指標の他にも、アンケートで取得する意識指標もあわせて確認することで、「施策→意識変化→行動変化」を理解しようと試みました。
私達のチームでは施策によって、ビジネスKPIがあがることはもちろん重視しているのですが、「配送料金・配送方法の課題が解決する（理解できる）と出品につながる」という仮説の検証も重視しています。
つまり、インタビューやアンケートで構築した仮説からテストを行い、ビジネスKPIが上がったら成功ではなく、構築した仮説の良し悪しも検証することで、ネクストアクションにつなげることを意識しました。
テストの結果は、ビジネスKPIと意識KPIで以下の図のように整理できます。今回は、右下に当てはまる結果となったため、仮説が ”正しく” 行動までつながったと結論づけました。このように、2軸で整理することで結果とネクストアクションが考えやすくなりました。（もちろん、実際は一筋縄では行かないことも多いですが、補助線の1つとしては十分に役立っていると感じています）
結果とまとめ
「アイテム詳細画面」に配送方法と配送料金を表示するテストでは、目的としていたKPIのリフトが確認できました。また、当初狙っていた未出品→出品のコンバージョンだけでなく、その他のKPIや意識指標のリフトも確認することができました。したがって、「 ”配送料金” ”配送方法” の課題が解決する（理解できる）と出品につながる」という仮説は、（一定）検証されたうえでリリースすることができました。
こうした一連のプロセスを経て上手くいったこともありますが、以下の点については、まだまだ十分ではないと感じています（前回のブログでも触れた内容です）。
MATの区分けが曖昧：
Motivation/Ability/Triggerそれぞれについて、なにがMでなにがAなのかなどがまだ曖昧。また、M/A/Tの区分（だけ）でよいのかが不透明
仮説検証ステップにおける実験設計のための、施策立案が大変：
今回の施策はPdMが考えた施策だが、重要な仮説から筋の良い施策を立案するのはとても難しく、個人に依存している
Analyst / Researcher 双方の知見とリソースが必要：
チームでは私と別にAnalyst（@natsume）がいるため、リサーチ周りを私、Analytics周りをnatsumeと分担したためワークしたが、1名で行うのは大変
現在は、1と2に注力し、改善を進めています。
ここまでお読みいただき、ありがとうございました。
▼採用情報サイト・関連記事はこちらから
▼Analytics teamに関する他のオススメ記事
・「他人の目」ではなく「自分のやりたいこと」に集中できる場を求めて メルカリAnalytics新卒メンバーの所感
・アナリスト歴3ヶ月目と3年目のメンバーそれぞれが考える、楽しさの軸とキャリアプラン
・メルカリAnalyticsチームのミッション・ロールモデルを策定した狙い マネージャーが語る“変遷”と“今
この記事が気に入ったらサポートをしてみませんか？