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

レガシーシステム刷新とは、老朽化したCOBOL・メインフレームや、長年の改修で属人化・ブラックボックス化してしまった「塩漬け」システムを、経営判断としてどう扱うかという意思決定そのものを主題とする取り組みです。カタカナ英語の「モダナイゼーション」が技術的なアプローチ（リホスト・リプラットフォーム・リファクタリング・リビルド・リプレース）の使い分けに重心を置くのに対し、和語の「刷新」という言葉には、なぜ・いつ着手するのか、誰が意思決定し、どのように予算を確保するのかという経営層・プロジェクト責任者の視点が色濃く反映されます。本記事では、レガシー化した具体的なシステムを対象に、開発期間・スケジュール・納期を「技術工程の長さ」としてではなく、着手判断から稟議承認、プロジェクト推進体制までを含めた経営プロセス全体として捉え直します。

本記事では、レガシーシステム刷新という言葉が持つ経営判断としての位置づけから、「いつ着手すべきか」を判断する5つのサインとタイムリミット、意思決定から稟議承認までにかかる見落とされがちな期間、アセスメントから稼働までのプロジェクト全体のスケジュール感、そして納期遅延を防ぐプロジェクト推進体制のつくり方までを体系的に解説します。技術的な移行手法そのものの詳しい期間相場は既存の「レガシーシステムのモダナイゼーション」記事に譲り、本記事では意思決定と社内プロセスが全体スケジュールに与える影響という、見落とされがちな論点に焦点を当てます。着手判断を先送りするほど、社内合意形成にかかる時間もリスクも膨らむ構造を理解することが、現実的な納期を描く第一歩です。

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

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

レガシーシステム刷新とは何か（経営判断として捉えるべき理由）

独立行政法人情報処理推進機構（IPA）が2025年に公表した「レガシーシステムモダン化委員会総括レポート」によれば、およそ6割の企業がレガシーシステムを保有しており、特に大企業でその傾向が強いとされています。日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2024」でも、いまだに4割の企業がレガシーシステムを使用していると報告されています。こうしたレガシーシステムの刷新プロジェクトで開発期間・納期を正しく見積もるには、技術的な工程の長さだけでなく、誰が・いつ・どのようにこの投資判断を下すのかという経営プロセスの長さを含めて考える必要があります。技術検証さえ終われば着手できる新規開発とは異なり、レガシー刷新は経営層の合意形成そのものが最初の、そして最大のボトルネックになりやすいためです。

「レガシーシステムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという技術的アプローチの使い分けや、技術的負債がどのように蓄積していくかという課題構造の解説に重心を置いているのに対し、「レガシーシステム刷新」という言葉には、経営層がなぜ・いつこの投資を決断すべきかという意思決定の側面がより強く込められます。同じレガシーシステムを対象にしていても、情報システム部門が技術的な移行手法を検討するフェーズと、経営層が予算承認や体制構築を判断するフェーズでは、必要な情報も所要期間も大きく異なります。技術的な移行手法の詳細や工程別の期間相場について詳しく知りたい方は、姉妹記事である「レガシーシステムのモダナイゼーション」の開発期間・スケジュール・納期に関する解説をあわせてご覧ください。本記事では、その手前にある「刷新に踏み切るという経営判断」がスケジュール全体にどう影響するかを中心に扱います。

本記事が想定するレガシーシステム刷新の対象は、一般的な業務システムの入れ替えではなく、COBOLで書かれたメインフレーム上の基幹システムや、長年改修を重ねた末に誰も全体像を把握できなくなった「塩漬け」システムです。こうしたシステムでは、経営会議で刷新の是非を議論しようにも「そもそも現在何ができて何ができないのか」を説明できる社員がいない、見積もりを取ろうにも仕様書が実態と一致していないためベンダーが精度の高い提案を出せない、といった特有の事情がスケジュール全体に影を落とします。一般的なシステム刷新であれば要件を整理して発注すればよい場面でも、レガシーシステムの場合は現状把握そのものに時間がかかり、経営層への説明資料を作る段階からすでに遅延要因を抱えているケースが少なくありません。この特殊性を理解しておくことが、現実的なスケジュールを描く出発点になります。

「いつ着手すべきか」を判断する5つのサインとタイムリミット

「まだ動いているから」という理由で刷新の検討を先送りにする企業は少なくありませんが、この判断は開発期間・納期の観点からも合理的ではありません。放置している間にも技術者の退職やドキュメントの陳腐化は進行し、いざ着手した際のアセスメント期間はむしろ長期化します。着手判断を先送りにするかどうかを迷っている段階の担当者にこそ、まず「今すぐ現状分析を始めるべきタイミングかどうか」を客観的に判断するための基準が必要です。

