「データメッシュで各ドメインに権限を分散」「でも組織として最低限のルールは守る」。両立は言葉では簡単ですが、実装は難しい領域です。Federated Computational Governanceは、この矛盾を解こうとするデータメッシュの第4原則で、データメッシュの中で最も誤解されやすい部分でもあります。
「Federated」は「連邦」、つまり中央政府と地方政府が役割を分担する形。「Computational」は「コード化された」、つまり人間がチェックするのではなく、自動的に強制される仕組み。組織モデルと技術実装の両方を整理します。
なぜFederated Governanceが必要か
| 従来の中央集権ガバナンス | 完全な分散 | Federated Governance |
|---|---|---|
| 中央が全てを決める | 各ドメインが好き勝手 | 共通ルールは合議、領域別は自由 |
| 遅い、現場感覚と乖離 | 標準化が崩壊 | 速さと統制の両立 |
| 大規模で機能不全 | 大規模で混乱 | 大規模でも回る |
「中央が全部決める」と現場が遅くなり、「全部分散」では組織として体をなさなくなる。Federated Governanceは、その間を取って「最低限の共通ルールだけ合議で決め、それ以外は各ドメインの自由」を目指します。
共通ルールと領域別ルールの分担
| レベル | 例 |
|---|---|
| 共通ルール（中央が定義） | PII定義・暗号化要件・データ保持期間・命名規約の枠組み |
| 領域別ルール（ドメインが定義） | そのドメイン固有の品質指標、用語、メトリクス計算式 |
共通ルールは「組織として守るべき最低限」に絞ります。「全ドメインのスキーマがpascalCaseでなければならない」のような細かいルールを中央が決めると、中央集権に戻ります。共通ルールは「PII」「暗号化」「監査ログ」のような、組織横断で意味があるものだけに絞るのが原則です。
Computational：ルールをコード化して自動適用
「Computational」が示すのは、ルールを文書化するだけでなく、ツールに組み込んで自動的に強制することです。人間がチェックするレビューは、規模が大きくなると形骸化します。
| ルール | 自動適用の例 |
|---|---|
| PIIタグ必須 | カタログでタグなしのテーブルは公開できない |
| 主キー必須 | dbt CIで主キー定義のないモデルを拒否 |
| SLA違反通知 | 鮮度監視で違反を自動Slack通知 |
| 機密データのアクセス制御 | Snowflake Row-Level Securityで自動適用 |
これらは、dbt CIテスト、Atlan等のカタログ、Snowflake等のDWH機能、品質ツール（Soda等）の組み合わせで実装できます。ガバナンスツールはデータガバナンスとカタログツール選定を参照してください。
Governance Councilの組織モデル
Federated Governanceの組織的な仕組みとして、「Governance Council」が置かれます。各ドメインの代表＋中央プラットフォームチーム＋法務・セキュリティ代表で構成される合議機関です。
| 役割 | 担当 |
|---|---|
| 共通ルールの策定・改廃 | Governance Council |
| 領域別ルールの管理 | 各ドメインのData Product Owner |
| 共通ルールの技術的実装 | 中央プラットフォームチーム |
| 違反時の最終判断 | Governance Council |
Councilは月1〜2回程度の会議体で、共通ルールに関する意思決定を行います。日々の運用判断は各ドメインに任せ、Councilは「共通ルールの設計」に集中します。
実装のレイヤー
| レイヤー | 担当ツール |
|---|---|
| データの分類 | カタログのタグ・分類（カタログ） |
| アクセス制御 | DWHのRow-Level Security、Masking |
| 品質の自動検証 | dbt tests、Soda、Great Expectations（品質ツール） |
| パイプライン強制 | CI/CDでのテスト・リンター |
| 監視・アラート | オブザーバビリティ・通知連携 |
よくある落とし穴
- 共通ルールが多すぎる：中央が「これも共通ルール」と次々増やすと、結局中央集権に戻る。共通ルールは「組織横断で守るべきもの」だけに絞る。
- Councilが意思決定機関にならない：参加者の権限が不明確だと、議論だけで決まらない。意思決定権限と決議方法を最初に明確化。
- ルールが文書化だけで実装されない：守られないルールはあっても無いのと同じ。各ルールに「自動実装方法」をセットで定義する。
- 違反時の対応が曖昧：違反者への対応プロセスがないと、ルールが形骸化する。Council判断とエスカレーションパスを定める。
向く・向かない場面
- 向く：複数ドメインに分散している、コンプライアンス要件がある（GDPR・個人情報保護法等）、規模が大きくて中央集権が機能不全に陥っている
- 向かない：単一ドメインでガバナンス対象が少ない、組織変革を伴う取り組みに経営支援がない
まとめ
- Federated Governanceは「分散と統制の両立」を目指す原則。
- 共通ルールは中央が合議で定め、領域別ルールは各ドメインが自由に定める。
- 「Computational」はルールをコード化して自動適用する仕組み。
- Governance Councilで共通ルールを合議し、技術的にはdbt CI・カタログ・DWH機能で強制する。
- 共通ルールを絞ること、自動実装すること、違反対応を定めることが運用の核心。
全体像はデータメッシュ実装の現実、隣接はドメイン駆動データ・Data Product とは。Federated Governance設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. 共通ルールはどのくらいの数が適切？
A. 中堅企業で10〜20、大企業で30〜50程度が目安です。「PII定義」「暗号化要件」「データ保持期間」「破壊的変更の通知期間」「主キー必須」のような、組織横断で意味があるものだけに絞ります。100を超えるとほぼ中央集権に逆戻りで、Federated Governanceの体をなしません。
Q. Governance Councilの参加者は？
A. 典型的には、各ドメインのData Product Owner代表数名、中央プラットフォームチームのリード、データ品質責任者、法務・セキュリティ担当、Chief Data Officer（いれば）です。10〜20名規模で、月1〜2回の会議体として運営する形が多いです。「権限を持つ意思決定者」が集まる場が重要で、議論だけになる会議体は機能しません。
Q. Computational Governanceは具体的に何のツールで？
A. 複数のツールの組み合わせです。dbt CIでスキーマや命名のリンター、カタログのタグ強制、DWHのRow-Level Security、品質ツールのSLA監視、オブザーバビリティの自動通知。「人間がチェックする」を「ツールが強制する」に置き換える方向で、組み合わせを設計します。各レイヤーの選定は本サイトの品質ツール・カタログ・オーケストレーター記事を参照してください。
Q. 完全に守れないルールはどう扱う？
A. 「例外申請プロセス」を設計します。一時的に違反を許容する代わりに、期限と代替手段を提示する例外申請。Councilが審査・承認・期限管理を行う形が現実的です。「ゼロトレランス」で運用が止まるよりも、現実的な例外を扱う仕組みがある方が、組織の運用は安定します。