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、後続ジョブ、帳票出力を確認し、設計書との差分をメモします。差分を見つけることが目的で、最初から設計書を完全に書き直す必要はありません。
具体的な確認順は、RPG/CL影響調査チェックリストに整理しています。
ジョブログで実際に動いた証拠を見る
設計書とソースだけでは、実際にどの経路で動いたか分からないことがあります。DSPJOBLOGでは対象ジョブに記録されたメッセージを、DSPLOGではQHSTの履歴を調べ、時刻と対象ジョブを照合します。ただし、ログは全命令の実行履歴ではありません。記録設定と保管範囲によって残る情報が変わるため、「ログにないから未実行」とは断定しません。CLコマンドの記録条件はIBM公式のCHGJOB（LOG・LOGCLPGM）を参照してください。確認のために無断で本番の記録設定を変えず、まず既存の証跡の範囲を確かめます。
ジョブログの読み方は、AS400ジョブログの見方も参考になります。
Codexで差分整理を補助する
私の場合、最近は資料が古いとほぼ判断した時点で、Codexにソースを解析してもらい、処理の内容を教えてもらう進め方をしています。古い資料だけを頼りに読み進めるのではなく、まずソースから処理内容を把握するために使っています。ただし、匿名化だけで共有許可が得られるわけではありません。社内ルールと契約で利用が認められた環境へ、共有許可のある範囲だけ渡します。この進め方を使う際の注意は、Codexの説明をそのまま「本番で確認済みの仕様」にしないことです。解析したソースが本番オブジェクトに対応するか、外部設定や動的な呼び出しに依存しないかを別に確認する必要があります。
まとめ
AS400の設計書が古い時は、設計書だけで判断せず、業務名、実行経路、RPG/CL、ファイル定義、ジョブログを照合します。全部を一気に直すより、まず現行運用との差分を見える化することが大切です。設計書が信用できない現場ほど、業務と技術をつなぐ確認メモが価値を持ちます。
関連: RPG/CL小改修後のテスト観点や証跡を整理する場合は、RPG/CL修正後のテスト観点で、正常系・異常系・境界値と証跡の確認項目を整理できます。
関連: AS400設計書・運用資料の棚卸しチェックリストもあわせて確認してください。
関連: AS400 RPGソース解析をAIに手伝わせる時のチェックリスト｜仕様不明でも安全性を保つもあわせて確認してください。
設計書と現行処理が違う時の次アクション
設計書が古い時は、ドキュメントだけを直すのではなく、現行ソース、実行ジョブ、利用部門の業務手順を分けて確認します。特に改修や外部相談へ進む場合は、どこまでが事実で、どこからが推測かを切り分けておくと手戻りを減らせます。
| 確認したいこと | 次に読む記事 |
|---|---|
| 業務部門に聞く項目を整理する | AS400業務ヒアリングシート |
| RPG/CLの影響範囲を洗い出す | RPG/CL影響調査チェックリスト |
| プログラム参照関係を確認する | DSPPGMREFによる参照情報と調査の限界 |
Codexに整理を手伝わせる場合は、設計書の全文や実データをそのまま渡さず、画面名、プログラム名、ファイル名、確認済みの事実、未確認の仮説に分けて使います。現場向けの進め方はAS400 / IBM i の現場向け研修でも確認できます。
設計書の古いジョブ名を確認する想定例
設計書に書かれた月次ジョブ名が現行スケジュールに見つからない場合、すぐ資料を誤りとせず、改名、統合、廃止の経緯を確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 現行資産 | ソース、呼び出し元、ジョブ記述、スケジュールを検索する | 同じ処理が別名へ移っていないかを見る |
| 実行証跡 | ジョブログ、スプール、更新時刻、外部連携記録を確認する | 実際に動く処理と資料の対応を取る |
| 業務確認 | 利用部門へ入力、出力、締め条件、例外時対応を聞く | 画面名だけで処理範囲を決めない |
資料を更新する時は、確認日、根拠、未確認事項、旧名称を残します。分からない箇所を推測で埋めず、現行仕様と確認できた範囲を明確にする方が安全です。
不一致を見つけたら、設計書を直す前に差分票を作る
「設計書が古い」の一言では、資料だけを直せばよいか、実装を直すべきか判断できません。一つの食い違いごとに、次の欄を残してください。
対象業務・画面・ジョブ：
設計書の記載と版・該当箇所：
観測した現行動作と確認日時：
実行オブジェクトと対応ソースの確認状況：
根拠の所在・確認できた条件：
承認済み業務仕様との一致／不一致／未確認：
修正候補（資料・実装・運用・判断保留）：
影響範囲・判断者・次の確認：
たとえば「設計書では締め後に変更不可、画面では変更できた」という架空のケースでは、資料更新と即断しません。承認済みの仕様変更なら資料への反映漏れ、禁止のままなら実装や権限の問題、特定権限だけ許可なら条件の記載漏れが候補です。どれかを決めるまでは、未確認のまま判断者へ引き継ぎます。
調査対象の機能について、不一致の根拠と判断先が決まり、修正した範囲を承認済み仕様・検証結果に結び付けて説明できる状態を目指します。システム全体の設計を復元したと扱わず、未調査の分岐・条件も明記してください。