マイグレーションの進め方｜アセスメント・AI移行・テストの3段階

マイグレーションの進め方は、「アセスメント（現状の数値化）→ AI支援による移行 → テスト（旧システムを正解とする品質の証明）」の3段階で考えると、判断と責任の所在が明確になります。

重要なのは、段階そのものよりも、段階と段階の間に「次へ進んでよいか」を判定する関門（ゲート）を置くことです。HBLABは、テストを最後の工程ではなく、コード変換を始める前に設計します。

本記事では、マイグレーションの進め方について、一般的な手順との違い、各段階の完了条件と成果物、ベンダーの進め方を見極める質問まで、意思決定に必要な情報を整理します。関連テーマはモダナイゼーション記事一覧からもご覧いただけます。

マイグレーションの進め方とは？一般的な手順と見落とされがちな落とし穴

まず、多くの解説で紹介されている標準的な手順を確認します。そのうえで、実際のプロジェクトでつまずきやすいポイントを見ていきます。

一般的なマイグレーションの進め方（5ステップ）

マイグレーションとは、既存のシステムやデータを、新しい環境・言語・基盤へ移すことです。一般的な手順は、次の5ステップで説明されます。

1. 現状分析：現行システムの資産・仕様・課題を洗い出す
2. 計画策定：移行範囲、移行方式、スケジュールを決める
3. 移行（変換・開発）：コードやデータを新しい環境へ移す
4. テスト：新システムが正しく動くかを検証する
5. 本番移行・運用：切り替えを行い、運用を定着させる

本番の切り替え方式には、全体を一度に切り替える一括移行、範囲を分けて順に切り替える段階移行、新旧を同時に動かす並行稼働の3つがあります。規模が大きいほど、段階移行や並行稼働でリスクを分散するのが一般的です。

この5ステップは、マイグレーションの進め方として正しい整理です。ただし、用語の前提が揃っていないと、進め方の議論そのものがずれてしまいます。

マイグレーション・モダナイゼーション・リプレースの違い

マイグレーションは、業務の振る舞いを維持したまま、システムを新しい環境へ移すことです。モダナイゼーションは、移行に加えて、アーキテクチャや業務プロセスの刷新まで含む、より広い取り組みです。リプレースは、既存システムを廃止し、パッケージやSaaSに置き換えることを指します。

本記事が扱うのは、主に「業務を変えずに移す」マイグレーションの進め方です。違いの詳細はモダナイゼーションとマイグレーションの違いと選び方、全体像はシステムモダナイゼーションの解説をご覧ください。

用語を揃えたところで、手順どおりに進めても失敗するプロジェクトがある理由に目を向けます。

失敗の多くは「工程と工程のつなぎ目」で起きる

5ステップを順番に進めても、つまずくプロジェクトは少なくありません。原因の多くは、個々の工程ではなく、工程と工程のつなぎ目にあります。

典型的なのは、次のような流れです。

• アセスメントの結果が、テスト計画に引き継がれない
• 新旧比較テストを、コード変換が終わった終盤に初めて実施する
• その結果、数千件の差異が一度に見つかる
• 本番稼働前の2週間で、人海戦術で差異を処理することになる

差異の大半はバグではありません。しかし分類のルールがなければ、チームはやがてすべての差異を無視し始めます。本物のバグも含めてです。

経済産業省の「レガシーシステムモダン化委員会総括レポート」でも、ユーザー企業に対してシステムの可視化や「現行踏襲」の見直しが求められています。可視化した結果を、次の工程の判断にどうつなぐか。それが、マイグレーションの進め方の成否を左右します。

HBLABのマイグレーションの進め方：3段階と4つの関門

HBLABのマイグレーションの進め方では、このつなぎ目の問題を「関門（ゲート）」で解決します。ここでは全体像、関門の完了条件、成果物の順に説明します。

アセスメント → AI支援の移行 → テストの全体像

HBLABのマイグレーションは、次の3段階で進めます。

