Analytics Engineeringチームを立ち上げて学んだこと

by nagai shinya

Slide 1

Slide 1 text

1 2024/06/27 Nagai Shinya (@_ _hiza_ _) Analytics Engineeringチームを立ち上げて学んだこと

Slide 2

Slide 2 text

2 ● 3つの取組みを通じて話します ● こんな人に役立つ内容を目指しました ○ ｢社内でデータの活用は進んできたが、データ基盤の整備が追いついてない。でも何とかしたい!｣本日のテーマ | ｢チーム立ち上げから3年間で学んだこと｣事例テーマレガシー化したdata pipelineの廃止越境ロードマップの作成とアライン役割の確立分析用中間テーブルの開発堅牢さと速度

Slide 3

Slide 3 text

3 ● 自身の役割 ○ メルカリのAnalytics EngineeringチームのMGR ● チームの役割 ○ 分析用の中間テーブルの開発/管理/展開 ○ ダッシュボードやBIツールの開発/管理/展開実際にはチームの役割にかなり変遷もあったが割愛自己紹介

Slide 4

Slide 4 text

4 レガシー化したdata pipelineの廃止

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

7 ● どんなシステムだったのか? ○ 本番環境からBigQueryへデータをloadするパイプライン ● システムの課題 ○ node.jsフルスクラッチという独特な構成稼働開始が2015年 ○ メインの開発者が退職した後オーナーシップが不明瞭に ○ 150名/dayの利用者。クリティカルな用途にも使用 ● 組織の課題 ○ みんな廃止した方が良いと思っていたが音頭を取れる人が居ないレガシー化したdata pipelineに多くの業務が依存課題

Slide 8

Slide 8 text

8 自分が率先して廃止に動いてみた ● 理由① 自分も困っていた ○ 1人のアナリストとして、データ基盤の課題に困っていた ○ なんとかしたかった ● 理由② やれそうな気がした ○ エンジニアとしての経験とアナリストとしての経験があった ○ 橋渡しができそうな気がしたこの時点ではAnalytics Engineeringのチームはまだなく、個人の越境としてレガシー data piplineの廃止に取り組みはじめたやったこと

Slide 9

Slide 9 text

9 ● 基本方針 ○ 新data pipelineへの統合(大元のソースは一緒→できるはず) ● ハードル① 仕様の差異 ○ レガシーと新で出てくるKPIが若干違う ○ ｢レガシーの仕様ではないと不都合｣という意見が上がっていた ● ハードル② 移行の量 ○ 仕様に問題なくても膨大な量のクエリ書き直しが必要マイグレーションに向けた課題課題

Slide 10

Slide 10 text

10 ● BigQueryのへのアクセスログ(INFORMATION_SCHEMAなど)の分析 ○ 具体的に誰がこのテーブルを使ってるのか分かる ○ 誰にヒアリングすれば良いのか分かる ● ヒアリング ○ なぜレガシーなKPIが必要なのか業務上の理由をヒアリング ○ 聞いたことをそのまま実現するのではなく目的にさかのぼるためデータ分析とヒアリングやったこと① | 現状の調査

Slide 11

Slide 11 text

11 [レガシー] スナップショット時点までのキャンセル抜き ● 移行のハードル ○ ｢レガシーのデータが良い｣ →なぜなのか深堀りできてなかった ● ヒアリングの結果 ○ 予実管理上、過去実績の取扱高が集計のたびに変化すると困る ○ 着地見込みを立てて、投資をコントロールすることが出来ないなぜレガシーの仕様が良いという部署があるのか? ヒアリング ① ② [キャンセル抜き] 集計するたびに減る (キャンセル分) 取引高

Slide 12

Slide 12 text

12 [キャンセル込み] ● レガシーKPIを完全再現? ○ キャンセルが発生した時刻という新たなデータが必要 ● 目的を達するにはKPIを再定義 ○ ｢スナップショット｣が重要なのではなく、集計するたびに値が変わらないことが重要。 ○ キャンセル込み取扱高+別途キャンセル率を監視 ○ 実装が段違いに楽言われたことを実現するのではなく、目的を達せられるようにするシンプルなシステムにするためのポイント ① ② [キャンセル抜き] [レガシー] スナップショット時点までのキャンセル抜き ③ 減る減らない減らない取引高

