データメッシュ

なぜ「中央データチーム」は規模とともに詰まるのか

分析基盤の伝統的な形は中央集権です。あらゆる業務システム（注文、在庫、決済、マーケティング……）から中央のデータレイクやウェアハウスへデータを吸い上げ、一つの中央データチームがそれを取り込み・洗浄・統合・モデリングし、下流の分析やMLへ提供します。パイプライン設計そのものの整理は /data-engineering/etl-elt-pipelines/ に譲りますが、データメッシュが問題にするのはパイプラインの中身ではなく、この構造が抱える組織的なスケール限界です。

限界の正体は、性能ではなく結合（coupling）にあります。中央チームは、各ドメインの生データの意味（「この status=7 は何か」「なぜ返品は二重に計上され得るか」）を、それを生んだ業務ドメインから移し替えて理解しなければなりません。ドメインが5個なら回っても、50個、100個になると、中央チームは全ドメインのドメイン知識を抱え込む認知の一極集中に陥ります。新しい分析要望のたびに、業務を知らない中央チームが仕様を聞き取り、壊れやすい変換を足す。ドメイン数に対してリードタイムと運用負荷が線形以上に膨らむ——これが中央集権の構造的な詰まりです。

第一の柱：ドメイン指向の分散データ所有

メッシュの出発点は、データの所有権を、それを生み最もよく理解する業務ドメインへ戻すことです。注文ドメインの分析データは注文チームが、決済ドメインは決済チームが所有・公開する。中央チームがすべてを吸い上げて再解釈する代わりに、データを一番よく知る者が自分のデータに責任を持つ——ドメイン駆動設計の「境界づけられたコンテキスト」を分析データにも引くわけです。

これは物理的な集中を禁じるものではありません。ストレージが共有基盤上にあってもよい。変わるのは論理的な所有と説明責任です。中央への移送で失われがちだったドメイン知識と変換ロジックの近接を保ち、認知負荷をドメインへ分散させます。

第二の柱：データ・アズ・ア・プロダクト

所有権を分散しただけでは、他ドメインは相手のデータを使えません。そこでメッシュは各ドメインの公開データを**プロダクト（製品）**として扱うことを要求します。生テーブルを放流するのではなく、消費者（他ドメイン）を第一級の利用者と見なした成果物に仕立てる。優れたデータ製品が満たすべき性質は、しばしば次のように整理されます。

発見可能 (discoverable) : カタログで探せる。誰の何のデータか分かる
アドレス可能 (addressable): 安定した一意なアドレスで参照できる
自己記述的 (self-describing): スキーマ・意味・例が付属し単体で理解できる
信頼できる (trustworthy)  : 鮮度・完全性などSLOを明示し保証する
相互運用可能 (interoperable): 全体共通の型・ID・規約に沿い結合できる
セキュア (secure)         : アクセス制御が製品自身に組み込まれている

鍵は、これらが製品を提供するドメイン自身の責任になることです。中央チームが後追いでドキュメントを書くのではなく、データを出す側が発見可能性・鮮度SLO・スキーマの安定性まで含めて所有する。発見と信頼判断を支える発見層（データカタログ）とリネージの原理は /data-engineering/data-lineage-catalog/ に詳しく、メッシュでは各ドメインが自分の製品のメタデータを能動的にカタログへ供給する側に回ります。

第三の柱：セルフサービスのデータ基盤

所有権とプロダクト化をドメインへ課すと、素朴には各ドメインが自前でストレージ・パイプライン・カタログ・アクセス制御を構築する羽目になり、専門人材のいないドメインには過大な負担です。分散が「車輪の再発明の分散」になっては本末転倒。そこでメッシュは**セルフサービスのデータ基盤（プラットフォーム）**を第三の柱に据えます。

要点はプラットフォーム・チームとプロダクト・ドメインの責任分界です。プラットフォーム・チームはドメイン非依存の共通能力——ストレージのプロビジョニング、パイプライン実行、カタログ登録、系譜収集、アクセス制御、監視——を、ドメインが自律的に（中央にチケットを切らずに）使えるサービスとして提供します。ドメインはその上でドメイン固有のロジックだけに集中する。