段階	目的	主な作業
第1段階 アセスメント	移行対象と「成功の定義」を数字で決める	AI解析、スコープ・方式の決定、シームの特定
第2段階 AI支援による移行	人の判断のもとでAIに変換を実行させる	変換スクリプトの生成、レビュー、小さな単位でのコミット
第3段階 テスト	旧システムを正解として品質を証明する	ゴールデンデータ、4軸評価、現新比較、差異分類

この3段階は、HBLABのAIツールセット「Migurei AI Inside」の4つのモジュール（診断・設計・移行・テスト）に対応しています。設計モジュールは、第1段階の方式決定と、第2段階の変換準備にまたがる位置づけです。

ポイントは、テストの準備が第1段階から始まることです。テストは最後の工程ではなく、移行を始めてよいかを判断する材料として使います。

では、各段階の間で「次へ進んでよいか」を、どのように判定するのでしょうか。

各段階の完了条件：省略してはならない4つの関門

HBLABのマイグレーションの進め方は、10のステップと4つの関門で構成されます。関門は、条件を満たさない限り次へ進まないための仕組みです。

段階	ステップ	完了条件
アセスメント	01 アセスメント	モジュール一覧、リスクレベル、品質しきい値をPMとBrSEが承認。旧システムの環境を構築できることを確認
アセスメント	02 シームの特定	境界線が引かれ、お客様が確認済み
テスト準備	03 ゴールデンデータの構築	マスキング済み・バージョン管理済みで、全ケースにメタデータがある
テスト準備	04【関門①】データの評価と補強	結論の出ていないギャップがゼロ
テスト準備	05【関門②】テストを生成し旧システムで実行	旧システム上でテストが100%グリーン
テスト準備	06【関門③】4つの軸でテストを評価	テスト対象ごとに4軸がしきい値を満たす
移行	07 AI支援による変換	小さな単位でコミットし、変更箇所の100%にテストが到達
テスト	08 シームでの新旧比較	一致率がしきい値に到達
テスト	09【関門④】差異の分類	説明のつかない差異がゼロ
切り替え	10 並行稼働・カットオーバー	ロールバックのリハーサルが完了

多くのプロジェクトでは、ステップ04と06が存在しません。集まったデータをそのまま使い、テストが緑になった時点で完成とみなされます。

指標は、先へ進むことを止められるときにだけ価値を持ちます。終盤にまとめて報告するレポートでは、問題に気づいたときには手遅れです。

関門の考え方が分かったところで、各段階で何が成果物として残るのかを確認します。

各段階の成果物・お客様にご用意いただくもの・判断者

稟議やRFPの作成では、「何を受け取り、何を準備し、誰が判断するのか」が明確であることが重要です。

段階	主な成果物	お客様にご用意いただくもの	主な判断者
アセスメント	診断レポート（LOC・依存関係・難易度・リスク）、モジュール別の推奨方式、シームの定義、品質しきい値	対象ソース一式（NDA締結のうえ）、旧システムの実行環境、業務部門へのヒアリング機会	お客様の情シス部門・業務部門、HBLABのPM・BrSE
AI支援による移行	変換済みコード、変換スクリプト、レビュー記録	移行先アーキテクチャの方針への合意	お客様のアーキテクト、HBLABのSA
テスト	バージョン管理されたゴールデンデータ、4軸レポート、承認済みの差異分類ルール、お客様のCIで動くテストスイート、監査用のエビデンス一式	マスキング済みの本番データまたはトラフィックログ、差異分類ルールの承認	お客様の業務部門、HBLABのQCリード

最終的には、新システムに加えて30種類以上のドキュメントをお渡しします。移行後に、システムを再びブラックボックス化させないためです。

※成果物の名称と範囲は、プロジェクトの方式や規模に応じて調整します。

最後に、一般的な進め方との違いを一覧で整理します。

一般的なマイグレーションの進め方との違い

観点	一般的な進め方	HBLABの進め方
テストの正解	テスト担当者が期待値を推測する	旧システムから記録したゴールデンデータ
新旧比較のタイミング	終盤、コードを書き終えてから	コード変換の前。テストへのインプットとして使う
テストデータ	集まれば完成	網羅性を評価し、すべてのギャップに結論を出す
品質指標	コードカバレッジの数字1つ	4つの軸 × テスト対象ごと
指標の役割	終盤のレポート	進行を止める4つの関門
偽差異の処理	本番前に人海戦術で処理	出力正規化ライブラリと承認済みの分類ルール

