レガシーシステム更改の開発期間・スケジュール・納期について

レガシーシステム更改とは、メインフレームやCOBOLで書かれた古い基幹システムなど、すでにレガシー化している具体的なシステムを対象に、ベンダーの保守サポート契約満了やOS・ミドルウェアのEOS（End of Support）／EOL（End of Life）という「外部から強制される期限」をきっかけに入れ替える取り組みです。同じくレガシーシステムを扱う既存記事のうち、「レガシーシステムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという技術手法の使い分けに重心を置き、「レガシーシステム刷新」が経営層の投資判断・稟議承認プロセスに重心を置くのに対し、本記事が扱う「レガシーシステム更改」は、ベンダーからの保守契約終了通知やOSのサポート終了告知という具体的な期限そのものから逆算して、開発期間・スケジュール・納期をどう組み立てるかに焦点を当てます。

本記事では、レガシーシステム更改を動かす具体的な外圧トリガーの実態から、期限から逆算した開発期間・スケジュールの目安、更改を先送りした場合のセキュリティリスク・障害時サポート不能リスクという緊急性、納期を守るための進め方、そして依頼先選定と着手判断が期間に与える影響までを体系的に解説します。技術手法や経営判断の詳しい内容はそれぞれ姉妹記事に譲り、本記事では「いつまでに動かなければならないのか」という期限管理の観点から現実的なスケジュールを描くための判断軸をお伝えします。

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

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

レガシーシステム更改とは何か（契約満了・EOS/EOLという外圧トリガーで動く更改）

「まだ動いているから」という理由でレガシーシステムの入れ替えを先送りにしている企業は少なくありませんが、更改のタイミングは自社の都合だけで決められるものではありません。ベンダーの保守サポート契約満了、ハードウェアのリース期限、そしてOS・ミドルウェアのEOS/EOLという、企業側の意向とは無関係に外部から強制される期限が、更改プロジェクトの実質的なデッドラインになります。この「外圧トリガー」の性質を正しく理解することが、開発期間・スケジュールを現実的に組み立てるための出発点です。

メインフレームやCOBOLで構築された基幹システムのような大規模な独自ハードウェア・ソフトウェアは、ベンダーが保守サポートを終了する際、事業への影響の大きさから通常はサポート終了の3〜5年前にロードマップとともに公式なアナウンスが行われるのが一般的です。しかし、この「予告」を受け取ってからようやく検討を始める企業は少なくなく、通知が来てから移行方針を決定しても、大規模で複雑なシステムであれば移行そのものに1年以上を要するため、直前の対応では到底間に合いません。加えて、国産メーカーによるメインフレーム・UNIXサーバー事業からの撤退も相次いでおり、これまで長期にわたり延長を重ねてきた保守契約そのものが、ある時点で「これ以上の延長は不可能」という形で強制的に打ち切られるケースも増えています。契約満了通知は単なる事務連絡ではなく、開発期間・スケジュールを規定する最も重要な起点として扱う必要があります。

レガシーシステムを支えるOS・ミドルウェアのサポート終了も、更改を強制する外圧として無視できません。実際に、2023年10月にはWindows Server 2012／2012 R2の延長サポートが終了し、2024年6月にはCentOS 7のサポートが終了、そして2025年10月には一般利用者にも馴染み深いWindows 10のサポートまでもが終了しました。さらに、世界的な基幹業務システムであるSAP ERP（ECC6.0）についても、標準保守サポートが2027年末に終了する「2027年問題」が確実に迫っています。これらのEOLは、システムの機能や業務要件とは無関係に、あらかじめ決められた日付として一方的にやってくる点が最大の特徴です。自社のレガシーシステムがどのOS・ミドルウェアの上で稼働しているかを棚卸しし、それぞれのEOLの期日をカレンダーに落とし込むことが、開発期間・スケジュールを検討する最初の一歩になります。

期限から逆算する開発期間・スケジュールの目安

