移行後の業務ロジック検証｜業務ルール台帳で進める5ステップ

移行後の業務ロジック検証とは、新システムが旧システムと同じ「業務上の正しさ」を保っているかを、業務ルール単位で確かめる作業です。対象は、金額計算や端数処理、承認条件の判定、受注から請求までの状態遷移、締め日や月末処理のタイミングなど、業務の結果を左右するロジックです。

マイグレーションでは、現新比較テストで新旧の出力を突き合わせるのが一般的です。しかし、出力の一致が示すのは「用意した入力について同じ結果が出た」ことだけです。テストデータにない例外ケースや、SQL・ジョブ順序・運用の手作業に埋もれたルールは、比較の対象にすら入りません。

そこで本記事では、業務ルールを抽出して台帳化し、テストケースに変え、業務部門の確認と本番監視まで含めて検証する方法を解説します。テスト全体の設計（ゴールデンデータ、シーム、4つの品質軸）については、ピラー記事「マイグレーションテストの進め方」をあわせてご覧ください。

1. 移行後の業務ロジック検証とは？「動く」と「業務として正しい」は別物

システム移行のテストでは、画面が開く、バッチが正常終了する、といった「動くこと」の確認に工数が集中しがちです。しかし利用部門にとって重要なのは、請求金額や在庫数、承認結果が以前と同じく正しいかどうかです。まずは、検証の対象となる業務ロジックの範囲を整理しましょう。

1-1. 業務ロジック（ビジネスロジック）とは：4つの類型

業務ロジック（ビジネスロジック）とは、業務上のルールをシステムの処理として実装した部分です。移行で検証すべきものは、大きく次の4類型に分けられます。

• 計算ロジック：消費税の計算と端数処理、利息・手数料、単価×数量の丸め、和暦変換など
• 判定ロジック：与信限度の判定、金額に応じた承認ルート、割引条件の適用など
• 状態遷移ロジック：受注→出荷→請求→入金、取消・返品など業務ステータスの流れ
• タイミングロジック：締め日、月末営業日、年度末処理、バッチの実行順序など

4類型を意識すると、「どのテストで何を確かめたか」を業務の言葉で説明できるようになります。では、なぜ現新比較だけでは足りないのでしょうか。

1-2. なぜ現新比較だけでは業務ロジックを保証しきれないのか

現新比較テストは移行テストの中核ですが、業務ロジック検証の観点では次の3つの限界があります。

1. データにないケースは検証されない：本番データは通常ケースに偏ります。閏年の2月29日、年度をまたぐ取引、上限ちょうどの金額といった境界ケースは、ほとんど含まれていません。
2. コードの外にあるロジックは比較されない：ジョブの実行順序、コード値マスタ、運用担当者の手作業による補正などは、プログラムの出力比較では捉えにくい領域です。
3. 「一致」は「正しい」を意味しない：旧システムのバグも、新システムで再現すれば一致します。一致したことと、業務として正しいことは別の問題です。

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド」も、「現行踏襲」の「現行」が何を指すかについて、ユーザ企業とベンダ企業の間でギャップが生じうると指摘しています。比較の前に、守るべき業務ルールを言葉にしておく必要があるのです。

テストがすべてPASSしても安心できない理由は、「テストが「PASS」でも品質を証明できない理由」で詳しく解説しています。

1-3. 業務ロジック検証・現新比較テスト・リグレッションテストの違い

3つは対立するものではなく、答える問いが異なります。

項目	業務ロジック検証	現新比較テスト	リグレッションテスト（移行）
答える問い	業務として正しいか	新旧の出力が一致するか	移行で挙動が変わっていないか
検証の単位	業務ルール	画面・帳票・ファイル	機能・シーム（接合点）
正解の出どころ	業務ルール台帳＋旧システム	旧システムの出力	旧システムの挙動
判定に関わる人	業務部門＋情シス	情シス・ベンダ	情シス・ベンダ

