【2025年版】【図解】参照・マスタ管理（RDM/MDM）とは？｜ID設計と候補選定の基本（テンプレ付）

「同じユーザーなのにダッシュボードでは2人に見える」「部署ごとに“商品ID”が違う」——これでは意思決定が割れます。
結論：参照・マスタ管理（RDM/MDM）は、「同じ現実をひとつのIDで表し、迷いなく決める」ための仕組みです。PdMはID設計→候補選定→重複解消→運用の順で整えれば、Aha/TTV/翌日活性の読みがブレません。

1. RDM/MDMの全体像（ねらい→やり方→失敗と直し方）

ねらいは、指標と顧客・商品・組織が一対一に結び付く状態を作り、議論を5分で終わらせること。やり方は、①IDの原則を決める→②データ源を洗い出す→③重複・矛盾を解消→④変更できる道を作る、の4段。失敗は、いきなりツールで“統合っぽさ”を演出すること。直すなら、まずID規約とマージ基準をテキストで合意します。

意思決定と価値づくりの全体像は、課題解決型PdM 完全ガイド／価値提供型PdMの設計図で基礎から確認できます。

2. 参照データとマスタデータの違い（まず言葉をそろえる）

用語が曖昧だと運用が壊れます。2つの区別だけ掴めば十分です。ここが分かるとPRD・ダッシュボードの線引きが一気に楽になります。

• 参照データ（RDM）：都道府県コード、通貨、業界分類など“滅多に変わらない辞書”。
  → 正しさと一貫性が命。値の増減は稀、改訂は“版管理”。
• マスタデータ（MDM）：ユーザー、商品、契約など“同じ現実を特定するデータ”。
  → 重複や表記揺れが発生。同一性の判定と代表IDが命。

3. ID設計の原則（貼るだけテンプレ）

IDは“変わらない・一意・読まない”。人間が目で読むラベルは別列に。ここがぶれるとAha/TTV/D1の母数が崩れます。

【ID設計の原則】
・不変性：意味の変更や再発行で値を変えない（内部IDは乱数/UUID）
・一意性：システム全体で重複しない（名前やメールはIDにしない）
・不可読性：意味のある桁（部署/地域）を埋め込まない
・永続性：削除でもIDは再利用しない（退会フラグ/有効期限で表現）
・外部キー：他システムIDは「紐付けテーブル」で扱う（主IDは1つ）

4. 候補選定の手順（データ源→照合→代表ID決定）

現場では「どれを主とするか」が一番揉めます。感覚で決めず、スコアで決めるのがコツ。最初は手で十分、後から自動化します。

1. データ源の棚卸し：プロダクトDB、CRM、決済、CSツールなどの“人・物・契約”の出どころを列挙。
2. 照合キーを準備：メール、電話、氏名（標準化）、生年月日、住所コードなど“比較に使える列”を正規化。
3. マッチングスコア：完全一致=2点、あいまい一致=1点、矛盾=−1点など、合計点で同一候補を抽出。
4. 代表IDの決定：同一と判断された行に“代表フラグ”を付け、主IDを新規発行（既存IDは別テーブルで保持）。

5. 重複解消のルール（擬似コード／そのまま合意文）

毎回“職人芸”になると再現性が落ちます。重複の線引きを言語化し、施行日付きで運用するとトラブルが減ります。

rule email_exact_match: 2pt（trim/小文字化後の完全一致）
rule phone_normalized: 2pt（国番号/ハイフン除去）
rule name_fuzzy_match: 1pt（全角半角/かな漢字のゆらぎ吸収）
rule birthdate_match: 1pt（yyyy-mm-dd完全一致）
rule conflict_address: -1pt（都道府県コードが矛盾）
merge if score ≥ 3pt
promote representative = latest_active_record()  # 直近の有効記録を優先
preserve all source_ids in link_table             # 由来は別テーブルで保持
施行日: 2025-09-01

6. PRD断片：非スコープ→基準→評価（Aha/TTV/D1に接続）

マスタを作って終わり、は一番の罠。会議で“読める数字”に直結させます。下記の断片をPRDに貼ってください。

