システムリプレイス(=老朽化した既存システムを新しい仕組みに置き換えること)の費用は、小規模で500万〜1,500万円、中規模で1,500万〜5,000万円、大規模では5,000万円〜数億円が一般的な目安です。成功の鍵は、開発費だけでなく現行調査・データ移行・並行稼働・教育・廃止まで含めて比較することです。

ただし、同じ利用者数のシステムでも、外部サービスとの連携数、データの状態、停止できる時間、セキュリティ要件によって費用は大きく変わります。本記事では、システムリプレイスを検討する発注者に向けて、相場、方式の選び方、進め方、見積もりの確認項目、開発会社の見極め方を解説します。

システムリプレイスの費用相場と期間

システムリプレイスの予算は、新システムの開発費だけではなく、現行調査から旧システムの廃止までを一つのプロジェクトとして見積もる必要があります。見積書の金額が安く見えても、データ移行や切り替え支援が別料金なら、最終的な支出は大きくなる可能性があります。

規模別の費用・期間の目安

以下は、既存の業務システムを別の仕組みに置き換える場合の一般的な目安です。

規模 想定されるシステム 費用の目安 期間の目安
小規模 単一部門で使う管理システム、外部連携が少ないシステム 500万〜1,500万円 4〜8カ月
中規模 複数部門で利用し、権限管理や複数の外部連携があるシステム 1,500万〜5,000万円 8〜15カ月
大規模 全社基幹システム、大量データや複雑な業務ルールを扱うシステム 5,000万円〜数億円 12〜30カ月以上

既製のSaaS(=インターネット経由で利用する完成済みの業務サービス)へ移行できる場合は、初期費用を抑えられることがあります。一方、24時間停止できないサービス、金融・医療など高い安全性が求められる業務、独自ルールが多い基幹システムは、上記より高額になる場合があります。

開発費は、作業量を示す人月(=1人が1カ月働く作業量)と役割ごとの単価を基に計算されるのが一般的です。人月単価は経験や役割、契約条件により異なりますが、80万〜180万円程度が一つの目安です。例えば40人月のプロジェクトなら、開発作業だけでも数千万円規模になり得ます。プロジェクト管理、クラウド利用料、製品ライセンス料などが別途必要かも確認してください。

リプレイス費用を構成する項目

費用を比較するときは、次の項目が含まれているかを確認します。

費用項目 主な内容 見落としやすい点
現行調査 仕様書、ソースコード、データ、利用状況の確認 資料不足の場合は調査工数が増える
要件定義・設計 新システムで実現する業務と機能の決定 現行機能を無条件に引き継ぐと肥大化する
開発・設定 個別開発、パッケージ設定、外部連携 ライセンス料や連携サービス利用料が別の場合がある
データ移行 抽出、変換、重複整理、移行結果の照合 データ量よりも形式の不統一や欠損が費用を押し上げる
テスト 機能、権限、性能、セキュリティの確認 実際の業務シナリオによる確認が必要
切り替え・教育 移行リハーサル、マニュアル、利用者研修 休日作業や拠点別研修が別料金になりやすい
並行稼働・安定化 新旧システムを同時に動かして結果を確認 二重入力や問い合わせ対応の負担が生じる
旧システム廃止 契約解約、データ保管、サーバー停止 法令や社内規程に応じたデータ保存が必要

現行システムがブラックボックス化(=仕様や構造を把握できる人・資料がない状態)している場合、開発見積もりの前に2〜8週間程度の調査が必要になることがあります。調査費用は規模により50万〜300万円程度が目安ですが、ソースコードやデータベースにアクセスできない場合は、さらに時間がかかります。

また、初期費用だけでなく、TCO(=導入から廃止までにかかる総費用)で判断することが重要です。最低でも3〜5年間について、保守費、クラウド費、ライセンス費、社内運用工数、追加改修費を試算しましょう。初期費用の安い製品でも、利用者数に応じた月額料金や追加開発費により、長期では高くなる場合があります。

リプレイス方式の選び方

最初に決めるべきことは開発会社ではなく、どの範囲を、どの方式で置き換えるかです。現行システムをそのまま作り直すことが常に正解とは限りません。

方式 向いている状況 費用・期間の傾向 主な注意点
現行システムを改修する 問題が限定的で、基盤や保守体制を継続できる 比較的抑えやすい 老朽化や属人化の根本原因が残ることがある
フルスクラッチで再構築する 独自業務が競争力になっており、既製品では対応しにくい 高く、長くなりやすい 現行機能の過剰な再現を避ける必要がある
パッケージ・SaaSへ移行する 業務を標準機能に合わせられる 初期費用と期間を抑えやすい 月額費用、機能制約、データ持ち出し条件を確認する
段階的に置き換える 業務停止の影響が大きく、一括移行が難しい 総額は増えやすいがリスクを分散できる 新旧連携と二重運用が一時的に必要になる

