レガシーシステム改修の保守・運用費用・ランニングコストについて

レガシーシステム改修における保守・運用費用・ランニングコストとは、COBOLや汎用機など老朽化したシステム全体を作り替えるのではなく、特定の機能・特定のモジュールだけを対象にした部分的・小規模な修正を行った後に、どれだけの費用で運用し続けられるかという論点です。同じくレガシーシステムを扱う既存記事群のうち、「レガシーシステムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという技術手法の使い分けに、「レガシーシステム刷新」が経営層の投資判断・稟議承認プロセスに、「レガシーシステム更改」がベンダー保守契約満了やEOS/EOLという外部から強制される期限に、「レガシーシステムリニューアル」がユーザーの見た目・使い勝手という顧客体験に、「レガシーシステムリアーキテクチャ」がアーキテクチャ構造の技術深掘りに、「レガシーシステムリプレイス」が製品・ベンダー乗り換えという意思決定にそれぞれ重心を置くのに対し、本記事が扱う「レガシーシステム改修」は、全面刷新には予算的に踏み切れない中小企業・予算制約のある企業が、最小限のコストで改修後の運用を続けるための費用感に焦点を当てます。

本記事では、改修後の保守・運用費用の相場感から、レガシーシステム特有のコスト増要因、追加改修のたびに発生する費用の落とし穴、低予算でランニングコストを抑える契約形態の工夫、そして費用を適正化する体制づくりまでを体系的に解説します。全面刷新や技術手法全般の詳しい内容はそれぞれ姉妹記事に譲り、本記事では「限られた予算の中で、改修後も無理なく運用を続ける」という、中小企業の担当者が予算策定の場面で最も知りたい論点に絞って解説します。他の波に比べて費用感は小さめになる一方、見落としがちな追加費用の構造には特に注意が必要です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム改修の完全ガイド

レガシーシステム改修後の保守・運用費用の全体像（部分修正だからこその費用構造）

レガシーシステム改修を選ぶ企業の多くは、そもそも「全面刷新に見合う予算が確保できない」という事情を抱えています。だからこそ、改修後の保守・運用費用も、全面刷新後の大規模なインフラ運用コストとは異なり、月額数万円〜数十万円という小さな単位で予算化されるのが一般的です。一般的なシステム保守費用の目安は初期開発費の年間15〜20%とされており、500万〜2,000万円規模の小規模改修であれば、年間の保守費用もおのずと数十万〜数百万円程度の範囲に収まります。ただし、金額そのものが小さいからこそ、契約の細部を詰めないまま進めてしまうと、想定外の追加費用が発生した際の負担感が相対的に大きくなる点には注意が必要です。

姉妹記事の「刷新」や「リプレイス」が数千万円〜数億円規模の投資判断・TCO比較を扱い、「リアーキテクチャ」がクラウドネイティブ基盤への移行に伴う新たなインフラコストを扱うのに対し、本記事が扱う「改修」は、そもそもそうした大規模投資の議論の土俵に乗らない、最小限の予算で運用を続けたい企業のための費用感を扱います。改修という言葉が示す通り、対象範囲を絞り込むことで初期費用そのものを抑えられる一方、保守・運用フェーズにおいても「大掛かりな運用体制を組まずに、必要最低限のサポートだけを受ける」という発想が中心になります。開発期間の見積もりと同様、保守・運用費用の見積もりも、まず「どこまでを保守の範囲に含めるか」という線引きから始める必要があります。

規模別の月額保守費用の目安を見ると、中小企業などの低予算向けの小規模システムでは月額数万円〜10万円前後がひとつの水準です。障害対応や軽微な修正、最低限の運用サポートなどに範囲を限定することでコストを抑えられます。中規模システムになると月額10万〜50万円程度が目安となり、対応範囲や監視体制の充実度に応じて費用が上がっていきます。全面刷新後の大規模基幹システムでは月額数十万〜数百万円規模の保守費用がかかることも珍しくないため、これと比較すれば部分改修後の保守費用は圧倒的に小さい水準で収まりますが、後述する追加費用の構造を理解しないまま契約すると、この「小さいはずの費用」が想定を大きく上回るリスクがある点に注意が必要です。

レガシーシステム特有のコスト増要因

同じ小規模改修であっても、対象がCOBOLや汎用機といったレガシー技術である場合、一般的なシステムの保守費用相場よりも高額になりやすい構造的な要因があります。

COBOLなどの古い技術や独自仕様が使われているレガシーシステムは、設計書・仕様書が最新化されていない、あるいはそもそも存在しないケースが多く、特定の担当者に知識が依存する属人化も進んでいます。保守・運用の場面では、何か不具合や問い合わせが発生するたびに、この不足したドキュメントを補うための調査・切り分け作業が必要になり、その工数が保守費用に転嫁されます。同じ内容の作業であっても、モダンな技術で構築されたシステムに比べて、レガシーシステムは対応にかかる時間が長くなりやすく、結果として月額保守費用が相場よりも高額になりやすい傾向があります。改修時にドキュメントを最低限整備しておくことが、保守フェーズのコストを抑える先行投資になります。

COBOLや汎用機に対応できる技術者は年々希少になっており、対応できる人材の高齢化・退職が進んでいることが多くの調査で指摘されています。改修範囲が小さいとはいえ、こうした特殊な技術への対応力を持つ人材を確保する必要がある以上、保守費用が一般的なモダン技術のシステムと同水準に収まるとは限りません。特定のベンダー・特定の担当者への依存度が高い状態が続くと、価格競争原理が働かず、見積もりが年々高止まりしていくリスクもあります。低予算での運用を実現するためには、この技術者不足という構造的な制約を前提に、複数の候補パートナーを比較検討しておくことが重要です。

