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

レガシーシステムリプレイスとは、COBOLや汎用機上で長年運用されてきた自社スクラッチシステムを、同じコードベースを維持したまま手直しするのではなく、別製品・別パッケージ・SaaSへ完全に乗り換える取り組みです。同じくレガシーシステムを扱う既存記事群のうち、「レガシーシステムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術手法の使い分けを並列に扱い、「レガシーシステム刷新」が経営層の投資判断・稟議承認プロセスに、「レガシーシステム更改」がベンダー保守契約満了やEOS/EOLという外部から強制される期限に、「レガシーシステムリニューアル」がユーザーの見た目・使い勝手という顧客体験に、「レガシーシステムリアーキテクチャ」がモノリスからマイクロサービスへの分解というアーキテクチャ構造の技術深掘りにそれぞれ重心を置くのに対し、本記事が扱う「レガシーシステムリプレイス」は、自社スクラッチ開発を維持するか他社のSaaS・パッケージ製品へ乗り換えるかという「ビルド・バイ判断」そのものと、乗り換えに伴う製品選定・データ移行・並行稼働リスクに焦点を当てます。

本記事では、レガシーシステムリプレイスが製品・ベンダー乗り換え起点であるという位置づけの整理から、工程別の開発期間・スケジュールの全体像、データ移行・並行稼働が期間を左右する最大の変数であること、納期が読みにくくなる根本原因と遅延を防ぐ進め方、そして製品・依頼先選定と着手判断が期間に与える影響までを体系的に解説します。技術手法全般の相場観や経営判断・契約起点・顧客体験起点の詳しい内容はそれぞれ姉妹記事に譲り、本記事では「どの製品に乗り換え、どう移行すれば、現実的な納期に着地できるのか」という、経営層・情シス部門が製品選定の場面で最も知りたい論点に絞って解説します。

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

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

レガシーシステムリプレイスとは何か（製品・ベンダー乗り換え起点という位置づけ）

経済産業省の調査によれば、これまでメインフレームやスクラッチ開発を利用していた企業のうち25%が「標準システム・パッケージ」への移行を選択しており、メインフレーム利用企業の52%がすでに脱メインフレームを決定しています。この数字が示す通り、レガシーシステムの刷新は「今のコードを直しながら延命する」道と、「別の製品・ベンダーに乗り換える」道の二択に直面する場面が増えています。開発期間の見積もりも、この分岐点をどちらに倒すかによって工程そのものが大きく変わります。自社スクラッチのリファクタリングであれば既存コードの解析・書き換えが主工程になりますが、製品・ベンダー乗り換えであれば、候補製品の選定・RFP作成・PoC検証・データ移行・並行稼働という、まったく別の工程が期間の大半を占めることになります。

「レガシーシステムのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5手法をどう使い分けるかという総論であるのに対し、本記事が扱う「リプレイス」は、その中の1手法である「別製品・別パッケージへの完全乗り換え」だけを単独で深掘りします。同様に「刷新」が経営層の投資判断・稟議承認プロセスに、「更改」がベンダー保守契約満了やEOS/EOLという契約上の期限に、「リニューアル」がユーザーの見た目・使い勝手という顧客体験に、「リアーキテクチャ」がモノリスからマイクロサービスへの分解という技術構造にそれぞれ重心を置くのに対し、リプレイスは「自社で作り続けるか、他社の製品を買うか」というビルド・バイ判断そのものと、乗り換え先製品の選定基準・データ移行の確実性を主題にします。開発期間の見積もりも、稟議のリードタイムやアーキテクチャ設計の精度ではなく、製品選定の精度とデータ移行の難易度によって決まる点が最大の違いです。

ビルド・バイ判断とは、対象業務が自社の競争力の源泉であり続けるか、それとも業界標準的な業務プロセスに過ぎないかを見極め、前者であれば自社スクラッチ（ビルド）を維持・再構築し、後者であればSaaS・パッケージ製品（バイ）へ乗り換えるという意思決定です。製造業特有の原価管理ロジックのように、他社にはない独自の手順が競争力に直結している領域はビルドが適していますが、勤怠管理・経費精算・会計・人事といった業界共通のバックオフィス業務は、標準機能に自社の業務を合わせる「Fit to Standard」の考え方でパッケージ・SaaSに乗り換えたほうが、開発期間・費用の両面で合理的です。開発期間を正しく見積もるには、まずこのビルド・バイ判断を早期に確定させ、どちらの工程表で計画を立てるべきかを明確にしておく必要があります。判断が曖昧なまま製品選定を進めると、要件定義の途中で「やはり自社開発すべきだった」という手戻りが発生し、スケジュール全体が崩れる原因になります。

