レガシーシステム改修の期間は、対象を機能やモジュールに絞り、調査・改修・テスト・切り替えの工程ごとに見積もります。小規模なら数週間〜数ヶ月、中規模なら数ヶ月〜1年が目安です。さらに、納期は依頼先の選び方と着手の時期によっても大きく変わります。
姉妹記事は、「モダナイゼーション」が技術手法、「刷新」が経営判断、「更改」が保守契約満了やEOS/EOLという外部期限に重心があります。「リニューアル」は使い勝手、「リアーキテクチャ」は構造の深掘り、「リプレイス」は乗り換えの判断に重心があります。レガシーシステム改修は、全面刷新には予算的に踏み切れないが、バグ修正・法改正対応・特定帳票の改修だけは最小限のコストと期間で済ませたい取り組みです。
- 対象範囲：機能やモジュール単位の改修
- 工程：現行調査から改修、テスト、切り替えまで
- 遅延対策：現行仕様と技術者の確保の確認
▼全体ガイドの記事
・レガシーシステム改修の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム改修の位置づけ（部分的・小規模修正）
建築の「改修（リノベーション）」は、家全体を建て替えず、傷んだ屋根や水回りだけをピンポイントで直す工事を指します。レガシーシステム改修も同じ発想で、COBOLや汎用機上の基幹システム全体は作り替えず、特定の機能やモジュールだけを修正して済ませる選択肢です。
全面刷新には数千万円〜数億円規模の予算と長期間のプロジェクト体制が必要です。そのため、多くの中小企業や予算に制約のある企業にとっては、その規模の投資に踏み切れないのが実情です。開発期間を正しく見積もるには、まず「必要な部分だけを直す」という前提を理解しておく必要があります。
他6波との違いと、部分的・小規模、低予算・短納期を起点とする理由
「レガシーシステムのモダナイゼーション」「刷新」「更改」「リニューアル」「リアーキテクチャ」「リプレイス」の6つの姉妹記事は、いずれも既存システムを大きく作り替えることを前提にしています。それぞれ、技術手法や経営判断、契約期限など、異なる切り口で解説しています。
一方、「レガシーシステム改修」は、そもそも全面的な作り替えを前提にしません。特定のバグを直す、法改正に対応する、特定の帳票フォーマットを変更するといった、範囲が明確に限られた修正だけを対象にします。
そのため、開発期間の見積もりも、姉妹記事で扱う数ヶ月〜数年単位の大規模プロジェクトとは違い、数週間〜数ヶ月という短いスパンで考える必要があります。この点が、姉妹記事との最大の違いです。
COBOL・汎用機の全面刷新に踏み切れない企業が改修を選ぶ理由
COBOLや汎用機で長年運用されてきた基幹システムほど、全面刷新のハードルは高くなります。刷新には数千万円〜数億円規模の予算、数年単位の期間、経営層を巻き込んだ合意形成が必要になります。そのため、「刷新したほうがいいのは分かっているが、今すぐ決断はできない」という企業は少なくありません。
一方で、日々の業務では「この帳票のフォーマットを変えたい」「法改正に対応しないと業務が回らない」「特定のバグを直さないと現場が困っている」という、待ったなしの小さな課題が次々と発生します。
レガシーシステム改修は、「全面刷新はまだ先だが、今すぐ困っている部分だけは何とかしたい」というニーズに応える、現実的な選択肢です。特に、開発期間・予算の両面で、全面刷新とは一桁違う規模感で計画できる点が最大の利点です。
改修案件の開発期間・スケジュールの目安（工程別）
レガシーシステム改修の開発期間は、対象範囲の大きさによって大きく2段階に分かれます。どちらも全面刷新と比べれば短期間で済みます。ただし、「小規模」と「中規模」を混同すると見積もりを誤るため、まずは自社の改修がどちらに当たるかを見極める必要があります。
小規模改修（数週間〜数ヶ月）と中規模改修（数ヶ月〜1年）の目安
一部機能の刷新、特定画面の再構築、周辺機能の置き換えといった、対象を限定した小規模な改修は、費用がおおむね500万〜2,000万円程度、期間は数週間〜数ヶ月が目安です。機能をシンプルに絞り込んだ改修であれば、2〜3ヶ月程度で完了するケースもあります。さらに、ごく小規模な業務ツールのバグ修正や軽微な自動化なら、数日〜1ヶ月程度で済むこともあります。
一方、既存システムの一部再構築、複数部門をまたぐ業務見直し、データ移行や外部連携を伴う改修は、中規模改修に分類されます。費用は2,000万〜8,000万円程度、期間は数ヶ月〜1年程度に伸びます。
全面刷新（フルスクラッチでのリビルド）は、費用が8,000万〜数億円以上、期間が半年〜複数年に及びます。これと比べると、部分改修はいずれの規模でも一桁小さいスケールで計画できる点が大きな特徴です。
ドキュメント不在の古いシステムを継続的に改修した実例
「前任者が不在で、ドキュメントも残っていない」という古いアパレル品質管理システムの改善案件では、事前の現状把握と調査・解析を丁寧に行いました。そのうえで、インフラ改善に4ヶ月、その後の機能改善に6ヶ月、合計10ヶ月をかけて開発が進められました。
インフラ部分と機能部分を切り分けて、段階的に改修を進めたことが、限られた予算の中でプロジェクトを完遂できた要因です。
レガシーシステム改修では、一度に大きな範囲を対象にせず、優先度の高い部分から順に継続的に手を入れていくやり方が現実的です。そのため、開発期間の見積もりも、単発のプロジェクトより継続改修の1サイクルとして捉えるほうが、無理のないスケジュールにつながります。
典型的な改修案件別のスケジュール感（法改正対応・バグ修正・帳票改修）
レガシーシステム改修と一口にいっても、案件の性質によって求められるスケジュール感は異なります。特に発生頻度の高い典型パターンは3つあり、法改正対応、バグ修正、帳票改修です。法改正対応と、バグ修正・帳票改修とでは、スケジュールを決める基準が違います。
法改正対応（インボイス制度・税率変更等）の早期着手
インボイス制度や消費税率変更といった法改正対応は、期限が明確に決まっている改修案件です。「◯ヶ月で完了する」といった画一的な目安があるわけではありませんが、変更内容が発表された段階から、できるだけ早く余裕を持ったスケジュールで着手することが必須とされています。
ギリギリの納期で進めると、テストが不十分なまま本番リリースせざるを得なくなり、トラブルが起きても修正が間に合わず、法的な問題に発展するリスクがあります。
法改正は、締め切りが自社の都合に関係なく決まる案件です。だからこそ、発表から施行までのリードタイムを、そのまま開発期間として最大限に活用する意識が重要です。
バグ修正・帳票改修のSLAと最低作業単位
システム停止や業務への支障につながる特定バグの修正は、迅速な対応が求められます。そのため、多くの場合は保守契約の範囲内で対応され、対応開始までのSLA（サービスレベル合意）に基づいてスケジュールが決まります。
一方、帳票フォーマットの変更や画面の表示項目順序の変更といった軽微な改修は、保守契約外となることが多くあります。実作業は30分〜1時間程度で済む場合でも、ベンダー側の最低作業料金の設定により、案件として独立したスケジュールで扱われる点に注意が必要です。
この種の軽微な改修は、単体では数日〜数週間で完了します。ただし、複数の改修要望が同時に発生すると優先順位付けが必要になり、全体のスケジュールが読みにくくなる点も見込んでおく必要があります。
納期が読みにくくなる要因と遅延を防ぐ進め方
対象範囲が限られているはずの部分改修でも、レガシーシステム特有の事情によって、納期が計画どおりに進まないことがあります。そのため、この構造を理解したうえで進め方を工夫することが、限られた予算と期間で確実に完遂する鍵になります。
事前調査・要件定義の比重（全体の10〜20%以上）
レガシーシステムの改修は、既存のコードや仕様がドキュメント化されておらず、ブラックボックス化しているケースが多くあります。対象範囲が小さくても、既存システムの調査や周辺システムへの影響確認に、想定以上の時間がかかります。
一般的な新規開発では要件定義は工程全体の一部ですが、レガシーシステムの部分改修では、現状調査と要件定義だけで全体スケジュールの10〜20%以上を占めることも珍しくありません。
対象が小さいからといって調査を省略すると、着手後に「この機能は想定外の別処理と連携していた」という事態が発覚し、かえって手戻りが発生します。改修規模が小さいプロジェクトほど事前調査の比率は相対的に大きくなるため、見積もり段階から織り込んでおく必要があります。
デグレードテストと全体の10〜30%のバッファ
特定機能のみを対象にした改修であっても、修正したプログラムが既存の機能に悪影響を及ぼしていないかを確認する「デグレードテスト（リグレッションテスト）」は必須の工程です。対象範囲が小さいからとテストを簡略化すると、改修箇所以外の機能に予期しない不具合が発生し、稼働後にかえって大きなトラブルへ発展するリスクがあります。
開発工程だけでなく、テストや本番移行のスケジュールにも十分な余裕を持たせることが重要です。全体スケジュールの10〜30%程度をバッファとして確保しておくことが推奨されています。
このバッファは、余分な余裕ではなく、レガシー改修では構造的にほぼ発生する遅延要因を吸収するための必須の要素です。見積もりの段階から発注者と開発パートナーの双方で共通認識にしておくことが、納期の信頼性を高める工夫になります。
依頼先選定と着手判断が期間に与える影響
低予算・短納期の改修案件だからこそ、どのパートナー企業に依頼するかで、実現できるスケジュールは大きく変わります。そのため、小規模案件でも確実に対応してくれる依頼先を見極めることが、期間短縮の鍵を握ります。
小規模改修を確実にこなせるパートナーの見極め方
大規模な刷新プロジェクトを主戦場とするベンダーの中には、数百万円規模の小規模改修案件を積極的に受けたがらないところや、体制が整っておらず対応が後回しになりやすいところがあります。
依頼先を選ぶ際は、対象言語や基盤（COBOLや汎用機等）の解析実績に加えて、低予算・短納期の小規模改修案件をどれだけの件数こなしてきたかを確認することが重要です。さらに、継続的な保守・改修のパートナーとして長期的に付き合える体制があるかも確認します。
実績が乏しい、あるいは小規模案件への対応に消極的なパートナーに依頼すると、見積もり段階からレスポンスが遅く、着手そのものが先延ばしになりがちです。
着手を先送りするほど改修範囲が膨らみ全面刷新に近づく構造
「今すぐ困っているわけではないから」と小さな改修要望を放置し続けると、未対応の課題が積み重なります。いざまとめて対応しようとすると、もはや部分改修では収まらない規模の作業になってしまうことがあります。
着手が遅れるほど、システムの構造を理解している担当者の異動や退職も重なり、事前調査の期間はさらに長くなります。法改正のように期限が外部から強制される案件では、この傾向が特に顕著です。
改修規模を小さく、期間を短く保つためには、課題が小さいうちに早めに着手し、優先度の高い部分から継続的に手を入れていく姿勢が、結果的に最も低予算・短納期を実現する近道になります。
まとめ
ここまで、部分的・小規模修正という位置づけから、開発期間・スケジュールの目安、法改正対応やバグ修正などの典型的な改修案件別のスケジュール感までを解説してきました。さらに、納期が読みにくくなる要因と遅延を防ぐ進め方、依頼先選定と着手判断が期間に与える影響についても解説しました。
レガシーシステム改修は、小規模改修なら費用500万〜2,000万円・期間数週間〜数ヶ月、中規模改修なら費用2,000万〜8,000万円・期間数ヶ月〜1年が目安です。全面刷新と比べると、いずれも一桁小さい規模感で計画できます。
一方で、対象範囲が小さくても、事前調査・要件定義には全体の10〜20%以上の時間がかかります。デグレードテストのために10〜30%のバッファが必要になる点は、部分改修だからといって軽視できません。
着手を先送りするほど改修範囲は膨らんでいくため、小規模改修を確実にこなせるパートナーに早めに相談し、課題が小さいうちに手を打つことをお勧めします。
▼全体ガイドの記事
・レガシーシステム改修の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。