第1段階 アセスメント：移行対象と「成功の定義」を数字で決める

アセスメントは、マイグレーションの進め方全体の土台です。その役割は、移行対象を「感覚」ではなく「数字」で把握し、何をもって成功とするかを先に合意することです。AIが集める事実と、人が決める判断を分けて見ていきます。

AIで集める事実：LOC・依存関係・業務ルール・デッドコード

AIが最も確実に力を発揮するのは、現行資産の解析です。人手なら数週間かかる作業を、短期間で一次集計できます。

• 言語別のLOC（ソースコード行数）、プログラム・画面・帳票・バッチの数
• モジュール間の依存関係と外部インターフェース
• ソースコードから抽出した業務ルールの候補
• 一度も実行されていないデッドコードの候補

LOCは、複雑さの指標として完璧ではありません。しかし、発注側と受注側が同じ数字を見て合意できるという大きな利点があります。LOCが確定して初めて、工数・予算・移行範囲の分割を議論できます。

事例：デッドコードの特定で、移行範囲を約3分の1削減

VB6からC# .NETへ移行した物流システムでは、約12万LOC・45画面・30帳票を解析し、約35%がデッドコードであることが分かりました。その結果、移行範囲を約3分の1削減できています（出典：HBLAB Migration Assessment Service 解説ウェビナー）。

事実が揃ったら、次はその事実をもとに人が判断する番です。

人が決めること：移行スコープ・優先順位・モジュールごとの移行方式

AIが集めるのは「事実」です。その事実から、何を、どの順番で、どの方式で移すかは人が決めます。

• 移行スコープ：どこまでを今回の移行対象にするか。使われていない機能は移さない
• 優先順位：ビジネス価値・技術的なリスク・依存関係から、着手の順番を決める
• 移行方式：システム全体で1つに決めず、モジュールごとにリホスト・リファクタリング・リビルドなどを選ぶ

これらは、間違えたときに誰かが責任を負わなければならない判断です。だからこそAIではなく、お客様とHBLABのPM・BrSE・SAが合意して決めます。評価の観点はレガシーシステムアセスメントの評価7領域、着手順の決め方はモダナイゼーションの優先順位と範囲の決め方で詳しく解説しています。

方式の中でも、業務を変えずに移すリファクタリング型を選ぶ場合は、事前に確認すべき条件があります。

リファクタリングを選ぶ前に確認すべき3つの前提条件

旧システムの振る舞いを「正解」としてテストするには、次の3つの条件が必要です。遅くともアセスメントの段階で確認します。

1. 旧システムを動かす環境を構築できること：動かせなければ、正解を記録できません
2. マスキング済みの本番データ、またはトラフィックログを取得できること
3. 出力を毎回同じ条件で比較できること：時刻やランダムな値に依存する要素を固定できること

旧システムがすでに停止している、ライセンスが残っていない、業務そのものを変える必要がある。こうした場合は、リビルド（お客様が確認した新しい仕様書を正解とする方式）を検討します。

旧環境を構築できるかを確かめないままリファクタリングを選ぶことは、見積もりに織り込まれていない大きなリスクです。HBLABは、この確認をアセスメントの完了条件にしています。

前提条件を確認したら、テストをどこに置くかを決めます。

持続するシーム（接合点）を特定し、「移行成功」の定義を合意する

リファクタリングでは、旧システムのコード構造は消えていきます。旧構造に沿って書いたテストは、構造と一緒に失われます。

そこで、新旧の両方に存在し、移行後も消えない接合点、つまりシームにテストを置きます。典型的なシームは次のとおりです。

• HTTPエンドポイント、APIのエントリポイント
• メッセージキュー、トピック
• 帳票、取引先への送信ファイル、バッチの出力ファイル
• ストアドプロシージャのインターフェース
• 他システムが直接読み込んでいるテーブル

