基幹システムの刷新を検討するとき、

「数千万円をかけてまで入れ替える必要があるのか」

「今のシステムをもう少し使った方がよいのではないか」

と判断に迷うことがあります。

基幹システムの費用は、対象となる業務やデータ量、外部システムとの連携、移行方法などによって大きく変わります。

そのため、公開されている費用相場だけを見ても、自社にとって高いのか安いのか判断するのは簡単ではありません。

さらに、刷新費用だけを見ていると、今のシステムを使い続けるために発生している費用や負担が抜け落ちてしまいます。

基幹システムの予算を考えるときは、

新しくする場合にいくらかかるか

だけでなく、

今のまま3年、5年と使い続ける場合に何がかかるか

も並べて考えることが重要です。

この記事では、基幹システムの費用目安を確認したうえで、「刷新する費用」と「先送りする費用」を比較し、予算を考える方法を分かりやすく解説します。

基幹システム刷新の費用目安

基幹システムの刷新費用は、どこまで変更するかによって大きく変わります。

公開されている相場情報を参考にすると、初期検討では次のようなイメージで考えられます。

刷新する範囲 費用の目安
周辺業務・一部機能の刷新 数百万円〜1,000万円程度
部門単位の刷新 1,000万円〜3,000万円程度
複数部門をまたぐ刷新 3,000万円〜1億円以上
全社基幹システム・ERP刷新 数千万円〜数億円

※あくまで初期検討の目安です。必要な機能、データ移行、外部システムとの連携、開発方法などによって費用は大きく変わります。

たとえば、同じ「基幹システム刷新」でも、

  • 在庫管理だけを変更する
  • 販売管理と在庫管理をまとめて変更する
  • 会計や生産管理まで含める
  • ERPを導入して全社の業務を見直す

では、必要な費用も期間も異なります。

そのため、相場だけを見て「高い・安い」を判断しないことが重要です。

システム開発全体の費用相場や、見積もりの内訳については、以下の記事でも詳しく解説しています。

システム開発の費用相場は？規模別の目安と、見積もりが2〜3倍変わる理由

「刷新費用が高い」だけでは判断できない

基幹システムの刷新には、大きな初期費用がかかる場合があります。

一方で、現在のシステムを使い続ける場合も、費用がゼロになるわけではありません。

たとえば、

  • 毎年の保守費
  • サーバーやライセンスの更新
  • 障害時の調査と復旧
  • 古い技術に対応できる担当者の確保
  • 二重入力や手作業の継続
  • 新しいサービスと連携するための追加改修

などがあります。

さらに、特定の担当者しか仕様を理解していない場合、その人が異動・退職すると、システムを調べるところから始めなければならない可能性があります。

経済産業省の「レガシーシステムモダン化委員会総括レポート」でも、レガシーシステムが新しいデジタル技術の導入を妨げることや、IT資産を把握する重要性などが示されています。

つまり、

「刷新するにはいくら必要か」

だけではなく、

「刷新しなかった場合に何を払い続けるのか」

も確認する必要があります。

まず「今のシステムに使っている費用」を集める

基幹システムの保守費・ライセンス費・改修費などを整理するイメージ

新しいシステムの見積もりを取る前に、まず現在のシステムにどのくらい費用を使っているか確認します。

1. 保守・ライセンス・インフラ費

過去1〜3年分の請求書から、

  • 保守契約
  • サーバー
  • クラウド
  • データベース
  • ソフトウェアライセンス
  • 延長サポート

などを確認します。

これらは毎年発生する費用として比較的把握しやすい項目です。

2. 改修費

過去に行った、

  • 機能追加
  • 不具合修正
  • 法改正対応
  • 外部サービスとの連携

などにかかった費用を確認します。

1回あたりの金額が小さくても、毎年繰り返している場合は、数年間で大きな金額になることがあります。

システム改修の規模ごとの費用や、改修と作り直しの判断については、以下の記事も参考にしてください。

システム改修の費用相場は？見積もりの内訳・高くなる理由と作り直しの判断基準

3. 障害対応に使った時間

障害が発生した場合は、開発会社へ支払った金額だけではなく、

  • 社内で何人が対応したか
  • 何時間業務が止まったか
  • 手作業で代替したか
  • 復旧までどのくらい時間がかかったか

も確認します。

すぐに金額へ換算できない場合は、まず「件数」と「時間」を記録するだけでも構いません。

4. システムの外で行っている手作業

基幹システムだけでは対応できず、

  • Excelへ転記している
  • CSVを加工している
  • 複数システムへ同じ内容を入力している
  • 月末に手作業で集計している

といった作業がある場合、その時間も現在のシステムを使い続けるための負担です。

「先送りする費用」を3年程度で見えるようにする

現在の費用が分かったら、次は「刷新しなかった場合」を整理します。

最初から5年、10年先まで正確に予測する必要はありません。

まずは3年程度を目安に、

  • 現在分かっている固定費
  • 過去に発生した改修費
  • 手作業
  • 障害対応

などを並べます。

3年程度であれば、現在の実績をもとに比較しやすく、社内でも説明しやすくなります。

刷新する費用と先送りする費用を比較するイメージ

たとえば、次のように整理します。

