少数精鋭部隊が生み出す メルカリを加速させる超・実務データ分析

Transcript

1. Copyright © Mercari, Inc. All Rights Reserved. 少数精鋭部隊が生み出す メルカリを加速させる超・実務データ分析 shoei@Mercari BI Team
2. Copyright © Mercari, Inc. All Rights Reserved. Part 2 少数精鋭部隊が生み出すメルカリを加速させる超・実務データ分析 プロダクトを改善するデータ分析の全体像 Part 3 プロダクトを改善したデータ分析の具体例 Part 1 メルカリのBIチームのデータ分析の考え方
3. Copyright © Mercari, Inc. All Rights Reserved. はじめに
4. メルカリについて 「売れる・買える」フリマアプリです
5. 数字で見るメルカリ① 日用品から車まで取り扱っています (様々なカテゴリの商品のデータがあります ) スポーツ・レジャー 
 6% 家電・スマホ・カメラ 
 
8% エンタメ
 21% 宝探し感覚での購入体験
 レディース
 24% メンズ
 17% コスメ美容
 6% ベビー・キッズ 
 4% その他
 14% 「メルカリ」には、アパレル商品だけでなくエンタメ 用品・家電・コスメ等、多彩な商品が出品されてい ます。個人の出品者によるユニークな商品が数多 く出品されているため、他のサービスでは見つから ない掘り出し物に出会うことができます。また、「メ ルカリ」に蓄積された豊富な取引データとAI技術を 組み合わせ、個人の趣味嗜好に合った商品をレコ メンドする等、商品を探しやすい環境整備にも取り 組んでいます。このような「宝探し感覚」での購入 体験を提供することで、「メルカリ」はEコマース（電 子商取引）でありながら、ソーシャルメディアと匹敵 するほど滞在時間が長いアプリとなっています。
 オールジャンルの多彩な 商品ラインナップ

6. 数字で見るメルカリ② たくさんの時間を使って頂いております (商品取引だけでなくメッセージや良いね等のコミニケーションデータもあります ) ソーシャルメディアに匹敵する滞在時間 
 （時間／月）
 ZOZO TOWN ヤフオク！
 ラクマ
 楽天
 AMAZON メルカリ
 Facebook Instagram LINE Twitter hour 5.3 出典：ニールセンデジタル（ 2018年1月）
 ※ニールセンデータはモバイルアプリのみに基づき、 PCブラウザを含まない。 2018年1月の月間ユニークユーザあたり月間平均利用時間。 2018年2月にフリルはラクマに統合 

7. 数字で見るメルカリ③ 急成長しています (Dailyで使われるアプリならではの大規模なデータがあります ) 出典：会社資料。JP版メルカリ事業の通期決算概況（FY2018.06）より 1. キャンセル等を考慮後の取引高の合計 2. .Monthly Active Userの略であり、1ヶ月に一度以上利用した登録ユーザーの数（「メルカリ アッテ」「メルカリ カウル」「メルカリ メゾンズ」「メルチャリ」「teacha」は含まず） GMV(1) 3,468億円 FY 2016.6 FY 2017.6 FY 2018.6 MAU(2) 1,075万人 1326 2320 3468 525 845 1075 FY 2016.6 FY 2017.6 FY 2018.6 FY 2018.6 売上高 334億円 122 212 334 FY 2016.6 単位：億円 単位：億円 単位：万人 FY 2017.6
8. Copyright © Mercari, Inc. All Rights Reserved. Part 1 メルカリのBIチームのデータ分析の考え方 少数精鋭部隊が生み出すメルカリを加速させる超・実務データ分析 ▶ Part 2 プロダクトを改善するデータ分析の全体像 ▶ Part 3 プロダクトを改善したデータ分析の具体例 ▶ Part 1 メルカリのBIチームのデータ分析の考え方
9. Data Analysit | Mgr @ mercari - Cross UX Team - NPS / RR - Registration Rate iOS Engineer @ eversense - Apps for Woman - Family-friendly Apps Data Engineer @ GENIEE - Datawarehouse for Ads (RTB) - ETL(Large Scale/Distributed) - Analytics Platform - Medium-term management plan Ishida Shoei (twitter : @_ _shoei_ _) 自己紹介 エンジニアリングから企画、分析まで
10. 今日伝えたいことをひとことで言うと 「データ分析はプロダクト改善を飛躍的に強化するもの」 ※ 特別な「~アルゴリズム」のような難しい分析手法を使わずとも強化は可能
11. 1 2 難しいことをせずともデータを使って意思決定できる 手段の派手さよりも、目的を意識して分析することが重要 今日伝えたいこと（詳細） 3 メルカリのBIチームでの具体例 本発表では「超・実務的なデータを使った試合運び」をご紹介します
12. Warning 今日は以下の内容は残念ながら出てきません。 • 細かい鮮やかな・最新の「 ~分析」の手法 • 相関と因果を切り分けるエレガントな方法 • 横文字のアルゴリズム 今日話さないこと 小難しい話はしません
13. Copyright © Mercari, Inc. All Rights Reserved. Part 0 メルカリのBIチームのデータ分析の考え方 少数精鋭部隊が生み出すメルカリを加速させる超・実務データ分析 ところで、メルカリのBIチームとは
14. Business Intelligence Team 意思決定を最大化させることをミッションにしたチーム Engineer Backend / iOS / Android / QA 売上あげるぞ Designer Product Manager 使い易いアプリ にするぞ Analyst Xさん Aさん Hさん Oさん Yさん Bさん Iさん Pさん Zさん Cさん Jさん Qさん Retention 上げていくぞ プロジェクト軸 職能軸 Here!
15. メルカリBIチームのデータに対する考え方 メルカリでは色んな意思決定を + Data で考えています 成長戦略 重点項目決定 機能開発 クーポン配信 目的先行型 + Data な考え方
 データ先行型な考え方 + Data + Data + Data + Data 「このデータ、何かに活用できないだろうか」 データ処理を頑張る 出口を探して活用