どこがシームかは、AIには判断できません。人が外部とのつながりを洗い出して境界線を引き、お客様の確認を得て文書化します。この境界線が、「移行成功」の定義そのものになります。

境界線がなければ、比較の段階で差異が見つかったとき、それがバグなのか許容できるものなのかを誰も裁定できません。

アセスメントの完了条件と成果物

アセスメントは、次の状態になって初めて完了とします。

• モジュール一覧と、モジュールごとのリスクレベル・推奨方式が揃っている
• テスト対象ごとの品質しきい値が決まり、PMとBrSEが承認している
• 旧システムの環境を構築できることが確認されている
• シームの境界線を、お客様が確認している

診断レポートで確認すべき項目は、アセスメントレポートが移行前に答えるべき10の問いにまとめています。ここまでが、AIに変換を任せる前の土台です。

第2段階 AI支援による移行：AIは「実行」、人は「決定」

第2段階では、AIを使ってコード変換を進めます。ただし、AIに任せるのは「実行」であり、「決定」は人が担います。この線引きを工程ごとに見ていきます。

工程別のAIと人の責任分界

作業・判断	AI主体	AI＋人のレビュー	人のみ
静的コード解析・依存関係の抽出	●
仕様書・業務ロジックのドラフト作成		●
骨格・定型処理のコード変換		●
テストケースの大量生成		●
現新比較の実行	●
移行スコープ・優先順位の決定			●
アーキテクチャ設計・責務分割			●
差異の最終判定（許容か不具合か）			●

「人のみ」の欄に並ぶのは、いずれも間違えたときに責任を負う必要がある判断です。工程ごとのAI活用の詳細は、マイグレーションのAI活用｜工程別にできること・限界と品質担保で解説しています。

この責任分界は、コード変換の自動化範囲にもそのまま表れます。

AIで自動化しやすい領域と、人の判断が必要な領域

自動化しやすい領域	人の判断が必要な領域
宣言部・型マッピング・構文変換などの骨格部分	業務ルールが絡む条件分岐
パターンが反復する定型処理	業務上の例外のために規則から外れている箇所
仕様が明確な部分のテストコード生成	アーキテクチャの再設計と責務分割
共通様式に沿った帳票・画面の変換	旧基盤固有の特性に依存する処理

ただし、自動化しやすい領域でも、AIの使い方を誤ると検証できない成果物が生まれます。

AIにファイルを直接変換させず「変換スクリプト」を書かせる

生成AIの出力には、再現性が保証されません。同じ指示でも、実行のたびに結果が変わる可能性があります。

そのためHBLABは、AIにファイルを直接書き換えさせるのではなく、変換スクリプトを書かせる方法をとります。スクリプトであれば、人が読んでレビューでき、テストや再実行も可能です。

原則はシンプルです。自動的に検証できないものは、AIの担当範囲に入れません。

検証の仕組みについては、もう一つ守るべき原則があります。

同じAIにコード変換とテスト生成の両方をさせない

同じAI・同じコンテキストで、コードの変換と、そのコードを検証するテストの生成を両方行うと、AIは「検証される側」と「正解を出す側」を兼ねることになります。

そのテストが証明できるのは、「AIが自分自身と一貫している」ということだけです。

マイグレーションでは、独立した正解がすでに存在します。現在稼働している旧システムそのものです。HBLABのマイグレーションの進め方全体は、この原則に支えられています。

変換を始める条件：旧システム上でテストが100%グリーンであること

HBLABでは、コード変換を始める前に、旧システム上でテストが100%グリーンになっていることを必須条件にしています。

このステップの目的は、コードのテストではありません。自分たちが旧システムを正しく理解しているかを確かめることです。

旧システム上でテストが赤になるなら、旧システムの振る舞いに関する仮定が間違っています。その状態で変換を始めると、その後の比較はすべて意味を失います。テストの作り方は、次の第3段階で説明します。

工数30〜50%削減が成立する条件

