レガシーシステム刷新の納期は、技術工程の前後にある社内の手続きまで含めた一続きの流れで見積もって決まります。技術工程の長さだけで計画を組むと、社内の意思決定にかかる時間が抜け落ちがちです。
- 着手判断：事業機会、保守費用、脆弱性などのサインから見た、刷新に動く時期
- 社内プロセス：RFP作成、ベンダー選定、稟議承認にかかる期間
- 技術工程：アセスメントから稼働後の定着まで、手法別の期間
レガシーシステム刷新とは、老朽化したCOBOL・メインフレームや、長年の改修で属人化・ブラックボックス化した「塩漬け」システムを、経営判断としてどう扱うかを中心に据える取り組みです。
「モダナイゼーション」は、リホストからリプレースまでの技術的な手法の使い分けに重心があります。一方で、和語の「刷新」という言葉には、なぜ、いつ着手するのか、誰が決め、どのように予算を確保するのかという、経営層やプロジェクト責任者の視点が色濃く表れます。
開発期間・スケジュール・納期を、技術工程の長さも含めた経営プロセス全体として捉え直します。まず、経営判断としての位置づけと、「いつ着手すべきか」を判断する5つのサインとタイムリミットを整理します。
続いて、稟議承認までの見落とされがちな期間と、アセスメントから稼働までのスケジュール感を取り上げます。最後に、納期遅延を防ぐプロジェクト推進体制のつくり方を解説します。
技術的な移行手法そのものの期間相場は、姉妹記事の「レガシーシステムのモダナイゼーション」に譲ります。そのうえで、意思決定と社内プロセスが全体スケジュールに与える影響に焦点を当てます。
着手判断を先送りするほど、社内の合意形成にかかる時間もリスクも膨らみます。この構造を理解することが、現実的な納期を描く第一歩です。
このテーマの全体像は、下記の記事で解説しています。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム刷新とは何か（経営判断として捉えるべき理由）
独立行政法人情報処理推進機構（IPA）が2025年に公表した「レガシーシステムモダン化委員会総括レポート」によれば、およそ6割の企業がレガシーシステムを保有しており、特に大企業でその傾向が強いとされています。
日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2024」でも、いまだに4割の企業がレガシーシステムを使用していると報告されています。
刷新プロジェクトの開発期間と納期は、技術的な工程の長さだけでなく、誰がいつどのように投資判断を下すかという経営プロセスの長さも含めて見積もる必要があります。
新規開発では技術検証が終われば着手できますが、レガシー刷新では、経営層の合意形成そのものが最初で最大のボトルネックになりやすいためです。
「モダナイゼーション」との違い、技術手法ではなく意思決定に重心を置く理由
「レガシーシステムのモダナイゼーション」は、リホストからリプレースまでの技術的な移行手法の使い分けや、技術的負債がどう積み重なるかという課題構造に重心を置いています。一方で、「レガシーシステム刷新」という言葉には、経営層がなぜ、いつこの投資を決断すべきかという意思決定の側面が、より強く込められます。
同じレガシーシステムを対象にしていても、情報システム部門が技術的な移行手法を検討する段階と、経営層が予算承認や体制構築を判断する段階では、必要な情報も所要期間も大きく異なります。
技術的な移行手法の詳細や工程別の期間相場を知りたい場合は、姉妹記事「レガシーシステムのモダナイゼーション」の、開発期間・スケジュール・納期に関する解説をあわせてご覧ください。そのうえで中心に扱うのは、その手前にある「刷新に踏み切るという経営判断」が、スケジュール全体に与える影響です。
対象となるのはCOBOL・メインフレーム・塩漬けシステム特有の事情
この記事が想定するのは、COBOLで書かれたメインフレーム上の基幹システムや、長年の改修を重ねて誰も全体像を把握できなくなった「塩漬け」システムです。一般的な業務システムの入れ替えとは、前提が大きく違います。
こうしたシステムでは、経営会議で刷新の是非を議論する前提となる「そもそも現在何ができて何ができないのか」を説明できる社員がいない場合があります。見積もりを取ろうにも、仕様書が実態と一致していないため、ベンダーは精度の高い提案を出しにくくなります。こうした特有の事情が、スケジュール全体に影響します。
一般的なシステム刷新であれば、要件を整理して発注すれば進められる場面でも、レガシーシステムでは現状把握そのものに時間がかかります。そのため、経営層への説明資料を作る段階から、すでに遅延の要因を抱えているケースも少なくありません。この特殊性を理解しておくことが、現実的なスケジュールを描く出発点になります。
「いつ着手すべきか」を判断する5つのサインとタイムリミット
「まだ動いているから」と刷新の検討を先送りにする企業は少なくありませんが、この判断は、開発期間・納期の観点からも合理的とはいえません。
さらに、放置している間にも技術者の退職やドキュメントの陳腐化は進み、いざ着手したときのアセスメント期間はむしろ長くなります。そのため、着手を迷っている担当者にこそ、今すぐ現状分析を始めるべきかどうかを客観的に判断する基準が必要です。
着手を判断する5つのサイン
社内で次のような状態が1つでも見られたら、今すぐ刷新に向けたアセスメント（現状分析）を始める時期です。
- 機会の損失：事業戦略に既存システムが追従できず、新規事業や海外展開の要件に対応できないために、事業機会そのものを逃している状態
- 保守負担の増大：保守費用が継続的に増え、軽微な改修でも高額な費用がかかって、変更のたびに予算が膨らんでいく状態
- セキュリティ面の不備：OSやミドルウェアのサポートが切れた環境で稼働を続けている場合、新たな脆弱性への対応ができません
- 外部連携の欠如：新しい技術やSaaSとの連携が進まず、データ活用ができない状態
- 深刻な属人化：システムの中身を理解している人材が社内にごく一部しかおらず、その担当者の異動や退職がそのままプロジェクトの停止リスクに直結する状態
複数該当するほど、着手を先送りする余地は小さくなります。
2025年の崖とSAP ERP 2027年問題という外部リミット
レガシーシステム刷新の時期を考えるうえで無視できないのは、企業の内部事情とは別に迫ってくる外部リミットです。経済産業省は「DXレポート」において、2021年から2025年を「システム刷新集中期間」と位置づけました。
その根拠は、2025年時点で「21年以上稼働しているレガシーシステムが全体の6割を占める」という予測にあります。この技術的負債を解消できなければ、日本全体で2025年以降に年間最大12兆円の経済損失が生じる可能性があり、これが「2025年の崖」と呼ばれて警鐘が鳴らされています。
さらに、世界的な基幹業務システムであるSAP ERP（ECC6.0）の保守サポートは、当初の2025年から延長されたものの、2027年末に終了する「2027年問題」が確実に迫っています。長年のカスタマイズでシステムが肥大化・複雑化した企業ほど後継システムへの移行は容易ではないため、余裕あるスケジュールを確保するには、外部リミットから逆算して早期に着手判断を行うことが不可欠です。
意思決定〜稟議承認にかかる期間（現場が見落としがちな社内プロセス）
多くの企業は、刷新のスケジュールを検討する際、開発ベンダーが示す「要件定義から稼働まで」の期間だけで計画を立てがちです。しかし実際には、その手前に、社内で意思決定を通すための期間が存在します。
この期間は個社の事情によって大きく変わるにもかかわらず、見落とされがちです。そのため、後になって「思ったより着手が遅れた」という事態を招きます。
RFP作成・ベンダー選定コンペにかかる期間
「とりあえず始めよう」という曖昧な要件定義は、予算超過やスケジュール遅延の温床になります。
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つのサインや外部リミットを見てきました。そのうえで、稟議承認までの期間、全体のスケジュール感、推進体制のつくり方を確認しました。
レガシーシステム刷新のスケジュールは、技術工程の長さに、RFP作成、ベンダー選定、稟議承認といった社内プロセスの長さを合算して、初めて現実的なものになります。着手判断を先送りするほど外部リミットとの距離は縮まり、選択肢とスケジュールの余裕は失われていきます。
技術的な移行手法の詳細は姉妹記事の「レガシーシステムのモダナイゼーション」もあわせて参照しつつ、まずは経営層を巻き込んだ着手判断から始めることをお勧めします。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。