SAP S/4HANAコンバージョンのテスト戦略：移行前後の検証を実務で設計する方法

SAP S/4HANAへのコンバージョンでは、移行処理が完了してシステムが起動することだけでは業務継続を確認できません。会計伝票、購買、在庫、販売、製造、帳票、外部連携などを、移行前後で同じ業務結果になるかという観点から検証する必要があります。特に重要なのは、テストを本番稼働直前にまとめず、準備段階から対象業務と合格条件を固定することです。

この記事では、オンプレミスのSAP ERPからSAP S/4HANAへ移行するプロジェクトを想定し、テスト計画の分解、テストデータの準備、回帰テスト、移行リハーサル、障害管理、カットオーバー判定までを実務の順序で整理します。

01コンバージョンテストの全体像

コンバージョンのテストは、単一のテスト工程ではなく、技術確認と業務確認を重ねる構造で設計します。まず移行基盤とアドオンの稼働を確認し、その後に業務プロセス、データ、権限、帳票、外部連携を確認します。最後に、実際のカットオーバー手順を含むリハーサルで所要時間と復旧手順を検証します。

プロジェクトの対象範囲を整理するときは、全体計画をまとめたSAP S/4HANA移行の全体像と、工程ごとの作業を確認できるSAP S/4HANA移行プロジェクトのフェーズを参照し、テスト工程だけを独立させずに計画へ組み込みます。

各テストには、担当者、前提データ、実行手順、期待結果、証跡、判定者を割り当てます。単に「正常終了」と記録するのではなく、業務上の期待結果を数値または画面・帳票の証跡で残すと、移行前後の比較が容易になります。

02移行前に固定するテストベースライン

移行前のシステムで、比較対象となる業務結果を取得します。これをテストベースラインとして、同じ入力条件を移行後システムで再現します。ベースラインには、伝票番号だけでなく、会社コード、プラント、販売組織、購買組織、勘定科目、税コード、通貨、換算レートなど、結果に影響する条件を含めます。

最初に業務プロセスを一覧化し、次の観点で優先度を付けます。

• 月次・四半期・年次決算に直結する処理
• 売上、購買、在庫、製造、支払に関わる高頻度処理
• 外部システムとの送受信を伴う処理
• カスタムコードやアドオンに依存する処理
• 移行後にデータ構造や業務画面が変わる処理
• 障害発生時の影響範囲が大きい処理

業務一覧を作成する際は、SAP S/4HANA移行のSUM概要で技術的な移行工程を確認し、業務テストの開始条件と切り分けます。SUMの処理完了、後処理完了、システム利用可能という状態は、業務プロセスの合格を意味しないためです。

ベースラインとして取得する代表例は、総勘定元帳残高、補助元帳残高、未消込明細、在庫数量と評価額、受注残、発注残、納品残、請求残、固定資産残高、オープンアイテム、主要帳票の出力結果です。集計値だけでなく、代表明細を抽出して明細レベルでも比較します。

03テストデータとシナリオの設計

テストシナリオは、正常系だけでなく、例外系と境界値を含めて作成します。例えば購買では、通常発注、分納、返品、価格差異、入庫先行、請求書先行、税区分変更を分けて確認します。販売では、受注、出荷、請求、返品、値引、与信エラー、出荷ブロックを一連の流れとして検証します。

データ準備では、次の3種類を分けると管理しやすくなります。

1. 代表業務データ：日常的に発生する標準的な取引
2. 高リスクデータ：大量明細、複数通貨、複雑な税、長期未処理などを含む取引
3. 例外データ：エラー、取消、返品、差戻し、再処理を確認するための取引

テストデータには所有者と有効期限を設定します。本番データを複製する場合は、アクセス権、個人情報、取引先情報、マスキング方針を事前に決めます。データ作成者が不明なままでは、失敗したシナリオを再現できません。

回帰テストでは、全取引を同じ深さで繰り返す必要はありません。高リスク業務は毎回実行し、低リスク業務は変更影響と過去の障害実績に応じてサンプリングします。回帰対象の判断には、SAP S/4HANAカスタムコード移行の確認ポイントを使い、独自プログラム、拡張、バリアント、ジョブ、帳票を洗い出します。

04機能テストと統合テストの進め方

機能テストは、担当モジュール単位で完結させず、業務の開始から会計・在庫・物流の結果まで追跡します。例えば受注から請求までを確認する場合、販売伝票の状態だけでなく、出庫、売上計上、売掛金、税、収益性分析などの結果を関連づけて確認します。

購買では、購買依頼、発注、入庫、請求書照合、債務計上、支払対象化を確認します。在庫では、入出庫、移動、棚卸、評価、ロットやシリアル管理を確認します。製造では、所要量計画、製造指図、払出、作業実績、入庫、原価計算のつながりを確認します。担当領域をまたぐシナリオには、業務プロセスの責任者を置きます。

統合テストでは、連携が「送信できた」だけで合格にしません。送信元で作成したデータが受信側で正しく登録され、エラー時に再送でき、重複登録を防げることまで確認します。IDoc、RFC、ファイル、API、ミドルウェア連携は、正常、遅延、項目欠落、コード変換エラー、再送、順序逆転をテストします。

外部連携のテストでは、送受信時刻、件数、キー項目、ステータス、エラーログを記録します。連携先がテスト環境を提供できない場合は、スタブや疑似応答を用意し、本番切替前に実接続の疎通試験を別途実施します。

05移行データの検証方法

