AS400保守で業務理解がないと設計できない理由｜現場で差が出る確認ポイント

AS400 / IBM iの保守では、RPGやCLを読めるだけでは足りません。現場で本当に差が出るのは、受注、在庫、出荷、請求、締め、EDIの流れを理解し、どこを変えると誰の業務に影響するかを説明できるかです。

25年以上AS400の現場を見ていると、障害の原因は「コマンドを知らない」だけではありません。むしろ、業務を理解しないまま設計し、テスト観点を落とし、本番反映後に締めや外部連携で崩れるケースが目立ちます。

業務理解がないと設計できない場面

場面	業務理解が必要な理由	確認すること
請求締め	売上、返品、赤伝、税計算、再締めの影響がつながるため	締め前後で変更してよいデータ、再計算条件、戻し手順
出荷確定	在庫、物流、EDI、納品予定に影響するため	出荷済み、未出荷、二重送信、相手先受信状況
EDI	相手先が絡み、物が届かない、請求がずれるなど社外影響が出るため	送信先、送信データ、本番/テスト環境、再送条件
在庫照会	画面に見える数量と、引当、移動、棚卸、出荷予定が違うため	どの数量を見ているか、更新タイミング、締め反映
RPG/CL改修	ソース上の分岐だけでは、業務上の意味が分からないため	入力、更新ファイル、後続ジョブ、例外運用

技術力だけで進めると起きやすい事故

• テストデータをEDI本番送信してしまう
• 締め後のデータを修正して、請求や在庫が合わなくなる
• 帳票やPDFは出ているのに、業務側が見る場所を誤解する
• 5250画面だけを見て、Web側や外部連携の結果を見落とす
• 読み解きにくいRPG/CLを一部だけ読んで、後続処理を壊す

設計前に聞くべき現場質問

• この処理は、受注、在庫、出荷、請求のどこに関係するか
• 夜間バッチ、締め処理、EDI送信のどのタイミングで動くか
• 失敗した場合、誰がいつ気づくか
• 戻す場合、データを戻すのか、再送するのか、再計算するのか
• 本番とテストで、ライブラリ、送信先、マスタ、ジョブスケジュールは同じか

業務知識をどう身につけたか

業務理解が要る、という話はここまで書いてきました。では実際にどう身につけるのか。自分の場合を正直に書きます。きれいな話ではありません。

1年目は、言われたことをこなすだけで精一杯だった

入社1年目の頃は、とにかく言われたことをこなすだけで精一杯でした。業務を理解しようという余裕はありません。渡された作業を終わらせることしか考えていませんでした。

別のところで「言われたことしかやらない人には任せられない」と書いていますが、自分も最初はそうでした。そこは正直に書いておきます。習熟の速さは、任される範囲や周囲の支援によっても変わります。

問題は、そこから動いたかどうかです。差がつくのは1年目の出来ではなく、その次に何をしたかです。

きっかけは、出世と給料だった

変わったきっかけは、出世したい、給料を多くもらいたいという意識を持ったことです。技術が好きだから、という話ではありませんでした。

そこから、先輩のアドバイスを受けたり、真似をするようになりました。どう聞いているか、どこを確認しているか、客先でどう話しているか。手本が近くにいたのは大きかったと思います。

若手に業務を覚えてほしいと考えている場合、この順序は参考になるはずです。私の場合は、自分が何のために学ぶのかを意識できたことが転機でした。そして手本になる人を近くに置くことです。

「分かった」と感じたのは、客と対等に話せるようになった時

業務が分かったと感じたのは、お客さんと対等に話ができるようになった時です。

言われたことを確認するだけの会話から、こちらから業務の話ができる状態に変わった時点が境目でした。分量や年数ではなく、会話が成立するかどうかが基準になります。

これは自己評価しやすい指標だと思います。相手の話を自分の言葉で説明し、確認が必要な点を持ち帰れているかを見ます。知らない用語を調べ直すことは、経験者にも必要です。

覚える方法は、仕様を詰める場に入ること

では何をすれば覚えられるか。答えははっきりしています。お客さんと打ち合わせをして、仕様を詰めるところから参画することです。

