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.3k
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.5k
Analytics Engineeringチームの目標管理
__hiza__
55
31k
データ整備の優先順位付けに役立つテクニック
__hiza__
5
2.7k
データマネジメントがちょっと楽になるBigQuery監査ログの使い方
__hiza__
0
4.7k
レガシー化したdata pipelineの廃止
__hiza__
0
930
メルカリにおける分析環境整備の取り組み
__hiza__
8
7.4k
LookerのDashboardをより柔軟に作る
__hiza__
0
1.5k
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
The Cult of Friendly URLs
andyhume
76
5.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
22
580
No one is an island. Learnings from fostering a developers community.
thoeni
18
2.9k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
A better future with KSS
kneath
235
17k
Fireside Chat
paigeccino
31
2.9k
In The Pink: A Labor of Love
frogandcode
139
22k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
27
8.9k
Done Done
chrislema
180
16k
Designing Experiences People Love
moore
138
23k
Documentation Writing (for coders)
carmenintech
65
4.3k
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チームでやったこと学んだこと