レガシーシステムの移行では、新しい技術や移行先の選定だけでなく、現行システムをどこまで正確に理解しているかが重要です。
長年運用されてきたシステムには、設計書に記載されていない業務ロジックや、担当者しか把握していない処理、複雑なシステム間の依存関係が存在する場合があります。
こうした情報が不足したままMigrationを進めると、必要な機能の欠落、データ不整合、追加改修、業務停止などにつながるおそれがあります。
そこで重要になるのが、リバースエンジニアリング（Reverse Engineering）です。
リバースエンジニアリングとは、既存のソースコード、データベース、設定ファイル、運用ログなどを分析し、システムの構造や処理内容を明らかにする手法です。
本記事では、Migration前に確認すべき5つのポイントをチェックリスト形式で解説します。
1. 既存システムの仕様とソースコードを把握できているか
Migration前に最初に確認したいのは、現行システムの仕様を正しく理解できているかという点です。
設計書が存在していても、その内容が現在のシステムと一致しているとは限りません。長年の機能追加や障害対応によって、資料と実装の間に差が生じている場合があります。
1.1. 設計書と実装の差異を確認する
基本設計書、詳細設計書、画面仕様書、データベース定義書、運用手順書などを収集し、実際のソースコードや設定ファイルと照合します。
特に確認すべきなのは、条件分岐、例外処理、共通モジュール、定期実行処理です。
例えば、販売管理システムに特定顧客向けの割引処理が追加されていても、設計書に反映されていなければ、新システムへの移行時に見落とされる可能性があります。
1.2. チェックリスト
-
最新の設計書とソースコードを取得できる
-
主要な機能と処理の流れを説明できる
-
設計書と実装の差異を整理している
-
重要な条件分岐や例外処理を把握している
-
不明な処理の確認担当者が決まっている
判断基準：重要な業務処理について、仕様と実装の対応関係を説明できない場合は、移行設計を確定する前に追加分析を検討します。
2. 業務ロジックとシステム間の依存関係を可視化できているか
二つ目は、システム内部の業務ロジックと外部連携の把握です。
レガシーシステムでは、一つの機能が複数のプログラムやデータベース、外部サービスに依存している場合があります。
そのため、対象アプリケーションだけを分析しても、移行による影響を十分に把握できないことがあります。
2.1. 画面から見えない業務ロジックを確認する
例えば、受注登録を実行すると、在庫引当、金額計算、請求情報の生成、会計システムへの連携などが連続して実行される場合があります。
このような処理を把握せずに画面機能だけを再構築すると、業務結果が既存システムと一致しない可能性があります。
重要なのは、コードから「何を実行しているか」を調べるだけでなく、業務担当者に「なぜその処理が必要なのか」を確認することです。
2.2. 依存関係を整理する
次の項目を対象に、依存関係図を作成します。
2.3. チェックリスト
-
主要な業務ロジックを一覧化している
-
外部システムとの連携を把握している
-
バッチ処理の実行順序を確認している
-
変更による影響範囲を説明できる
-
業務担当者による仕様確認を実施している
判断基準：一つの機能変更が他システムへ及ぼす影響を追跡できない場合は、依存関係の分析を優先します。
3. データ構造と移行後の整合性を検証できるか
三つ目は、データ移行の準備状況です。
Migrationでは、アプリケーションが正常に起動することだけでは十分ではありません。移行後のデータが業務上正しく利用できることを確認する必要があります。
3.1. データの構造と品質を確認する
まず、テーブル構造、主キー、外部キー、データ型、文字コード、更新頻度を調査します。
さらに、重複データ、欠損値、過去の仕様変更によるデータ形式の違いなども確認します。
例えば、旧システムで一つの項目に保存されていた情報を、新システムでは複数の項目に分割する場合、変換規則が必要になります。
変換規則が曖昧なまま移行すると、件数が一致していても、業務上の意味が変わってしまう可能性があります。
3.2. データ照合の方法を決める
移行前後の比較では、レコード件数だけでなく、重要項目の値、集計結果、参照関係も確認します。
特に売上金額、在庫数量、請求残高などは、業務上の検証条件を事前に定義することが重要です。
3.3. チェックリスト
-
データベース構造を把握している
-
データ変換規則を定義している
-
重複・欠損・不整合を確認している
-
移行前後の照合方法を決めている
-
不整合発生時の対応手順がある
判断基準：重要なデータについて移行後の正しさを検証する方法が決まっていなければ、本番移行前に検証計画を整備する必要があります。
4. Migration方式とリスク対策を具体的に判断できるか
四つ目は、分析結果を実際の移行方式の選定につなげられるかという点です。
Reverse Engineeringを実施しても、その結果が移行計画に反映されなければ、十分な価値を得られません。
4.1. 分析結果に基づいて移行方式を比較する
例えば、既存の業務ロジックを維持し、インフラだけを更新する場合はRehostが候補になります。
一部の実行基盤を改善する場合はReplatform、アプリケーション構造を見直す場合はRefactor、既存機能を新しく作り直す場合はRebuildを検討します。
ただし、方式ごとに必要な分析範囲や検証内容は異なります。
既存システムの構造が複雑で、仕様書も不足している場合は、詳細なコード解析や小規模な技術検証を先に実施することが考えられます。
4.2. 停止時間と復旧条件を明確にする
移行方式を決定する際は、業務を停止できる時間、切り替え手順、復旧条件も確認します。
例えば、夜間に移行を実施する場合でも、データ移行、動作確認、問題発生時の切り戻しに必要な時間を考慮しなければなりません。本番環境で初めて問題が発見されないよう、事前に移行手順を検証することが重要です。
4.3. チェックリスト
-
移行方式の選択理由を説明できる
-
方式ごとの費用とリスクを比較している
-
許容停止時間を定義している
-
移行リハーサルを計画している
-
切り戻し条件と責任者を決めている
判断基準：移行方式を選んだ理由や失敗時の対応を説明できない場合は、計画を確定する前に技術検証とリスク評価を行います。
4.2. 停止時間と復旧条件を明確にする
移行方式を決定する際は、業務を停止できる時間、切り替え手順、復旧条件も確認します。
例えば、夜間に移行を実施する場合でも、データ移行、動作確認、問題発生時の切り戻しに必要な時間を考慮しなければなりません。本番環境で初めて問題が発見されないよう、事前に移行手順を検証することが重要です。
4.3. チェックリスト
-
移行方式の選択理由を説明できる
-
方式ごとの費用とリスクを比較している
-
許容停止時間を定義している
-
移行リハーサルを計画している
-
切り戻し条件と責任者を決めている
判断基準：移行方式を選んだ理由や失敗時の対応を説明できない場合は、計画を確定する前に技術検証とリスク評価を行います。
5. 移行後の品質を確認するテスト基準が明確になっているか
最後に確認したいのは、Migrationの成功を何によって判断するかです。
新システムが起動し、画面が表示されるだけでは、移行が成功したとは言えません。
重要なのは、業務上必要な処理が期待どおりに実行され、データと外部連携が正しく機能することです。
5.1. 既存システムとの比較基準を設定する
Reverse Engineeringによって把握した業務ロジックは、移行後のテスト条件を作成する際にも活用できます。
例えば、同じ入力データに対して、旧システムと新システムの計算結果を比較します。
差異が発生した場合は、それが意図した仕様変更なのか、移行による不具合なのかを確認します。
5.2. 品質評価の項目を整理する
5.3. チェックリスト
-
主要な業務シナリオを定義している
-
旧システムとの比較テストを計画している
-
データ整合性の合格基準がある
-
外部連携と性能を検証できる
-
本番移行の承認条件が明確になっている
判断基準：テストの合格条件が曖昧な場合は、Migration前に業務担当者と技術担当者が共同で受入基準を定義する必要があります。
まとめ
Migration前にReverse Engineeringが必要な理由は、現行システムを正しく理解し、移行に伴うリスクを把握するためです。
特に確認すべきポイントは、既存システムの仕様とソースコード、業務ロジックと依存関係、データ整合性、移行方式とリスク対策、テスト基準の5つです。
これらを事前に整理することで、移行対象と影響範囲を明確にし、根拠のある移行計画を策定できます。
重要なのは、すべてのコードを解析することではなく、Migrationの判断に必要な情報を揃えることです。
現行システムの仕様や依存関係が不明確な場合は、移行方式を決める前に、まずアセスメントとReverse Engineeringの必要範囲を整理しましょう。
詳細はこちら
■RIKAIについて
高い技術と高い品質で事業を成功させる。
RIKAIはソフトウェア開発を軸に、「人と技術を中心としたビジネス」を展開しています。お客様に寄り添うことで、お客様の「真のニーズ」を把握し、本当に価値のあるサービスを提供します。私たちは、お客様と長期的かつ信頼できるパートナーになることを目指しています。
🏢 商号：RIKAI株式会社
📅 設立：2017年11月15日
👤 代表者：代表取締役 ドアン・ハイ・バン
📍 所在地：〒160‐0023 東京都新宿区西新宿6－12－1 パークウエスト5階
👥 従業員数：300名
🛠️ 業務内容：
・システム開発（業務システム、モバイルアプリ、インターネットサービスサイト、IoT・AIアプリ）
・システムマイグレーション
・システム保守・運用
・通信販売
🌐 公式WEBサイト：https://rikai.technology/
✉️ お問い合せ先：https://rikai.technology/contact