このとき基盤が提供する共通能力の実体は、本サイトで扱ってきた分析基盤技術そのものです。ストレージと取り込みの土台には /data-engineering/lakehouse-iceberg-delta/ のようなテーブルフォーマットが使われ、各ドメインは基盤の作法に沿って自分の製品を publish します。基盤の狙いは、データ製品を作る限界コストを下げ、ドメインが基盤の専門家でなくても製品化できるようにすること。プラットフォームの成否は「どれだけ多くのドメインが、専門家の手を借りずに自力で製品を出せるか」でほぼ決まります。

第四の柱：連合的な計算ガバナンス

所有権を分散すると、全体としての一貫性（部門を横断した結合可能性、規制対応、機密の統制）をどう保つかが最後の難所になります。中央集権なら中央が一手に統べればよかった。メッシュの答えは、集中でも放任でもない**連合的な計算ガバナンス（federated computational governance）**です。

連合（federated）とは、各ドメイン代表とプラットフォーム／セキュリティが共同で最小限のグローバル・ルールを定めるガバナンス体制です。決めるのは、ドメインを跨いで結合するために全員が守るべき事柄に絞ります。

• 相互運用の標準：全社共通の識別子（顧客IDの表現）、日時・通貨の型、命名規約。これが揃うから別ドメインの製品どうしを結合できる。
• 機密分類とアクセス方針：PII等のタグ付けと、それに応じたマスキング・アクセス制御の原則。
• 全製品共通のSLO下限：鮮度・可用性・スキーマ後方互換の最低基準。

そして計算（computational）とは、これらのルールを文書ではなくコードとして基盤に埋め込み、自動で強制・検証することを指します。命名規約はCIで検査し、機密タグはリネージに沿って自動伝播させ、アクセス制御はプラットフォームが一律適用する。人手のレビュー運用に頼らず、ルールをプラットフォームの機能として実装するからこそ、分散した多数のドメインへ一貫して効かせられます。

要は、「全体で守るべき最小限」と「ドメインに委ねる自由」を分離し、前者だけを自動化された共通の仕組みで固定する。これにより、分散の自律性を保ちつつ、システム全体が一つの結合可能な**メッシュ（網）**として振る舞います。

中央集権レイクとの本質的な対比

ここまでを踏まえると、メッシュとレイクの違いは技術選定ではなく分解の軸にあると分かります。中央集権レイクは機能（取り込み・変換・提供という工程）で組織を割り、各工程を中央の専門チームが担うため、あらゆるドメインの要望がその一本の工程パイプラインを通過します。メッシュはドメイン（業務境界）で組織を割り、各ドメインが自分のデータに関する全工程を縦に所有する。

まとめ

• データメッシュは特定の製品ではなく、大規模組織で分析データの所有権をどう配置するかという社会技術的な設計原則。中央集権レイク／ウェアハウスの構造的な詰まりへの応答である。
• 中央集権の限界は性能ではなく結合。全ドメインの知識と要望が中央データチームへ一極集中し、ドメイン数に対して認知負荷とリードタイムが線形以上に増える。
• 四本柱は相互依存する：ドメイン指向の分散所有（データを最もよく知る者が持つ）、データ・アズ・ア・プロダクト（発見可能・信頼できる契約付き成果物として公開）、セルフサービス基盤（共通能力でドメインの製品化コストを下げる）、連合的な計算ガバナンス（最小限のグローバル規約をコード化し自動強制）。
• メッシュとレイクは対立軸ではなく層が違う。レイクハウスのような技術基盤の上で、所有権をドメインへ配置するのがメッシュ。分解の軸が工程かドメインかの違い。
• 分散はサイロではない。提供義務（データ製品）とセルフサービス基盤と連合ガバナンスが欠けると、分散はサイロ化やスタック乱立へ退化し、中央集権より悪化し得る。
• メッシュはコンウェイの法則への賭けであり、組織をドメインで割る変更そのもの。ドメインが少なく中央で捌ける規模では、便益よりオーバーヘッドが勝つ。