レガシーシステムのモダナイゼーションの開発期間・スケジュール・納期について

レガシーシステムのモダナイゼーションとは、老朽化した基幹システムや業務システムがなぜ「レガシー」と呼ばれる状態に陥るのかという課題そのものに向き合いながら、クラウドネイティブな環境へと作り替えていく取り組みです。手法論としての「システムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つのアプローチの使い分けに重心を置くのに対し、本記事が扱う「レガシーシステムのモダナイゼーション」は、継ぎ足し開発による技術的負債の蓄積、ドキュメントと実態が乖離するブラックボックス化、担当者しか仕様がわからない属人化、そして改修できないまま放置される「塩漬け」問題という、なぜ着手が必要なのかという前提側に重心を置いて解説します。開発期間・スケジュール・納期は、この前提となるレガシー化の進行度合いによって大きく左右されるため、手法の期間相場を知るだけでは正確な計画は立てられません。

本記事では、レガシーシステムがなぜ生まれるのかという構造的な要因から、自社のレガシー化度合いを診断するセルフチェック、工程別の開発期間の目安、納期が読みにくくなる根本原因と遅延を防ぐ進め方、そして依頼先選定と着手判断が期間そのものに与える影響までを体系的に解説します。「そろそろ刷新すべきか」を検討し始めた担当者の方はもちろん、すでに移行計画の立案を進めている方にとっても、現実的なスケジュールを描くための判断軸が身に付く内容です。着手の判断を先送りするほど期間もリスクも膨らみやすいため、まずは自社の現在地を正しく把握することから始めましょう。

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

▼全体ガイドの記事
・レガシーシステムのモダナイゼーションの完全ガイド

レガシーシステムのモダナイゼーションとは何か（なぜレガシー化するのかという前提整理）

独立行政法人情報処理推進機構（IPA）が2025年に公表した「レガシーシステムモダン化委員会総括レポート」によると、およそ6割の企業がレガシーシステムを保有しており、特に大企業でその傾向が強いとされています。日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2024」でも、いまだに4割の企業がレガシーシステムを使用していると報告されており、経済産業省の「DXレポート2」では日本企業の約8割が「既存システムの老朽化・ブラックボックス化」をDXやAI活用の最大の障壁と回答しています。レガシーシステムのモダナイゼーションの開発期間を正しく見積もるには、まずこの「なぜ自社のシステムがレガシー化してしまったのか」という構造的要因を理解する必要があります。原因を理解しないまま作業量だけを見積もると、着手後にアセスメントが想定以上に長期化し、当初のスケジュールが早々に崩れてしまいます。

システムがレガシー化していく背景には、大きく2つの構造的要因があります。1つ目は継ぎ足し開発によるシステムの肥大化です。企業システムは10年〜20年以上の長期にわたり運用される中で、法制度の変更や業務フローの変化に合わせて改修が繰り返されます。拡張性や保守性を軽視して新しい機能を「継ぎ足す」形で開発が進められた結果、当初の設計思想が崩れ、機能同士が複雑に絡み合うモノリシック（密結合）な構造へと肥大化していきます。2つ目は「丸投げ体質」とベンダーロックインです。日本のソフトウェア産業の構造的な特徴として、ユーザー企業がIT投資を「コスト」とみなし、開発・運用を外部ベンダーに過度に依存してきた歴史があります。これにより社内にシステムの知見が蓄積されず、特定ベンダーの個別カスタマイズ仕様に縛られ続け、高額な維持保守費用を払い続ける構図が固定化されてしまいます。開発期間の見積もりは、こうした負債がどの程度積み上がっているかを可視化することから始まります。

ブラックボックス化は日々の運用の積み重ねによって徐々に進行します。開発当初は要件定義書や設計書が存在していても、「急ぎの改修」が優先されドキュメントの更新が後回しにされるケースが極めて多く、数年経つと「資料はあるが実際のシステムと内容が一致しない」状態に陥ります。構造が複雑化しドキュメントもないため、コードの一部を書き換えた際にどこへ影響が及ぶかを予測できなくなり、「怖くて手を加えられない」完全なブラックボックス状態へと転落します。この段階まで進むと、仕様やトラブル対処法は特定の社員・ベンダー担当者の記憶だけで管理される属人化に陥り、担当者の高齢化・退職が進むと誰も改修できない「塩漬け」状態になります。経済産業省はこれを放置した場合、2025年以降に年間最大12兆円の経済損失が生じる可能性があると「DXレポート」で警告しており、これが「2025年の崖」と呼ばれる所以です。開発期間の計画は、この負の連鎖をどの段階で断ち切るかという意思決定から始まります。

