レガシーシステム刷新における保守・運用費用の問題は、単に「今の維持費が高い」という現場レベルの悩みにとどまらず、経営層がどう投資判断を下し、社内稟議をどう通すかという意思決定プロセスそのものに直結します。COBOLで書かれたメインフレームや、長年の改修で属人化した「塩漬け」システムほど、保守費用は年々高止まりしやすい一方、刷新のための投資は数千万円から数億円規模に達することも珍しくなく、経営層を数字とリスクの両面で説得できなければ稟議は前に進みません。「レガシーシステムのモダナイゼーション」記事が放置コストの構造そのものやROIの示し方の基礎に重心を置くのに対し、本記事はその一歩先、すなわちRFP作成・ベンダー選定・予算承認という稟議を通すための実務プロセスと、経営判断の具体的な事例に焦点を当てます。
本記事では、レガシーシステム刷新の保守・運用費用が経営課題になる理由から、放置コストという「先送りの代償」の考え方、稟議を通すためのRFP作成とベンダー選定の実務、予算承認プロセスで押さえるべきポイント、そして経営判断の実例に学ぶ教訓までを体系的に解説します。毎年の保守費用が増え続けているものの経営層への説明に苦戦している担当者の方はもちろん、すでに刷新の稟議準備を進めている方にとっても、予算獲得を後押しする実務的な材料が身に付く内容です。放置コストは複利的に膨らむ性質を持つため、まずは意思決定のプロセスそのものを正しく設計することから始めましょう。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の保守・運用費用が経営課題になる理由

経済産業省の「DXレポート」によれば、企業のIT予算の9割以上がレガシーシステムの維持管理費に充当されているとされ、この構図を放置した場合、2025年以降に日本全体で年間最大12兆円の経済損失が生じる可能性があるという「2025年の崖」が警鐘として鳴らされています。個社レベルで見ても、COBOLやメインフレームに対応できる技術者は高齢化・退職が進み希少化しており、保守を依頼できるベンダーが限られることで人件費相場そのものが上昇していく構造的な圧力がかかります。保守・運用費用の問題が単なる現場のコスト削減テーマではなく経営課題として扱われるべきなのは、この費用の高止まりが会社全体のIT予算配分を歪め、新規のDX投資に回せる原資を圧迫し続けるからです。刷新の稟議を通すには、この構造を経営層が「自分ごと」として理解できる形で提示する必要があります。
放置した場合の3つの経営リスク
レガシーシステムの保守・運用費用を放置した場合の経営リスクは、大きく3つに整理できます。1つ目はコストの肥大化と人材枯渇です。老朽化したシステムの維持・保守にIT予算の多くが割かれ続ける一方、COBOLなどを扱える技術者の退職によってブラックボックス化がさらに進行します。2つ目はセキュリティとコンプライアンスの危機です。OSやハードウェアのサポート終了により、サイバー攻撃や情報漏洩のリスクが放置された状態が続きます。3つ目は競争力の喪失です。古いシステムでは新しいデジタル技術との連携(API連携など)ができず、新しいビジネスモデルの展開が遅れてしまいます。これら3つを個別のリスクとしてではなく、放置期間が長引くほど互いに悪化を加速させ合う一体の構造として経営層に提示することが、危機感の醸成につながります。
コスト構造の技術的な詳細は姉妹記事を参照
技術的負債がどのようにコストを押し上げていくのか、ブラックボックス化が改修コストを雪だるま式に増大させるメカニズム、移行後にどの程度の運用コスト削減が見込めるのかといった詳しい構造の解説や相場データについては、「レガシーシステムのモダナイゼーション」の保守・運用費用・ランニングコストに関する記事で詳しく取り上げています。本記事では、そうしたコスト構造そのものの解説は最小限にとどめ、実際に経営層を動かし予算を確保するための実務、すなわちRFP作成・ベンダー選定・稟議承認のプロセスに絞って解説を進めます。コスト構造の全体像を先に把握したい方は、あわせてご一読いただくことをお勧めします。
放置コストという「先送りの代償」の考え方

