マスターデータ管理システム(MDM)開発の進め方/やり方/流れや方法/手法/工程/手順

MDM開発は全6フェーズで進み、要件整理と製品・方式の選定から始めて、設計開発、テストを経て、稼働と定着へ至ります。最初に対象データと責任者を決め、方式を選んでから設計とテストへ進むと、データの重複や集計の不一致を解消しやすくなります。

▼全体ガイドの記事
・マスターデータ管理システム(MDM)の完全ガイド

マスターデータ管理システム(MDM)の全体像

MDMの主な機能をデータ品質、業務統制、配信・監査の3領域に分けた図解。
データの整備から業務での統制、各システムへの配信までが機能領域です。

MDMは、複数の業務システムで共通に使うデータを、全社で信頼できる基準にそろえる仕組みです。対象となるのは、顧客、取引先、製品、品目などです。拠点や従業員も含まれます。

MDMでは、データを一つのデータベースに集めたうえで、登録・変更・廃止のルールや承認、権限を管理します。さらに、品質監視から各システムへの配信までを担います。管理する範囲が広いため、開発ではツール選びより先に、どのデータを誰が正とするかを決めます。

MDMが解決する業務課題と主な機能

ERP、CRM、販売管理、会計、EC、PLMなどで同じ顧客や商品が別名・別コードだと、二重入力、請求ミス、誤配送、在庫集計の不一致が起こります。さらに、BIの集計値への不信にもつながります。

そこでMDMは、各システムのデータを取り込み、表記や単位をそろえます。複数のソースから優先する値を選んで作った代表データを、ゴールデンレコードと呼びます。

MDMは、データの統合から承認、配信、監査までを一続きの機能として備えており、その中身は3領域に分かれます。

  • データ品質:収集・統合、標準化、クレンジング、名寄せ、重複排除。
  • 業務統制:申請承認ワークフローと権限管理。
  • 配信・監査:APIやETLを使った提供、品質ダッシュボード、変更履歴、監査ログ。

品質を左右するのは、自動判定率に加えて、判定できない候補の確認者や誤統合の戻し方です。さらに、変更が各業務システムへ届いた時刻も追跡できる必要があります。

最初に対象にするデータと導入方式の決め方

対象ドメインは、顧客、製品、取引先、拠点などから選びます。選ぶ基準は、事業への影響が大きいこと、重複や欠損を測定できること、データオーナーを置けることです。

あわせて、連携先を2〜3システムに絞れるかも確認します。導入方式は、既存システムを残すか、マスターの正をどこに置くかで選び分けます。

  • レジストリ型:既存システムを残し、参照情報を統合。
  • ハブ型:中央のハブでマスターを集約し、配信。
  • 業務システムを正とする:主要業務システムで登録・更新を管理。
  • MDMを正とする:MDMで登録・更新を一元管理。

全社のマスターをすべて最初から統合すると、部門間の定義調整に時間がかかります。その結果、品質改善の効果を確かめる前に計画が膨らむおそれがあります。

そこで、まず1ドメイン、2〜3システムでパイロットを行います。その結果をもとに横展開するのが現実的です。

パッケージやSaaSは、標準データモデル、マッチング、ワークフローを利用しやすい方式です。一方で、業務を標準機能に合わせる判断が必要になります。

独自採番や複雑な配信があっても、まず標準機能と設定で対応できる範囲を確認します。スクラッチ開発は、差分に絞ると保守性を保ちやすくなります。

ポイント

迷ったときは、どのデータを誰が正とするかを先に決め、ツールの比較はそのあとで進めます。対象は、事業への影響が大きく、重複や欠損を測れるデータから絞ります。

マスターデータ管理システム(MDM)の進め方

MDM開発を要件整理、選定、設計開発・テスト・移行、稼働・定着の順につないだ図解。
選定後に設計と検証を経て、運用へ移る構成です。

MDM開発は全6フェーズで進みます。要件整理と製品・方式の選定を最初に行い、その後、設計開発からテストまでを経て、稼働と定着へ進みます。各段階では、作成するものと意思決定者を明確にします。

前段階で決めたことを後工程へ持ち越さないことが重要です。次の各フェーズでは、作業内容と、次へ進むための合格条件を順に説明します。

フェーズ1:要件整理と現状データの診断

最初に、経営課題をデータの課題へ置き換えます。「分析したい」といった段階から、業務内容と期限を具体的に書き直します。

  • 売上集計:顧客別の月次売上を、締め後2日以内に確定させる。
  • 商品登録:登録申請の承認待ちを、3営業日以内に収める。