自社のレガシー化度合いを診断するセルフチェック

開発期間の見積もり精度を左右する最大の変数は、自社システムのレガシー化度合いそのものです。以下のチェック項目に複数該当する場合、現状アセスメントの段階で想定以上の時間を要する可能性が高く、スケジュールにあらかじめ余裕を持たせておく必要があります。

属人化・ドキュメント面では、システムの全体像や仕様を説明できる社員が限られている（または誰もいない）、トラブル発生時に「まず特定の担当者に聞かないとわからない」状態になっている、仕様について開発ベンダーに問い合わせないと自社では何も判断できないほどベンダーに依存している、設計書・仕様書・運用手順書が最新化されておらず実際のシステムと内容が一致していない、過去の改修履歴がどこにも正しく記録されていない、といった項目が挙げられます。これらに該当する数が多いほど、開発着手前の現状アセスメント・分析フェーズの期間は長期化する傾向にあります。有識者へのヒアリングだけに頼らず、コード解析ツールや構成管理データベースを用いて客観的に依存関係を可視化する工程を、あらかじめスケジュールに組み込んでおくことが重要です。

保守性・インフラ面では、機能改修のたびに影響範囲の特定・確認に膨大な時間がかかる、業務部門からDXやデータ活用の要望があっても既存システムの制約で対応が遅れる・断っている、複雑な構造が原因で他部署のシステムや最新のSaaSツールとデータ連携ができない、現在稼働しているOS・ミドルウェア・ハードウェアの中にすでに保守サポート期限（EOL）が切れている、または間近に迫っているものが存在する、維持管理費が毎年増え続けているが根本的な見直しができていない、といった項目を確認します。特にEOLについては、メーカーサポートが終了すると新たな脆弱性への修正パッチが提供されなくなりセキュリティリスクの温床となるほか、古いハードウェアが故障した際に代替部品が入手できず長時間のダウンタイムに直結するリスクがあります。近年は国産メーカーのメインフレーム・UNIXサーバー事業撤退も相次いでおり、EOLの期限そのものが着手時期を強制的に規定するケースが増えています。

レガシーシステムのモダナイゼーションの開発期間・スケジュールの目安

セルフチェックで自社の現在地を把握したら、次に工程別の期間の目安を確認します。レガシーシステムのモダナイゼーションは、実装フェーズだけでなくその前後に発生する上流工程・稼働後の定着化フェーズを含めて全体スケジュールを描く必要があり、特にレガシー特有の事情によって上流工程の期間が変動しやすい点が、新規システム開発との大きな違いです。

上流工程は、現状アセスメント・分析（通常2〜3ヶ月が目安）、目標設定・優先順位の決定（1〜2ヶ月）、手法選定と計画策定（1〜2ヶ月）の3ステップで構成されます。ところがレガシーシステムの場合、この現状アセスメントの期間が想定を大きく超えるケースが頻発します。原因は、前章のセルフチェックで確認した属人化やドキュメント乖離そのものにあります。構造や依存関係を把握しているはずの有識者がすでに退職している、資料が実態と一致しておらず解析からやり直す必要がある、といった事態が判明すると、アセスメント期間だけで当初想定の1.5〜2倍を要することも珍しくありません。見積もり段階では、このレガシー特有の不確実性をあらかじめバッファとして織り込んでおくことが、後工程での納期崩壊を防ぐ最初の防波堤になります。

計画が固まった後の段階的実装フェーズは、選択する手法によって数ヶ月から2年以上まで大きく変動します。コードやデータ構造を変えずインフラのみ移行するリホストであれば数ヶ月単位、基本構造を維持しつつクラウドのマネージドサービスへ置き換えるリプラットフォームであれば4〜10ヶ月程度、ビジネスロジックを維持したままコード内部を整理するリファクタリングであれば8〜18ヶ月程度、既存を廃棄しゼロから再構築するリビルドであれば12〜30ヶ月以上が目安です。実際の事例では、ある製造業大手のグローバルERP刷新において、システム全体を一気に移行せずビジネス価値のまとまりごとに分割する「トランシェ方式」を採用し、大規模移行でありながら約12ヶ月での本稼働に成功しています。実装が完了し本番稼働した後も、クラウドコストの最適化や運用監視体制の設計、担当者への教育のために6〜12ヶ月程度の定着化期間が必要になる点も見積もりに含めておく必要があります。

納期が読みにくくなる根本原因と遅延を防ぐ進め方

