基幹システムの追加開発費用が高い理由4つと打ち手

「ちょっとした画面の項目追加なのに、見積もりが想像の何倍にもなる」「保守費が毎年少しずつ上がっているが、何に払っているのか説明できない」「バージョンアップのたびに、追加開発した部分の改修費が別にかかる」「仕様を分かっているのがベンダーの担当者だけで、言われた金額をのむしかない」。パッケージやERPに追加開発を重ねてきた企業から、こうした声が聞かれます。この記事では、基幹システムの追加開発の費用が高くなる構造的な理由と、今の費用が妥当かを確かめる手順、費用を下げる打ち手の選び方、ベンダーとの話し方をお伝えします。

追加開発・カスタマイズ・アドオンの違い

基幹システムの「追加開発」は、パッケージやERPの標準機能では足りない部分を、自社向けに作り足すことを指します。呼び方は製品やベンダーによって違いますが、おおむね次のように分けられます。

種類	内容	後から効いてくる費用
設定（パラメータ）	製品が用意している設定値や画面の選択肢で、動きを変えること	多くの場合は小さめ
カスタマイズ	製品の標準の画面や処理そのものに手を入れること	バージョンアップのたびの影響確認と改修
アドオン	標準機能の外側に、独自の画面・帳票・処理を追加すること	本数に応じて増える保守とテストの負担
外部連携	他のシステムとのデータのやり取りを作ること	相手側のシステムが変わったときの改修

ベンダーによっては、アドオンもまとめて「カスタマイズ」と呼ぶことがあります。言葉の定義をそろえないまま話すと、見積もりの比較や保守範囲の確認で食い違いが起きるため、自社の契約や見積書で何をどう呼んでいるかを最初に確かめておくと話が進めやすくなります。

追加開発の費用が高くなる理由4つ

追加開発の見積もりが高いと感じるとき、ベンダーの単価だけで説明できるとは限りません。多くの場合、これまでに積み重ねた追加開発そのものが、次の改修の費用を押し上げています。

経済産業省がまとめたレガシーシステムモダン化委員会総括レポート（2025年5月）では、レガシーシステムを、運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足かせや高コスト構造の原因となっているシステムと定義しています。そのうえで、要因の一つに「肥大化・複雑化」を挙げ、補完機能やカスタマイズ箇所が増えて機能の追加・変更が難しくなる状態を示しています。古い技術で作られているかどうかではなく、作りと保守の状態で決まるという考え方です。

1. アドオンが積み重なり、調査とテストが膨らむ

追加開発の費用のうち、実際にプログラムを書き換える作業は一部にすぎません。改修の前には「どこに影響が出るか」を調べ、改修の後には「他の機能が壊れていないか」を確かめる必要があります。

アドオンが数本のうちは、影響範囲もすぐに分かります。ところが、何年もかけてアドオンが増え、アドオンどうしがデータや処理を参照し合うようになると、1か所の変更が思わぬところに波及します。ベンダーは影響を見落とすリスクを見込んで、調査とテストの工数を厚めに積むことになります。「画面に項目を1つ足すだけ」の依頼が高額になるのは、この調査とテストの分が大きいためです。

2. バージョンアップのたびに再改修が要る

パッケージやERPは、製品の側で定期的にバージョンアップや保守期限の切り替えがあります。標準機能だけで使っていれば、製品側の更新に合わせて移行するだけで済みます。しかし、標準の処理に手を入れたカスタマイズや、標準のデータ構造に依存したアドオンがあると、新しいバージョンでも動くかを一本ずつ確かめ、動かないものは作り直す必要があります。

つまり、追加開発は作ったときに一度払えば終わりではなく、バージョンアップのたびに改修費がかかる「繰り返し発生する費用」です。追加開発の本数が多い企業ほど、バージョンアップそのものが大きなプロジェクトになり、先送りしているうちに保守期限が迫る、ということが起きます。

3. 仕様を知るのがベンダーだけになっている

追加開発を長く同じベンダーに任せていると、設計書が更新されないまま改修が重なり、仕様を正確に知っているのがベンダーの担当者だけ、という状態になりがちです。前述のレポートでも、レガシーシステムの要因として「ブラックボックス化」を挙げ、仕様や設計のドキュメントが整備されていないこと、運用維持保守が属人的になっていることを示しています。また、ユーザー企業がベンダー企業へ依存した結果として、ベンダーロックインによる経営のアジリティの低下にも触れています。

仕様が社内で分からなければ、見積もりの妥当性を判断する材料がありません。他のベンダーに相見積もりを頼んでも、まず現行の仕様を調べるところから始まるため、今のベンダーより高くなりやすく、比較そのものが成り立ちにくくなります。費用が高いかどうか以前に、「高いかどうかを判断できない」ことが問題の中心にあります。

