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

レガシーシステム刷新の費用は、放置してきた期間、複雑さ、選定方法によって、数千万円から数億円規模まで変わります。

保守・運用費用は企業のIT予算の多くを占め、放置が続くと刷新の予算そのものも増える傾向があります。全体像は、レガシーシステム刷新の完全ガイドもご覧ください。

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

レガシーシステム刷新の保守・運用費用が経営課題になる理由

経済産業省の「DXレポート」では、企業のIT予算の9割以上がレガシーシステムの維持管理費に充てられるとされています。

この構図を放置すると、2025年以降に日本全体で年間最大12兆円の経済損失が生じる可能性があります。これは「2025年の崖」と呼ばれる警鐘です。

COBOLやメインフレームに対応できる技術者は、高齢化と退職によって希少化しています。

保守を依頼できるベンダーも限られ、人件費相場そのものが上がる構造もあります。

保守・運用費用は、現場のコスト削減にとどまらず、経営が判断すべきテーマです。費用が高止まりすると全社のIT予算の配分が歪み、新しいDX投資の原資まで圧迫されるためです。

刷新の稟議では、この構造を経営層が自分ごととして理解できる形で示します。

放置した場合の3つの経営リスク

レガシーシステムを放置したときの経営リスクは、次の3領域で捉えます。

  • コスト・人材:維持費の肥大化と、技術者不足の進行
  • 安全・法令:サポート終了後の攻撃や情報漏洩
  • 競争力:API連携の難しさと、新規事業の遅れ

コスト・人材の面では、維持や保守にIT予算を割き続けることになります。

COBOLなどを扱える技術者の退職によって、ブラックボックス化も進みます。

安全・法令の面では、OSやハードウェアのサポートが終わったあとも、サイバー攻撃や情報漏洩のリスクが残り続けます。

競争力の面では、古いシステムは新しいデジタル技術と連携しにくく、API連携などに手間がかかります。その結果、新しいビジネスモデルの展開が遅れます。

3つのリスクは互いに影響し合い、放置期間が長いほど悪化していきます。

コスト構造の技術的な詳細と姉妹記事

コスト構造と本記事の実務範囲は、次の2つに分けて確認します。

  • コスト構造:技術的負債とブラックボックス化が中心
  • 実務範囲:RFP・選定・稟議が中心

技術的負債がコストを押し上げる仕組みと、ブラックボックス化が改修費を増やす仕組みは、姉妹記事で詳しく扱っています。

移行後の運用コスト削減の見込みや相場データも、姉妹記事で扱っています。

姉妹記事の名前は「レガシーシステムのモダナイゼーション」で、保守・運用費用とランニングコストに関する記事です。

コスト構造の説明は最小限にとどめ、ここからは予算確保の実務に進みます。RFP作成、ベンダー選定、稟議承認の流れを扱います。

コスト構造を先に把握したい方は、姉妹記事もあわせてご一読ください。

ポイント

維持管理費がIT予算の多くを占めている場合は、刷新を経営課題として稟議にかける目安になります。経営層に示すときは、放置した場合のリスクも一緒に並べます。

放置コストという「先送りの代償」の考え方

放置コストを保守契約費、緊急対応費、機会損失の3項目に分けたパネル図。
月々の支出に加え、障害や失われた成長機会も費用として捉えます。

稟議では、刷新にかかる費用と、刷新しない場合にかかる費用を並べて示します。この比べ方が「先送りの代償」という考え方です。

保守費用の高止まりは、一度起きると自然には下がりません。着手を1年先送りするたびに、人件費相場の上昇や技術者の退職が進みます。その結果、刷新に必要な予算そのものが増える傾向があります。

機会損失と緊急対応コストの内訳

放置コストは、見える支出と見えにくい損失に分けて整理します。

  • 保守契約費:月々の契約にかかる直接的な支出
  • 緊急対応費:障害対応と業務停止による損失を含む
  • 機会損失:失われた売上や成長機会

ハードウェアやミドルウェアが老朽化すると、突発障害が起きやすくなります。その結果、原因の究明や復旧に時間がかかり、緊急対応コストが発生します。この費用は修理費用だけでなく、ブランドの毀損も含めて考える必要があります。