設計が固まった後に「これを作ってください」と渡されるだけでは、業務上の判断の背景を学びにくくなります。なぜその仕様になったのか、何を捨てたのか、どこで揉めたのかが見えないからです。決まる前の会話にいるかどうかで、身につくものが変わります。

そして正直に言うと、これができていない人が多すぎます。コーディングだけを長年やっていて、客先の打ち合わせに一度も入ったことがない、という技術者は珍しくありません。本人の意欲以前に、そういう機会が与えられていないという構造の問題でもあります。

関わる段階	身につくもの
コーディングだけ	言語と書き方を学べるが、仕様を決めた理由は別途確認が必要
テスト・障害対応から	業務の流れは見えてくる。ただし断片的
仕様を詰める場から	なぜその処理なのかが分かる。業務が身につく

若手を育てたい会社であれば、研修より先に、打ち合わせへ同席させることのほうが効く場合があります。発言しなくても構いません。決まっていく過程を見せることに意味があります。

何を聞くかはAS400業務ヒアリングシートにまとめています。ただし質問リストがあっても、その場にいなければ使えません。まず入ることが先です。

業務が分かったと感じたのは、客に「それは非効率です」と言えた時でした

私が業務理解を実感したのは、知識のテストとは別の場面でした。私の場合、お客様が明らかに非効率なことを言った時に、対等の立場で指摘できるようになった時が、その分かれ目でした。

言われた通りに作るだけなら、業務を知らなくてもできます。仕様書のとおりに実装できても、その仕様自体が現在の業務に合うとは限りません。ですが、その仕様が業務として遠回りをしている時に、気づけるかどうかは別の話です。

気づいても、業務を知らなければ言えません。「なぜ非効率なのか」を、相手の業務の言葉で説明できないと、ただの反対意見になってしまいます。受注から出荷、請求までの流れが頭に入っていて初めて、「その手順だと締めの時に手戻りが出ます」という形で話せます。

ここまで来ると、お客様との関係が変わります。作業を渡される相手から、相談される相手になります。若手を育てる時も、最終的にこの状態を目指すことになります。コマンドを覚えることが目的ではありません。

信頼されるAS400担当者に必要なこと

AS400保守では、技術説明だけでなく、業務担当者や外部ベンダーと会話できることも重要です。説明の分かりやすさ、レスポンス、身だしなみや清潔感を含めた基本的な信頼感は、現場で安心して任せてもらうための土台になります。

特に本番障害やEDIトラブルでは、焦っている相手に対して「今どこまで分かっているか」「次に何を確認するか」を短く説明できる人が重宝されます。

Codexを使うなら業務理解とセットにする

Codexは、読み解きにくいRPG/CLソースを整理し、処理概要、更新ファイル、呼び出し関係、テスト観点をまとめる用途に向いています。ただし、AIの要約だけでは業務判断はできません。ソース解析の結果を、締め、出荷、在庫、EDIなどの業務文脈に戻して確認することが大切です。

AS400現場でAIを安全に使う流れは、AS400のRPGソースをAIに読ませる時の注意点｜本番データ・機密情報を守る考え方 で、入力してよい情報と人が検証する範囲を確認してください。

25年でどんな業務領域を担当してきたかは運営者のAS400実務経験に書いています。流通業の販売管理を中心に、受注から請求までを見てきた前提での話です。

業務が分かると、部分改修で対応するか、基盤やシステムの更新まで検討するかを説明しやすくなります。判断材料は、IBM iの継続利用と移行を考えるロードマップにまとめています。

聞き取った内容を設計とテストへつなげる

聞いたこと	設計に残すこと	確認方法
誰が、いつ確定するか	更新を許す状態と権限、締め時刻の境界	締め前後・担当者別に同じ操作を比較する
取消・返品・再送はどう扱うか	元取引との関係、戻す対象、重複防止	通常処理だけでなく取り消した後の残高を照合する
現場が手で直す箇所はあるか	手修正が必要な理由と、仕様へ取り込む範囲	修正前後の値と後続帳票・連携の結果を確認する

聞いた説明がソースや稼働結果と違う場合は、「現行の動き」「業務上期待する動き」「未確認」を分けて記録します。業務ヒアリングシートを使い、業務責任者の確認を得てから仕様として確定してください。