AS400 / IBM iの保守では、RPGやCLを読めるだけでは足りません。現場で本当に差が出るのは、受注、在庫、出荷、請求、締め、EDIの流れを理解し、どこを変えると誰の業務に影響するかを説明できるかです。
25年以上AS400の現場を見ていると、障害の原因は「コマンドを知らない」だけではありません。むしろ、業務を理解しないまま設計し、テスト観点を落とし、本番反映後に締めや外部連携で崩れるケースが目立ちます。
業務理解がないと設計できない場面
| 場面 | 業務理解が必要な理由 | 確認すること |
|---|---|---|
| 請求締め | 売上、返品、赤伝、税計算、再締めの影響がつながるため | 締め前後で変更してよいデータ、再計算条件、戻し手順 |
| 出荷確定 | 在庫、物流、EDI、納品予定に影響するため | 出荷済み、未出荷、二重送信、相手先受信状況 |
| EDI | 相手先が絡み、物が届かない、請求がずれるなど社外影響が出るため | 送信先、送信データ、本番/テスト環境、再送条件 |
| 在庫照会 | 画面に見える数量と、引当、移動、棚卸、出荷予定が違うため | どの数量を見ているか、更新タイミング、締め反映 |
| RPG/CL改修 | ソース上の分岐だけでは、業務上の意味が分からないため | 入力、更新ファイル、後続ジョブ、例外運用 |
技術力だけで進めると起きやすい事故
- テストデータをEDI本番送信してしまう
- 締め後のデータを修正して、請求や在庫が合わなくなる
- 帳票やPDFは出ているのに、業務側が見る場所を誤解する
- 5250画面だけを見て、Web側や外部連携の結果を見落とす
- 読み解きにくいRPG/CLを一部だけ読んで、後続処理を壊す
設計前に聞くべき現場質問
- この処理は、受注、在庫、出荷、請求のどこに関係するか
- 夜間バッチ、締め処理、EDI送信のどのタイミングで動くか
- 失敗した場合、誰がいつ気づくか
- 戻す場合、データを戻すのか、再送するのか、再計算するのか
- 本番とテストで、ライブラリ、送信先、マスタ、ジョブスケジュールは同じか
業務知識をどう身につけたか
業務理解が要る、という話はここまで書いてきました。では実際にどう身につけるのか。自分の場合を正直に書きます。きれいな話ではありません。
1年目は、言われたことをこなすだけで精一杯だった
入社1年目の頃は、とにかく言われたことをこなすだけで精一杯でした。業務を理解しようという余裕はありません。渡された作業を終わらせることしか考えていませんでした。
別のところで「言われたことしかやらない人には任せられない」と書いていますが、自分も最初はそうでした。そこは正直に書いておきます。1年目でそれができる人はまずいません。
問題は、そこから動いたかどうかです。差がつくのは1年目の出来ではなく、その次に何をしたかです。
きっかけは、出世と給料だった
変わったきっかけは、出世したい、給料を多くもらいたいという意識を持ったことです。技術が好きだから、という話ではありませんでした。
そこから、先輩のアドバイスを受けたり、真似をするようになりました。どう聞いているか、どこを確認しているか、客先でどう話しているか。手本が近くにいたのは大きかったと思います。
若手に業務を覚えてほしいと考えている場合、この順序は参考になるはずです。好奇心や向上心を待つより、本人に動く理由があるかどうかのほうが効きます。そして手本になる人を近くに置くことです。
「分かった」と感じたのは、客と対等に話せるようになった時
業務が分かったと感じたのは、お客さんと対等に話ができるようになった時です。
言われたことを確認するだけの会話から、こちらから業務の話ができる状態に変わった時点が境目でした。分量や年数ではなく、会話が成立するかどうかが基準になります。
これは自己評価しやすい指標だと思います。打ち合わせで相手の話を業務として理解できているか、それとも用語を持ち帰って後で調べているか。後者ならまだ途中です。
覚える方法は、仕様を詰める場に入ること
では何をすれば覚えられるか。答えははっきりしています。お客さんと打ち合わせをして、仕様を詰めるところから参画することです。
設計が固まった後に「これを作ってください」と渡される立場では、業務は覚えられません。なぜその仕様になったのか、何を捨てたのか、どこで揉めたのかが見えないからです。決まる前の会話にいるかどうかで、身につくものが変わります。
そして正直に言うと、これができていない人が多すぎます。コーディングだけを長年やっていて、客先の打ち合わせに一度も入ったことがない、という技術者は珍しくありません。本人の意欲以前に、そういう機会が与えられていないという構造の問題でもあります。
| 関わる段階 | 身につくもの |
|---|---|
| コーディングだけ | 言語と書き方。業務は身につかない |
| テスト・障害対応から | 業務の流れは見えてくる。ただし断片的 |
| 仕様を詰める場から | なぜその処理なのかが分かる。業務が身につく |
若手を育てたい会社であれば、研修より先に、打ち合わせへ同席させることのほうが効く場合があります。発言しなくても構いません。決まっていく過程を見せることに意味があります。
何を聞くかはAS400業務ヒアリングシートと運営者のAS400実務経験にまとめています。ただし質問リストがあっても、その場にいなければ使えません。まず入ることが先です。
業務が分かったと感じたのは、客に「それは非効率です」と言えた時でした
業務知識が身についたかどうかは、テストでは測れません。私の場合、お客様が明らかに非効率なことを言った時に、対等の立場で指摘できるようになった時が、その分かれ目でした。
言われた通りに作るだけなら、業務を知らなくてもできます。仕様書のとおりに書けば動きます。ですが、その仕様が業務として遠回りをしている時に、気づけるかどうかは別の話です。
気づいても、業務を知らなければ言えません。「なぜ非効率なのか」を、相手の業務の言葉で説明できないと、ただの反対意見になってしまいます。受注から出荷、請求までの流れが頭に入っていて初めて、「その手順だと締めの時に手戻りが出ます」という形で話せます。
ここまで来ると、お客様との関係が変わります。作業を渡される相手から、相談される相手になります。若手を育てる時も、最終的にこの状態を目指すことになります。コマンドを覚えることが目的ではありません。
信頼されるAS400担当者に必要なこと
AS400保守では、技術説明だけでなく、業務担当者や外部ベンダーと会話できることも重要です。説明の分かりやすさ、レスポンス、身だしなみや清潔感を含めた基本的な信頼感は、現場で安心して任せてもらうための土台になります。
特に本番障害やEDIトラブルでは、焦っている相手に対して「今どこまで分かっているか」「次に何を確認するか」を短く説明できる人が重宝されます。
Codexを使うなら業務理解とセットにする
Codexは、読み解きにくいRPG/CLソースを整理し、処理概要、更新ファイル、呼び出し関係、テスト観点をまとめる用途に向いています。ただし、AIの要約だけでは業務判断はできません。ソース解析の結果を、締め、出荷、在庫、EDIなどの業務文脈に戻して確認することが大切です。
AS400現場でAIを安全に使う流れは、AS400のRPGソースをAIに読ませる時の注意点｜本番データ・機密情報を守る考え方 と AS400 / IBM i 現場向けCodex実戦研修 も参考にしてください。
25年でどんな業務領域を担当してきたかは運営者のAS400実務経験に書いています。流通業の販売管理を中心に、受注から請求までを見てきた前提での話です。
業務が分かると、部分改修で対応するか、基盤やシステムの更新まで検討するかを説明しやすくなります。判断材料は、IBM iの継続利用と移行を考えるロードマップにまとめています。
業務理解と設計判断の要点
AS400保守で設計できる人は、RPGやCLだけでなく、業務の流れと運用の例外を見ています。締め処理、EDI、在庫、請求、出荷確定のような現場影響が大きい領域では、技術力と業務理解をセットで育てることが、障害を減らす近道です。
業務が分からないと、AS400の設計は起こせない
AS400保守で設計ができない原因は、RPGやCLの文法不足だけではありません。画面、帳票、ファイル、ジョブ、EDI、締め処理、出荷、請求のどこに影響するかを理解できないと、変更範囲、テスト範囲、戻し方、利用部門への説明を決められません。業務が理解できないと設計を起こせない、というのが現場の実感です。
| 設計前に確認すること | 理由 |
|---|---|
| 業務名と利用部門 | 誰の作業が止まるかを判断する |
| 画面・帳票・ファイル | 改修対象と確認対象を分ける |
| 夜間バッチ・締め処理 | 反映時刻、リラン、戻し方を決める |
| EDI・外部連携 | 相手先への影響と再送可否を確認する |
| 例外処理と運用ルール | 通常処理だけでは見えない事故を防ぐ |
外部担当者の面談では業務説明力を見る
外部エンジニアやビジネスパートナーを面談する時は、AS400経験年数やコマンド名だけでなく、担当した業務、触ったファイル、改修の目的、利用部門に確認したこと、障害時にどう説明したかを具体的に聞きます。案件期間が1か月や3か月で続く場合は、短期支援なのか、契約が早く終わったのか、現場での会話や設計力に課題がなかったかも確認します。
AS400保守では、現場コミュニケーションや身だしなみを含めた信頼感も大切です。利用部門が安心して話せる相手でなければ、業務の例外、締め日の事情、相手先との約束、過去の運用回避策が出てきません。技術力と業務理解をセットで見ることが、改修後の手戻りを減らします。
