Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Analytics Engineeringチームを立ち上げて学んだこと
Search
nagai shinya
June 27, 2024
4
1.6k
Analytics Engineeringチームを立ち上げて学んだこと
Data Engineering Study #24 データドリブン組織を支える技術
https://forkwell.connpass.com/event/320271/
nagai shinya
June 27, 2024
Tweet
Share
More Decks by nagai shinya
See All by nagai shinya
1日50万件貯まるクエリのログを活かして、SQLの生成に挑戦している話
__hiza__
7
1.6k
Analytics Engineeringチームの目標管理
__hiza__
60
35k
データ整備の優先順位付けに役立つテクニック
__hiza__
5
2.7k
データマネジメントがちょっと楽になるBigQuery監査ログの使い方
__hiza__
0
4.9k
レガシー化したdata pipelineの廃止
__hiza__
0
950
メルカリにおける分析環境整備の取り組み
__hiza__
8
7.6k
LookerのDashboardをより柔軟に作る
__hiza__
0
1.5k
Featured
See All Featured
How GitHub (no longer) Works
holman
311
140k
How to Ace a Technical Interview
jacobian
275
23k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
Facilitating Awesome Meetings
lara
49
6k
KATA
mclloyd
29
13k
Making Projects Easy
brettharned
115
5.9k
The Cult of Friendly URLs
andyhume
78
6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
GraphQLとの向き合い方2022年版
quramy
43
13k
Transcript
1 2024/06/27 Nagai Shinya (@_ _hiza_ _) Analytics Engineeringチームを 立ち上げて学んだこと
2 • 3つの取組みを通じて話します • こんな人に役立つ内容を目指しました ◦ 「社内でデータの活用は進んできたが、データ基盤の整備が追いついて ない。でも何とかしたい!」 本日のテーマ |
「チーム立ち上げから3年間で学んだこと」 事例 テーマ レガシー化したdata pipelineの廃止 越境 ロードマップの作成とアライン 役割の確立 分析用中間テーブルの開発 堅牢さと速度
3 • 自身の役割 ◦ メルカリのAnalytics EngineeringチームのMGR • チームの役割 ◦ 分析用の中間テーブルの開発/管理/展開
◦ ダッシュボードやBIツールの開発/管理/展開 実際にはチームの役割にかなり変遷もあったが割愛 自己紹介
4 レガシー化したdata pipelineの廃止
5 本番環境 → BigQuery → 利用 データ分析環境の大まかな構成 (2021年当時) 本番環境DB BigQuery
From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS
6 本番環境 → BigQuery → 利用 データ分析環境の大まかな構成 (2021年当時) 本番環境DB BigQuery
From レガシーdata pipeline BigQuery From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム 分析 : アナリストチーム ?
7 • どんなシステムだったのか? ◦ 本番環境からBigQueryへデータをloadするパイプライン • システムの課題 ◦ node.jsフルスクラッチという独特な構成 稼働開始が2015年
◦ メインの開発者が退職した後オーナーシップが不明瞭に ◦ 150名/dayの利用者。クリティカルな用途にも使用 • 組織の課題 ◦ みんな廃止した方が良いと思っていたが音頭を取れる人が居ない レガシー化したdata pipelineに多くの業務が依存 課題
8 自分が率先して廃止に動いてみた • 理由① 自分も困っていた ◦ 1人のアナリストとして、データ基盤の課題に困っていた ◦ なんとかしたかった •
理由② やれそうな気がした ◦ エンジニアとしての経験とアナリストとしての経験があった ◦ 橋渡しができそうな気がした この時点ではAnalytics Engineeringのチームはまだなく、個人の越境としてレガシー data piplineの廃止に取り組みはじめた やったこと
9 • 基本方針 ◦ 新data pipelineへの統合(大元のソースは一緒→できるはず) • ハードル① 仕様の差異 ◦
レガシーと新で出てくるKPIが若干違う ◦ 「レガシーの仕様ではないと不都合」という意見が上がっていた • ハードル② 移行の量 ◦ 仕様に問題なくても膨大な量のクエリ書き直しが必要 マイグレーションに向けた課題 課題
10 • BigQueryのへのアクセスログ(INFORMATION_SCHEMAなど)の分析 ◦ 具体的に誰がこのテーブルを使ってるのか分かる ◦ 誰にヒアリングすれば良いのか分かる • ヒアリング ◦
なぜレガシーなKPIが必要なのか業務上の理由をヒアリング ◦ 聞いたことをそのまま実現するのではなく目的にさかのぼるため データ分析とヒアリング やったこと① | 現状の調査
11 [レガシー] スナップショット 時点までの キャンセル抜き • 移行のハードル ◦ 「レガシーのデータが良い」 →なぜなのか深堀りできてなかっ
た • ヒアリングの結果 ◦ 予実管理上、過去実績の取扱高が 集計のたびに変化すると困る ◦ 着地見込みを立てて、投資をコン トロールすることが出来ない なぜレガシーの仕様が良いという部署があるのか? ヒアリング ① ② [キャンセル抜き] 集計するたびに減る (キャンセル分) 取引高
12 [キャンセル込み] • レガシーKPIを完全再現? ◦ キャンセルが発生した時刻という 新たなデータが必要 • 目的を達するにはKPIを再定義 ◦
「スナップショット」が重要なので はなく、集計するたびに値が変わ らないことが重要。 ◦ キャンセル込み取扱高+別途キャ ンセル率を監視 ◦ 実装が段違いに楽 言われたことを実現するのではなく、目的を達せられるようにする シンプルなシステムにするためのポイント ① ② [キャンセル抜き] [レガシー] スナップショット 時点までの キャンセル抜き ③ 減る 減らない 減らない 取引高
13 • 新pipelineで集計可能な定義へ ◦ レガシーの廃止のため「キャンセ ル込み取扱高」に取扱高を再定 義。 ◦ 定義から変えることで、仕様の差 異が原因で移行できないハードル
を解消。 KPIの再定義 やったこと② [キャンセル込み] ① ② [キャンセル抜き] [レガシー] スナップショット 時点までの キャンセル抜き ③ 取引高
14 • 量の問題 ◦ 仕様上問題なくてもクエリを書き換える量の問題がある。 • マニュアルを展開、レガシーへのアクセスをモニタリング ◦ 最終的に利用者ほぼゼロへ アクセスログのモニタリングと移行
やったこと③
15 なぜレガシー化は起きたのか
16 • アナリストだけの仕事でもない • エンジニアだけの仕事でもない 会社のフェーズの変化 → 組織間の隙間に落ちた業務 背景 |
なぜそんな事態に? 技術の創造と設計
17 背景 | なぜそんな事態に? • 2015年 ◦ 隣の島に座る人に「これ消そっか?」ですんだ(想像) • 2021年
◦ 会ったことも無い人がする知らない業務×150人分 のデータを消す業務 コミットメントの後退ではなく、会社の拡大で未知の業務が出現 → 隙間になる。
18 誰かが意思をもって越境する? 理想かも知れない流れ • 経営陣が新たな役割の必要性を認識 • 組織に新たなロールを定義 • 採用 •
組織の隙間が埋まる 実際によくある事 なかなか理想通りいかない。 結果、誰かが役割を越境しないと問題は解決しな い → 功罪あり(後述) 打開策? you
19 • 2015年のメルカリ ◦ 前年10月にお客さまから 手数料を頂きはじめた ◦ つまり、それまで売上が無 かった。 ◦
とにかくデータが見れるこ とが最優先 node.jsでdata pipelineを作った当時の判断は正しかった どんな構成であれ明日役立つ物を作った当時の判断は正しかった 振り返って思うこと 有価証券報告書 当時 優先すべきだったこと 「明日生き残れるか >>> 7年後までメンテしやすいシステムか」
20 • 起きたこと ◦ 「組織の隙間に落ちる課題」 ◦ 明日の生き残りをかけたフェーズからの事業成長 ◦ さけられない変化だったと思う •
やったこと ◦ 越境する ◦ ① データ/ヒアリングによる現状把握 ◦ ② KPI再定義 ◦ ③ モニタリングとマイグレーション まとめ
21 Analytics Engineeringのチーム化 レガシー化したpipelineの廃止のその後 本番環境DB BigQuery From レガシーdata pipeline BigQuery
From 新data pipeline データの利用者 データアナリスト エンジニア PdM・マーケター CS・TnS 本番環境toBQ : エンジニアチーム 分析 : アナリストチーム Analytics Engineering
22 ロードマップの作成とアライン
23 今後1年で取り組むテーマをVP(役員)や横のMGRにレビューしてもらう • 対象 ◦ Analytics Engineeringチームの今後1年の取り組み • 頻度 ◦
Qに1回 • 内容 ◦ 優先度、費用対効果などについても議論し、内容をブラッシュアップ → チームの方向性を横や上とアラインする取り組み ロードマップとアラインの取り組み
24 ロードマップの例① | チームの位置づけ、注力領域
25 ロードマップの例② | 四半期ごとの取り組みテーマ
26 ロードマップの例③ | 個別PJの振り返り、今後の計画 前Qまでの取り組み 定量的な評価 PJの今後の評価基準
27 • 効果 ◦ サービスはみんなで作ってる ◦ サービスのある効果にどれくらいデータ基盤が貢献したか定量化は難しい • 費用 ◦
人件費、BigQueryのコスト ◦ 費用は即時、明瞭に、定量的に、出てくる • 起きること ◦ 経営陣からみて費用は明瞭なのに効果が見えにくい存在になる 費用は明瞭に数字で出てくる、効果は間接的 背景 | 費用対効果の説明が難しい
28 データ基盤の改善はとても間接的で測りにくい 背景 | データ基盤の改善で「成果」を上げるには? お客さまに 良いサービスが 届く サービスを作る エンジニア/デザイナー
サービスを考える PdM 意思決定を支援 アナリスト 良いデータ基盤で アナリストを支援 Analytics Engineer 「成果」 「成果」にいたる過程 収益が向上する 遠い...
29 • 過去の失敗 ◦ 「node.jsフルスクラッチメンテナ不在のdata piplineのリスクの肌感覚をどう VPに説明するか?」 → 説明が難しいことに対してコミュニケーションが消極的 だった
→ 難しいからこそ話すべきだった ◦ 生々しい面として、そのアラインがなければ人員が継続的に割り当てられない チームが取り組んでいることにしっかり納得感を得られていなかった 失敗談 | コミュニケーションに消極的だった
30 「越境」について
31 越境は尊いが人はいつか居なくなる • 越境した人の貢献が大きかったほど、その人 が抜けた後の穴も大きい • 正直何回も見た やるべきこと • 個人の越境ではなく組織としての役割の確
立が出来てはじめて組織の隙間は埋まる • では役割の確立とはなにか 個人に依存した取り組みは持続性が弱い 越境の功罪 you
32 役割の確立 • 組織図に名前が載れば確立? → No 周囲とのアライン • 他の組織との協力がなければ社外まで届く 成果を出すことはできない
• 他のチームやVPから役割を期待され、それ に応えている状態になってはじめて役割とし ての確立 • ロードマップのアラインはその過程 周囲からの期待+そこに応えられているか 役割の確立 team
33 中間テーブルの開発
34 • 工夫した点 ◦ 一気に幅広いチームに聞く ▪ 18チームにヒアリング ◦ 1チームにだけ聞くと優先度が高いのかど うか判断がつかない
• 見えてきた課題 ◦ テーブルが複雑でSQLを書くのが大変 レガシー化したdata pipelineは廃止できた。次の課題は? → 社内ヒアリング 背景 | データ基盤の課題ヒアリング
35 • 分析の結果 ◦ 頻繁に使われているテーブルは50程度 ◦ 上位には「出品」「購入」などのUX上もビジ ネス上も重要なテーブルが来る • ポイントをおさえた改善
◦ 重要なデータを集中して中間テーブル化 ◦ BigQueryのログを分析することでどの テーブル同士がjoinされやすいか分析 良く使われているテーブルから整備 解決策 | 集計を効率化する中間テーブル
36 振り返り | スピードと堅牢さのバランスを取れてなかった 「明日生き残れるか vs N年後までメンテしやすいシステムか」 • 堅牢さを重視しすぎた ◦
これまで開発した中間テーブルで処理内容にミスがあって修正した記憶がない ◦ 品質重視でしっかり作った その分時間がかかっていた • エラーバジェット的な発想が必要だった ◦ 年間X件まではインシデントを許容、その範囲でできるだけスピードを出す ◦ 以下を0 or 100で考えるのではなくバランスで考える
37 まとめ
38 • やったこと ◦ レガシーの廃止・やる事のアライン・中間テーブルの開発 • 学んだこと ◦ 組織には隙間があく。成長する以上避けられない ◦
越境は尊いが人はいつか居なくなる ◦ 役割を作って穴を埋めることが必要 ▪ 周囲から期待されること、それに応えることで役割が確立していく Analytics Engineeringチームでやったこと学んだこと