4. 使われていない機能まで保守している

業務や組織は変わっていきますが、一度作った追加開発は、使われなくなっても残り続けることがほとんどです。廃止した取引形態のための画面、今は誰も見ていない帳票、担当者の異動とともに使われなくなった集計処理などが、そのまま保守の対象になり、バージョンアップのたびに改修の対象にもなります。

保守費が追加開発の本数や規模に応じて決まる契約であれば、使われていない機能の分まで毎年払っていることになります。また、使われていない機能があるだけで、改修時の影響調査とテストの範囲が広がり、理由1の費用も押し上げます。

外部環境による値上がりもある

上の4つは自社のシステムの作りに由来する理由ですが、外部の要因もあります。日本情報システム・ユーザー協会の企業IT動向調査2026（2025年度調査）報告発表資料では、IT予算の増加理由は既存システムの更新や値上げ等の不可避的要因の影響が大きいとし、物価高や人件費の高騰などを背景に、既存システムの維持（ランザビジネス）のコストが増えているとまとめています。単価の上昇は自社だけでは止められないため、なおさら「払う対象」を減らす取り組みが効いてきます。

今の費用が妥当かを見直す4つの手順

費用を下げる打ち手を選ぶ前に、何にいくら払っているのかを把握します。次の4つの手順で進めると、ベンダーと話すための材料もそろいます。

手順1：追加開発を棚卸しする

まず、これまでに作った追加開発を一覧にします。相談をいただいた企業で、この一覧そのものが社内に無い、ということは少なくありません。ベンダーの納品物や保守の記録、過去の見積書・発注書から拾い集め、次のような項目で整理します。

項目	記入する内容
名称と種類	画面・帳票・バッチ処理・外部連携・標準機能の改修のいずれか
目的	どの業務の、どんな困りごとのために作ったか
作った時期と費用	分かる範囲での発注時期と金額
依存関係	他のアドオンや標準機能のどこを参照しているか
業務上の担当部署	使っている部署と、内容を説明できる人
設計書の有無	最新の仕様が分かる資料があるか

すべてを一度に埋める必要はありません。最初は名称と種類、使っている部署だけでも、全体の規模が見えてきます。

手順2：利用状況を確かめる

一覧ができたら、それぞれが今も使われているかを確かめます。画面のアクセス記録、帳票の出力記録、バッチ処理の実行記録など、システム側に残っているログがあれば、まずそれを見ます。ログが取れない場合は、担当部署に「この画面や帳票が無くなったら困るか」を聞いて回ります。

このとき、「使っている」の中身も分けておくと後の判断に役立ちます。

毎日・毎月の業務で欠かせない機能
年に数回、決算や棚卸しのときだけ使う機能
使ってはいるが、標準機能や表計算ソフトでも代わりが利く機能
誰も使っていない、または誰が使っているか分からない機能

最後の2つに入るものは、廃止や置き換えの候補になります。

手順3：保守契約の中身を確認する

保守費が何に対する対価なのかを、契約書と保守の実績から確かめます。たとえば次のような点です。

問い合わせ対応・障害対応・軽微な修正のうち、どこまでが保守費に含まれているか
追加開発した部分の保守が、製品本体の保守と別の契約や別の料金になっているか
バージョンアップ対応や法改正への対応が、保守の範囲か、別途見積もりか
保守費の算定の根拠（追加開発の本数や規模、対応時間など）が示されているか
設計書やソースコードの更新・引き渡しについて、どう定められているか

契約の解釈や権利関係の判断が必要な点は、条項を確かめたうえで、社内の法務部門や専門家に相談してください。この記事で扱うのは、費用の中身を把握するための確認までです。

あわせて、過去1〜2年の保守の実績（問い合わせや障害の件数、実際に行った作業）を出してもらうと、保守費と実際の作業量の関係が見えてきます。

手順4：見積もりの内訳を確認する

次に追加開発を頼むときや、過去の見積もりを見直すときは、合計金額だけでなく内訳を確認します。

工程ごとの工数（影響調査、設計、実装、テスト、本番反映）
影響調査で、どの機能に影響があると判断したか
テストの範囲と、その範囲にした理由
見積もりの前提条件（仕様の確定時期、社内側の作業、対象外の作業）

内訳を見ると、実装よりも影響調査とテストの工数が大きいことがあります。それ自体は不当ではなく、理由1で述べた構造の表れです。内訳が分かれば、「この影響範囲は、使っていない機能を廃止すれば狭められるのではないか」といった、費用を下げるための具体的な相談ができるようになります。

費用を下げる5つの打ち手と向く条件