Slide 13

Slide 13 text

13 ● 新pipelineで集計可能な定義へ ○ レガシーの廃止のため｢キャンセル込み取扱高｣に取扱高を再定義。 ○ 定義から変えることで、仕様の差異が原因で移行できないハードルを解消。 KPIの再定義やったこと② [キャンセル込み] ① ② [キャンセル抜き] [レガシー] スナップショット時点までのキャンセル抜き ③ 取引高

Slide 14

Slide 14 text

14 ● 量の問題 ○ 仕様上問題なくてもクエリを書き換える量の問題がある。 ● マニュアルを展開、レガシーへのアクセスをモニタリング ○ 最終的に利用者ほぼゼロへアクセスログのモニタリングと移行やったこと③

Slide 15

Slide 15 text

15 なぜレガシー化は起きたのか

Slide 16

Slide 16 text

16 ● アナリストだけの仕事でもない ● エンジニアだけの仕事でもない会社のフェーズの変化 → 組織間の隙間に落ちた業務背景 | なぜそんな事態に? 技術の創造と設計

Slide 17

Slide 17 text

17 背景 | なぜそんな事態に? ● 2015年 ○ 隣の島に座る人に「これ消そっか?」ですんだ(想像) ● 2021年 ○ 会ったことも無い人がする知らない業務×150人分のデータを消す業務コミットメントの後退ではなく、会社の拡大で未知の業務が出現 → 隙間になる。

Slide 18

Slide 18 text

18 誰かが意思をもって越境する? 理想かも知れない流れ ● 経営陣が新たな役割の必要性を認識 ● 組織に新たなロールを定義 ● 採用 ● 組織の隙間が埋まる実際によくある事なかなか理想通りいかない。結果、誰かが役割を越境しないと問題は解決しない → 功罪あり(後述) 打開策? you

Slide 19

Slide 19 text

19 ● 2015年のメルカリ ○ 前年10月にお客さまから手数料を頂きはじめた ○ つまり、それまで売上が無かった。 ○ とにかくデータが見れることが最優先 node.jsでdata pipelineを作った当時の判断は正しかったどんな構成であれ明日役立つ物を作った当時の判断は正しかった振り返って思うこと有価証券報告書当時優先すべきだったこと「明日生き残れるか >>> 7年後までメンテしやすいシステムか」

Slide 20

Slide 20 text

20 ● 起きたこと ○ 「組織の隙間に落ちる課題」 ○ 明日の生き残りをかけたフェーズからの事業成長 ○ さけられない変化だったと思う ● やったこと ○ 越境する ○ ① データ/ヒアリングによる現状把握 ○ ② KPI再定義 ○ ③ モニタリングとマイグレーションまとめ

Slide 21

Slide 21 text

21 Analytics Engineeringのチーム化レガシー化したpipelineの廃止のその後本番環境DB BigQuery From レガシーdata pipeline BigQuery From 新data pipeline データの利用者データアナリストエンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム分析 : アナリストチーム Analytics Engineering

Slide 22

Slide 22 text

22 ロードマップの作成とアライン

Slide 23

Slide 23 text

23 今後1年で取り組むテーマをVP(役員)や横のMGRにレビューしてもらう ● 対象 ○ Analytics Engineeringチームの今後1年の取り組み ● 頻度 ○ Qに1回 ● 内容 ○ 優先度、費用対効果などについても議論し、内容をブラッシュアップ → チームの方向性を横や上とアラインする取り組みロードマップとアラインの取り組み

Slide 24

Slide 24 text

24 ロードマップの例① | チームの位置づけ、注力領域

Slide 25

Slide 25 text

25 ロードマップの例② | 四半期ごとの取り組みテーマ

Slide 26

Slide 26 text

26 ロードマップの例③ | 個別PJの振り返り、今後の計画前Qまでの取り組み定量的な評価 PJの今後の評価基準

Slide 27

Slide 27 text