契約満了・EOLという期限が明確な更改プロジェクトでは、通常のシステム開発のように上流から積み上げてスケジュールを組むのではなく、デッドラインから逆算して各工程に配分できる期間を割り出す「タイムボックス型」の発想が不可欠です。更改本体の実作業だけでなく、その手前に発生するリードタイムも含めて全体像を把握しておく必要があります。

ベンダーから保守契約終了やEOLの通知を受け取っても、すぐに開発工程に入れるわけではありません。まず現行システムの資産・機能・データ量を棚卸しし、RFP（提案依頼書）を作成して複数のベンダーから提案を募り、比較検討のうえで発注先を決定し、社内で予算承認を得るという一連のプロセスが必要です。特にメインフレーム・COBOLシステムの場合、仕様書が実態と乖離していることが多く、棚卸しの段階だけで数ヶ月を要することも珍しくありません。このリードタイムを見込まずに「通知から逆算した残り期間」だけで開発期間を計算してしまうと、着手する頃にはすでに納期に間に合わない状況に陥っているという事態を招きます。

リードタイムを終えて更改本体の工程に入ると、現状分析・企画・ベンダー選定に約2〜3ヶ月、要件定義に約3〜4ヶ月、設計・開発に約4〜6ヶ月、テスト・データ移行・UAT（ユーザー受け入れテスト）に約3〜5ヶ月というのが、大規模な基幹系システムを12〜18ヶ月程度で更改する場合のおおよその工程別目安です。メインフレームからオープン系・クラウド環境への移行では、複数回にわたるデータ移行リハーサルが不可欠であり、この工程を軽視すると本番切り替え直前になって想定外の不整合が発覚し、全体スケジュールを押し戻す最大の要因になります。契約満了・EOLという動かせない期日がある以上、テスト・移行フェーズには十分な余裕を持たせた工程設計が求められます。

更改を先送りした場合のセキュリティリスク・障害時サポート不能リスク

更改の開発期間を検討する際、「間に合わなければ、もうしばらく今のシステムを使い続ければよい」と安易に考えるのは危険です。契約満了・EOLという期限を過ぎて稼働し続けることには、後戻りのできない具体的なリスクが伴うことを理解しておく必要があります。

OS・ミドルウェアがEOLを迎えると、ベンダーは新たに発見された脆弱性に対する修正パッチの提供を停止します。これは「今すぐ何かが起こる」というものではなく、日を追うごとに攻撃者に狙われやすい穴が塞がれないまま蓄積していく、静かに進行するリスクです。ランサムウェアなどの攻撃を受けて重大な情報漏えいや事業停止に至れば、直接的な復旧費用だけでなく、損害賠償や信用の失墜という形で、更改を先送りして節約したはずのコストをはるかに上回る損失を招きかねません。特にメインフレーム・COBOLで構築された基幹システムは顧客情報や取引データなど重要度の高い情報を扱っていることが多く、脆弱性放置のリスクは事業全体に波及する規模になりやすい点を認識しておく必要があります。

保守契約が満了した後にシステム障害が発生した場合、これまで当たり前のように受けられていたベンダーからの復旧支援を得られなくなります。原因調査から復旧作業まですべて自社もしくは限られた協力会社だけで対応せざるを得ず、対応の遅れがそのまま業務停止時間の長期化に直結します。加えて、古いハードウェアが故障した場合には生産終了によって代替部品を入手できず、修理そのものが不可能になるケースもあります。古い技術に対応できる保守担当者自体が高齢化・退職によって減少していることも、いざという時の対応力をさらに弱める要因です。契約満了・EOLという期限は、単なる「サポートが受けられなくなる日」ではなく、「業務が止まった時に誰も助けてくれなくなる日」として捉えることが、開発期間の緊急性を正しく評価する鍵になります。

期限に間に合わせるための進め方

契約満了・EOLという動かせない期限が定まっている以上、遅延を前提とした計画ではなく、期限内に安全に着地させるための進め方そのものを工夫する必要があります。

