MDMの発注は、対象データと責任者を決め、RFPと契約条件を整えてから進めます。
まず発注範囲と形態を決め、要件を整理して委託先を選びます。さらに、小規模な診断やPoCから導入と運用へ段階的に進めると、見積の比較と品質改善につながります。
▼全体ガイドの記事
・マスターデータ管理システム（MDM）開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
マスターデータ管理システム（MDM）の発注で最初に決めること
最初に決めるのは、対象ドメインと正とするデータです。接続先のシステム、業務上の責任者、導入後に測る効果も、この段階で決めておきます。
「顧客と商品を全部統合したい」と曖昧に依頼すると、各社の前提が異なり、金額も納期も比べられません。そこで、全社の全データを一度に対象にするより、1ドメインと2〜3システムから始める計画が現実的です。
発注対象の分け方（データ・仕組み・運用）
発注範囲は、データ、仕組み、運用の三つに分けて考えます。データには、診断、クレンジング、名寄せが入ります。
仕組みには、製品設定や開発、ERPやCRMとの連携、申請・承認が入ります。さらに、運用には、移行・テスト、教育・保守・品質監視が入ります。
- 部分委託：製品ライセンスは自社で契約し、連携と移行をSIerに任せる形です。
- 一括委託：製品選定からデータモデル、運用設計までを一社に依頼する形です。
部分委託と一括委託では外注の範囲が違うため、どこまで外注するかを明記すると、各社の見積項目を同じ枠で比べられます。
データオーナーと承認者の決め方
MDMは、システム部門だけでは完成しません。顧客、製品、取引先などの各ドメインに、定義を決めるオーナーと、登録や品質確認を担うスチュワードを置きます。例外を承認する業務責任者も、あわせて決めておきます。
正式な会社名は登記情報を優先する、商品単位は販売用と在庫用に分ける、といったルールは業務側が決めます。そのうえで、委託先がそのルールをシステムとワークフローに実装します。
責任者がいないまま発注すると、業務判断まで受託会社が担うことになり、後から仕様変更が増えがちです。
MDMの発注形態（パッケージ・クラウド・スクラッチ）の選び方
形態は、既製品、クラウドサービス、独自システム開発の三つから選びます。機能数よりも、対象データの複雑さと既存システムとの接続を比べます。さらに、変更頻度、運用人材、拡張性も見ておきます。
製品を導入しても、データ定義と名寄せルールが整わなければ、品質は改善しません。そのため、製品と導入支援は分けて評価します。
パッケージ型の標準機能と実績の活用
候補となる製品には、SAP Master Data GovernanceとInformatica MDMがあります。IBM InfoSphere MDMやOracle系製品も候補に入ります。
- 共通機能：標準データモデル、名寄せ、承認、品質管理、監査を利用しやすい製品群です。
- SAP中心のERP：既存ライセンスやパートナー体制との整合が要点です。
- マルチドメイン：大規模な管理では、複数業種やデータモデルへの対応力が比較点になります。
- 標準機能と追加開発：業務を標準機能に合わせれば短期化できる一方、独自画面や例外処理は保守を難しくするため、RFPで区分して回答を求めます。
クラウド型の初期環境と拡張性の確認
クラウド型は、サーバー調達や環境構築の負担を抑えられ、対象ドメインや利用量に応じて拡張しやすい形態です。ただし、月額料金だけで判断せず、移行費用やAPI利用料も確認しておきます。
- 費用と復旧：追加環境、バックアップ、障害復旧、退去時のデータ出力の扱いです。
- 管理と終了：保存場所、再委託先、権限、暗号化、ログ期間、終了時の移行支援の条件です。
クラウド事業者と導入支援会社が、それぞれどこまでを受け持つかを、契約書に反映します。
独自要件が必要な場合のスクラッチ型
独自採番、複雑な承認、特殊な配信が標準製品で難しい場合は、スクラッチ開発やクラウド部品の組み合わせが候補になります。既存業務との細かな整合が必要な場合も、検討の対象になります。
データモデル、名寄せ、権限を作る必要があり、監査ログやAPI、運用画面も加わります。そのため、要件は膨らみやすく、保守要員も欠かせません。まず、「標準機能ではできない」項目が必須か、現行運用の再現かを見直します。
代替案は、標準機能と設定変更で足りる範囲から順に出してもらうと、判断しやすくなります。追加開発や完全独自開発は、その後で比べます。
MDMのRFPと要件整理で記載する内容
RFPは、同じ前提で提案と見積を受け取るための比較条件です。製品紹介を求める資料とは性格が違います。
まず現状と目標、範囲をまとめ、連携と移行の条件を加えます。そのうえで、体制、納期、見積条件を書き込みます。
NTTデータビジネスシステムズの「マスターデータ管理（MDM）サービス」（2026年確認）は、MDM導入の初期段階にデータガバナンス構想を挙げています。また、同サービスは、システム横断のルール整理も重視しています。
現行システムとデータ品質の数値化
現行調査では、システムごとに一覧を作ります。一覧には、システム名、管理部門、項目を書きます。件数、更新頻度、登録経路も加えます。
さらに、コード体系、連携方式、保有期間も一覧に入れます。可能なら、重複率や欠損率も測ります。
このほか、表記ゆれの件数、登録完了までの日数、月次集計の作業時間も測ります。数値が取れない場合は、「未計測」と明記します。委託先のデータプロファイリング範囲と、発注側が渡すサンプルデータを明確にすると、調査工数を見積に含められます。
名寄せ・品質・承認ルールの業務要件
要件には、重複をなくす目標だけでなく、照合キーまで書き込みます。照合キーは、氏名、法人番号、住所から定めます。電話番号や品番、JANコード、仕入先コードも対象です。
完全一致と類似一致の使い分け、人が確認する基準、自動統合を避ける例外を決めます。さらに、申請項目と承認者、差し戻し条件も定めます。また、廃止データや履歴の保存期間も決めておきます。
品質KPIは、重複率や欠損率、連携エラー数などから選びます。登録リードタイムや承認滞留時間も、候補になります。
連携と移行の受入条件
連携要件には、送受信項目と方向、頻度、即時性を書きます。さらに、API・ETL・ファイル方式と再送の扱いを決めます。障害時の通知先と監視担当も、記載しておきます。
移行要件には、対象件数と事前クレンジング、名寄せの確認者を含めます。加えて、リハーサルの回数、並行稼働、切り戻し条件も記載します。
受入テストでは、重複候補や必須項目の欠損、コードの不一致を確認します。連携先の停止、権限外の変更、承認期限の超過も、確認項目に加えます。
MDMの発注から稼働までの進め方
流れは、企画と現状診断から始まり、構想・要件定義を経て製品選定へ進みます。製品が決まると、設計・開発、移行・テスト、教育・稼働の順に進み、稼働後は運用改善に移ります。
特に、製品決定の前に、データ品質と業務ルールを確認します。製品を先に決めて業務を合わせると、不要な機能や追加開発が増えやすくなるためです。
将来のドメイン追加や連携拡張を見据えた設計原則は、小さく始める場合でも残しておきます。
データ診断と小規模PoC
サンプルデータで、表記ゆれや重複、欠損を確認します。さらに、異常値やコードの対応も確かめます。ただし、名寄せは、住所や名称が似たレコードをすべて自動で統合できるとは限りません。
誤統合が請求や出荷に影響する場合は、人が確認する工程を残す設計が必要です。
2〜3システム、数万〜数十万件の代表データでPoCを行い、照合精度と確認件数を検証します。加えて、処理時間と現場負担も確かめます。本開発の前にこの検証を行えば、見積の不確実性を下げられます。
設計・開発でのデータと業務の受入
設計では、まずデータモデルと項目定義、採番を固めます。そのうえで、名寄せやゴールデンレコードの優先順位、権限を決めます。ワークフロー、連携、監査ログも、設計に含めます。
納品物には画面のほかに、ルール定義書やデータマッピングを含めます。API仕様や障害時の再処理、運用手順書も、納品物に入れます。
特に、業務側が項目定義とサンプルデータを段階的に確認すると、設計後半の手戻りを抑えられます。
移行・教育・稼働後の改善計画
移行は、テスト移行、本番前のリハーサル、本番移行の三段階に分けます。確認するのは、件数に加えて項目の意味や名寄せです。さらに、連携先の表示や承認履歴、権限、集計の正しさも確かめます。
稼働前には、登録・変更・廃止の手順と問い合わせ先を整えます。エラーの切り分け方も決めて、スチュワードの教育を行います。その後は、30日、90日、180日などのレビューで、品質KPIと利用状況を見直します。
MDM開発の契約形態（請負と準委任）の使い分け
要件が固まった成果物には請負、調査やPoCには準委任を組み合わせます。さらに、データ整理や継続改善も準委任に含めます。成果物と受入条件を明確にすれば、作業と完成の両方を確認できます。
すべて請負にすると、未確定のデータや業務ルールまで完成の責任を負うことになり、変更費用が生じやすくなります。一方で、すべて準委任にすると、完成の判定が難しくなります。
請負契約の範囲・成果物・受入条件
請負に向くのは、基本設計、確定した画面やAPI、定義済みの連携、合意済みの移行です。契約には、範囲と納期、納品物、検収基準を記載します。さらに、検査期間、瑕疵対応、再移行、仕様変更の扱いも書いておきます。
契約では、「データを正規化する」といった表現より、判定方法まで具体化します。たとえば、欠損項目を一覧にする、合意したルールで補正する、発注側がサンプルを確認する、といった形です。
準委任契約の使いどころ（調査・伴走・運用改善）
準委任に向くのは、現行データを洗い出す作業やガバナンス構想、PoCです。さらに、部門ワークショップや段階的な要件整理、稼働後の品質改善も向いています。
作業時間と体制に加えて、月ごとの成果物と会議体を合意します。さらに、決定事項や課題一覧、翌月計画も合意します。発注側も、決裁者と期限を決めておきます。
委託先に任せきりで会議や資料作成だけが続かないよう、準委任の成果を次の請負範囲として切り出します。
追加費用とデータ所有権の条件
追加連携や件数の増加、再移行、仕様変更が、追加請求になる条件を確認します。さらに、更新や障害対応、時間外作業についても、条件を確かめます。
データやバックアップ、ログの帰属を決めます。マッピングや名寄せルール、設計書、ソースも、取り決めの対象です。管理者アカウントの扱いも、あわせて定めます。
解約時には、データの形式と返却までの日数、移行支援の費用を確認します。さらに、再委託がある場合は、委託先の範囲と所在地、監査、事故時の報告経路も定めます。
MDM開発を外注する費用相場
MDMの費用は、ライセンス料に加えて、作業に関わる費用全体で考えます。データ診断やクレンジング、名寄せ、連携の工数も含めます。移行、教育、保守も対象になります。
ここで示すのは、国内案件の基幹刷新費用と、MDM特有のデータ整理・連携工数を踏まえた、2026年時点の推定レンジです。
小規模は500万〜1,500万円、中規模は1,500万〜4,000万円です。さらに、大規模は4,000万円〜1.5億円以上です（出典：NotebookLMリサーチノート、2026年8月）。
これらは目安で、正式な市場価格ではありません。金額は、対象ドメインや接続数、データ量と品質で変わります。また、拠点数や可用性、運用範囲によっても変わります。
規模別の初期導入費と対象範囲
顧客または製品の小規模案件から複数ドメインの大規模案件まで、規模に応じて初期導入の対象範囲が変わります。
- 小規模の範囲：顧客または製品の1ドメイン、2〜3システム、数万〜数十万件が対象です。
- 小規模の作業：診断、基本設定、初回移行、APIまたはCSV連携、テストです。
- 中規模：1〜3ドメイン、4〜10システム。複数部門の承認、データハブ、権限、品質ダッシュボード、運用設計を含むケースです。
- 大規模の範囲：複数ドメイン、国内外拠点、10システム超、数百万件の移行が含まれます。
- 大規模の運用：24時間運用、高可用性、複雑なERP連携などが加わります。
金額を左右するのは、件数だけでなく、重複判定の難しさと業務部門の確認工数です。
見積の六つの費用項目
費用項目は、製品ライセンスまたはSaaS、初期設定・導入支援、データ診断・クレンジング・名寄せ、外部連携、移行・テスト・教育、保守・スチュワード運用の六つです。
ライセンスが安くても、連携や移行の対象が多ければ初期費用は増えます。また、運用設計を省くと、登録ルールが定着せず手作業が残ります。
一時費用と月次・年次の費用を分けて、3年間の総保有コストで比べます。
公開価格の見方（上限感と条件）
IBMのクラウド管理型料金は、Managed Smallが月額31,000米ドルです。Managed Mediumは月額51,000米ドル、Managed Largeは月額80,000米ドルと示されています。
- 開発・テスト環境：Smallは月額19,000米ドル、Mediumは月額25,000米ドルです。
これらは税や地域差を含まない参考価格です。ただし、料金には件数や取引、環境、高可用性などの条件があります。
料金はIBM InfoSphere Master Data Management公式料金ページで、2026年8月に確認しました。
この数字は、国内企業の一般相場ではなく、エンタープライズ製品のライセンス上限を知る材料として扱います。
MDMの見積書で比べる項目
合計額を比べる前に、各社が同じ作業を同じ条件で見積もっているかを確かめます。そのため、ドメイン、接続先、件数、環境数を揃えます。移行と教育の回数、保守時間、除外事項、前提も同じ条件にします。
「一式」と書かれた項目には、作業内容と担当者、期間を質問します。さらに、成果物と上限工数も確認します。
前提条件と除外項目の横並び比較
前提には、利用者数と対象ドメイン、件数と増加率を書きます。さらに、接続方式、稼働時間、可用性、セキュリティを記載します。移行データの品質と発注側の担当者も、前提に含めます。
除外項目では、追加ライセンスやデータ修正、旧システム改修の有無を確認します。ネットワークや海外拠点、休日作業、再移行、追加研修も、有無を確かめます。
「連携一式」「移行一式」「保守一式」は、項目数や回数が見えにくいため、明細化を依頼します。
工数・体制・成果物の対応
PMや業務コンサルタント、データエンジニアが、どの工程に何日関わるかを確認します。連携やテスト、運用設計の担当についても、どの工程に何日関わるかを確かめます。
人月は、成果物と結び付けて見ます。対象は、要件定義書や項目定義書、マッピング表、名寄せルールなどです。テスト計画、移行結果、運用手順書も含まれます。
発注側のレビュー遅れによる影響、再委託や要員交代、不在時の引き継ぎも、提案の段階で確認します。
3年間の総保有コストと効果の比較
初期費用、利用料、保守の三つに加え、追加環境や連携変更、社内スチュワードの工数も、3年間で合算します。効果は、重複の解消や登録の短縮、請求・出荷エラーの低減、監査の効率化などをKPIにして測ります。
効果は一般事例をそのまま使うのではなく、自社の月間作業時間、エラー件数、関係部門数で算定します。判断は、品質と運用を含む総額で行います。
MDMの委託先の選定基準
委託先は、製品の知名度だけでなく、現状診断から運用定着まで支援できるかで選びます。見る観点は、実績、名寄せと移行、ERP・CRM連携です。さらに、ガバナンス、セキュリティ、管理、保守、見積の透明性も確認します。
製品ベンダー、導入SIer、データ整備会社、業務コンサルティング会社は、それぞれ得意分野が異なります。そのうえで、役割分担も提案してもらいます。
似たドメインとデータ量の実績
「MDM導入実績」があるかだけでなく、どのドメインの実績かを質問します。件数と接続数、名寄せ方法、移行後の品質KPIも聞きます。
同業でなくても、似た課題の経験が役立ちます。たとえば、複数拠点、M&A、海外コード、製造品目、請求先と納品先の分離などです。
可能であれば、匿名化したサンプルデータで照合方法を説明してもらい、実装力を確かめます。
データガバナンスと現場定着の提案力
現場が登録ルールや承認を使わず、Excel管理に戻ってしまうことも、MDMの失敗です。各社には、オーナーの役割や登録・変更・廃止の手順、例外処理を提案してもらいます。さらに、教育や問い合わせ、品質レビュー、KPI報告も示してもらいます。
NTTデータビジネスシステムズは、データハブで集配信をまとめて扱い、MDMと組み合わせて連携の運用・管理コストを減らす考え方を示しています。業務と連携の運用改善まで説明できる会社を、優先して見ます。
提案会での質問の順番
各社には、同じ質問を同じ順番で聞きます。順番は、データリスク、初期診断、標準機能と追加開発の順です。
続けて、移行リハーサル、人手確認、障害復旧を尋ねます。最後に、体制、発注側作業、保守、データ返却を確かめます。
加えて、不明点の説明や、追加調査の方法と費用を評価します。自社の課題がきちんと反映されるか、RFPの前提を保っているかも見ます。
MDM発注時のセキュリティと運用の確認事項
顧客、従業員、取引先の情報を扱うMDMでは、開発中も委託先のアクセス期間と方法を管理する必要があります。
個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」（2026年8月確認）は、安全管理措置や委託先監督の考え方を示しています。
最小権限・MFA・暗号化・監査ログの要件
管理者と一般利用者の権限を分け、委託先のアカウントは必要な期間だけ発行します。さらに、多要素認証や通信・保存時の暗号化を要件に加えます。操作履歴、バックアップ、復旧テストも、要件に含めます。
脆弱性への対応とログの保管期間を決め、データの保持期限と安全な削除の方法も決めます。元データを取得できる権限は、利用者、目的、範囲で制限します。
開発・テスト環境では、本番データをそのまま複製せず、マスキングや匿名化を検討します。
電子取引データと個人情報の連携
請求や会計、受発注のデータを連携する場合は、業務システムの保存要件や証跡が欠けないかを確認します。
国税庁の案内を参照し、どのシステムが何を担保するかを整理します。対象は、検索性、改ざん防止、保存期間、訂正・削除の履歴です（出典：国税庁「電子取引関係」、2026年8月確認）。
法令への対応は、製品機能と業務規程を組み合わせて整えます。取得から削除までの各段階で、責任者と証跡を業務規程に定めます。
稼働後のKPIと担当者の契約条項
稼働後は、重複率や欠損率、連携エラーを定期的に確認します。さらに、登録時間や承認の滞留、手作業の補正件数、問い合わせも見ていきます。月次の報告者と、ルール変更の責任者を決めます。
保守契約に、品質レビューやルール改善、追加ドメインの相談を含めると、稼働後の別発注を減らせます。障害訓練や教育も、契約に含めておきます。
マスターデータ管理システム（MDM）の発注でよくある質問
費用や製品の比較に加えて、発注側の準備と導入後の責任も見ておく必要があります。
MDMの発注費用はどのくらいから検討すればよいですか？
1ドメイン・2〜3システムの小規模な導入でも、診断や名寄せ、移行、連携、テストまで含めると、国内向けの推定レンジは500万〜1,500万円が目安です。
中規模は1,500万〜4,000万円、大規模は4,000万円〜1.5億円以上ですが、正式価格ではありません。
まず、対象ドメインと件数、接続先を整理します。品質や承認、運用範囲も整えたうえで、同じ前提で複数社から見積もります。
MDMは内製と外注のどちらが向いていますか？
業務ルールを決めるオーナーと品質管理の担当は社内に置き、製品設定や連携、移行、専門的な名寄せ設計は外注する分担が現実的です。
既存システムやデータの事情に詳しい人材が社内に十分いて、独自要件も少なければ、内製の範囲を広げられます。
部門の調整やレガシー連携、個人情報の扱い、短期移行が重なる場合は、経験のある委託先を活用します。社内は、意思決定と受入に集中します。
RFPがなくてもMDMの開発会社へ相談できますか？
相談できます。現行システムや対象ドメイン、件数、課題をまとめておくと、提案の精度が上がります。希望時期と予算の考え方も、あわせて伝えます。
要件が未確定なら、診断やPoCを準委任で依頼し、その成果から本開発のRFPを作れます。初回の相談では、成果物と移行の条件を確認します。
AIで名寄せできるなら、データ整理を省けますか？
AIやセマンティック照合は、表記ゆれや重複候補の提示を効率化します。ただし、業務上の正解までは保証しません。
- データ統合：SAPが、マスターデータやポリシー、メタデータを一つにまとめる仕組みです。
- 品質管理：プロファイリング、整合、連結、セマンティック照合、品質監視の組み合わせです。
- 判定ルール：判定基準と、信頼度の低い候補の人手確認を要件に含めます。
- 記録と責任：誤統合を取り消す手段と、判断の履歴、責任者です。
この考え方はSAP Master Data Governance公式ページで示されています（2026年8月確認）。
マスターデータ管理システム（MDM）発注・外注のまとめ
MDMの発注では、対象ドメインと正とするデータ、オーナー、接続先を決めます。そのうえで、品質KPIを定め、形態を比べます。RFPには、データとルール、移行を書き込み、連携やセキュリティ、運用も記載します。
費用は、製品の価格だけでなく、診断やクレンジング、名寄せ、移行、保守まで含めた総保有コストで見ます。
発注前のチェックポイント
まず、対象と件数、システム一覧を確認します。さらに、重複や欠損の把握状況、業務ルール、承認者を確かめます。
連携と移行回数、受入条件、契約の内容を確かめます。追加費用、データ返却、セキュリティ、稼働後のKPIも、あわせて確認します。
各社へ同じRFPを渡し、見積を求めます。見積には、標準機能と追加開発、体制、成果物、除外項目、リスクを含めてもらいます。
小さく発注して品質を測る進め方
全社一括で刷新するより、検証結果を次の投資判断に活かせます。
- 小さく検証：1ドメイン・少数システムで、診断とPoCを行います。
- 品質を測定：名寄せ精度、登録リードタイム、重複率、現場の運用負荷が指標です。
MDMの目的は、データを一つの箱に集めることではなく、信頼できるマスターを継続的に作り、業務システムと意思決定へ届けることです。
課題と責任の範囲を整理して、データ整備から定着まで伴走できる会社に相談します。
▼全体ガイドの記事
・マスターデータ管理システム（MDM）開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。