新旧の結果が一致すれば移行成功か：業務を守る移行テストの設計

レガシーシステムを刷新するとき、現行システムと新システムに同じデータを与え、結果を比較する方法は有効です。仕様書が十分でない場合でも、実際に動いている処理を確認材料にできます。

しかし、出力の一致だけで移行を判断すると、現行の不具合を引き継いだり、帳票に出ない更新の誤りを見落としたりします。移行テストでは、そのまま引き継ぐ振る舞いと、承認を得て変更する振る舞いを切り分けたうえで、「この業務を続けられる」と判断するための証拠を集めます。

差異を発見し、その理由を説明できることが新旧比較の価値になる。

期待する結果を誰が決めるか

テストを始める前に、何を正しい結果とするかを整理します。現行の出力をそのまま期待値にできる処理もあれば、業務ルールの確認が必要な処理もあります。

対象	期待値の決め方	判定で残す記録
そのまま継承する業務	現行結果と業務担当者の確認を基にする	比較条件と一致の証拠
仕様を変更する業務	承認済みの新しい業務ルールを基にする	変更理由と期待される差異
現行の不具合を修正する業務	正しいルールを改めて確認する	旧結果の問題と修正後の基準
意味が不明な処理	調査して判断を保留する	未解決事項と解決責任者

仮の例として、旧システムが明細ごとに金額を丸め、新システムが合計後に丸める場合を考えます。差額が出たとき、計算ミスなのか、承認された仕様変更なのかは比較ツールだけでは判断できません。計算単位、端数処理、過去データへの適用範囲を業務側と確認し、期待値を定義します。

新旧の結果が一致した場合でも、両方が同じ誤りを含む可能性は残ります。重要な計算や状態遷移には、現行システムとは別に業務ルールから求めた期待値を用意すると、現行の出力だけに頼らずに済みます。

比較する条件をそろえ、差異を消しすぎない

比較テストの入力は、取引データだけではありません。マスターの状態、業務日、設定値、実行権限、外部サービスの応答も結果に影響します。開始時点のデータを保存し、新旧それぞれを同じ条件から実行できるようにします。

実行時刻や自動採番は、正常に動いていても一致しないことがあります。その場合は、値の意味を保ったまま対応付けるか、比較対象から外します。ただし、どこまで除外するかは明示しておく必要があります。たとえば「日時をすべて無視する」とすると、締めの判定に使う業務日時の差異まで見逃すおそれがあります。

並び順をそろえる、空白を統一するといった加工も、利用者にとって意味のない差異を消す場合に限ります。比較しやすくする処理そのものをレビュー対象にし、「何を比較しなくなったか」を記録します。

画面や帳票の先まで確認する

注文が登録できたとしても、在庫引当、後続の請求、外部への連携が正しいとは限りません。入力から業務の完了までを一つのシナリオとし、途中で変わるデータや状態を確認します。

GoogleのSRE資料でも、単体、結合、システムの各テストを区別し、システムテストの中で性能や回帰を扱っています。小さな処理の正しさを確かめるテストと、組み合わせた全体の振る舞いを確かめるテストでは、役割が異なります。

Google SRE：信頼性のためのテスト(https://sre.google/sre-book/testing-reliability/)

移行では、次のような観点を業務シナリオへ組み込みます。

観点	確認する場面	主な証拠
正常処理	登録から締め・照会まで	出力、更新データ、状態遷移
境界・例外	締め時刻の前後、取消、差し戻し	判定結果と後続処理の扱い
権限	他部門データの参照、承認者の変更	許可・拒否と監査記録
同時処理	同じ在庫や伝票を同時に更新	競合時の結果と整合性
再実行	通信断や途中停止の後にやり直す	重複の有無と再開位置
外部連携	応答遅延、エラー、二重受信	送受信履歴と回復結果

すべての組み合わせを試すことはできません。業務への影響が大きいもの、実装の変更が大きいもの、複数のシステムをまたぐものから優先して確認します。月次や年次の処理は、利用頻度が低いという理由だけで後回しにせず、実行時に失敗した場合の影響を基準に判断します。

実データの特徴を残し、外部への影響を制御する

本番データのコピーは、実際の値の分布や例外を調べるのに役立ちます。ただし、そのまま使うことが適切とは限りません。利用条件を確認し、必要な情報を加工したうえで、参照関係や桁数、重複、偏りなど、試験に必要な特徴を保ちます。

コピーに含まれない境界値や障害条件は、意図して作る必要があります。通常日のデータだけで、月末処理や大量集中時の品質を説明することはできません。

また、テストの実行によって実際のメール、出荷依頼、外部への確定データが送られないよう、接続先と認証情報を分離します。外部連携は検証環境や代替応答で条件を制御し、実際の接続仕様については、相手先と調整して結合確認を行います。画面上の結果だけでなく、「送るべきものだけを送ったか」も検証対象です。

性能と復旧を、業務の時間制約で評価する

平均応答時間が改善しても、繁忙時の遅延や夜間バッチの時間超過が残れば、業務に支障が出ます。オンライン処理とバッチが重なる時間帯、データ量の増加、外部連携の待ち時間を含め、業務で許される時間内に終わるかを確認します。

復旧については、停止から再起動するまでの時間だけでなく、その後のデータ整合性まで確かめます。具体的には、処理済みの明細を再度計上しないか、未処理の明細が残らないか、担当者が状況を判別できるかを確認します。復旧手順を実行し、その結果を照合することで、手順書の実用性も確認できます。

合格率よりも、重要な未確認事項を見えるようにする

「テストの99％が成功」と報告されても、残りに締め処理や二重登録の問題があれば移行判断は変わります。報告では、総件数に加えて、重要シナリオの完了状況、未解決の障害、未実施の試験、条件付きで受け入れる差異を示します。

合格基準は、結果を見てから都合よく変えることがないよう、テストの実施前に合意しておきます。例外を受け入れる場合は、業務への影響、暫定対応、解消期限、判断者を記録します。不具合を修正したときは、その箇所だけでなく、影響を受ける関連処理も再確認します。

株式会社Managetechが移行テストで重視するのは、「何が確かめられ、何が残っているか」を関係者が共有できることです。主要な業務シナリオと受け入れ基準を早い段階で定めれば、仕様調査、設計、データ移行も同じ目標に向けて進められます。