レガシーシステムの制約で、新しいデータ活用や外部連携を断る場合があります。その状態が続けば、こうした機会の損失もコストとして数えるべきです。

稟議では、見えるコストと見えないコストをできるかぎり数字で示します。

今年発生している費用と今後発生しうる費用を並べると、経営層に危機感を持ってもらう根拠になります。

2025年の崖・SAP2027年問題という予算獲得の論拠

放置コストを説得力のある議論にするには、外部で示された期限も引用します。

  • 2025年の崖:年間最大12兆円の損失予測が示されています。
  • 刷新集中期間:2021年から2025年までの期間
  • SAP2027年問題:保守サポートが2027年末に終了します。

経済産業省が示す期限は、自社の事情とは別の判断材料になります。SAP ERPの保守終了も、対応時期を決める手がかりになります。これらは、自社の判断とは独立して迫る期限です。

SAPなどの保守終了が近づくと、期限直前にベンダーのリソースが集中します。そのため、対応できるベンダーを確保しにくくなる二次的なリスクにも注意が必要です。

ポイント

今年の支出と、放置した場合に将来発生する損失を並べると、着手を先送りするリスクが数字で伝わりやすくなります。

稟議を通すためのRFP作成とベンダー選定の実務

RFPに記載する目標と課題、数値と予算、納期と評価の3項目を示すチェックリスト図。
見積もりの前提をそろえると、提案内容を同じ条件で見比べやすくなります。

費用の稟議では、社内向けの資料だけでなく、発注のプロセスも精度高く設計する必要があります。

見積もりの根拠が曖昧なままだと、経営リスクを訴えても数字の妥当性を問われてしまいます。

RFP(提案依頼書)の作成ポイント

提案と見積もりの精度は、RFPにどこまで情報をそろえたかで左右されます。見積もりがぶれないよう、RFPには事業目標、予算、納期、評価の条件を書き込みます。

  • 目標と課題:事業目標と解決したい課題
  • 数値と予算:定量目標と予算
  • 納期と評価:希望納期と評価基準

「とりあえず始めよう」という曖昧な要件定義は、予算超過の原因になります。スケジュール遅延を防ぐためにも、要件はRFPに詳しく文書化しておく必要があります。

発注側は、RFI(情報提供依頼書)を事前に使い、技術的な実現可能性を擦り合わせます。

レガシーシステムでは、仕様書と実態が一致しないケースも少なくありません。そのため、RFPを作る時点で簡易的な現状調査を行い、見積もりの材料をそろえます。

この準備によって、後工程での追加費用の発生を防げます。

ベンダー選定の3大基準と参照確認

ベンダー選定では、価格や知名度だけでなく、次の3基準を確認します。

  • 導入実績:同業種・類似規模での実績とデータ移行の経験
  • 管理力:非IT用語での説明力と、トラブル時の体制
  • 保守体制:導入後のサポート範囲とSLA

初期費用の安さや大手のネームバリューだけで選ぶと、失敗につながります。

導入実績では、自社特有の業務プロセスを理解しているかを確かめます。

管理力では、現場や経営層に非IT用語で説明できるかを見て、トラブル時のエスカレーション体制も確認します。

保守体制では、SLA(サービス品質保証)がどこまで約束されているかも見ておきます。

最終候補の段階では、過去のクライアント企業に参照確認を行います。提案書からは見えない実力を、リファレンスチェックで見極めます。

ポイント

見積もりの根拠を数字で示せるよう、RFPの段階で要件を詰めておきます。曖昧なまま進めると、追加の工数や費用が発生しやすくなります。

予算承認プロセスで押さえるべきポイント

初年度のアセスメントとPoCから、次年度以降の本開発、移行判断へ進む予算執行のタイムライン。
各段階の完了基準と継続基準が、次の予算へ進む節目になります。

見積もりがそろったら、社内の予算承認プロセスに進みます。資料の質によって、稟議が一度で通るか、差し戻しを受けて着手が遅れるかが決まります。

TCOでの比較とKPI設定

予算承認の資料では、現状維持と刷新を比べる材料と、刷新後の効果を測る材料を同じ資料にそろえます。

  • TCO比較:現状維持と刷新の総所有コストの比較
  • 回収時期:投資回収までのシミュレーション
  • KPI設定:実行後に測る効果の明確化
  • 投資区分:削減領域と戦略投資の区分

