【初心者向け】AS400保守で使う調査メモの作り方｜障害対応を早くする記録術

AS400（IBM i）の保守では、調査した内容をメモに残すことがとても重要です。ジョブログを見た、ファイルを確認した、プログラムを追った、という作業を頭の中だけで進めると、同じ確認を繰り返したり、原因を見失ったりしやすくなります。

特に障害対応では、短い時間で状況を整理し、関係者へ説明する必要があります。調査メモがあると、原因の切り分け、再発防止、後日の引き継ぎがしやすくなります。

コピーして使う調査メモ

私は2000年にIT業界へ入り、流通業界の販売管理システムでAS400（IBM i）の開発・保守・追加要望対応を続けてきました。保守では、調べた内容を頭の中だけに残すと、次回も同じ確認から始まります。ジョブ名、メッセージID、対象ライブラリ、判断理由、次に見る場所まで記録すると、障害対応にも引き継ぎにも使えるメモになります。本記事では、そのために残したい項目を整理しています。

最初は空欄があっても構いません。「未確認」を明示し、確認済みの事実と原因の仮説を分けて追記します。

発生日時／記録者：
接続先システム・環境：
対象ジョブ（番号／ユーザー／ジョブ名）：
業務・対象期間・対象伝票：
現象／メッセージID・全文：
対象ライブラリ／プログラム／ファイル／メンバー：
確認時刻・使ったコマンド・結果：
根拠（ジョブログ・スプール・差分の保存先）：
確認できた事実：
原因の仮説と未確認事項：
途中更新・後続処理・外部連携への影響：
判断・承認者・実施した操作：
復旧後の照合結果：
次に確認すること／担当／期限：

記入例：バッチがMSGWになった場合

次は書き方を示す架空の例です。実際の障害報告ではありません。

09:15 TESTSYSの受注取込がMSGW。対象は123456/TESTUSR/ORDIN。
09:18 WRKJOBでジョブログを表示し、メッセージ全文を所定の保管先へ保存。
確認済み：当該ジョブは応答待ち。後続の出荷連携は未開始。
未確認：入力100件のうち、どこまでDBに反映済みか。
仮説：入力データの一部不備。原因はまだ確定していない。
判断：返信・再投入は保留。取込済みキーとエラー箇所を照合する。
次の担当：保守担当Aが途中更新を確認、業務担当Bが出荷期限を確認。
完了条件：承認した再開後に取込件数と出荷連携結果を照合する。

悪い調査メモは「結論だけ」で終わっている

初心者の調査メモで危ないのは、「エラーでした」「修正しました」「再実行しました」だけで終わっているものです。これでは、何を見てそう判断したのか、どの環境で実行したのか、再発した時にどこから調べればよいのかが分かりません。

AS400の現場では、ジョブログやスプール、ライブラリリスト、対象ファイルの状態を見れば、かなりのことが分かります。だからこそ、調査メモには「見たもの」を残します。結果だけではなく、判断材料を残すのが大事です。

弱いメモ	改善したメモ
ジョブが止まっていた	WRKACTJOBでMSGWを確認。ジョブ名、ユーザー、番号を控え、DSPJOBLOGで該当メッセージを確認した
ファイルがおかしい	対象ライブラリ、ファイル名、件数、前回処理日時、後続処理への影響を確認した
再実行した	再実行前にバックアップ有無、対象データ、実行コマンド、実行者、レビュー者を確認した
原因不明	分かっている事実、まだ未確認の点、次に見るジョブログ・CL・ファイルを分けて記録した

販売管理システムの調査メモで意識すること

販売管理の保守では、ひとつの障害が別の業務へつながることがあります。たとえば受注データの作成に失敗すると、在庫引当、出荷指示、売上計上、請求、外部連携まで影響する可能性があります。だから調査メモでは、プログラム単体ではなく「業務の流れのどこで止まっているか」を書きます。

私なら、まず商品が客に届くところに関係する処理を優先して見ます。受注、出荷、物流連携の影響が大きい場合は、バックオフィス系より先に確認します。もちろんシステムごとに違いますが、販売管理ではこの優先順位の考え方がかなり大事です。

• 受注系が止まっていないか
• 出荷指示や物流連携に影響していないか
• 在庫引当や売上計上の前後関係が崩れていないか
• 同じデータを二重処理していないか
• 後続バッチが動いてよい状態か

調査メモを再発防止に使うコツ

調査メモは障害対応中だけでなく、再発防止にも役立ちます。原因、影響範囲、一時対応、恒久対応を分けて残すことで、同じエラーが出たときに短時間で判断できるようになります。

• 原因が確定している情報と推測を分ける
• 一時対応で終わらせず恒久対応の候補を書く
• 関係するファイルやプログラム名を残す
• 再実行手順と注意点を残す
• 次回確認すべきログやコマンドを残す

AS400保守では、長く使われている処理ほど資料が古くなっていることがあります。調査メモを積み上げることは、属人化を減らし、次の担当者が安全に作業するための小さなドキュメント作りにもつながります。

Codexに調査メモを手伝わせる時の使い方

Codexを使う場合は、社内規程・契約で利用を許可されたサービスと情報の範囲を先に確認します。その範囲のジョブログ、CL、RPG、ファイル定義から機密情報を除き、「何を整理してほしいか」を明確にします。たとえば、ジョブログのメッセージID一覧を整理する、CLの呼び出し順を表にする、影響しそうなファイル名を抜き出す、といった使い方です。

ただし、本番環境の判断をAIに任せてはいけません。最終的に責任を持つのは人間です。Codexは調査メモのたたき台や整理には便利ですが、ライブラリ名、対象ファイル、実行可否、リカバリー方針は、必ず人間がレビューする必要があります。

関連して、ジョブログの見方は AS400のジョブログ確認手順、本番作業の注意点は AS400の本番対応で初心者がやってはいけないこと、法人向けに調査メモの作り方をそろえる場合は、Codex実践研修の内容も確認できます。

参考：IBM公式ドキュメント（DSPJOBLOG）

本記事で扱った DSPJOBLOG の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。

• Display Job Log (DSPJOBLOG) – IBM Documentation