新旧の挙動を比較する手順は、「移行のリグレッションテストの進め方」で解説しています。本記事では、その前提となる「業務ルール」をどう見つけ、どう検証するかに絞って説明します。

2. 業務ロジックはどこに隠れているか：移行で壊れやすい7つの場所

業務ロジックの検証漏れの多くは、「ロジックがそこにあると知らなかった」ことから生まれます。長年運用されたシステムでは、ルールがソースコードの外にも分散しています。ここでは3つの層に分けて、壊れやすい7つの場所を見ていきます。

2-1. コードの中：条件分岐と計算式

1つ目は、COBOLやPL/I、VB、Javaなどのソースコードに書かれた条件分岐と計算式です。移行で特に注意すべきなのは、言語やデータ型の違いによる計算結果のずれです。

• COBOLのパック10進数（COMP-3）から浮動小数点型への変換による誤差
• ROUNDED指定の有無による、四捨五入と切り捨ての違い
• 桁あふれ時の扱い（エラーにするか、上位桁を切り捨てるか）

数円の差であっても、請求や会計では重大な問題になります。

2-2. コードの外：SQL・ストアドプロシージャ・ジョブ順序・マスタ

2つ目から4つ目は、プログラム本体の外にあるロジックです。

• SQL・ストアドプロシージャ・トリガー：在庫引当や集計のルールが、データベース側に実装されているケースは珍しくありません。ORDER BYのない検索結果の並び順に、暗黙的に依存していることもあります。
• ジョブの実行順序：「売上計上バッチの後に在庫締めバッチを流す」といった順序そのものが業務ルールです。JCLやジョブ管理ツールの定義を移すときに崩れやすい部分です。
• コード値マスタ・パラメータテーブル：税率や手数料率、区分コードの意味をテーブルで管理している場合、データ移行の不備がそのままロジックの不具合になります。

AWSの規範ガイダンスでも、データベースにあるビジネスロジックをアプリケーション層へ移す際は、新旧の実装を並行して実行し、結果を比較して機能の同等性を検証することが推奨されています（ビジネスロジックのアプリケーションレイヤーへの移行に関するFAQ）。

2-3. システムの外：帳票・画面チェック・運用でカバーしている手作業

5つ目から7つ目は、システムの外側にあるロジックです。

• 帳票・CSVのレイアウト：桁数、全角・半角、ゼロ埋めなど、取引先のシステムが前提にしている仕様
• 画面の入力チェック：入力時点で弾いていたため、後続処理に想定外の値が来ない前提になっているもの
• 運用でカバーしている手作業：毎月末に経理担当者が端数を手で補正している、といった暗黙のルール

最後の手作業は、コードをどれだけ解析しても見つかりません。属人化が進んだシステムほど、この層が厚くなります。背景は「システムのブラックボックス化」の記事で詳しく解説しています。

3. 検証の出発点：業務ルールを抽出し「業務ルール台帳」を作る

業務ロジックの在りかが見えたら、次はそれを検証できる形に整理します。中心となる成果物が「業務ルール台帳」です。台帳があれば、テスト・業務部門の確認・カットオーバー判定を、すべて同じルールIDで追跡できます。

3-1. 業務ルール抽出の3つの情報源：ソースコード・実データ・業務担当者

業務ルールは、1つの情報源だけでは抽出しきれません。次の3つを組み合わせるのが基本です。

1. ソースコード：静的解析とAIで条件分岐・計算式を洗い出し、ルール候補として一覧化します。
2. 実データ：値の分布や区分コードの出現頻度を調べ、使われていない分岐や想定外の値を見つけます。
3. 業務担当者へのヒアリング：例外処理や運用上の手作業など、コードにもデータにも現れないルールを補います。

設計書が残っていないシステムでは、AIを使ってソースコードから仕様を復元するアプローチが有効です。具体的な手順は「AIリバースエンジニアリングによる設計書の復元」をご覧ください。

