← メインに戻る
Topic 09

参照データとマスターデータ管理 (MDM)

DAMA-DMBOK 2nd Edition — Chapter 10: Reference and Master Data Management

出題 10%
3種類のデータ比較
種類変化頻度例特徴
参照データ
Reference Data		 極めて低い 国コード・通貨コード・性別コード 分類・コード化のために使用。変化が少なく全社共有
マスターデータ
Master Data		 低〜中 顧客・製品・従業員・取引先・場所 ビジネスの中核エンティティ。複数システムで共有
トランザクションデータ
Transaction Data		 高い 注文・支払い・在庫移動 ビジネスイベントの記録。時系列で蓄積される
MDM実装スタイル（4+1種）
① Registry

レジストリ型

各システムのデータへのポインタのみを管理。データは各システムに残る。

低侵襲・段階的導入向け
② Consolidation

統合型

各システムからデータを収集して中央でマスター作成。元システムへの書き戻しなし。

分析・レポート向け
③ Coexistence

共存型

中央でマスター作成後、各システムに配信する。段階的移行が可能。

柔軟・実務で最多
④ Centralized

集中型

全システムが中央MDMシステムを参照。最高の一貫性を実現。

最高一貫性・高コスト
スタイルデータの場所元システムへの配信用途
Registry各システムに残る（ポインタのみ）なし段階的MDM導入
Consolidation中央にコピーなし（分析専用）分析・レポート
Coexistence両方に存在あり段階的移行
Centralized中央のみ全更新を中央経由高整合性が必要な場合
ゴールデンレコード（Golden Record）の概念
ソースA 顧客DB (CRM) ソースB ECサイト ソースC 実店舗アプリ 名寄せ処理 Entity Resolution マッチング + マージ 生存ルール適用 ★ ゴールデンレコード Golden Record 最も正確で完全な 統合された単一レコード = Single Source of Truth 複数ソースデータ 統合処理 MDHが管理・配信
名寄せ（Entity Resolution）のフローと手法
データ収集 プロファイリング マッチング (名寄せ) マージ (生存ルール) ゴールデンレコード
手法説明利点欠点
完全一致
Exact Match		 ID等の完全一致でマッチング 精度高い・誤検知なし 表記揺れを検出できない
ファジーマッチ
Fuzzy Match		 類似度スコアでマッチング（Jaro-Winkler等） 表記揺れ・誤字を検出 誤検知リスクあり
確率的
Probabilistic		 複数項目の組み合わせ確率で判断 高精度・スケーラブル 実装コスト高・閾値調整必要
生存ルール（Survivorship Rules）
複数レコードをマージする際にどの値を採用するかのルール。例：「最新の更新日時の値を採用」「信頼スコア最高のシステムから採用」「NULLでない最初の値を使用」
主要5マスターデータドメイン
ドメイン例
顧客（Customer）顧客ID・名前・住所・連絡先
製品（Product）製品コード・仕様・価格
従業員（Employee）社員番号・部署・役職
取引先（Supplier/Vendor）取引先コード・契約情報
場所（Location）事業所・倉庫の住所
MDMとデータガバナンスの関係
役割責任
データスチュワードマスターデータドメインの品質・定義・整合性の説明責任
マスターデータポリシー制定・遵守のガバナンス
品質ルール定義・適用・モニタリング
MDM目的Single Source of Truth の確立
試験ポイント
SSoT（Single Source of Truth）= 物理的な単一DBではなく、論理的な「信頼できる唯一の情報源」のこと
3種類のデータ比較（重要）
種類変化頻度例
参照データ極めて低い国コード・通貨コード
マスターデータ低〜中顧客・製品・従業員
トランザクションデータ高い注文・支払い・在庫
MDMの実装スタイル（最重要）
スタイルデータの場所元システムへの配信
Registry各システムに残る（ポインタのみ）なし
Consolidation中央にコピーなし（分析向け）
Coexistence両方に存在あり
Centralized中央のみすべての更新を中央経由
キーワード集
用語定義
ゴールデンレコード最も正確な統合済み単一レコード
生存ルール
Survivorship Rules		マージ時に採用する値のルール
名寄せ
Entity Resolution		同一エンティティの複数レコードを統合
Single Source of TruthMDMの主目的。論理的な唯一の信頼源
試験直前チェックポイント
⚠ 絶対に覚えること
  • 参照データ vs マスターデータ vs トランザクションデータの違い
  • MDMの4スタイル（Registry / Consolidation / Coexistence / Centralized）
  • ゴールデンレコード = 統合された単一の正確なレコード
  • 名寄せの3手法（完全一致 / ファジー / 確率的）
  • 生存ルール = マージ時の値採用ルール
  • SSoT = 物理的単一DBではなく論理的な唯一情報源
  • 主要5ドメイン: 顧客・製品・従業員・取引先・場所
