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

レガシーシステム改修とは、COBOLや汎用機など老朽化したシステムを対象に、システム全体を作り替えるのではなく、特定の機能・特定のモジュールだけを対象にした部分的・小規模な修正を行う取り組みです。同じくレガシーシステムを扱う既存記事群のうち、「レガシーシステムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという技術手法の使い分けに、「レガシーシステム刷新」が経営層の投資判断・稟議承認プロセスに、「レガシーシステム更改」がベンダー保守契約満了やEOS/EOLという外部から強制される期限に、「レガシーシステムリニューアル」がユーザーの見た目・使い勝手という顧客体験に、「レガシーシステムリアーキテクチャ」がアーキテクチャ構造の技術深掘りに、「レガシーシステムリプレイス」が製品・ベンダー乗り換えという意思決定にそれぞれ重心を置くのに対し、本記事が扱う「レガシーシステム改修」は、全面刷新には予算的に踏み切れないが、特定のバグ修正・法改正対応・特定帳票の改修だけは最小限のコストと期間で済ませたいという、建築の「改修（リノベーション）」に近い発想の取り組みです。

本記事では、レガシーシステム改修が部分的・小規模修正という位置づけであることの整理から、改修案件の開発期間・スケジュールの目安、法改正対応や特定バグ修正といった典型的な改修案件別のスケジュール感、納期が読みにくくなる要因と遅延を防ぐ進め方、そして依頼先選定と着手判断が期間に与える影響までを体系的に解説します。全面刷新や技術手法全般の詳しい内容はそれぞれ姉妹記事に譲り、本記事では「予算も期間も限られる中で、必要な部分だけを確実に直しきる」という、中小企業・予算制約のある企業の担当者が最も知りたい論点に絞って解説します。他の波に比べて開発期間・費用感は小さめになる点も、あわせて押さえておきましょう。

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

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

レガシーシステム改修とは何か（部分的・小規模修正という位置づけ）

建築の世界で「改修（リノベーション）」といえば、家全体を建て替えるのではなく、傷んだ屋根や水回りだけをピンポイントで直す工事を指します。レガシーシステム改修もこれと同じ発想で、COBOLや汎用機上の基幹システム全体を作り替えるのではなく、特定の機能・特定のモジュールだけを対象にした修正で済ませるという選択肢です。全面刷新には数千万円〜数億円規模の予算と長期間のプロジェクト体制が必要になりますが、多くの中小企業・予算制約のある企業にとって、その規模の投資には踏み切れないのが実情です。開発期間を正しく見積もるには、まず「全部を変える」のではなく「必要な部分だけを直す」という前提そのものを理解しておく必要があります。

「レガシーシステムのモダナイゼーション」「刷新」「更改」「リニューアル」「リアーキテクチャ」「リプレイス」という6つの姉妹記事は、いずれも既存システムを大きく作り替えることを前提に、技術手法・経営判断・契約期限・顧客体験・アーキテクチャ構造・製品乗り換えという異なる切り口で解説しています。これに対し「レガシーシステム改修」は、そもそも全面的な作り替えを前提にしません。特定のバグを直す、法改正に対応する、特定の帳票フォーマットを変更するといった、範囲が明確に限定された修正だけを対象にします。開発期間の見積もりも、6波のような数ヶ月〜数年単位の大規模プロジェクトではなく、数週間〜数ヶ月という短いスパンで考える必要がある点が最大の違いです。

COBOLや汎用機上で長年運用されてきた基幹システムほど、全面刷新のハードルは高くなります。刷新には数千万円〜数億円規模の予算、数年単位の期間、そして経営層を巻き込んだ合意形成が必要になるため、「刷新したほうがいいのは分かっているが、今すぐその決断はできない」という企業は少なくありません。一方で、日々の業務では「この帳票のフォーマットを変えたい」「法改正に対応しないと業務が回らない」「特定のバグを直さないと現場が困っている」という、待ったなしの小さな課題は次々と発生します。レガシーシステム改修は、こうした「全面刷新はまだ先だが、今すぐ困っている部分だけは何とかしたい」というニーズに応える、現実的な選択肢として位置づけられます。開発期間・予算の両面で、全面刷新とは一桁違う規模感で計画できる点が最大の利点です。

