ケーススタディ：メタデータ管理

実務シナリオ + アーキテクチャ設計 — Specialist試験対策

Case 1: データカタログ導入プロジェクト（大手製薬）

背景

グローバル製薬企業（社員8,000名、データソース200以上）。データエンジニアの「どのテーブルを使えばいいか誰も知らない」問題。具体的には：

• DWHに300以上のテーブルがあるが、ビジネス上の意味が不明
• 同じ顧客セグメントを計算するSQLが部門ごとに15種類存在する
• GxP（医薬品規制）のデータ監査で「データの起源を証明できない」と指摘

実施したメタデータ管理プログラム

Step 1: メタデータ戦略の定義

収集対象を3分類してスコープを決定：

優先度 High（6ヶ月以内）:
  - Business Metadata: 全DWHテーブルの定義・オーナー情報
  - Technical Metadata: スキーマ・DDL（自動収集）
  
優先度 Medium（12ヶ月）:
  - Operational Metadata: ETLジョブ実行履歴・データ鮮度
  
優先度 Low（18ヶ月）:
  - カラムレベルのデータリネージ

Step 2: ツール選定

Step 3: Business Glossary の設計

# Business Glossary エントリ例
term: "アクティブ顧客"
definition: "過去12ヶ月以内に最低1回の購入取引がある顧客"
synonyms: ["有効顧客", "active customer"]
related_terms: ["ロイヤル顧客", "休眠顧客"]
data_steward: "営業本部 田中部長"
approved_date: "2024-03-01"
related_tables:
  - schema: "mart"
    table: "dim_customer"
    column: "is_active_flg"
    mapping_note: "is_active_flg = 'Y' かつ last_purchase_date >= DATEADD(year,-1,GETDATE())"

導入後の効果

Case 2: データリネージの実装（金融機関）

背景

地方銀行のデータガバナンス部門。BCBS 239（バーゼル委員会のリスクデータ集計原則）への対応が必要。「貸倒引当金計算に使ったデータがどこから来たか」をトレースできる必要がある。

データリネージの設計

リネージの粒度の選択（重要な設計判断）:

この銀行はBCBS239対応のためカラムレベルを選択。

リネージ図（実例）:

[ソース: 勘定系システム]
  loan_master.balance_amount
      ↓ [ETL Job: daily_loan_extract]
[ステージング: STG_LOAN]
  stg_loan.balance_amt
      ↓ [変換: ROUND(balance_amt, 0)]
[DWH: DIM_LOAN]
  dim_loan.balance_rounded
      ↓ [集計: SUM()]
[集計テーブル: FACT_LOAN_SUMMARY]
  fact_loan_summary.total_exposure
      ↓ [Report: 与信リスクレポート]
[監督当局提出レポート]
  BCBS_Report_LN01.exposure_amount

リネージ収集の自動化手法

1. ETLツール統合（最も効率的）:

• dbt（Data Build Tool）はメタデータとリネージを自動生成
• Apache Airflow + OpenLineage でジョブ実行のリネージをキャプチャ

2. クエリログ解析:

-- BigQueryの例：クエリログからリネージを推定
SELECT
  referenced_tables,
  destination_table,
  query
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE job_type = 'QUERY'
  AND statement_type IN ('INSERT', 'CREATE_TABLE_AS_SELECT')

3. 静的コード解析:

• SQLパーサーでSELECT文のソーステーブル・ターゲットテーブルを抽出
• dbtのマニフェスト（manifest.json）を解析

失敗パターン:

• 手動でリネージを記録しようとする → すぐに陳腐化し管理不能
• リネージをドキュメントで管理する → コードとの乖離が発生

Case 3: Metadata Architecture の設計パターン

パターン1: Centralized（集中型）

[全データソース] ───→ [中央メタデータリポジトリ] ←─ [全ユーザー]
  ETLで収集             （単一のデータカタログ）        データカタログUI経由

適合シナリオ:

• データソースが30以下の中規模組織
• データガバナンスが中央集権型
• 標準化が容易な環境

問題:

• ソース数が増えると収集処理がボトルネック
• リアルタイム性が低い（バッチ収集の場合）

パターン2: Federated（連邦型）

[部門A メタデータストア] ─┐
[部門B メタデータストア] ─┼──→ [メタデータハブ（統合ビュー）]
[部門C メタデータストア] ─┘

適合シナリオ:

• データメッシュアーキテクチャを採用している
• 部門ごとのデータオーナーシップが明確
• 大規模組織でスケーラビリティが重要

問題:

• 部門間でのメタデータ標準の統一が困難
• ハブでの統合コストが高い

パターン3: Active Metadata（アクティブメタデータ）

従来のPassive Metadata（記録するだけ）から進化した概念。

Passive: データが更新される → 人間がメタデータを手動更新
Active:  データが更新される → メタデータが自動更新 → 下流処理を自動トリガー

Active Metadata の応用:

• データ品質ルール違反 → 自動アラート
• スキーマ変更 → 影響を受けるレポートリストの自動生成
• データ利用頻度 → 低利用テーブルの自動アーカイブ候補提案

Specialist試験: Active Metadata はDAMAコミュニティで注目されているトピック。概念として「メタデータはパッシブな記録から、アクティブなシステム制御へ進化する」を理解する。

Case 4: Impact Analysis の実装

背景

DWHのソーステーブル（src_customer）のカラム名を変更したい（cust_no → customer_id）。変更前に影響範囲を調査する必要がある。

Impact Analysis のプロセス

Step 1: 直接依存の特定

-- どのETLジョブが cust_no を参照しているか
SELECT job_name, source_table, source_column, target_table, target_column
FROM metadata_lineage
WHERE source_column = 'cust_no'
  AND source_table = 'src_customer';

Step 2: 間接依存の特定（トランジティブ分析）

src_customer.cust_no
  ↓（直接依存）
stg_customer.customer_no
  ↓（間接依存）
dim_customer.customer_sk
  ↓（間接依存）
fact_sales.customer_sk
  ↓（間接依存）
report_sales_by_customer（最終レポート）

Step 3: リスクアセスメント

教訓: Impact Analysis が完全に機能するには、すべてのデータフローがメタデータとして記録されている必要がある。Excelマクロのような「管理外ツール」はリスクとして認識されるべき。

Specialist試験の重要概念まとめ

メタデータ成熟度モデル

ISO 11179 標準（Specialist試験で問われる）

データ要素の登録・分類に関するISO標準。

主要コンポーネント：

• Data Element: 定義・識別されたデータの単位
• Data Element Concept: ビジネス概念の記述
• Value Domain: データ要素が取りうる値の集合
• Conceptual Domain: 概念として許可される値の集合

実務での活用: MDMのゴールデンレコード定義やBusiness Glossaryの標準化に参照される。

メタデータの品質指標（Specialist試験頻出）