レガシーマイグレーションの費用は何で決まりますか？

行数だけでは決まりません。実際に金額を左右するのは、有効ステップ数（デッドコードを除いた実質的な規模）、画面・帳票の数、外部連携とデータベースの複雑さ、そして仕様書と現行システムの乖離度です。特に最後の乖離度が、見積もりの振れ幅の大半を生みます。

なぜ会社によって見積額が大きく違うのですか？

前提条件が違うためです。仕様復元をどこまで行うか、テストの範囲を誰が持つか、移行期間中の並行稼働を含むか。同じ「システム刷新」でも作業範囲が異なれば金額は数倍変わります。比較する際は金額ではなく前提条件を先に揃える必要があります。

見積もりを取る前に何を準備すべきですか？

現行コードの規模と構造を把握しておくことです。総行数、デッドコードの割合、画面数、外部連携の一覧、モジュール間の依存関係。これらが揃っていない状態で取った見積もりは、各社が異なる前提で出した数字になり、比較の意味を持ちません。

レガシーマイグレーションの費用 — 見積もりの読み方

「レガシーシステムの刷新にいくらかかるのか」——モダナイゼーションの検討は、たいていこの問いから始まります。そして多くの場合、数社から見積もりを取った時点で、担当者は困惑することになります。金額が数倍違うのです。

同じシステム、同じ依頼書を出したはずなのに、なぜこうなるのか。本記事では、費用相場そのものよりも重要な、見積もりの構造と読み方を解説します。

「1行あたりいくら」が成立しない理由

レガシーマイグレーションの見積もりを、総ステップ数（行数）に単価を掛けて算出する方法があります。分かりやすい一方で、これだけで判断すると高い確率で外れます。理由は3つあります。

行数の大半が生きていないことがある。 長く使われたシステムには、到達しないコード、コメントアウトされた旧ロジック、コピーして少しだけ変えた重複モジュールが堆積しています。総行数が同じでも、有効ステップ数が半分なら作業量は大きく変わります。
1行の重さが均一ではない。 定型的なCRUD画面のコードと、20年分の例外処理が積み重なった料金計算ロジックでは、同じ100行でも難易度が違います。
作業の中身が会社ごとに違う。 これが最大の要因です。

見積額を左右する4つの要因

金額の差は、値引き幅ではなく前提条件の差から生まれます。特に効くのは次の4つです。

要因	見積もりへの影響	確認すべきこと
有効ステップ数	大	デッドコードを除いた実質規模を把握しているか
画面・帳票の数	大	類似画面をまとめて数えていないか
外部連携・DB	中〜大	連携先の数、データベース移行を含むか
仕様書との乖離	最大	仕様復元の工数を誰が持つか

とくに4つ目です。仕様書が現行システムと合っていない場合、「動いているコードから仕様を読み解く」工程が必要になります。この工程は見積書の行として立ちにくく、しかし実際のプロジェクトでは最も時間を食う部分です。見積もりが大きく外れるプロジェクトの多くは、ここを誰も見積もっていません。

手法によって費用の「形」が変わる

刷新手法ごとに、費用の総額だけでなく、どこにコストが集中するかが変わります。

リホスト。 初期費用は最も小さく、短期で終わります。ただし業務ロジックは古いまま残るため、保守コストは下がりません。費用を先送りしている、という理解が正確です。
再構築（リライト）。 費用の中心は開発ではなく要件定義と仕様復元です。ここが読めないため、当初見積もりからの超過が起きやすい手法でもあります。一方で、業務プロセスごと作り替える価値がある場合には、その超過に見合うリターンがあります。
自動変換。 費用の中心は、変換そのものよりも事前の解析と、変換後の検証に寄ります。業務ロジックを現行コードから引き継ぐため仕様復元の工程が小さく、見積もりの前提が崩れにくいのが特徴です。ただし、OCXや外部コンポーネントへの依存が多い場合、その部分は個別対応になります。

手法ごとの向き不向きは再構築か、自動変換かで詳しく比較しています。

見積書のどこを見るか

提示された見積書を受け取ったら、金額の前に次の5点を確認してください。いずれも「書かれていないこと」を探す作業です。

仕様復元の工数は含まれているか。 含まれていなければ、その分は後から追加見積もりとして発生します。
テストの範囲は誰が持つか。 「単体テストまで」と「業務観点の受入テスト支援まで」では、自社側に残る負担がまったく違います。
移行期間中の並行稼働は含まれるか。 止められない基幹システムでは、新旧を並行させる期間の費用が必ず発生します。
データ移行は別か。 別計上であることが多い項目です。
変換後のコードは誰のものか。 自社で保守できる標準的なコードなのか、ベンダー固有の形式なのか。これは初期費用ではなく、その後10年の費用に効きます。

金額だけを並べた比較表は、前提が揃っていなければ意味を持ちません。安い見積もりは、多くの場合「含んでいない」だけです。

見積もりを取る前にやるべきこと

もっとも効果的なコスト対策は、値引き交渉ではなく、見積もりの前提を自社側で固めることです。

現行コードの総行数、デッドコードの割合、画面数、外部連携の一覧、モジュール間の依存関係。これらが分かっていれば、各社に同じ前提で見積もりを依頼でき、初めて比較が成立します。同時に、規模が正確に分かることで、過大な見積もりも過小な見積もりも見抜けるようになります。

実務ではこの把握をコード分析で行います。全量解析によって依存関係マップと規模の実数を出し、そのうえで移行方式と費用を判断する順序です。数百万行規模のVB6システムで、解析から移行計画の策定までを2ヵ月で完了した事例を含め、実績は導入事例で紹介しています。

まとめ

レガシーマイグレーションに、一律の「相場」はありません。同じ行数でも、仕様書の状態と作業範囲の定義によって費用は数倍変わります。だからこそ、判断の軸は金額の大小ではなく、その金額が何を含んでいるかに置くべきです。

自社システムの実際の規模と構造を把握するところから始めたい場合は、無料コード診断をご利用ください。現行コードを解析し、規模の実数と移行方式の選択肢をご提示します。

技術別の移行についてはVB6 からの移行ガイド、PowerBuilder からの移行ガイドも参考になります。