3-2. 業務ルール台帳に書くべき項目【サンプル付き】

台帳は、Excelやスプレッドシートで十分に運用できます。最低限、次の項目をそろえましょう。

ルールID	業務領域	条件	結果	根拠	業務オーナー	重要度	移行方針
BR-INV-012	請求	消費税額に1円未満の端数が出た場合	請求書単位・税率ごとに切り捨て	プログラムINV300／経理規程	経理部	高	守る
BR-ORD-034	受注	与信残高を超える受注	保留にして承認待ち	ストアドSP_ORD_CHK	営業管理部	高	守る
BR-SHP-008	出荷	15時以降の受注	翌営業日に出荷	ジョブJOB_SHP01の起動時刻	物流部	中	変える（16時に変更）

※表の内容は説明用のサンプルです。

ポイントは「根拠」と「業務オーナー」の列です。根拠があればルールの正しさを後から確認でき、オーナーがいれば判定を誰に仰ぐかが明確になります。

3-3. ルールごとに「守る・変える・捨てる」を合意する

台帳ができたら、ルールごとに移行方針を決めます。

• 守る：新システムでも同じ結果を出すべきルール
• 変える：法改正や業務改善に合わせて、意図的に変更するルール
• 捨てる：すでに使われていない機能・分岐

「変える」ルールや旧システムの既知のバグは、テストで「差異あり」が正しい結果になります。合意内容は台帳に記録し、後から「なぜ違うのか」と問われたときに答えられるようにしておきましょう。

4. 業務ルールをテストケースに変える4つの設計技法

台帳のルールは、そのままではテストになりません。ここでは、1-1で整理した4類型ごとに、テストケースへの変換方法を紹介します。

4-1. 計算ロジック：境界値と端数処理

計算ロジックでは、境界値と端数処理を重点的にテストします。

• 消費税：税率の切り替わり日、1円未満の端数が出る金額、軽減税率の混在
• 利息・手数料：日割り計算、閏年（366日）の扱い、上限金額ちょうど
• 和暦：元号の切り替わり日（例：2019年4月30日と5月1日）
• 桁数：最大桁の金額、マイナス値、ゼロ

本番データにはこうしたケースがほとんど含まれません。合成データとして意図的に作る必要があります。

4-2. 判定ロジック：デシジョンテーブルで条件の組み合わせを網羅する

複数の条件で結果が決まる判定ロジックには、デシジョンテーブルが有効です。条件と結果を表にすることで、組み合わせの漏れが一目でわかります。

例えば「顧客ランク×注文金額×販売チャネル」で割引率が決まる場合、条件の組み合わせをすべて列挙し、組み合わせごとに期待結果を定義します。旧システムのコードから組み合わせを抽出すると、業務担当者も知らなかった条件が見つかることもあります。

4-3. 状態遷移：受注・出荷・請求・取消など業務ステータスの流れ

業務ステータスを持つデータは、状態遷移の観点でテストします。正常な流れだけでなく、「起きてはいけない遷移」も確認するのがポイントです。

• 取消済みの受注に対して、請求が発行されないか
• 出荷後の受注を、数量変更できないようになっているか
• 一部入金の状態から返品したとき、残高が正しく計算されるか

4-4. 時間依存ロジック：締め日・月末営業日・年度末・バッチの実行順

最後は、時間に依存するロジックです。移行直後には発生しない処理が多いため、テスト日付を意図的に設定して確認します。

• 締め日（20日締め、月末締めなど）と、締め日が休日の場合の扱い
• 月末営業日、年末年始、祝日カレンダーの反映
• 年度末の繰越処理、年次バッチ
• 前のジョブが遅延・異常終了したときの、後続ジョブの挙動

4-5. ルールIDとテストIDを双方向に紐づける（トレーサビリティ）

テストケースを作ったら、ルールIDとテストIDを双方向に紐づけます。

