中央集権型を脱却した話 分散型をやめて、連邦型にたどり着くまで データマネジメント戦略Night Sansan株式会社 技術本部 CTO室 AI Solution Development 永井 僚 

永井 僚（Ryo Nagai） Sansan株式会社 技術本部 CTO室 AI Solution Development データエンジニア 2025年に明治⼤学で⼯学修⼠号を取得、Sansanに新卒⼊社 Sansan⼊社まではスタートアップ企業でデータエンジニア として、データ分析基盤の⽴ち上げから運⽤の⽀援をしてい ました。 現在は全社横断データ基盤の開発・運⽤・アナリティクス AIエージェントまでデータに関して幅広く従事しています。 

話すこと - 2025年に中央集権型アプローチから連邦型アプローチに辿り着くまで、 事業部にデータ基盤を渡すようになってから と ⽬下の課題 話さないこと - もっと以前のデータ基盤のなりたちや、技術的な話 - 2⽉にブログを書いているのでよければご覧ください 「中央集権型の限界とデータメッシュの壁。Sansanのデータ分析基盤のこれまでとこれから」 はじめに 

Sansan株式会社の働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 名刺管理から、収益を最⼤化する AI契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える 名刺アプリ 経理AXサービス 取引管理サービス ビジネスデータベース 各サービスの活⽤で変わる働き⽅ 情報を分析・活⽤しやすく データに基づいた判断ができる 情報の管理がしやすく すぐに共有できる 必要な情報を すぐに⾒つけられる 個⼈向け 法⼈向け 

現在のデータ基盤アーキテクチャ 全社横断データ分析基盤 企業DB Hubから 各Spokeへ データ連携 データ構造化 データ連携 Salesforce Spoke ※ Salesforce は Salesforce inc. の商標であり、 許可のもとで使⽤しています。 Spoke 分散データ分析基盤 HubはSSoTとして機能 Hub etc… Spoke利⽤者はデータの活⽤・運⽤に集中 事業部の Spoke利⽤者 事業部の Spoke利⽤者 

中央集権型から 分散型を断念し、 連邦型に辿り着くまで 

利⽤者 分散基盤の壁を越え、ハイブリッド（中央集権＋分散）へ 分散型を⽬指した時期 2025.01 ~ 2025.08 - ⼀点集中の構造が、管理と 活⽤双⽅のボトルネックに - 中央集権型からの脱却を ⽬指しはじめる 中央集権型のみ ~ 2025.01 連邦型へ 2025.08 ~ 2026.03現在 - 分散型はガバナンス維持 (SSoT維持など)が困難と予想 - ⽣成AIの登場で中央集権型の メリットが再浮上 - HubとSpokeを併⽤ Hub 運⽤者 利⽤者 Hub （SSoT） デ ー タ 連 携 Spoke デ ー タ 連 携 Spoke 利⽤者 Spoke 運⽤者 Spoke 利⽤者 

事業部側に どこまで責任を 持ってもらうか 

標準コンポーネント提供 + メタデータ公開 - SSoTのデータはHubで維持 - 連邦型のデータ基盤では「Hubは維持しつつ、Spokeを渡す」形へ 責任の境界を設計する プロジェクト分割による権限分離と、責任分界の明確化 - プロジェクトを責任分界・認可の境界線とした - これにより、事業部側で⾃律して動くことが可能 〜2025.01 2025.08〜 2026.03現在 2025.01〜 2025.08 

トップダウンで解決できなかった課題を事業部が⾃ら解決 事業部側で徐々にオーナーシップを持つ動きが加速 課題 ⼤元のデータソースにマイグレーションが⼊ると、 データパイプラインが壊れるケースがある - 事業部ごとにマイグレーションやリポジトリの作法が異なるため、 データエンジニア側から対策が難しい - 事後復旧するのは⼤変かつ様々なコストが掛かる 〜2025.01 2025.01〜 2025.08 2025.08〜 2026.03現在 ボトムアップで変化の芽が出始める Spokeを活⽤する事業部のエンジニアが「スキーマ変更の事前通知機能」を作成 - 突然のパイプライン破壊を防⽌できるように - マイグレーションの際は事前にやり取りをすることを基本の取り決めとした 

事業部に基盤を 展開して見えた課題 

⾃律性が上がった結果、今度は統制と品質の問題が⾒えてきた ⾃律性が上がるほど、統制がとりづらい - ⾃⾛し始めたが、各Spokeでのデータモデルの品質やルールの整備不⾜が⾒ つかり始めるという運⽤⾯の壁に直⾯ 事業部ごとに統制のレベルが異なる - ⾃⾛の成功例はあるが、事業部ごとに抱える課題は異なり、 全社での再現性はまだない ⾃律性 統制・品質 

課題が⾒えること⾃体が、前進している証拠 時期 課題 打ち⼿ 2025.01〜 2025.07 中央集権のボトルネック （管理も活⽤も詰まる） ロール分割 + 標準化の基盤を渡す 中央集権型データ基盤からの脱却 2025.07〜 2026.03現在 完全分散のガバナンスリスク AI時代に中央集権型の利点が急浮上 中央集権型データ基盤は継続利⽤ ハイブリッド化 2026.03現在〜 事業部側の推進者に負担が集中（属⼈化） 再現性のあるデータ分析基盤提供にする ガードレール・初動⽀援・伴⾛を強化 「データマネジメント組織の確⽴は⾰命ではなく進化」 DMBOKより 

まとめ アーキテクチャ設計 - 正解は1回では出なかったが、最良の道を進んでいる（と思っている） - 中央集権からの脱却を⽬指して分散基盤を導⼊→ハイブリッドへ軌道修正 事業部側にどこまで責任を持ってもらうか - 責任の境界を設計。それによって事業部側の⾃⾛も可能に - 実際に⾃⾛した例はAppendixとして補⾜。 データマネジメントは進化する - 課題を解くと、次の課題が⾒える - ⾃律性が上がってきた、その後の統制・品質のジレンマが今の課題 仮説を深く試し、ダメなら抜本的に変える。 それを短いスパンで回し続ける （ただし中途半端にやらないよう、現場に深く⼊り込む） 

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 

No content

Appendix: データ基盤を渡して⾃⾛が始まったエピソード 事業部側で明確に⾃⾛してもらえた実例 - 我々が介⼊することなく、ルールに則ってデータ抽出やダッシュボードが可能に - 新機能リリース翌⽇にダッシュボードが作成されたケースも存在 - 詳細は過去登壇資料参照 - ナレッジがSpoke利⽤部署間で広がった - ある部署のPdMがデータ利活⽤に関するブログを投稿 - その後、別プロダクトからもやりたいといった相談が2プロダクトから来て既に連携開始 もちろん最初からこんなができたわけじゃない - 初期はSDP導⼊を持ちかけて断られてしまうこともあった - 最初から事業部側に⾼度な⾃⾛を要求してしまった