データエンジニアがクラシルでやりたいことの現在地

「データエンジニアがクラシルでやりたいこととその理由」というブログを書いてから1年。
今どこまで到達をして、どういうことを考えて、どこに向かっているのかをお話します。
https://note.com/gappy50/n/n24fc4aa963d0

〜事業を支えるデータエンジニアリングとは〜各社のデータ活用の現在地
https://findy.connpass.com/event/363726/

Transcript

1. データエンジニアが クラシルでやりたいことの 現在地 harry (@gappy50) / dely株式会社 〜事業を支えるデータエンジニアリングとは〜 各社のデータ活用の現在地 2025年7月29日
2. 自己紹介 harry (@gappy50) dely株式会社 データエンジニア 担当業務 ・ クラシルのデータ基盤新規構築 ・ 現在は全社データ基盤の構築・運用 技術スタック ・ Snowflake / dbt / Lightdash Snowflake Data Superhero ・ 2022-2025（4年連続）
6. 本日のアジェンダ 1. データエンジニアがクラシルでやりたいこと 2. 提案したビジョン 3. Lightdash導入の経緯と成果 4. AIを活用したデータライフサイクル → 1年前に描いたビジョンがどこまで実現し、次の1年で何を目指すのか
7. データエンジニアが クラシルでやりたいこと
9. 1年前に書いたブログ 「データエンジニアがクラシルでやりたいこととその理由」 ブログで提示した3つのやりたいこと 1. 3900万人規模の1st Partyデータを活用 ・ レシピ閲覧から購買まで全ファネルを分析 2. ゼロからデータ基盤を構築 ・ データマネジメントチームの立ち上げ 3. 発明力を強くするデータ文化 ・ 全員がデータから価値を生み出す組織へ → 1年後の今、どこまで実現できたか
10. 補足：発明力とは…
11. これまでの取り組み プロダクトごとにデータ基盤を構築 クラシル（2021年〜） ・ Snowflakeによる高速分析基盤 ・ ML基盤でコンテンツを最適化 クラシルリワード（2022年〜） ・ 既存BigQuery基盤の運用改善 ・ CRMのためのデータモデリング それぞれ成功したが...
12. 浮かび上がってきた3つの課題 1. データのサイロ化 ・ クラシル（Snowflake）とリワード（BigQuery） ・ ユーザーの購買行動全体が見えず機会損失に 2. Redashのクエリが価値を生まない ・ Redashをforkして、それをforkして、それをforkして… ・ SSoTがなく、正しいデータ探しに時間を浪費し、PDCAが回らない 3. 組織がスケールしない ・ 残念なことにデータエンジニアがボトルネックに ・ 重要なところにのみ投資し、知識も属人化
13. 結局はオーナーシップが取れるかの問題
14. あるべき姿はこれ
15. 提案したビジョン
16. 連邦制ガバナンスによるデータ基盤
17. 連邦制ガバナンスによるデータ基盤 プロダクトの自律性と全社の統制を両立 プロダクト側（左） ・ 各チームが責任を持ってデータを管理 ・ 今後マルチプロダクト化していくことを見据えたアジリティは担保 ・ 開発スピードを優先 分析側（右） ・ 全社共通のデータは品質を保証 ・ ツールやガバナンスは中央集権的に管理しやすいように ・ 誰もが使える環境
18. データライフサイクルを最速で回すことが目的
19. Lightdash導入の 経緯と成果
20. Redashではデータライフサイクルが回らない ForkのForkのForkでSSoTが崩壊 ・ 元クエリから派生して正解が分からない ・ 1年で1000個以上の無秩序なクエリ 管理統制の限界 ・ 命名規則なし、タグなし、検索不可能 ・ 誰でも変更可能でガバナンス不在 知識の属人化 ・ クエリの意図や計算ロジックがブラックボックス ・ ビジネスコンテキストが引き継がれない → データから価値を生み出すサイクルが停滞
21. なぜLightdashを選んだのか アドホック分析力を活かすデータマネジメント 組織の強みを活かす発想の転換 ・ SQLを書ける人にデータ管理も任せる ・ dbtでモデル化しながらBIと直結 ・ アジリティを保ちながらガバナンスを実現 Lookerとの決定的な違い ・ LookMLのような専門性不要 ・ データエンジニアへの依存を解消 ・ 意思決定者が一気通貫で完結 → 組織文化にフィットする唯一の選択肢
22. 段階的な導入戦略 データオーナー制度の導入 権限設計とロール定義 ・ データオーナー：各スクラムの意思決定責任者 ・ Developer：SQLを書くメンバー ・ Editor：ダッシュボード作成者 ・ Viewer：ダッシュボード閲覧者 4ステップの成長パス 1. 定型分析を見る（Spaces/Dashboard活用） 2. ダッシュボードを作る（Query From Tables） 3. 深掘り分析をする（アドホック分析） 4. 高品質なモデルを作る（データエンジニアと協働）
23. 虎の巻による教育体制 段階的なスキル習得 ・ Lightdashメトリクスの定義方法 ・ CI/CDでのプレビュー確認 ・ 品質向上のベストプラクティス
24. 導入の成果 15名のデータオーナーが誕生 ・ PdMがOBTを自ら実装してSSoTを実現 ・ Bizチームが商談中にダッシュボード活用 ・ データ出し依頼がほぼゼロに データエンジニアはDataOpsに集中 ・ 個別の分析依頼対応から解放 ・ CI/CDパイプライン構築 ・ AIを活用した自動化の推進 → これからデータライフサイクルをいかに高速にまわしていくかが大事
25. AIを活用した データライフサイクル
26. AIを活用したデータライフサイクル Step1: DataOpsの型を作る【現在地】 ・ 高速なアドホック分析を継続 ・ Devin x PlaybookでDataOps自動化を実現 (zenn.dev/dely_jp/articles/ai-dataops-devin-playbook-automation) Step2: ライフサイクルを回す ・ 3ヶ月でAdhocデータを削除するルール ・ 定常分析への昇華をAIがサポート ・ コンポーネント化をClaude Codeで支援 Step3: AI Readyなデータ活用 ・ Snowflake Intelligenceとの連携 ・ すべての人がAIエージェントで分析
27. AIとデータ品質の両立 意思決定者のオーナーシップは崩さない データエンジニアの新しい役割 ・ 可観測性を基盤として担保 ・ テスト実装や異常データの自動検知の仕組み化 いつの間にAI Readyになってる！となる仕組み作り ・ メタデータやテストを埋めてもらうことでAIエージェントを使えるインセンティブ設計 ・ LightdashのYAMLをSnowflakeのSemantic Modelに自動変換する仕組み ・ AIエージェントのガードレール設計 今後を見据えて ・ MCP（Model Context Protocol）の活用 ・ 画像・テキストデータのパイプライン構築
28. 1年後の理想 データエンジニアリングの民主化が完了 全員がデータから価値を生み出す組織 ・ 品質の高いデータで全員が意思決定 ・ DataOpsはAIで完全自動化 ・ データエンジニアという役割が不要に 「データエンジニアを卒業しました」と言える世界 次の挑戦は、データを最大の競争力として より本質的な組織課題の解決へ → 発明力を強くするデータ基盤の完成
29. まとめ ベストプラクティスは存在しない 技術的課題は解決しやすい ・ AIやツールで素早く対応可能 ・ ベストプラクティスも豊富 本当の勝負は適応課題 ・ 組織にどう価値貢献するか ・ AIだろうが何だろうが泥臭く向き合う データから価値を生み出すために 技術 < 組織 < 文化 組織の適応課題に向き合い続けることが 「発明力を強くする」 唯一の道
30. Thank you! harry (@gappy50) dely株式会社 データエンジニア X: @gappy50 Blog: note.com/gappy50 Tech Blog: zenn.dev/gappy dely Tech Blog: zenn.dev/dely_jp