データ検証は、件数、金額、数量、キー、状態、参照関係の順に階層化します。件数が一致していても、会社コードや通貨が誤っていれば業務結果は一致しません。反対に、技術的な内部番号が変わっていても、業務上の参照関係と結果が保たれていれば、対応表で追跡できる場合があります。

代表的な検証単位は次のとおりです。

• マスタ：件数、必須項目、重複、組織割当、状態
• 残高：勘定科目、会社コード、通貨、期間、借方・貸方
• 未消込明細：取引先、金額、期日、消込状態
• 在庫：品目、プラント、保管場所、数量、評価額
• 伝票：ヘッダと明細の対応、参照伝票、ステータス
• ジョブ・帳票：実行結果、出力件数、合計値、配信先

移行前後の比較では、集計SQLや抽出ファイルの結果を保存し、差分を自動判定できる形にします。差分が出た場合は、移行漏れ、変換ルール、丸め、通貨換算、期間条件、抽出時点の違いに分類します。差分を手作業で修正するのではなく、原因と再発防止策を記録します。

移行対象と移行対象外を明確にすることも重要です。履歴を全量移行しない場合は、参照方法、残高への反映、旧システムの保存期間、監査証跡をテストケースに含めます。データ移行方式の整理にはSAP S/4HANAデータ移行方式の比較も役立ちます。

06回帰テストの優先順位付け

回帰テストは、変更された箇所だけを確認する作業ではありません。共通マスタ、価格決定、税、勘定設定、権限、ジョブ、帳票、連携基盤の変更は、複数業務へ影響するため、横断的なシナリオを組み込みます。

優先順位は、影響度と発生頻度に加えて、検出の難しさで決めます。日常処理でも会計結果に影響するもの、月次処理でしか発見できないもの、外部連携の失敗で復旧に時間がかかるものは、早い段階から繰り返し確認します。

合格基準には、機能結果だけでなく性能と運用条件も含めます。例えば、日次ジョブが予定時間内に終わること、帳票が所定時間内に出力されること、同時利用時に業務画面が操作可能であること、エラー監視で異常を検出できることを明文化します。

07移行リハーサルとカットオーバー判定

移行リハーサルでは、実際の本番手順と同じ順序で作業します。停止告知、最終バックアップ、データ凍結、移行処理、後処理、技術確認、業務確認、連携再開、利用者確認までを時間計測します。

リハーサルの成果物には、開始・終了時刻、担当者、実行ログ、エラー、判断ポイント、所要時間、未解決事項を含めます。計画時間を超えた作業は、担当者の追加、並列化、事前準備、対象範囲の見直しによって改善します。

カットオーバー判定会では、次の項目を個別に承認します。

• 技術テストの重大障害が解決または受容されている
• 主要業務シナリオが合格している
• 残高、在庫、未処理伝票の照合が完了している
• 外部連携と定期ジョブが再開可能である
• 権限、監視、バックアップ、運用手順が確認済みである
• 切り戻し条件と意思決定者が明確である

「テスト完了」をケース消化率だけで判断せず、業務リスクが許容範囲に収まっているかで判断します。未実施ケース、暫定回避策、既知の制限は、稼働後の対応期限と責任者を明記します。

08障害管理と再テスト

障害票には、発生環境、再現手順、入力データ、期待結果、実際の結果、ログ、影響範囲、優先度、担当者を記録します。スクリーンショットだけでなく、伝票番号、実行時刻、ジョブ名、連携メッセージIDなど、再現に必要な識別情報を残します。

優先度は、単なる画面エラーか、会計・在庫・顧客・仕入先・連携に影響するかで分けます。原因が未確定のまま修正済みにせず、修正内容、再テスト条件、再発防止テストを関連づけます。

再テストでは、修正されたケースに加えて、同じ共通設定を使う周辺ケースを実行します。価格条件を修正した場合は、受注、返品、値引、請求を確認し、権限を修正した場合は、許可される操作と拒否される操作の両方を確認します。

09テスト成果物の運用

テスト計画、ケース一覧、データ台帳、実行結果、障害票、差分分析、承認記録を同じ管理体系で扱います。ファイル名だけで版を管理せず、リリース、環境、実行日、担当者を記録します。

週次の品質会議では、ケース消化率よりも、重大障害数、再発障害数、未検証の高リスク業務、移行差分、リハーサル時間、未決定事項を確認します。数値が改善していても、高リスク業務が未実施なら稼働判定の材料として不十分です。

本番稼働後は、初回の月次処理、初回の支払、初回の請求、初回の棚卸、初回の決算を監視対象にします。稼働後に発生した問題を、次回リリースの回帰テストへ反映し、テスト資産を一度きりの移行成果物にしないことが重要です。

10実務で使えるテスト実施チェックリスト

• 業務プロセスと対象範囲を確定した
• 移行前のベースラインを取得した
• 代表、リスク、例外のテストデータを準備した
• カスタムコード、アドオン、帳票、ジョブを回帰対象に含めた
• 会計、在庫、未処理伝票の照合方法を決めた
• 外部連携の正常系、異常系、再送を確認した
• 権限と職務分掌を確認した
• 移行リハーサルの所要時間を計測した
• カットオーバーと切り戻しの判定条件を承認した
• 未解決事項の責任者と期限を登録した

SAP S/4HANAコンバージョンのテスト戦略では、技術的な移行成功、業務結果の一致、データの整合性、連携の継続、運用可能性を一つの判定体系で扱います。早い段階でベースラインと合格基準を固定し、回帰テストと移行リハーサルを反復することで、本番稼働時の不確実性を減らせます。