大規模サービス開発におけるデータ運用の傾向と対策

Transcript

1. Copyright © Mercari, Inc. All Rights Reserved. 大規模サービス開発における データ運用の傾向と対策 大規模ゆえの三重苦とその対策について Shoei@Mercari | Data Analyst Manager
2. 今日の内容
3. 今日の話し 運用 データ環境 組織・文化 分析 今日は分析を支えるレイヤーの話 分析の話はこちらへ 「少数精鋭部隊が生み出す メルカリを加速させる超・実務データ分析」
4. 大規模サービスのデータ三重苦 広い・重い・混沌 WIDE Time Consuming Chaos
5. 自己紹介
6. Self Introduction Ishida Shoei (twitter : @_ _shoei_ _) Data Analyst | 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 ・サービス企画・分析からエンジニアリング ・プレイヤーからマネジメントまで
7. データ・アナリティクスで担保する分野
8. データ・アナリティクスが活躍する３つの領域 現在・未来・過去 お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案
9. メルカリの分析環境
10. ・Google Slide
 ・Wiki
 ・Docs
 ・Slack
 ・etc
 
 粒度・重要度に応じて <物理環境> 分析環境 思想 : 「生データ全部BQに置いとくからあとはよろしく」 BigQuery Client log Transaction DB 各マイクロサービス ETL Query Data Document ・SpreadSheet
 ・Python
 ・Colaboratory
 ・R
 ・etc
 
 データの加工ツールは個人の自由
 Data Analyst
11. <組織環境> 分析組織の立ち位置 各職能がTeamにアサイン。TeamによってPlanning重視or効果分析重視か、各種重点項目は異なる Engineer Backend / iOS / Android / QA 売上あげるTeam Designer Product Manager 出品者増やすTeam Analyst Xさん Aさん Hさん Oさん Yさん Bさん Iさん Pさん Zさん Cさん Jさん Qさん 横断的なUX改善Team
12. <思想> データアナリストのデータに対する考え方 意思決定の目的有りきでデータを活用する 成長戦略 重点項目決定 機能開発 クーポン配信 目的先行型 + Data な考え方
 データ先行型な考え方 + Data + Data + Data + Data 「このデータ、何かに活用できないだろうか」 データ処理を頑張る 出口を探して活用