追加改修のたびに発生する費用の落とし穴

低予算での運用を目指す企業ほど陥りやすいのが、月額保守費用の安さだけを見て契約し、その後の追加改修費用の積み重ねで結果的に高額になってしまうという落とし穴です。

多くの保守契約では、バグ修正やOSのアップデート対応などは月額費用に含まれますが、新たな機能追加や仕様変更、帳票フォーマットの変更といった要望は「保守対象外」として別途追加費用が発生するのが一般的です。この保守契約外の追加改修では、ベンダー側が「最低作業料金」を設定していることが多く、実作業が15分〜30分程度の軽微な修正であっても、5万〜10万円を請求されるケースがあります。この費用感を知らないまま「ちょっとした改善」を気軽に依頼してしまうと、想定外の出費が積み重なり、小さな改善要望を出すこと自体をためらってしまう悪循環に陥ります。

従業員50名規模のある製造業の企業では、月額保守費用は5万円に抑えられていたものの、データ出力項目の変更や軽微な画面修正がすべて「保守外」とされ、年間の追加作業費用が平均80万円にまで膨らんでしまった事例があります。月額換算すると6万円を超え、当初想定していた月額保守費用そのものを追加費用が上回る結果となりました。この事例が示す通り、契約時の月額費用の安さだけを見て予算計画を立てると、実際のランニングコストを大きく見誤ることになります。低予算での運用を実現するには、月額費用と追加費用の両方を合算した実質的な年間コストで判断することが不可欠です。

低予算でランニングコストを抑える契約形態の工夫

追加費用の落とし穴を回避するには、契約形態そのものを自社の改修頻度に合わせて工夫することが有効です。代表的な3つの選択肢を紹介します。

月額固定型（定額制）は、毎月一定額を支払う契約ですが、契約内に「月に◯時間までの軽微な改修・メンテナンス作業を含む」といった条件をあらかじめ組み込んでもらうことで、ちょっとした修正のたびに追加費用が発生するのを防ぐことができます。一方、従量課金型・時間課金型は、改修やトラブル対応が発生した作業量に応じて支払う形式です。障害や問い合わせが少ないシステムであれば、無駄な固定費を払わずに済み、コストを安く抑えやすいというメリットがあります。自社の改修頻度が高いか低いかによって、どちらの形態が適しているかを見極めることが、低予算での運用の第一歩です。

チケット制・ポイント制は、あらかじめ一定の作業時間やポイントを購入しておき、軽微な修正依頼が発生するたびに消費していく形式です。月額固定費を高くしたくないが、不定期にちょっとした改修をお願いしたいという、まさに部分改修を選ぶ企業のニーズに合致した契約形態と言えます。法改正対応や特定帳票の改修のように、発生頻度は低いものの都度対応が必要になる案件では、このチケット制を採用することで「最低作業料金」による割高な単発発注を避け、あらかじめ確保した予算の範囲内で計画的に改修を進めることができます。契約前に「どこまでが月額保守の範囲内で、どこからが追加費用になるのか」を明確にし、自社の改修頻度に合わせて最適な形態を選ぶことが、ランニングコストを適正に保つ最大のポイントです。

費用を適正化する体制づくり

契約形態を工夫するだけでなく、社内の体制そのものを見直すことでも、レガシーシステム改修後のランニングコストを適正な水準に保つことができます。

「最低作業料金」の存在を踏まえると、軽微な改修要望が発生するたびに個別に発注するのではなく、緊急性の低いものはある程度まとめて、四半期に1回、あるいは半年に1回といったサイクルでバッチ的に依頼する方が、トータルの費用を抑えられるケースが多くあります。社内で改修要望を一覧化して優先順位をつけ、緊急対応が必要なもの（バグ修正等）とまとめて依頼できるもの（帳票フォーマットの変更等）を区別する運用ルールを設けておくことが、ランニングコストの最適化に直結します。この一手間が、月額数万円という小さな保守費用の枠内で、必要な改修を着実にこなしていくための実務的な工夫になります。

最も費用対効果の高い最適化は、契約段階で「何が月額保守の範囲内で、何が追加費用になるのか」という境界線を、口頭ではなく文書として明確に定義しておくことです。「バグ修正」「軽微な設定変更」「機能追加」「仕様変更」といった作業区分ごとに、対応可否と概算費用をあらかじめ合意しておけば、実際に改修要望が発生した際にベンダーとの認識齟齬による追加交渉の手間を省けます。低予算での運用を目指す企業ほど、この境界線の曖昧さが後々のコスト増につながりやすいため、初期の改修プロジェクトの契約段階から、保守フェーズの費用構造まで見据えて交渉しておくことをお勧めします。

まとめ

本記事では、レガシーシステム改修の保守・運用費用・ランニングコストについて、部分修正だからこその費用構造という全体像から、レガシーシステム特有のコスト増要因、追加改修のたびに発生する費用の落とし穴、低予算でランニングコストを抑える契約形態の工夫、費用を適正化する体制づくりまでを体系的に解説しました。改修後の月額保守費用は小規模システムで数万円〜10万円前後と、全面刷新後の運用と比べて一桁小さい水準に収まる一方、機能追加や仕様変更は保守対象外となり、「最低作業料金」によって実作業以上の追加費用が請求されるケースがある点は見落とせません。月額固定型・従量課金型・チケット制という契約形態を自社の改修頻度に合わせて選び、保守範囲の境界を契約時に文書化しておくことが、低予算でのランニングコスト最適化の鍵です。改修プロジェクトの初期段階から、保守フェーズまで見据えたパートナー選びを心がけることをお勧めします。

▼全体ガイドの記事
・レガシーシステム改修の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。