AI活用による工数削減の目安は、手作業比で30〜50%です（当社実績に基づく参考値であり、対象言語・コード規模・要件により変動します）。ただし、この数字は前提条件によって大きく変わります。

削減率が伸びる条件	削減率が伸びにくい条件
ソース一式と実行環境が揃っている	ソースの一部が欠落している
定型的な処理・画面が多い	業務ルールと密に絡んだ分岐が中心
旧システムの挙動を正解として使える	旧システムが停止済みで挙動を再現できない
デッドコード・未使用機能を対象外にできる	全機能に「現行どおり」の方針を適用する

最大のコスト削減は、移行しないコードを決めることです。使われていない機能を移すことは、移行費用と移行後の保守費用の二重払いになります。

AI生成コード専用のレビューチェックリスト

AIが生成したコードには、人が書いたコードとは異なる典型的な問題があります。HBLABは、AI生成コード専用のチェックリストでレビューします。

• 見慣れないライブラリが追加されていないか
• エラー処理が簡略化されていないか
• テストから持ち込まれたハードコード値がないか
• コメントと実際の振る舞いが食い違っていないか
• シークレット（認証情報など）が紛れ込んでいないか

あわせて、1つのコミットに1つの目的というルールで変更量を管理します。差分が小さいからこそ、差異が見つかったときに原因のコミットまで遡れます。

AIは生産性を高めますが、責任を移すことはありません。品質に署名するのは、あくまでQCリードです。

第3段階 テスト：旧システムを「正解」として品質を証明する

マイグレーションの進め方において、第3段階のテストは名前こそ最後ですが、準備は第1段階から始まっています。ここでは、正解の作り方、網羅性の測り方、差異の判定方法を順に説明します。詳しい手法はマイグレーションテストの進め方｜ゴールデンデータと4つの品質軸をご覧ください。

ゴールデンデータ：正解は推測せず、旧システムから記録する

ゴールデンデータとは、サンプル入力と、それに対応して旧システムから記録した出力のセットです。以降のすべての比較で、基準となる正解として使います。

新旧比較テスト自体は、日本のプロジェクトで広く行われています。違いは、HBLABがゴールデンデータをコードを書く前に構築し、テストへのインプットとして使う点です。

入力は、本番ログ、本番DBのスナップショット、コードの条件分岐から生成したデータ、業務部門から提供されたデータの4つを組み合わせます。そのうえで、実行は2層に分けます。

• 高速層：数百件。コミットごとに実行し、10分以内で終わらせる
• フル層：数万〜数百万件。毎晩、またはマイルストーンの前に実行する

10分を超えると、開発者はコミット前にテストを流さなくなり、安全網が機能しなくなるためです。

ただし、ゴールデンデータは件数が多ければよいわけではありません。

データの網羅性を評価し、すべてのギャップに結論を出す

本番由来のデータは、分布が大きく偏っています。頻繁に起きる処理は大量にあり、めったに起きない処理はほとんどありません。そして、マイグレーションのバグはその「めったに起きない」部分に集中します。

ゴールデンデータが50万件あっても、そのうち49万件が同じ分岐を通っているかもしれません。件数は指標ではありません。

そこでHBLABは、データセットそのものの網羅性を、コード分岐・業務ルール・ケース種別・データの組み合わせの4つの観点で評価します。見つかったギャップには、必ず次のいずれかの結論を出します。

• 補充する：稀なケースや異常系を、手作り、または条件から生成して追加する
• 除外する：デッドコードと確認し、文書に記録して移行範囲から外す
• リスクを受容する：業務リスクを評価し、承認者とともに文書化する

100%網羅する必要はありません。必要なのは、結論の出ていないギャップがひとつも残っていないことです。

データが揃ったら、次はテストそのものの品質を測ります。

カバレッジ1つではなく「4つの品質軸」で測る

テスト品質の指標がコードカバレッジだけだと、重要なギャップが見えなくなります。すべての関数を呼ぶだけで何も検証しないテストでも、カバレッジは100%になるからです。

HBLABは、独自の測定フレームワークMigurei Qualityで、次の4つの軸を直列のフィルタとして使います。