リプレイスの開発期間・スケジュールの全体像（工程別の期間目安）

ビルド・バイ判断でパッケージ・SaaSへの乗り換えを選んだ場合、開発期間は現状分析・製品選定・PoC・開発・データ移行・並行稼働という一連の工程で構成されます。技術手法そのものの詳しい期間相場は姉妹記事「レガシーシステムのモダナイゼーション」に譲り、本記事では製品乗り換え特有の工程に重心を置いて解説します。

最初のステップは現行システムの棚卸しです。ソースの解析、データの品質・移行難易度の診断、そして7Rフレームワーク（リタイア・リテイン・リホスト・リプラットフォーム・リパーチェス・リファクタリング・リビルド）を用いた移行ロードマップの策定を行いますが、既存システムの仕様がブラックボックス化している場合、この棚卸しだけで数十万〜数百万円規模のコストと相応の期間を要します。続く製品選定・RFP作成〜要件定義には約1〜2ヶ月以上を見込むのが一般的です。ここで重要なのが「Fit to Standard」、すなわち自社の業務を製品の標準機能に合わせるという発想への転換です。標準機能に業務を合わせられればカスタマイズを最小限に抑えられ、開発期間・コストの両方を圧縮できますが、逆に自社の旧業務フローを製品側に無理やり合わせ込もうとすると、要件定義の段階からカスタマイズ要望が膨張し、後工程の開発期間を押し上げる最大の要因になります。

要件定義と並行、あるいはその直後に行うPoC（概念実証）は、影響範囲や不確実性の高い領域について2〜4週間程度の短いスプリントを回して小さく検証するのが一般的です。PoCで実現可能性を確認できたら開発・カスタマイズ工程に入りますが、パッケージ・SaaSの基本機能のみで構成できる場合は2〜3ヶ月程度で導入・開発工程を完了できるケースがある一方、フルスクラッチで作り込む場合はこの工程だけでさらに長期化します。実際の事例として、従業員50名の製造業が受注・在庫・売上管理システムを対象に、要件を本当に必要な機能へ絞り込み、段階的に導入した結果、開発期間6ヶ月・総費用1,200万円でプロジェクトを完遂したケースがあります。カスタマイズの範囲をどこまで許容するかという初期の意思決定が、この工程の期間を大きく左右します。

データ移行・並行稼働（パラレルラン）が期間を左右する最大の変数

製品・ベンダー乗り換えという形のリプレイスにおいて、他の刷新手法以上に開発期間を読みにくくするのが、データ移行と並行稼働という2つの工程です。旧システムのコードをどれだけ丁寧に解析しても、この2工程だけは「実際にデータを流してみないと分からない」性質を持っているためです。

レガシーシステムからの製品乗り換えにおいて最大の難所となるのがデータ移行です。長年蓄積されたデータには表記ゆれ・欠損・重複が付き物で、これをきれいにする「データクレンジング」に想定以上の期間がかかります。実際に、従業員200名規模の商社の事例では、20年分の顧客データが3つの異なるシステムに分散していたため、データ統合とクレンジングだけで4ヶ月を要したと報告されています。新しい製品のデータ構造は旧システムとは仕様が異なるため、単純なコピーでは移行できず、項目ごとの変換ロジックを設計・検証する工程が不可欠です。開発期間の見積もりでは、コード変換や画面開発と同列に扱うのではなく、データ移行を独立した重量級の工程として、あらかじめ十分な期間を確保しておく必要があります。

データ移行が完了しても、いきなり旧システムを停止して新製品に切り替える「一斉カットオーバー」はリスクが高すぎます。安全に本番稼働を迎えるためには、稼働初期に旧システムと新システムを同時に動かす「並行稼働（パラレルラン）」の期間を数週間から数ヶ月設けるのが一般的です。日次や月次の締め処理ごとに両者の結果を照合し、差異がないかを検証することで、稼働直後の致命的な業務停止を防ぎます。この並行稼働期間は、旧システムの運用コストと新システムの導入コストが二重にかかる期間でもあるため、闇雲に長く取ればよいというものではなく、業務のピーク時（月末締め処理等）を最低1サイクルは含める形で、必要十分な期間を設計することが重要です。

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

製品・ベンダー乗り換え型のリプレイスで納期が計画通りに進まなくなる要因は、技術的負債の発覚とは性質が異なり、多くの場合「製品の標準機能からの逸脱」という形で表面化します。この構造を理解した上で進め方を工夫することが、納期を守る最善の対策になります。

