AS400 / IBM i の改修依頼は、「この項目を追加して」「この帳票を変えて」の一言で始まることがあります。しかし、RPG/CL、ファイル、帳票、夜間バッチ、外部連携がつながっている場合、依頼内容だけで作業を始めると影響漏れが起きます。変更依頼の時点で、業務目的と戻しまで確認します。
変更依頼で聞く項目
| 項目 | 聞くこと | 理由 |
|---|---|---|
| 業務目的 | 何の業務を改善したいか | 見た目だけの修正を避ける |
| 対象 | 画面、帳票、バッチ、ファイル | 影響範囲を絞る |
| 期限 | 締め日、出荷日、運用開始日 | 本番反映日を決める |
| 確認者 | 利用部門、保守担当、承認者 | 誰がOKを出すか明確にする |
| 戻し | 失敗時に元へ戻せるか | 本番事故を防ぐ |
改修前に影響調査を入れる
RPG/CLの小改修でも、呼び出し元、使用ファイル、帳票、後続バッチ、外部連携を確認します。特に請求締めや出荷確定のような業務は、1項目の変更が後続処理に影響することがあります。
依頼書にCodexを使う
Codexには匿名化した依頼内容を渡し、確認項目や影響調査メモのたたき台を作らせる使い方ができます。本番データや顧客名は入れず、最終判断は人が行います。
影響調査は AS400 RPG/CL影響調査チェックリスト、テストは テスト・エビデンスチェックリスト、本番反映は 本番反映・戻し手順チェックリスト、リリース直前の判断は AS400本番反映Go/No-Goチェックリスト、マスタ変更が絡む場合は AS400マスタ変更の影響調査チェックリスト を参照してください。
依頼書に残す戻し・承認
変更依頼は、開発担当へ渡す指示書であると同時に、あとから「なぜ変えたか」を確認する証跡です。特に本番作業では、戻し方と承認者が曖昧な依頼をそのまま進めないようにします。
| 残す項目 | 書く内容 | 止める判断 |
|---|---|---|
| 業務影響 | 受注、出荷、請求、在庫、帳票、連携 | 影響範囲が空欄のまま |
| 確認者 | 利用部門、保守担当、承認者 | 誰がOKを出すか不明 |
| 戻し手順 | プログラム、マスタ、データ、ジョブの戻し方 | 戻せる単位が説明できない |
| 本番判断 | 実施日時、停止条件、連絡先 | 締め処理や外部連携とぶつかる |
小改修を変更依頼へ落とす例
「帳票へ項目を一つ追加する」という依頼でも、データ取得元と下流影響が曖昧なら本番事故につながります。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 目的 | 誰が何の判断に使う項目か、現在の代替手段は何か | 見た目だけでなく業務目的を確定する |
| 影響 | RPG、CL、ファイル、帳票、CSV、外部連携、権限を確認する | 変更対象外も記録する |
| 反映 | テスト条件、承認者、作業時間、戻し対象、No-Go条件を決める | 旧版へ戻すだけでデータも戻るか確認する |
依頼票には期待結果を具体的な入力値と出力値で書きます。「問題なく動くこと」だけでは、テスト担当と依頼者の合格基準が一致しません。
関連するAS400確認ルート
変更依頼は、RPG/CLの修正内容だけでなく、業務目的、影響範囲、戻し方、テスト観点をそろえる入口です。AIで解析する場合も、依頼内容が曖昧だと良い結果になりません。
変更依頼で必ず分けて書く項目
AS400 / IBM i の変更依頼では、「何を変えるか」だけでなく、「どの業務に影響するか」を分けて書きます。RPGやCLの修正は小さく見えても、締め処理、夜間バッチ、帳票、EDI、在庫引当、請求金額に影響することがあります。
| 項目 | 書く内容 | 確認する理由 |
|---|---|---|
| 変更目的 | 業務上なぜ必要か | 仕様変更と不具合修正を分けるため |
| 対象範囲 | 画面、帳票、バッチ、ファイル、連携先 | 影響調査の抜けを防ぐため |
| 確認方法 | 入力条件、期待結果、照合先 | 受入確認を属人化させないため |
| 戻し方 | プログラム戻し、データ戻し、停止判断 | 本番反映後の事故を小さくするため |
依頼文だけで判断しない
依頼文に「項目を追加するだけ」「計算式を変えるだけ」と書かれていても、実際には複数プログラムや帳票に影響することがあります。変更前には DSPPGMREF、DSPFFD、ジョブログ、既存帳票、利用部門への確認を合わせて見ます。依頼内容が曖昧な場合は、作業を急がず、業務担当者に確認条件を聞き直す方が安全です。