軸	問い	検出できるもの
① Code coverage	テストはコードの分岐を通っているか	一度も実行されていないコード
② Spec coverage	テストは業務ルールに対応しているか	通過はしているが検証されていない業務
③ Test category	正常系・境界値・異常系が揃っているか	正常系ばかりのテストスイート
④ Test quality	テストは本当にバグを捕まえるか	存在するがバグを捕まえられないテスト

④では、コードに意図的にバグを埋め込み、テストが捕まえる割合を測るミューテーションスコアを主な指標にします。意味のある検証（assert）を持たないテストは、AIが生成したテストの典型的な問題です。この軸で見つけて除外します。

なお、「単体テストのカバレッジを100%にしてほしい」というご要望には、2つの概念を分けてお答えしています。テストの100%パスは必須です。一方で、コードカバレッジ100%は誤った目標になりえます。まもなく消える旧構造のコードに、工数を注ぐことになるからです。

4つの軸は、業務ロジックだけでなく、すべてのテスト対象に適用します。

テスト対象別の検証ポイント

対象	検証すべきこと	不足しやすいケース
業務ロジック	金額の計算式、税のルール、承認条件、営業日の計算	しきい値の前後、税率の変更日
データ	件数突合、金額列の合計、型と小数精度、外部キーの整合性	制約を満たさない過去データ
API	スキーマ、ステータスコード、エラーのフォーマット	エラー経路、タイムアウト
バッチ	固定長レイアウト、文字コード、全角文字のバイト数、再実行	境界値と異常系の両方
外部連携	実トラフィックの記録と再生、リトライ、重複メッセージ	異常系がほぼ皆無

レポートは対象ごとに分けて作成し、システム全体で1つの数字にまとめません。きれいな数字が、最もリスクの高いバッチや外部連携を覆い隠してしまうためです。

テストを流したら、次は差異の判定です。

現新比較の差異分類：バグと許容できる差異の線引き

最初の現新比較では、たいてい数千件の差異が出ます。その大半はバグではありません。分類のルールがあるかどうかで、チームの負荷は大きく変わります。

差異の種類	具体例	結論
フォーマット	2025/01/05 と 2025-1-5、行末の空白	正規化
丸め	四捨五入と銀行丸め、演算の順序	常にバグ
文字コード	CP932からUTF-8、波ダッシュ、全角と半角	バグ
NULL・空文字・0	DBエンジン変更時の定番パターン	バグ
レコードの順序	キー重複時の順序、照合順序の違い	ルール化（下流が依存していればバグ）
ID・タイムスタンプ	自動採番、JSTとUTC	正規化

HBLABは、偽差異の大半を出力正規化レイヤーで自動的に解消し、残った差異をお客様が文書で承認した分類ルールで判定します。完了条件は、説明のつかない差異がゼロであることです。「とりあえず後で見る」という保留枠は作りません。

日本の業務特有の境界ケース

日本の業務システムには、一般的なテスト技法だけではカバーしきれない境界ケースがあります。

• 元号（令和・平成）と改元
• 営業日カレンダー、月末・決算期末・うるう日
• 複数税率の消費税、税率の変更日
• 全角と半角、Shift_JISとCP932、波ダッシュ（〜）
• フィールドの最大長と、全角文字のバイト数

HBLABは、これらを日本の業務向け境界ケースライブラリとして蓄積し、プロジェクトの初日から再利用しています。技法は公開されていますが、校正済みのライブラリは、実際のプロジェクトを重ねてはじめて手に入るものです。

並行稼働とカットオーバー：ロールバックまでリハーサルする

最後のステップが、本番への切り替えです。HBLABは、規模やリスクに応じて段階的な置き換えと並行稼働を組み合わせます。

並行稼働では新旧2つの系統を同時に動かし、実際の結果を書き込むのは旧系統だけにします。新系統の出力は、シャドーとして比較に使います。段階的な置き換えの考え方は、Martin Fowler氏がStrangler Figとして整理したパターンが知られています。

切り替えの完了条件は、ロールバックのリハーサルが済んでいることです。戻せる状態を確認してから、初めて切り替えます。