16. Copyright © Mercari, Inc. All Rights Reserved. Part 0 メルカリのBIチームのデータ分析の考え方 少数精鋭部隊が生み出すメルカリを加速させる超・実務データ分析 意思決定におけるデータの意義
17. 意思決定におけるデータの意義 ① 不確実性を低減 不確実性 不確実性
18. 意思決定におけるデータの意義 ② アイデアを生み出す
19. メルカリのデータアナリストの環境 ・出品や購入等のトランザクションデータ
 ・起動・タップ・画面表示等のClientイベントデータ
 ・分析用中間テーブル
 ・etc
 
 
 ありとあらゆるデータをbigqueryに集約
 bigquery
 分析者 Analyst Query Data ・SpreadSheet
 ・Python
 ・Colaboratory
 ・R
 ・etc
 
 データの加工ツールは個人によって様々
 ドキュメンテーション ・Google Slide
 ・Wiki
 ・Docs
 ・Slack
 ・etc
 
 重要度に応じて必要十分な
 ドキュメンテーションを行う
 インサイト抽出 データソース インサイト抽出し放題のbigqueryは宝の山
20. メルカリのデータ分析チームの目指すところ 普段の業務 + Data = 強いサービス改善 + Data
21. Copyright © Mercari, Inc. All Rights Reserved. Part 2 プロダクトを改善するデータ分析の全体像 少数精鋭部隊が生み出すメルカリを加速させる超・実務データ分析 ▶ Part 2 プロダクトを改善するデータ分析の全体像 ▶ Part 3 プロダクトを改善したデータ分析の具体例 ▶ Part 1 メルカリのBIチームのデータ分析の考え方
22. 何かを達成するときのステップ ①「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め 理想を描いて 客観的に現状を把握して 理想と現状のGAPが 起こる真因・背景を理解し 解決方法を決めて実施し 解決度合いを客観的に確認 皆さんも無意識のうちにこんなプロセスであらゆることを考えてるんじゃないでしょうか？
23. サービス単位・チーム単位・施策単位 サービス改善の中で満たすべき2つの要求 ①「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め 理想を描いて 客観的に現状を把握して 理想と現状のGAPが 起こる真因・背景を理解し 解決方法を決めて実施し 解決度合いを客観的に確認 ビジネス観点の理想 : 目標・計画を達成する 理想の二面性
 1
 お客様観点での理想 : 理想の生活を実現する 2
 営利団体の事業者には 両方を同時に解くことが求められる ２つの要求を同時に満たすことが事業者として求められる（やりがいのある部分） 粒度間の統一性
 粒度ごとにそれぞれのステップが存在。 整合性を合わせて、理想を実現することが求められる 粒度