比較する項目 現状維持 一部刷新 全面刷新
初期費用 小さい 中程度 大きい
毎年の保守・ライセンス 継続 一部継続 新環境へ変更
既存システムの改修 継続する可能性 対象範囲を縮小 原則、新環境へ集約
手入力・二重入力 残る 一部削減 業務設計次第
データ移行 ほぼなし 対象部分のみ 広範囲
教育 少ない 対象部門で必要 全社的に必要
将来の追加投資 発生する可能性 分散しやすい 設計次第
将来の変更しやすさ 現状に依存 範囲ごとに改善 設計次第

このように並べると、全面刷新だけが選択肢ではないことも分かります。

新システムの効果を「売上が上がるはず」で計算しない

システム刷新の稟議では、

「生産性が上がる」

「DXを進められる」

「業務効率が良くなる」

といった説明になりがちです。

しかし、それだけでは「本当に数千万円を投資する必要があるのか」を判断しにくくなります。

そこで、できるだけ現在確認できる数字を使います。

たとえば、

  • 月末集計に毎月30時間かかっている
  • 同じ情報を2つのシステムへ入力している
  • 年に何回障害が発生している
  • 障害復旧まで平均何時間かかっている
  • 1回の改修でどのくらい調査期間が必要だった
  • 現在の製品や技術のサポート期限がいつまでか

といった数字です。

「新しくすれば売上が上がるはず」と大きな効果を予測するより、

今、実際に発生している負担がどのくらい減るのか

を基準にした方が、予算の根拠を説明しやすくなります。

刷新を検討しやすいサイン

次のような状態が複数重なっている場合は、単発の改修だけでなく、中長期的な刷新を検討する価値があります。

  • サポート終了が近い
  • 古い技術に対応できる人が少ない
  • 小さな改修でも影響調査に時間がかかる
  • 同じ情報を何度も入力している
  • 外部サービスとの連携が難しい
  • 障害時の復旧に時間がかかる
  • 特定の担当者しか仕様を説明できない

ただし、これらに当てはまるからといって、すぐ全面刷新が必要という意味ではありません。

まずは、

残せる部分

先に変える部分

将来変える部分

に分けて考えます。

予算会議では「3つの案」を並べる

基幹システムの予算は、1つの案だけで提示するより、複数の選択肢を比較できるようにした方が判断しやすくなります。

現状維持・一部刷新・全面刷新の3案を比較するイメージ

案1：現状維持

現在のシステムを利用しながら、必要な改修と保守を続けます。

短期的な支出は抑えやすい一方で、

  • 手作業
  • 保守費
  • 属人化
  • 古い技術への依存

など、現在の問題が残る可能性があります。

案2：問題の大きい部分から刷新

在庫管理や受注管理など、現在特に負担が大きい部分から変更します。

一度に大きな投資をしなくて済む一方、新旧システムを一定期間つなぐ必要が出る場合があります。

案3：全体を再設計

複数部門の業務とデータをまとめて見直します。

初期費用と社内の負担は大きくなりますが、長年積み重なった、

  • 重複作業
  • 個別対応
  • システム間の分断
  • データのばらつき

などをまとめて整理しやすくなります。

予算会議では、単純に3案の金額だけを並べるのではなく、

「この案を選ぶと、何が改善され、何が残るのか」

まで比較することが重要です。

「あと何年使うか」を決めるだけでも判断は進む

すぐに刷新予算を決められない場合は、まず現在の基幹システムをあと何年使うのか決めます。

期限を決めないまま改修を続けると、毎回の修正が「当面の対応」になり、刷新に向けた準備が進まない可能性があります。

たとえば、

  • 2028年度までは現行システムを利用する
  • 2027年度までに現在のシステムや業務を調査する
  • 2028年度から一部業務を切り替える

というように、大まかな期限を置きます。

期限が決まれば、

  • 現行システムの調査
  • 要件整理
  • 予算確保
  • 開発会社の選定
  • データ移行
  • 社内教育

などの準備を逆算できます。

システム開発に必要な期間や、利用開始日から逆算する考え方については、以下の記事で詳しく解説しています。

システム開発に必要な期間や、利用開始日から逆算する考え方については、以下の記事で詳しく解説しています。

システム開発の期間はどれくらい？希望日に間に合わせる準備とスケジュール

まとめ

基幹システム刷新の費用は、一部の業務を見直す場合と、全社システムを再構築する場合では大きく異なります。

そのため、「相場より高いか安いか」だけで判断するのではなく、

刷新する費用

と

今のシステムを使い続ける費用

の両方を確認することが重要です。

特に確認したいのは、

  • 毎年の保守・ライセンス費
  • 継続している改修費
  • 障害対応
  • 手作業や二重入力
  • 担当者への依存
  • サポート期限

です。

これらを、

現状維持

一部刷新

全面刷新

の3案で比較すると、

「高いから延期する」

「古いから全部作り直す」

という二択ではなく、自社の状況に合わせて判断しやすくなります。

まずは、現在のシステムに毎年どのくらい費用と時間を使っているかを整理するところから始めるとよいでしょう。

ご相談・お問い合わせ

現在の課題や予算、利用開始時期などを整理しながら、必要な開発範囲をご検討いただけます。

お問い合わせ

参考情報