稟議を通しやすいマイグレーションの進め方：無償AI診断 → PoC → 段階的な本格移行

ここまで、3段階と4つの関門を見てきました。では、社内の稟議はどう通せばよいのでしょうか。HBLABがおすすめしているのは、全体を一括で決めない進め方です。

全体を一括で契約しない「段階契約」という選択肢

規模が見えない段階で全体を確約すると、見積もりの前提が曖昧なまま意思決定することになります。HBLABでは、次の3ステップがそれぞれ「次に進むかどうか」を判断できる区切りになるよう設計しています。

ステップ	内容	お客様にご用意いただくもの	得られる成果
1. 無償AI診断	コード構造・依存関係・難易度の分析、移行リスクの評価	対象ソースのZIP（一部のモジュールでも可）	診断レポート（LOC・難易度・主要課題）
2. 小規模PoC	限定した範囲で実現可能性と効果を検証	PoC範囲の選定（HBLABと共同）	稟議に使える定量的な検証結果
3. 段階的な本格移行	予算と優先順位に応じて範囲を拡大	―	新システム＋30種類以上のドキュメント

この進め方なら、「大きすぎて決裁できない案件」を、「決裁できる規模の案件の集合」に変えられます。

段階契約の中でも、稟議の材料を作る要になるのがPoCです。

PoCで確認すべきこと：稟議に使える定量データ

PoCでは、「動いた」ことよりも、数字で語れる結果を残すことが重要です。

• 自動変換できた割合と、人の修正が必要だった箇所の傾向
• シームでの新旧一致率と、差異の種類別の件数
• LOCあたりの実工数と、本格移行時の見積もりの根拠
• 4つの品質軸の測定結果と、残る弱点のリスト

4つの数字と弱点のリストがあれば、経営層は「どこがまだ守られていないか」「追加投資に値するか」を判断できます。98%という数字が1つあるだけでは、何も判断できません。

マイグレーションの進め方でよくある失敗と対策

手順を知っていても、同じ失敗は繰り返されます。代表的な6つと、それを防ぐ関門を整理します。

• アセスメントを省略し、方式を先に決めてしまう：数字がないまま工数とリスクを見積もることになります。LOCとデッドコードを確定させてから方式を決めます。
• 旧環境を構築できないのにリファクタリングを選ぶ：正解を記録できず、テスト戦略が成り立ちません。旧環境の構築確認を、アセスメントの完了条件にします。
• 現新比較を終盤に回す：数千件の差異が本番直前に噴出します。ゴールデンデータを変換前に構築します（関門①②）。
• コードカバレッジ100%をKPIにする：消える構造のテストに工数が流れ、本当に守るべき場所が手薄になります。4つの品質軸で評価します（関門③）。
• 差異を「要判断」のまま保留する：保留された差異は、二度と見直されません。承認済みの分類ルールで判定します（関門④）。
• 旧システムのバグを移行のついでに直す：業務側が適応しているバグは、リファクタリングにおいては仕様です。修正したい場合は、移行とは別のリリースで行います。

ベンダーの「進め方」を見極める7つの質問

マイグレーションの成否は、ベンダーの進め方に大きく左右されます。提案書でマイグレーションの進め方を比較する際は、次の7つの質問を投げかけてみてください。答え方で、進め方の成熟度が見えてきます。

質問	確認したいポイント	HBLABの回答
1. テストの「正解」はどこから得ますか？	期待値を推測していないか	旧システムから記録したゴールデンデータ
2. 現新比較はいつ始めますか？	終盤まで後回しにしていないか	コード変換の前に準備し、変換中も継続
3. 品質指標はカバレッジだけですか？	検証の質を測っているか	4つの品質軸をテスト対象ごとに測定
4. 差異の分類ルールは文書で合意しますか？	判定が担当者任せになっていないか	お客様の承認を得た分類ルールを作成
5. 各段階の完了条件はありますか？	進行を止める仕組みがあるか	4つの関門と10ステップの完了条件
6. AIが生成したコードとテストを、誰がどうレビューしますか？	AI任せになっていないか	専用チェックリストでレビューし、QCリードが署名
7. 段階的に契約できますか？	規模が分かる前に全体を確約させていないか	無償AI診断 → PoC → 段階的な本格移行

