データ管理システム開発の開発期間・スケジュール・納期について

データ管理システムの開発期間は、対象データの品質と連携するシステム数で変わります。MDMは方式によって投資規模と複雑さが異なるため、採用方式を見極めて段階的に進めます。

期間の目安や工程、MDM特有の要因を押さえておくと、情報システム部門の予定づくりに役立ちます。全体像は完全ガイドもご覧ください。

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

データ管理システム開発期間の全体像

データ管理システムの開発期間に関わる要因を示す図解。
見積もりでは方式とデータの実態を合わせて確認します。

データ管理システム(マスターデータ管理、MDM: Master Data Management)の期間は、対象マスタの種類と連携システム数で変わります。さらに、採用するアーキテクチャ類型も期間を左右します。

方式別に見ると、既存システムのデータを変えずにIDを紐付けるレジストリ型は3〜6ヶ月が目安です。一方、データ集約型とシステム共存型は6〜12ヶ月、マスタ配信型・トランザクション型は12〜24ヶ月以上かかります。

大規模なSAP Master Data Governance(MDG)の導入では、企業規模を問わず18〜24ヶ月かかることが一般的とされます。また、全社的なデータ統制を目指すプロジェクトほど、期間は長くなる傾向です。

プロジェクトによっては、期間に数ヶ月から2年以上を要することもあります。なお、Google Cloudのマネージドサービスによるシンプルな内製構築や、専業ベンダーの移行支援パッケージを活用する方法もあります。こうした方法では、最短2〜3ヶ月で導入するケースも増えています。

一般的な業務システム開発と異なり、期間を大きく左右するのは、画面や機能より、データ品質と統合の難易度です。要件定義で綿密に計画しても、集約後に表記ゆれ・重複・欠損が想定以上に見つかることがあり、クレンジングや名寄せの工数が膨らみます。

アーキテクチャ類型の選定と並行して、対象データの実態を早く把握することが、精度の高いスケジュールを立てる前提になります。

アーキテクチャ類型別の開発期間の目安

MDMのアーキテクチャは、主に4つの類型に分かれます。類型ごとに、導入期間や費用感、既存システムへの影響が異なります。

  • レジストリ型:既存データは残したまま、ID同士の紐付けを管理する形式です。
  • データ集約型:データを集約・クレンジングし、分析向けに一元管理する形です。
  • システム共存型:MDMと各システムが双方向に同期し、どちらからも更新できます。
  • マスタ配信型・トランザクション型:MDMを唯一の管理元とし、全システムが参照・更新する方式です。

レジストリ型は、単一ドメインに絞れば3〜6ヶ月、数百万円〜1,000万円程度で構築できます。既存システムへの影響を抑えやすい方式です。

データ集約型は6〜12ヶ月程度、システム共存型は6〜12ヶ月、1,000万円〜数千万円が目安です。共存型は、既存業務を維持しながら品質を高められ、中規模導入の標準とされています。

マスタ配信型・トランザクション型は12〜24ヶ月、数千万円〜1億円以上の大規模プロジェクトになります。統制レベルを高められるものの、全システムの改修が必要です。

目指す類型によって、見積もる開発期間の桁が変わります。このため、発注側は期間と費用の両方を踏まえて類型を選びます。

開発期間を左右する変数

同じシステム共存型でも、導入が6ヶ月で済む場合と12ヶ月かかる場合があります。そこで、差を生む主な変数を、要件定義の段階で洗い出します。

  • 元データの品質(最大の影響要因):表記ゆれ・重複・欠損が多いほど、名寄せやクレンジングに時間がかかります。
  • マスタドメイン数とシステム数:統合対象が増えると、設計・実装・テストの工数が増えます。
  • データガバナンスの成熟度:データオーナーやデータスチュワードの役割が社内にあるか、新設するかで、運用ルールの策定期間が変わります。
  • ツールと既存システムの親和性:ERPやCRMとの連携実績がある製品は、インターフェース開発を圧縮できます。

顧客マスタや取引先マスタの品質によっては、名寄せとクレンジングだけで数ヶ月かかることもあります。まず、対象データの状態を確認してから、納期を見積もります。

ポイント

期間は、対象データの品質、連携するシステム数、採用する類型で変わります。目指す類型の目安で見積もりの桁を決め、期間を左右する変数を確かめてから予定を組むと、判断の材料になります。

要件定義から本番稼働までの工程別スケジュール

中規模プロジェクトの3工程と、それぞれの期間目安を並べた図解。
工程の中では設計・開発に最も長い期間を見込みます。

期間を見積もるには、プロジェクトを工程に分け、時間の配分を把握します。従来のウォーターフォール型では、設計約20%、実装約60%、テスト約20%が一般的でした。

近年はAI駆動開発(仕様駆動開発)が普及し、人間が要件定義とビジネスロジックの検証に集中する形へ移りつつあります。