• テストのないルールは、未検証のリスクが残っていることを意味します。
• ルールに紐づかないテストは目的が不明確で、保守コストだけが増えていきます。

この紐づけは、ピラー記事で解説している「ゴールデンデータの網羅性評価」の業務ルール軸とも直結します。「テストは十分か」という問いに、ルールの網羅率で答えられるようになります。

5. 移行後の業務ロジック検証の進め方：5ステップ

ここまでの内容を、プロジェクトの流れに沿って5つのステップにまとめます。各ステップに完了条件を設け、満たすまで次に進まないことが重要です。

Step1. 業務ルールを抽出し、台帳化する

ソースコード・実データ・ヒアリングから業務ルールを抽出し、台帳にまとめます。

完了条件：主要な業務領域ごとにルールが一覧化され、根拠と業務オーナーが記入されている。

Step2. 業務影響度でルールに優先順位をつける

すべてのルールを同じ深さでテストするのは現実的ではありません。金額・法令・顧客への影響を軸に、重要度を決めます。

完了条件：重要度「高」のルールについて、テスト方針と担当者が決まっている。

Step3. 旧システムで正解を確定し、テストを全件パスさせる

ルールごとのテストケースを旧システムで実行し、期待結果を確定させます。旧システムで100%パスしないテストは、ルールの理解が誤っている可能性があります。正解データの作り方は、「マイグレーションテストの進め方」のゴールデンデータの章で解説しています。

完了条件：旧システム上で、テストが全件パスしている。

Step4. 業務シナリオテストと帳票突合を業務部門と実施する

新システムでテストを実行したうえで、業務部門と一緒に業務シナリオテストを行います。請求書や月次帳票は、新旧を並べて金額・件数を突き合わせます。

完了条件：重要度「高」のルールについて、業務オーナーの確認と承認記録がある。

Step5. 月次・年次の締めを含む並行稼働で最終判定する

最後に新旧システムを並行稼働させ、最低でも1回の月次締めを通して結果を比較します。年次処理が重要な業務では、年度末を想定したリハーサルも計画しましょう。

完了条件：説明できない差異がゼロで、カットオーバー判定会議で承認されている。

工程全体の中での位置づけは、「マイグレーションの進め方」もご参照ください。

6. 業務部門をどう巻き込むか：情シスだけでは「正しい」と判断できない

業務ロジック検証の最終的な判定者は、情報システム部門ではなく業務部門です。とはいえ、日常業務で忙しい業務部門にテスト作業そのものを任せるのは現実的ではありません。役割分担の設計がカギになります。

6-1. 業務部門に確認してもらうこと・任せなくてよいこと

業務部門に依頼するのは、「業務として正しいか」の判断に限定します。

業務部門に確認してもらうこと	情シス・ベンダが担うこと
重要度「高」の業務ルールの妥当性	テストケースの作成・実行
「変える」ルールの変更内容	フォーマット・並び順など技術的な差異の解消
請求書・月次帳票などの最終出力	差異の一次分類と原因調査
許容する差異の承認	テスト結果の集計・レポート作成

Microsoftの「Cloud Adoption Framework」でも、移行時にはビジネスユーザーと受け入れテストを実施し、ワークロードがビジネスの期待を満たしていることを確認するよう推奨されています。

6-2. 1日・1か月・1年の業務カレンダーで業務シナリオを作る

業務シナリオは、機能単位ではなく業務カレンダー単位で作ると漏れを防げます。

• 1日：受注入力→在庫引当→出荷指示→日次集計
• 1か月：締め処理→請求書発行→入金消込→月次帳票
• 1年：決算処理→繰越→年次帳票→税率・マスタの年次更新

業務担当者にとって馴染みのある流れなので、確認の負担も小さくなります。

6-3. 合格判定と承認記録：誰が「この差異は許容」と決めたかを残す