棚卸しと利用状況の確認が済んだら、追加開発ごとに打ち手を選びます。打ち手は1つに絞る必要はなく、追加開発ごとに組み合わせるのが現実的です。

打ち手	内容	向く条件
1. 使っていないアドオンの廃止	利用実績のない追加開発を止めて、保守とバージョンアップの対象から外すこと	利用状況で「誰も使っていない」と確かめられた場合
2. 標準機能や業務の見直しによる吸収	業務のやり方を製品の標準に合わせ、追加開発を減らすこと	他社と差のつかない業務で、追加開発が慣習の維持のためにある場合
3. 周辺業務のSaaSへの切り出し	経費精算・勤怠・ワークフローなどを外部のサービスに移すこと	基幹システムの外に出しても、データ連携で業務が回る場合
4. 必要な機能だけのスクラッチでの作り直し	自社に固有で価値のある業務を、パッケージの外で作り直すこと	追加開発が多すぎて、パッケージを使う利点が薄れている場合
5. リプレイス	基幹システム全体を新しい仕組みに入れ替えること	保守期限が近い場合や、他の打ち手を組み合わせても足りない場合

1. 使っていないアドオンを廃止する

最も費用がかからず、効果が出やすい打ち手です。利用状況の確認で使われていないと分かった追加開発を廃止すれば、保守の対象から外れ、次のバージョンアップでも改修の対象から外れます。影響調査とテストの範囲も狭まるため、他の改修の費用も下がりやすくなります。

いきなり削除するのではなく、まずは画面や処理を利用できない状態にして一定期間様子を見て、問い合わせが無いことを確かめてから廃止すると安全です。年に一度しか使わない帳票もあるため、確認の期間は決算などの業務の周期を踏まえて決めます。

2. 標準機能や業務の見直しで吸収する

追加開発の中には、「以前のシステムでこうだったから」「この部署はずっとこの帳票の形で見てきたから」という理由で作られたものが含まれています。こうした追加開発は、業務のやり方を製品の標準に合わせることで不要にできる場合があります。製品の標準の業務の流れを前提に、業務の側を合わせていく進め方は「Fit to Standard」と呼ばれます。

前述のレポートでも、現行機能の保証や現行踏襲へのこだわりが、システム移行の際に多くのカスタマイズを伴い、コストがかさむ要因になりうると指摘しています。そのうえで、現行踏襲にこだわらずあるべき業務の姿から検討し、標準的な仕様に寄せる部分と、付加価値を作り込む部分とを明確に分けることを求めています。

会計・人事給与のように、法令や一般的な慣行に沿って進める業務は、他社と差がつきにくく、標準に合わせやすい領域です。業務を変えるには現場の理解が必要になるため、情報システム部門だけで決めず、業務部門の責任者を巻き込んで判断します。

3. 周辺業務をSaaSに切り出す

基幹システムに追加開発で載せてきた機能の中には、基幹システムの中にある必要がないものもあります。経費精算、勤怠管理、稟議などのワークフロー、問い合わせ管理などは、専用のSaaSが多く提供されている領域です。こうした機能を外に出せば、基幹システム側の追加開発を減らせます。

ただし、切り出した先とのデータ連携が新たな追加開発になっては意味がありません。マスタデータ（取引先・品目・社員など）をどちらで管理するか、連携の頻度と方法をどうするかを、切り出す前に決めておきます。連携の本数が増えすぎる場合は、切り出す範囲を見直します。

4. 必要な機能だけをスクラッチで作り直す

パッケージに追加開発を重ねた結果、パッケージの標準機能はほとんど使っておらず、使わない機能まで含めて保守とバージョンアップの費用を払っている、という状態になることがあります。この場合、パッケージを使い続ける利点そのものが薄れています。

こうした企業には、自社の業務に必要な機能だけを洗い出し、スクラッチ（独自開発）で作り直すという選択肢があります。作り直す際には、書類の読み取りや入力の補助のように、AIを業務の仕組みに組み込むことも前提にできます。どの作業をAIに任せるかは、AI化する業務の洗い出し方の考え方で選ぶと判断しやすくなります。

私たちが支援した医療卸の基幹システム刷新では、見積・受発注・請求がそれぞれ独立して管理され、同じ取引情報を重複入力しているうえ、既存システムに新たな機能を追加できない状態でした。業務を工程単位で棚卸しして再設計し、見積・受発注・請求・取引管理をモジュールとして単一のデータ基盤上に再構築したうえで、AI-OCRによる入力自動化を追加しました。二重入力と転記ミスを解消し、月次処理を短縮しています。稼働後も保守運用と機能追加を続けており、取り組みの詳細は支援実績で紹介しています。

