マルチプロダクトのデータ基盤設計 〜データメッシュを運用して見えた課題と伸びしろ〜

db tech showcase 2025 Tokyo

Transcript

1. マルチプロダクトのデータ基盤設計 〜データメッシュを運用して見えた課題と伸びしろ〜 db tech showcase 2025 Tokyo ファインディ株式会社 CTO 室データソリューションチーム 開 功昂(hiracky16)
2. 自己紹介
3. 3
 自己紹介 Findy / データエンジニア 開 功昂 / Noriaki Hiraki / @hiracky16 • 2023/11 にファインディの CTO 室データソリュー ションチームにジョイン 🙌 • マルチプロダクトデータ基盤を設計開発をリード • サッカー⚽とかポッドキャスト 🎙が好きです
4. 挑戦するエンジニアの プラットフォームをつくる。 テクノロジーによる社会変⾰の時代に最も必要なことは、エンジニアの可能性を拡げることです。 Findyは、アルゴリズムとヒューマニティの融合によって、 すべてのエンジニアが不安なく挑戦できる世界共通のプラットフォームをつくります。 個⼈のチャンスを⽣み出し、組織の⽣産性を向上させ、社会の⼈材資産を好循環させる。 エンジニアプラットフォームが、デジタル社会の発展を加速していきます。 ビジョン © Findy Inc. 4
5. 5
 ファインディの事業
6. 6
 組織プラットフォーム事業 「組織」を見える化するアルゴリズム チームの生産性を可視化し、開発者体験を向上するためのアナリティクスツール 開発リードタイムの見える化 定量的なデータを活用して 
 １on1を活性化 自身のデータを振り返り 
 自己成長をスピードアップ
7. • 中央集権型の課題と「データメッシュ」を採用した理由 • データメッシュの 4 原則とファインディでの直近 2 年間の取り組み • データメッシュ実運用から見えてきたノウハウ セッションで話すこと 7

8. ファインディの データ基盤と組織の伸びしろ
9. 9
 2 年前のファインディのデータ基盤
10. 2 年前のファインディのデータ基盤 
 10

11. データメッシュへの 移行理由と背景
12. 12
 データメッシュとは？ • 分散型のデータ基盤アーキテクチャ • 変更に対する柔軟性が向上 • コストの透明性 • きめ細かい権限管理
13. 13
 • 採用理由 ✅ ◦ 事業やチームごとにアクセス権を管理できる設計 ◦ データ蓄積や利活用の幅をより柔軟に広げられる • 懸念事項 ⚠ ◦ 事業間の連携が遅くなる → ニーズがないので未考慮 ◦ データエンジニアが必要 → 採用頑張る💪 データメッシュへの移行理由と背景
14. データメッシュへの リアーキテクチャ
15. 15
 移行後のアーキテクチャ ※ スペースの都合で Findy, Findy Freelance のアーキテクチャを掲載 

16. 16
 データメッシュに必要な 4 つの原則 分散型の データアーキテクチャ セルフサービスの データプラットフォーム プロダクトとしてのデータ フェデレーテッド・ガバナンス
17. 17
 データメッシュに必要な 4 つの原則 分散型の データアーキテクチャ セルフサービスの データプラットフォーム プロダクトとしてのデータ フェデレーテッド・ガバナンス
18. 18
 分散型のデータアーキテクチャ データメッシュの概念図 ファインディでのアーキテクチャ
19. 19
 各ドメインチームでデータを所有・管理できる体制を組織 事業ドメインに詳しいデータアナリストを募りデータオーナーとしてデータ品 質向上の活動を促す
20. 20
 データメッシュに必要な 4 つの原則 分散型の データアーキテクチャ セルフサービスの データプラットフォーム プロダクトとしてのデータ フェデレーテッド・ガバナンス
21. データカタログの提供 21

22. 22
 他部署へのデータシェアリング publish explore & subscribe develop query
23. 23
 データ品質に対する取り組み # GitHub Actions name: validate-sql on: pull_request: branches: - main jobs: steps: - name: lint - name: coverage - name: dbt-build 
 – user_count_by_skill.sql select skill, count(1) from `project_a.dataset_b.users` where created_at >= '2025-01-01' push review review review
24. 24
 データメッシュに必要な 4 つの原則 分散型の データアーキテクチャ セルフサービスの データプラットフォーム プロダクトとしてのデータ フェデレーテッド・ガバナンス
25. ノーコードで ETL パイプライン構築 
 25
 ETL Reverse ETL
26. 26
 データ可視化のセルフサービス化 select changed_date, count(1) from `project_a.dataset_b.user_job_logs` where changed_date >= '2025-01-01' explore: 転職分析 dim:change_month measure: count filter: change_date >= '2025-01-01' user_job_logs 
 user_job_histories 
 SELECT
 FROM ?
 logs or histories ?
 月次の転職数

27. 27
 責任分界点・オーナーを明確化
28. 28
 各ドメインチームでデータ利活用をサポート データ基盤チームはドメインチームが自立してデータを管理できるように支援
29. 29
 データメッシュに必要な 4 つの原則 分散型の データアーキテクチャ セルフサービスの データプラットフォーム プロダクトとしてのデータ フェデレーテッド・ガバナンス
30. DMBOK で定義されるデータガバナンスの成果物（ドキュメント）を整備 データガバナンスに対する取り組み 
 30
 全社 事業A 事業B Architecture architecture. md architecture_ a.md architecture_ b.md Modeling modeling.md - - Security security.md security_a.md - Metadata metadata.md - - Storage storage.md - storage_b.md
31. 31
 個人情報への取り組み Policy Tag を用いた動的マスキング DLP API を用いた個人データのマスキング select text,　 `function.dlp`(text) as masked_text – マスキング処理をリモート関数で提供 from messages
32. Terraform Private Module でインフラ構成を共通化 インフラ構成の共通化 
 32
 publish pull & apply
33. 学んだ教訓と ベストプラクティス
34. 34
 システムと組織のリアーキテクトが必要 • 事業部サイドのアナリストやデータ活用者を巻き込むことが重要 • 責任範囲やオーナーを明確化することでセルフの範囲を定義
35. 35
 成果を出しながらリアーキテクチャを進める • 成果を小出しに進めなければリアーキも持続可能ではない • データエンジニアがストリームアラインドを支援、時には一緒に作業
36. 36
 Don’t Repeat Yourself • インフラは Terraform Private Module で共通化 • データは Analytics Hub で共通化することで SSoT を実現 • 共通化は工数削減やガバナンスの統一に効果がある
37. 37
 “セルフサービス” をレベルアップし続ける • 組織ごとやドメインによってセルフサービスの意味合いが違う • 技術の進歩によってアップデートし続ける必要がある DWH Transform ETL Tool BI AI Agent?
38. • 社内のメディアを使ってアウトプットし続ける • テックブログ、イベントや Findy Tools への投稿でアウトプット 38
 データエンジニアの採用に注力
39. まとめ
40. 40
 • データメッシュの 4 原則は抑えつつ設計は進めましょう • データインフラだけでなく組織構造のリアーキテクトが必要 • ドメインごとにその時の最適なセルフサービスを追求 • データガバナンスを適用するために DRY を推進 • ファインディのイベントや Findy Tools はおすすめ まとめ
41. 複数プロダクト横断データ基盤を設計・開発しています！ 興味ある方はご応募、カジュアル面談お待ちしています→ データエンジニア 絶賛募集中です！！
42. ご清聴 ありがとうございました🙏