【PRD断片】
非スコープ：外部IDを主キーにしない／人手判定のみでマージしない
基準：主ID=内部UUID。外部IDはlink_tableで多重保持。重複はscore≥3でマージ
評価（KR）：Aha達成率 +4pp／TTV P50 −1.5分／翌日活性 +3pp（ID整備前比）
撤退条件：問い合わせ増加×Aha悪化 → 施行前へロールバック（施行日注記）

7. “毎日4枚＋1枚”の見方（ダッシュボード運用）

IDの整理は効果検証まで一筆書きで。指標は先行3＋新規比率、加えて“マスタ健全性カード”を1枚用意します。

• Aha達成率／TTV P50・P95／翌日活性／新規比率。
• マスタ健全性：重複候補件数（週次推移）／手動判定残件／マージ失敗率／施行日。

計測の並べ方はKPI設計と運用ガイドが最短です。

8. 現場で使える“ひな形”（コピペOK）

Notion/スプレッドシートでそのまま回せる型です。小さく始めて、回り出したら自動化で置き換えます。

【マスタリンク表（master_links）】
主ID｜source_system｜source_id｜確信度（0-1）｜最終更新｜施行日

【重複レビュー表（dedupe_review）】
候補ID1｜候補ID2｜score｜判定者｜判定（merge/keep）｜理由｜施行日

【辞書（RDM）表】
コード｜ラベル｜開始日｜終了日｜版｜備考

9. Slack定型文＆10分レビュー台本（読み上げで終わる）

説明会ではなく判定会に。差分→健全性→入替宣言の3点で閉じます。Slackは施行日と影響幅を必ず書きます。

【Slack #release-data】
対象：ユーザーMDM（重複マージ基準=score≥3）施行=2025-09-01
影響：重複候補 1,240 → 320（-74%）、Aha +2.3pp 見込み
運用：link_tableに元ID保持。問い合わせはCS経由で #data-ops へ

【10分レビュー台本】
[00-03] 先週差分（Aha/TTV/D1）＋健全性カード（重複候補/残件/失敗率）
[03-07] 入替宣言（撤退/継続/新規）→PRD断片に反映
[07-10] リスク確認（法務/プライバシー/計測）。施行日の縦線をダッシュボードに

10. 7日ロードマップ（ゼロから導入）

「最低限で回す」ことに集中します。運用が回り出してから仕組みを厚くします。

1. Day1：ID原則と重複スコア表を1ページで合意。
2. Day2：データ源の棚卸しと照合キーの正規化（小文字化・ハイフン除去）。
3. Day3：重複候補を抽出→dedupe_review表を作成。
4. Day4：代表IDの付与とmaster_links表の運用開始。
5. Day5：ダッシュボードに“マスタ健全性カード”追加、施行日縦線。
6. Day6：CS/営業と問い合わせ運用（旧ID→新ID照会）を整備。
7. Day7：効果判定→次のルール改訂（±1ptなど）を告知。

11. ありがちな失敗と回避策

• 外部IDを主キーに採用：提供元の仕様変更で崩壊。内部UUID＋link_tableで吸収。
• 人手onlyでマージ：疲弊して止まる。スコアで足切り→“人は境界だけ”。
• 意味のある桁をIDに埋め込む：組織改編で破綻。意味は属性列に分離。
• 施行日の未管理：グラフが壊れる。必ず施行日で分割し、影響幅をSlackで告知。

FAQ（見えるブロック）

Q. 小規模でもMDMは必要？

A. はい。小規模こそ“同じ現実を1つのID”で表せると、Aha/TTV/D1の読みが早くなり、改善の入替が速くなります。

Q. 代表IDは既存のメールで代用できますか？

A. 推奨しません。メールは変わります。内部UUIDを主にし、メールは属性/外部キーで扱ってください。

Q. 手動レビューが追いつきません。

A. スコアで5段階に分け、上位（自明）を自動マージ、境界だけ人手に。週次で基準をチューニングします。

Aha→TTV→翌日活性の順で判断が速くなります。詳細はKPI設計と運用ガイドをどうぞ。