ケーススタディ：データガバナンス

実務シナリオで学ぶ — Specialist試験対策を含む

Case 1: 金融機関のガバナンスプログラム立ち上げ

背景

日本の大手地方銀行（従業員3,500名）。合併後3年が経過しているが、旧2行のシステムが並存しており、「顧客」の定義が部門ごとに異なる（個人部門は「口座保有者」、法人部門は「法人コード」、リテールは「世帯単位」）。GDPR相当の規制対応も必要になり、CDO就任を契機にガバナンスプログラムを開始。

課題の連鎖

問題の発端: 同一顧客が3システムで別々に管理
    ↓
顧客向けDM送付時に同一世帯に複数通届く（クレーム増加）
    ↓
規制当局からデータ品質に関する指摘
    ↓
CDO就任 → データガバナンスプログラム開始

実施アクション（フェーズ別）

Phase 1（月1-3）: Assessment & Foundation

• 現状調査：データドメインのインベントリ作成（23ドメインを特定）
• エグゼクティブスポンサーの確保（CFO + CROが共同スポンサー）
• Data Governance Councilの設立（CXOレベル、月次開催）

Phase 2（月4-6）: Organization Design

• 「顧客」ドメインのデータスチュワード任命
  • ビジネス側: 個人部門シニアマネージャー → Business Data Steward
  • IT側: データアーキテクト → Technical Data Steward
• RACI定義：顧客IDポリシーの変更承認フロー

データ変更要求
    ↓ 提案
Business Data Steward（Responsible: 検討・提案）
    ↓ レビュー
Data Governance Council（Accountable: 最終承認）
    ↓ 通知
IT部門（Informed: 実装）、コンプライアンス部門（Consulted: 規制確認）

Phase 3（月7-12）: Policy & Standards

• 「顧客」のゴールデン定義を制定：「本行と口座・融資・保証いずれかの取引がある法人または個人」
• 命名標準（Naming Standard）の策定
• データ品質SLAの定義（顧客マスター：Completeness 99%以上）

選択の根拠（試験頻出の判断ポイント）

失敗パターン（試験で問われる判断）

Case 2: Federated → Hybrid への移行（製造業）

背景

グローバル製造業（従業員12,000名、子会社14社）。各子会社が独立したデータ管理を行うFederated体制を20年続けてきたが、以下の問題が顕在化。

問題

• 製品コードが子会社ごとに独自体系（本社で統合レポートが作れない）
• IFRS16対応でリース資産データを統合する必要が生じたが、資産定義が子会社間で不一致
• グループ全体のサプライチェーン可視化が困難

ガバナンスモデルの移行設計

From（現状）: Federated

• 各子会社がデータポリシーを独自に策定
• 本社はデータに関与しない
• 利点：子会社の意思決定速度が高い
• 問題：グループ全体での集計・分析が不可能

To（目標）: Hybrid（Center of Excellence方式）

本社 Data CoE（Center of Excellence）
├── グローバル共通ポリシーの策定・維持
├── クリティカルなデータドメインの中央管理（製品マスター、顧客、サプライヤー）
└── 標準・ガイドラインの提供

各子会社 Local Data Steward
├── ローカルポリシーはグローバル標準に準拠
├── ローカルユースケースの独自ルール（中央承認制）
└── ローカルデータ品質の管理

移行で最も困難だった点

Change Management（試験でも「最も困難な側面」として出題される）

• 抵抗の源泉：「本社に管理される」への心理的抵抗
• 対策：「ポリシーを押し付けるのではなく、共に作る」スタンスで各子会社のStewardを設計プロセスに参画させた
• KPI：移行後12ヶ月でポリシー遵守率を60% → 85%に改善

Specialist試験レベルの考察

Governance Maturity Model（成熟度）の視点：

Level 0: No formal governance
Level 1: Initial（reactive）
Level 2: Repeatable（aware but inconsistent）
Level 3: Defined（documented, standardized）
Level 4: Managed（metrics-driven）
Level 5: Optimized（continuous improvement）

この会社は移行前がLevel 1-2、目標はLevel 3-4。 Level 5は「AIによる自動ガバナンス」を含む先進的な状態。多くのFortune 500企業でもLevel 3が現実的な目標。

Case 3: Data Stewardship Program の設計

背景

大手保険会社。既存のデータガバナンス組織（Council/DGO）はあるが、現場レベルの実装が進まない。「ガバナンスが絵に描いた餅」という現場の声。原因調査：Business Data Stewardが責任だけ与えられ、権限・時間・ツールが与えられていない。

Stewardship Program の再設計

Before（失敗パターン）:

• Data Stewardの役割定義：「データに関する問題の責任者」（曖昧）
• Time Commitment: 明確に定義なし（実際はほぼゼロ）
• 権限: データ変更の「意見を言える」程度
• ツール: Excelでの手動管理

After（改善版）:

Steward種別ごとの役割定義（実務）

試験ポイント: DMBOK定義の「Data Steward」はビジネス側だが、実務では上記4層が共存する。試験では「Business側 = Steward / IT側 = Custodian」の二項対立で問われる。

Specialist試験対策：よく問われる判断シナリオ

シナリオ型問題の解き方フレームワーク

1. 誰が問題のオーナーか？（ビジネス or IT）
2. どのガバナンスモデルが適切か？（Centralized/Federated/Hybrid）
3. Change Management は十分か？
4. Metrics で効果を測定できるか？

頻出判断パターン