プロジェクトが始まった当初は「標準機能に業務を合わせる」という方針で合意していても、要件定義や開発が進むにつれて、現場から「今までのやり方をそのまま再現してほしい」という個別要望が積み重なっていくケースが後を絶ちません。この状態が進行すると、製品全体に対するカスタマイズ率が知らぬ間に膨れ上がり、標準機能を使う前提だった開発期間・体制では対応しきれなくなります。カスタマイズ率が50%を超えると、総費用が当初予算の2〜3倍に膨らむケースも珍しくないとされており、これは期間についても同様の膨張圧力として働きます。この罠を避けるには、要件定義の初期段階で「どうしても譲れない独自要件」と「慣れの問題で変更可能な要件」を切り分け、後者は製品の標準機能に合わせるという方針を、プロジェクト関係者全員であらかじめ合意しておくことが有効です。

移行における技術的な不確実性やデータ移行の難易度を考慮すると、プロジェクト全体期間の10〜30%程度をリスクバッファとしてあらかじめ確保しておくことが推奨されています。このバッファは「余分に確保しておく余裕」ではなく、レガシーシステムのリプレイスにおいては構造的にほぼ確実に発生する遅延要因（想定外のデータ不整合、旧システムの暗黙仕様の発覚、製品側の仕様制約への対応）を吸収するための必須の設計要素として扱うべきです。契約前の提案段階でこのバッファを見積もりに明示的に含めてもらい、発注者・開発パートラン双方が「バッファはいつ、何のために使われるのか」を共通認識として持っておくことが、納期の信頼性を高める実務的な工夫になります。

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

同じ規模のレガシーシステムでも、どの製品に乗り換え、どのパートナー企業に導入を依頼するかによって、開発期間は大きく変わります。製品乗り換え型のリプレイスだからこそ、製品選定と依頼先選定の両方の精度が期間短縮の鍵を握ります。

製品・依頼先を選ぶ際は、機能一覧のカタログスペックだけで判断するのではなく、類似業種・類似規模での導入実績、Fit to Standardを実現するための業務改善提案力、そして何より対象業界のデータ移行実績を具体的な数値とともに確認することが、期間見積もりの妥当性を検証する近道です。特にデータ移行は、経験豊富なパートナーであれば「どの項目で表記ゆれが起きやすいか」「どの工程で工数が膨らみやすいか」を事前に見抜けるため、期間の見積もり精度そのものが変わってきます。実績が乏しいパートナーに依頼すると、製品選定の段階からミスマッチが生じ、要件定義・データ移行の両方でつまずくリスクが高まります。

「まだ動いているから」という理由で製品乗り換えの検討を先送りにする判断は、開発期間の観点からも合理的ではありません。国税庁が定めるソフトウェアの法定耐用年数「5年」を一つの目安として、5年ごとにリプレイスの要否を検討することが保守運用を安定させる一般的な基準とされていますが、この節目を過ぎて放置するほど、データはさらに複雑化・肥大化し、いざ着手した際のデータ移行期間はむしろ長期化します。日本企業の87.8%が何らかのレガシーシステムを抱えているという調査結果もあり、放置した場合の経済損失は2025年以降年間最大12兆円に達すると経済産業省は警告しています。余裕のあるうちに現状分析と製品選定の情報収集だけでも早期に着手し、自社にとってのビルド・バイ判断の材料を揃えておくことが、現実的な開発期間を確保するための最も有効な備えになります。

まとめ

本記事では、レガシーシステムリプレイスの開発期間・スケジュール・納期について、製品・ベンダー乗り換え起点という位置づけの整理から、工程別の開発期間・スケジュールの全体像、データ移行・並行稼働が期間を左右する最大の変数であること、納期が読みにくくなる根本原因と遅延を防ぐ進め方、製品・依頼先選定と着手判断が期間に与える影響までを体系的に解説しました。レガシーシステムリプレイスの開発期間は、コード変換の工数ではなく、ビルド・バイ判断の精度、Fit to Standardをどこまで貫けるか、そしてデータ移行・並行稼働という重量級工程をどれだけ現実的に見積もれるかによって決まります。製品選定・要件定義に約1〜2ヶ月、PoC検証に2〜4週間、開発・カスタマイズに数ヶ月、データ移行・クレンジングに数ヶ月、並行稼働に数週間〜数ヶ月という工程別の目安を踏まえつつ、全体の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を創業。