レガシーシステムの移行を検討する際、多くの企業が最初に直面するのが「移行にはどのくらいの費用がかかるのか」という問題です。
特に、長年運用されてきた基幹システムでは、ソースコードの規模を示すLOC（Lines of Code：コード行数）をもとに、開発工数や移行費用を概算することがあります。
しかし、同じLOCでも、システム構造や業務ロジック、外部連携の複雑さによって必要な作業は大きく異なります。
例えば、10万行のシステムでも、構造が整理され、仕様書が整備されている場合と、複雑な依存関係や独自の業務処理が多数存在する場合では、調査・改修・テストに必要な工数は同じではありません。
つまり、Migration CostはLOCだけでは決まりません。
本記事では、レガシーマイグレーションの費用を左右する要因、見積もりの進め方、適切な予算判断の基準を実務視点で解説します。
1. レガシーマイグレーションの費用はLOCだけで決まるのか？
結論から言えば、LOCは移行費用を概算するための指標の一つですが、それだけで正確な費用を算出することは困難です。
1.1. LOCとは何か
LOCは、プログラムのソースコードの行数を示す指標です。
移行対象の規模を把握する際に利用できますが、コードの行数がそのまま開発難易度を表すわけではありません。
例えば、同じ1万行でも、単純なデータ表示処理と、複雑な業務ルールを含む計算処理では、解析やテストに必要な時間が異なります。
また、コメント行や自動生成コードをどのように扱うかによってもLOCの測定結果は変わります。
そのため、見積もり時にはLOCの定義と計測範囲を統一する必要があります。
1.2. LOCだけの見積もりが不十分な理由
LOCだけを基準にすると、次のような作業を十分に評価できない場合があります。
-
既存仕様の調査と業務ロジックの解析
-
外部システムとの連携変更
-
データベース構造の変更
-
旧環境と新環境の動作比較
-
サードパーティ製品の更新や代替
-
本番移行と切り戻しの準備
特に、仕様書が不足しているシステムでは、コードを変更する前の調査に多くの工数が必要になることがあります。
LOCは出発点として利用し、その他の要因を組み合わせて評価することが重要です。
2. Migration Costを左右する4つの重要な要因
レガシーマイグレーションの費用を考える際は、LOCに加えて、Complexity（複雑性）、Dependency（依存関係）、3rd-party Components（外部製品・部品）を確認する必要があります。
2.1. LOC：移行対象の規模
まず、移行対象となるコード量を把握します。
ただし、すべてのコードを同じ方法で移行するとは限りません。
利用されていない機能や、移行後に不要となる処理が含まれている可能性もあります。
そのため、総LOCだけでなく、実際に移行が必要な範囲を明確にすることが重要です。
2.2. Complexity：プログラムと業務ロジックの複雑性
複雑性は、移行工数に大きく影響します。
例えば、条件分岐が多い処理、共通化されていないコード、独自の計算ロジックなどは、解析や検証に時間がかかる場合があります。
特に基幹システムでは、長年蓄積された業務ルールがコード内部に組み込まれていることがあります。
これらを十分に理解せずに移行すると、新システムで業務結果が変わるおそれがあります。
2.3. Dependency：システム間の依存関係
一つのアプリケーションが複数のシステムと連携している場合、移行対象のコード量が少なくても、対応範囲が広がる可能性があります。
例えば、販売管理システムが在庫管理、会計、顧客管理と連携している場合、インターフェースの変更や連携テストが必要になることがあります。
こうした依存関係は、追加工数や移行スケジュールに影響します。
2.4. 3rd-party Components：外部製品・部品の制約
既存システムでは、外部ライブラリ、帳票ツール、ミドルウェア、商用コンポーネントなどが利用されている場合があります。
これらが新しい環境に対応していない場合、バージョンアップ、代替製品の導入、機能の再開発などが必要になります。
ライセンス費用や保守費用も確認対象です。
これらを組み合わせて評価することで、LOCだけでは見えない費用要因を整理できます。
3. Migration Costを適切に見積もるための進め方
Migration費用を検討する際は、最初から確定金額を求めるのではなく、段階的に見積もりの精度を高める方法が有効です。
3.1. Step 1：現行システムの調査
まず、対象システムの構成、ソースコード、データベース、外部連携、運用環境を確認します。
この段階では、移行対象と対象外の範囲を整理することが重要です。
仕様書が不足している場合は、Reverse Engineeringによって実際の処理内容を把握します。
3.2. Step 2：複雑性と依存関係の評価
次に、主要な機能の複雑性、外部連携、データ移行の難易度、利用中の外部製品を調査します。
調査結果をもとに、リスクの高い部分を特定します。
例えば、複雑な業務ロジックや互換性が不明なコンポーネントは、見積もりの不確実性を高める要因になります。
3.3. Step 3：移行方式の比較
調査結果を踏まえ、Rehost、Replatform、Refactor、Rebuildなどの移行方式を比較します。
既存の構造を維持する場合と、アプリケーションを再設計する場合では、必要な作業と費用が異なります。
初期費用だけでなく、移行後の保守性や運用費用も考慮する必要があります。
3.4. Step 4：PoCによる検証
不確実性が高い場合は、代表的な機能を対象にPoC（概念実証）を実施します。
実際のコードを用いて移行可能性やテスト難易度を確認することで、見積もりの前提条件を具体化できます。
3.5. Step 5：見積もりの更新
PoCや詳細調査の結果を反映し、開発、データ移行、テスト、本番切り替えなどの工数を再評価します。
このとき、前提条件、対象外作業、未確定事項を明記しておくことが重要です。
4. LOCが同じでもMigration費用が異なる実務例
ここでは、同じLOCでも費用が異なる理由を、仮想的なケースで説明します。
4.1. ケースA：構造が整理されたシステム
移行対象は10万LOCで、設計書が整備され、モジュール間の依存関係も比較的明確です。
外部システムとの連携が少なく、主要な業務処理のテスト条件も定義されています。
この場合、調査範囲や検証対象を比較的明確にできるため、見積もりの不確実性を抑えやすくなります。
4.2. ケースB：複雑な依存関係を持つシステム
こちらも10万LOCですが、長年の改修によって業務ロジックが複雑化しています。
設計書が不足し、複数の外部システムや古い商用コンポーネントにも依存しています。
この場合、コード量は同じでも、Reverse Engineering、連携変更、製品の代替検討、追加テストなどの工数が発生する可能性があります。
4.3. 二つのケースから分かること
この例から分かるように、LOCが同じでもMigrationの作業内容は大きく異なります。
そのため、単純な「LOC × 単価」だけで費用を判断することは避けるべきです。
5. Migration費用を判断するための基準とチェックリスト
適切なMigration予算を策定するには、金額だけでなく、見積もりの根拠と不確実性を確認することが重要です。
5.1. 見積もり前に確認したい項目
-
移行対象と対象外の範囲が明確になっている
-
LOCの計測方法が統一されている
-
業務ロジックの複雑性を評価している
-
外部システムとの依存関係を確認している
-
サードパーティ製品の互換性を調査している
-
データ移行とテストの工数を含めている
-
本番切り替えと切り戻しを計画している
-
未確定事項と見積もりの前提条件を明記している
5.2. 初期費用と長期的な運用費用を分けて考える
Migrationの費用評価では、初期開発費用だけでなく、移行後の保守、ライセンス、インフラ、運用などの費用も確認する必要があります。
例えば、初期費用が低い方式でも、旧技術への依存が残れば、将来的な保守負担が継続する可能性があります。
一方、初期費用が高くても、保守性や拡張性の改善によって長期的な運用負担を軽減できる場合があります。
そのため、複数の移行方式を比較する際は、総保有コスト（TCO）も判断材料にすることが重要です。
5.3. 概算から詳細評価へ進む
初期段階では、LOCやシステム構成などの情報から概算を作成できます。
ただし、概算は確定見積もりではありません。
Complexity、Dependency、3rd-party Componentsなどを調査し、必要に応じてPoCを実施することで、より具体的な費用判断につなげられます。
まとめ
レガシーマイグレーションの費用は、LOCだけで決まるものではありません。
LOCは移行対象の規模を把握するための出発点ですが、実際の費用にはComplexity、Dependency、3rd-party Components、データ移行、テストなどの要因が影響します。
重要なのは、初期段階で無理に確定金額を算出することではなく、現行システムの調査とリスク評価を通じて、見積もりの根拠を明確にすることです。
また、初期費用だけでなく、移行後の保守性や運用費用も含めて判断する必要があります。
RIKAIでは、現行システムの理解、技術検証、移行後の品質確認を重視したMigrationに関する情報を公開しています。
詳細はこちら
■RIKAIについて
高い技術と高い品質で事業を成功させる。
RIKAIはソフトウェア開発を軸に、「人と技術を中心としたビジネス」を展開しています。お客様に寄り添うことで、お客様の「真のニーズ」を把握し、本当に価値のあるサービスを提供します。私たちは、お客様と長期的かつ信頼できるパートナーになることを目指しています。
🏢 商号：RIKAI株式会社
📅 設立：2017年11月15日
👤 代表者：代表取締役 ドアン・ハイ・バン
📍 所在地：〒160‐0023 東京都新宿区西新宿6－12－1 パークウエスト5階
👥 従業員数：300名
🛠️ 業務内容：
・システム開発（業務システム、モバイルアプリ、インターネットサービスサイト、IoT・AIアプリ）
・システムマイグレーション
・システム保守・運用
・通信販売
🌐 公式WEBサイト：https://rikai.technology/
✉️ お問い合せ先：https://rikai.technology/contact