現行システム、項目定義、コード体系、レコード件数を洗い出します。さらに、更新頻度や連携方式、所有部署も確認します。

データプロファイリングでは、欠損率と重複率を測り、表記ゆれや更新遅延も確認します。この段階で作成するのは、対象ドメインの定義とデータ項目一覧、システム間のデータフロー、現状品質レポートです。

あわせて、業務課題と優先順位、KPI案をまとめます。次へ進む前に、データオーナーとデータスチュワードを決め、MUSTとWANTの区分と品質の基準値も定めます。

責任者が曖昧なままだと、どのシステムを正とするかという議論に戻ってしまいます。そのため、部門長を含む意思決定会議を設けます。責任者を決めることが、この段階の合格条件です。

フェーズ2:製品・導入方式・開発会社の選定

要件を整理したら、パッケージやSaaS、既存基盤の拡張、スクラッチを比べます。比較表には、次の機能と費用を含めます。

  • データ・名寄せ:対象ドメイン、標準モデル、判定アルゴリズム、手動レビュー。
  • 運用・連携:承認、API・ETL・ファイル連携、権限、監査ログ、バックアップ、運用画面。
  • 拡張費用:追加ドメインにかかる費用。

機能の有無に加えて、自社データで重複候補をどの程度正しく判定できるかを、PoCで確認します。選定先には、現状データのサンプル、連携先一覧、想定ユーザー数を渡します。

品質KPIと稼働目標も同じ条件で提示し、提案の前提をそろえます。候補会社には、担当範囲や評価項目を確認します。

  • データ判断:データオーナーの支援者と、名寄せ例外の判断者。
  • 移行・定着:リハーサルの回数、稼働後の教育と運用改善。
  • 引き継ぎ:製品ベンダーと導入SIerの役割、障害時窓口、設計書やルールの引き渡し条件。
  • デモと評価:名寄せ結果、手動確認件数、登録から配信までの時間、例外処理。
  • 会社比較:機能、実績、提案体制、価格、定着、セキュリティ、契約の柔軟性。同じドメインやデータ量、ERP・CRM連携の経験。

役割と引き渡しの条件は、契約前に書面で定めます。

フェーズ3:データモデル設計・連携設計・開発

データモデルでは、項目名や型、必須か任意かを決めたうえで、コードや入力制約も定めます。さらに、履歴や廃止状態、ソースごとの優先順位も決めておきます。たとえば、顧客であれば法人番号や住所を確認します。

製品の場合は、品番や単位、販売状態など、ドメイン固有の属性を洗い出します。また、名寄せで自動化する範囲も決めます。

  • 照合方法:完全一致、表記正規化、住所や電話番号の分割、類似度による候補抽出。
  • 人手確認:自動判定しない候補のスコア帯を決める。

連携設計では、登録・変更・廃止のイベントを、どの方向へどの頻度で配信するかを定めます。リアルタイムAPIと夜間バッチを使い分けます。

エラー時の再送や重複配信、順序の逆転、受信側の停止も想定しておきます。開発データには、欠損や旧字体、住所変更のほか、統廃合、廃番、同一企業の別拠点も入れます。

個人データを扱う場合、最小権限、多要素認証、通信・保存時の暗号化、操作履歴を要件にします。さらに、バックアップと復旧テストも必要です。

フェーズ4:テストと移行リハーサル

テストでは、機能に加えて、データ品質、連携、権限、性能を確かめます。名寄せでは、判定の結果ごとにケースを用意します。

  • 統合する:正しくまとめられるケース。
  • 統合しない:別データとして残すケース。
  • 判定を保留する:人手確認へ回すケース。
  • 業務受入:申請、承認、差し戻し、変更、廃止、検索を行う。
  • 障害時対応:配信エラーからの復旧を行う。

適合率と再現率の両面で、名寄せの判定精度を確認します。さらに、業務部門に実際に操作してもらい、手順書では見えにくい運用負荷も把握します。

本番相当のデータで、少なくとも複数回の移行リハーサルを行います。そのうえで、移行前後の件数、重複数、必須項目の充足、コード変換を照合します。関連データの参照整合性も確認します。

差異の許容範囲と承認者を決めます。また、切り戻し条件、凍結期間、旧システムの参照方法、問い合わせ窓口も確認します。これらが未決なら、テスト完了とは扱いません。

受入基準は数値で定めます。未解決課題には、重要度と解決予定日を添えます。