改修案件の開発期間・スケジュールの目安（工程別）

レガシーシステム改修の開発期間は、対象範囲の大きさによって大きく2段階に分かれます。全面刷新と比較すればいずれも短期間で済みますが、「小規模」と「中規模」を混同すると見積もりを誤るため、まずは自社の改修がどちらに該当するかを見極める必要があります。

一部機能の刷新、特定画面の再構築、周辺機能の置き換えといった対象を限定した小規模な改修は、費用感でおおむね500万〜2,000万円程度、期間は数週間〜数ヶ月が目安です。機能をシンプルに絞り込んだ改修であれば2〜3ヶ月程度で完了するケースもあり、ごく小規模な業務ツールのバグ修正や軽微な自動化であれば、数日〜1ヶ月程度で済むこともあります。一方、既存システムの一部再構築、複数部門をまたぐ業務見直し、データ移行や外部連携を伴う改修になると中規模改修に分類され、費用は2,000万〜8,000万円程度、期間は数ヶ月〜1年程度に伸びます。全面刷新（フルスクラッチでのリビルド）が費用8,000万〜数億円以上、期間半年〜複数年になることと比較すると、部分改修はいずれの規模でも一桁小さいスケールで計画できる点が大きな特徴です。

「前任者が不在で、ドキュメントも残っていない」という古いアパレル品質管理システムの改善案件では、事前の現状把握と調査・解析を丁寧に行った上で、インフラ改善に4ヶ月、その後の機能改善に6ヶ月、合計10ヶ月をかけて継続的に開発が進められました。一気に全機能を作り替えるのではなく、インフラ部分と機能部分を切り分けて段階的に改修を進めたことが、限られた予算の中でプロジェクトを完遂できた要因です。このように、レガシーシステム改修では一度に大きな範囲を対象にするのではなく、優先度の高い部分から順に、継続的に手を入れていくスタイルが現実的です。開発期間の見積もりも、単発のプロジェクトとしてではなく、こうした継続改修の1サイクルとして捉えることが、無理のないスケジュールにつながります。

典型的な改修案件別のスケジュール感（法改正対応・バグ修正・帳票改修）

レガシーシステム改修と一口に言っても、案件の性質によって求められるスケジュール感は異なります。ここでは特に発生頻度の高い3つの典型パターンを取り上げます。

インボイス制度や消費税率変更といった法改正対応は、期限が明確に決まっている改修案件です。決まった「◯ヶ月で完了する」という画一的な目安があるわけではありませんが、変更内容が発表された段階からできるだけ早めに、余裕を持ったスケジュールで着手することが必須とされています。ギリギリの納期で改修を進めると、テストが不十分なまま本番リリースせざるを得なくなり、トラブルが発生した際に修正が間に合わず、法的な問題に発展するリスクがあります。法改正対応は「いつまでに」という締め切りが自社の都合とは無関係に決まる案件だからこそ、発表から施行までのリードタイムを、そのまま開発期間として最大限活用する意識が重要です。

システム停止や業務への支障につながる特定バグの修正は、迅速な対応が求められるため、多くの場合は保守契約の範囲内で対応され、対応開始までのSLA（サービスレベル合意）に基づいてスケジュールが決まります。一方、帳票フォーマットの変更や画面の表示項目順序の変更といった軽微な改修は、保守契約外となることが多く、実作業自体は30分〜1時間程度で済む場合でも、ベンダー側の最低作業料金の設定により、案件として独立したスケジュールで扱われる点に注意が必要です。この種の軽微な改修は、単体では数日〜数週間で完了しますが、複数の改修要望が同時に発生した場合は優先順位付けが必要になり、全体としてのスケジュールが読みにくくなる点も見込んでおく必要があります。

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

対象範囲が限定されているはずの部分改修でも、レガシーシステム特有の事情によって納期が計画通りに進まないことがあります。この構造を理解した上で進め方を工夫することが、限られた予算・期間の中で確実に完遂する鍵になります。

