フレームワーク活用ガイドひとことで言うと#
データの所有権をドメイン（事業部門）に分散させつつ、全社的な品質・セキュリティ・相互運用性を担保する**「連邦型ガバナンス」**の設計手法。中央集権で全部決めるのでも、完全に放任するのでもなく、**グローバルポリシー（全社共通ルール）とローカルポリシー（ドメイン固有ルール）**を使い分ける。
押さえておきたい用語#
- データメッシュ（Data Mesh）
- ドメインごとにデータの所有と提供を行い、分散型アーキテクチャでデータ基盤を構築するアプローチ。4つの原則（ドメイン所有・データプロダクト・セルフサービスプラットフォーム・連邦型ガバナンス）で成り立つ。
- 連邦型ガバナンス（Federated Computational Governance）
- 中央チームとドメインチームが役割を分担してガバナンスを運営する仕組み。共通ルールは中央が定め、実装と運用はドメインが担う。
- グローバルポリシー（Global Policy）
- 全社で統一すべきルール。命名規則、データ分類基準、セキュリティ要件、相互運用性の標準など。
- ローカルポリシー（Local Policy）
- 各ドメインが自律的に決めるルール。ドメイン固有のスキーマ設計、更新頻度、品質閾値など。
- 計算的ガバナンス（Computational Governance）
- ポリシーを人手のレビューではなくコードで自動検証する仕組み。CI/CDパイプラインに組み込んでスケーラブルに運用する。
データメッシュガバナンスの全体像#
こんな悩みに効く#
- 中央のデータチームがボトルネックになり、各部門のデータ要望に対応しきれない
- ドメインに任せたいが、品質やセキュリティがバラバラになるのが怖い
- データガバナンスが「ルール集」で終わっており、実際に守られているか確認できない
- データメッシュに興味があるが、ガバナンスの設計方法がわからない
基本の使い方#
まずどのドメインがどのデータを生成・所有しているかを可視化する。
- 事業プロセスに沿ってドメインを区切る（営業・マーケ・プロダクト・カスタマーサポート等）
- 各ドメインが生成するデータ資産をリストアップする
- 現在のデータフローと依存関係を図にする
- ドメインごとにデータオーナー候補を特定する
全社で統一すべきルールとドメインに任せるルールの境界を決める。
- グローバル（例）: テーブル命名規則、PIIの分類とマスキング基準、アクセス権限の階層、メタデータの必須項目
- ローカル（例）: スキーマ設計、更新頻度、品質閾値の具体値、ドメイン固有のビジネスルール
- 迷ったら「他ドメインに影響するか？」で判断する。影響するならグローバル
ポリシーをコードとして実装し、自動検証の仕組みを整える。
- スキーマバリデーション: データ契約（Data Contract）を定義し、変更時にCIで検証
- 品質チェック: dbt testやGreat Expectationsでデータ品質を自動テスト
- アクセス制御: ポリシーベースのアクセス管理（例: Open Policy Agent）
- メタデータ: データカタログへの登録を自動化（未登録のテーブルはアラート）
定期的にガバナンスの実効性をレビューし、改善する。
- 月次でガバナンス委員会（中央＋各ドメイン代表）を開催する
- ポリシー違反率・品質スコア・カタログカバレッジ率をKPIとして追跡する
- ドメインからの「このルールが実態に合わない」フィードバックを収集し、ポリシーを更新する
具体例#
従業員350名のフィンテック企業。事業拡大に伴いデータ量が急増し、中央のデータチーム5名が全社のデータパイプライン120本を管理していた。新しいデータ要望の対応に平均3週間かかり、ビジネス側の不満が高まっていた。
連邦型ガバナンスを導入:
グローバルポリシー（中央が策定）:
- テーブル命名:
{domain}_{entity}_{granularity}の統一フォーマット - PII分類: 4段階のレベル分け、レベル3以上は自動マスキング必須
- メタデータ: description / owner / SLA / update_frequency の4項目必須
ローカルポリシー（各ドメインが決定）:
- スキーマ設計・カラム定義
- 更新頻度（融資ドメインはリアルタイム、マーケはバッチ）
- 品質閾値（融資は欠損率0.01%以下、マーケは1%以下で可）
計算的ガバナンスの実装:
- dbt projectに全ドメインのスキーマテストを組み込み
- GitHub ActionsでData Contract変更時に自動バリデーション
- DataHubに全テーブルを自動登録、未登録はSlackアラート
6か月後: データ要望の対応期間が3週間→3日に短縮。各ドメインが自律的にデータプロダクトを作れるようになり、中央チームはプラットフォーム改善に集中できるようになった。データ品質インシデントは月8件→2件に減少。
自動車部品メーカー3工場（愛知・群馬・九州）が、それぞれ独自のMES（製造実行システム）を使っていた。全社で品質データを横断分析したいが、工場ごとにデータ定義もフォーマットも違い、月次レポートの集計に毎回2日かかっていた。
ガバナンスの線引き:
| 項目 | グローバル | ローカル |
|---|---|---|
| 品質指標の定義 | 不良率 = 不良数 / 検査数（全社統一） | 不良分類コード（工場固有の工程に対応） |
| データ粒度 | ロット単位で統一 | ロット内のサブ粒度は工場裁量 |
| 更新頻度 | 日次で統合DWHに連携（必須） | 工場内でのリアルタイム性は各自判断 |
| 命名規則 | factory_{code}_{entity} で統一 | 工場内の中間テーブルは自由 |
各工場のMESからのデータ連携にData Contractを導入し、スキーマ変更時は自動テストが走る仕組みにした。
導入後: 月次レポート集計が2日→2時間に短縮。不良率の工場間比較がリアルタイムで可能になり、ベストプラクティスの横展開が加速。全社の不良率が1年間で0.8ポイント改善し、年間約4,200万円のコスト削減につながった。
欧州展開を開始したヘルスケアSaaS企業。患者データを扱うためGDPRと医療データ保護規制への準拠が必須。5つのドメイン（患者管理・診療記録・請求・分析・研究）がそれぞれデータを持っていた。
計算的ガバナンスの実装:
グローバルポリシー（コード化）:
- データ分類の自動タグ付け: カラム名とデータパターンからPIIを自動検出し、分類タグを付与
- 同意ベースのアクセス制御: 患者の同意レベルに応じて、データプロダクトごとにアクセス可能範囲を制御（OPA + カスタムミドルウェア）
- データ保持期間の自動管理: 規制に基づく保持期間を超えたデータは自動でアーカイブ→削除
- 監査ログ: 全アクセスをイミュータブルログに記録
ローカルポリシー:
- 診療記録ドメイン: 暗号化方式はAES-256（規制要件から）、アクセスは医師ロールに限定
- 分析ドメイン: 集計データのみ、個人特定不可能な粒度に制限
- 研究ドメイン: IRB（倫理審査委員会）承認済みデータセットのみ利用可能
成果: GDPR監査を指摘事項ゼロで通過。ポリシー違反の92%がデプロイ前のCIで検出され、本番環境での問題発生がほぼなくなった。新ドメイン追加時のガバナンス整備が数週間→数日に短縮。
やりがちな失敗パターン#
- 中央集権のまま「メッシュ」と呼ぶ — ドメインに所有権を移譲せずに名前だけ変えても、中央チームのボトルネックは解消しない。権限委譲を伴わないガバナンスはメッシュではない
- グローバルポリシーを作りすぎる — 全社統一ルールが100項目あると、ドメインの自律性が失われる。本当に統一が必要な10〜20項目に絞り、残りはローカルに委ねる
- 手動レビューに依存する — ポリシー準拠をPRレビューだけで確認していると、スケールしない。コードで自動検証できるものはすべて自動化する
- ガバナンス組織を作って終わる — 委員会を設置しただけでは機能しない。KPI（違反率・カタログカバレッジ等）を定め、定期的に実効性を測定・改善する
まとめ#
データメッシュガバナンスは、データの所有権を分散させながら全社的な品質とセキュリティを担保する「連邦型」のアプローチである。グローバルポリシー（全社共通）とローカルポリシー（ドメイン固有）を明確に線引きし、ポリシーをコードとして自動検証する「計算的ガバナンス」を実装することで、自律性とガバナンスの両立が実現する。大事なのは「すべてを統一する」のではなく、「何を統一し、何を任せるか」を設計すること。