Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Analytics Engineeringチームを立ち上げて学んだこと

nagai shinya
June 27, 2024
1.6k

Analytics Engineeringチームを立ち上げて学んだこと

Data Engineering Study #24 データドリブン組織を支える技術
https://forkwell.connpass.com/event/320271/

nagai shinya

June 27, 2024
Tweet

Transcript

  1. 2 • 3つの取組みを通じて話します • こんな人に役立つ内容を目指しました ◦ 「社内でデータの活用は進んできたが、データ基盤の整備が追いついて ない。でも何とかしたい!」 本日のテーマ |

    「チーム立ち上げから3年間で学んだこと」 事例 テーマ レガシー化したdata pipelineの廃止 越境 ロードマップの作成とアライン 役割の確立 分析用中間テーブルの開発 堅牢さと速度
  2. 3 • 自身の役割 ◦ メルカリのAnalytics EngineeringチームのMGR • チームの役割 ◦ 分析用の中間テーブルの開発/管理/展開

    ◦ ダッシュボードやBIツールの開発/管理/展開 実際にはチームの役割にかなり変遷もあったが割愛 自己紹介
  3. 5 本番環境 → BigQuery → 利用 データ分析環境の大まかな構成 (2021年当時) 本番環境DB BigQuery

    From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS
  4. 6 本番環境 → BigQuery → 利用 データ分析環境の大まかな構成 (2021年当時) 本番環境DB BigQuery

    From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム 分析 : アナリストチーム ?
  5. 7 • どんなシステムだったのか? ◦ 本番環境からBigQueryへデータをloadするパイプライン • システムの課題 ◦ node.jsフルスクラッチという独特な構成 稼働開始が2015年

    ◦ メインの開発者が退職した後オーナーシップが不明瞭に ◦ 150名/dayの利用者。クリティカルな用途にも使用 • 組織の課題 ◦ みんな廃止した方が良いと思っていたが音頭を取れる人が居ない レガシー化したdata pipelineに多くの業務が依存 課題
  6. 8 自分が率先して廃止に動いてみた • 理由① 自分も困っていた ◦ 1人のアナリストとして、データ基盤の課題に困っていた ◦ なんとかしたかった •

    理由② やれそうな気がした ◦ エンジニアとしての経験とアナリストとしての経験があった ◦ 橋渡しができそうな気がした この時点ではAnalytics Engineeringのチームはまだなく、個人の越境としてレガシー data piplineの廃止に取り組みはじめた やったこと
  7. 9 • 基本方針 ◦ 新data pipelineへの統合(大元のソースは一緒→できるはず) • ハードル① 仕様の差異 ◦

    レガシーと新で出てくるKPIが若干違う ◦ 「レガシーの仕様ではないと不都合」という意見が上がっていた • ハードル② 移行の量 ◦ 仕様に問題なくても膨大な量のクエリ書き直しが必要 マイグレーションに向けた課題 課題
  8. 10 • BigQueryのへのアクセスログ(INFORMATION_SCHEMAなど)の分析 ◦ 具体的に誰がこのテーブルを使ってるのか分かる ◦ 誰にヒアリングすれば良いのか分かる • ヒアリング ◦

    なぜレガシーなKPIが必要なのか業務上の理由をヒアリング ◦ 聞いたことをそのまま実現するのではなく目的にさかのぼるため データ分析とヒアリング やったこと① | 現状の調査
  9. 11 [レガシー] スナップショット 時点までの キャンセル抜き • 移行のハードル ◦ 「レガシーのデータが良い」 →なぜなのか深堀りできてなかっ

    た • ヒアリングの結果 ◦ 予実管理上、過去実績の取扱高が 集計のたびに変化すると困る ◦ 着地見込みを立てて、投資をコン トロールすることが出来ない なぜレガシーの仕様が良いという部署があるのか? ヒアリング ① ② [キャンセル抜き] 集計するたびに減る (キャンセル分) 取引高
  10. 12 [キャンセル込み] • レガシーKPIを完全再現? ◦ キャンセルが発生した時刻という 新たなデータが必要 • 目的を達するにはKPIを再定義 ◦

    「スナップショット」が重要なので はなく、集計するたびに値が変わ らないことが重要。 ◦ キャンセル込み取扱高+別途キャ ンセル率を監視 ◦ 実装が段違いに楽 言われたことを実現するのではなく、目的を達せられるようにする シンプルなシステムにするためのポイント ① ② [キャンセル抜き] [レガシー] スナップショット 時点までの キャンセル抜き ③ 減る 減らない 減らない 取引高
  11. 13 • 新pipelineで集計可能な定義へ ◦ レガシーの廃止のため「キャンセ ル込み取扱高」に取扱高を再定 義。 ◦ 定義から変えることで、仕様の差 異が原因で移行できないハードル

    を解消。 KPIの再定義 やったこと② [キャンセル込み] ① ② [キャンセル抜き] [レガシー] スナップショット 時点までの キャンセル抜き ③ 取引高
  12. 17 背景 | なぜそんな事態に? • 2015年 ◦ 隣の島に座る人に「これ消そっか?」ですんだ(想像) • 2021年

    ◦ 会ったことも無い人がする知らない業務×150人分 のデータを消す業務 コミットメントの後退ではなく、会社の拡大で未知の業務が出現 → 隙間になる。
  13. 18 誰かが意思をもって越境する? 理想かも知れない流れ • 経営陣が新たな役割の必要性を認識 • 組織に新たなロールを定義 • 採用 •

    組織の隙間が埋まる 実際によくある事 なかなか理想通りいかない。 結果、誰かが役割を越境しないと問題は解決しな い → 功罪あり(後述) 打開策? you
  14. 19 • 2015年のメルカリ ◦ 前年10月にお客さまから 手数料を頂きはじめた ◦ つまり、それまで売上が無 かった。 ◦

    とにかくデータが見れるこ とが最優先 node.jsでdata pipelineを作った当時の判断は正しかった どんな構成であれ明日役立つ物を作った当時の判断は正しかった 振り返って思うこと 有価証券報告書 当時 優先すべきだったこと 「明日生き残れるか >>> 7年後までメンテしやすいシステムか」
  15. 20 • 起きたこと ◦ 「組織の隙間に落ちる課題」 ◦ 明日の生き残りをかけたフェーズからの事業成長 ◦ さけられない変化だったと思う •

    やったこと ◦ 越境する ◦ ① データ/ヒアリングによる現状把握 ◦ ② KPI再定義 ◦ ③ モニタリングとマイグレーション まとめ
  16. 21 Analytics Engineeringのチーム化 レガシー化したpipelineの廃止のその後 本番環境DB BigQuery From レガシーdata pipeline BigQuery

    From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム 分析 : アナリストチーム Analytics Engineering
  17. 23 今後1年で取り組むテーマをVP(役員)や横のMGRにレビューしてもらう • 対象 ◦ Analytics Engineeringチームの今後1年の取り組み • 頻度 ◦

    Qに1回 • 内容 ◦ 優先度、費用対効果などについても議論し、内容をブラッシュアップ → チームの方向性を横や上とアラインする取り組み ロードマップとアラインの取り組み
  18. 27 • 効果 ◦ サービスはみんなで作ってる ◦ サービスのある効果にどれくらいデータ基盤が貢献したか定量化は難しい • 費用 ◦

    人件費、BigQueryのコスト ◦ 費用は即時、明瞭に、定量的に、出てくる • 起きること ◦ 経営陣からみて費用は明瞭なのに効果が見えにくい存在になる 費用は明瞭に数字で出てくる、効果は間接的 背景 | 費用対効果の説明が難しい
  19. 28 データ基盤の改善はとても間接的で測りにくい 背景 | データ基盤の改善で「成果」を上げるには? お客さまに 良いサービスが 届く サービスを作る エンジニア/デザイナー

    サービスを考える PdM 意思決定を支援 アナリスト 良いデータ基盤で アナリストを支援 Analytics Engineer 「成果」 「成果」にいたる過程 収益が向上する 遠い...
  20. 29 • 過去の失敗 ◦ 「node.jsフルスクラッチメンテナ不在のdata piplineのリスクの肌感覚をどう VPに説明するか?」 → 説明が難しいことに対してコミュニケーションが消極的 だった

    → 難しいからこそ話すべきだった ◦ 生々しい面として、そのアラインがなければ人員が継続的に割り当てられない チームが取り組んでいることにしっかり納得感を得られていなかった 失敗談 | コミュニケーションに消極的だった
  21. 31 越境は尊いが人はいつか居なくなる • 越境した人の貢献が大きかったほど、その人 が抜けた後の穴も大きい • 正直何回も見た やるべきこと • 個人の越境ではなく組織としての役割の確

    立が出来てはじめて組織の隙間は埋まる • では役割の確立とはなにか 個人に依存した取り組みは持続性が弱い 越境の功罪 you
  22. 32 役割の確立 • 組織図に名前が載れば確立? → No 周囲とのアライン • 他の組織との協力がなければ社外まで届く 成果を出すことはできない

    • 他のチームやVPから役割を期待され、それ に応えている状態になってはじめて役割とし ての確立 • ロードマップのアラインはその過程 周囲からの期待+そこに応えられているか 役割の確立 team
  23. 34 • 工夫した点 ◦ 一気に幅広いチームに聞く ▪ 18チームにヒアリング ◦ 1チームにだけ聞くと優先度が高いのかど うか判断がつかない

    • 見えてきた課題 ◦ テーブルが複雑でSQLを書くのが大変 レガシー化したdata pipelineは廃止できた。次の課題は? → 社内ヒアリング 背景 | データ基盤の課題ヒアリング
  24. 35 • 分析の結果 ◦ 頻繁に使われているテーブルは50程度 ◦ 上位には「出品」「購入」などのUX上もビジ ネス上も重要なテーブルが来る • ポイントをおさえた改善

    ◦ 重要なデータを集中して中間テーブル化 ◦ BigQueryのログを分析することでどの テーブル同士がjoinされやすいか分析 良く使われているテーブルから整備 解決策 | 集計を効率化する中間テーブル
  25. 36 振り返り | スピードと堅牢さのバランスを取れてなかった 「明日生き残れるか vs N年後までメンテしやすいシステムか」 • 堅牢さを重視しすぎた ◦

    これまで開発した中間テーブルで処理内容にミスがあって修正した記憶がない ◦ 品質重視でしっかり作った その分時間がかかっていた • エラーバジェット的な発想が必要だった ◦ 年間X件まではインシデントを許容、その範囲でできるだけスピードを出す ◦ 以下を0 or 100で考えるのではなくバランスで考える
  26. 38 • やったこと ◦ レガシーの廃止・やる事のアライン・中間テーブルの開発 • 学んだこと ◦ 組織には隙間があく。成長する以上避けられない ◦

    越境は尊いが人はいつか居なくなる ◦ 役割を作って穴を埋めることが必要 ▪ 周囲から期待されること、それに応えることで役割が確立していく Analytics Engineeringチームでやったこと学んだこと