AI駆動開発では、設計・レビューに全体の60%以上(設計8割・実装2割程度)を割き、全体の工期を30〜70%短縮するケースもあります。

開発期間がおよそ8ヶ月のシステム共存型・中規模プロジェクトを例に、工程ごとの予定を示します。

要件定義・アーキテクチャ選定フェーズ

要件定義・アーキテクチャ選定は、開発の成否を左右する上流工程で、期間の目安は1〜1.5ヶ月です。

  • 対象範囲:顧客・製品・組織・取引先などの対象ドメインと、連携システムを決めます。
  • 方式:4つのアーキテクチャ類型から、採用する方式を選びます。
  • 体制:データオーナーやデータスチュワードなど、ガバナンスの骨子を合意します。
  • 品質確認:対象データのサンプルを見て、実態を早い段階でつかみます。

全社統合を一度に目指すビッグバン導入は、対象範囲が広がり、関係部門との調整が長期化しがちです。そこで、特に重要な1〜2のマスタドメインに絞ると、後工程の手戻りを防ぎやすくなります。

設計・開発(データモデル・名寄せロジック実装)フェーズ

設計・開発は全体工数の中で最も比重が大きく、中規模プロジェクトでは4〜5ヶ月程度を見込みます。

  • データモデル:項目定義や階層構造を設計します。
  • 名寄せロジック:完全一致・ファジーマッチング・AIスコアリングの組み合わせを決めます。
  • 連携仕様:既存システムとのインターフェースを定義します。
  • ガバナンス:変更申請から影響分析、承認、展開までの流れを決めます。
  • 構築:MDMツールや基盤を設定し、名寄せエンジンとAPI・バッチ連携を実装します。

クレンジングや名寄せのロジックは、実データで試行錯誤しながら調整する前提で進めます。このため、2週間〜1ヶ月単位のスプリントで精度を確かめる、アジャイル的な進め方が適しています。

テスト・データ移行・運用開始フェーズ

テスト・データ移行・運用開始には、1.5〜2ヶ月程度を見込みます。特に、データ移行の正確性は慎重に確かめます。

  • 移行データ:移行前後のレコード数や主要項目の値を照合します。
  • 名寄せ結果:統合レコードが業務上正しいか、データスチュワードが確認します。
  • アクセスと連携:権限の設定と制御、外部システムとの接続をテストします。
  • 運用開始:重要度の高い部門やドメインから、まず一部で稼働させます。

パイロットで運用上の課題を洗い出し、そのうえで対象を段階的に広げます。全部門へ一斉に展開するより、失敗を避けやすい進め方です。

ポイント

工程の配分は、設計・開発に最も長い期間を割く想定です。要件定義からテスト・移行までの各工程を、この配分に照らして見ると、どこで時間が足りなくなるかを早く見つけられます。

マスターデータ管理特有の期間要因

開発期間を見積もる際は、一般的な業務システム開発にはないMDM固有の工程を見落としがちです。とくに期間を左右するのは、データクレンジング・名寄せと、データガバナンス体制の構築です。

データクレンジング・名寄せに要する期間

開発期間の中でも、データクレンジング・名寄せは見通しにくい工程です。実データに適用して初めて分かる例外が多く、ロジックの調整に時間がかかることがあります。

  • 完全一致:メールアドレスや法人番号など、一意の項目を使うルールベースの判定方法です。
  • ファジーマッチング:「株式会社〇〇」と「(株)〇〇」などの表記ゆれを、レーベンシュタイン距離やTF-IDFで見分けます。
  • AIスコアリング:会社名・住所・電話番号などから、同一性を確率的に判定します。

外注時の機械処理期間は、1万件規模で1〜2週間、10万件規模で2〜4週間、100万件規模で1〜2ヶ月程度が目安です。ただし、判定ロジックを業務に合わせて磨く反復作業は、この期間に含まれません。

反復作業まで含めると、さらに時間がかかります。例えば、名寄せとクレンジングだけで半年かかったケースもあります。この工程を過小評価すると、全体の予定の信頼性が損なわれます。

データガバナンス体制構築に要する期間

MDMツールの導入と名寄せが終わっても、運用体制がなければ、データは再び乱れていきます。このため、ガバナンス体制の構築も期間の見積もりに含めます。

  • データオーナー:データドメインの方針決定に責任を持ちます。
  • データスチュワード:データ定義の標準化や品質基準の策定を担います。
  • データキュレーター:実際のデータ整備を受け持ちます。
  • 運用ルール:変更申請から影響分析、承認、展開までの流れと監査ログを整備します。

DAMA-DMBOKなどの枠組みに沿って役割を整理し、RACI(責任分解マトリクス)で明確にします。

体制づくりには、システム開発と並行して2〜3ヶ月程度かかるのが一般的です。

体制は、システム完成後に本番運用へ移るための前提になります。だからこそ、要件定義の初期段階から、システム開発と並行して着手します。

