AS400 / IBM i の保守で困るのは、資料がないことだけではありません。資料はあるのに古い、画面名と業務名が合わない、ジョブ一覧が更新されていない、ファイル定義と現行ソースがずれている、という状態もよくあります。棚卸しは、資料をきれいにする作業ではなく、保守で使える状態に戻す作業です。
棚卸しする資料
| 資料 | 確認すること | 使い道 |
|---|---|---|
| 業務一覧 | 業務名、担当部門、利用頻度 | 問い合わせの入口 |
| 画面一覧 | メニュー名、プログラム、権限 | 障害時の調査 |
| ジョブ一覧 | 夜間バッチ、投入時刻、依存関係 | 停止時の初動 |
| ファイル定義 | DSPFFDで項目、DSPFD TYPE(*ACCPTH)でキー順序等、業務資料で用途 | 影響調査 |
| 運用手順 | 再実行、戻し、連絡先 | 属人化防止 |
現行ソースとジョブログで裏取りする
古い設計書は、現行ソース、ジョブログ、スプール、利用部門へのヒアリングで裏取りします。資料に書いてあるから正しいのではなく、今の本番でどう動いているかを確認します。
完璧な資料より使える資料
最初から完璧な設計書を作ろうとすると止まります。まずは障害時に必要な業務名、ジョブ名、プログラム、ファイル、再実行手順を押さえた資料を作る方が効果的です。
古い設計書の調査は AS400の設計書が古い時の調査手順、引き継ぎは 担当者退職時の引き継ぎチェックリスト、影響調査は RPG/CL影響調査チェックリスト を参照してください。
Codexで資料化を速くする
社内で利用を認められたCodexに、共有許可のある匿名化した情報を渡して、棚卸し表の書式や未確認事項の整理を補助させる方法があります。匿名化しただけで共有可能と判断せず、社内ルールと契約を確認してください。AIに資料の正しさや廃止可否を決めさせません。
関連: AS400のセキュリティ・運用改善・外部依頼を整理する場合は、AS400保守・運用完全ガイド も確認してください。
関連: AS400業務ヒアリングシートもあわせて確認してください。
古い資料を現行仕様と照合する例
設計書に「毎日23時実行」と書かれていても、現在の運用が同じとは限りません。文書名だけで棚卸しを終えず、実行中の仕組みと照合します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| ジョブ運用 | 設計書の時刻と現行スケジュールを比較する | 差があれば承認済み仕様を確認して理由を記録する |
| プログラム | 資料に記載されたプログラム名と呼び出し元を確認する | 未使用、名称変更、代替済みを区分する |
| 連絡先 | 障害時の担当部署と承認者が在籍しているか確認する | 個人名だけでなく役割と代替連絡先を残す |
資料には最終確認日、確認者、根拠にした画面や設定、次回見直し日を付けます。更新できない資料は削除せず、旧版であることと参照禁止の理由を明記します。差分が見つかった場合は、資料だけでなく手順書や監視設定にも同じ古い記述が残っていないか横断確認します。
資料と実態が合っていない時は、本番オブジェクトと対応するソースを照合する
設計書や運用資料が実態と合っていないことは、AS400の現場ではよくあります。珍しい事故ではなく、長く動いているシステムでは普通に起きます。
理由は単純です。改修のたびに資料まで直されるとは限らないからです。緊急対応で先に直した、担当者が変わった、外部に委託した。どれも起こります。そして直っていない資料は、直っていないことが分からない形で残ります。
資料だけでなくソースを読むことが重要です。ただし、保存されているソースが本番で実行中のプログラムオブジェクトと対応しているとは限りません。実行ジョブの呼び出し先とライブラリ、オブジェクトの作成・反映記録、対応するソースの版を照合します。実際の動作と承認された業務仕様も分けて記録し、対応が確認できないソースから仕様を断定しないでください。
| 情報源 | 信頼度 | 扱い方 |
|---|---|---|
| RPG/CLソース | 本番との対応確認が必要 | 実行オブジェクトとソースの版を照合してから処理内容を読む |
| ジョブログ等の実行記録 | 記録範囲と時点を確認 | 記録された事実の証拠にする。ログにない処理を未実行と断定しない |
| 設計書・仕様書 | 参考 | いつ時点のものか、その後の改修が反映されているかを疑う |
| 口頭の説明・引き継ぎメモ | 参考 | 意図を知る手がかりとしては有用。仕様の根拠にはしない |
対応を確認したソースの整理に生成AIを使う
本番との対応を確認したソースを調査する際にも、現実的な問題があります。ソースを読むのは時間がかかるということです。何十年分の改修が積み重なったRPGやCLを、資料なしで追うのは重い作業です。だから多くの現場で、古い資料を頼りにする、詳しい人に聞く、といった回り道が選ばれてきました。
ここが、今の時代に変わったところです。生成AIによるソース解析が使えるようになったことで、ソースから処理の候補を整理する作業を支援できるようになりました。ただし、AIの説明は実行記録やテスト結果と照合し、動的な呼び出しや設定による分岐の見落としも確認します。処理の流れを整理させる、参照しているファイルを列挙させる、影響範囲の候補を出させる。資料の正しさを疑う代わりに、ソースから組み立て直すという進め方が取れます。
ただし、AIへ渡すものには線を引いてください。本番データ、顧客情報、認証情報、パスワード、APIキーは渡しません。渡すのは一般化したソースや構造の情報に限ります。
この進め方を現場で回せるようにする研修も用意しています。御社の環境とソースを使って、RPG/CLの読解から影響調査までを実際に行う形です。内容と料金はAS400 / IBM i Codex実戦研修の研修内容・料金で確認できます。
設計書・運用資料の棚卸しとあわせて確認したい手順
設計書や運用資料の棚卸しは、古い資料を捨てる作業ではなく、現行業務と障害対応に使える形へ整える作業です。AIで要約する場合も、元資料の所在と信頼度を先に分けます。
一つの資料を一行で判定する棚卸し台帳
資料名の一覧だけでは、障害時にどれを使ってよいか分かりません。次の欄を台帳へ作り、確認状態と利用可能な範囲を残します。更新日が新しいだけで「利用可」にしないでください。
資料ID・資料名・版：
保管先・管理担当：
対象業務・対象環境：
確認日・確認者：
照合した本番オブジェクト・対応ソースの版：
根拠にした記録・対象日時：
一致した範囲／食い違う範囲：
状態（未確認・確認中・限定利用・利用可・旧版）：
利用してよい目的／利用しない操作：
不足を確認する担当・期限：
次回見直しの条件：
架空の記入例：夜間バッチ運用手順書
設計書は「23時に処理Aを開始」、現行設定は「前処理Bの終了後に処理Aを開始」だったと仮定します。台帳には「起動条件が不一致。変更の承認記録は未確認。手動投入手順としては利用しない」と残します。画面名や連絡先だけ照合済みなら、その範囲に限定して利用できます。
現在動いているから現行設定が正しいとも、設計書と違うからプログラムの不具合とも断定できません。運用責任者が承認された起動条件を確認し、技術担当が設定との一致を確かめてから、手順書の改訂を承認します。過去の実行記録だけでは、現在の全条件が正しいと証明できない点に注意してください。
何から直し、どこで棚卸しを完了にするか
- 誤操作につながる復元・再実行・取消手順と、連絡先の不備を優先して確認する。
- 次に、締め・出荷・請求など業務期限に関わる起動条件と依存関係を確認する。
- 参照用の画面説明などは、利用頻度と変更予定を基準に順番を付ける。
今回選んだ業務について、使える正本の場所、利用してよい範囲、未確認事項の担当が分かれば棚卸し結果を共有できます。ただし、台帳が埋まったことと、復旧手順を実行できることは別です。復旧手順の利用承認には、対象環境・バックアップ・途中更新・後続影響・検証結果などの確認が必要です。
旧版は保存方針に従って区別し、正本から誤って参照されないようにします。処理変更、担当交代、障害での食い違いがあった時を、次回見直しのきっかけとして台帳に記録してください。