MDMスタイル選択の判断基準
  • 分析目的のみ → Consolidation
  • 段階的移行・配信が必要 → Coexistence
  • 最高一貫性（大改修OK）→ Centralized
  • 低侵襲でまず始める → Registry

練習問題 — 参照データとMDM（10問）

スコア: 0 / 10
Case 1: 小売チェーンの顧客MDM導入
背景
全国展開の小売チェーン（420店、EC・アプリ・実店舗の3チャネル）。同一顧客が3チャネルに別々に登録されており、会員ポイント統合不能・DM重複送付・顧客数40%水増しが発生。
MDMスタイルの選択判断
スタイルこの事例での評価
Registry△ 各チャネルのシステム変更なし。ポイント統合は別途必要
Consolidation△ 分析には使えるが、リアルタイムのポイント反映が困難
Coexistence ◎採用既存システム変更なし + ゴールデンレコード配信でポイント統合可能 + 段階的移行
Centralized△ 既存システムの大規模改修が必要
実装後の効果
指標BeforeAfter（6ヶ月）
重複顧客率40%2.3%
ポイント通算可能顧客0%98.7%
DM重複送付多数1件/月以下
年間顧客数（実績）2.8M（水増し）1.9M（実態）
生存ルール（Survivorship Rules）の設計例
survivorship_rules:
  customer_name:
    strategy: "most_recent_update"   # 最新更新のシステムの値を採用
  email:
    strategy: "trust_score"          # 信頼スコア最高のシステムから採用
    trust_order: [web, app, store]
  postal_address:
    strategy: "most_complete"        # NULLが最も少ない値を採用
  birth_date:
    strategy: "non_null_first"       # NULLでない最初の値
Case 2: 製品マスターの参照データ管理（グローバル消費財メーカー）
背景
製品カテゴリコード（参照データ）が地域ごとに独自化。日本「HPC」/ 欧州「HC」/ 米国「Hair」がバラバラ。グローバル売上集計をスプレッドシートで手動変換、年間工数400時間。
特性参照データマスターデータ
変更頻度極めて低い（年数回以下）中程度（日々変更）
例国コード、通貨コード、製品カテゴリ顧客、製品、サプライヤー
ガバナンス中央集権的（少数の管理者）ドメイン単位（多数のSteward）
変更プロセス形式的な承認プロセスデータ品質修正が多い
参照データ変更の承認プロセス（Change Control）
変更要求提出 (ローカルSteward) 影響分析 (下流システム確認) 委員会レビュー Ref Data Committee 変更実装・配信 (全システムへ) 変更通知 (影響チームへ)
Case 3: MDMアンチパターン（よくある失敗）
✗ アンチパターン1
完璧な名寄せを目指す
「99.99%の精度が出るまで本番化しない」→ 完璧追求のコストは99.5%の10倍以上。その間も重複データが増え続ける。
✓ 正解: 高確度は自動マージ、中確度は人手確認のハイブリッド運用で早期稼働
✗ アンチパターン2
MDMをITプロジェクトとして扱う
IT部門が主導しビジネス側が要件だけ出す。名寄せ・生存ルールにはビジネス知識が必要なのに、ビジネスオーナーシップがない。
✓ 正解: Business Data Stewardがリードし、IT部門はCustodian役割
✗ アンチパターン3
最初から全ドメインで構築
顧客・製品・サプライヤー・従業員を全部同時に統合しようとして、プロジェクトが膨大になり管理困難に。
✓ 正解: ビジネス価値の高いドメイン1つ（多くは「顧客」）からスタート
Specialist試験対策: MDMスタイル選択の判断フレームワーク
質問回答と推奨スタイル
既存システムを大幅変更できるか？Yes → Centralized / No → Registry か Coexistence
ゴールデンレコードを各システムに配信する必要があるか？Yes → Coexistence か Centralized
分析目的のみか？Yes → Consolidation
リアルタイム参照が必要か？Yes → Centralized（最終的な目標）
名寄せアルゴリズムの評価指標
指標説明トレードオフ
Precision（精度）マッチ判定の中で実際に同一人物の割合閾値を上げると精度↑・再現率↓
Recall（再現率）実際の同一人物のうちマッチ検出できた割合閾値を下げると再現率↑・精度↓
F1スコアPrecisionとRecallの調和平均両者のバランスを示す指標