AS400 / IBM iのリプレース、Power更新、IBM iバージョンアップでは、技術的に起動するだけでは十分ではありません。現場の業務が正しく回るか、締め処理や帳票、外部連携、再実行、切戻しまで含めて移行テスト計画を作る必要があります。
AS400の移行テストで大切なのは、通常日の確認だけでなく、月末、月初、棚卸、請求締め、出荷ピーク、返品、単価改定のような例外日を含めることです。
移行テスト計画を社内研修に落とし込む
移行テストは、チェックリストを作るだけでは不十分です。受講者が、どの業務を先に確認するか、どの帳票やCSVを比較するか、異常時にジョブログやデータをどう見るかを説明できる状態にする必要があります。
移行テストで見る項目
| 分類 | 確認内容 | 注意点 |
|---|---|---|
| 基本操作 | ログイン、メニュー、照会、更新 | 権限ごとに見る |
| 締め処理 | 請求締め、月次、年次、棚卸 | 通常日だけで判断しない |
| 帳票 | 出力内容、並び順、プリンター、PDF | 数字だけでなく配布先も見る |
| 外部連携 | CSV、FTP、EDI、ODBC/JDBC、API | 相手側取込まで確認する |
| 障害時 | MSGW、異常終了、再実行、切戻し | 戻せる条件を決める |
現場担当者を巻き込む
移行テストは情報システム部門だけでは完結しません。実際に在庫照会、請求締め、出荷確定、帳票確認を行う現場担当者に見てもらう必要があります。画面が動いても、現場の判断や帳票の使い方に合わなければ本番移行後に混乱します。
- 業務担当者ごとの確認シナリオを作る
- 重要日と例外処理をテストに入れる
- 旧環境との結果比較を行う
- 切戻し条件と判断者を決める
- 未解決課題を本番移行前に潰す
移行失敗の見落としは AS400リプレース失敗を防ぐチェックリスト、業務確認は AS400業務ヒアリングシートも確認してください。
まとめ
AS400移行テスト計画では、基本操作、締め処理、帳票、外部連携、障害時対応、切戻しを確認します。技術テストだけでなく、現場の業務テストを入れることで、本番移行後の事故を減らせます。
件数一致でも合格にしない移行テスト例
旧環境と新環境でレコード件数が同じでも、金額や文字が変わっていることがあります。件数、内容、業務結果を別々に照合します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 件数 | ファイル単位と抽出条件単位で移行前後を比較する | 除外データとエラー件数を説明できる |
| 内容 | 金額、符号、日付、全角文字、空白、コード値を比較する | CCSIDや桁変換による差を見つける |
| 業務 | 代表伝票を受注から請求まで通して帳票も照合する | データが存在するだけでなく業務処理できることを確認する |
差異は件数だけでなく、対象キー、期待値、実値、原因、受入可否を記録します。許容差を設ける場合は、テスト後ではなく計画時に業務責任者と決めます。
関連するAS400確認ルート
移行テストは、画面が動くかだけでは足りません。締め、EDI、帳票、権限、戻し方まで含めて、AS400の現場運用として検証します。
移行テストは技術確認と業務確認を分けて計画する
移行テストでは、プログラムが動くかだけでなく、締め処理、請求、在庫、出荷、外部連携、帳票、権限、運用手順まで確認範囲に入れる必要があります。技術的な正常終了と、業務として問題ないことは別の確認です。
テスト計画を作るときは、失敗したときに戻せるか、どの時点でGo/No-Goを判断するか、誰が業務OKを出すかを決めておくと安全です。データ移行やリリース判定の記事へつなげて読むと、移行直前の抜け漏れを減らせます。