エグゼクティブ・サマリー
- 「部署によって顧客数が違う」「同じ取引先が別の会社として集計されている」という問題は、システム連携やBIツールの改善では解けない。原因はデータの受け渡しではなく、同一の実体を一つと認識するための基準——マスターデータの設計——が存在しないことにある。
- マスターデータ管理（MDM）の本質は、システム統合ではなく「正本（ゴールデンレコード）を誰がどのルールで決めるか」という業務上の合意形成である。技術は合意を実行するための手段に過ぎない。
- 名寄せは完全自動化できない。決定的マッチングと確率的マッチングを組み合わせても一定割合の判断保留は必ず残るため、人が判断する例外処理のワークフローを最初から設計に含める必要がある。
- MDMの実装スタイルには参照型・統合型・共存型・集中型という段階があり、いきなり集中型を目指す取り組みはほぼ確実に頓挫する。事業インパクトの大きい一つのドメイン（多くの場合は顧客か取引先）から参照型で着手するのが現実的である。
- 生成AIの活用が広がるほどMDMの重要性は増す。AIは与えられたデータの重複や表記ゆれを自ら疑わないため、マスターが整っていない基盤の上では、誤った集計をもっともらしい文章で説明してしまう。
なぜ「数字が合わない」は連携では解けないのか
多くの企業が、システム間のデータ連携に相当の投資をしてきた。ETLでデータウェアハウスに集約し、iPaaSで業務システムを繋ぎ、APIで疎結合な連携基盤を整えた。それでもなお、経営会議では同じ問いが繰り返される。「うちの取引先は結局、何社あるのか」。営業部門はSFAの取引先レコード数を答え、経理部門は会計システムの請求先マスタの件数を答え、その数字は一致しない。
この不一致は、データが届いていないことによるものではない。データは正しく届いている。問題は、届いた先で「株式会社山田製作所」「（株）山田製作所」「ヤマダセイサクショ」「山田製作所（本社）」という四つのレコードが、同一の会社を指しているという事実を、どのシステムも知らないことにある。連携基盤はレコードを運ぶが、運ばれたレコードが何を指しているかを判断しない。ここが、システム連携とマスターデータ管理の決定的な違いである。
この構造を理解しないまま「データ統合プロジェクト」に着手すると、典型的な失敗が起きる。データウェアハウスに全システムのデータを集約したものの、集約された結果は「重複を含んだまま一箇所に集まっただけ」の状態にとどまり、経営が求める「一つの数字」には到達しない。むしろ、これまで各部署の中で閉じていた不整合が全社の目に触れる形で可視化され、「新しいデータ基盤は信用できない」という評価を招くことすらある。
さらに厄介なのは、この問題が時間とともに劣化する性質を持つことである。ある時点で名寄せ作業を実施し、重複を解消したとする。しかし翌月には新規登録によって新たな重複が生まれ、企業の合併や商号変更、部署移管によって既存の紐付けも崩れていく。多くの企業で、名寄せは「毎月誰かがスプレッドシートで手作業する業務」として定着してしまっている。これは統合が完了していないのではなく、統合を継続する仕組みが設計されていないことの帰結である。