こんにちは。データエンジニアの田頭(@tagasyksk)です。
ファインディのデータ基盤は、CTO室データソリューションチームが事業部横断で開発・運用を担っています。事業の拡大に伴ってプロダクト数が急増し、当初採用していたデータメッシュのアーキテクチャでは管理コストの増大やサイロ化といった課題が顕在化してきました。
本記事では、Google Cloudプロジェクトの統合や共通化と分権のバランス再設計など、データ基盤をプラットフォームへと進化させている途上の取り組みについてご紹介します。まだ道半ばではありますが、同様の課題に向き合っている方の参考になれば幸いです。
これまでのデータ基盤のあゆみ
データメッシュの採用
ファインディのデータ基盤は、分散型のデータウェアハウスアーキテクチャであるデータメッシュを採用していました。
データメッシュは、各事業部がデータの所有権を持ち自律的にデータを管理するアーキテクチャです。ファインディでは次のような方針で運用してきました。
- 事業部ごとにGoogle Cloudプロジェクト及びBigQueryを分離
- 各事業部がそれぞれのデータを管理し、アクセス権を事業部単位で制御
- 事業部間のデータ共有にはBigQuery Sharingを利用
責任分界点の設計
データチームでは、レイヤーごとに責任分界点を定め、各チームが自律的にデータを活用できる体制を整えていました。データチームはソースデータの取り込みや共通のデータモデルを整備し、各事業部はその上に独自の分析用モデルを構築する形です。
データメッシュの運用については、過去に別の登壇でも発表しています。
事業拡大で直面した課題
プロダクトの急増
ファインディでは2026年に「生成AI時代の事業戦略2026」として、Findy InsightsやFindy AI+など4つの新規AI事業を同時に発表しました。
これにより、当初の設計で前提としていた「プロダクト数がある程度限られている」状態が崩れ、いくつかの課題が表面化しました。
Google Cloudプロジェクトの増殖
当初の設計思想に則り、プロダクトごとにGoogle Cloudプロジェクトを分離していたため、プロダクトが増えるたびにプロジェクトも増え続ける構造になっていました。IAM、予算、リソースの管理がプロジェクトの数に比例して煩雑になり、新しいプロダクトが追加されるたびに同じようなインフラ構築作業が発生していました。
技術選定のサイロ化
データメッシュではデータに関わる技術選定も各事業部に委ねていたため、ツールや実行環境が事業部ごとにバラバラになっていました。データ変換にはdbtとDataformが混在し、BIもスプレッドシートとLooker Studioが併存、dbtの実行環境もDocker・GitHub Actions・ローカル実行と統一されていない状態でした。中央で統制しづらく、会社として共通のノウハウを蓄積しにくいことが課題になっていました。
プロジェクト間データ連携の複雑化
事業部横断でのデータ活用ニーズも増えてきました。各プロダクトのCRMに蓄積された顧客情報をBigQueryに集約した「共通企業マスタ」の構築や、MCPとAIエージェントを組み合わせたSlackからの横断検索など、プロダクトを跨いだデータ連携の取り組みが広がっています。
しかし、プロジェクトが分離された構成のままでは、プロダクトが増えるたびに連携先も倍々で増加し、管理が追いつかなくなることが見えていました。
どう解決したか
データメッシュの再解釈とプロジェクト統合
方針転換の核となったのは、「データメッシュにおけるドメイン分離の単位をプロジェクトからデータセットに変える」という判断です。
Google Cloudプロジェクトを一つに統合し、BigQueryのデータセット単位でドメインを分離する構成に移行しました。これにより、プロジェクト管理のオーバーヘッドを大幅に削減しつつ、ドメインごとのデータの独立性は維持しています。
フェデレーテッド・ガバナンスの確立
フェデレーテッド・ガバナンスとは、全社共通で統制すべきルールと各事業部に委ねるルールを明確に分け、中央集権と分権を両立させるガバナンスモデルです。プロジェクト統合に伴い、このモデルに沿ってガバナンスの境界を整理しました。
IAM管理、Cloud DLP、BigQuery Policy Tagなどのセキュリティ・コンプライアンス領域は元々共通化していたものです。事業拡大を機に、CI検査項目、Formatter・Linter、dbtの実行環境(ランタイム)を新たに標準化しました。一方で、事業ドメイン、ビジネスイベント、データモデリングといったビジネスに近い領域は引き続き各事業部に委譲しています。
共通化すべきものと分権すべきものの線引きが明確になったことで、データチームと事業部チームの双方が迷いなく動けるようになりました。
dbtランタイムの共通化
バラバラだったdbtの実行環境をDockerに統一しました。共通のDockerイメージをArtifact Registryで管理し、各リポジトリはGitHub Reusable Workflowを通じて共通のワークフローを呼び出す形にしています。
jobs: dbt-build: uses: org/shared-workflows/.github/workflows/dbt.yml@main with: image_tag: "0.0.0" mount_path: "." dbt_args: "build --target prod"
また、ローカル開発時の共通コマンドにはTaskfileのincludes機能を活用しています。各リポジトリは共通Taskfileを参照するだけで、lint、test、buildなどの操作を統一されたインターフェースで実行できます。
includes: common: taskfile: ./path/to/shared/Taskfile.yml tasks: lint: cmds: - task: common:lint test: cmds: - task: common:test
新しいプロダクトが追加された場合も、共通のワークフローとTaskfileを参照するだけでdbt環境が整うため、立ち上げのリードタイムが大きく下がりました。バージョンアップやdependabotへの対応も、事業部の数だけ必要だったものが共通イメージ1つの更新で済むようになっています。
Lookerによる事業部横断の指標管理
データ基盤のリアーキテクチャとあわせて、BIツールの見直しも行いました。これまで事業部ごとにスプレッドシートやLooker Studioで管理していた指標を、Lookerに集約しています。
Lookerのセマンティックレイヤーを活用することで、全社で共通のビジネスロジックを定義し、指標の一貫性を担保できるようになりました。一方で、指標の定義そのものは各事業部に委譲しています。実際に、全体のダッシュボードの68%がデータエンジニア以外のメンバーによって作成されており、中央に寄せつつも現場のデータ活用はむしろ活発になっています。Looker導入の詳細については次の記事で紹介しています。
今後の展望
プラットフォーム化の取り組みはまだ道半ばです。今後は次の2つの方向で進化を続けていきます。
1つ目は、セルフサービスかつAI Readyなデータ基盤です。事業部のメンバーやAIが自らデータを探索・分析できる仕組みをさらに拡充し、データチームへの依存を減らしていきたいと考えています。
2つ目は、メタデータの整備です。今後事業やプロダクトが増えても低コストでデータを探し利用できるようにし、事業や組織間のシナジーをデータで生み出していくことがチームのミッションとして求められています。
終わりに
本記事では、データメッシュからプラットフォームへとデータ基盤を進化させた取り組みについて紹介しました。
事業の成長フェーズによって、最適なアーキテクチャは変わります。ファインディでは、データメッシュの考え方自体を捨てたわけではなく、「プロジェクト分離」から「データセット分離」へとドメイン境界の粒度を見直すことで、スケーラビリティと自律性のバランスを取り直しました。
データ基盤は一度作って終わりではなく、事業の成長に合わせて進化し続けるものです。今回紹介したリアーキテクチャもまだ道半ばで、セルフサービス化やメタデータ整備など取り組むべきテーマは山積みです。この記事が、同様の課題に向き合っている方の参考になれば嬉しいです。
ファインディではこのデータ基盤を一緒に育てていくメンバーを募集しています。少しでも興味が湧いた方はカジュアル面談お待ちしております！
