メルカリのデータアナリストが解説! 事実に基づくプロダクト改善の進め方

[2019/06/27 08:00]冨永裕子 ブックマーク ブックマーク

施策を決定するまでの「4つのステップ」

具体的な施策を勘案するにあたっては、次の4つのステップで検討が進められた。

  1. 問題の構造を理解する
  2. チームレベルの解決策=戦略を導く
  3. 解決する問題を見極める
  4. 解決策の”筋の良さ”を見極める

以降では、それぞれについて順に見ていこう。

1. 問題の構造を理解する

出発点は「ユーザーの購入継続率を高める」というビジネス側からの”お題”である。問題がわかったとき、最初に手を付けるのは「解ける問題に変換すること」だ。

石田氏はこのときによく使うアプローチとして「影響のある変数の発見」と「指標の分解と構造化」を挙げた。今回の問題に影響する変数として着目したのは「取引時間」である。「早く届くからAmazonを使う」人にとっては当たり前に思えるかもしれないが、考え得る仮説を全て洗い出し、データで全てを検証して見つけることが重要だと石田氏は訴える。

続いて、「取引時間」という変数を、購入ボタンが押されてから取引が終わるまでとし、「購入~発送時間」「発送~商品確認時間」「確認~評価時間」の3つに分解した。この3つの中から「購入継続率へのインパクトが大きいのはどれか」を選ばなければならない。

「発送~商品確認時間」はコントロールが難しい。「確認~評価時間」はインパクトが小さい。しかし「購入~発送時間」であれば、コントロール可能でインパクトも大きいとわかった。

2. チームレベルの解決策=戦略を導く

「購入~発送時間」という解けそうな問題がわかったが、これではまだ粗すぎる。”レバー”が多すぎて、どこをどう動かせば問題が解けるのかはがわからない。動かさなくてはならないレバーを見極めるには、「その問題を解くとどれだけいいことがあるか」というインパクトの見積もりと、「その問題をどれだけ解けそうか」という実現可能性の見積もりで絞り込めばよいと石田氏は説く。

今回のケースでは、取引時間をどこまで短縮でき、継続率がどのぐらい上がるかを見積もることにした。

インパクトの見積もりでは、これまでの取引のうち、「1~2日で発送」「2~3日で発送」「4~7日で発送」の割合がそれぞれどの程度か、平均取引時間はどの程度かを確認した。このうち最も日数の長い「4~7日で発送」の割合や平均取引時間を確認し、どのぐらい改善できるか、どの程度の売り上げ改善効果が見込めるかを算出する。石田氏はここでは「このぐらい改善しよう」という意志を反映すると話す。この時点でボツになることも多いが、その場合は別の改善案を検討する。

実現可能性の見積もりでは、ユーザーのニーズを裏付ける行動データが存在するかを確認する。今回の場合、出品者が1~2日で発送できるかどうか、無理がない発送なのかを確認することになる。実際の発送時間のデータを調べたところ、設定は「4~7日で発送」としていても、24時間以内に発送していることがほとんどだとわかった。この発見で、設定を「1~2日で発送」に変更を促してもユーザーにストレスがないと判断できた。

3. 解決する問題を見極める

設定を「1~2日で発送」にしてもらうことが売り上げ貢献につながる度合いや、実現可能性の高さを経営に示すことができるようになったが、まだ終わりではない。設定を「1~2日で発送」にしないのは、ユーザーが何か問題を抱えているからだと考える。ニーズがないのに改善しようと意気込んでも、空回りになるだけだ。そこで行うのが、改善したいと思うビジネス側の理想とユーザーの置かれた現実のギャップを確認することである。

具体的には、定性データで仮説を構築し、定量データで問題の大きさを検証する。今回のケースでは、ユーザーインタビューなどで得た定性情報を読み解いた結果、「土日にしかコンビニに行けない」「急な用事で対応できない」などのユーザーの置かれている状況が浮かび上がった。

さらにユーザーが「早く売りたいが、どうすればいいかがわからない」と考えていると仮定し、それが少数派でないことが確認して、その問題が解決しなくてはならないほどの大きさなのかどうかを検証した。

4. 解決策の”筋の良さ”を見極める

最後が具体的な施策を決めるステップである。

「このステップでは施策の優先順位を付けることが重要」だと石田氏は強調する。施策を考えても、失敗することは多い。期待した効果が得られない場合、何を変えるべきかをトライ&エラーで試す必要があるのだ。

今回はまず「1~2日で発送すれば、早く売れる」というお知らせをメールで出し、反応を見ることにした。その開封率が悪ければメールの件名を変えなくてはならない。開封されても読了率が悪い場合は、内容を変える必要があるだろう。その後の行動に変化がなければ、アプリの動線を変えなくてはならない。それでもダメなら「お知らせ」以外の施策に変えるべきだし、逆に、最初のお知らせで反応が良かった場合はすぐに機能化すればよい。

* * *

石田氏が示した4ステップで進める機能改善の例は、これまで取り組んできたさまざまな施策のほんの一例に過ぎない。このほかにも、石田氏らのチームは多くの意思決定の材料を提供している。メルカリの急成長はデータアナリストのほか、エンジニアやデザイナーなど、プロダクトに関わるあらゆる人たちのたゆまぬ努力によって支えられているのだ。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

もっと知りたい!こちらもオススメ

メルカリはなぜ、想定外のトラブルに迅速かつ誠意ある対応ができたのか

メルカリはなぜ、想定外のトラブルに迅速かつ誠意ある対応ができたのか

メルカリにおいて2017年6月22日、ログイン後の画面が他のユーザーに表示されたかもしれないという事故が発生した。パフォーマンス改善に向けてCDNプロバイダの切り替え作業を実施した際の出来事だ。顧客からの問い合わせにより発覚したこの問題は、約1時間のうちに対処された。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします
注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
[解説動画] 個人の業務効率化術 - 短時間集中はこうして作る
ミッションステートメント
教えてカナコさん! これならわかるAI入門
AWSではじめる機械学習 ~サービスを知り、実装を学ぶ~
対話システムをつくろう! Python超入門
Kubernetes入門
SAFeでつくる「DXに強い組織」~企業の課題を解決する13のアプローチ~
PowerShell Core入門
AWSで作るマイクロサービス
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

会員登録(無料)

ページの先頭に戻る