24. サービス単位・チーム単位・施策単位 サービス改善の中で満たすべき2つの要求 ①「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め 理想を描いて 客観的に現状を把握して 理想と現状のGAPが 起こる真因・背景を理解し 解決方法を決めて実施し 解決度合いを客観的に確認 ビジネス観点の理想 : 目標・計画を達成する 理想の二面性
 1
 お客様観点での理想 : 理想の生活を実現する 2
 営利団体の事業者には 両方を同時に解くことが求められる ２つの要求を同時に満たすことが事業者として求められる（やりがいのある部分） 粒度間の統一性
 粒度ごとにそれぞれのステップが存在。 整合性を合わせて、理想を実現することが求められる 粒度
 メルカリのデータアナリストは この2つの要求を満たしながら 全てのステップで活動しています
25. 施策単位 [施策決め] ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Data Analyst’s Work Overview サービス単位 [方針決め] チーム単位 [方針決め] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし ▶ 仮説検証のための定量分析 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 ※実績と取り組み中のものを含む
26. 施策単位 [施策決め] ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Data Analyst’s Work Overview サービス単位 [方針決め] チーム単位 [方針決め] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 ※実績と取り組み中のものを含む サービスの成長を推進する組織として 必要な全stepにおいて活動
27. 施策単位 [機能・施策ぎめ] ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Data Analyst’s Work Overview サービス単位 [方針ぎめ] チーム単位 [方針ぎめ] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 ※実績と取り組み中のものを含む この中から、
 今日は実務的なサービス改善の事例を、
 データが活躍する部分を中心にお話します
28. ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 プロダクト改善に近い部分を中心にデータの活用方法を紹介します サービス単位 [方針決め] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 施策単位 [施策決め] チーム単位 [方針決め] Ⅰ. 問題の構造を理解する Ⅲ. 解決する問題を見極める Ⅱ. チームレベルの解決策 = 戦略 を導く Ⅳ. 解決策の筋の良さを見積もる
29. Copyright © Mercari, Inc. All Rights Reserved. Part 3 プロダクト改善したデータ分析の具体例 少数精鋭部隊が生み出すメルカリを加速させる超・実務データ分析 ▶ Part 2 プロダクトを改善するデータ分析の全体像 ▶ Part 3 プロダクトを改善したデータ分析の具体例 ▶ Part 1 メルカリのBIチームのデータ分析の考え方
30. 実際に行った改善ケースにそって
 超・実務なデータ分析の使い方の例をご紹介します

31. ※注 : ある程度のリアルさを残したまま、実際の情報・数字は丸めています 
 今日は1~2日出品割合の増加に取り組んだケースを例に説明 早く売れる・早く届くプラットフォームを目指して
32. 施策単位 [施策ぎめ] ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Part 1 サービス単位 [方針ぎめ] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 Ⅰ. 問題の構造を理解する ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 チーム単位 [方針ぎめ]
33. ~Ⅰ. チーム単位の問題仮説の構築・検証 〜 
 
 
 
 Goal : 「問題の構造を理解して、解ける問題を選ぶ」

34. Let’s start ! Please Imagine 状況 お題 「チームで継続率を上げることが決まりました」 「さあ継続率を上げて下さい」
35. この状態を写真で表すと 天の声 : 「さぁどうぞ。上げてください！」 継続率
36. この状態を写真で表すと 天の声 : 「さぁどうぞ。上げてください！」 継続率 まずは解ける問題に落とし込みましょう