差異を許容する場合は、必ず承認者と理由を記録します。カットオーバー後に問い合わせが来たとき、記録がなければ「誰がOKを出したのか」が分からなくなります。承認記録は、稟議や内部監査の資料としてもそのまま活用できます。

7. カットオーバー後も続く業務ロジック検証：本番での監視とリコンサイル

業務ロジック検証は、カットオーバーで終わりではありません。本番稼働後に初めて実行される処理があるからです。

7-1. 初回の月次締め・年次処理は「第2のカットオーバー」

月次締めや年次処理は、本番稼働から数週間〜数か月後に初めて実行されます。並行稼働で確認していても、本番のデータ量や実際の日付で初めて表面化する不具合があります。初回の締め処理は、カットオーバーと同じ体制で臨むことをおすすめします。

7-2. 件数・金額・残高・業務KPIを新旧でリコンサイルする

本番稼働後の一定期間は、次の指標を定期的に突き合わせます（リコンサイル）。

• 取引件数、売上・請求金額の合計
• 在庫数量、売掛金・買掛金の残高
• 業務KPI（受注処理時間、出荷率など）の急な変化

旧システムを参照用に残しておけば、異常値が出たときに原因の切り分けが早くなります。

7-3. 切り戻し基準と、旧ロジックへ戻せる仕組みを用意する

重大な差異が見つかったときに備えて、切り戻しの判断基準を事前に決めておきます。前述のAWSのガイダンスでも、機能フラグでデプロイを制御し、必要に応じて元のロジックに戻せるようにしておくことが推奨されています。「どの差異が出たら戻すのか」を、業務部門と合意しておきましょう。

8. 旧システムが動かせない場合の業務ロジック検証

ハードウェアの保守切れやライセンスの問題で、旧システムを動かせないケースもあります。その場合は、次の方法で「正解」を補います。

• 過去の出力を正解データにする：保管されている帳票、CSV、ログを、入力と結果のペアとして再利用します。
• 業務担当者が判定する：重要なルールは、業務担当者が期待結果を定義します。
• ソースコードから仕様を復元する：リバースエンジニアリングで業務ルールを文書化し、台帳の根拠にします。
• リスクを明示して受け入れる：検証できない範囲は、承認者を明記したうえでリスクとして受容します。

旧システムを動かせるかどうかは、移行前のアセスメントで確認しておくべき重要な項目です。評価の観点は「レガシーシステムアセスメント」で解説しています。

9. AIは業務ロジック検証のどこまでを担えるか

生成AIを活用すれば、業務ロジック検証の工数は大きく減らせます。ただし、AIに任せてよい作業と、人が判断すべき作業ははっきり分かれます。

9-1. AIに任せられること

• ソースコードからの業務ルール候補の抽出と、台帳形式への整理
• 条件分岐のデシジョンテーブル化
• 境界値・異常系のテストケース生成
• ルールIDとテストIDの紐づけ案の作成

9-2. 人が判断すべきこと

• 抽出したルールが、業務として正しいかどうか
• ルールの重要度と業務リスクの評価
• 許容する差異の承認

特に注意したいのは、コード変換とテストの正解作成を同じAIに任せないことです。同じAIが同じ誤解をすれば、テストは誤ったまま「合格」します。AI活用時の注意点は、「生成AIマイグレーションのハルシネーション対策」や「マイグレーションのAI活用と品質担保」もご覧ください。

10. 移行後の業務ロジック検証チェックリスト（15項目）

本記事の内容を、15項目のチェックリストにまとめました。社内の稟議や、関係部門との合意形成にもご活用ください。

移行前

• ☐ 業務ルール台帳を作成し、根拠と業務オーナーを記入した
• ☐ コードの外（SQL・ジョブ順序・マスタ・手作業）のルールも洗い出した
• ☐ ルールごとに「守る・変える・捨てる」を合意した
• ☐ 業務影響度で重要度を決めた
• ☐ 旧システムを動かせるかを確認した

