業務システムの改修費用が高すぎる／引き受け先が見つからない時の選択肢

「3社に見積もりを取ったんですが、いちばん安いところでも、聞いていた相場の3倍くらいなんです。しかも全社、最後は『全部作り直しになります』としか言ってこなくて」――業務システムの改修費用の相談で、最近こういったケースは少なくありません。手元には10年以上動いている基幹システムがあり、止まってはいない。ただ、ちょっとした項目を1つ足したい、画面を1枚増やしたい、それだけのはずだったのに、見積もりが想定の桁違いに膨らんで返ってくる。

別のパターンもあります。「そもそも見積もりまでたどり着けない」というご相談です。問い合わせ先に状況を説明した時点で「うちでは難しいです」と返される。3社、5社と当たって、どこも引き受けてくれない。これはこれで、経営判断が止まる困り方です。

業務システムの改修は、費用が高すぎるか、引き受け先が見つからないか、あるいはその両方で詰まることが少なくありません。引き取り側として見ていると、原因は意外と限られた数のパターンに収まります。そして、ほとんどの場合は「全部作り直す」以外に選択肢があります。

「改修費用が高すぎる」「引き受け先が見つからない」が同時に起きる理由

業務システムの改修で行き詰まる相談は、表面の症状が違っても、根の原因が重なっていることが多いです。費用が膨らむ理由と、引き受け先が見つからない理由は、別の問題ではなく裏表の関係にあります。

たとえば、開発当時の技術が古く、それを触れる人が市場に少なくなっているシステムを想像してください。改修を引き受ける側から見ると、調査と検証にかかる時間が読みにくく、慎重に積めば積むほど見積もりは大きくなります。慎重に積めない会社は、最初から「うちでは無理です」と断ります。同じ理由で、ある会社では数千万円の見積もりが出て、ある会社では断られる、という現象が同時に起きます。

加えて、業務システムは「動いている」ことが前提です。改修中に止めるわけにいかず、影響範囲の見切りが甘いと本番業務に跳ね返ります。だから引き受ける側は、改修そのものより、改修しても他が壊れないことを確認する作業に時間を割きます。これが見積もりに乗ると、依頼側からは「なぜこんなに高いのか」に見える。

つまり、改修費用が高い・引き受け先がないという2つの困りごとは、別々の対処を打つよりも、共通の手前で1度立ち止まった方が解けやすい性質を持っています。

なぜ「改修費用が高すぎる」と感じる見積もりが返ってくるのか

見積もりが想定を超えて返ってきたとき、最初に確認したいのは「何にいくらかかっているのか」の中身です。総額の数字だけを見て高い・安いを判断しても、交渉の手がかりが得られません。

中小企業の業務システム改修で、見積もりが大きく振れる原因はいくつかあります。

仕様書がないと、調査工数だけで見積もりの半分以上になる

10年以上動いている業務システムでは、設計書や仕様書が手元に残っていないことが珍しくありません。開発した会社と連絡が取れない、当時の担当者が退職した、紙の仕様書はあるが古い世代のもので今のシステムと合っていない――こうした状態で改修を依頼すると、引き受ける側は「まずシステムの中身を読み解く」ところから始めます。

この読み解きの工数が、改修そのものの工数と同じか、それより大きくなることはよくあります。仕様書のない状態でも段階改修は進められますが、見積もりの観点で言うと、「直したい部分」だけ見て金額を読むと、調査と検証の分が見えなくなります。仕様書がないこと自体は改修を不可能にしませんが、見積もり総額の構成を変えます。

改修のついでに、潜んでいた問題まで直す前提になっている

「項目を1つ足したい」だけの改修依頼に対して、見積もりに「全画面のフレームワーク更新」「データベースのバージョンアップ」「セキュリティ脆弱性の解消」が含まれていることがあります。引き受ける側からすると、古いままの土台に新しい改修を載せると後で壊れる、という判断で前提条件として組み込んでいるケースが多いです。

これは間違った提案ではありません。ただし、依頼側にとっては「項目1つ足すだけのつもりが、家を建て替える話になっている」ように見える。ここでよくあるのは、「全部一度にやる前提」の見積もりだけが返ってきて、「最低限の改修だけならいくらか」が並んで提示されないことです。

引き受ける側のリスクが、料率として乗っている

見積もりに直接「リスク料」と書かれることはほぼありませんが、調査時間の見積もりが厚めに取られている、検証工程の人日が多めに乗っている、というかたちで実質的にリスクが反映されています。古いシステムや、引き取って間もないシステムに対しては、これが大きくなります。

引き受ける側に責任があるわけではなく、未知の領域に踏み込むときの慎重さが、まじめな会社ほど数字に出る、という構造です。相見積もりを並べているフェーズなら、リプレース見積もりの妥当性を見極める3つの基準で別に整理しているので、参考になります。

引き受け先が見つからない時、相手から見えている景色