改修で延命するか、リプレイスするか迷う場合は、次の条件で判断します。

改修が向いているケース

  • 問題が特定の画面や機能に限られている
  • 使用している技術や製品のサポートが数年以上継続する
  • ソースコードや設計資料があり、保守できる人材を確保できる
  • 業務そのものを大きく変える予定がない
  • データ構造や外部連携に深刻な制約がない

リプレイスが向いているケース

  • 製品や技術のサポート終了が迫っている
  • 一つの修正が別機能の障害につながりやすい
  • 特定の担当者や開発会社しか仕様を把握していない
  • 事業拡大に対して性能や機能が不足している
  • 部門ごとにデータが分断され、二重入力が発生している
  • 保守費や障害対応費が継続的に増えている

問題が限定的なら、全面的な置き換えより改修の方が合理的な場合もあります。改修範囲の判断や費用については、システム改修の費用相場|見積もり・外注の注意点も参考にしてください。

パッケージやSaaSを選ぶときは、現行業務に合わせて製品を大幅にカスタマイズするのではなく、可能な範囲で業務を標準機能に合わせることが重要です。独自開発を増やしすぎると、製品の更新に追随できず、次回のリプレイスでも同じ問題を抱える可能性があります。

方式を選ぶ際は、経営・業務・ITの3つの観点で、次の質問に答えられる状態を目指します。

  1. リプレイスにより、どの経営課題を解決するのか
  2. 残すべき独自業務と、標準化できる業務はどれか
  3. システムを停止できる時間はどの程度か
  4. 何年分のデータを移行し、何年分を保管だけにするか
  5. 将来、自社で運用・改修する範囲はどこか

システムリプレイスの進め方と依頼前の準備

リプレイスは、現行調査、構想、要件定義、開発、データ移行、切り替えの順に進めます。特に重要なのは、開発会社へ見積もりを依頼する前に、目的と現行資産を整理することです。

ステップ1:目的と成功条件を決める

「古いから新しくする」だけでは、必要な投資額や優先順位を判断できません。経営上・業務上の目的を数値または確認可能な状態で定義します。

例えば、次のような成功条件があります。

  • 月末集計にかかる日数を短縮する
  • 二重入力をなくし、入力元を一本化する
  • 障害時の復旧時間を短くする
  • 新拠点や新サービスを追加しやすくする
  • 特定の保守担当者への依存を解消する
  • 運用マニュアルと権限管理を標準化する

すべての要望を同じ優先度にせず、「必須」「できれば必要」「将来対応」に分けます。初回リリースの範囲を絞ることで、予算超過とスケジュール遅延を抑えやすくなります。

ステップ2:現行システムと契約を棚卸しする

画面や機能だけでなく、契約、アカウント、データ、業務手順まで確認します。開発のご相談を受ける立場では、ソースコードが手元にあると思っていたものの、実際には保守会社の環境から取り出せなかったという相談もあります。

依頼前に、次の資料・情報を確認してください。

  • 現行システムの設計書、画面一覧、操作マニュアル
  • ソースコードとその利用・改変に関する権利
  • サーバー、クラウド、ドメインの管理アカウント
  • データベースの項目一覧、データ件数、サンプルデータ
  • 会計、決済、認証など外部システムとの連携一覧
  • 利用者数、拠点数、繁忙時間、月間処理件数
  • 障害履歴、問い合わせ履歴、定期作業の内容
  • 現行ベンダーとの契約期間、解約条件、引き継ぎ義務
  • 法令や社内規程で定められたデータ保存期間
  • 現行システムを停止できる時間

資料がそろっていなくてもリプレイスは可能ですが、その場合は「分からない項目」を明示し、事前調査の期間と予算を確保します。推測だけで固定金額の開発契約を結ぶと、後から追加費用が発生しやすくなります。

ステップ3:移行方針と対象範囲を決める

機能、データ、利用部門を整理し、一括移行か段階移行かを決めます。すべての過去データを新システムへ移す必要はありません。

データは、次の3種類に分けると判断しやすくなります。

  • 新システムの業務で継続利用するため、必ず移行するデータ
  • 法令・監査対応のため、検索可能な状態で保管するデータ
  • 保存期間を過ぎており、安全に廃棄できるデータ