テスト中

• ☐ 計算ロジックの境界値・端数処理を、合成データでテストした
• ☐ 判定ロジックを、デシジョンテーブルで網羅した
• ☐ 起きてはいけない状態遷移もテストした
• ☐ 締め日・年度末など、時間依存の処理をテストした
• ☐ ルールIDとテストIDを双方向に紐づけた

カットオーバー前後

• ☐ 業務部門の承認記録を残した
• ☐ 月次締めを含む並行稼働で最終判定した
• ☐ 初回の月次締め・年次処理の体制を決めた
• ☐ 件数・金額・残高のリコンサイルを計画した
• ☐ 切り戻し基準を業務部門と合意した

11. HBLABの業務ロジック検証支援：Migurei AI Inside

HBLABは、AIを組み込んだモダナイゼーションソリューション「Migurei AI Inside」で、業務ロジックを守るマイグレーションを支援しています。

• AIによる業務ルールの抽出：ソースコードから業務ルール候補を抽出し、エンジニアが根拠を確認したうえで台帳化します。
• 工程を一貫して支援：技術調査・評価・移行戦略・業務仕様の文書化・コード変換・単体テスト・結合テストまでの7工程を、一貫して支援します。
• 品質とセキュリティの体制：ISTQB®ゴールドパートナー、CMMIレベル3、ISO/IEC 27001:2022認証を取得した体制でプロジェクトを進めます。

サービスの詳細は「マイグレーション・モダナイゼーションサービス」や、「Modernization Solution（Migurei AI Inside）提供開始のお知らせ」をご覧ください。

12. 移行後の業務ロジック検証に関するよくある質問

Q1. 業務ロジック検証と現新比較テストは何が違いますか？

現新比較テストは、新旧の出力が一致するかを確かめる手法です。業務ロジック検証は、業務として正しいかを業務ルール単位で確かめる取り組みで、現新比較はその手段の1つです。データにないケースやコードの外にあるルールは、現新比較だけでは検証できません。

Q2. 設計書がなくても業務ルールは抽出できますか？

可能です。ソースコードの静的解析とAIで業務ルール候補を抽出し、実データの分析と業務担当者へのヒアリングで補完します。設計書がないシステムほど、台帳化の効果は大きくなります。

Q3. 業務ルールはどこまで洗い出せば十分ですか？

すべてを同じ深さで洗い出す必要はありません。金額・法令・顧客に影響する重要度「高」のルールは漏れなく洗い出し、それ以外はリスクに応じて範囲を決めます。検証できない範囲は、承認者を明記してリスクとして受容します。

Q4. 旧システムの計算ミスも新システムで再現すべきですか？

原則として、移行では旧システムの挙動を維持し、修正は別リリースで行うのが安全です。ただし、法令違反につながるものは業務部門と合意したうえで「変える」ルールとして扱い、差異を記録します。

Q5. 業務部門にはどれくらいの工数をお願いすべきですか？

システムの規模によって異なりますが、業務部門の役割を「重要ルールの確認」「最終出力の確認」「差異の承認」に絞れば、負担は大きく抑えられます。テスト作業そのものは、情シス・ベンダ側で担うのが一般的です。

まとめ

移行後の業務ロジック検証のポイントは、次の4つです。

1. 現新比較の「一致」は「正しい」ではない。データにないケースとコードの外のルールに注意する
2. 出発点は業務ルール台帳。根拠と業務オーナーを明確にする
3. 4つの設計技法でルールをテストに変え、ルールIDとテストIDを紐づける
4. 業務部門の承認と、カットオーバー後の監視・リコンサイルまでを検証範囲に含める

業務ルールを起点に計画すれば、「何を守り、何を確かめたか」を説明できる移行になります。ルールの抽出から台帳化、テスト設計、本番監視までを一貫して進めることが、移行後の業務ロジック検証を成功させる近道です。