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で入力項目の桁数を広げた場合、正常値だけでなく境界値と下流出力を確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 入力 | 空、最小桁、旧最大桁、新最大桁、超過入力を試す | 画面制御とプログラム検証の両方を見る |
| 保存 | ファイル定義、変換、切り捨て、符号、CCSIDを確認する | 保存後に読み直して値を比較する |
| 下流 | 帳票、CSV、外部連携、再処理で同じ値を確認する | 1画面の成功だけで合格にしない |
証跡には期待値、実値、使用データ、実行日時、オブジェクトレベルを残します。個人情報や本番データを画像へ写し込まず、テスト用データを使います。