以下のいずれかに該当する場合、今すぐ刷新に向けたアセスメント（現状分析）を開始すべきタイミングだと考えられます。1つ目は、事業戦略に既存システムが追従できないことです。新規事業や海外展開の要件に既存システムが対応できず、事業機会そのものを逃している状態を指します。2つ目は、保守費用が継続的に増加していることです。軽微な改修であっても高額な費用がかかり、変更のたびに予算が膨らんでいく状態です。3つ目は、セキュリティの脆弱性です。OSやミドルウェアのサポートが切れた環境で稼働を続けている場合、新たな脆弱性への対応ができません。4つ目は、外部連携の欠如です。新しい技術やSaaSとの連携が進まず、データ活用ができない状態を指します。5つ目は、深刻な属人化です。システムの中身を理解している人材が社内にごく一部しかおらず、その担当者の異動や退職がそのままプロジェクトの停止リスクに直結する状態です。複数該当するほど、着手を先送りする余地は小さくなります。

レガシーシステム刷新のタイミングを考える上で無視できないのが、企業の内部事情とは独立して迫ってくる外部リミットの存在です。経済産業省は「DXレポート」において、2021年から2025年を「システム刷新集中期間」と位置づけました。その根拠は、2025年時点で「21年以上稼働しているレガシーシステムが全体の6割を占める」という予測にあり、この技術的負債を解消できなければ、日本全体で2025年以降に年間最大12兆円の経済損失が生じる可能性があるという「2025年の崖」が警鐘として鳴らされています。さらに、世界的な基幹業務システムであるSAP ERP（ECC6.0）の保守サポートが2027年末に終了する「2027年問題」も、当初の2025年から延長されたとはいえ確実に迫っています。長年のカスタマイズでシステムが肥大化・複雑化している企業ほど後継システムへの移行は容易ではなく、余裕を持ったスケジュールを確保するためには、外部リミットから逆算して早期に着手判断を行うことが不可欠です。

意思決定〜稟議承認にかかる期間（現場が見落としがちな社内プロセス）

多くの企業がレガシーシステム刷新のスケジュールを検討する際、開発ベンダーが提示する「要件定義から稼働まで」の期間だけを見て計画を立ててしまいますが、実際にはその手前に、社内で意思決定を通すための期間が存在します。この期間は個社の事情によって大きく変動するにもかかわらず、見落とされがちなために、後になって「思ったより着手が遅れた」という事態を招きます。

「とりあえず始めよう」という曖昧な要件定義は、予算超過やスケジュール遅延の温床です。自社のビジネス目標、解決したい課題、定量的な目標、予算、希望納期、評価基準を詳細に文書化したRFP（提案依頼書）を作成し、複数のベンダーから精度の高い提案を引き出すプロセスには、社内調整も含めて相応の期間が必要になります。事前にRFI（情報提供依頼書）で技術的な実現可能性を擦り合わせるケースも増えており、これも期間に加算されます。プロジェクト失敗の多くはベンダー選定のミスに起因するとも言われており、同業種・類似規模での導入実績とデータ移行の経験、プロジェクト管理とコミュニケーション能力、運用保守・アフターサポート体制という3つの基準で複数社を比較検討し、最終候補には過去のクライアントへのリファレンスチェックまで行うとなると、RFP発行から契約締結までに数ヶ月単位の期間を見込んでおく必要があります。

ベンダー選定と並行して、あるいはその後に控えているのが社内稟議・経営会議での承認プロセスです。特にレガシーシステム刷新は投資金額が大きくなりやすいため、部門決裁だけでなく取締役会クラスの承認が必要になるケースも珍しくありません。稟議を通すためには、放置した場合の経営リスク（コストの肥大化、セキュリティ・コンプライアンス上の危機、競争力の喪失）を定量的に訴求する資料の準備、投資対効果（TCO・ROI）のシミュレーション、そして関係部門からの合意取得が必要であり、これらの資料作成と社内調整だけで数週間から数ヶ月を要することが一般的です。稟議に必要な情報がその都度後出しになると差し戻しが発生し期間がさらに伸びるため、着手判断の初期段階から、稟議に必要な材料を見据えて逆算的にスケジュールを組んでおくことが、全体の納期を守る鍵になります。

プロジェクト全体のスケジュール感（アセスメントから稼働まで）

経営判断・稟議承認までのプロセスを終えると、ようやく技術的な移行工程へと進みます。ここでの工程別の期間は、対象システムのレガシー化の度合いと選択する手法によって変動しますが、全体像を把握しておくことは経営会議での説明資料を作る上でも欠かせません。

