AS400 / IBM i の担当者が退職する、またはすでに不在になっている会社では、最初に何を引き継ぐかで保守の安定性が変わります。RPGやCLのソースを全部読む前に、業務、ジョブ、ファイル、障害対応、連絡先を整理しないと、本番障害や小改修のたびに調査が止まります。
研修対象として合っているか迷う場合は、先に AS400若手エンジニア育成カリキュラム｜IBMi保守を引き継ぐ学習順 を確認してください。
まず集めるべき引き継ぎ資料
| 資料 | 最低限ほしい内容 | 使う場面 |
|---|---|---|
| 業務一覧 | 在庫照会、請求締め、出荷確定などの業務名 | 問い合わせの影響範囲を判断する |
| 日次・月次バッチ一覧 | ジョブ名、実行時刻、JOBQ、後続処理 | 夜間バッチ停止時に確認する |
| 主要プログラム一覧 | RPG/CL、呼び出し順、担当業務 | 小改修や障害調査で見る |
| 主要ファイル一覧 | 物理ファイル、論理ファイル、更新タイミング | データ抽出や不整合調査で見る |
| 障害対応メモ | MSGW、CPF/RNX、再実行手順、連絡先 | 本番障害の初動で見る |
退職前に必ず聞く質問
- 夜間バッチが止まった時、最初に見るジョブはどれか
- MSGWが出た時、返信してよいものと止めるものは何か
- 請求締め、出荷確定、在庫更新で再実行してはいけない処理はどれか
- プログラム修正後、どのテストデータで確認しているか
- 本番反映、バックアップ、戻し手順は誰が承認しているか
ソースより先に業務と運用を押さえる
引き継ぎでありがちなのは、RPGソースやCLだけを集めて安心してしまうことです。しかし、現場で困るのは「どの業務に影響するか」「再実行してよいか」「誰へ連絡すべきか」が分からない時です。ソース調査は大切ですが、業務名とジョブ名、ファイル名がつながっていないと判断しにくくなります。
本番障害時の確認順は、AS400本番障害の初動チェックリストと、AS400ジョブログの見方に整理しています。
若手に渡すならコマンド逆引きも用意する
若手へ引き継ぐ場合は、コマンド名だけを渡しても使いこなせません。「ジョブを見る」「ジョブログを見る」「ファイル定義を見る」「ライブラリを確認する」のように目的別に整理しておくと、調査の入口で迷いにくくなります。
目的から調べる場合は、AS400コマンド逆引き、学習順を整理する場合は AS400初心者向け学習ロードマップ を入口にできます。
引き継ぎが間に合わない時の優先順位
| 優先度 | やること | 理由 |
|---|---|---|
| 高 | 夜間バッチと締め処理を押さえる | 業務停止や二重処理のリスクが高い |
| 高 | MSGWとジョブログの見方を残す | 障害時の初動が遅れるため |
| 中 | 主要ファイルとライブラリを整理する | 調査・抽出・小改修の入口になるため |
| 中 | RPG/CLの主要処理だけ説明を残す | 全部読めなくても影響調査に使えるため |
| 低 | 古い設計書を完全に直す | 時間がかかるため、まず現行運用を優先する |
Codexで引き継ぎ資料を整理する時
Codexは、ジョブログ、CLの流れ、RPGソースの処理概要、テスト観点を整理する用途と相性があります。利用するサービスに資料やソースを渡せるかは、契約・社内規程を先に確認してください。許可範囲でも本番データ、会社名、取引先名、ユーザー名などを除き、「何を確認すべきか」の整理に使います。匿名化しても送信禁止の資料は渡さず、生成された説明は実際の処理や運用と照合します。
引き継ぎ先は、社内とは限らない
引き継ぎというと、社内の後任者に渡すことを想像します。ただ現場を見ていると、お客様先でも転職や退職で人材の流動がそれなりにあります。業務を分かっている担当者が数年で入れ替わることは珍しくありません。
つまり、今つくっている引き継ぎ資料は、数年後に業務側の新しい担当者へ説明する時にも使うことになります。相手はシステムの人とは限りません。
「前提を共有していない人」向けに書く
ここが分かれ目です。同僚に渡すつもりで書くと、社内の常識を省略します。「例の締め処理」「いつものバッチ」で通じてしまうので、書かなくなります。数年後、その言葉が通じる人はもう社内にいないかもしれません。
| 書き方 | 渡せる相手 | 数年後 |
|---|---|---|
| 社内の同僚向け | 前提を共有している人だけ | 用語が通じず読めなくなる |
| 前提を共有していない人向け | 後任者、業務側の新担当、外部パートナー | そのまま説明資料として使える |
具体的には、処理の名前だけでなく何のための処理か、ファイル名だけでなくどの業務のデータかを添えます。用語も自社の言い方をそのまま書くのではなく、一般的な言い方を併記しておくと、外から来た人に通じます。業務と用語の確認項目は、業務ヒアリングシートも使って整理してください。
相手が変わっても残るように
この書き方をしておくと、引き継ぎ資料が一回きりの受け渡しで終わりません。後任者へ渡し、数年後に業務側の新しい担当者へ説明し、外部へ相談する時の説明にも使えます。同じ資料が三回役に立ちます。
逆に、社内の常識に依存した資料は、人が入れ替わった瞬間に価値がなくなります。引き継ぎに時間をかけたのに残らなかった、という結果になりやすいのはこのパターンです。
引き継ぐ相手が業務を覚えられるかどうかは、業務理解をどう身につけたかに書いた経緯が参考になるはずです。仕様を詰める場に入れるかどうかで変わります。
引き継ぎ後に研修化した方がよいサイン
引き継ぎ資料を作っても、次の担当者がジョブログの見方、RPG/CLの読み方、月次処理の確認ポイントを説明できない状態なら、資料だけでは不足しています。特に、障害時に「どの画面を見ればよいか」「どのメッセージを優先するか」「保守会社へ何を伝えるか」が人によって変わる場合は、引き継ぎを研修化しておくと、退職後の問い合わせ集中を減らせます。
- 若手・後任者の学習順を作るなら、AS400若手エンジニア育成カリキュラムを先に整理します。
- ソース調査も引き継ぐなら、AS400業務ヒアリングシート｜保守・改修前に現場へ聞くべき質問で確認項目を分けます。
- Codexを使って調査・説明・証跡作成を型にするなら、AS400 / IBM i 現場向けCodex実践研修が向いています。
引き継ぎ資料が無い現場に入った時、私がやったこと
前任者がいない状態で入る現場があります。資料は古く、前任のシステム担当者には確認できません。
その時にやったのは、分からないところをとにかくヒアリングすることでした。お客様にも、社内の関係者にも聞きます。そして聞いた内容を、自分の中で仕様として落とし込み直します。
資料を読んで理解するのではなく、聞いた話を自分の言葉で組み立て直す作業です。この工程を飛ばして「資料が無いので分かりません」で止めると、いつまでも分からないままになります。逆に言えば、引き継ぎ資料が完璧でなくても、聞ける相手が残っていれば何とかなります。引き継ぎで本当に困るのは、資料が無いことより、聞ける人が誰もいなくなることです。