レガシーシステムリプレイスの開発期間は、現状分析から並行稼働までの工程の積み重ねで決まります。なかでも、データ移行と並行稼働が期間を最も左右する変数です。
技術手法全般の相場観や経営判断、契約起点、顧客体験起点の詳しい内容は、姉妹記事に譲ります。現実的な納期に着地させるには、どの製品に乗り換え、どう移行するかを製品選定の段階で詰めることが核心になります。
- 起点：製品・ベンダー乗り換えとビルド・バイ判断
- 工程：開発期間・スケジュールの全体像
- 変数：データ移行・並行稼働と遅延対策
本テーマの全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステムリプレイスの定義（製品・ベンダー乗り換え起点という位置づけ）
レガシーシステムリプレイスとは、COBOLや汎用機上で長年運用されてきた自社スクラッチシステムを、同じコードベースを維持したまま手直しするのではなく、別製品・別パッケージ・SaaSへ完全に乗り換える取り組みです。
経済産業省の調査によると、メインフレームやスクラッチ開発を利用してきた企業のうち25%が「標準システム・パッケージ」への移行を選んでいます。メインフレーム利用企業では、52%がすでに脱メインフレームを決めています。
こうした数字が示すとおり、レガシーシステムの刷新では、今のコードを直して延命する道と、別の製品・ベンダーに乗り換える道の二択を迫られる場面が増えています。そのため、開発期間の見積もりも、この分岐点でどちらを選ぶかによって工程そのものが大きく変わります。
自社スクラッチのリファクタリングでは、既存コードの解析と書き換えが主な工程になります。一方で、製品・ベンダー乗り換えでは、候補製品の選定やRFP作成、PoC検証が中心になります。さらに、データ移行と並行稼働も加わり、これらがまったく別の工程として期間の大半を占めます。
「モダナイゼーション」「刷新」「更改」「リニューアル」「リアーキテクチャ」との違いと、製品乗り換え起点で語る理由
「レガシーシステムのモダナイゼーション」は、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの手法をどう使い分けるかを扱う総論です。本記事の「リプレイス」は、その中の1手法である「別製品・別パッケージへの完全乗り換え」だけを単独で掘り下げます。
これらの言葉は、重心の置きどころが異なります。製品乗り換え起点のリプレイスとの違いは、次の5つで整理できます。
- 「刷新」：経営層の投資判断と稟議承認
- 「更改」：ベンダー保守契約の満了やEOS/EOLという契約上の期限
- 「リニューアル」：ユーザーの見た目や使い勝手という顧客体験
- 「リアーキテクチャ」：モノリスからマイクロサービスへの分解という技術構造
- リプレイス：「自社で作り続けるか、他社の製品を買うか」というビルド・バイ判断、乗り換え先製品の選定基準、データ移行の確実性
リプレイスの開発期間は、稟議のリードタイムやアーキテクチャ設計の精度よりも、製品選定の精度とデータ移行の難易度で決まる点が最大の違いです。
ビルド・バイ判断の定義（自社スクラッチ維持か、SaaS/パッケージへの乗り換えか）
ビルド・バイ判断は、対象業務が自社の競争力の源泉であり続けるか、業界標準的な業務プロセスに過ぎないかを見極める意思決定です。前者であれば自社スクラッチ（ビルド）を維持・再構築し、後者であればSaaS・パッケージ（バイ）へ乗り換えます。
たとえば、製造業特有の原価管理ロジックのように、他社にはない独自の手順が競争力に直結している領域はビルドが向いています。一方で、勤怠管理・経費精算・会計・人事といった業界共通のバックオフィス業務は、標準機能に業務を合わせる「Fit to Standard」の考え方で、パッケージ・SaaSへ乗り換えるほうが合理的です。
開発期間を正しく見積もるには、まずこのビルド・バイ判断を早期に確定させ、どちらの工程表で計画を立てるかを明確にしておく必要があります。判断が曖昧なまま製品選定を進めると、要件定義の途中で「やはり自社開発すべきだった」という手戻りが起きがちです。その手戻りが、スケジュール全体を崩す原因になります。
リプレイスの開発期間・スケジュールの全体像（工程別の期間目安）
ビルド・バイ判断でパッケージ・SaaSへの乗り換えを選んだ場合、開発期間は一連の工程で構成されます。現状分析、製品選定、PoC、開発、データ移行、並行稼働の順に進み、工程ごとの期間を積み上げて全体のスケジュールを組みます。
技術手法そのものの期間相場は、姉妹記事「レガシーシステムのモダナイゼーション」に譲ります。本記事では、製品乗り換えに特有の工程を中心に解説します。
現状分析・製品選定・RFP作成〜要件定義の期間（Fit to Standardの重要性）
最初のステップは、現行システムの中身を洗い出すことです。ソースの解析とデータの品質・移行難易度の診断を行い、移行ロードマップを策定します。ロードマップは、7Rフレームワークを使って組み立てます。7Rには、リホスト、リプラットフォーム、リファクタリングのほかに、次の4つがあります。
- リタイア
- リテイン
- リパーチェス
- リビルド
特に、既存システムの仕様がブラックボックス化している場合は、この洗い出しだけで数十万〜数百万円規模のコストと相応の期間がかかります。続く製品選定、RFP作成から要件定義までには、約1〜2ヶ月以上を見込むのが一般的です。
このとき鍵になるのが「Fit to Standard」、つまり自社の業務を製品の標準機能に合わせるという発想の転換です。標準機能に業務を合わせられると、カスタマイズを最小限に抑えられ、開発期間とコストの両方を圧縮できます。一方で、旧業務フローを製品側に無理に合わせ込もうとすると、要件定義の段階からカスタマイズ要望が膨らみ、後工程の開発期間を押し上げる最大の要因になります。
PoC検証〜開発・カスタマイズの期間目安
要件定義と並行、あるいはその直後に行うPoC（概念実証）は、影響範囲や不確実性の高い領域を対象に、2〜4週間程度の短いスプリントを回して小さく検証するのが一般的です。PoCで実現可能性を確認できたら、開発・カスタマイズ工程に入ります。
パッケージ・SaaSの基本機能だけで構成できる場合は、2〜3ヶ月程度で導入と開発を終えるケースもあります。一方で、フルスクラッチで作り込む場合は、この工程だけでさらに長期化します。
実際の事例では、従業員50名の製造業が受注・在庫・売上管理システムを対象に、要件を本当に必要な機能まで絞り込み、段階的に導入しました。その結果、開発期間6ヶ月、総費用1,200万円でプロジェクトを完遂しています。また、この工程の期間は、カスタマイズの範囲をどこまで許容するかという初期の意思決定で大きく左右されます。
データ移行・並行稼働（パラレルラン）が期間を左右する最大の変数
製品・ベンダー乗り換えのリプレイスでは、他の刷新手法以上に開発期間を読みにくくするのが、データ移行と並行稼働です。その理由は、旧システムのコードをどれだけ丁寧に解析しても、この2工程は「実際にデータを流してみないと分からない」性質を持つからです。
データクレンジング・データ移行の期間が読みにくい理由
レガシーシステムからの製品乗り換えで最大の難所となるのが、データ移行です。長年蓄積されたデータには表記ゆれ・欠損・重複が付き物で、これをきれいにする「データクレンジング」に想定以上の期間がかかります。
実際に、従業員200名規模の商社の事例では、20年分の顧客データが3つの異なるシステムに分散していたため、データ統合とクレンジングだけで4ヶ月を要したと報告されています。新しい製品のデータ構造は旧システムと仕様が異なり、単純なコピーでは移行できないため、項目ごとの変換ロジックを設計・検証する工程が不可欠です。
開発期間の見積もりでは、データ移行をコード変換や画面開発と同列に扱わず、独立した重量級の工程として、十分な期間をあらかじめ確保しておく必要があります。
並行稼働（パラレルラン）・移行テストで安全に切り替える進め方
データ移行が完了しても、いきなり旧システムを停止して新製品に切り替える「一斉カットオーバー」は、リスクが高すぎます。このため、安全に本番稼働を迎えるには、稼働初期に旧システムと新システムを同時に動かす「並行稼働（パラレルラン）」の期間を、数週間〜数ヶ月設けるのが一般的です。
日次や月次の締め処理ごとに両者の結果を照合し、差異がないかを検証することで、稼働直後の致命的な業務停止を防ぎます。ただし、並行稼働期間は旧システムの運用コストと新システムの導入コストが二重にかかる期間でもあるため、闇雲に長く取ればよいわけではありません。業務のピーク時（月末締め処理など）を最低1サイクルは含め、必要十分な期間を設計することが重要です。
納期が読みにくくなる根本原因と遅延を防ぐ進め方
製品・ベンダー乗り換え型のリプレイスで納期が計画どおりに進まなくなる要因は、技術的負債の発覚とは性質が異なり、多くの場合「製品の標準機能からの逸脱」という形で表面化します。このため、この構造を理解したうえで進め方を工夫することが、納期を守る最善の対策になります。
カスタマイズの罠（Fit to Standardが崩れて期間が膨らむ仕組み）
プロジェクト開始時は「標準機能に業務を合わせる」方針で合意していても、要件定義や開発が進むにつれ、現場から「今までのやり方をそのまま再現してほしい」という個別要望が積み重なるケースが後を絶ちません。こうした状態が進むと、製品全体に対するカスタマイズ率が知らぬ間に膨れ上がり、標準機能を前提にした開発期間や体制では対応しきれなくなります。
カスタマイズ率が50%を超えると、総費用が当初予算の2〜3倍に膨らむケースも珍しくないとされています。期間についても、同様の膨張圧力が働きます。
この罠を避けるには、要件定義の初期段階で「どうしても譲れない独自要件」と「慣れの問題で変更可能な要件」を切り分けることが有効です。そのうえで、後者は製品の標準機能に合わせるという方針を、プロジェクト関係者全員で事前に合意しておきます。
リスクバッファ（全体の10〜30%）の事前確保
技術的な不確実性やデータ移行の難易度を考えると、プロジェクト全体期間の10〜30%程度を、リスクバッファとしてあらかじめ確保しておくことが推奨されています。
レガシーシステムのリプレイスでは、想定外のデータ不整合や旧システムの暗黙仕様の発覚、製品側の仕様制約への対応といった遅延要因が、構造的にほぼ確実に起きます。そのため、バッファは余分な余裕ではなく、これらを吸収するための必須の設計要素として扱うべきです。
契約前の提案段階で、このバッファを見積もりに明示的に含めてもらうことが大切です。さらに、発注者と開発パートナーの双方が「バッファはいつ、何のために使われるのか」を共通認識として持っておくことが、納期の信頼性を高める実務的な工夫になります。
製品・依頼先選定と着手判断が期間に与える影響
同じ規模のレガシーシステムでも、どの製品に乗り換え、どの依頼先に導入を任せるかによって、開発期間は大きく変わります。特に製品乗り換え型のリプレイスでは、製品選定と依頼先選定の両方の精度が期間短縮の鍵を握ります。
製品選定基準（Fit to Standard支援力とデータ移行実績）
製品や依頼先を選ぶ際は、類似業種・類似規模での導入実績、Fit to Standardを実現するための業務改善の提案力、そして何より対象業界のデータ移行実績を、具体的な数値とともに確認します。機能一覧のカタログスペックに頼るより、こうした確認のほうが期間見積もりの妥当性を検証する近道です。
中でもデータ移行では、経験豊富なパートナーほど「どの項目で表記ゆれが起きやすいか」「どの工程で工数が膨らみやすいか」を事前に見抜けるため、期間見積もりの精度そのものが変わります。
パートナーの実績が乏しいと、製品選定の段階からミスマッチが生じ、要件定義とデータ移行の両方でつまずくリスクが高まります。
着手を先送りするほど選択肢と期間の余裕が失われる構造
「まだ動いているから」という理由で製品乗り換えの検討を先送りにする判断は、開発期間の観点からも合理的ではありません。国税庁が定めるソフトウェアの法定耐用年数は「5年」で、これを一つの目安として5年ごとにリプレイスの要否を検討することが、保守運用を安定させる一般的な基準とされています。この節目を過ぎて放置するほど、データはさらに複雑化・肥大化し、いざ着手したときのデータ移行期間はむしろ長くなります。
日本企業の87.8%が何らかのレガシーシステムを抱えているという調査結果もあります。また、経済産業省は、放置した場合の経済損失が2025年以降、年間最大12兆円に達すると警告しています。そのため、余裕のあるうちに現状分析と製品選定の情報収集だけでも早めに始め、ビルド・バイ判断の材料を揃えておくことが、現実的な開発期間を確保する最も有効な備えになります。
まとめ
本記事では、レガシーシステムリプレイスの開発期間・スケジュール・納期を、製品・ベンダー乗り換えを起点に整理しました。工程別の期間の全体像から、データ移行・並行稼働が期間を左右する最大の変数であること、納期が読みにくくなる根本原因と遅延を防ぐ進め方、製品・依頼先選定と着手判断が期間に与える影響まで、順に解説しました。
レガシーシステムリプレイスの開発期間は、コード変換の工数よりも、ビルド・バイ判断の精度で決まります。さらに、Fit to Standardをどこまで貫けるか、データ移行・並行稼働という重量級の工程をどれだけ現実的に見積もれるかも、期間を左右します。
工程別の目安は、製品選定と要件定義が約1〜2ヶ月、PoC検証が2〜4週間です。開発・カスタマイズとデータ移行・クレンジングはそれぞれ数ヶ月、並行稼働は数週間〜数ヶ月が目安になります。そのうえで、全体の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を創業。