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

by Noriaki Hiraki

Embed

Start on current slide

Slide 1

Slide 1 text

マルチプロダクトのデータ基盤設計〜データメッシュを運用して見えた課題と伸びしろ〜 db tech showcase 2025 Tokyo ファインディ株式会社 CTO 室データソリューションチーム開功昂(hiracky16)

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

3  自己紹介 Findy / データエンジニア開功昂 / Noriaki Hiraki / @hiracky16 ● 2023/11 にファインディの CTO 室データソリューションチームにジョイン 🙌 ● マルチプロダクトデータ基盤を設計開発をリード ● サッカー⚽とかポッドキャスト 🎙が好きです

Slide 4

Slide 4 text

挑戦するエンジニアのプラットフォームをつくる。テクノロジーによる社会変⾰の時代に最も必要なことは、エンジニアの可能性を拡げることです。 Findyは、アルゴリズムとヒューマニティの融合によって、すべてのエンジニアが不安なく挑戦できる世界共通のプラットフォームをつくります。個⼈のチャンスを⽣み出し、組織の⽣産性を向上させ、社会の⼈材資産を好循環させる。エンジニアプラットフォームが、デジタル社会の発展を加速していきます。ビジョン © Findy Inc. 4

Slide 5

Slide 5 text

5  ファインディの事業

Slide 6

Slide 6 text

6  組織プラットフォーム事業「組織」を見える化するアルゴリズムチームの生産性を可視化し、開発者体験を向上するためのアナリティクスツール開発リードタイムの見える化定量的なデータを活用して   １on1を活性化自身のデータを振り返り   自己成長をスピードアップ

Slide 7

Slide 7 text

● 中央集権型の課題と「データメッシュ」を採用した理由 ● データメッシュの 4 原則とファインディでの直近 2 年間の取り組み ● データメッシュ実運用から見えてきたノウハウセッションで話すこと 7 

Slide 8

Slide 8 text

ファインディのデータ基盤と組織の伸びしろ

Slide 9

Slide 9 text

9  2 年前のファインディのデータ基盤

Slide 10

Slide 10 text

2 年前のファインディのデータ基盤   10 

Slide 11

Slide 11 text

データメッシュへの移行理由と背景

Slide 12

Slide 12 text

12  データメッシュとは？ ● 分散型のデータ基盤アーキテクチャ ● 変更に対する柔軟性が向上 ● コストの透明性 ● きめ細かい権限管理

Slide 13

Slide 13 text

13  ● 採用理由 ✅ ○ 事業やチームごとにアクセス権を管理できる設計 ○ データ蓄積や利活用の幅をより柔軟に広げられる ● 懸念事項 ⚠ ○ 事業間の連携が遅くなる → ニーズがないので未考慮 ○ データエンジニアが必要 → 採用頑張る💪 データメッシュへの移行理由と背景

Slide 14

Slide 14 text

データメッシュへのリアーキテクチャ

Slide 15

Slide 15 text

15  移行後のアーキテクチャ ※ スペースの都合で Findy, Findy Freelance のアーキテクチャを掲載  

Slide 16

Slide 16 text

16  データメッシュに必要な 4 つの原則分散型のデータアーキテクチャセルフサービスのデータプラットフォームプロダクトとしてのデータフェデレーテッド・ガバナンス

Slide 17

Slide 17 text

17  データメッシュに必要な 4 つの原則分散型のデータアーキテクチャセルフサービスのデータプラットフォームプロダクトとしてのデータフェデレーテッド・ガバナンス

Slide 18

Slide 18 text

18  分散型のデータアーキテクチャデータメッシュの概念図ファインディでのアーキテクチャ

Slide 19

Slide 19 text

19  各ドメインチームでデータを所有・管理できる体制を組織事業ドメインに詳しいデータアナリストを募りデータオーナーとしてデータ品質向上の活動を促す

Slide 20

Slide 20 text

20  データメッシュに必要な 4 つの原則分散型のデータアーキテクチャセルフサービスのデータプラットフォームプロダクトとしてのデータフェデレーテッド・ガバナンス

Slide 21

Slide 21 text

データカタログの提供 21 

Slide 22

Slide 22 text

22  他部署へのデータシェアリング publish explore & subscribe develop query

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

24  データメッシュに必要な 4 つの原則分散型のデータアーキテクチャセルフサービスのデータプラットフォームプロダクトとしてのデータフェデレーテッド・ガバナンス

Slide 25

Slide 25 text

ノーコードで ETL パイプライン構築   25  ETL Reverse ETL

Slide 26

Slide 26 text

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 ?  月次の転職数 

Slide 27

Slide 27 text

27  責任分界点・オーナーを明確化

Slide 28

Slide 28 text

28  各ドメインチームでデータ利活用をサポートデータ基盤チームはドメインチームが自立してデータを管理できるように支援

Slide 29

Slide 29 text

29  データメッシュに必要な 4 つの原則分散型のデータアーキテクチャセルフサービスのデータプラットフォームプロダクトとしてのデータフェデレーテッド・ガバナンス

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

31  個人情報への取り組み Policy Tag を用いた動的マスキング DLP API を用いた個人データのマスキング select text,　 `function.dlp`(text) as masked_text – マスキング処理をリモート関数で提供 from messages

Slide 32

Slide 32 text

Terraform Private Module でインフラ構成を共通化インフラ構成の共通化   32  publish pull & apply

Slide 33

Slide 33 text

学んだ教訓とベストプラクティス

Slide 34

Slide 34 text

34  システムと組織のリアーキテクトが必要 ● 事業部サイドのアナリストやデータ活用者を巻き込むことが重要 ● 責任範囲やオーナーを明確化することでセルフの範囲を定義

Slide 35

Slide 35 text

35  成果を出しながらリアーキテクチャを進める ● 成果を小出しに進めなければリアーキも持続可能ではない ● データエンジニアがストリームアラインドを支援、時には一緒に作業

Slide 36

Slide 36 text

36  Don’t Repeat Yourself ● インフラは Terraform Private Module で共通化 ● データは Analytics Hub で共通化することで SSoT を実現 ● 共通化は工数削減やガバナンスの統一に効果がある

Slide 37

Slide 37 text

37  “セルフサービス” をレベルアップし続ける ● 組織ごとやドメインによってセルフサービスの意味合いが違う ● 技術の進歩によってアップデートし続ける必要がある DWH Transform ETL Tool BI AI Agent?

Slide 38

Slide 38 text

● 社内のメディアを使ってアウトプットし続ける ● テックブログ、イベントや Findy Tools への投稿でアウトプット 38  データエンジニアの採用に注力

Slide 39

Slide 39 text

まとめ

Slide 40

Slide 40 text

40  ● データメッシュの 4 原則は抑えつつ設計は進めましょう ● データインフラだけでなく組織構造のリアーキテクトが必要 ● ドメインごとにその時の最適なセルフサービスを追求 ● データガバナンスを適用するために DRY を推進 ● ファインディのイベントや Findy Tools はおすすめまとめ

Slide 41

Slide 41 text

複数プロダクト横断データ基盤を設計・開発しています！興味ある方はご応募、カジュアル面談お待ちしています→ データエンジニア絶賛募集中です！！

Slide 42

Slide 42 text

ご清聴ありがとうございました🙏