前述のレポートでは、パッケージやSaaSへ移行できるかを最優先で検討すべきとし、とくに経営資源の制約が大きい中堅・中小企業はオーダーメイドのスクラッチ開発を避け、パッケージやSaaSを原則とすべきとしています。スクラッチ開発には費用と期間がかかる、というのがこれまでの前提でした。

ただ、この前提は変わりつつあります。今は設計・実装・テストにAIを使うことで、自社の業務に合わせたシステムを、以前より短い期間と少ない費用で作れる場合があります。AIを業務の流れに最初から組み込んだ「AIネイティブ」な仕組みや、自社のやり方に特化した仕組みを、パッケージに追加開発を重ね続けるより早く、安く作れることもあります。

もちろん、すべてを作り直せばよいわけではありません。会計のように標準的な業務はパッケージやSaaSに任せ、自社の強みに関わる業務や、標準に合わせると現場が回らない業務だけを作り直す、という線引きが大切です。作り直した後に、再び追加開発を重ねて同じ状態に戻らないよう、設計書の整備と、社内で仕様を説明できる体制もあわせて用意します。

5. リプレイスする

製品の保守期限が近い場合や、追加開発の本数が多く、上の打ち手を組み合わせても費用の構造が変わらない場合は、基幹システム全体のリプレイスを検討します。リプレイスは費用も期間も大きく、業務を止めずに切り替える計画が必要です。移行方式の選び方やデータ移行の計画は、基幹システムリプレイスの進め方で詳しく説明しています。

リプレイスを選ぶ場合でも、手順1〜2の棚卸しと利用状況の確認は無駄になりません。使っていない機能を新しいシステムに持ち込まないことが、リプレイスの費用を抑える一番の近道だからです。

打ち手を選ぶ順番

迷ったときは、費用と影響の小さい順に検討すると判断しやすくなります。

使っていないアドオンを廃止できないか
業務を標準に合わせて、追加開発を減らせないか
基幹システムの外に出せる機能はないか
残った機能のうち、作り直すべきものはどれか
全体を入れ替えるべきか

1〜3を進めるだけで、保守とバージョンアップの対象が減り、4や5を検討するときの範囲も小さくなります。

ベンダーとの話し方

追加開発の費用を下げる取り組みは、今のベンダーと対立して進めるものではありません。仕様を最もよく知っているのはベンダーであり、協力が得られなければ、棚卸しも廃止も進みにくくなります。話し合いの際は、次の点を意識すると前向きな相談にしやすくなります。

事実を持って相談する：「高い」と伝えるだけでなく、棚卸しの一覧と利用状況をもとに「この機能は使っていないので、保守とバージョンアップの対象から外したい」と具体的に伝えます。
内訳の説明を求める：見積もりの工程別の工数と、影響調査の結果を出してもらいます。内訳を見て、影響範囲を狭めるための案を一緒に考えます。
廃止や標準化の提案を求める：ベンダーの側から、使われていない機能や標準機能で置き換えられる機能の提案をもらうよう依頼します。
ドキュメントの整備を依頼する：設計書の更新を改修の作業範囲に含め、仕様が社内でも分かる状態を少しずつ作ります。
契約の見直しは条項の確認から始める：保守の範囲や料金の算定方法を変えたい場合は、まず契約書の条項を確かめ、必要に応じて法務部門や専門家に相談したうえで話し合います。

それでも見積もりの妥当性が判断できない場合は、第三者に現行の仕様と見積もりの内訳を見てもらう方法もあります。IT戦略やシステム投資の見直しについては、コンサルティングの支援内容もご覧ください。

まとめ：追加開発の費用は「払う対象」を減らして下げる

基幹システムの追加開発の費用が高くなるのは、アドオンの積み重ねで調査とテストが膨らむこと、バージョンアップのたびに再改修が要ること、仕様を知るのがベンダーだけになっていること、使われていない機能まで保守していることの4つが主な理由です。
費用が妥当かを判断するには、追加開発の棚卸し、利用状況の確認、保守契約の中身の確認、見積もりの内訳の確認の4つの手順で、何にいくら払っているかを把握します。
打ち手は、使っていないアドオンの廃止、標準機能や業務の見直しによる吸収、周辺業務のSaaSへの切り出し、必要な機能だけのスクラッチでの作り直し、リプレイスの5つです。費用と影響の小さいものから検討します。
会計のような標準的な業務はパッケージやSaaSに任せ、自社に固有で価値のある業務だけを作り直す、という線引きが大切です。
ベンダーとは対立せず、棚卸しと利用状況という事実をもとに、内訳の説明や廃止の提案を求めていきます。

追加開発の棚卸しや、どの機能を残し、どれを作り直すかの判断から、開発・保守運用までご相談いただけます。進め方を検討されている段階でも、システム開発の支援の内容をご覧のうえ、お気軽にお問い合わせください。