業務システムのリプレース見積もりが高すぎる時の妥当性を見極める3つの基準

自社の業務システムにちょっとした機能を足したい。その程度のつもりで既存のベンダーに相談したら、「システムが古いので全面的に作り直す必要があります」と数千万円の見積もりが返ってきた。

こうしたご相談は、弊社にも珍しくありません。少し手を入れて使い続けたいだけなのに、ゼロから作り直す前提の金額を示され、「いくらなんでも高すぎる」「これが普通の相場なのか」と戸惑う方は多いです。

先にお伝えしておくと、高額な見積もりがそのまま不当というわけではありません。ただ、提示された金額に見合うだけの目的が自社にあるとは限らず、全面リプレース以外の道が残っていることも多いです。見積もりの妥当性をどう判断し、どこで線を引くか。開発と保守の両方を手がける弊社の立場から整理します。

---

なぜ全面リプレースの見積もりは高くなりやすいのか

本来は数百万円の改修で足りそうな要望に、桁の違う金額が返ってくる。そこには、ベンダーが不当に儲けようとしているという単純な話ではなく、もう少し構造的な事情が隠れています。理由が分かると、見積もりの読み方も変わってきます。

古い技術を保守できる人が減っている

10年前後にわたって動いてきたシステムは、使われている言語やフレームワークが、今では主流から外れているケースが多いです。

開発会社としては、現役の技術を扱えるエンジニアを採用・育成したいのが本音です。古い技術をメンテナンスできる人材を社内に抱え続けるのは、それ自体が負担になります。そのため「古い環境を維持するより、今うちが扱える技術で作り直したい」という力学が、どうしても働きます。

仕様書のないコードは、改修のリスクが読みづらい

開発当時の担当者がすでに退職し、設計書も残っていないという状況は、決して特殊ではありません。

ベンダーから見れば、たとえ自社が過去に作ったものでも、担当者が抜けてしまえば中身の見えないコードに近い状態です。全体像がつかめないまま一部だけ直すと、思わぬ別の場所で不具合が出ることもあります。この不確実性を金額のバッファとして積むと、見積もりはどうしても膨らみます。

段階的な改修は、手間がかかるわりに利益が読みにくい

既存のシステムを生かしながら少しずつ直す進め方は、実は新規開発よりも神経を使います。動いている処理を壊さないための調査が必要で、慎重さも求められます。

手間と不確実性が大きいわりに見積もりは作りにくく、利益も読みにくい。結果として「それなら一度作り直したほうが確実です」という提案に落ち着きやすくなります。

念のため補足すると、これはベンダーが怠けているという話ではありません。ただ、こうした事情は「今の仕組みは大きく変えず、少しだけ直したい」という発注側の要望とは、どうしても噛み合いにくいのです。

---

見積もりが高すぎると感じたときに確認する3つの基準

では、示された数千万円を受け入れるしかないのでしょうか。弊社の経験では、次の3点に照らすと、その見積もりが自社にとって妥当かどうかを判断しやすくなります。

1. 業務フロー自体を大きく変える必要があるか

システムを全面的に作り直すと、多かれ少なかれ現場の業務フローにも変更を迫ることになります。

「これを機に業務のやり方を根本から見直し、標準化して組織を変えたい」という明確な目的があるなら、数千万円の投資も妥当な経営判断になり得ます。一方で、「やり方はそのままに、使い勝手だけ良くしたい」という程度なら、全面リプレースの費用を回収するのは難しく、投資に見合いません。

2. サーバーやOSのサポート切れ（EOL）が迫っているか

EOL（End of Life）とは、ソフトウェアやOSのサポート提供が終了することを指します。既存システムを動かしているサーバーのOSやデータベースのサポートがすでに切れている、あるいは1年以内に切れる場合は、放置できない状態です。

この場合、移行や刷新は待ったなしの課題です。ただし、必ずしもアプリケーション全体を作り直す必要はありません。サーバー環境だけを新しい基盤へ移す「マイグレーション」で、コストを抑えながら危険な状態を解消できる場合もあります。

3. 段階的な改修や部分リプレースの選択肢が示されているか

誠実な見積もりであれば、「全部まとめて数千万円」の一択ではなく、「まず最低限必要な部分だけを数百万円で直し、数年かけて段階的に移行する」といった複数のプランが出てくるはずです。

もし「現状のまま我慢するか、数千万円で作り直すか」という両極端しか提示されないなら、自社の予算や課題よりも、作り手側の都合が優先されている可能性があります。

この3点を判断の早見表にすると、次のように整理できます。

全面リプレースが妥当になりやすいケース	保守・部分改修で足りる可能性が高いケース
業務フローそのものを作り変えたい	業務フローは変えず、使い勝手だけ改善したい
OS・データベースのサポートが既に切れている	環境はサポート期間内、または移行だけで対応できる
機能の大半が今の業務に合っていない	不満が一部の機能や画面に限られている

---

リプレースの費用はどのくらいが目安になるか

費用の相場を一言で示すのは難しく、システムの規模や作り方で大きく変わります。あくまで弊社がご相談をお受けする範囲での感触としてですが、軽微な改修なら数十万円から、部分的な作り直しで数百万円、全面リプレースになると数百万円から数千万円という幅に収まることが多いです。

ここで大事なのは、金額の絶対額そのものよりも、その金額に見合う目的が自社にあるかどうかです。同じ500万円でも、業務のやり方を変える前提なら妥当な投資になり得ますし、使い勝手を少し直したいだけなら割高になります。相場の数字と自社を単純に比べるのではなく、前章の3つの基準とセットで考えると、判断を見誤りにくくなります。

---

全面リプレース以外に残されている「第三の選択肢」

全面リプレースは予算的に踏み切れない。かといって、今のベンダーに思うように動いてもらえないまま使い続けるのも不安だ。そうお考えの場合は、別の開発会社にセカンドオピニオンを求め、保守や改修だけを引き継いでもらうという道があります。

弊社three dots. では、取り残された業務システムを引き取り、保守・改修を継続するサービスを用意しています。全面リプレースを前提とせず、現状維持から漸進的な改善まで、ご予算に合わせて段階的に提案します。

ソースコードと稼働環境から現状を読み解く（診断）

「仕様書がないから他社には引き継げない」と言われることがありますが、諦める必要はありません。設計書が残っていなくても、実際のソースコードと稼働サーバーの状況をエンジニアが直接読み解き、システムの構造を把握します。

優先度の高い不具合とセキュリティから直す（改修）

診断の結果をもとに、業務に支障が出ている不具合や、緊急性の高い脆弱性の対応など、優先順位の高いものからピンポイントで手を入れます。言語やフレームワークが古くても、レガシーな技術を含めて対応します。

月額で運用を支えながら、次の一手を一緒に考える（保守）

一度に多額の投資をするのではなく、月額契約の保守を通じて稼働を安定させます。問い合わせ窓口の設置や軽微な改修を続けながら、システムを将来どうしていくか、中長期の計画を一緒に練っていきます。

---

まとめ

高い見積もりを出されたからといって、その言い値にそのまま従う必要はありません。確認したいのは、業務フローを本当に変える必要があるのか、サポート切れの期限が迫っているのか、段階的な選択肢が示されているのか、という3点です。この3つを起点にすれば、慌てて全面リプレースに踏み切る前に、自社にとって妥当な落としどころが見えてきます。

「高すぎる」という感覚が拭えないまま判断を迫られているなら、一度別の視点で現状を見てもらうところから始めても遅くはありません。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します

/service/system-rescue/