フェーズ5:段階稼働と業務切り替え

全社一斉に切り替えるより、対象ドメインや部門を限定した段階稼働が向いています。先行部門で運用状況を確認し、問題がなければ、次の部門や連携先へ拡張します。

  • 稼働状況:登録ルール、承認時間、配信遅延、問い合わせ件数。
  • 並行稼働:新規登録の正とするシステム、変更窓口、同期の停止条件。

本番切り替え当日は、データをバックアップしてから移行結果を照合します。次に、連携ジョブや権限、監視アラートを確認し、利用者へ連絡します。

稼働直後は、問い合わせ窓口と判断のエスカレーション先を用意します。これは、現場が旧Excelへ戻るのを防ぐためです。完了の条件は、業務が新ルールで動き、KPIを測れる状態になったときとします。

フェーズ6:運用定着と継続的な品質改善

MDMは稼働後に価値が決まるため、データスチュワードが日々、重複候補や登録申請、変更依頼、配信エラーを確認します。月次または四半期で、品質KPIをレビューします。品質KPIは、次の観点に分けて設定します。

  • データ品質:重複率、必須項目の欠損率。
  • 業務速度:登録から承認までの時間、更新遅延。
  • 運用状況:配信エラー、手動修正、問い合わせ件数。

導入前の基準値と比べて改善しない指標があれば、その原因を調べます。ルール、画面、教育、連携のどこに問題があるかを切り分けます。

商品や取引先が増えたときに、例外運用が積み重なるのを防ぎます。このため、データ定義と承認ルールの変更を管理する仕組みを設け、判断基準や名寄せ例、廃止ルールを文書に残します。担当者の異動に備えて、障害対応やエクスポート手順も同じ文書に加えます。

IPAは2025年の考察で、生成AIなどの技術進展を背景に、データ整備・管理の重要性が高まっていると整理しています(出典:IPA「データマネジメントに関する調査考察」、2025年)。AI活用を急ぐほど、元データの品質と責任の所在を定期的に見直す必要があります。

ポイント

迷ったときは、責任者と合格条件が決まっているかを確かめてから次の工程へ進みます。責任者が曖昧なままだと、設計以降で同じ議論が繰り返されやすくなります。

マスターデータ管理システム(MDM)の費用相場とコストの内訳

MDMの小規模、中規模、大規模の初期導入・開発費の推定レンジを比較した横棒図。
規模が上がるほど、費用レンジの上限も広がります。

MDM費用は、ライセンスやSaaS利用料に加えて、データの洗い出しやクレンジング、名寄せにも左右されます。移行、連携、教育の作業も費用を変えます。さらに、稼働後のデータスチュワードの運用も費用を左右します。

国内のレンジは、一般的な基幹システム案件の公開情報を、MDM向けに補正した推定目安です。この推定目安はリサーチノートに基づくもので、個別案件の正式な見積もりとは異なります。比べる際は、対象ドメイン、件数、連携本数、品質、運用体制をそろえてください。

規模別の初期導入・開発費の目安

小規模は、顧客または製品の1ドメインと、接続2〜3システムが目安です。規模は、対象ドメインの数と接続システムの数で分かれ、推定レンジは小規模、中規模、大規模の3段階で示します。

  • 小規模:500万〜1,500万円。要件整理、診断、基本設定、初回移行、APIまたはCSV連携、テストを含む想定。
  • 中規模:1,500万〜4,000万円。1〜3ドメイン、4〜10システム、複数部門と複数回の移行リハーサルを想定。
  • 大規模:4,000万円〜1.5億円以上。複数ドメイン、国内外拠点、10システム超などを含む場合。

小規模は数万〜数十万件を想定しています。既存システムの項目定義が整い、名寄せ例外が少なければ、レンジの下側に寄ります。Excelや個別コードが多い場合は、上側に寄ります。

中規模では、名寄せルールや承認ワークフロー、データハブに加えて、権限と品質ダッシュボードも含みます。大規模では、数百万件の移行、24時間運用、高可用性、複雑なERP連携が重なる場合があります。

大規模案件は構想策定から個別に見積もります。これらは推定レンジであり、特定金額を保証するものではありません。

ライセンス・移行・連携・運用の費用の分け方

見積書は、製品利用料から稼働後の費用まで、項目ごとに分けて確認します。移行の対象件数や対象項目、除外データ、手動確認件数を明記してもらいます。加えて、リハーサル回数も書いてもらいます。

  • 製品・初期導入:ライセンスやSaaSの利用料、設定と支援作業。
  • データ整備・名寄せ:プロファイリング、クレンジング、照合ルールの作成。
  • 移行・連携:初回のデータ投入、外部システムとの接続。
  • テスト・教育:検証作業と、利用者向けの研修。
  • 保守・運用:稼働後の対応作業全般。