ポイント

MDM特有の期間は、データクレンジング・名寄せと、データガバナンス体制の構築で膨らみがちです。この2つを見積もりに入れないと、全体の予定の信頼性が損なわれます。

開発手法による期間差

ウォーターフォール型とアジャイル型について、向く案件を左右に比較した図解。
変更の少なさと実データでの検証が選択の目安になります。

名寄せロジックは、実データで精度を高めていく作業です。仕様を固めるウォーターフォール型か、反復するアジャイル型かで、期間とリスクの取り方が変わります。

ウォーターフォール型が向くケース

ウォーターフォール型は、要件定義・設計・開発・テストの順に進めます。最初に範囲と仕様を固めるため、予算と予定を立てやすく、変更が少ないプロジェクトに向いています。

  • 対象マスタが明確:変更が少なく、先に仕様を固められる場合に適します。
  • 大規模な基幹系:金融機関や製造業のマスタ配信型・トランザクション型で、上流工程の設計を固めてから開発できます。

大規模な基幹系では、データモデルの変更が既存の会計・生産システムに広く影響します。このため、上流で設計を固める進め方が適しています。

一方で、名寄せの精度検証で想定外の例外が多数見つかると、設計の手戻りが大きくなります。その結果、全体の予定が後ろ倒しになりやすい点には注意が必要です。

アジャイル型・AI駆動開発による期間短縮

アジャイル型は、短いスプリントで名寄せロジックの実装と検証を繰り返し、精度を段階的に高めます。また、小さく始めることで、手戻りを抑えやすくなります。

  • スモールスタート:1つのマスタドメインでMDMを作り、現場の反応を見て対象を広げます。
  • 仕様駆動開発(SDD):AIにコーディングを任せ、人間は要件定義とビジネスロジックの検証に力を注ぎます。
  • ハイブリッド型:基盤やガバナンスの根幹はウォーターフォール的に固め、名寄せや画面はアジャイルで調整する。

仕様駆動開発では設計・レビューの比重を高め、設計8割・実装2割程度とすることで、全体工期を30〜70%短縮する事例も報告されています。

ハイブリッド型は、実務でバランスの取れた選択肢として選ばれることが増えています。基盤の安定性とロジックの反復改善を両立できます。

ポイント

対象マスタが明確で変更が少ない案件はウォーターフォール型、名寄せの精度を実データで確かめながら進める案件はアジャイル型が目安になります。

納期遅延の典型要因と対策

納期の遅れは、一般的なシステム開発の要因と、MDM特有の要因が重なって起きます。そこで、典型的な原因を事前に把握して対策しておくと、予定の破綻を防げます。

スコープの肥大化(ビッグバン導入)とその対策

一度に全社のマスタ統合を目指すビッグバン導入は、代表的な遅延要因です。対象のドメインやシステムを広げすぎると、部門間の利害やデータ定義の調整に時間がかかります。

その対策として、最初の90日間は重要なドメインに絞り、データ統合と品質改善を素早く進めます。例えば、取引先マスタや顧客マスタだけを対象にします。

パイロット部門で成果を出してから、他部門や他のマスタへ段階的に広げます。そうすることで、ビジネス側の関心を保ち、手戻りリスクを抑える効果もあります。

クレンジング基準の曖昧さによる手戻り

もう一つの典型的な遅延要因は、名寄せ・クレンジングの基準が曖昧なまま開発・外注し、業務に合わないロジックで誤りの指摘を招くことです。本開発に入る前に、業務への適合を早い段階で確かめておく必要があります。

  • 判定ルールを決める:重複は氏名と電話番号で見分け、未入力の項目は空欄のまま残すなど、条件を明記します。
  • サンプルでテストする:少量のデータで2〜3回の検証サイクルを回してから、本開発や本発注に進みます。
  • 移行データを検証する:既存の帳票や現行システムの値と突き合わせ、確認に十分な時間を確保します。

検証工数を軽く見ると、リリース直前に数値の信頼性を問われる問題が見つかりかねません。

ポイント

スコープを重要なドメインに絞り、判定ルールを文書化したうえで、サンプルと移行データの検証を早めに行うことが、典型的な遅延要因への備えになります。

まとめ

ここまで、方式別の目安、工程の配分、MDM特有の期間要因、開発手法、遅延対策を見てきました。

期間を左右するのは、対象データの品質、名寄せロジックの検証、データガバナンス体制の構築です。これらのMDM固有の要因は、要件定義の段階から予定に織り込みます。

遅延の主な原因は、スコープの肥大化とクレンジング基準の曖昧さです。その対策として、90日単位のスモールスタートと、判定ロジックの早期文書化があります。

まず対象データの実態を把握し、複数の開発会社やMDMベンダーに要件概要を提示します。そのうえで、アーキテクチャの選定を含む見積もりとスケジュールを比較します。

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

会社紹介

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

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

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

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

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

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