稟議を通す上で最も強力な材料になるのが、「刷新にかかる費用」だけでなく「刷新しないことで発生し続ける費用」を対比させて提示する「先送りの代償」という考え方です。保守費用の高止まりは一度発生すると自然には減少せず、着手を1年先送りするごとに人件費相場の上昇や技術者のさらなる退職によって、刷新に必要な予算そのものが増加していく傾向があります。
機会損失と緊急対応コストを可視化する
放置コストには、月々の保守契約費用のように目に見える支出だけでなく、目に見えにくい機会損失と緊急対応コストが含まれます。ハードウェアやミドルウェアの老朽化は突発障害を引き起こしやすく、原因究明・復旧に時間がかかることで「緊急対応コスト」が発生します。この緊急対応コストには、直接的な修理費用だけでなく、業務停止による機会損失やブランド毀損まで含めて考える必要があります。また、レガシーシステムの制約によって新しいデータ活用や外部連携の要望を断らざるを得ない状態が続けば、それ自体が失われた売上・成長機会として計上されるべきコストです。稟議資料では、これらの見えにくいコストを可能な限り定量化し、「今年発生している見えるコスト」と「今後発生しうる見えないコスト」の両方を提示することで、経営層の危機感を数字で裏付けることができます。
2025年の崖・SAP2027年問題という予算獲得の論拠
放置コストの議論を社内で説得力のあるものにするには、自社固有の事情だけでなく、社会全体・業界全体で共有されている外部リミットを引用することも有効です。経済産業省が「システム刷新集中期間」と位置づける2021年から2025年、そして放置した場合の年間最大12兆円という経済損失の予測、さらに世界的な基幹業務システムであるSAP ERPの保守サポートが2027年末に終了するという「2027年問題」は、いずれも自社の判断とは独立して迫ってくる期限として、経営層に「先送りできない理由」を客観的に示す論拠になります。特にSAP等のパッケージ製品に関連する保守サポート終了は、対応するベンダー側のリソースが期限直前に集中し確保が難しくなるという二次的なリスクも伴うため、予算化の緊急性を訴える際の具体的な材料として活用できます。
稟議を通すためのRFP作成とベンダー選定の実務

費用面の稟議を通すためには、単に社内向けの説明資料を作るだけでなく、外部への発注プロセスそのものを精度高く設計することが欠かせません。見積もり金額の根拠が曖昧なままでは、いくら経営リスクを訴求しても稟議の場で数字の妥当性を突かれてしまいます。
RFP(提案依頼書)を精度高く作成する
「とりあえず始めよう」という曖昧な要件定義は、予算超過やスケジュール遅延の温床です。自社のビジネス目標、解決したい課題、定量的な目標、予算、希望納期、評価基準をRFP(提案依頼書)に詳細に文書化し、ベンダーから精度の高い提案を引き出すことが、稟議で提示する見積もり金額の説得力を高める第一歩になります。事前のRFI(情報提供依頼書)で技術的な実現可能性を擦り合わせておくことも有効です。特にレガシーシステムの場合は、現状の仕様書が実態と一致していないケースが多いため、RFP作成の段階で簡易的な現状調査を実施し、ベンダーが精度の高い見積もりを出せる材料を揃えておくことが、後工程での追加費用発生を防ぐ上でも重要です。
ベンダー選定の3大基準と参照確認
プロジェクト失敗の多くはベンダー選定のミスに起因すると言われており、初期費用の安さや大手のネームバリューだけで選んではいけません。確認すべき基準は大きく3つです。1つ目は同業種・類似規模での導入実績とデータ移行の経験、すなわち自社の特殊な業務プロセスを理解しているかどうかです。2つ目はプロジェクト管理とコミュニケーション能力、つまり現場や経営層に非IT用語でわかりやすく説明できるか、トラブル時のエスカレーション体制があるかです。3つ目は運用保守・アフターサポート体制、導入後のサポート範囲やSLA(サービス品質保証)が明確かどうかです。最終候補のベンダーについては、過去に手掛けたクライアント企業に直接ヒアリングを行う参照確認(リファレンスチェック)を実施することで、提案書だけでは見えない実力を見極めることができます。
予算承認プロセスで押さえるべきポイント