データ移行の費用は、単純な件数だけでは決まりません。入力形式のばらつき、重複、文字化け、未入力、コード体系の違いを修正するデータクレンジング(=データを正しい状態に整える作業)が必要かどうかで変わります。

ステップ4:要件定義と提案依頼を行う

要件定義(=作るものと満たす条件を決める工程)では、機能だけでなく、性能、セキュリティ、可用性、バックアップなどの非機能要件(=画面機能以外の品質条件)も決めます。

提案を比較する場合は、RFP(=開発会社へ条件を伝える提案依頼書)に次の内容を記載します。

  • リプレイスの背景と目的
  • 現行システムの概要と課題
  • 対象業務、利用者、拠点
  • 必要機能と優先順位
  • 外部システムとの連携
  • 移行対象データ
  • 希望時期と予算の上限
  • 発注者と開発会社の役割分担
  • 納品物、検収条件、保守の希望

依頼資料の具体的な構成は、RFPの作り方|システム開発の依頼準備で詳しく解説しています。

ステップ5:開発・テスト・移行リハーサルを実施する

開発中は、月単位で完成を待つのではなく、画面や業務フローを段階的に確認します。発注者側も、業務責任者、データ確認担当者、最終判断者を決めておく必要があります。

リプレイスでは、通常の機能テストに加えて次の確認が重要です。

  • 主要業務を開始から完了まで処理できるか
  • 利用者ごとの閲覧・更新権限が正しいか
  • 移行前後で件数、金額、残高が一致するか
  • 繁忙時間の処理量に耐えられるか
  • 外部システムとの送受信が失敗した場合に検知できるか
  • バックアップから復旧できるか
  • 現場担当者がマニュアルに沿って操作できるか

受入テスト(=発注者が実際の業務で利用できるか確認するテスト)は、開発会社だけに任せられません。現場で起こる例外処理や締め作業は、発注者側の担当者が確認する必要があります。

ステップ6:本番切り替えと安定化を行う

本番切り替え(=利用者が新システムを使い始める移行)では、作業手順、担当者、判断時刻、連絡経路を事前に決めます。最低1回、重要システムでは複数回の移行リハーサルを行うのが安全です。

次の項目を含む切り替え計画を用意します。

  • 現行システムの入力停止時刻
  • 最終データの抽出・変換・投入手順
  • 移行後の件数・金額・権限の確認方法
  • 利用開始を承認する責任者
  • 問題発生時の切り戻し(=旧システムに戻す手順)
  • 利用者への告知と問い合わせ窓口
  • 旧システムの参照期間と廃止日

一時的な並行稼働(=新旧システムを同時に動かすこと)は安全性を高めますが、二重入力や照合作業の負担も増えます。期間を決めずに続けるのではなく、終了条件と責任者を設定してください。

見積もり・開発会社の見極め方と失敗回避

見積もりは総額だけでなく、前提条件、対象外、発注者側の作業、移行・テストの具体性まで比較します。システムリプレイスでは、安い見積もりよりも「何が未確定で、どの条件なら金額が変わるか」を説明できる見積もりの方が信頼できます。

見積もりで確認する項目

確認項目 確認する質問
現行調査 どの資料・環境を調査し、何を成果物として残すか
開発範囲 必須機能、管理画面、帳票、外部連携が含まれているか
データ移行 対象データ、クレンジング、リハーサル回数、照合方法は何か
テスト 性能、権限、セキュリティ、受入支援が含まれるか
切り替え 休日・夜間作業、問い合わせ対応、切り戻し支援が含まれるか
インフラ・製品 クラウド、ライセンス、外部サービスの料金が含まれるか
成果物 ソースコード、設計書、テスト結果、運用手順書を受け取れるか
保守 保証期間、障害対応時間、月額保守の範囲は何か
対象外 現行ベンダーへの依頼、社内データ整理、利用者教育は誰が行うか

要件が不明確な段階で「一式」とだけ書かれた見積もりには注意が必要です。追加費用の単価、変更の承認手続き、納期への影響も契約前に確認します。

要件定義や現行調査は、準委任契約(=成果の完成ではなく、専門的な業務の遂行に対して報酬を支払う契約)で進め、範囲が固まった後に開発契約を分ける方法もあります。どの契約形態が適切かは、要件の確定度や責任分担により異なるため、契約書は法務担当者や専門家にも確認してもらいましょう。

予算を立てるときは、開発会社の見積金額とは別に、未確定事項へ対応する社内予備費を10〜20%程度確保する方法があります。これは曖昧な追加請求を認めるためではなく、現行調査で判明する連携仕様やデータ不備など、事前に確定しにくいリスクへ備えるための予算です。