初期構築費用だけで比べると、運用保守費用の差が見落とされます。そのため、運用保守費用を含む総所有コスト(TCO)で、現状維持と刷新を並べて比べるのが基本です。

クラウド移行で運用コストを削減する場合は、1.5〜4年で投資を回収するシミュレーションも示せます。

KPIには、「事務作業時間を30%削減する」のように明確な目標を置きます。「保守対応時間を◯分の1に短縮する」といった設定も使えます。

KPIは、投資を実行したあとの効果測定に役立つほか、次年度以降の追加投資を判断する材料にもなります。

投資は、コスト削減と戦略的投資を分けて考えます。SaaS移行や廃止対象は、コスト削減が主目的の領域です。一方で、コアシステムの再構築は、戦略的投資が主目的の領域です。

複数年度予算化と段階的な予算執行

大規模な刷新では、予算と判断を年度・フェーズに分けて管理します。

  • 初年度:アセスメントとPoCに予算を絞る
  • 次年度以降:結果を踏まえた本開発の承認
  • 移行判断:完了基準と継続基準を先に決める

レガシーシステム刷新は投資規模が大きく、単年度予算では難しい場合があります。初年度に小さな予算枠を確保し、本開発費は翌年度以降に求める方法が現実的です。

一度に大きな金額を求めるより、段階的に進めたほうが稟議を通しやすくなります。経営層も、各段階でリスクを見極めながら判断できます。

各フェーズの完了基準と次フェーズへの移行基準は、事前に関係者と合意しておきます。基準を定めることで、途中で予算執行が止まる事態を防げます。

ポイント

大きな金額を一度に求めるより、初年度は小さな予算枠で始め、完了基準を先に決めておくことが判断の目安になります。

経営判断の実例に学ぶ教訓

費用と予算の意思決定は、プロジェクトの成否に直結します。ここでは、経営判断が明暗を分けた2つの実例を確認します。

あえて高い見積もりを選んだ基幹システム刷新の成功例

この成功例では、価格よりも現状分析の深さを評価しました。

  • 規模:10億円規模の基幹システム刷新
  • 選定理由:旧システムを全部洗い出す提案だった点

ある企業は、外部コンサルタントのコンペで最も高い提案を採用しました。他社が詳細な現状分析を避けるなか、その会社だけが全構成の洗い出しを明言していました。また、成功への具体的な道筋を示していたことも、採用の理由です。

安さだけで選んでいれば、着手後にブラックボックス部分が表面化していた可能性があります。その場合、予算超過のリスクはむしろ高まっていたと考えられます。

稟議では、単価の安さに加えて、レガシー特有のリスクも評価の対象にします。

放置がもたらすコストを示す警鐘事例

この警鐘事例は、日常の費用と突発障害の両方を稟議で示す必要があることを伝えています。

  • 発生時期:2021年、大手金融機関での発生
  • 影響:復旧に8時間を要したこと

このシステム障害では、顧客被害が発生しました。

外部調査委員会は、同種の予兆事象が過去にもあったと報告しています。

その後も特段の検討をせず、仕様が見直されずに続いたことが、重大な被害に直結しました。

放置コストは、保守費用の高止まりだけでなく、事業継続を揺るがす形でも表れます。

稟議では、突発障害のリスクと事業への影響を、定量的または定性的に併記します。

まとめ

本記事では、レガシーシステム刷新の保守・運用費用を経営課題として整理しました。放置コストから予算承認までの流れと、RFP作成やベンダー選定、経営判断の実例を扱いました。

保守・運用費用は、コスト削減の対象であると同時に、経営判断の材料として示すものです。

TCO比較、KPI設定、複数年度予算化の形に置き換えると、稟議を通しやすくなります。

放置コストは、着手を先送りするほど複利的に膨らみます。ベンダー選定や予算承認の進め方によって、結果は大きく変わります。

コスト構造の詳しい解説は、姉妹記事の「レガシーシステムのモダナイゼーション」をご参照ください。

まずは自社の放置コストを洗い出し、稟議に必要な材料を早めにそろえます。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。