AS400の設計書が古い時の調査手順｜現行ソース・ジョブログ・業務ヒアリングで確認する

AS400 / IBM i の保守では、設計書が古い、現行ソースと合っていない、誰も更新していないという相談がよくあります。設計書だけを信じて小改修や障害対応を進めると、実際のRPG/CL、夜間バッチ、ファイル更新、外部連携とずれていて手戻りになります。

この記事では、AS400の設計書が古い時に、現行ソース、ジョブログ、業務ヒアリング、ファイル定義からどう事実確認するかを整理します。属人化した現場や担当者退職後の引き継ぎでも使える確認順です。

古い設計書をそのまま信じない

設計書は入口としては有効ですが、現行運用と一致しているとは限りません。長年の保守で、臨時改修、障害対応、帳票変更、外部連携追加が積み重なり、設計書に反映されていないことがあります。まず「設計書」「現行ソース」「本番ジョブ」「業務担当者の説明」を分けて確認します。

設計書が古い時は、RPG/CLの影響調査をセットで行います。CLのCALL順、RPGのファイル更新、MONMSG、後続ジョブ、帳票出力を確認し、設計書との差分をメモします。差分を見つけることが目的で、最初から設計書を完全に書き直す必要はありません。

具体的な確認順は、AS400 RPG/CL影響調査チェックリストに整理しています。

設計書とソースだけでは、実際にどの経路で動いたか分からないことがあります。DSPJOBLOGやDSPLOG、QHSTで実行履歴を見ると、どのジョブがどの時刻に動き、どのメッセージを出したかを追えます。障害調査では、設計書よりジョブログの方が強い証拠になることがあります。

ジョブログの読み方は、AS400ジョブログの見方も参考になります。

Codexは、古い設計書の内容、匿名化したRPG/CL、ジョブログ、業務ヒアリングメモを整理して、差分や確認観点を洗い出す用途に向いています。ただし、本番データや会社名をそのまま入れず、匿名化した情報で使うことが前提です。AIに設計判断を任せるのではなく、調査メモの整理に使います。

AS400の設計書が古い時は、設計書だけで判断せず、業務名、実行経路、RPG/CL、ファイル定義、ジョブログを照合します。全部を一気に直すより、まず現行運用との差分を見える化することが大切です。設計書が信用できない現場ほど、業務と技術をつなぐ確認メモが価値を持ちます。

関連: RPG/CL小改修後のテスト観点や証跡を整理する場合は、AS400小改修後のテスト・エビデンスチェックリストで、コンパイル、正常系、異常系、ジョブログ、スプールの残し方を確認できます。

関連: AS400設計書・運用資料の棚卸しチェックリスト｜古い資料を現行仕様に合わせるもあわせて確認してください。

関連: AS400 RPGソース解析をAIに手伝わせる時のチェックリスト｜仕様不明でも安全性を保つもあわせて確認してください。

設計書が古い時は、ドキュメントだけを直すのではなく、現行ソース、実行ジョブ、利用部門の業務手順を分けて確認します。特に改修や外部相談へ進む場合は、どこまでが事実で、どこからが推測かを切り分けておくと手戻りを減らせます。

Codexに整理を手伝わせる場合は、設計書の全文や実データをそのまま渡さず、画面名、プログラム名、ファイル名、確認済みの事実、未確認の仮説に分けて使います。現場向けの進め方はAS400 / IBM i 現場向けCodex実戦研修でも確認できます。

設計書に書かれた月次ジョブ名が現行スケジュールに見つからない場合、すぐ資料を誤りとせず、改名、統合、廃止の経緯を確認します。

資料を更新する時は、確認日、根拠、未確認事項、旧名称を残します。分からない箇所を推測で埋めず、現行仕様と確認できた範囲を明確にする方が安全です。