上流工程は、現状アセスメント・分析（通常2〜3ヶ月が目安）、目標設定・優先順位の決定（1〜2ヶ月）、手法選定と計画策定（1〜2ヶ月）の3ステップで構成されるのが一般的です。ただしレガシーシステム、とりわけCOBOLやメインフレーム上のシステムでは、構造を把握しているはずの有識者がすでに退職している、資料が実態と一致しておらず解析からやり直す必要がある、といった事態が判明し、アセスメント期間だけで想定の1.5〜2倍を要することも珍しくありません。この上流工程の期間見積もりには、前章で解説した稟議承認のためのリードタイムと重なる部分もあるため、経営層への説明とアセスメントの実務を並行して進める体制を組むことが、全体期間を短縮する現実的な工夫になります。

計画が固まった後の実装フェーズは、選択する手法によって数ヶ月から2年以上まで大きく変動します。インフラのみを移行するリホストであれば数ヶ月単位、クラウドのマネージドサービスへ置き換えるリプラットフォームであれば4〜10ヶ月程度、ビジネスロジックを維持したままコード内部を整理するリファクタリングであれば8〜18ヶ月程度、既存を廃棄しゼロから再構築するリビルド・フルスクラッチであれば12〜30ヶ月以上が目安です。手法ごとの詳しい期間相場や技術的な進め方については、「レガシーシステムのモダナイゼーション」の開発期間・スケジュール・納期に関する記事で詳しく解説していますので、あわせてご参照ください。本番稼働した後も、クラウドコストの最適化や運用監視体制の設計、担当者への教育のために6〜12ヶ月程度の定着化期間が必要になる点も、経営層への報告スケジュールに含めておくべき要素です。

納期遅延を防ぐプロジェクト推進体制のつくり方

レガシーシステム刷新は、システムを入れ替えるだけでなく業務プロセスと組織文化そのものを変革する取り組みです。技術的な計画がどれほど精緻でも、推進体制が整っていなければ現場の抵抗や部門間の調整不足によって計画は容易に崩れてしまいます。

「経営層」「IT部門」「業務部門（現場）」の三者が共通の目標を持つ全社横断のプロジェクト体制（PMO）を構築することが、納期を守る最も重要な土台になります。ある企業の10億円規模の基幹システム刷新プロジェクトでは、経営層（専務）がプロジェクト責任者として強力な方針提示と旗振りを担い、情報システム部長がプロジェクトマネージャーを務め、業務部門・開発ベンダー・外部コンサルタントが参画する体制で進められました。IT部門への「丸投げ」は絶対に避け、経営層が率先して変革のビジョンを発信し続けることが、各部門からの細かな追加要望を交通整理し、スケジュールの肥大化を防ぐ上で不可欠です。

納期遅延を防ぐもう一つの鉄則は、システム全体を一度に刷新しようとする「ビッグバン方式」を避けることです。一括移行はテスト規模が膨大になりすぎてエラーの特定が事実上不可能になり、稼働直後に業務停止を伴う致命的な障害を引き起こすリスクが高まります。影響の少ない部門や機能からパイロット導入を行い、検証と改善を重ねながら段階的に移行を進めるスモールスタートは、現場の混乱を防ぐと同時に、想定外の技術的負債が表面化した際の影響範囲を局所化し、納期全体への打撃を最小限に抑える現実的なベストプラクティスです。新旧システムの並行稼働期間を設け、実データで両者を同時運用しながら検証を行う進め方も、遅延リスクを抑える有効な手段になります。

まとめ

本記事では、レガシーシステム刷新の開発期間・スケジュール・納期について、経営判断として捉えるべき理由から、「いつ着手すべきか」を判断する5つのサインと2025年の崖・SAP ERP 2027年問題という外部リミット、意思決定から稟議承認までの見落とされがちな期間、アセスメントから稼働までのプロジェクト全体のスケジュール感、そして納期遅延を防ぐプロジェクト推進体制のつくり方を体系的に解説しました。レガシーシステム刷新のスケジュールは、技術工程の長さだけでなく、RFP作成・ベンダー選定・稟議承認という社内プロセスの長さを合算して初めて現実的なものになります。着手判断を先送りするほど外部リミットとの距離は縮まり、選択肢とスケジュールの余裕は失われていきます。技術的な移行手法の詳細は姉妹記事の「レガシーシステムのモダナイゼーション」もあわせてご参照いただきつつ、まずは経営層を巻き込んだ着手判断から始めることをお勧めします。

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

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