37. 問題の構造化・選定フェーズでよく使う２つのアプローチ ？ 改善したい変数 影響ある変数 ~ 1. 影響のある変数の発見 ~ 解ける問題に変換していく必要がある ※ 相関・因果のある変数の特定 ~ 2. 指標の分解・構造化 ~ 改善したい変数 改善したい変数 ※ KPI分解・セグメント分解等
38. Case : 影響のある変数を発見する 「早く届けば届くほど、購入者の継続率が高まる」ことがデータから判明 ブレスト・UI・UT等日頃から蓄積されている仮説を洗い出す ひとつひとつデータで検証する 購入継続率と取引時間の関係 購 入 継 続 率 取引時間 ？ 改善したい変数 影響ある変数 ~ 1. 影響のある変数の発見 ~
39. Case : チームの指標を発見 その中でも購入 ~ 発送時間を解ける問題として選定 ★ Controlable インパクト/ 実現性共にある領域 出品者様 購入者様 出品 購入 到着 発送 商品確認 最終評価 購入 ~ 発送時間 発送 ~ 商品確認時間 確認 ~ 評価時間 Uncontrolable 配送業者 / 不在等 コントロールできない要素が多い領域 Few Potential インパクトの無い領域 ~ 指標の分解・構造化 ~ 改善したい変数 改善したい変数
40. 施策単位 [施策決め] ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Part 2 サービス単位 [方針ぎめ] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 Ⅱ. 解決策の方向性 = “戦略”を導く ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 チーム単位 [方針決め]
41. ~Ⅱ. チーム単位の解決策仮説の構築 ⇢ 検証 〜 Goal : 問題を解決する大枠の方針 = 「戦略」を持つこと
42. Step③のゴールは達成された。が... 状況 お題 問題 「購入~発送時間を縮めれば良いことが決まりました」 「さあ縮めてください」 「とはいえやり方っていっぱいあるよな ...」
43. この状況を表すと 「ど、どのつまみをどのくらいアゲれば ...」 KPIアゲアゲで 行こうYO！ どれを、 どれだけ？
44. この状況を表すと 「ど、どのつまみをどのくらいアゲれば ...」 KPIアゲアゲで 行こうYO！ どれを、 どれだけ？ 戦略を決めて、
 解決策の方針を絞りましょう

45. 何がどのくらい上がれば目標を達成できるのか？ 解決策選定フェーズでよく使う２つのアプローチ ~ インパクトの見積もり ~ 改善したい変数 ~ 実現可能性の見積もり ~ 問題を十分に解決 & 実現可能な戦略を持って、施策の効果を集中させる範囲を絞る Fact Fact Fact × × × 仮の数字 (意志) お客様のニーズを裏付ける行動データが存在するか ※ モデル化によるシミュレーション等 (仮の数値の部分を極小化し、なるべく Factで詰めていく ) ※ 需要を表す特定の行動をするお客様の割合・頻度の調査等
46. 発送まで日数 商品割合 平均取引時間 1~2 日 x1% ⇢ x1’% y1 2~3 日 x2% ⇢ x2’% y2 4~7 日 x3% ⇢ x3’% y3 何がどのくらい上がれば目標を達成できるのか？ Question : この戦略のポテンシャルは十分か？ ~ インパクトの見積もり ~ 改善したい変数 複数の候補から十分なインパクトを持つ戦略に絞っていく Fact Fact Fact × × × 仮の数字 (意志) <案> 1~2日発送商品を増やし取引時間を短縮する戦略はどうか？
 × × 「このくらいは改善するぞ！」（意志） データで取れる値はかき集める (実績) 取引時間削減 ポテンシャル 出品割合の 増減幅 xxx日発送 商品の割合 平均取引 時間 × × × × ※ モデル化によるシミュレーション等 (仮の数値の部分を極小化し、なるべく Factで詰めていく ) 1~2日発送の商品 
 2~3日発送の商品 
 4~7日発送の商品 
 取引時間： z ⇢ z’ 時間 継続率： A ⇢ A’% ※目標達成に十分な戦略かを確認する

47. Question : この戦略は受け入れられるのか？ ~ 実現可能性の見積もり ~ 出品・購入、どちらのお客様体験も向上する（受け入れられる）戦略に絞っていく お客様のニーズを裏付ける行動データが存在するか 1~2日発送商品 は売れやすい (購入者側の需要を表す ) 実は多くの商品が 設定日数より早めに 出品している (出品者側のチャンスも存在 ) 発送日数別の売れやすさの指標 24時間以内 での発送 <案> 1~2日発送商品を増やし取引時間を短縮する戦略はどうか？

48. ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Part3 サービス単位 [方針ぎめ] チーム単位 [方針決め] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 Ⅲ. 解決する問題を見極める ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 施策単位 [機能決め]
49. ~Ⅲ. 施策編・ 問題仮説の構築 ⇢ 検証 〜 Goal : 解決するお客様の問題を特定する
50. Step③のゴールは達成された。が... 状況 お題 問題 「1日~2日商品の割合を増やすと良さそうです」 「さぁ増やしましょう」 「ビジネス的な要求はわかったけど、 お客様のどんな課題を解決すればよいのだろうか？」
51. この状況を表すと ニーズなきところに改善なし 俺はやったるぜ！！ こんな平和な場所で 何を意気込んでいるのやら
52. この状況を表すと ニーズなきところに改善なし こんな平和な場所で 何を意気込んでいるの やら 俺はやったるぜ！！ お客様のニーズ・課題を大切にしましょう

