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

Transcript

1. Copyright © Mercari, Inc. All Rights Reserved.
   大規模サービス開発における
   データ運用の傾向と対策
   大規模ゆえの三重苦とその対策について
   Shoei@Mercari | Data Analyst Manager
   

   View Slide

2. 今日の内容
   

   View Slide

3. 今日の話し
   運用
   データ環境
   組織・文化
   分析
   今日は分析を支えるレイヤーの話
   分析の話はこちらへ
   「少数精鋭部隊が生み出す メルカリを加速させる超・実務データ分析」
   

   View Slide

4. 大規模サービスのデータ三重苦
   広い・重い・混沌
   WIDE Time Consuming Chaos
   

   View Slide

5. 自己紹介
   

   View Slide

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
   ・サービス企画・分析からエンジニアリング
   ・プレイヤーからマネジメントまで
   

   View Slide

7. データ・アナリティクスで担保する分野
   

   View Slide

8. データ・アナリティクスが活躍する３つの領域
   現在・未来・過去
   お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案
   

   View Slide

9. メルカリの分析環境
   

   View Slide

10. ・Google Slide

    ・Wiki

    ・Docs

    ・Slack

    ・etc

    

    粒度・重要度に応じて
    分析環境
    思想 : 「生データ全部BQに置いとくからあとはよろしく」
    BigQuery
    Client log Transaction DB
    各マイクロサービス
    ETL
    Query
    Data
    Document
    ・SpreadSheet

    ・Python

    ・Colaboratory

    ・R

    ・etc

    

    データの加工ツールは個人の自由

    Data Analyst
    

    View Slide

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
    

    View Slide

12. データアナリストのデータに対する考え方
    意思決定の目的有りきでデータを活用する
    成長戦略
    重点項目決定
    機能開発
    クーポン配信
    目的先行型 + Data な考え方
 データ先行型な考え方
    + Data
    + Data
    + Data
    + Data
    「このデータ、何かに活用できないだろうか」
    データ処理を頑張る
    出口を探して活用
    

    View Slide

13. どこに三重苦が生まれるか？
    

    View Slide

14. 大規模サービスのデータ三重苦
    広い・重い・混沌
    WIDE Time Consuming Chaos
    

    View Slide

15. データ・アナリティクスが活躍する３つの領域
    現在・未来・過去
    お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案
    

    View Slide

16. 大規模サービスのデータ三重苦の出現場所
    広いゆえに見落とす
    「あれ? その指標xxチームが見てるんじゃな
    いの？」
    お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案
    理
    想
    苦
    現
    実
    重いゆえに遅い
    「セグメント切って分析したいけど集計重
    い...」
    混沌ゆえに漏れる
    「えっログ埋め込まないでリリースしてたっ
    て？えっ」
    

    View Slide

17. All We Need is 三重苦の退治
    

    View Slide

18. 実施した(ている)こと３つをご紹介
    広いゆえに見落とす
    「あれ? その指標xxチームが見てるんじゃな
    いの？」
    お客様の行動・事業進捗の把握 UXプランニング・効果予測 施策の効果分析・Pivot提案
    理
    想
    苦
    現
    実
    重いゆえに遅い
    「セグメント切って分析したいけど集計重
    い...」
    混沌ゆえに漏れる
    「えっログ埋め込まないでリリースしてたっ
    て？えっ」
    ① 横断モニタリング ② 誰でも中間テーブル ③ テスト設計FMT
    

    View Slide

19. ① 横断モニタリングPRJ
    森の中からの脱出⇢人工衛星から森を見る世界へ
    

    View Slide

20. ・チーム毎のダッシュボードの指標や構成などが独自設計
    ・イベントレベルでの行動モニタリングが行われてなかった
    問題 : 広いゆえに見落としてしまうこと
    KGIを各KPIにMECEに分解して全体を(完璧には)モニタリングできていなかった
    組織
    構造
    分析
    環境
    ・全社を横断的にモニタリングする組織の不在 (異常検知への対応)
    　(各チームのデータアナリスト・ PdMが自発的に見ていた )
    

    View Slide

