レガシーシステムのモダナイゼーションの開発期間・スケジュール・納期は、レガシー化がどこまで進んでいるかで大きく変わります。そのため、まずは自社の現在地を把握し、そのうえで工程ごとの期間を見積もることが、現実的な計画の出発点になります。
▼全体ガイドの記事
・レガシーシステムのモダナイゼーションの完全ガイド
- 技術的負債：継ぎ足し開発による構造の複雑化
- 属人化：仕様や運用の知識が特定の担当者に偏っている状態
- 刷新方針：現状に合った手法の選定
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムのモダナイゼーションの前提：レガシー化の構造的要因
独立行政法人情報処理推進機構（IPA）が2025年に公表した「レガシーシステムモダン化委員会総括レポート」によると、およそ6割の企業がレガシーシステムを保有しており、特に大企業でその傾向が強いとされています。
日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2024」でも、いまだに4割の企業がレガシーシステムを使用していると報告されています。さらに、経済産業省の「DXレポート2」では、日本企業の約8割が「既存システムの老朽化・ブラックボックス化」をDXやAI活用の最大の障壁と回答しています。
開発期間を正しく見積もるには、まず「なぜ自社のシステムがレガシー化してしまったのか」という構造的な要因を理解する必要があります。原因を理解しないまま作業量だけを見積もると、着手後にアセスメントが想定以上に長期化し、当初のスケジュールが早々に崩れてしまいます。
継ぎ足し開発とベンダー丸投げ体質が生む技術的負債
システムがレガシー化していく背景には、大きく2つの構造的要因があります。1つ目は、継ぎ足し開発によるシステムの肥大化です。拡張性や保守性を軽視して機能を「継ぎ足す」形で開発が進むと、当初の設計思想が崩れ、機能同士が複雑に絡み合うモノリシック（密結合）な構造へと肥大化していきます。
企業システムは10年〜20年以上の長期にわたり運用されるなかで、法制度や業務フローの変化に合わせた改修が繰り返されます。2つ目は「丸投げ体質」とベンダーロックインです。日本のソフトウェア産業の構造的な特徴として、ユーザー企業がIT投資を「コスト」とみなし、開発・運用を外部ベンダーに過度に依存してきた歴史があります。
その結果、社内にシステムの知見が蓄積されず、特定ベンダーの個別カスタマイズ仕様に縛られ続け、高額な維持保守費用を払い続ける構図が固定化されてしまいます。開発期間の見積もりは、こうした負債がどの程度積み上がっているかを把握することから始まります。
属人化・ブラックボックス化と「2025年の崖」
ブラックボックス化は、日々の運用の積み重ねによって徐々に進行します。開発当初は要件定義書や設計書があっても、「急ぎの改修」が優先されてドキュメントの更新が後回しにされるケースが極めて多く、数年経つと「資料はあるが実際のシステムと内容が一致しない」状態に陥ります。
構造が複雑化しドキュメントもないため、コードの一部を書き換えた際にどこへ影響が及ぶかを予測できなくなります。そのため、「怖くて手を加えられない」完全なブラックボックス状態へと転落します。この段階まで進むと、仕様やトラブル対処法は特定の社員・ベンダー担当者の記憶だけで管理される属人化に陥り、担当者の高齢化・退職が進むと誰も改修できない「塩漬け」状態になります。
経済産業省は、これを放置した場合に2025年以降、年間最大12兆円の経済損失が生じる可能性があると「DXレポート」で警告しています。これが「2025年の崖」と呼ばれる所以です。開発期間の計画は、この負の連鎖をどの段階で断ち切るかという意思決定から始まります。
自社のレガシー化度合いを診断するセルフチェック
開発期間の見積もり精度を左右する最大の変数は、自社システムのレガシー化度合いそのものです。チェック項目のうち複数に当てはまる場合は、現状アセスメントの段階で想定以上の時間を要する可能性が高く、スケジュールにあらかじめ余裕を持たせておく必要があります。
属人化・ドキュメント面のチェック項目
属人化・ドキュメント面では、全体像や仕様を説明できる社員が限られている（または誰もいない）ことが挙げられます。トラブル発生時に「まず特定の担当者に聞かないとわからない」状態もあります。
また、仕様について開発ベンダーに問い合わせないと自社では何も判断できないほど、ベンダーに依存している場合もあります。さらに、設計書・仕様書・運用手順書が最新化されず実際のシステムと内容が一致していないことや、過去の改修履歴がどこにも正しく記録されていないことも、確認したい項目です。
これらに該当する数が多いほど、開発着手前の現状アセスメント・分析フェーズの期間は長期化する傾向にあります。そのため、有識者へのヒアリングだけに頼らず、コード解析ツールや構成管理データベースを使って依存関係を客観的に洗い出す工程を、あらかじめスケジュールに組み込んでおくことが重要です。
保守性・インフラ面のチェックとEOLリスク
保守性・インフラ面では、機能改修のたびに影響範囲の特定・確認に膨大な時間がかかる状態が挙げられます。業務部門からDXやデータ活用の要望があっても、既存システムの制約で対応が遅れる、または断っている場合もあります。さらに、複雑な構造が原因で他部署のシステムや最新のSaaSツールとデータ連携ができない状態もあります。
また、現在稼働しているOS・ミドルウェア・ハードウェアの中に、保守サポート期限（EOL）が切れている、または間近に迫っているものが存在します。維持管理費が毎年増え続けているのに、根本的な見直しができていない状態もあります。
特にEOLでは、メーカーサポートが終了すると新たな脆弱性への修正パッチが提供されなくなり、セキュリティリスクが高まります。さらに、古いハードウェアが故障した際に代替部品が入手できず、長時間のダウンタイムに直結するリスクもあります。また、近年は国産メーカーのメインフレーム・UNIXサーバー事業撤退も相次いでおり、EOLの期限そのものが着手時期を強制的に規定するケースが増えています。
レガシーシステムのモダナイゼーションの開発期間・スケジュールの目安
自社の現在地をセルフチェックで把握したら、次に工程別の期間の目安を見ていきます。レガシーシステムのモダナイゼーションでは、実装フェーズだけでなく、その前後の上流工程や稼働後の定着化フェーズを含めて全体のスケジュールを描く必要があります。特にレガシー特有の事情によって上流工程の期間が変動しやすい点が、新規システム開発との大きな違いです。
レガシー特有の理由で長期化する現状アセスメント〜計画策定の期間
上流工程は、現状アセスメント・分析（通常2〜3ヶ月が目安）、目標設定・優先順位の決定（1〜2ヶ月）、手法選定と計画策定（1〜2ヶ月）の3ステップで構成されます。ところが、レガシーシステムでは、この現状アセスメントの期間が想定を大きく超えるケースが頻発します。
その原因は、前章のセルフチェックで確認した属人化やドキュメント乖離そのものにあります。たとえば、構造や依存関係を把握しているはずの有識者がすでに退職している、資料が実態と一致しておらず解析からやり直す必要がある、といった事態が判明することがあります。
そうなると、アセスメント期間だけで当初想定の1.5〜2倍を要することも珍しくありません。見積もりの段階で、このレガシー特有の不確実性をあらかじめバッファとして織り込んでおくことが、後工程で納期が崩れるのを防ぐ最初の手立てになります。
段階的実装〜稼働後定着化までの期間と手法別の目安
計画が固まったあとの段階的実装フェーズは、選ぶ手法によって数ヶ月から2年以上まで大きく変わります。手法ごとに見ると、コードやデータ構造を変えずにインフラのみ移行するリホストは数ヶ月単位です。一方で、基本構造を維持したままクラウドのマネージドサービスへ置き換えるリプラットフォームは4〜10ヶ月程度、ビジネスロジックを維持してコード内部を整理するリファクタリングは8〜18ヶ月程度です。
既存を廃棄してゼロから再構築するリビルドは、12〜30ヶ月以上が目安です。また、実装が終わって本番稼働したあとも、クラウドコストの最適化や運用監視体制の設計、担当者への教育のために、6〜12ヶ月程度の定着化期間が必要になります。この期間も見積もりに含めておく必要があります。
実際の事例では、ある製造業大手のグローバルERP刷新で、システム全体を一気に移行せず、ビジネス価値のまとまりごとに分割する「トランシェ方式」を採用しました。その結果、大規模移行でありながら約12ヶ月での本稼働に成功しています。
納期が読みにくくなる根本原因と遅延を防ぐ進め方
新規開発とは違い、納期が計画どおりに進まない最大の要因は、着手前には見えていなかった「隠れた技術的負債」が実装フェーズで次々と表面化することにあります。そのため、この構造を理解したうえで進め方を工夫することが、納期を守る最善の対策になります。
ブラックボックス化・属人化がアセスメント精度に与える影響
ドキュメントが実態と乖離し、属人化が進んだシステムでは、事前のアセスメントでどれだけ丁寧に調べても、影響範囲を100%洗い出すことは現実的に困難です。
実装フェーズに入って初めて、「このモジュールは想定外の別システムと連携していた」「この処理は特定の担当者しか意図を理解していなかった」といった事実が判明することがあります。その結果、追加の調査や設計変更が発生し、納期が押してしまうケースが後を絶ちません。
これを防ぐには、契約前の提案段階で見積もりに「隠れた負債の発見に対応するバッファ」を明示的に含めてもらうことが有効です。さらに、実装初期の段階で優先度の高い領域から先にコードを解析し、想定外の依存関係を早期に洗い出すアプローチを依頼先と合意しておくことも、遅延の抑えに役立ちます。
ビッグバン方式を避けるインクリメンタル移行と並行稼働
納期遅延を防ぐ最大の鉄則は、システム全体を一度に刷新しようとする「ビッグバン方式」を絶対に避けることです。一括移行では、テスト規模が膨大になりすぎてエラーの特定が事実上不可能になり、稼働直後に業務停止を伴う致命的な障害を招くリスクが高まります。
これに対し、影響の小さい周辺機能から段階的に新しい環境へ移行する「インクリメンタル方式」を採用すれば、隠れた負債が表面化しても影響範囲を局所化できます。これにより、納期とリスクの両方をコントロールしやすくなります。
新旧システムの並行稼働期間を設け、実データで両者を同時運用しながら動作確認を行う進め方も、予期しない不具合を稼働前に発見し、遅延リスクを抑える有効な手段です。
依頼先選定と着手判断が期間に与える影響
同じ規模・技術構成のレガシーシステムでも、どのパートナー企業に依頼するか、そしていつ着手するかによって開発期間は大きく変わります。特にレガシー領域は特殊な技術を扱うからこそ、依頼先の実績が期間短縮の鍵を握ります。
レガシー技術者不足時代の依頼先選定基準
経済産業省の「IT人材需給に関する調査」によれば、2030年には最大で約79万人のIT人材不足に陥ると予測されています。さらに、ユーザー企業のIT人材需要に対し、ベンダー企業からの供給充足率は約66%にとどまっています。
COBOLやメインフレームなど古い技術に対応できる技術者は、この中でも特に希少です。対応できる人材の高齢化や退職が進んでいることは、多くの調査で共通の課題として指摘されています。
依頼先を選ぶ際は、対象言語・基盤の解析実績や類似規模のプロジェクト実績を、具体的な数値とともに確認することが、期間見積もりの妥当性を検証する近道です。また、AWS Transformなどのクラウドベンダー製ツールや国内ベンダーの自動変換ツールの活用実績も確認します。実績が乏しいパートナーに依頼すると、現状分析の段階からつまずき、期間全体が想定以上に伸びるリスクが高まります。
着手を先送りするほど期間・リスクが膨らむ構造
「まだ動いているから」と着手を先送りにする判断は、開発期間の観点からも合理的とは言えません。実際、放置している間にも技術者の退職やドキュメントのさらなる陳腐化は進み、いざ着手するときのアセスメント期間はむしろ長くなります。
加えて、OSやミドルウェアのEOL、メーカーのハードウェア事業撤退といった外部要因によって、期限が強制的に区切られるケースも増えています。その場合、期限直前の駆け込み着手では十分な期間を確保できないまま計画を進めざるを得なくなります。
開発期間を現実的にコントロールしたいのであれば、余裕のあるうちに現状アセスメントだけでも早期に着手し、自社のレガシー化の進行度合いと期限を整理しておくことが最も有効な備えになります。
まとめ
ここまで、レガシーシステムのモダナイゼーションの開発期間・スケジュール・納期について、構造的要因、セルフチェック、工程別の期間の目安、納期の遅延を防ぐ進め方、依頼先選定と着手判断の影響を体系的に解説しました。
開発期間を正しく見積もる鍵は、単なる技術移行のスケジュールとしてではなく、技術的負債やブラックボックス化・属人化といった前提条件そのものの解消と捉えることにあります。
上流工程の期間は、レガシー特有の不確実性によって想定の1.5〜2倍に伸びることがあります。実装フェーズは、リホストの数ヶ月からリビルドの12〜30ヶ月以上まで手法によって大きく変動し、稼働後にも6〜12ヶ月の定着化期間が必要です。
着手を先送りするほど、技術者の枯渇やEOLの期限接近によって期間・リスクは膨らみます。そのため、余裕のあるうちに現状アセスメントから着手し、実績豊富なパートナーに早めに相談することをお勧めします。
▼全体ガイドの記事
・レガシーシステムのモダナイゼーションの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。