53. 訂正情報から何を読み取れるか 問題の構造化・選定フェーズでよく使うアプローチ ~ 定性情報のプロセッシング ~ ~ 問題の大きさの比較 ~ 定性データで仮説を構築 ⇢ 定量データで問題の大きさを検証する お客様のニーズを裏付ける行動データが存在するか
54. お客様の課題リスト ・どうすれば早く売れるかを知りたい ・1~2日で出品にすると、急な用事や旅行等に対応できない ・コンビニだとゆっくり発送できない 訂正情報から何を読み取れるか Question : お客様はどんな課題を抱えているのか？ ~ 定性情報のプロセッシング ~ KJ法や独自の工夫を使い訂正情報も一手間かけて、お客様の課題を抽出していく ユーザーテスト・インタビュー・アンケート・ KJ法等
55. Question : その問題はどのくらいの大きさなのか？ ~ 問題の大きさの把握 ~ 定性情報等から得られた問題が、どのくらい実際に起こっているのかを定量化する インパクトの大きな問題を選定していく お客様のニーズを裏付ける行動データが存在するか Q.「早く売りたいけどどうすればよいかわからない」は大きな問題なのか？ ※ 満足度に影響を与えた体験のアンケート調査 A. 色々な体験の中、一番大きくプラスに作用し、 かつマイナスにも作用する体験であるので大きな問題である。 定性データの定量化 早く売れた経験
56. Question : その問題はどのくらいの大きさなのか？ ~ 問題の大きさの把握 ~ 定性情報等から得られた問題が、どのくらい実際に起こっているのかを定量化する インパクトの大きな問題を選定していく お客様のニーズを裏付ける行動データが存在するか 満足度別のある体験を経験する割合 機 能 を 使 う 割 合 定性データと行動ログとの突き合わせ A. アンケート結果と行動ログの整合性を確認。 　 ノイジー・マイノリティーではないことを確認する。
57. ▶ ABテストの設計と検証 
 ▶ 施策指標のアップ/ダウン影響調査 
 ▶ 施策の改善提案
 Part4 サービス単位 [方針決め] チーム単位 [方針決め] ▶ 目標KR(KPI)の設定 
 ▶ 提供したい体験・価値の明確化 
 ▶ 施策用ダッシュボード・可視化 
 (時系列/ファネル/コホート等) 
 ▶ ユーザテスト/インタビュー/アンケート等の定性情報から仮説出し 
 ▶ ダッシュボード・過去の定量情報から仮説出し 
 ▶ ⇢ 仮説の定量検証 
 ▶ チームKR(KPI)の提案 
 ▶ KR達成の戦略提案 
 ▶ チームダッシュボード 
 ▶ 計画予実の管理
 ▶ KJ法などでインサイト抽出 ▶ ⇢ 仮説の定量検証 
 ▶ ⇢ 施策前のポテンシャルの試算 ① 「何が理想なのか」 理想構築 ② 「現状どうなっているのか」 現状把握 ③ 「なぜ or どのような構造で 問題が起こってるのか」 問題仮説の構築 ⇢ 検証 ▶ サービスKR達成へ登り方の確認 
 ▶ サービスダッシュボード 
 ▶ 計画予実のモニタリング 
 ▶ 季節性や外部要因の把握 
 ▶ KPIの予知しない動きの検知/調査 
 ▶ UT/VOCから仮説構築⇢定量検証 
 ▶ マーケットシェアの調査 
 ▶ 戦略変更案の案だし (チーム経由) ▶ 仮説出しのための定量分析 
 ▶ KRのモニタリング ▶ KRラップアップ ▶ 方針変更提案 ▶ 仮説分解とMVPでの検証方法設計 
 ▶ ⇢ 施策が刺さるかの前分析 
 ▶ ⇢ 施策のポテンシャル試算 
 ▶ ブレスト・頭で考える ▶ 仮説出しのための可視化 
 Ⅳ. 解決策の筋の良さを見積もる ④ 「どうすれば解決するのか」 解決策仮説の構築 ⇢ 検証 ⑤ 「本当に解決したのか」 効果検証と解釈・ ネクストアクション決め 施策単位 [機能決め]