「3社に当たったが全部断られた」というご相談を受けたとき、まず確認するのは「相手にどう見えているか」です。依頼側からは「うちのシステムを直してくれる会社が見つからない」という1つの問題に見えますが、引き受ける側から見ると、断る理由は何種類かに分かれています。

ひとつは、技術スタックの問題です。古いPHP（4・5系）、VB6、Access VBA、ColdFusion、PerlのCGI、独自フレームワークで書かれたシステム――こうした環境を触れる現役エンジニアは年々減っており、若い開発会社では人材が確保できません。技術的に「やれない」のではなく、自社内に対応できる人材がいない、という理由で断られます。

もうひとつは、調査範囲が見えないことへの不安です。仕様書がなく、ソースコードの所在も曖昧で、ログインに必要なIDがどこにあるかも分からない――この状態で見積もりを出すには、引き受ける側がリスクを丸ごと背負うことになります。慎重な会社ほど、ここで「お断り」を選びます。これは技術力の問題ではなく、リスクをコントロールできるかの問題です。

そして、依頼の規模感です。改修費用が数十万円規模の小さな依頼だと、引き受ける側にとっては固定的なコスト（契約・打ち合わせ・調査の初期コスト）が相対的に重くなり、利益が読みにくくなります。これも断る理由になります。

引き受け先が見つからないと感じたら、断られた理由を相手に聞いてみるのが、次の動きを決める手がかりになります。「うちでは難しい」だけで電話が切れることが多いですが、「技術が古いから」「リスクが見えないから」「規模が小さいから」のどれなのかが分かると、対処の方向が変わります。技術が古いことが理由なら、その技術を扱える会社を狙って探す。リスクが見えないことが理由なら、後述するように調査だけを切り出して頼む。

依頼先がない状態に近づく前段では、頼んでいる会社と連絡が取りづらくなったときの備えも土台になります。今すでに引き受け先がないなら、その手前で押さえておくべき情報を揃えておくと、相談相手探しの解像度が上がります。

全部作り直さずに済ませる、4つの選択肢

「改修費用が高すぎる」「引き受け先が見つからない」を解くときに、最初から全面リプレースを選ぶ必要はありません。引き取り現場で見ていると、刷新せずに乗り切れる場面が思いのほか多くあります。

選択肢1: 改修範囲を「絶対に必要なところ」だけに絞り込む

見積もりが膨らむ最大の理由が「ついでに直す前提」になっている場合、改修範囲そのものを見直すと費用が大きく下がります。

「項目を1つ足したい」のであれば、フレームワーク更新もデータベースのバージョンアップも、本当に今やる必要があるのか、別の年度に分けられないか、を引き受け側と一緒に整理します。土台の更新が将来必要なのは事実でも、今期の予算で全部やる必然性があるかは別の話です。

経営判断としては、「今期は項目追加だけにとどめて、土台更新は来期の検討に回す」という分け方ができれば、見積もりは大幅に圧縮できます。全面リプレースか現状維持かの2択ではなく、その間にいくつもの粒度がある、と捉えるのが出発点です。作り直す／乗り換える／段階改修するの3つの選択肢と判断基準も合わせて見ると、自社の状況に近い軸が見つけやすくなります。

選択肢2: 調査だけを先に切り出して、見積もりの精度を上げる

引き受け側のリスクが大きいほど見積もりは厚くなり、リスクが大きすぎる場合は断られます。であれば、リスクの正体である「中身が見えない」状態を、改修依頼の手前で減らしてしまう、という打ち手があります。

具体的には、改修を1つの契約にせず、「現状調査」と「改修本番」を分けて発注します。先に調査だけを小さく頼み、その結果を踏まえて改修本番の見積もりを取り直す。調査フェーズで分かることは多く、「思っていたより簡単に直せる」「逆に思っていたより根が深い」のどちらかが判明します。どちらに転んでも、判断の材料が増えます。

調査だけならスポット契約で対応できる会社もあります。「全部やらないと見積もれない」と言われがちな業界の中で、調査と改修を切り分けてくれる先を探すと、相談の入り口が広がります。

選択肢3: 月額固定ではなく、実働ベース（使った分だけ）で頼む

業務システムの保守・改修は月額固定契約が業界の慣行ですが、これは依頼側にとって必ずしも合理的ではありません。年間の改修依頼が数件しかない会社にとって、月額固定は「使わない月にも払い続ける」契約になります。

実働ベース（使った分だけ払う料金型）の保守・改修は、作業した時間に応じて請求する形式で、依頼が少ない月の負担をなくせます。改修費用の総額を抑えるだけでなく、「ちょっとした相談」を気軽に持ちかけられるようになるのも、運用面では大きな違いです。

選択肢4: SaaS・パッケージで置き換えられる業務は、置き換えてしまう

業務システム全体を直そうとすると費用は跳ね上がりますが、業務の中には汎用のSaaSやパッケージで置き換えられる部分が含まれていることがあります。受注管理・在庫管理・顧客管理・会計のような、業界横断で似た業務になりやすい領域は、自前のシステムにこだわるより、市場にある製品に乗せた方が安く・速く・安定する場面が多いです。

