AS400 / IBM i の小改修では、プログラムを直した後のテストとエビデンスが重要です。RPG/CLを修正してコンパイルが通っても、在庫照会、請求締め、出荷確定、夜間バッチ、帳票、外部連携まで確認しないと、本番反映後に手戻りになることがあります。
この記事では、AS400保守で小改修後に残すべきテスト観点とエビデンスを、現場目線で整理します。保守会社へ依頼する時、若手にレビューさせる時、Codexでテスト観点を作る時にも使えます。
AS400小改修後に確認すること
| 観点 | 確認内容 | 残すエビデンス |
|---|---|---|
| コンパイル | RPG/CLが正常にコンパイルされたか | コンパイルリスト、エラーなしの画面 |
| 正常系 | 想定した入力で画面・帳票・更新が正しいか | 入力条件、画面、出力結果 |
| 異常系 | エラー時にMSGWやCPF/RNXが想定通りか | ジョブログ、メッセージID |
| 後続処理 | 夜間バッチ、帳票、CSV、外部連携に影響がないか | JOBQ、スプール、連携ファイル |
| 戻し | 問題発生時に戻せるか | バックアップ、変更前ソース、反映手順 |
正常系だけで終わらせない
AS400の小改修では、正常に1件処理できたことだけでテスト完了にすると危険です。空データ、桁あふれ、コード未登録、日付境界、締め済みデータ、再実行など、実運用で起きるパターンを少しでも入れておくと、本番後の事故を減らせます。
ジョブログとスプールを残す
テスト時のジョブログは、後から「何を確認したか」を説明する証拠になります。DSPJOBLOGでエラーがないこと、想定したメッセージが出ていること、帳票が出る場合はWRKSPLFでスプールを確認します。コンパイルリストも、警告や参照ファイルの確認に使えます。
ジョブログの読み方は、AS400ジョブログの見方、影響調査の観点は AS400 RPG/CL影響調査チェックリスト に整理しています。
業務担当者に見せるエビデンス
開発者向けのエビデンスだけでは、業務担当者に伝わらないことがあります。在庫照会なら変更前後の数量、請求締めなら締め対象と帳票、出荷確定なら出荷ステータスや外部連携ファイルなど、業務の言葉で確認できる資料を残します。
業務名から調査する流れは、AS400業務トラブルの調べ方も参考になります。
Codexでテスト観点を作る時
Codexは、RPG/CLの処理概要からテスト観点を洗い出したり、ジョブログや影響調査メモを整理したりする用途に向いています。ただし、本番データや会社名、取引先名は伏せ、匿名化した処理概要で使うことが前提です。AIに合否判断を任せるのではなく、レビュー用の下書きとして使います。
会社で安全に使う型は、AS400 / IBM i 現場向け Codex実戦研修で整理できます。
まとめ
AS400の小改修後は、コンパイル、正常系、異常系、後続処理、戻しを確認し、ジョブログ、スプール、画面、業務結果をエビデンスとして残します。テスト観点を残しておくと、担当者が変わっても同じ基準で確認でき、保守の属人化も減らせます。
関連: RPG/CL小改修を本番反映する前に、AS400本番反映・戻し手順チェックリストで、バックアップ、反映時間、ジョブログ、戻し基準を確認できます。
関連: AS400で帳票・スプールが出ない時の確認手順は、こちらの記事で確認できます。
関連: AS400データ抽出依頼を受けた時の確認手順は、こちらの記事で確認できます。
関連: AS400現場の競合対策記事として、AS400 RPG/CLコンパイルエラーの調べ方｜スプール・ソース・ライブラリリストを見る も追加しました。
関連: AS400変更管理・本番作業の実務記事として、AS400変更依頼テンプレート｜RPG/CL改修前に業務・影響範囲・戻しを整理する も追加しました。
関連: AS400変更管理・本番作業の実務記事として、AS400 RPG/CLコードレビュー観点｜本番障害を減らすために見るポイント も追加しました。