58. ~Ⅳ. 施策編・ 解決策仮説の構築 ⇢ 検証 〜 Goal : 具体的な施策を決める
59. Step③のゴールは達成された。が... 状況 お題 問題 「早く届くサービスを目指して、色々な施策を行いましょう」 「いよいよ施策を打ちましょう」 「施策の優先順位決めや、失敗した場合には？」
60. この状況を表すと 色々な可能性がある中、考えた施策をどんな順番で打てば良いか どの施策が 成功に近いのか 失敗した場合は どうすればいいのか
61. この状況を表すと 色々な可能性がある中、考えた施策をどんな順番で打てば良いか どの施策が 成功に近いのか 失敗した場合は どうすればいいのか インパクトと最小単位での検証方法を考え
 施策を出す順番を決めましょう

62. どのくらいの効果がありそうか？ 解決策の検証フェーズでよく使う２つのアプローチ ~ インパクトの見積もり ~ 改善したい変数 問題を十分に解決 & 実現可能な戦略を導き、施策の効果を集中させる範囲を絞る必要がある Fact Fact Fact × × × 仮の数字 (予想) 所望の結果が得られない時に何を変えるか ~最小検証・問題特定方法の設計 ~
63. どのくらいの効果がありそうか？ Question : その解決策はどのくらいのポテンシャルがあるのか？ ~ インパクトの見積もり ~ 改善したい変数 なるべくFactで詰め、施策の効果の予測をある程度の精度で試算する ⇢ 施策の優先順位付け Fact Fact Fact × × × 仮の数字 (予想) +α 1~2日商品の増分 ここはかなり細かい行動ログの数値を見て見積もる ※ 対象となるお客様数・似た機能の使用者数・その回数・その頻度等 × × × 仮の数字 (予想) お知らせ対象 お客様数 お知らせの 開封率 出品割合を 変える割合 出品割合の UP幅 +α × × × +α × × × +α × × × +α × × × 施策をインパクト順に並べて、優先順位をつける
64. Question : 所望の結果が得られなかったら何を変えるか？ ~最小検証・問題特定方法の設計 ~ 問題を十分に解決 & 実現可能な戦略を導き、施策の効果を集中させる範囲を絞る必要がある 所望の結果が得られない時に何を変えるか お知らせの 送信数 ①お知らせの 開封率 ② 読了率 ③ 行動が変化 する割合 ①が悪い時 ⇢ お知らせのタイトルを変える ②が悪い時 ⇢ 記事の内容を変える ③が悪い時 ⇢ 動線を変える ⇢ 目が出ない時は適宜Pivotする 1.まずはお知らせで仮説があたっているか反応をみる
 2. 反応が良ければ機能化する。悪い場合はtry&error
 反応が良いコンテンツが FIXしてから機能化
65. こうして生まれた施策の一部 早く売れる・早く届くプラットフォームへ成長
66. 結果
67. Result 5施策程で目標数値もほぼ達成
68. まとめ
69. 今日伝えたいこと（ひとこと） 「データ分析はプロダクト改善を飛躍的に強化するもの」 ※ 特別な「~アルゴリズム」のような難しい分析手法を使わずとも強化は可能 再掲
70. 1 2 難しいことをせずともデータを使って意思決定できる 手段の派手さよりも、目的を意識して分析することが重要 今日伝えたいこと（詳細） 3 メルカリのBIチームでの具体例 つまり「超・実務データ分析」 再掲
71. データを使う意義 ① 不確実性を低減 不確実性 不確実性 再掲
72. データを使う意義 ② アイデアを生み出す 再掲
73. 普段の業務 + Data = 強いプロダクト改善部隊 + Data で生まれ変わるかもしれません + Data
74. 最後に３つ宣伝させてください！
75. メルカリではデータアナリストを絶賛募集中です
76. BIチーム専属のデータエンジニアも募集しています
77. データを用いたプロダクトグロース討論会やってます 詳細はtwitter @_ _shoei_ _ まで！！ 第1回目 にして大盛況 2回目企画中