すべてをSaaSに置き換えるのが現実的でなくても、「この機能はSaaSに任せて、業務固有のこの部分だけ残った業務システムに残す」という分け方ができれば、改修対象が小さくなり、費用も引き受けやすさも変わります。

「うちには判断材料がない」と感じたときの相談の進め方

選択肢を並べても、「自社のシステムにどれが当てはまるのか、判断する材料がない」と感じる方は多いです。社内に詳しい人がおらず、頼んだ会社に聞いても「全部作り直すしかない」しか返ってこない――そうした状態でも、相談の入り口を整える順序はあります。

まず、相談する相手に「全部やる前提でなく、最低限のところだけならいくらか」を必ず聞くことです。会社によっては最低限の改修を見積もる前提を持っていないことがあります。その場合は、最初から複数の前提で見積もりを出してくれる会社を探した方が、判断の幅が広がります。

次に、「調査だけ」「相談だけ」を別契約として受けてくれるかを確認します。一括の見積もりしか出せない会社と、調査だけを切り出せる会社とでは、依頼側の取れる選択肢の数が変わります。

最後に、現状の情報を整理してから相談する、という順序を守ることです。動いているシステムの一覧、サーバーの場所、ソースコードの所在、関連するライセンス、現状のベンダーとの契約状況――これらが手元にまとまっているかどうかで、相手から返ってくる見積もりの精度も、断られる確率も変わります。引き受ける側から見ると、情報が整理されている依頼は「リスクが見えている依頼」で、見積もりを出しやすくなります。

私たちは、こうした「全部作り直さない方が安く済むはずなのに、相談先がない」という状況の引き取りを主な仕事にしています。月額固定ではなく実働ベースで動き、調査だけのスポット相談から受けています。サービス業の中規模の会社で、20年来の内製基幹システムを刷新せず必要な部分のみ改修して運用を続けた事例もあります。これは特殊な技術ではなく、まず中身を見て、何を今やるべきで何を後に回してよいかを切り分ける、という地味な作業の積み重ねです。

よくある質問

改修費用の相場はいくらくらいですか？

弊社の引き取り案件で見ている範囲では、項目追加のような小さな改修であれば数十万円〜、画面を複数追加する規模で100〜300万円、フレームワークやデータベースの更新を含めると500万円以上、全面リプレースだと数千万円から――というのが目安です。ただし、仕様書がない・調査範囲が見えない場合は、上記の数倍に振れることがあります。相場の数字よりも、見積もりの中身（調査・改修本体・検証・予備）の内訳で判断するのが安全です。

全部作り直す以外の選択肢を、相手から提示されないのですが？

会社によって、相見積もりに乗せる前提が違います。「全部やる」前提だけで動いている会社もあれば、「最低限だけ・調査だけ・段階的に」を組み合わせて提示する会社もあります。提示されないと感じる場合は、「最低限の改修だけならいくらか」「調査だけを先に切り出せるか」を直接質問してみてください。返答が「うちではできません」なら、別の会社にも当たる価値があります。

古い技術で書かれたシステムでも、引き受けてくれる会社はありますか？

あります。古いPHP（4・5系）、VB6、Access VBA、ColdFusion、Perl CGIといった古い技術を扱える会社は、数は減ったものの市場から消えてはいません。「最新技術しか扱わない」会社と、「古い技術も含めて引き受ける」会社が混在しているので、最初の3社で断られても、探し方を変えれば見つかります。引き受ける側から見ると、技術の新しさより「中身が分かる状態で渡されるか」の方が判断に効きます。

改修と保守の契約は、分けた方がよいですか？

分けられる場合は分けた方が、依頼側の選択肢が広がります。改修は「都度の見積もり・都度の発注」で、保守は「月額固定か実働ベースか」で、別々に判断できます。両方を1社にまとめると割引が効くこともありますが、見積もりの中身が見えにくくなる側面もあります。

まとめ

業務システムの改修で「費用が高すぎる」「引き受け先が見つからない」と感じたら、全面リプレースに進む前に確認できる順序があります。

見積もりの中身を「調査・改修本体・検証・前提となる土台更新」に分解して読む
改修範囲を「今期どうしてもやること」「来期に回せること」に分ける
調査だけを先に切り出して、リスクを下げてから本番の見積もりを取り直す
月額固定にこだわらず、実働ベースの選択肢も検討する
SaaSやパッケージで置き換えられる業務がないかを並行で見る

「全部作り直すしかない」と言われた時点で経営判断を急がず、まず「今すぐ直すべきこと」と「今は触らなくてよいこと」を切り分ける相談相手を1社確保するところから、現実的な打ち手につながります。

システムレスキュー

動いてはいるが触れる人がいなくなった業務システムを、刷新せず必要な部分だけ直して運用を続ける引き取り型のサービスです。実働ベースで、調査だけのご相談から受けています。

/service/system-rescue/