データの整理や名寄せを「移行作業一式」にまとめてしまうと、品質改善の難易度や追加費用の条件が見えにくくなります。

公開価格の上限感を示す例として、IBMのInfoSphere Master Data Managementには、クラウド管理型の本番プランがあります。小規模は月額31,000米ドル、中規模は51,000米ドル、大規模は80,000米ドルです。

開発・テスト環境は月額19,000〜25,000米ドルです(出典:IBM「InfoSphere Master Data Management – 料金体系」、確認時点の参考価格)。1米ドル=150円で機械的に換算すると、本番は月465万〜1,200万円相当です。税、地域、契約条件を含まない参考値です。

国内の小規模案件へは当てはめず、エンタープライズ製品のライセンス上限を考える材料にします。

開発・導入期間と社内工数の見方

期間は規模によって異なります。規模別の全体目安を確認したうえで、小規模案件では各工程の期間も見積もります。

  • 小規模:4〜8か月。
  • 中規模:8〜15か月。
  • 大規模・グローバル:15〜24か月以上。

小規模でも、現状調査とプロファイリングに1〜2か月かかります。次に、設計・設定・連携に2〜3か月、移行・受入・教育に1〜2か月ほどを見込みます。

部門間で定義の合意が難しい場合、開発会社の作業を増やしても短縮できません。そのため、意思決定会議の頻度と社内レビュー期間を計画に入れます。

費用に含まれない社内工数にも注意が必要です。項目定義や名寄せ確認、受入テスト、承認ルールの決定は、自社側の作業です。

利用者教育と稼働後の品質レビューも、社内工数に含まれます。外注費を抑えても、社内確認が遅れると納期が延びます。

そこで、役割分担表を作り、誰が何営業日以内に判断するかを合意します。こうしておくと、遅延の原因を早く特定できます。

ポイント

費用は、ライセンス料だけでなく、移行や連携、運用の作業まで分けて比べます。推定レンジは個別見積もりではないため、対象ドメインや件数、連携本数をそろえてから見ます。

マスターデータ管理システムの見積もりを取る際のポイント

MDMの見積もりは、前提をそろえ、作業範囲と除外範囲を分けてもらうと正しく比べられます。製品名と総額を並べても、前提の違いは見えにくいためです。

対象ドメインやデータ量、品質、連携数を同じ前提で提示します。さらに、業務ルールやセキュリティ要件、導入後の体制も示します。

安い提案は、データクレンジングや移行リハーサルを含まない場合もあります。成果物と受入条件まで確認してください。

RFPや要件一覧の記載項目

発注前に要件一覧を作り、決まっていない項目には状態を付けます。空欄のままにせず、「提案で確認」「PoCで判定」「将来対応」などと記します。

  • データ:対象ドメイン、目的、項目・件数・増加見込み、現行システム、正の候補、コード変換。
  • 業務ルール:名寄せ基準、登録・変更・廃止の承認、利用者・権限、連携の方向・頻度・方式。
  • 運用面:性能・可用性、ログ、バックアップ、復旧、移行、切り戻し、教育、保守。

品質KPIは、重複率や欠損率、登録リードタイム、配信成功率、復旧時間、手動確認件数などから選びます。経営課題に結び付けることが重要です。

たとえば、月次集計の手作業を減らすなら、集計準備時間とデータ差し戻し件数を基準値にします。KPIを決めていないと、稼働後の評価が感想に留まり、追加投資の判断もできません。

複数社を同じ条件で比較する方法

候補会社には、同じデータサンプルと業務シナリオを渡して比較します。

  • デモ:名寄せ結果、手動確認件数、登録から配信までの時間、例外処理。
  • 評価軸:機能、実績、提案体制、価格、定着、セキュリティ、契約の柔軟性。
  • 類似実績:同じドメインやデータ量、ERP・CRM連携の経験。
  • 契約方式:調査・要件調整を含む初期診断は準委任。範囲と受入基準が固まった設定・連携は請負。
  • 契約条件:追加連携、再移行、仕様変更、製品更新、障害対応、引き継ぎの費用負担を記す。設計書、データマッピング、名寄せルールを納品物に含める。

失敗しやすいポイントとセキュリティの確認

