データメッシュは Zhamak Dehghani が2019年に提唱した組織モデルで、4原則からなります：(1) ドメインがデータを所有、(2) データを製品として提供、(3) 共通プラットフォームを中央が提供、(4) Federated Governance（分散と統制の両立）。技術ではなく組織モデルです。

よくある誤解：「Snowflake/dbtを各部署に配る」「中央データチームを解体」「すぐ全社展開」のすべて間違い。データメッシュは年単位の組織変革で、成熟した中央集権の「次のステージ」と捉えるのが現実的です。

「ドメイン」は業務的に意味のある一貫した領域で、組織図と必ずしも一致しません。注文管理、顧客管理、配送管理など業務プロセス単位で切るのが定石。DDD（ドメイン駆動設計）のBounded Contextを応用し、「同じ言葉でも文脈で意味が違う」ことを認めて境界を引きます。

Data Productは3種類：Source-aligned（ソースシステム由来）、Aggregate（複数Source-aligned統合）、Consumer-aligned（消費者向け最適化）。境界引きは「暫定で動かして調整」のサイクルで、完璧主義は罠です。

Data Productはデータ＋メタデータ＋SLA＋ドキュメント＋サポートのパッケージ。「テーブルを公開する」だけでは不十分で、利用者が「安心して使える状態」を作るのが製品化の本質です。鮮度・可用性・品質・変更通知をSLAとして明文化します。

変更管理は3段階：後方互換（追加）は事前通知で済む、セマンティック変更（意味の変更）は30日前通知、破壊的変更（削除等）は90日前通知＋移行サポート。APIと同じ感覚で運用します。

「各ドメインに権限を分散」と「組織として最低限のルールを守る」を両立するのが Federated Computational Governance。共通ルール（PII定義・暗号化要件など）は中央が合議で定め、領域別ルールは各ドメインの自由とします。共通ルールは絞ることが鉄則。

「Computational」はルールをコード化して自動強制すること。dbt CI、カタログのタグ強制、DWH のRow-Level Security、品質ツールのSLA監視を組み合わせ、人間チェックではなくツールが守る運用にします。

データメッシュは年単位の組織変革。全社一斉移行は失敗パターンです。成熟ドメインを1〜2個選び、Data Productパイロットを3〜6ヶ月運用する。学びを共通プラットフォームとガバナンスに反映し、他ドメインに広げる、というステップが現実的です。

必要な技術は本サイトで個別解説した既存スタック（クラウドDWH、dbt、品質ツール、カタログ、オーケストレーター、セマンティックレイヤー）の組み合わせ。「データメッシュ専用の技術」は基本ありません。共通プラットフォームとして整備するのが中央の役割です。