ベンダーからの見積もりが揃った後は、いよいよ社内の予算承認プロセスに進みます。ここで提示する資料の質が、稟議が一度で通るか、差し戻しを繰り返して着手が遅れるかを大きく左右します。
TCOでの比較とKPI設定
予算承認の場では、初期構築費用だけでなく運用保守費用を含めた「総所有コスト(TCO)」で現状維持シナリオと刷新シナリオを比較することが基本です。クラウド移行によって運用コストを削減し、1.5〜4年で投資を回収できるといったシミュレーションを提示することで、経営層が投資判断を下しやすい材料が揃います。あわせて、「事務作業時間を30%削減する」「保守対応時間を◯分の1に短縮する」といった明確なKPIを設定しておくことで、投資実行後の効果測定にもつながり、次年度以降の追加投資の稟議も通しやすくなります。ポートフォリオ管理の発想で、コスト削減が主目的の領域(SaaS移行・廃止対象)と、戦略的投資が主目的の領域(コアシステムの再構築)を切り分けて説明することも、予算の配分根拠を明確にする上で有効です。
複数年度予算化と段階的な予算執行
レガシーシステム刷新は投資規模が大きく、単年度予算だけでまかなうことが難しいケースが多いため、複数年度にわたる予算化を前提とした計画立案が現実的です。初年度はアセスメントとPoCに絞った小さな予算枠を確保し、その結果を踏まえて本開発フェーズの予算を翌年度以降に段階的に承認してもらう進め方は、一度に大きな金額を求めるよりも稟議が通りやすく、経営層にとってもリスクを段階的に見極められるメリットがあります。段階的な予算執行を採用する場合は、各フェーズの完了基準と次フェーズへの移行判断基準をあらかじめ合意しておくことで、途中で予算執行が止まってしまう事態を防ぐことができます。
経営判断の実例に学ぶ教訓

費用・予算に関する意思決定の巧拙は、実際のプロジェクトの成否を大きく分けます。ここでは、経営判断のあり方が明暗を分けた2つの実例から、稟議準備に活かせる教訓を確認します。
あえて高い見積もりを選んだ基幹システム刷新の成功例
ある企業が取り組んだ10億円規模の基幹システム刷新プロジェクトでは、外部コンサルタントを選定するコンペにおいて、あえて「最も見積金額が高かった」提案を採用しました。理由は、他社が責任問題を恐れて詳細な現状分析を避ける中、そのコンサルタントだけが「旧システムの構成を全部洗い出す」と明言し、成功への具体的な道筋を提示していたためです。見積金額の安さだけで判断していれば、着手後にブラックボックス化した部分が次々と露呈し、予算超過のリスクはむしろ高まっていたと考えられます。稟議の場で予算の妥当性を説明する際は、単価の安さではなく、提案内容がどこまでレガシー特有のリスクを織り込んでいるかを評価基準に含めることが重要な教訓です。
放置がもたらすコストを示す警鐘事例
2021年に発生したある大手金融機関のシステム障害では、外部調査委員会の報告書により、過去に発生した同種の予兆事象があったにもかかわらず、特段の検討もされないまま仕様が継続されていたことが重大な顧客被害に直結したと指摘されています。復旧までに8時間を要したこの障害は、放置コストが「保守費用の高止まり」という緩やかな形だけでなく、ある日突然、事業継続そのものを揺るがす形で顕在化しうることを示す警鐘事例です。稟議資料に放置コストを盛り込む際は、日常的な保守費用の増加だけでなく、こうした突発的な障害リスクとその事業インパクトも定量的または定性的に併記することで、経営層の危機感をより現実的なものとして共有できます。
まとめ

本記事では、レガシーシステム刷新の保守・運用費用・ランニングコストについて、経営課題になる理由から、放置コストという「先送りの代償」の考え方、稟議を通すためのRFP作成とベンダー選定の実務、予算承認プロセスで押さえるべきポイント、経営判断の実例に学ぶ教訓までを体系的に解説しました。保守・運用費用の議論は、コスト削減という現場目線の話にとどめず、TCOでの比較・KPI設定・複数年度予算化といった経営層が意思決定しやすい形に翻訳して初めて稟議を通過します。放置コストは着手を先送りするほど複利的に膨らみ、選定するベンダーや予算承認の進め方一つで結果は大きく変わります。コスト構造そのものの詳しい解説は姉妹記事の「レガシーシステムのモダナイゼーション」もあわせてご参照いただきつつ、まずは自社の放置コストを可視化し、稟議に必要な材料を早めに揃えることから始めることをお勧めします。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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