レガシーシステムのモダナイゼーションで納期が計画通りに進まない最大の要因は、新規開発のような要件の追加・変更ではなく、着手前には見えていなかった「隠れた技術的負債」が実装フェーズで次々と表面化することにあります。この構造を理解した上で進め方を工夫することが、納期を守る最善の対策になります。

ドキュメントが実態と乖離し属人化が進んだシステムでは、事前のアセスメントでどれだけ丁寧に調査しても、影響範囲を100%洗い出すことは現実的に困難です。実装フェーズに入って初めて「このモジュールは想定外の別システムと連携していた」「この処理は特定の担当者しか意図を理解していなかった」といった事実が判明し、追加の調査・設計変更が発生することで納期が押してしまうケースが後を絶ちません。これを防ぐには、契約前の提案段階で見積もりに「隠れた負債の発見に対応するバッファ」を明示的に含めてもらうこと、そして実装初期の段階で優先度の高い領域から先にコードを解析し、想定外の依存関係を早期に洗い出すアプローチを依頼先と合意しておくことが有効です。

納期遅延を防ぐ最大の鉄則は、システム全体を一度に刷新しようとする「ビッグバン方式」を絶対に避けることです。一括移行はテスト規模が膨大になりすぎてエラーの特定が事実上不可能になり、稼働直後に業務停止を伴う致命的な障害を引き起こすリスクが高まります。これに対し、影響の小さい周辺機能から段階的に新しい環境へ移行していく「インクリメンタル方式」を採用することで、隠れた負債が表面化しても影響範囲を局所化でき、納期とリスクの両方をコントロールしやすくなります。新旧システムの並行稼働期間を設け、実データで両者を同時運用しながら動作確認を行う進め方も、予期しない不具合を稼働前に発見し、遅延リスクを抑える有効な手段です。

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

同じ規模・技術構成のレガシーシステムでも、どのパートナー企業に依頼するか、そしていつ着手するかによって開発期間は大きく変わります。特にレガシー領域は特殊な技術を扱うからこそ、依頼先の実績が期間短縮の鍵を握ります。

経済産業省の「IT人材需給に関する調査」によれば、2030年には最大で約79万人のIT人材不足に陥ると予測されており、ユーザー企業のIT人材需要に対するベンダー企業からの供給充足率は約66%にとどまっています。COBOLやメインフレームなど古い技術に対応できる技術者はこの中でもさらに希少で、対応できる人材の高齢化・退職が進んでいることが多くの調査で共通の課題として指摘されています。依頼先を選ぶ際は、対象言語・基盤の解析実績、AWS Transformなどのクラウドベンダー製ツールや国内ベンダーの自動変換ツールの活用実績、類似規模のプロジェクト実績を具体的な数値とともに確認することが、期間見積もりの妥当性を検証する近道です。実績が乏しいパートナーに依頼すると、現状分析の段階からつまずき、期間全体が想定以上に伸びるリスクが高まります。

「まだ動いているから」と着手を先送りにする判断は、開発期間の観点からも合理的とは言えません。放置している間にも技術者の退職やドキュメントのさらなる陳腐化は進行し、いざ着手した際のアセスメント期間はむしろ長期化します。加えて、OSやミドルウェアのEOL、メーカーのハードウェア事業撤退といった外部要因が期限を強制的に区切ってしまうケースも増えており、期限直前の駆け込み着手では十分な期間を確保できないまま計画を進めざるを得なくなります。開発期間を現実的にコントロールしたいのであれば、余裕のあるうちに現状アセスメントだけでも早期に着手し、自社のレガシー化の進行度合いと期限を可視化しておくことが最も有効な備えになります。

まとめ

本記事では、レガシーシステムのモダナイゼーションの開発期間・スケジュール・納期について、なぜレガシー化するのかという構造的要因、自社の状態を診断するセルフチェック、工程別の期間の目安、納期が読みにくくなる根本原因と遅延を防ぐ進め方、依頼先選定と着手判断が期間に与える影響を体系的に解説しました。開発期間を正しく見積もる鍵は、これを単なる技術移行のスケジュールとしてではなく、継ぎ足し開発とベンダー丸投げ体質が生んだ技術的負債、ブラックボックス化・属人化という前提条件そのものの解消と捉えることにあります。上流工程の期間はレガシー特有の不確実性によって想定の1.5〜2倍に伸びることがあり、実装フェーズはリホストの数ヶ月からリビルドの12〜30ヶ月以上まで手法によって大きく変動し、稼働後も6〜12ヶ月の定着化期間が必要です。着手を先送りするほど技術者の枯渇や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を創業。