データガバナンスとカタログ｜データエンジニアリング

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：データ品質とテスト・データレイクとオブジェクトストレージ　|　関連：SQL変換とdbt・ワークフローオーケストレーション

要点（BLUF）

データガバナンスは、データを発見でき・信頼でき・正しく使える状態に保つ横断的な統治。特定の段ではなく、ライフサイクル全体を貫くテーマ。
中核は4つ：カタログ（メタデータで探せる）／リネージ（来歴：どの数字がどこ由来か）／品質・契約（正しさの保証）／アクセス制御（誰が何を見られるか）。
規模が増えるほど「あるはずのデータが見つからない・この数字は信じていいか分からない」が増える。ガバナンスはデータ基盤を“沼”にしないための秩序。

概念 ── 「探せる・信じられる・守れる」

データが増えると、技術的に動くだけでは足りません。「どこに何があるか（発見）／この数字は正しいか（信頼）／見てよい人か（統制）」に答える仕組みが要ります。これがガバナンスで、データエンジニアリング・ライフサイクル（→ データエンジニアリングとは・役割）の横断テーマ（undercurrents）の中心です。

flowchart TB
    CAT["カタログ：メタデータで検索・所有者・説明"] --> GOV["データガバナンス"]
    LIN["リネージ：列・テーブルの来歴と依存"] --> GOV
    QC["品質・契約：検証・SLA・スキーマ契約"] --> GOV
    AC["アクセス制御：権限・マスキング・監査"] --> GOV

仕組み ── 4本柱

柱	問い	道具・例
カタログ	どこに何がある？	データカタログ・メタデータ管理（dbt docs等）
リネージ	この数字はどこ由来？	列/テーブルの依存グラフ（変換DAGから生成）
品質・契約	信じてよい？	テスト・SLA・スキーマ契約（→ データ品質とテスト）
アクセス制御	見てよい人？	ロール権限・PIIマスキング・監査ログ

リネージはワークフローオーケストレーションや SQL変換とdbt のDAGから自動生成できる。「このKPIが間違っている」とき、上流のどのテーブル・変換が原因かを辿れる。
メタデータは「データについてのデータ」（列名・型・所有者・更新頻度・説明）。これが整っていれば、利用者は中身を開かずに見当を付けられる（discovery）。
アクセス制御は、ELT（→ ETLとELT）で生データがDWHに入る現代で特に重要。個人情報のマスキング・行/列レベル権限を設計する。

設計の勘所 ── 規模とともに必要になる

小さいうちは「全部知っている人」が頭の中で統治できます。が、テーブルが数千、利用者が数百になると破綻する。ガバナンスは規模が一定を超えたら必須になる投資です。

所有者（ownership）を決める：各データセットに責任者を。誰のものでもないデータは腐る。
契約を機械化：スキーマ契約・品質テストをパイプラインに組み込み、違反を自動検知（→ データ品質とテスト）。
自動化されたメタデータ：手で台帳を書くと必ず陳腐化する。パイプライン（dbt/オーケストレータ）から自動収集する。

なぜそうするか ── 信頼が基盤の価値を決める

なぜ動くパイプラインに加えて統治が要るのか。データは“信頼されて初めて”使われるからです。どれだけ整ったデータでも、「どこにあるか分からない・正しいか確信が持てない・勝手に使うと規約違反かもしれない」なら、誰も使わず価値を生まない。逆に、探せて・来歴が辿れて・品質が保証され・権限が明確なら、組織は安心してデータで意思決定できる。ガバナンスは官僚的な制約ではなく、基盤への信頼＝活用量を最大化する投資です。これでデータエンジニアリングの一周——集めて・整えて・届けて・統治する——が閉じます。

⚠️ よくある落とし穴

カタログを手で書く → すぐ陳腐化。パイプラインから自動収集。
ガバナンスを後回し → 沼化してから整備すると地獄。規模が増える前に最小限から。
統制を厳しくしすぎる → 誰も使えず本末転倒。発見性・利用しやすさと両立させる。
リネージを持たない → 障害時に原因テーブルを辿れず復旧が遅れる。DAGから生成しておく。

対応ラボ

なし（横断テーマ・統治回）。品質テストの実機はデータ品質とテスト、リネージの源（変換DAG）は SQL変換とdbt・ワークフローオーケストレーションのラボを参照。