開発会社を選ぶポイント

リプレイスでは、新規開発の実績だけでなく、既存システムを調査し、安全に移行した経験が重要です。次の観点で確認してください。

  • 現行調査からデータ移行、旧環境の廃止まで提案できるか
  • 類似する業務・規模・外部連携の経験があるか
  • 不明点を断定せず、調査事項として整理できるか
  • 移行リハーサルと切り戻し条件を具体的に説明できるか
  • 発注者側の作業と必要な社内体制を明示できるか
  • プロジェクト責任者と実際の担当者が確認できるか
  • 開発後の保守、マニュアル、引き継ぎまで支援できるか
  • 将来の内製化や他社への引き継ぎを妨げない契約になっているか

良い提案をする会社は、初回相談から機能の話だけを進めるのではなく、「停止できる時間」「データの照合方法」「現行ベンダーの協力範囲」「社内の承認者」「旧システムをいつ廃止するか」を確認します。

資料が少ない場合や、改修とリプレイスのどちらが妥当か決められない場合は、いきなり開発見積もりを求めず、現行調査と構想整理を先に依頼する方法があります。調査から移行計画まで含めて検討したい場合は、開発のご相談はこちらからご相談ください。

よくある失敗と回避策

よくある失敗 起こる問題 回避策
現行機能をすべて再現する 不要な機能まで作り、費用と期間が膨らむ 利用実績と業務目的から廃止・統合を判断する
データ移行を終盤に始める 欠損や重複が直前に判明し、公開が遅れる 要件定義中にサンプルデータで移行検証する
最安値だけで会社を選ぶ 調査、テスト、切り替え支援が後から追加になる 同じ範囲と前提条件で見積もりを比較する
現場確認が遅い 完成後に業務と合わないことが判明する 業務責任者が段階的に画面と運用を確認する
一括移行だけを前提にする 問題発生時に全業務が止まる 段階移行や切り戻しの可否を検討する
現行契約を早く終了する データ抽出や仕様確認を依頼できなくなる 引き継ぎ完了と安定稼働を確認してから解約する
旧システムを廃止できない 新旧の保守費と運用負担が残り続ける 廃止条件、保存データ、終了日を計画時に決める

発注者が特に誤解しやすいのは、「新システムが完成すれば移行も終わる」という点です。実際には、データ確認、利用者教育、問い合わせ対応、旧システムの停止までがリプレイスです。開発完了日ではなく、安定稼働と旧環境廃止までをプロジェクト期間として計画してください。

まとめ

  • システムリプレイスの費用目安は、小規模で500万〜1,500万円、中規模で1,500万〜5,000万円、大規模で5,000万円〜数億円です
  • 開発費だけでなく、現行調査、データ移行、テスト、教育、並行稼働、旧システム廃止を含めて予算化します
  • 問題が限定的なら改修、標準化できるならSaaS・パッケージ、独自業務が重要なら再構築を検討します
  • 見積もりは総額ではなく、前提条件、対象外、移行方法、成果物、保守範囲を比較します
  • ソースコード、アカウント、データ、外部連携、現行契約を依頼前に棚卸しします
  • 開発会社は、新規開発の実績だけでなく、現行調査とデータ移行、切り替えの経験で選びます
  • 新システムの公開ではなく、安定稼働と旧システム廃止までをリプレイス計画に含めます

よくある質問

システムリプレイスにはいくらかかりますか?

一般的な目安は、小規模で500万〜1,500万円、中規模で1,500万〜5,000万円、大規模で5,000万円〜数億円です。外部連携、データ移行、停止可能時間、セキュリティ要件によって大きく変わるため、現行調査後の見積もりが必要です。

改修とリプレイスはどちらを選ぶべきですか?

問題が一部の機能に限られ、技術や製品のサポートが継続するなら改修が適しています。サポート終了、保守の属人化、障害の頻発、事業拡大への対応不足がある場合は、リプレイスを検討する価値があります。

現行システムの仕様書がなくてもリプレイスできますか?

可能ですが、ソースコード、データベース、画面、操作手順、外部連携を確認する事前調査が必要です。一般的には2〜8週間程度の調査期間を設け、判明した仕様と未確定事項を整理してから開発範囲を決めます。

データ移行で最も注意すべきことは何ですか?

移行後の件数だけでなく、金額、残高、権限、関連データの整合性を業務単位で確認することです。要件定義中にサンプルデータで検証し、本番前に移行リハーサルと問題発生時の切り戻し手順を用意してください。