失敗を避けるには、計画範囲、名寄せの責任、稼働後の評価を確認しておきます。

  • 対象を広げすぎる:定義や移行が増え、テストと教育が遅れます。
  • 責任者を決めない:候補が保留され、品質が改善しません。
  • 稼働日をゴールにする:KPIや予算が不足し、旧運用へ戻るおそれがあります。

個人データを扱う場合は、取得と利用、保存と提供、削除の順に、目的と期間を整理します。アクセス権限、委託先、監査、漏えい時の連絡は、データマップと規程に記します。

個人情報保護委員会のガイドラインは、委託先が委託元に求められるものと同等の安全管理措置を実施することを、選定時に確認するよう示しています(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」)。

電子取引データや請求・会計データと連携する場合は、国税庁の電子取引データ保存要件を確認します。そのうえで、検索性や改ざん防止、証跡が連携の過程で欠けないようにします。

ポイント

見積もりは、前提と作業範囲をそろえてから比べます。総額が低いときは、クレンジングや移行リハーサルが含まれているかを、成果物と受入条件とあわせて見ます。

よくある質問(FAQ)

費用や期間は企業ごとに異なるため、質問ごとに判断の考え方と、発注前に確認したい条件を示します。

MDMは小規模企業でも導入できますか?

導入できます。全社展開は避け、顧客か製品の1ドメインと2〜3システムに絞ります。データ品質と登録業務の改善を測れば、費用と運用負荷を抑えやすくなります。

SaaSや既存クラウド基盤、CSV連携から始める方法もあります。効果を確認してから、API連携や対象ドメインを広げられます。

MDMの開発・導入にはどのくらいの期間がかかりますか?

目安は小規模で4〜8か月、中規模で8〜15か月、大規模・グローバルで15〜24か月以上です。重複や欠損の多さ、部門合意、連携本数によっても変わります。

移行リハーサルの回数や、受入テストに参加できる社内メンバーも影響します。要件整理の段階で意思決定者とレビュー期限を決めておくと、期間の短縮につながります。

AIで名寄せすればMDMの導入作業は簡単になりますか?

AIや類似度アルゴリズムを使う場合は、候補を提示する部分と、統合を判断する部分の運用を分けて考えます。

  • 自動化の範囲:候補提示は効率化できても、正しい統合の責任まで自動化できるとは限らない。
  • 誤判定の例:似た法人名や住所でも別会社、似た商品名でも別規格の場合がある。
  • 運用記録:学習・判定データ、信頼度、確認者、採否履歴を残し、人手確認の基準と誤統合を戻す手順を決める。

MDMとPIMやDWHはどのように使い分けますか?

目的とデータライフサイクルに応じて、各基盤の役割を分けます。

  • MDM:顧客や製品の共通マスターを正確に定義・統合・管理し、業務システムへ配信。顧客統合やコード管理を担う。
  • PIM:主に商品情報を販売チャネル向けに豊富化・配信。商品説明や画像をECへ届ける。
  • DWH:業務データを蓄積して分析。過去実績の分析を担う。

まとめ

MDM開発は、要件整理、選定、設計、テスト、稼働、定着の6段階で進みます。まず対象ドメインを絞り、欠損率や重複率、更新遅延を測ります。

次に、データオーナーと品質KPIを決め、自社データのPoCで名寄せ精度と現場の確認負荷を検証します。そのうえで、移行や連携を含む総費用をもとに、方式と発注先を比べます。

成功の要点は、データと運用の同時設計

データ定義や重複判定の責任は、製品機能とは別に決めておく必要があります。登録・変更・廃止のルールや承認者、例外処理、配信エラーからの復旧を設計します。

教育と監査も業務設計に含めます。規模別の推定費用は、小規模で500万〜1,500万円、中規模で1,500万〜4,000万円、大規模で4,000万円〜1.5億円以上です。ライセンス、移行、連携、保守を分けた見積もりで、精度を高めます。

最初の一歩は対象ドメインのデータ診断

まず対象データを診断し、候補会社への相談に必要な条件をまとめます。

  • 対象を診断:影響が大きいドメインを選び、2〜3システムの項目、件数、品質、更新経路を一覧にする。
  • 発注条件を整理:MUST要件、KPI、PoC判定条件、移行範囲、社内の意思決定者をまとめ、前提をそろえた提案を受ける。
  • 段階的に進める:小さく品質を測ってから対象を広げ、MDMの定着につなげる。

▼全体ガイドの記事
・マスターデータ管理システム(MDM)開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。