27 ● 効果 ○ サービスはみんなで作ってる ○ サービスのある効果にどれくらいデータ基盤が貢献したか定量化は難しい ● 費用 ○ 人件費、BigQueryのコスト ○ 費用は即時、明瞭に、定量的に、出てくる ● 起きること ○ 経営陣からみて費用は明瞭なのに効果が見えにくい存在になる費用は明瞭に数字で出てくる、効果は間接的背景 | 費用対効果の説明が難しい

Slide 28

Slide 28 text

28 データ基盤の改善はとても間接的で測りにくい背景 | データ基盤の改善で「成果」を上げるには? お客さまに良いサービスが届くサービスを作るエンジニア/デザイナーサービスを考える PdM 意思決定を支援アナリスト良いデータ基盤でアナリストを支援 Analytics Engineer 「成果」「成果」にいたる過程収益が向上する遠い...

Slide 29

Slide 29 text

29 ● 過去の失敗 ○ ｢node.jsフルスクラッチメンテナ不在のdata piplineのリスクの肌感覚をどう VPに説明するか?｣ → 説明が難しいことに対してコミュニケーションが消極的だった → 難しいからこそ話すべきだった ○ 生々しい面として、そのアラインがなければ人員が継続的に割り当てられないチームが取り組んでいることにしっかり納得感を得られていなかった失敗談 | コミュニケーションに消極的だった

Slide 30

Slide 30 text

30 「越境」について

Slide 31

Slide 31 text

31 越境は尊いが人はいつか居なくなる ● 越境した人の貢献が大きかったほど、その人が抜けた後の穴も大きい ● 正直何回も見たやるべきこと ● 個人の越境ではなく組織としての役割の確立が出来てはじめて組織の隙間は埋まる ● では役割の確立とはなにか個人に依存した取り組みは持続性が弱い越境の功罪 you

Slide 32

Slide 32 text

32 役割の確立 ● 組織図に名前が載れば確立? → No 周囲とのアライン ● 他の組織との協力がなければ社外まで届く成果を出すことはできない ● 他のチームやVPから役割を期待され、それに応えている状態になってはじめて役割としての確立 ● ロードマップのアラインはその過程周囲からの期待+そこに応えられているか役割の確立 team

Slide 33

Slide 33 text

33 中間テーブルの開発

Slide 34

Slide 34 text

34 ● 工夫した点 ○ 一気に幅広いチームに聞く ■ 18チームにヒアリング ○ 1チームにだけ聞くと優先度が高いのかどうか判断がつかない ● 見えてきた課題 ○ テーブルが複雑でSQLを書くのが大変レガシー化したdata pipelineは廃止できた。次の課題は? → 社内ヒアリング背景 | データ基盤の課題ヒアリング

Slide 35

Slide 35 text

35 ● 分析の結果 ○ 頻繁に使われているテーブルは50程度 ○ 上位には「出品」「購入」などのUX上もビジネス上も重要なテーブルが来る ● ポイントをおさえた改善 ○ 重要なデータを集中して中間テーブル化 ○ BigQueryのログを分析することでどのテーブル同士がjoinされやすいか分析良く使われているテーブルから整備解決策 | 集計を効率化する中間テーブル

Slide 36

Slide 36 text

36 振り返り | スピードと堅牢さのバランスを取れてなかった「明日生き残れるか vs N年後までメンテしやすいシステムか」 ● 堅牢さを重視しすぎた ○ これまで開発した中間テーブルで処理内容にミスがあって修正した記憶がない ○ 品質重視でしっかり作ったその分時間がかかっていた ● エラーバジェット的な発想が必要だった ○ 年間X件まではインシデントを許容、その範囲でできるだけスピードを出す ○ 以下を0 or 100で考えるのではなくバランスで考える

Slide 37

Slide 37 text

37 まとめ

Slide 38

Slide 38 text

38 ● やったこと ○ レガシーの廃止・やる事のアライン・中間テーブルの開発 ● 学んだこと ○ 組織には隙間があく。成長する以上避けられない ○ 越境は尊いが人はいつか居なくなる ○ 役割を作って穴を埋めることが必要 ■ 周囲から期待されること、それに応えることで役割が確立していく Analytics Engineeringチームでやったこと学んだこと