開発会社3社から見積もりが届いたものの、いちばん安い提案と高い提案で3倍近い差がついている。役員会には来月までに予算を出さないといけないのに、どれが妥当なのか判断がつかない。基幹システムの刷新でいちばん多い相談が、この「金額を比べられない」という状態です。
先に結論をお伝えすると、金額差の大半は開発会社の善し悪しではなく、各社が置いている前提の違いから生まれます。どこまでを見積もり範囲に入れたか、カスタマイズをどれだけ見込んだか、データ移行の作業をどちらが持つか。ここが揃っていない見積もりを金額だけで並べても意味がありません。この記事では、規模別の費用の目安と内訳を整理したうえで、届いた見積もりをどう検算すればいいかを発注側の目線で解説します。
この記事のポイント
- 刷新費用は部分改修の数十万円から全面刷新の1億円超まで幅があり、範囲で決まる
- 初期費用だけで比べず、稼働後の運用保守を足した5年総額で判断する
- カスタマイズ率とデータ移行が、あとから金額を膨らませる二大要因
- 相見積もりは前提を揃えてから比べないと、安い提案ほど後で高くつく
目次
基幹システム刷新の費用相場と内訳
まず、どれくらいの金額感なのかを押さえておきます。ただし基幹システムの刷新費用は「相場はこれくらい」と一言で言えるものではありません。何をどこまで作り替えるかで、桁がひとつ変わります。だからこそ、金額そのものより「何が入っていてこの額なのか」を読む力のほうが役に立ちます。
規模別に見る刷新費用の目安
刷新と一口に言っても、既存システムの一部を直すだけの改修から、業務プロセスごと作り替える全面刷新まで幅があります。公開されている各社の情報を整理すると、おおむね次のようなレンジになります。
| 刷新の規模 | やること | 費用の目安 | 期間の目安 |
|---|---|---|---|
| 部分改修 | 帳票レイアウトの変更、項目追加など | 数十万円〜300万円 | 1〜3か月 |
| 中規模改修 | 機能の拡張、他システムとの連携追加 | 300万円〜1500万円 | 3〜9か月 |
| 全面刷新 | 基盤ごと入れ替え、業務プロセスも見直す | 500万円〜1億円超 | 1〜2年 |
全面刷新のレンジがやたら広いのは、対象にする業務範囲と拠点数で変わるからです。販売管理だけを入れ替えるのか、会計・在庫・生産まで一気にやるのか。単一拠点なのか、海外を含む複数拠点なのか。この2つで金額は簡単に5倍以上動きます。
もうひとつ金額を左右するのが、何をベースに作るかです。パッケージやクラウドERPを導入して業務を製品側に寄せる場合、ライセンス費が中心になるぶん初期費用は読みやすくなります。逆に自社の業務に合わせてゼロから作るスクラッチ開発は、開発工数がそのまま金額になるので上限が見えにくく、同じ業務範囲でもパッケージ導入の2倍以上になることがあります。どちらが正解ということはなく、業務のやり方を変えられるかどうかで選ぶものです。
これはあくまで一般的な目安です。実際の判断は、自社の業務範囲と拠点数を前提にした個別の見積もりで確認してください。ここでの使い方としては、届いた見積もりが自社の規模感から大きく外れていないかを確かめる物差しくらいに考えておくとちょうどいいです。規模別の費用の考え方そのものは、システム開発の費用相場と内訳にも整理してあります。
初期費用の内訳と見落としやすい項目
次に、その金額が何で構成されているかを見ます。基幹システムの刷新にかかる初期費用は、だいたい次の要素に分解できます。
- ソフトウェアのライセンス費（クラウドなら初期費＋月額、オンプレなら買い切り）
- サーバーなどのインフラ費（クラウドに寄せると初期費は減るが月額に乗る）
- 導入支援・要件定義の費用（コンサル的に入ってもらう部分）
- カスタマイズ・アドオンの開発費
- データ移行の作業費
- 教育・マニュアル整備の費用
このうちライセンス費とインフラ費は、クラウドを選ぶかオンプレミスを選ぶかで構造がまるごと変わります。オンプレミスは自社にサーバーを置く前提なので、ソフトウェアの買い切りライセンスとハードウェアの購入費が初期にどんと乗ります。そのぶん月々の支払いは保守費だけになりますが、5年から7年でサーバーの更新時期が来て、また同じような投資が必要になります。
クラウドはその逆で、初期費用が抑えられる代わりに、ユーザー数や利用量に応じた月額が毎月かかり続けます。従業員が増えれば自動的に費用も増える構造です。初期の見積もり金額だけを見るとクラウドが圧倒的に安く見えますが、10年使う前提で足し算すると差は縮まります。どちらが得かは利用人数と使う年数で変わるので、両方の形態で見積もりを取って総額で比べるのが確実です。
提案書の合計金額を見るときは、この6つが全部入っているかを確認してください。安い提案は、たいてい下の3つ（カスタマイズ・データ移行・教育）が「別途お見積もり」になっています。悪意があるわけではなく、範囲が決まらないと出せないから外しているだけなのですが、比較する側からすると同じ土俵ではありません。
段階的に切り替える場合は、並行稼働の期間中に旧システムの保守費と新システムの利用料を二重で払うことになります。半年並行するなら、その半年ぶんの旧システム維持費は刷新プロジェクトの費用として見ておく必要があります。ここを別会計にしていると、予算の枠が知らないうちに膨らみます。
もうひとつ、見積書には絶対に出てこないのに確実にかかるのが、自社側の人件費です。現行業務の棚卸し、要件のレビュー、受入テスト、現場への説明会。これらは全部、社内の担当者の時間で払います。全面刷新なら、担当者1〜2名が1年近く半分以上の時間を取られると見ておいたほうがいいです。役員会に出す資料でここを書いていないと、稼働直前に「現場が回らない」という話になります。
稼働後にかかる運用・保守の費用
初期費用で判断してしまうと、あとで効いてくるのが運用保守費です。基幹システムの保守は年額でかかり、パッケージの場合はライセンス費の15〜20%程度が目安になることが多いです。個別開発なら、開発費に対する割合や、月額固定の保守契約で決まります。
保守費に何が含まれるかは会社によってかなり違います。障害が起きたときの一次対応だけなのか、法改正への対応まで含むのか、軽微な改修が年に何時間ぶん付いてくるのか。この中身を確認せずに年額だけを比べると、安いほうを選んだあとで「その対応は保守の範囲外です」と言われて都度課金になります。契約前に、保守で対応してもらえる作業と、別料金になる作業の線引きを文書でもらってください。
ここで大事なのは、初期費用と運用保守費を足した総額で比べることです。仮にA社が初期3000万円で年間保守300万円、B社が初期2000万円で年間保守600万円だとすると、初期はB社が1000万円安いのに、5年で見ればA社4500万円に対しB社5000万円で逆転します。基幹システムは10年以上使うものなので、この逆転は珍しくありません。
提案を受け取ったら、必ず「5年間の総額でいくらになるか」を各社に出し直してもらってください。この一言を投げるだけで、保守費を安く見せていた提案の実像が見えます。刷新に踏み切るかどうかの判断そのものは、基幹システムのリプレイスの進め方と判断基準で整理しています。
基幹システム刷新の費用が膨らむ理由と抑え方
当初の見積もりから金額が膨らむパターンには、はっきりした型があります。しかもその多くは、発注側が発注前に手を打てるものです。ここでは代表的な2つの要因と、届いた見積もりを検算する方法を見ていきます。
カスタマイズ率が費用を2〜3倍にする
パッケージやクラウドERPを入れる場合、金額を最も大きく動かすのがカスタマイズの量です。目安として、カスタマイズ率が5割を超えると費用が2〜3倍に膨らむと言われます。ある製造業では、特殊な業務フローに合わせて7割をカスタマイズした結果、当初予算の2.5倍になったという事例も報告されています。
なぜここまで跳ねるのかというと、カスタマイズは開発費が増えるだけで終わらないからです。標準機能から外れた部分は、バージョンアップのたびに動作確認と改修が必要になります。つまり初期費用だけでなく、その後10年の保守費まで押し上げます。カスタマイズは「一度払えば終わる買い物」ではありません。
対策はシンプルで、要件を出す前に「業務を製品に合わせられる部分」と「絶対に譲れない部分」を仕分けておくことです。現場に聞くと全部が譲れないものになるので、これは経営判断として上から線を引く必要があります。私が見てきた範囲でも、この線引きを情シス担当者だけに任せているプロジェクトは、ほぼ確実に要件が膨らみます。
データ移行という最大の隠れコスト
もうひとつ、当初の見積もりに入っていない典型がデータ移行です。長年動いてきた基幹システムには、表記のゆれた取引先名、廃止したはずの商品コード、桁数の合わない過去データが必ず溜まっています。これを新しいシステムの形式に整える作業は、地味なわりに工数を食います。
見積もり段階で範囲が決まっていないと、開発会社は「データ移行は別途」と書くしかありません。そのまま契約して開発が進み、移行の段になってから「思ったよりデータが汚い」となり、追加見積もりが出る。これが基幹システム刷新でいちばんよくある予算超過の形です。
防ぐには、見積もりを取る前の段階で、少なくとも次の3つを自社で決めておいてください。移行するデータの範囲（何年分を持っていくか）、いつ時点のデータを本番に載せるか、移行リハーサルを何回やるか。この3つが決まっていれば、開発会社は具体的な金額を出せますし、あとから「聞いていない」が発生しません。
相見積もりで前提を揃えて比べる
ここまで見てきたことを踏まえると、相見積もりでやるべきことははっきりします。金額を並べるのではなく、前提を揃えてから並べる。それだけです。
各社に見積もりを依頼するとき、次の項目については同じ条件を指定して出してもらってください。指定せずに投げると、各社が自分の得意な範囲で切ってくるので、比較そのものが成り立たなくなります。
相見積もりで揃えるべき前提
- 対象業務の範囲（販売・在庫・会計など、どこまでを含むか）
- 拠点数とユーザー数
- カスタマイズをどこまで許容するか（標準機能優先か、業務優先か）
- データ移行の対象範囲とリハーサル回数
- 要件定義をどちらがどこまで担当するか
- 稼働後の保守内容と年額、5年間の総額
- 契約形態（請負か準委任か）と、追加費用が発生する条件
最後の契約形態は見落とされがちですが、金額に直接効きます。請負契約は開発会社が納期と成果物の責任を負うぶん、リスクを織り込んだ見積もりになり、単純な人月計算の1.3〜1.5倍の係数がかかることがあります。安く見える準委任の提案が、実際には途中の仕様変更を全部こちらが負担する条件だった、ということも起こります。安さの理由は必ず確認してください。
比較項目を一から作るのが手間なら、システム開発見積もりチェックシート（危険サインを見抜く60項目）を土台に、基幹システム固有の項目を足す形でも構いません。見積書全般の読み方はシステム開発の見積もりの見方と根拠に整理してあります。