21. 問題 : 広いゆえに見落としていた事
    KGIを各KPIにMECEに分解して全体を(完璧には)モニタリングしていなかった
    組織構造 分析環境
    

    View Slide

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さん
    

    View Slide

23. 「横断モニタリングPRJ」ご紹介 (一部)
    Confidential
    口頭で説明します
    

    View Slide

24. イベントレベルまで詳細なモニタリングダッシュボードを0から作成
    横断モニタリングPRJ
    KGIを各KPIにMECEに分解してサービス全体をモニタリングすることに
    組織
    対策
    環境
    対策
    アナリストチーム内に、横断的にモニタリングするチームを組成
    追えていなかった数字が見え、新たな問題に築けた。(構築中から既に効果あり)
    効果
    管制塔のように、ディスプレイをオフィス内に並べ事業・顧客体験の数値理解を普及する
    今後
    (構想)
    

    View Slide

25. ② 誰でも中間テーブル
    アナリストが自由にテーブルへ作れる時代へ
    

    View Slide

26. 独自のセグメント定義の秘伝のタレ的なwith句・クエリが各チームで管理・運用されていた
    重いゆえに遅くなっていたこと
    チーム独自に行動ベースのセグメントを持っているが、毎回集計していてスピード感が出ていなかった
    要件
    環境
    メルカリでは各チームに目的特化の最適な独自セグメントが存在 (これは守りたい)
    出品機能強化用セグメント・購入機能強化用セグメント・CRM用セグメント
    

    View Slide

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
    

    View Slide

28. オンボーディング資料を作り、ハンズオンを実施
    誰でも中間テーブル
    SQLを書けば毎日中間テーブルが生成・更新されるように
    対策
    普及
    活動
    Airflow(Google Composer)を立て、中間テーブルが生成されるスクリプトをテンプレ化
    各チームでセグメント資料とデータセットが作られ、分析粒度の詳細化・透明性が向上 (gitでクエリ確認)
    (90程のDAG ≒ 中間テーブルが生成されている)
    効果
    

    View Slide

29. 「誰でも中間テーブル」の紹介
    口頭説明
    社内で実施したオンボーディングスライド の紹介
    

    View Slide

30. ③ 分析設計の開発フロー組み込み
    明示的な開発の一部化
    

    View Slide

31. テスト設計 / ログ設計が属人化していて、観点のばらつきが存在していた
    混沌ゆえに漏れていたところ
    重要なところだけテスト設計やログ設計やればいいでしょ ⇢ 施策だして重要だと気づくパターンも有る
    従来
    環境
    重要だと思う施策のみ、 PdMの判断でBIにテスト設計・ログ設計を確認していた
    

    View Slide

32. 誰でも中間テーブル
    SQLを書けば毎日中間テーブルが生成・更新されるように
    対策
    ・開発フローにテスト設計・ログレビューを必須として組み込み (Project Specに明記)
    ・テスト設計のフォーマットを用意
    ・BI内で数値変動仮説と検証方法をでダブルチェック
    On Going
    効果
    

    View Slide

33. 効果検証フォーマットの紹介 (一部・ドラフト)
    sorry secret
    sorry secret
    sorry
    secret
    Project Spec にReview項目を追加
    Review Formatを定義
    

    View Slide

34. これからやること
    

    View Slide

35. これからのデータ周りの課題について
    ・データQA : 中間テーブルと元テーブルの数値があっているかの自動テスト
    ・体系的な分析用中間テーブル(データマート)の充実化
    ・ログ定義情報の可視化とガバナンス
    ・異常検知の自動化
    ….
    是非、みなさんの課題と構想を教えて下さい
    やれることはまだまだあると認識しています (きっと行きている限り永遠に )
    

    View Slide

36. 懇親会へ向けて
    みなさま、各社どんな 課題がありますか？
    非常に興味があります。
    是非データ活用(基盤周り・分析周り含む )でお困りの方、お気軽に情報交換しましょう！
    

    View Slide

37. 採用、めっちゃやってます。興味あるかたは気軽に声かけて下さい
    

    View Slide