レガシーシステムの改修は、既存のコードや仕様がドキュメント化されておらずブラックボックス化しているケースが多く、対象範囲が小さくても既存システムの調査・周辺システムへの影響確認に想定以上の時間がかかります。一般的な新規開発であれば要件定義は工程全体の一部に過ぎませんが、レガシーシステムの部分改修では、この現状調査・要件定義の工程だけで全体スケジュールの10〜20%以上を占めることが珍しくありません。対象が小さいからといって調査を省略してしまうと、着手後に「この機能は想定外の別処理と連携していた」という事態が発覚し、かえって手戻りが発生します。改修規模が小さいプロジェクトほど、事前調査にかける時間の比率が相対的に大きくなるという点を、見積もり段階からあらかじめ織り込んでおく必要があります。

特定機能のみを対象にした改修であっても、修正したプログラムが既存の機能に悪影響を及ぼしていないかを確認する「デグレードテスト（リグレッションテスト）」は必須の工程です。対象範囲が小さいからとテストを簡略化してしまうと、改修箇所以外の機能に予期しない不具合が発生し、稼働後にかえって大きなトラブルへと発展するリスクがあります。開発工程だけでなく、このテスト工程や本番移行に向けたスケジュールには十分な余裕を持たせることが重要で、全体スケジュールの10〜30%程度をバッファとして確保しておくことが推奨されています。契約前の見積もり段階から、このバッファを「余分な余裕」ではなく「レガシー改修では構造的にほぼ発生する遅延要因を吸収するための必須要素」として、発注者・開発パートナー双方の共通認識にしておくことが、納期の信頼性を高める実務的な工夫になります。

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

低予算・短納期の改修案件だからこそ、どのパートナー企業に依頼するかによって、実現可能なスケジュールは大きく変わります。小規模案件を軽視せず、確実に対応してくれる依頼先を見極めることが期間短縮の鍵を握ります。

大規模な刷新プロジェクトを主戦場とするベンダーの中には、数百万円規模の小規模改修案件を積極的に受けたがらない、あるいは体制が最適化されておらず対応が後回しになりやすいケースがあります。依頼先を選ぶ際は、対象言語・基盤（COBOLや汎用機等）の解析実績に加えて、低予算・短納期の小規模改修案件をどれだけの件数こなしてきたか、継続的な保守・改修のパートナーとして長期的に付き合える体制があるかを具体的に確認することが重要です。実績が乏しい、あるいは小規模案件への対応に消極的なパートナーに依頼すると、見積もり段階からレスポンスが遅く、着手そのものが先延ばしになりがちです。

「今すぐ困っているわけではないから」と小さな改修要望を放置し続けると、いくつもの未対応課題が積み重なり、いざまとめて対応しようとした際には、もはや部分改修では収まらない規模の作業になってしまうことがあります。着手が遅れるほど、システムの構造理解を持つ担当者の異動・退職も進み、事前調査の期間はさらに長期化します。法改正対応のように期限が外部から強制される案件では、この傾向が特に顕著です。改修規模を小さく・期間を短く保つためには、課題が小さいうちに早めに着手し、優先度の高い部分から継続的に手を入れていく姿勢こそが、結果的に最も低予算・短納期を実現する近道になります。

まとめ

本記事では、レガシーシステム改修の開発期間・スケジュール・納期について、部分的・小規模修正という位置づけの整理から、改修案件の開発期間・スケジュールの目安、法改正対応やバグ修正といった典型的な改修案件別のスケジュール感、納期が読みにくくなる要因と遅延を防ぐ進め方、依頼先選定と着手判断が期間に与える影響を体系的に解説しました。レガシーシステム改修は、小規模改修で費用500万〜2,000万円・期間数週間〜数ヶ月、中規模改修で費用2,000万〜8,000万円・期間数ヶ月〜1年が目安であり、全面刷新と比べていずれも一桁小さい規模感で計画できます。一方で、対象範囲が小さくても事前調査・要件定義には全体の10〜20%以上の時間がかかり、デグレードテストのために10〜30%のバッファが必要になる点は、部分改修だからといって軽視できません。着手を先送りするほど改修範囲は膨らんでいくため、小規模改修を確実にこなせるパートナーに早めに相談し、課題が小さいうちに手を打つことをお勧めします。

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

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