ベンダー選定全般の評価基準はモダナイゼーションベンダーの選び方｜8つの評価基準、オフショアの活用はベトナムのシステムモダナイゼーション開発会社もあわせてご覧ください。

HBLABのマイグレーション支援：Migurei AI Inside

HBLABの「HBLAB Modernization Solution」は、独自のAIツールセットMigurei AI Insideを中核に、診断・設計・移行・テストの4つのモジュールで移行の全工程をカバーします。本記事で紹介したマイグレーションの進め方（3段階と4つの関門）は、このソリューションの進め方そのものです。

特に強みを持つ主な移行パターンは、次の5つです。

• VB6 / VBA → C# / Python
• Java Struts → Spring Boot
• COBOL → Java など
• Lotus Notes → intra-mart
• ネイティブ（iOS / Android）→ Flutter

これら以外の言語・システムについても、ご要望に応じて対応します。500件以上のプロジェクト実績と日本市場での10年の経験をもとに、プライバシーマーク・ISMS（ISO/IEC 27001）・CMMIレベル3の体制でご支援します。

サービスの詳細はHBLABのモダナイゼーション・マイグレーション支援、リリース情報はModernization Solution（Migurei AI Inside）のお知らせをご覧ください。

マイグレーションの進め方に関するよくある質問

Q1. マイグレーションにはどのくらいの期間がかかりますか？

期間は、移行対象の規模（LOC）、移行方式、テスト範囲によって大きく変わります。HBLABでは一律の目安ではなく、無償AI診断でLOCと難易度を可視化したうえで、段階ごとの期間をお示しします。範囲を分割して段階的に進めることで、最初の成果を早期に確認できます。

Q2. 費用はどのように見積もりますか？

LOC（ソースコード行数）をもとに、LOC → 人月 → 予算の順で算出します。デッドコードは見積もり対象から除外します。予算に応じて移行範囲を分割し、優先順位をつけることも可能です。

Q3. 旧システムがすでに動かない場合は、どう進めますか？

旧システムを動かせない場合は、旧システムから正解を記録できません。その場合はリビルド型を検討し、お客様が確認した新しい仕様書を正解とします。作業の順序やテストの重点も変わるため、アセスメントの段階で方式を見極めます。

Q4. 単体テストのカバレッジを100%にできますか？

テストの100%パスは必須であり、実現可能です。一方、コードカバレッジ100%は、マイグレーションでは誤った目標になりえます。社内資料のために100%の数値が必要な場合は、自動生成コードなどの除外リストを明示し、残り3つの品質軸を併記してご報告します。

Q5. 生成AIだけでマイグレーションは完結しますか？

完結しません。移行スコープの決定、アーキテクチャ設計、差異の最終判定は人が担います。AIは解析・変換・テスト生成を速くしますが、責任を伴う判断はできません。

Q6. 小さな範囲から始められますか？

はい。小さく始めることは、HBLABが推奨するマイグレーションの進め方です。無償AI診断は、ZIPファイル1つ（50MBまで）で、一部のモジュールだけでも受けられます。その後、小規模なPoCで効果を確認してから、段階的に本格移行へ進められます。

まとめ

マイグレーションの進め方は、アセスメント → AI支援による移行 → テストの3段階で考えると、判断と責任の所在が明確になります。

• アセスメントでは、LOC・依存関係・デッドコードを数字で把握し、シームで「成功の定義」を合意します。
• AI支援の移行では、AIが実行し、人が決定します。変換は再現可能なスクリプトで行い、同じAIにテストを作らせません。
• テストでは、旧システムから記録したゴールデンデータを正解とし、4つの品質軸と差異分類ルールで品質を証明します。

そして、段階の間に置く4つの関門が、工程のつなぎ目で起きる失敗を防ぎます。

現状を数字で把握することが、自社に合ったマイグレーションの進め方を描く第一歩です。