「データの定義が合わない」問題の解決パターン
ほぼすべての組織が抱える最頻出の実務課題。CDMPの複数トピックをまたぐ横断的な問題です。
典型的な状況シナリオ
営業部長：「先月の顧客数は1万5千人」
CTO ：「システムには2万人登録されている」
マーケ部長：「メルマガ対象は2万8千人」
→ 経営会議が紛糾。"正しい顧客数"が誰も分からない
原因と対応（トピック横断マッピング）
| 原因 | 関連トピック | 対応策 |
|---|---|---|
| 「顧客」の定義が合意されていない | データガバナンス | Business Glossary の作成・承認 |
| 複数システムに重複データ | MDM | ゴールデンレコードの構築 |
| データの品質が低い | データ品質 | プロファイリング + SLAの設定 |
| データの地図がない | データカタログの整備 | |
| 定義が文書化されていない | ガバナンス | Business Glossaryの維持 |
解決の実施順序（7ステップ）
1
Business Steward を任命
データガバナンス：ドメインの説明責任者を明確化
2
「顧客」の定義をステークホルダーと合意
ガバナンス活動：ビジネス部門全体で定義を統一
3
合意した定義をBusiness Glossaryに登録
メタデータ管理：全社員がアクセスできる形で文書化
4
各システムの「顧客」データをプロファイリング
データ品質：現状のデータ特性・品質問題を把握
5
名寄せとゴールデンレコード構築
MDM：重複を排除し、Single Source of Truthを確立
6
DWHのディメンション設計に反映
データモデリング：統一定義をスキーマに落とし込む
7
BIレポートを統一定義で再作成
DWH & BI：全社員が同じ数字を見られる環境を実現
実務アクションアイテム
- ✓主要ビジネスエンティティ（顧客・製品・取引等）をリストアップする
- ✓各エンティティにData Stewardを任命する
- ✓Business Glossaryツール（Confluence/Collibra等）を選定・導入する
- ✓最も重要な3〜5定義を先行してドラフトし、関係部署でレビューする
- ✓定義の承認フロー（誰が承認するか）を決める
- ✓定期的な定義レビューサイクルを設定する（四半期推奨）
データ品質問題のトリアージフレームワーク
「このデータが間違っている」と言われた時の対応手順と優先度付けの方法。
問題分類マトリクス（優先度付け）
ビジネスインパクト：低
ビジネスインパクト：高
高頻度
低頻度
高頻度 × 低インパクト
定期メンテナンス
四半期計画に組み込む
高頻度 × 高インパクト
即座に対応（Today）
経営判断・意思決定に影響
低頻度 × 低インパクト
バックログ
優先度低・後回し
低頻度 × 高インパクト
週次でレビュー
監視・モニタリング継続
根本原因のカテゴリと対策
| 根本原因 | 症状 | 予防策 |
|---|---|---|
| 入力時のミス | タイポ、フォーマット不正 | バリデーション強化、UI改善 |
| プロセス設計の欠陥 | 特定条件でNULLが発生 | プロセスの見直し、自動化 |
| ソースシステムの変更 | ある時点から問題が増加 | 変更管理プロセスの整備 |
| データ定義の不整合 | 部門間で数値が合わない | Business Glossary の整備 |
| ETL/変換のバグ | 特定の変換結果が誤り | ETLテストの強化、Unit Test |
データ品質6次元と測定方法
| 次元 | 測定指標例 | 改善手法 |
|---|---|---|
| Completeness（完全性） | NULL率 = NULL件数 / 全件数 | 必須項目バリデーション |
| Accuracy（正確性） | 外部ソースとの照合一致率 | 権威あるソースとの定期照合 |
| Consistency（一貫性） | システム間の差異件数 | MDMでのゴールデンレコード |
| Timeliness（適時性） | データ更新遅延時間 | リアルタイム連携・CDCの活用 |
| Validity（妥当性） | フォーマット違反率 | 入力段階のバリデーション |
| Uniqueness（一意性） | 重複レコード率 | Deduplication、MDM |
実務アクションアイテム
- ✓重要データ要素（CDE：Critical Data Elements）を特定する
- ✓各CDEにデータ品質指標（DQI）と目標値（SLA）を設定する
- ✓データプロファイリングを実施し現状のベースラインを把握する
- ✓品質問題の報告・エスカレーション・解決プロセスを定義する
- ✓月次のデータ品質ダッシュボードを作成する
- ✓根本原因分析（RCA）のテンプレートを整備する
アーキテクチャ選択の判断マトリクス
「どのアーキテクチャを使うべきか」を素早く判断するための実践ガイドです。
データストレージ選択
| 要件 | 推奨アーキテクチャ | 代表的なサービス |
|---|---|---|
| 大量の定型レポート・集計 | DWH | Snowflake / BigQuery / Redshift |
| 非構造化データ + ML/AI | Data Lake | S3 + Spark / Azure Data Lake |
| DWH + ML 両方必要 | Data Lakehouse | Databricks / Delta Lake |
| ドメイン分散・大規模組織 | Data Mesh | 組織パターン（製品+プラットフォーム） |
| リアルタイム分析のみ | Kappa Architecture | Kafka + Flink |
| バッチ + リアルタイム両方 | Lambda Architecture | Hadoop + Kafka |
統合パターン選択
| 要件 | 推奨パターン | 理由 |
|---|---|---|
| システム数が多い（5以上） | Hub-and-Spoke（ESB） | 接続数をN本に削減できる |
| 非同期通知・疎結合が必要 | Publish-Subscribe | 送受信が独立・スケーラブル |
| データ移動なしで統合 | データ仮想化 | ソースが分散かつ変化が多い場合 |
| リアルタイムDB変更の伝播 | ログベースCDC | ソースへの影響が最小限 |
| シンプルな定期バッチ転送 | ETL | シンプルで実績が豊富 |
| クラウドDWH + 大量データ | ELT | DWHの計算リソースを活用可能 |
MDMスタイル選択
| 要件 | 推奨スタイル | 特徴 |
|---|---|---|
| 分析目的のみ、配信不要 | Consolidation | 中央でマスター作成、元システムへ不配信 |
| 各ソースシステムへの変更なし | Registry | ポインタのみ中央保持、データは元のまま |
| 配信が必要、段階的移行 | Coexistence | マスター作成後、各システムに配信 |
| グリーンフィールド（新規構築） | Centralized | 完全に中央集権化、最高の一貫性 |
業種別適用例
| 業種 | 主な課題 | 推奨アーキテクチャ | 重要トピック |
|---|---|---|---|
| 金融 | 規制対応・リスク管理 | DWH + データリネージ | セキュリティ・メタデータ |
| 小売 | 顧客360度ビュー | MDM + Data Lakehouse | MDM・データ品質 |
| 製造 | IoTデータ処理 | Lambda Architecture | データ統合・BI |
| 医療 | 患者データ統合・HIPAA | MDM + Federated DWH | セキュリティ・ガバナンス |
| IT/SaaS | プロダクト分析・ML | Data Mesh + Lakehouse | データ品質・メタデータ |
ガバナンス組織 vs プロジェクト規模の対応表
組織規模に応じた推奨データガバナンス組織の設計ガイド。
小規模（従業員200人未満）
CDO（またはCIO兼務） └── Data Steward（兼務、2〜3名）
| 項目 | 推奨内容 |
|---|---|
| DGO（専任） | 不要。CDO/CIOが兼務 |
| ガバナンス委員会 | 月1回の定例MTGで代替 |
| ツール | SharePoint + 無料/低コストデータカタログ |
| 優先施策 | Business Glossary（Top20定義）の作成から開始 |
中規模（200〜2,000人）
CDO ├── Data Governance Office（専任1〜2名） ├── Data Steward（ドメイン別、5〜10名、兼務） └── Data Quality Manager（専任1名）
| 項目 | 推奨内容 |
|---|---|
| ガバナンス委員会 | 四半期開催・経営幹部が参加 |
| ツール | Collibra / Microsoft Purview / Alation |
| 優先施策 | 主要5〜8ドメインのSteward任命 + データカタログ導入 |
大規模（2,000人以上）
CDO ├── Data Governance Office（専任5名以上） ├── Domain Data Steward（各部門に専任） ├── Data Quality Center of Excellence └── Enterprise Data Architecture Team
| 項目 | 推奨内容 |
|---|---|
| ガバナンス委員会 | 月次開催・全主要ドメイン代表が参加 |
| ツール | エンタープライズ版データガバナンスプラットフォーム |
| 優先施策 | 全社MDMプログラム + エンタープライズデータアーキテクチャ |
実務アクションアイテム
- ✓自組織の規模・成熟度を確認し、適切な組織モデルを選択する
- ✓Executive Sponsor（経営層支持者）を確保する
- ✓主要データドメインを特定し、Stewardを任命する
- ✓ガバナンス活動のROIを示す指標（品質改善率・コスト削減等）を定義する
- ✓Data Stewardのトレーニングプログラムを設計する
- ✓ガバナンス成果を経営層に定期報告するダッシュボードを作成する
試験での「正解の方向性」を見分けるコツ
CDMP試験でDMBOKの価値観に沿った選択肢を選ぶための実践的なガイド。
DMBOKが優先する5つの価値観
1
Business-driven
データ管理はビジネスが主導。IT主導の選択肢は不正解寄り
2
Prevention over Cure
問題を予防することが修正より優れている（1:10:100の法則）
3
Incremental
段階的・漸進的な実装が推奨。一度に全部は不正解
4
Stewardship
データは組織の資産。Stewardが管理責任を持つ
5
Metadata as Foundation
メタデータがすべてのデータ管理の基盤
+
Executive Sponsorship
成功要因は常にツールより経営層のコミットメント
よくある「引っかけ」パターン
| 問題文のパターン | 引っかけ（不正解） | 正解の方向 |
|---|---|---|
| 「品質問題を解決するために...」 | データを修正する（Cure） | 根本原因を除去する（Prevention） |
| 「ガバナンス成功のために最重要は...」 | ツールの導入 | Executive Sponsorship |
| 「Data Stewardの主な役割は...」 | システムの維持管理（IT側の仕事） | ビジネスルール・定義の管理 |
| 「MDMの最初のステップは...」 | ツール選定 | ビジネスケースの確立・スコープ定義 |
| 「DQプログラムの最初は...」 | データのクレンジング | 要件定義・スコープ設定 |
| 「最も重要なアーキテクチャの決定は...」 | 技術的な実装方法 | ビジネス要件・ガバナンス設計 |
4択問題の消去法
1
IT主導の選択肢を除外
「IT部門が主導して...」「技術的な解決策のみ...」は多くの場合不正解
2
ツール選定を最初にする選択肢を除外
「まずツールを選定し...」はほぼ不正解。ツールはプロセス・人の後
3
一度にすべてを解決しようとする選択肢を除外
「全システムを同時に...」→ 段階的アプローチが正解
4
ビジネス+技術の組み合わせを選ぶ
組織・プロセス・技術の変革を組み合わせた選択肢が正解に多い
CDMP合格後の実務適用ロードマップ
資格を取得した後、実務でどのように活かしていくかのガイド。
Associate合格後（60〜74%）— 啓発・小規模プロジェクト期
| 活動領域 | 具体的なアクション |
|---|---|
| 組織啓発 | データ管理の重要性を社内で発信（ランチセッション・社内ブログ等） |
| 小規模改善 | 1〜2ドメインのデータ品質改善プロジェクトをリード |
| メタデータ | 部門内のBusiness Glossaryを初期作成（Top 20定義） |
| ネットワーク | DAMA Japanコミュニティへの参加・他社事例の収集 |
Practitioner合格後（70〜79%、Specialist×2）— プログラム設計・推進期
| 活動領域 | 具体的なアクション |
|---|---|
| Stewardshipプログラム | 全社Data Stewardship Programの設計・立ち上げ |
| データモデリング | DWH/BIプロジェクトでのディメンショナルモデリングをリード |
| MDM | MDMプロジェクトの要件定義・設計フェーズをリード |
| 品質KPI | データ品質KPI / SLAの設計と運用体制の構築 |
Master合格後（80%以上、Specialist×2）— 戦略・変革リーダー期
| 活動領域 | 具体的なアクション |
|---|---|
| データ戦略 | エンタープライズ規模のデータ戦略を立案・CDOへの提言 |
| アドバイザー | Data Governance Council / CDOへのアドバイザー |
| アーキテクチャ | エンタープライズデータアーキテクチャの設計・評価 |
| 成熟度向上 | 組織のData Maturity向上プログラムのリード |
データ成熟度アセスメント
自社のデータ管理成熟度を把握するための自己評価チェックリスト。
成熟度レベルの定義
Level 1
Ad hoc — 場当たり的。プロセスが個人依存で文書化されていない
Level 2
Repeatable — 繰り返し可能。いくつかのプロセスが定義されているが部門ごとに異なる
Level 3
Defined — 定義済み。プロセスが標準化・文書化。定量的管理はない
Level 4
Managed — 管理済み。定量的な測定と管理が行われている
Level 5
Optimized — 最適化。継続的改善が組織に組み込まれている
データガバナンス チェックリスト
- ✓CDOまたは相当の役職が存在する
- ✓Data Governance Councilが機能している（定期開催・意思決定がある）
- ✓主要データドメインにData Stewardが任命されている
- ✓Business Glossaryが存在し、定期的に更新されている
- ✓データポリシーが文書化され、周知されている
データ品質 チェックリスト
- ✓重要データ要素（CDE）が特定されている
- ✓データ品質指標（DQI）が定義・測定されている
- ✓データ品質問題の報告・解決プロセスがある
- ✓入力時のバリデーションが実装されている
- ✓データプロファイリングが定期的に実施されている
メタデータ管理 チェックリスト
- ✓データカタログが存在する
- ✓主要なデータ資産がカタログに登録されている
- ✓データリネージが記録されている（主要フローのみでも可）
- ✓データの更新日時・鮮度情報が利用可能
スコア算出（チェック数から成熟度レベルを算出）
上のチェックリストにチェックを入れると自動的にスコアが更新されます。
チェック数0 / 14
Level 1 — Ad hoc
データ管理が場当たり的な状態。まずガバナンスの基盤作りから始めましょう。