Migration CostはLOCだけで決まるのか？で失敗しないためのチェックリスト：確認すべ

レガシーシステムの移行を検討する際、「ソースコードの行数が分かれば、移行費用も計算できるのではないか」と考えることがあります。
確かに、LOC（Lines of Code：コード行数）は、システムの規模を把握するための指標の一つです。しかし、同じ10万行のシステムでも、構造や業務ロジック、外部システムとの連携状況によって、移行に必要な工数は大きく異なります。
特に、設計書が不足しているシステムや、長年の改修によって複雑化したシステムでは、コード変換以外の調査・検証作業が費用に影響します。
結論として、Migration CostはLOCだけでは決まりません。
本記事では、見積もりの失敗を防ぐために確認すべき5つのポイントを、実務で使えるチェックリスト形式で解説します。

1. LOCの数値だけでなく、移行対象の範囲を確認できているか

LOCは、移行対象となるソースコードの規模を把握する際に役立ちます。しかし、すべてのコードが同じ作業量を必要とするわけではありません。

1.1. LOCの計測方法を統一する

まず、コメント行、空行、自動生成コード、共通ライブラリなどを計測対象に含めるかどうかを決めます。
また、長年使用されていない機能が含まれている場合、すべてを新システムへ移行する必要があるとは限りません。
重要なのは、総LOCではなく、実際に移行するコードの範囲を明確にすることです。

1.2. チェックリスト

  • LOCの計測方法が統一されている

  • 移行対象と対象外の機能を区別している

  • 未使用コードや重複処理を確認している

  • 自動生成コードの扱いを決めている

判断基準：LOCの内訳や移行対象が不明確な場合は、コード量だけで工数を確定しないことが重要です。

2. コードと業務ロジックの複雑性を評価できているか

同じLOCでも、プログラムの複雑性（Complexity）によって必要な解析・改修・テスト工数は異なります。

2.1. 複雑性が費用に与える影響

例えば、単純なデータ表示処理と、多数の条件分岐を含む料金計算処理では、同じコード量でも移行難易度が異なります。
特にレガシーシステムでは、独自の業務ルールがソースコードに埋め込まれている場合があります。
設計書と実際の処理が一致していなければ、Reverse Engineeringによって現行システムの動作を把握する必要があります。

2.2. チェックリスト

  • 主要な業務ロジックを把握している

  • 複雑な条件分岐や例外処理を特定している

  • 設計書とソースコードの差異を確認している

  • 解析や再設計が必要な機能を整理している

判断基準：業務上重要な処理を説明できない場合は、移行工数に加えて調査・分析工数を考慮する必要があります。

3. システム間の依存関係を把握できているか

Migration費用を見積もる際に見落とされやすいのが、Dependency（依存関係）です。

3.1. 外部連携が見積もりに与える影響

例えば、販売管理システムが在庫管理、会計、顧客管理システムと連携している場合、アプリケーション本体の移行だけでは完了しません。
接続方式の変更、データ形式の調整、外部システムとの結合テストなどが必要になる可能性があります。
特に、バッチ処理やファイル連携などは、設計書だけでは全体像を把握できないことがあります。

3.2. チェックリスト

  • 外部システムとの連携を一覧化している

  • APIやファイル連携の仕様を確認している

  • バッチ処理の実行順序を把握している

  • 移行による影響範囲を評価している

判断基準：依存関係が明確でない場合は、連携変更や追加テストの工数を見積もりに反映する前に、影響調査を行います。

4. 3rd-party Componentsの互換性と追加費用を確認できているか

既存システムでは、外部ライブラリ、帳票ツール、ミドルウェア、商用コンポーネントなどが利用されている場合があります。
これらの3rd-party Componentsは、LOCだけでは把握できない費用要因です。

4.1. 新環境で利用できるかを確認する

例えば、旧環境で使用していた帳票ツールが新しいOSやフレームワークに対応していない場合、製品の更新や代替機能の開発が必要になることがあります。
また、商用製品ではライセンス費用や保守契約の変更も確認しなければなりません。

4.2. チェックリスト

  • 外部ライブラリと商用製品を一覧化している

  • 新環境での互換性を確認している

  • 更新・代替が必要な製品を特定している

  • ライセンス費用と保守費用を確認している

判断基準：互換性が未確認の製品がある場合は、代替案や追加費用を評価してから見積もりを確定します。

5. テスト・データ移行・運用費用まで含めて判断できているか

Migration Costは、コード変換やアプリケーション開発だけで構成されるものではありません。
移行後に業務が正常に継続できることを確認するためのテストや、データ移行、本番切り替えなども重要な費用項目です。

5.1. 初期開発費用だけで判断しない

例えば、新システムが正常に起動しても、旧システムと計算結果が異なれば、業務に影響する可能性があります。
そのため、主要な業務処理について、移行前後の結果を比較するテストが必要です。
また、データ変換、移行リハーサル、切り戻し準備なども見積もりに含める必要があります。
さらに、移行後の保守費用、ライセンス費用、インフラ費用などを含めた総保有コスト（TCO）も確認することが重要です。

5.2. チェックリスト

  • データ移行と検証の工数を含めている

  • 主要な業務機能のテストを計画している

  • 本番切り替えと切り戻しの費用を考慮している

  • 移行後の保守・運用費用を評価している

  • 見積もりの前提条件と未確定事項を明記している

判断基準：開発費用だけでなく、テスト、データ移行、運用まで含めて比較することで、より適切なMigration予算を検討できます。

まとめ

Migration Cost見積もり｜5つのチェックポイント

Migration Costを適切に見積もるためには、LOCだけでなく、次の5つのポイントを確認することが重要です。

  1. LOCと移行対象の範囲

  2. コードと業務ロジックの複雑性

  3. システム間の依存関係

  4. 3rd-party Componentsの互換性

  5. テスト・データ移行・運用費用

これらを事前に評価することで、見積もりの根拠を明確にし、想定外の追加工数や費用の発生リスクを抑えるための計画を立てやすくなります。
重要なのは、コード量だけで費用を判断するのではなく、現行システムの実態と移行後の品質要件を踏まえて評価することです。

RIKAIのシステム移行に関する情報は、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