新しいCRMを導入した。顧客データベースは一元化された ── はずだった。しかし営業部門が参照する「顧客マスタ」と、経理部門が使う「取引先マスタ」で、同じ企業の名称が異なっている。住所の表記も違う。与信情報は片方にしか存在しない。ダッシュボードの売上集計は、どちらを正とするかで数百万円の差異が出る。
この光景に、覚えはないだろうか。業種も規模も問わず、多くの企業がこの「見えにくいが根深い問題」に直面している。
マスターデータ ── 顧客、商品、組織、拠点など、企業活動の基盤となる共通データ ── の混乱は、IT部門の「あるある」として片づけられがちだ。しかしその影響は、システム間の不整合というテクニカルな問題にとどまらない。マスターデータの混乱は、DXプロジェクトの推進力を構造的に奪い、変革そのものを停滞させる。
Gartnerは、データ品質の低さが原因で組織が被る平均的な財務損失を年間1,290万ドルと推計している (Gartner, 2021)。また、データ品質に起因するプロジェクトの手戻りや遅延は、DXプログラム全体のスケジュールを2〜6か月延伸させるとの報告もある。問題はコストだけではない。マスターデータの信頼性が低い状態で「データドリブン経営」を掲げても、意思決定者はダッシュボードの数字を信用しない。以前のInsight「『データドリブン経営』の9割は掛け声で終わる」で論じた「データを見るが使わない」構造の根底には、しばしばこのマスターデータの信頼性問題が横たわっている。
マスターデータはなぜ「混乱」するのか
部門ごとの「正しさ」が乱立する構造
マスターデータの混乱は、技術的な問題であると同時に、組織的な問題だ。
多くの企業では、顧客マスタは営業部門が管理し、仕入先マスタは調達部門が管理し、社員マスタは人事部門が管理している。各部門は自部門の業務に最適化されたデータ定義を持ち、それぞれが「正しい」データを保持しているという自負がある。営業にとっての顧客とは「商談の対象」であり、経理にとっての顧客とは「請求の宛先」だ。同じ「顧客」という言葉が、部門によって異なる意味を持っている。
DAMA-DMBOKは、マスターデータ管理（MDM）をデータガバナンスの中核的な実践領域として位置づけ、「信頼できる唯一の情報源（Single Source of Truth）」の確立を求めている (DAMA International, 2017)。しかし、「唯一の正」を定義するとは、どこかの部門の定義を優先し、別の部門の定義を変更するということだ。これは技術の問題ではなく、組織の合意形成の問題である。
SaaS時代がもたらした新しい混乱
以前のInsight「『通じない』が変革を止める」で論じたSaaS導入の構造的課題は、マスターデータの文脈でさらに深刻化する。
SaaSは導入が容易だ。営業部門がCRMを、マーケティング部門がMAツールを、カスタマーサポート部門がチケット管理システムを、それぞれ独立に導入する。各ツールは独自の顧客マスタを持ち、独自のデータモデルで情報を管理する。部門ごとに最適化されたSaaSが組織全体で統合されないまま並立する状態 ── いわゆるデータサイロが加速する。
IDCの調査では、企業が保有するデータの約80%が非統合・非構造のサイロ状態にあるとされる (IDC, 2022)。SaaSの普及はこのサイロを増殖させた。かつてのレガシーシステム時代は、ERPという「巨大な一つの箱」にデータが集約されていた。品質に問題はあっても、少なくとも物理的には一箇所にあった。SaaS時代には、データの物理的な分散が常態化し、マスターデータの統合はより困難になっている。
マスターデータの混乱は、組織の「縦割り」がデータ層に投影された結果だ。技術で統合しようとしても、その前に組織の合意がなければ、統合は形式的なものに終わる。
マスターデータの「負債」が変革を阻むメカニズム
マスターデータの混乱がDXプロジェクトを阻害するメカニズムは、3つの経路で作用する。
経路① ── 信頼の毀損
データドリブンな意思決定は、データへの信頼を前提とする。しかし、経営会議で営業部門と経理部門が異なる売上数字を提示したとき、経営層はどちらの数字も信用しなくなる。「数字が合わないなら、今まで通り現場感覚で判断する」── こうして、データ活用への投資は回収されないまま放置される。
McKinseyの調査でも、経営層が組織のデータ品質に高い信頼を寄せている企業は少数派にとどまることが指摘されている (McKinsey, 2022)。信頼の欠如は、ダッシュボードの利用率低下に直結し、「データドリブン経営」は掛け声のまま終わる。マスターデータの品質問題は、この信頼毀損の最大の原因の一つだ。
経路② ── 統合コストの爆発
DXプロジェクトの多くは、複数システム間のデータ統合を伴う。顧客360度ビューの構築、サプライチェーンの可視化、全社横断のKPIダッシュボード。これらはすべて、マスターデータの統合を前提とする。
しかし、マスターデータが整備されていない状態で統合プロジェクトに着手すると、名寄せ、データクレンジング、マッピングの工数が当初見積りの数倍に膨らむ。たとえば、当初3か月・5,000万円で計画したデータ統合フェーズが、名寄せの複雑さやデータ定義の不整合により、9か月・1.5億円規模に膨らむケースは珍しくない。業界では広く知られる通説として、データ統合プロジェクトにおける工数の約60%がデータクレンジングと変換に費やされているとされる。本来の価値創造 ── 分析やインサイトの抽出 ── に到達する前に、プロジェクトは疲弊し、予算を使い果たす。
経路③ ── 変革の「谷」を深くする
以前のInsight「変革の『谷』を乗り越える5つのレバー」で論じた通り、変革プロジェクトにはJカーブの谷が必ず訪れる。新システム導入直後の混乱期だ。
マスターデータが混乱した状態で新システムに移行すると、この谷はさらに深くなる。旧システムのデータが新システムに正しくマイグレーションされず、現場は「新しいシステムで表示される数字は間違っている」という体験をする。この体験は、変革への抵抗を一気に増幅させる。「前のシステムの方がまだ正確だった」── この声が広がると、変革プロジェクト全体の正当性が揺らぐ。
データマイグレーションの失敗は、技術的にはリカバリー可能だ。しかし、現場の信頼を一度失うと、それを取り戻すのは技術では対処できないチェンジマネジメントの課題になる。マスターデータの問題は、技術層からチェンジマネジメント層へと波及するのだ。
データ移行の失敗がもたらす最大のリスクは、データの不整合そのものではない。「新しいシステムは信用できない」という現場の認識が定着し、変革プロジェクト全体の正当性が揺らぐことだ。
マスターデータ整備を「組織変革」として設計する
マスターデータの整備は、ETLツールの導入やデータクレンジングの実行という技術プロジェクトとして扱われることが多い。しかし、前述の通り、マスターデータの混乱は組織構造の反映であり、その解決には技術と組織変革の両面からのアプローチが不可欠だ。
データオーナーシップを明確にする
マスターデータ整備の第一歩は、「このデータは誰のものか」を定義することだ。DAMA-DMBOKが強調するデータスチュワードシップの概念 ── データの品質と利用に責任を持つ役割 ── を組織に実装する (DAMA International, 2017)。
ここで重要なのは、データオーナーはIT部門ではなくビジネス部門に置くべきだということだ。顧客マスタのオーナーは営業部門長であり、商品マスタのオーナーは商品企画部門長だ。IT部門はデータの技術的な管理基盤を提供するが、データの定義と品質に対するアカウンタビリティはビジネス側が持つ。
この原則は当然に聞こえるが、実装は容易ではない。ビジネス部門に「あなたがこのデータのオーナーです」と伝えたとき、多くの場合こう返ってくる。「それは情シスの仕事でしょう」。この抵抗を乗り越えるには、経営トップからの明確な指名と、データ品質の維持を部門KPIや評価制度に組み込むことが有効だ。一部門でパイロット運用し、成果を見せることで横展開の土台を作る。この認識を変えること自体が、チェンジマネジメントの課題なのだ。
「完璧」ではなく「十分」を目指す
マスターデータ整備プロジェクトが失敗する典型的なパターンは、全社・全領域のマスターデータを一度に統合しようとすることだ。完璧を追求するほどプロジェクトは長期化し、成果が見えないまま組織の関心が離れていく。
代わりに有効なのは、影響度の高い一つのマスターデータ領域に絞り、Quick Winを出すアプローチだ。たとえば顧客マスタの名寄せから始め、営業チームが実感できるレベルで「データがきれいになった」という体験を作る。重複顧客の排除によりマーケティングコストが目に見えて削減された、という成果は組織を動かす。
以前のInsight「データガバナンスは『文化』である」で論じた「小さな成功の積み重ね」の原則は、MDMプロジェクトにおいても有効だ。一つの成功体験が、次の領域への展開を支える推進力になる。
データ品質を「測れるもの」にする
先述の「データでデータガバナンスを語る」原則は、MDMにも直接適用できる。マスターデータの品質をスコアリングし、定期的にモニタリングする仕組みを構築する。
具体的な指標としては、完全性（必須フィールドの充填率）、一意性（重複レコード率）、正確性（外部情報源との一致率）、鮮度（最終更新日からの経過日数）が基本となる。これらの指標を部門別・データ領域別にダッシュボード化し、経営層に定期報告する。測定されるものは改善される。 この原則が、MDMの持続的な品質向上を支える。
実務への示唆
マスターデータ整備を「変革プロジェクト」として推進するための、具体的なアクションを提示する。
第一に、CDO（またはCIO・プロジェクトスポンサー）の主導で、次のDXプロジェクトの「データレディネスアセスメント」を実施する。 プロジェクトの企画段階で、対象領域のマスターデータの品質を評価する。重複率、欠損率、定義の不整合箇所を洗い出し、データ整備に必要な工数をプロジェクト計画に明示的に組み込む。「走りながら直す」ではなく、走る前にデータの地図を描く。
第二に、データガバナンス推進チーム（またはデータスチュワード）を中心に、「ビジネス用語集（ビジネスグロッサリー）」の整備に着手する。 「顧客」「売上」「契約」── これらの言葉が部門ごとに異なる意味で使われていないか。主要なビジネス用語の定義を組織横断で合意し、文書化する。DAMA-DMBOKが示すメタデータ管理の実践であると同時に、部門間の「翻訳」を促進する行為でもある。ビジネス用語集は、データの「共通言語」を組織にインストールする最も実務的な一歩だ。
第三に、CIO・CDOの連携のもと、データ品質スコアを経営ダッシュボードに加える。 IT部門のレポートの中に閉じ込めず、売上やコストと同じレベルで経営層がデータ品質を確認する仕組みを作る。「顧客マスタの重複率がX%改善したことで、マーケティングROIがY%向上した」「レポーティング工数がZ時間削減された」── この因果関係をデータで示せれば、MDMは「コストセンター」から「価値の源泉」へと認識が変わる。
まとめ ── データの基盤なくして、変革の基盤なし
マスターデータの混乱は、目に見えにくい。システムは動いている。業務は回っている。しかしその水面下で、データの不整合が意思決定の精度を蝕み、プロジェクトの統合コストを膨張させ、変革への信頼を毀損している。
マスターデータの整備は、ETLツールの導入で完結する技術プロジェクトではない。「このデータは誰のものか」「どの定義が正か」「品質を誰がどう維持するか」── これらの問いに組織として答えを出し、その答えを日々の業務に埋め込み、定着させていく組織変革のプロジェクトだ。
テクノロジーだけでは、組織は変わらない。DXの華々しい構想 ── AI活用、データドリブン経営、顧客360度ビュー ── は、すべてマスターデータという地盤の上に建つ。地盤が脆弱なまま建物を高くすれば、早晩傾く。データの基盤を整え、その整備を組織の習慣として根づかせること。それが、変革の基盤を作ることに他ならない。