期限に間に合わせようとするあまり、全機能を一斉に切り替える「一括移行（ビッグバン）」を選んでしまうと、万が一トラブルが発生した際に長時間のシステム停止という致命的な事態を招きます。これに対し、EOLの緊急性が特に高いコア機能から優先的に新環境へ移行する「段階移行」、特定の部門・拠点だけで先行導入して問題点を洗い出す「パイロット移行」、新旧システムを同時に稼働させて実データで検証する「並行稼働」を組み合わせることで、期限内に着地させながらもリスクを局所化できます。どの機能をいつまでに、どの方式で移行するかをあらかじめ整理しておくことが、期限内完遂の実務的な鍵になります。

どれだけ計画を工夫しても、開発期間の見通しがEOLの期日に間に合わないと判明する場合があります。そうした際の現実的な選択肢が、純正ベンダー以外の企業がハードウェア・ソフトウェアの保守を請け負う「第三者保守サービス」の活用です。EOSを迎えた機器であっても一定期間サポートを受けられるため、更改プロジェクトを完遂するまでの時間を安全に稼ぐことができます。ただし第三者保守はあくまで一時的な延命策であり、新たな脆弱性への根本的な対応にはならない点には注意が必要です。期限に間に合わない可能性が見えてきた段階で早めにこの選択肢を検討し、本更改プロジェクトのスケジュールに無理な短縮を強いないようにすることが、結果的に納期と品質の両方を守ることにつながります。

依頼先選定と着手判断が期間に与える影響

同じ契約満了・EOLの期限を抱えていても、どのパートナー企業に依頼するか、そしていつ着手判断を下すかによって、実現可能なスケジュールは大きく変わります。

メインフレームやCOBOLといった古い技術に対応できる技術者は年々希少になっており、対応できる人材の高齢化・退職が進んでいることが多くの調査で共通の課題として指摘されています。依頼先を選ぶ際は、対象言語・基盤の解析実績、自動変換ツール（コンバーター）の活用実績、契約満了・EOLを見据えた更改プロジェクトでの類似規模の実績を具体的な数値とともに確認することが、期限内完遂の妥当性を検証する近道です。実績が乏しいパートナーに依頼すると、現状棚卸しの段階からつまずき、ただでさえ厳しい期限がさらに圧迫されるリスクが高まります。

契約満了・EOLという期限は着手を先送りしても動いてはくれません。むしろ先送りするほど、選べる進め方の幅は狭まっていきます。期限まで十分な余裕があれば、段階移行やパイロット移行といったリスクの低い進め方を選べますが、期限直前になって動き出すと、一括移行に近い強行スケジュールを選ばざるを得なくなり、それに伴うリスクも跳ね上がります。また、着手が遅れるほど有力なパートナー企業のリソースが埋まってしまい、希望する体制を確保できない可能性も高まります。契約満了通知やEOLのアナウンスを受け取った時点、あるいはそれ以前の段階から現状棚卸しだけでも早期に着手し、自社の更改の緊急度と現実的な選択肢を可視化しておくことが、期限内に安全に完遂するための最も有効な備えになります。

まとめ

本記事では、レガシーシステム更改の開発期間・スケジュール・納期について、契約満了・EOS/EOLという外圧トリガーの実態から、期限から逆算した工程別の期間目安、更改を先送りした場合のセキュリティリスク・障害時サポート不能リスク、期限に間に合わせるための進め方、依頼先選定と着手判断が期間に与える影響までを体系的に解説しました。レガシーシステム更改の開発期間は、技術的な作業量だけでなく、ベンダーからの通知後に発生するリードタイムと、契約満了・EOLという動かせない期日の両方を織り込んで初めて現実的なものになります。先送りするほどセキュリティリスクと障害時のサポート不能リスクは静かに積み上がり、選べる進め方の選択肢も狭まっていきます。技術手法の詳細は「レガシーシステムのモダナイゼーション」、経営判断・稟議承認プロセスの詳細は「レガシーシステム刷新」の各記事もあわせてご参照いただきつつ、まずは自社が抱えるレガシーシステムの契約満了日・EOLの期日を正確に棚卸しすることから始めることをお勧めします。

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

株式会社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を創業。