リプレイス案件の見積は「新規開発より安い」とは限らない
「今使っている業務システムが古くなってきたので、そろそろリプレイスしたい」——情シスや事業責任者からのよくある相談です。しかし、いざ複数社に見積を依頼すると「同じ機能を作り直すだけなのに、なぜ新規開発より高いのか」と驚かれることが少なくありません。リプレイス案件には、新規開発には存在しない独特の見積構造があり、そこを理解しないまま RFP を出すと、後から「聞いていない工程」がどんどん積み上がっていきます。
この記事では、発注側の担当者向けに、リプレイス案件の見積で押さえるべき工程・データ移行・スコープ設計・事前準備の考え方を整理します。「既存システムがある」という前提がいかに見積を難しくするか——その仕組みを理解することが、精度の高い見積を引き出す第一歩です。
1. なぜリプレイスは「新規開発より高くつく」ことがあるのか
「作るものはほぼ同じなのだから、新規より安くなるはず」——これがリプレイス案件で最も多い誤解です。実際には、同じ機能を持つシステムを新規で作るのと、既存システムを刷新するのとでは、後者のほうが 1.3〜2 倍かかることも珍しくありません。
現行仕様の「解析」工程が発生する
新規開発なら要件をゼロから設計しますが、リプレイスでは「今のシステムが何をしているか」を先に読み解く必要があります。ソースコード解析・画面操作の書き起こし・担当者ヒアリング——この工程だけで数十人日かかることも普通です。
「隠れ仕様」を落とせない
長年使われているシステムには、ドキュメントに残っていない業務ルールが埋まっています。「月末だけ帳票フォーマットが変わる」「特定の得意先だけ端数処理が違う」——こうした挙動を新システムでも再現しないと現場が回りません。この抽出コストがリプレイス独特の重さです。
既存データの移行と並行運用が必要
空の DB から始められる新規と違い、リプレイスでは何年分もの実データを新スキーマに移す必要があります。さらに、稼働中のシステムを止めずに置き換えるための並行稼働・切替判断・ロールバック手順の準備が乗ります。この「業務を止めないためのコスト」は、新規開発の見積には登場しない項目です。
同じ機能規模でも見積の桁が変わる理由は、システム開発の見積相場で扱った「前提条件の差」がリプレイスでは特に大きく効くためです。
2. リプレイスの見積に必ず含めるべき 5 つの工程
リプレイス案件の見積書には、新規開発の見積には出てこない工程が並びます。次の 5 つが抜けていないかは、発注側でも必ず確認したいポイントです。
(1) 現行仕様の調査・解析
ソースコード解析、DB スキーマの読み取り、画面遷移の書き起こし、業務ヒアリングを行います。ドキュメントの有無で工数が大きく変わる工程です。
(2) 新システムの要件定義・設計
解析結果をもとに、新システムの要件と設計を作ります。「そのまま作り直す」のか「業務改善込みで作る」のかで、ボリュームは倍以上変わります。
(3) 開発・テスト
新規開発と最も近い工程ですが、「既存の挙動と一致させる」ためのリグレッションテストが厚めに乗ります。
(4) データ移行・変換
旧 DB から新 DB へのデータ移送、文字コード変換、コード体系の付け替え、テスト移行と本番移行のリハーサルを行います。
(5) 並行運用・切替・保守引き継ぎ
新旧の並行運用、切替日の作業、旧システムのデータ凍結、切替後の初期保守、旧システムのサンセット計画までを含みます。
保守フェーズまで含めた長期のコスト構造は保守・運用の見積側でも扱いますが、リプレイスでは「旧システム保守と新システム保守が並行する期間」があることを忘れないでください。
3. ドキュメントが無い既存システムの見積が難しい理由
リプレイス相談で最も頻出するのが「現行のドキュメントがほぼ無い」ケースです。開発会社側から見ると、これは見積精度を大きく下げる要因になります。
「読まないと分からない」ものは高めに積むしかない
要件が見えないものに対して、開発会社が取れる選択肢は大きく 2 つです。
- 事前に有償の現行調査フェーズ（アセスメント）を切り出す
- 一括見積の中に厚めのリスクバッファを積む
前者は精度が高い代わりに、発注側は「本開発の前に調査費用を払う」ことを受け入れる必要があります。後者は一見親切に見えますが、実態は「見えない分を発注側に転嫁している」だけで、後から追加請求が発生しやすい構造です。現行調査フェーズは対象システムの規模にもよりますが、1〜3 か月・数人月のスコープで組まれることが多く、ここで洗い出された前提を踏まえて本見積を出す 2 段階アプローチは、概算見積と本見積の違いで解説した考え方と同じです。
「作った人がもう社内にいない」問題
古い業務システムでは、当時の担当者が退職・異動しているケースが多く、口頭のヒアリング先が確保できません。この場合、開発会社は実挙動を 1 つずつ動かして確認するしかなく、その分の工数が確実に増えます。「現行を語れる人が誰もいない」という状態を、見積依頼時に正直に伝えるほうが結果的に安く済みます。
4. データ移行・変換の工数を見積もる考え方
データ移行はリプレイス案件で最も工数がぶれる工程で、「レコード数 × 単純な変換ロジック」で見積もれるほど単純ではありません。
工数に効く 4 つの要素
工数を左右する要素は次の 4 つです。
- データ量：数万件と数千万件では、変換処理の設計方針が変わります
- データの汚れ具合：null・重複・不正値・全角半角の混在は、クレンジング工数として跳ね返ります
- スキーマ差分：旧スキーマと新スキーマの構造が離れているほど、変換ロジックが複雑になります
- リハーサル回数：本番切替の前に何回テスト移行を回すかで、期間と工数が大きく変わります
現場感覚として、中規模の業務システムでは移行工程だけで全体の 10〜25% を占めることがあります。「移行はおまけ」扱いで見積依頼を出すと、この工程が抜け落ちたまま契約してしまい、後から追加見積が飛んできます。
発注側の意思決定が必要な項目
見積のバッファを薄くしたいなら、次の 3 点を発注側で決めておく必要があります。
- どこまで過去データを持っていくか（全件／直近 3 年／アクティブレコードのみ）
- 汚れたデータをクレンジングするか、そのまま持ち込むか
- 切替時のダウンタイムを何時間まで許容できるか
これらは技術判断ではなく業務判断で、開発会社側では決められません。RFP 段階で方針を示せると、見積のバッファが目に見えて薄くなります。
5. 3 つのスコープパターン｜同機能／改善込み／段階移行
リプレイス案件のスコープには大きく 3 つのパターンがあり、どれを選ぶかで見積の性質そのものが変わります。
パターン A：同機能リプレイス（機能等価）
現行機能をそのまま新しい技術スタックに載せ替えます。要件検討の工数は最小ですが、「隠れ仕様を全部拾う」責務が重くのしかかり、塩漬けの業務ルールごと引き継ぐため業務改善効果は限定的です。
パターン B：改善込みリプレイス
刷新のタイミングで業務プロセスの見直し・UI 改善・機能追加を同時に行います。ROI は大きい反面、要件定義工程が膨らみ、見積総額はパターン A の 1.3〜1.7 倍になることが多い構成です。非機能要件も同時に見直すことになるため、非機能要件が見積に与える影響も併せて確認してください。
パターン C：段階的移行（ストラングラーパターン）
大規模基幹系でよく採用される方式で、機能ブロックを 1 つずつ新システムに切り出し、旧システムと並走させながら置き換えていきます。一括切替のリスクを避けられる代わりに、新旧のデータ整合や連携の工数が上乗せされ、総額は膨らみやすい傾向があります。
パターン選択は「予算」ではなく「事業リスクの取り方」で決めるものです。ここが定まらないと、開発会社から出てくる見積の粒度もそろいません。
FIXIT「同じ機能を作り直すだけ」なのに、なぜ新規より高くなるの？
Dodai現行を読み解く工程と、データを止めずに移す工程が上乗せになるからです。
FIXITドキュメントが全く残っていない場合は、どうすればいいですか？
Dodai先にアセスメントを切り出します。本開発は 2 段階に分けるのが安全です。
FIXITDodai予算ではありません。事業リスクをどこまで取れるかで決めます。ここを外すと事故ります。
6. 見積依頼前に発注側が用意すべき現行資料
見積精度を上げる最短の方法は、発注側が現行の情報を棚卸してから依頼することです。次がミニマムのチェックリストです。
- 現行システムの概要（構築時期・利用者数・稼働環境）
- 使用言語・フレームワーク・DB・稼働インフラの一覧
- 画面一覧または画面遷移図（無ければ主要画面のキャプチャでも可）
- 機能一覧・外部システム連携の一覧
- データ量の概算（主要テーブルのレコード数）
- 現行保守ベンダーの有無と、ソースコードの入手可否
- 業務上「絶対に落とせない」タイミング（月末・決算・繁忙期）
- リプレイスで達成したいこと（延命／コスト削減／業務改善／脱属人化）
この一覧が揃っていれば、開発会社側は「何が分かっていて、何が分かっていないか」を明確化しやすくなります。見積依頼前の情報整理の全体像は発注前に整理すべきこと、業務システムの一般的な相場感は業務システムの見積相場を参考にしてください。
コツ
リプレイスの見積を精度良く引き出したいなら、まず「アセスメントで払う費用」と「本開発で払う費用」を分けて発注する覚悟を持つのが近道です。ドキュメントの無い現行を一括見積に押し込むと、リスクバッファか追加請求のどちらかで結局同じ額を払うことになります。
まとめ
リプレイス案件は「作り直すだけ」のイメージに反して、現行解析・データ移行・並行運用という新規開発にはない工程が積み上がるため、同じ機能規模でも新規より 1.3〜2 倍かかることがあります。見積書に 5 工程が揃っているか、ドキュメントが無いならアセスメントを切り出す選択肢が示されているか、データ移行の方針は発注側で握れているか、スコープ 3 パターンのどれを選ぶか——この物差しを持って複数社の見積を並べれば、桁違いの差の理由が読み取れるようになります。数字はあくまで目安なので、案件ごとに前提条件と揃えて使うのが安全です。
AI 駆動開発のクリエイティブスタジオである FIXIT では、リプレイスのご相談を受けた際、まず現行システムの棚卸と方針整理から一緒に行い、現行資料が揃っていない案件ではアセスメントフェーズと本開発フェーズを分けて見積を提示しています。「今のシステムを見てもらったうえで、現実的な進め方を相談したい」という方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。