中央集権型の限界とデータメッシュの壁。Sansanのデータ分析基盤のこれまでとこれから

課題1: DDGへの依存が生む「構造的なボトルネック」

最も分かりやすい課題は、データ活用プロセスが全てDDGを経由しなければならないという構造上の問題でした。
事業部からの要望は「新規パイプライン構築」から「データ調査」、「ダッシュボード改修」まで多岐にわたり、DDGのバックログは常に溢れている状態でした。
DDGメンバーは徐々に増加していますが、事業成長のスピード（＝データ需要の増加）には線形でしか追従できず、結果としてビジネス側への価値提供のリードタイムを長期化させてしまう構造になっていました。

課題2: ドメイン知識とデータ操作の分断による「検証サイクルの鈍化」

2つ目は、「データを使いたい人（ドメインエキスパート）」と「データ基盤を作る人（データエンジニア）」の分断です。現場の解像度が高い＆データの感度が高いPdMやBizDevメンバーが「このデータをこう分析したい」と思っても、複雑な権限設計や技術的ハードルにより、自ら手を動かすことができません。
結果、DDGへの依頼ベースとなり、試行錯誤（PoC）のサイクルが分単位ではなく週単位になってしまいます。 ブログリレー2日目で中根が触れた「屋台骨に最短で辿り着く」開発アプローチも、この中央集権的な環境下では、コミュニケーションコストが阻害要因となり実践が困難でした。

課題3: 変更に脆く、資産を捨てづらい「保守運用の肥大化」

3つ目は、保守・運用負荷の増大です。
中央集権型のアーキテクチャでは、さまざまなデータソースの変更影響が中央に集約されやすくなります。その結果、外部サービスの仕様変更に伴うパイプライン改修や、プロダクト側のリリース・改修によるスキーマ変更を契機として、データ取り込みやテストに調整が必要となる場面が見られるようになりました。
また、「生成AI」の登場によって新規実装のハードルは下がった一方で、既存リソースをどのタイミングで整理・見直すべきかという判断の難しさも顕在化してきました。
中央に集約されたデータは依存関係が複雑化しやすく、データオーナーシップが不明瞭になりがちです。そのため、「どこかで利用されている可能性」を考慮すると削除や統廃合の判断が慎重になり、結果として、活用されていないデータにも一定の運用コストを払い続けるという悪循環が生まれていました。

検討プロセス：実現可能性の評価

実装を検討する中で、Sansanにおける実現可能性が見えてきました。

メリットは、ドメインの独立性・自律性が高まり、プロダクト側の変化に迅速に対応可能になることでした。これでドメインエキスパートが直接データを扱える環境も実現できます。

一方で、Sansanの文脈では大きな壁も見えてきました。特に決定的だったのは、原則4つ目のFederated governanceの実現難易度です。
原則では自動化（computational）を中心とした支援ツールを使いつつ、最終的なガバナンスの責任は各ドメインが持つことが求められます。

しかし、現在の各事業部側には専任のデータエンジニアがいない（or いるがリソースが足りない）、こともあり、中央集権型のデータ基盤を止めることは現実的ではありませんでした。
ガードレールが不足している状況で、自由に事業部間でのデータ連携が始まると、SSoTの担保が困難になるなどの懸念もありました。

ハイブリッド型という決断

そこで私たちは、完全なデータメッシュではなく、原則を選択的に採用する方針に転換しました。

採用

• Domain ownership（SDPで実現）
• Data as a product（Colossusのモデリング資産をプロダクトとして提供することで実現）
• Self-serve data platform（SDPコンポーネントを提供して実現）

不採用（現在は中央集権型を維持）

• Federated computational governance

ガバナンスについては分散させず、DDGによる中央集権的な管理を維持することにしました。

結論として、Colossusから枝分かれした小規模データ基盤（SDP）を配布する方針に落ち着きました。完全分散ではなく、中央（Colossus）がSSoTとガバナンスを保持し、分散（SDP）がドメインの自律性を提供するハイブリッド型です。

ハイブリッド型の設計思想

Colossusは中央集権型のSSoT基盤として継続します。Lake/Warehouse/Martとしての信頼性を維持し、データプロダクトとしてのモデリング資産（Dim/Fact等）やゴールデンデータセットを各ドメインに配布します。
ここで重要なのは、SDPで作られたナレッジを手軽にColossusに吸い上げる仕組みも持つことです。

一方、SDPはドメインオーナーシップによる分散環境として機能します。各ロールがガードレールに沿ってEDA/開発できる環境を提供し、Colossusから枝分かれした小規模データ基盤として配布されます。データオーナーシップやモデリングの責務を徐々に利用者に移譲していく設計です。

データ連携とガバナンス設計

導入当初はSDP間でのデータ共有は行いません。複雑性を避けるためであり、また現時点でそこまでの要件も少ないためです。
基本的には、ColossusからSDPへの一方向のデータ提供を基本とし、どのレイヤ（source/warehouse）を配布するかは、ドメインごとの成熟度や目的に応じて柔軟に判断しています。Colossus側に既存の資産（Warehouseでのモデリング等）があれば、積極的に提供して再利用を促します。

このようにデータのフローを一方向に絞り、ガバナンスをDDGによる中央集権管理に固定することで、運用コストを抑えつつ安全な環境を提供しています。

段階的な移行戦略

いきなり事業部側でSDPを配って終わるわけにはいかないので、段階的に導入を進めます。

Phase 1：プロダクトエンジニアの自走によるデータ開発の民主化

ある新機能がリリースされる翌日には、プロダクト側のエンジニアたちがダッシュボードをリリースできるようになった事例が生まれました。
もちろんdbtを積極活用してデータモデリングを行っています。

参考資料 speakerdeck.com

技術基盤の進化

ColossusとSDPの継続的な改修も進めつつ、SDPやDevin/MCP Toolbox等を活用した「セルフサービス化」を推進し、リソースをかけずに社内データ利活用価値を最大化するのが現在取り組んでいる一つのテーマです。

データ組織の進化

最も重要なのは、データエンジニアの役割転換です。DDGはボトルネックから、超高速で環境を提供する存在へと変化しています。守りから攻めへ、ガバナンスを効かせながら現場に自律性を与える組織へと進化しています。

坂口が掲げた「データ利活用部隊が、プロダクト開発のど真ん中へ」というビジョンが、このハイブリッドアーキテクチャによって実現しつつあります。

DDGが選んだ道

私たちは、中央集権型でも完全な分散型でもない、ハイブリッド型という道を選びました。データメッシュの原則を参考にしつつも、Sansanの組織の現実に最適化した選択です。より良い設計は求めつつも、事業成長とともに継続的に進化し続けることを選びました。

データ・AI・現場が三位一体となり、Sansanは本気で「データから収益を生み出す」に挑戦しています。Sansanのデータ基盤は、これからも事業とともに変化し続けます。

データ基盤の本質

データアーキテクチャの変革には、技術的な入れ替えだけではなく、組織文化の転換が求められます。*3大事なのは、継続的に進化し続けることだと考えています。

本ブログリレーで紹介してきた、辺見のFDE活動、中根・齊藤のAIエージェント開発、中村のセマンティックレイヤ構築。これらの多様な取り組みを、それぞれの特性に合わせて支えている基盤こそが、ハイブリッドアーキテクチャです。

Sansan技術本部ではカジュアル面談を実施しています

Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。