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

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

Transcript

1. 1 2024/06/27 Nagai Shinya (@_ _hiza_ _) Analytics Engineeringチームを 立ち上げて学んだこと
2. 2 • 3つの取組みを通じて話します • こんな人に役立つ内容を目指しました ◦ ｢社内でデータの活用は進んできたが、データ基盤の整備が追いついて ない。でも何とかしたい!｣ 本日のテーマ | ｢チーム立ち上げから3年間で学んだこと｣ 事例 テーマ レガシー化したdata pipelineの廃止 越境 ロードマップの作成とアライン 役割の確立 分析用中間テーブルの開発 堅牢さと速度
3. 3 • 自身の役割 ◦ メルカリのAnalytics EngineeringチームのMGR • チームの役割 ◦ 分析用の中間テーブルの開発/管理/展開 ◦ ダッシュボードやBIツールの開発/管理/展開 実際にはチームの役割にかなり変遷もあったが割愛 自己紹介
4. 4 レガシー化したdata pipelineの廃止
5. 5 本番環境 → BigQuery → 利用 データ分析環境の大まかな構成 (2021年当時) 本番環境DB BigQuery From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS
6. 6 本番環境 → BigQuery → 利用 データ分析環境の大まかな構成 (2021年当時) 本番環境DB BigQuery From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム 分析 : アナリストチーム ?
7. 7 • どんなシステムだったのか? ◦ 本番環境からBigQueryへデータをloadするパイプライン • システムの課題 ◦ node.jsフルスクラッチという独特な構成 稼働開始が2015年 ◦ メインの開発者が退職した後オーナーシップが不明瞭に ◦ 150名/dayの利用者。クリティカルな用途にも使用 • 組織の課題 ◦ みんな廃止した方が良いと思っていたが音頭を取れる人が居ない レガシー化したdata pipelineに多くの業務が依存 課題
8. 8 自分が率先して廃止に動いてみた • 理由① 自分も困っていた ◦ 1人のアナリストとして、データ基盤の課題に困っていた ◦ なんとかしたかった • 理由② やれそうな気がした ◦ エンジニアとしての経験とアナリストとしての経験があった ◦ 橋渡しができそうな気がした この時点ではAnalytics Engineeringのチームはまだなく、個人の越境としてレガシー data piplineの廃止に取り組みはじめた やったこと
9. 9 • 基本方針 ◦ 新data pipelineへの統合(大元のソースは一緒→できるはず) • ハードル① 仕様の差異 ◦ レガシーと新で出てくるKPIが若干違う ◦ ｢レガシーの仕様ではないと不都合｣という意見が上がっていた • ハードル② 移行の量 ◦ 仕様に問題なくても膨大な量のクエリ書き直しが必要 マイグレーションに向けた課題 課題
10. 10 • BigQueryのへのアクセスログ(INFORMATION_SCHEMAなど)の分析 ◦ 具体的に誰がこのテーブルを使ってるのか分かる ◦ 誰にヒアリングすれば良いのか分かる • ヒアリング ◦ なぜレガシーなKPIが必要なのか業務上の理由をヒアリング ◦ 聞いたことをそのまま実現するのではなく目的にさかのぼるため データ分析とヒアリング やったこと① | 現状の調査
11. 11 [レガシー] スナップショット 時点までの キャンセル抜き • 移行のハードル ◦ ｢レガシーのデータが良い｣ →なぜなのか深堀りできてなかっ た • ヒアリングの結果 ◦ 予実管理上、過去実績の取扱高が 集計のたびに変化すると困る ◦ 着地見込みを立てて、投資をコン トロールすることが出来ない なぜレガシーの仕様が良いという部署があるのか? ヒアリング ① ② [キャンセル抜き] 集計するたびに減る (キャンセル分) 取引高
12. 12 [キャンセル込み] • レガシーKPIを完全再現? ◦ キャンセルが発生した時刻という 新たなデータが必要 • 目的を達するにはKPIを再定義 ◦ ｢スナップショット｣が重要なので はなく、集計するたびに値が変わ らないことが重要。 ◦ キャンセル込み取扱高+別途キャ ンセル率を監視 ◦ 実装が段違いに楽 言われたことを実現するのではなく、目的を達せられるようにする シンプルなシステムにするためのポイント ① ② [キャンセル抜き] [レガシー] スナップショット 時点までの キャンセル抜き ③ 減る 減らない 減らない 取引高
13. 13 • 新pipelineで集計可能な定義へ ◦ レガシーの廃止のため｢キャンセ ル込み取扱高｣に取扱高を再定 義。 ◦ 定義から変えることで、仕様の差 異が原因で移行できないハードル を解消。 KPIの再定義 やったこと② [キャンセル込み] ① ② [キャンセル抜き] [レガシー] スナップショット 時点までの キャンセル抜き ③ 取引高
14. 14 • 量の問題 ◦ 仕様上問題なくてもクエリを書き換える量の問題がある。 • マニュアルを展開、レガシーへのアクセスをモニタリング ◦ 最終的に利用者ほぼゼロへ アクセスログのモニタリングと移行 やったこと③
15. 15 なぜレガシー化は起きたのか
16. 16 • アナリストだけの仕事でもない • エンジニアだけの仕事でもない 会社のフェーズの変化 → 組織間の隙間に落ちた業務 背景 | なぜそんな事態に? 技術の創造と設計
17. 17 背景 | なぜそんな事態に? • 2015年 ◦ 隣の島に座る人に「これ消そっか?」ですんだ(想像) • 2021年 ◦ 会ったことも無い人がする知らない業務×150人分 のデータを消す業務 コミットメントの後退ではなく、会社の拡大で未知の業務が出現 → 隙間になる。
18. 18 誰かが意思をもって越境する? 理想かも知れない流れ • 経営陣が新たな役割の必要性を認識 • 組織に新たなロールを定義 • 採用 • 組織の隙間が埋まる 実際によくある事 なかなか理想通りいかない。 結果、誰かが役割を越境しないと問題は解決しな い → 功罪あり(後述) 打開策? you
19. 19 • 2015年のメルカリ ◦ 前年10月にお客さまから 手数料を頂きはじめた ◦ つまり、それまで売上が無 かった。 ◦ とにかくデータが見れるこ とが最優先 node.jsでdata pipelineを作った当時の判断は正しかった どんな構成であれ明日役立つ物を作った当時の判断は正しかった 振り返って思うこと 有価証券報告書 当時 優先すべきだったこと 「明日生き残れるか >>> 7年後までメンテしやすいシステムか」
20. 20 • 起きたこと ◦ 「組織の隙間に落ちる課題」 ◦ 明日の生き残りをかけたフェーズからの事業成長 ◦ さけられない変化だったと思う • やったこと ◦ 越境する ◦ ① データ/ヒアリングによる現状把握 ◦ ② KPI再定義 ◦ ③ モニタリングとマイグレーション まとめ
21. 21 Analytics Engineeringのチーム化 レガシー化したpipelineの廃止のその後 本番環境DB BigQuery From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム 分析 : アナリストチーム Analytics Engineering
22. 22 ロードマップの作成とアライン
23. 23 今後1年で取り組むテーマをVP(役員)や横のMGRにレビューしてもらう • 対象 ◦ Analytics Engineeringチームの今後1年の取り組み • 頻度 ◦ Qに1回 • 内容 ◦ 優先度、費用対効果などについても議論し、内容をブラッシュアップ → チームの方向性を横や上とアラインする取り組み ロードマップとアラインの取り組み
24. 24 ロードマップの例① | チームの位置づけ、注力領域
25. 25 ロードマップの例② | 四半期ごとの取り組みテーマ
26. 26 ロードマップの例③ | 個別PJの振り返り、今後の計画 前Qまでの取り組み 定量的な評価 PJの今後の評価基準
27. 27 • 効果 ◦ サービスはみんなで作ってる ◦ サービスのある効果にどれくらいデータ基盤が貢献したか定量化は難しい • 費用 ◦ 人件費、BigQueryのコスト ◦ 費用は即時、明瞭に、定量的に、出てくる • 起きること ◦ 経営陣からみて費用は明瞭なのに効果が見えにくい存在になる 費用は明瞭に数字で出てくる、効果は間接的 背景 | 費用対効果の説明が難しい
28. 28 データ基盤の改善はとても間接的で測りにくい 背景 | データ基盤の改善で「成果」を上げるには? お客さまに 良いサービスが 届く サービスを作る エンジニア/デザイナー サービスを考える PdM 意思決定を支援 アナリスト 良いデータ基盤で アナリストを支援 Analytics Engineer 「成果」 「成果」にいたる過程 収益が向上する 遠い...
29. 29 • 過去の失敗 ◦ ｢node.jsフルスクラッチメンテナ不在のdata piplineのリスクの肌感覚をどう VPに説明するか?｣ → 説明が難しいことに対してコミュニケーションが消極的 だった → 難しいからこそ話すべきだった ◦ 生々しい面として、そのアラインがなければ人員が継続的に割り当てられない チームが取り組んでいることにしっかり納得感を得られていなかった 失敗談 | コミュニケーションに消極的だった
30. 30 「越境」について
31. 31 越境は尊いが人はいつか居なくなる • 越境した人の貢献が大きかったほど、その人 が抜けた後の穴も大きい • 正直何回も見た やるべきこと • 個人の越境ではなく組織としての役割の確 立が出来てはじめて組織の隙間は埋まる • では役割の確立とはなにか 個人に依存した取り組みは持続性が弱い 越境の功罪 you
32. 32 役割の確立 • 組織図に名前が載れば確立? → No 周囲とのアライン • 他の組織との協力がなければ社外まで届く 成果を出すことはできない • 他のチームやVPから役割を期待され、それ に応えている状態になってはじめて役割とし ての確立 • ロードマップのアラインはその過程 周囲からの期待+そこに応えられているか 役割の確立 team
33. 33 中間テーブルの開発
34. 34 • 工夫した点 ◦ 一気に幅広いチームに聞く ▪ 18チームにヒアリング ◦ 1チームにだけ聞くと優先度が高いのかど うか判断がつかない • 見えてきた課題 ◦ テーブルが複雑でSQLを書くのが大変 レガシー化したdata pipelineは廃止できた。次の課題は? → 社内ヒアリング 背景 | データ基盤の課題ヒアリング
35. 35 • 分析の結果 ◦ 頻繁に使われているテーブルは50程度 ◦ 上位には「出品」「購入」などのUX上もビジ ネス上も重要なテーブルが来る • ポイントをおさえた改善 ◦ 重要なデータを集中して中間テーブル化 ◦ BigQueryのログを分析することでどの テーブル同士がjoinされやすいか分析 良く使われているテーブルから整備 解決策 | 集計を効率化する中間テーブル
36. 36 振り返り | スピードと堅牢さのバランスを取れてなかった 「明日生き残れるか vs N年後までメンテしやすいシステムか」 • 堅牢さを重視しすぎた ◦ これまで開発した中間テーブルで処理内容にミスがあって修正した記憶がない ◦ 品質重視でしっかり作った その分時間がかかっていた • エラーバジェット的な発想が必要だった ◦ 年間X件まではインシデントを許容、その範囲でできるだけスピードを出す ◦ 以下を0 or 100で考えるのではなくバランスで考える
37. 37 まとめ
38. 38 • やったこと ◦ レガシーの廃止・やる事のアライン・中間テーブルの開発 • 学んだこと ◦ 組織には隙間があく。成長する以上避けられない ◦ 越境は尊いが人はいつか居なくなる ◦ 役割を作って穴を埋めることが必要 ▪ 周囲から期待されること、それに応えることで役割が確立していく Analytics Engineeringチームでやったこと学んだこと