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

by shoei

Slide 1

Slide 1 text

Slide 2

Slide 2 text

今日の内容

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

自己紹介

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

メルカリの分析環境

Slide 10

Slide 10 text

・Google Slide  ・Wiki  ・Docs  ・Slack  ・etc    粒度・重要度に応じて <物理環境> 分析環境思想 : 「生データ全部BQに置いとくからあとはよろしく」 BigQuery Client log Transaction DB 各マイクロサービス ETL Query Data Document ・SpreadSheet  ・Python  ・Colaboratory  ・R  ・etc    データの加工ツールは個人の自由  Data Analyst

Slide 11

Slide 11 text

<組織環境> 分析組織の立ち位置各職能が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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

All We Need is 三重苦の退治

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

・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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

これからやること

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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