13. どこに三重苦が生まれるか？
14. 大規模サービスのデータ三重苦 広い・重い・混沌 WIDE Time Consuming Chaos
15. データ・アナリティクスが活躍する３つの領域 現在・未来・過去 お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案
16. 大規模サービスのデータ三重苦の出現場所 広いゆえに見落とす 「あれ? その指標xxチームが見てるんじゃな いの？」 お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案 理 想 苦 現 実 重いゆえに遅い 「セグメント切って分析したいけど集計重 い...」 混沌ゆえに漏れる 「えっログ埋め込まないでリリースしてたっ て？えっ」
17. All We Need is 三重苦の退治
18. 実施した(ている)こと３つをご紹介 広いゆえに見落とす 「あれ? その指標xxチームが見てるんじゃな いの？」 お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案 理 想 苦 現 実 重いゆえに遅い 「セグメント切って分析したいけど集計重 い...」 混沌ゆえに漏れる 「えっログ埋め込まないでリリースしてたっ て？えっ」 ① 横断モニタリング ② 誰でも中間テーブル ③ テスト設計FMT
19. ① 横断モニタリングPRJ 森の中からの脱出⇢人工衛星から森を見る世界へ
20. ・チーム毎のダッシュボードの指標や構成などが独自設計 ・イベントレベルでの行動モニタリングが行われてなかった 問題 : 広いゆえに見落としてしまうこと KGIを各KPIにMECEに分解して全体を(完璧には)モニタリングできていなかった 組織 構造 分析 環境 ・全社を横断的にモニタリングする組織の不在 (異常検知への対応) 　(各チームのデータアナリスト・ PdMが自発的に見ていた )
21. 問題 : 広いゆえに見落としていた事 KGIを各KPIにMECEに分解して全体を(完璧には)モニタリングしていなかった 組織構造 分析環境
22. KPIが抜け落ちる原因 組織は重点項目毎に切られる ≠ KGIのMECE分解 Engineer Backend / iOS / Android / QA 売上あげるTeam Designer Product Manager 出品者増やすTeam Analyst Xさん Aさん Hさん Oさん Yさん Bさん Iさん Pさん Zさん Cさん Jさん Qさん 横断的なUX改善Team え！ XX(指標)ってYY(チーム)がみてるんじゃないの！？ Aさん
23. 「横断モニタリングPRJ」ご紹介 (一部) Confidential 口頭で説明します
24. イベントレベルまで詳細なモニタリングダッシュボードを0から作成 横断モニタリングPRJ KGIを各KPIにMECEに分解してサービス全体をモニタリングすることに 組織 対策 環境 対策 アナリストチーム内に、横断的にモニタリングするチームを組成 追えていなかった数字が見え、新たな問題に築けた。(構築中から既に効果あり) 効果 管制塔のように、ディスプレイをオフィス内に並べ事業・顧客体験の数値理解を普及する 今後 (構想)
25. ② 誰でも中間テーブル アナリストが自由にテーブルへ作れる時代へ
26. 独自のセグメント定義の秘伝のタレ的なwith句・クエリが各チームで管理・運用されていた 重いゆえに遅くなっていたこと チーム独自に行動ベースのセグメントを持っているが、毎回集計していてスピード感が出ていなかった 要件 環境 メルカリでは各チームに目的特化の最適な独自セグメントが存在 (これは守りたい) 出品機能強化用セグメント・購入機能強化用セグメント・CRM用セグメント
27. ・Google Slide
 ・Wiki
 ・Docs
 ・Slack
 ・etc
 
 粒度・重要度に応じて 誰でも中間テーブル 思想 : 「SQL書いたら誰でも中間テーブル作れるよ」 BigQuery Client log Transaction DB 各マイクロサービス ETL Query Data Document ・SpreadSheet
 ・Python
 ・Colaboratory
 ・R
 ・etc
 
 データの加工ツールは個人の自由
 Data Analyst 中間テーブル Query Data
28. オンボーディング資料を作り、ハンズオンを実施 誰でも中間テーブル SQLを書けば毎日中間テーブルが生成・更新されるように 対策 普及 活動 Airflow(Google Composer)を立て、中間テーブルが生成されるスクリプトをテンプレ化 各チームでセグメント資料とデータセットが作られ、分析粒度の詳細化・透明性が向上 (gitでクエリ確認) (90程のDAG ≒ 中間テーブルが生成されている) 効果
29. 「誰でも中間テーブル」の紹介 口頭説明 社内で実施したオンボーディングスライド の紹介
30. ③ 分析設計の開発フロー組み込み 明示的な開発の一部化
31. テスト設計 / ログ設計が属人化していて、観点のばらつきが存在していた 混沌ゆえに漏れていたところ 重要なところだけテスト設計やログ設計やればいいでしょ ⇢ 施策だして重要だと気づくパターンも有る 従来 環境 重要だと思う施策のみ、 PdMの判断でBIにテスト設計・ログ設計を確認していた
32. 誰でも中間テーブル SQLを書けば毎日中間テーブルが生成・更新されるように 対策 ・開発フローにテスト設計・ログレビューを必須として組み込み (Project Specに明記) ・テスト設計のフォーマットを用意 ・BI内で数値変動仮説と検証方法をでダブルチェック On Going 効果
33. 効果検証フォーマットの紹介 (一部・ドラフト) sorry secret sorry secret sorry secret Project Spec にReview項目を追加 Review Formatを定義
34. これからやること
35. これからのデータ周りの課題について ・データQA : 中間テーブルと元テーブルの数値があっているかの自動テスト ・体系的な分析用中間テーブル(データマート)の充実化 ・ログ定義情報の可視化とガバナンス ・異常検知の自動化 …. 是非、みなさんの課題と構想を教えて下さい やれることはまだまだあると認識しています (きっと行きている限り永遠に )
36. 懇親会へ向けて みなさま、各社どんな 課題がありますか？ 非常に興味があります。 是非データ活用(基盤周り・分析周り含む )でお困りの方、お気軽に情報交換しましょう！
37. 採用、めっちゃやってます。興味あるかたは気軽に声かけて下さい