AS400 / IBM i のRPG/CL改修では、コンパイルが通っただけでは安心できません。業務データの更新、例外時の動き、MSGW、ライブラリリスト、後続処理、帳票、戻し手順まで見て初めて本番に出せます。コードレビューは、若手育成にも障害予防にも効きます。
レビューで見る観点
| 観点 | 見ること | リスク |
|---|---|---|
| ファイル更新 | 更新条件、キー、コミット単位 | 誤更新や二重更新 |
| エラー処理 | CPF/RNX、例外時の戻り | 途中停止や後続不整合 |
| MSGW | 返信が必要な処理か | 夜間バッチ停止 |
| LIBL | 開発・テスト・本番の差 | 別オブジェクト参照 |
| テスト | 正常系、異常系、戻し | 本番で初めて分かる不具合 |
業務影響をレビューに入れる
コードだけを見ても、請求締め、在庫更新、出荷確定、帳票出力への影響は分かりません。レビューでは、修正内容がどの業務に効くのか、利用部門がどう確認するのかも見ます。
AIはレビュー観点の抜け漏れ確認に使う
Codexには、匿名化した修正概要、エラー文、テスト観点を渡し、レビュー観点を洗い出す使い方ができます。実ソースや本番データをそのまま入れず、最終レビューは人が行います。
コンパイルエラーは RPG/CLコンパイルエラーの調べ方、ライブラリ差異は ライブラリリスト違いによる障害、テストは テスト・エビデンスチェックリスト を参照してください。
関連するAS400確認ルート
RPG/CLのコードレビューでは、ロジックだけでなく、締め、EDI、戻し、権限、ジョブログ出力まで確認します。AIで補助する場合も、現場の事故パターンを観点に入れます。
AS400のレビューは業務影響から逆算する
RPG/CLのレビューでは、きれいな書き方だけを見ても本番障害は減りません。販売管理の現場では、受注、出荷、在庫、売上、請求のどこに影響するかを先に見ます。更新ファイル、例外処理、再実行条件、戻し手順を確認してから、ソースの細部を見る方が実務的です。
- 更新対象ファイルとキー項目が想定どおりか
- MONMSGやエラー時の分岐が握りつぶしになっていないか
- 本番・検証ライブラリの取り違えが起きないか
- 途中で止まった場合に再実行できる作りか
- 帳票、CSV、外部連携、締め処理に影響しないか
レビュー結果は「問題なし」だけで終わらせず、何を見たかを残します。特に、例外時に止めるのか続行するのか、後続処理へ流すのかは、業務担当者にも説明できる形にしておくと本番前の不安を減らせます。
コードレビューでは、文法よりも本番影響と戻し方を見る
AS400のRPG/CLレビューでは、文法やインデントだけでなく、本番データへの影響、締め処理、再実行、戻し手順を確認します。特に古い販売管理や物流系の処理では、ひとつの項目変更が売上、在庫、請求、EDI、帳票へ広がることがあります。レビュー担当者は、修正箇所だけでなく、前後の処理を追う必要があります。
| レビュー観点 | 確認する内容 | 見落としやすいこと |
|---|---|---|
| 入力条件 | 画面、バッチ、外部連携、再実行時の入力 | 通常入力だけでテストを終える |
| 更新対象 | ファイル、キー、更新順、コミット有無 | 途中失敗時の状態を見ていない |
| 後続処理 | 帳票、売上、請求、在庫、EDI | 修正プログラム単体で閉じて考える |
| 戻し方 | バックアップ、再処理、取消、承認 | 戻し手順が口頭だけになっている |
| AI利用 | Codexの指摘を参考にしつつ人が判断する | 機密情報や本番データを入れない |
レビューで大事なのは、指摘数を増やすことではなく、本番障害につながる抜けを減らすことです。CodexやClaude Codeを使う場合も、ソース全文や機密データを入れず、修正目的、対象項目、影響範囲、テスト観点を一般化して渡すと安全です。レビュー観点をチームでそろえたい場合は、研修で実例ベースに練習すると定着しやすくなります。