AS400 / IBM i の保守では、設計書が古い、現行ソースと合っていない、誰も更新していないという相談がよくあります。設計書だけを信じて小改修や障害対応を進めると、実際のRPG/CL、夜間バッチ、ファイル更新、外部連携とずれていて手戻りになります。
この記事では、AS400の設計書が古い時に、現行ソース、ジョブログ、業務ヒアリング、ファイル定義からどう事実確認するかを整理します。属人化した現場や担当者退職後の引き継ぎでも使える確認順です。
古い設計書をそのまま信じない
設計書は入口としては有効ですが、現行運用と一致しているとは限りません。長年の保守で、臨時改修、障害対応、帳票変更、外部連携追加が積み重なり、設計書に反映されていないことがあります。まず「設計書」「現行ソース」「本番ジョブ」「業務担当者の説明」を分けて確認します。
最初に照合する5つ
| 確認対象 | 見るもの | 分かること |
|---|---|---|
| 業務名 | 在庫照会、請求締め、出荷確定など | 設計書の業務名と現場の呼び方のズレ |
| 実行経路 | メニュー、CL、SBMJOB、JOBQ | 実際にどこから起動されるか |
| 現行ソース | RPG/CL、CALL、MONMSG | 設計書にない分岐や例外処理 |
| ファイル定義 | DSPFFD、DSPPFM、SQL | 項目追加、桁数、コード値、実データ |
| 実行履歴 | DSPJOBLOG、DSPLOG、QHST | 実際に動いた処理とエラー履歴 |
業務ヒアリングで聞くこと
- 現在も使っている画面・帳票・メニューはどれか
- 昔は使っていたが今は使っていない処理はあるか
- 締め処理や出荷処理で再実行してはいけないものはあるか
- エラー時に手作業で補正している運用はあるか
- 設計書に載っていない外部連携やCSV出力はあるか
RPG/CL影響調査と合わせて見る
設計書が古い時は、RPG/CLの影響調査をセットで行います。CLのCALL順、RPGのファイル更新、MONMSG、後続ジョブ、帳票出力を確認し、設計書との差分をメモします。差分を見つけることが目的で、最初から設計書を完全に書き直す必要はありません。
具体的な確認順は、AS400 RPG/CL影響調査チェックリストに整理しています。
ジョブログで実際に動いた証拠を見る
設計書とソースだけでは、実際にどの経路で動いたか分からないことがあります。DSPJOBLOGやDSPLOG、QHSTで実行履歴を見ると、どのジョブがどの時刻に動き、どのメッセージを出したかを追えます。障害調査では、設計書よりジョブログの方が強い証拠になることがあります。
ジョブログの読み方は、AS400ジョブログの見方も参考になります。
Codexで差分整理を補助する
Codexは、古い設計書の内容、匿名化したRPG/CL、ジョブログ、業務ヒアリングメモを整理して、差分や確認観点を洗い出す用途に向いています。ただし、本番データや会社名をそのまま入れず、匿名化した情報で使うことが前提です。AIに設計判断を任せるのではなく、調査メモの整理に使います。
社内で安全に使うルールは、AS400 / IBM i 現場向け Codex実戦研修で整理できます。
まとめ
AS400の設計書が古い時は、設計書だけで判断せず、業務名、実行経路、RPG/CL、ファイル定義、ジョブログを照合します。全部を一気に直すより、まず現行運用との差分を見える化することが大切です。設計書が信用できない現場ほど、業務と技術をつなぐ確認メモが価値を持ちます。
関連: RPG/CL小改修後のテスト観点や証跡を整理する場合は、AS400小改修後のテスト・エビデンスチェックリストで、コンパイル、正常系、異常系、ジョブログ、スプールの残し方を確認できます。
関連: AS400専門サイトとしての戦略記事として、AS400設計書・運用資料の棚卸しチェックリスト｜古い資料を現行に近づける も追加しました。
関連: AS400保守でAIやCodexを安全に使う実務記事として、AS400 RPGソース解析をAIに手伝わせる時のチェックリスト｜仕様不明でも危なくしない も追加しました。
