AS400 / IBM iの保守では、RPGやCLを読めるだけでは足りません。現場で本当に差が出るのは、受注、在庫、出荷、請求、締め、EDIの流れを理解し、どこを変えると誰の業務に影響するかを説明できるかです。
25年以上AS400の現場を見ていると、障害の原因は「コマンドを知らない」だけではありません。むしろ、業務を理解しないまま設計し、テスト観点を落とし、本番反映後に締めや外部連携で崩れるケースが目立ちます。
業務理解がないと設計できない場面
| 場面 | 業務理解が必要な理由 | 確認すること |
|---|---|---|
| 請求締め | 売上、返品、赤伝、税計算、再締めの影響がつながるため | 締め前後で変更してよいデータ、再計算条件、戻し手順 |
| 出荷確定 | 在庫、物流、EDI、納品予定に影響するため | 出荷済み、未出荷、二重送信、相手先受信状況 |
| EDI | 相手先が絡み、物が届かない、請求がずれるなど社外影響が出るため | 送信先、送信データ、本番/テスト環境、再送条件 |
| 在庫照会 | 画面に見える数量と、引当、移動、棚卸、出荷予定が違うため | どの数量を見ているか、更新タイミング、締め反映 |
| RPG/CL改修 | ソース上の分岐だけでは、業務上の意味が分からないため | 入力、更新ファイル、後続ジョブ、例外運用 |
技術力だけで進めると起きやすい事故
- テストデータをEDI本番送信してしまう
- 締め後のデータを修正して、請求や在庫が合わなくなる
- 帳票やPDFは出ているのに、業務側が見る場所を誤解する
- 5250画面だけを見て、Web側や外部連携の結果を見落とす
- 解読不能なRPG/CLを一部だけ読んで、後続処理を壊す
設計前に聞くべき現場質問
- この処理は、受注、在庫、出荷、請求のどこに関係するか
- 夜間バッチ、締め処理、EDI送信のどのタイミングで動くか
- 失敗した場合、誰がいつ気づくか
- 戻す場合、データを戻すのか、再送するのか、再計算するのか
- 本番とテストで、ライブラリ、送信先、マスタ、ジョブスケジュールは同じか
信頼されるAS400担当者に必要なこと
AS400保守では、技術説明だけでなく、業務担当者や外部ベンダーと会話できることも重要です。説明の分かりやすさ、レスポンス、身だしなみや清潔感を含めた基本的な信頼感は、現場で安心して任せてもらうための土台になります。
特に本番障害やEDIトラブルでは、焦っている相手に対して「今どこまで分かっているか」「次に何を確認するか」を短く説明できる人が重宝されます。
Codexを使うなら業務理解とセットにする
Codexは、解読不能なRPG/CLソースを整理し、処理概要、更新ファイル、呼び出し関係、テスト観点をまとめる用途に向いています。ただし、AIの要約だけでは業務判断はできません。ソース解析の結果を、締め、出荷、在庫、EDIなどの業務文脈に戻して確認することが大切です。
AS400現場でAIを安全に使う流れは、AS400の解読不能なRPG/CLソースをCodexで整理する手順 と AS400 / IBM i 現場向けCodex実戦研修 も参考にしてください。
まとめ
AS400保守で設計できる人は、RPGやCLだけでなく、業務の流れと運用の例外を見ています。締め処理、EDI、在庫、請求、出荷確定のような現場影響が大きい領域では、技術力と業務理解をセットで育てることが、障害を減らす近道です。
業務理解がないと、影響範囲を設計に落とせない
AS400保守で設計ができない原因は、RPGやCLの文法不足だけではありません。ユーザーの業務、画面名、帳票、締めタイミング、外部連携を理解していないと、どこまで直せばよいか、どこをテストすべきか、誰に確認すべきかを決められません。
- 画面名やメニュー名だけでなく、その後続処理まで聞く
- 変更対象のファイル、帳票、外部連携を確認する
- ユーザーと会話できる言葉で影響範囲を説明する
- 業務ユーザーに聞くべき質問
- RPG/CL修正の影響調査チェックリスト
