AS400 / IBM iの変更依頼は、業務目的、変更前後の動き、対象外の範囲、受入条件、本番反映と戻し方を1枚にまとめてから保守担当へ渡します。「帳票に項目を追加して」だけでは、表示する値、過去データの扱い、CSVや夜間バッチへの影響が決まりません。
以下は社内の依頼票やメールへコピーして使えるひな形です。業務担当者が分かる部分を先に記入し、プログラム名や復旧方法は保守担当が調査して追記します。分からない欄は推測で埋めず、「未確認・確認担当・回答期限」を残してください。
コピーして使える変更依頼票
【依頼名・管理番号】 【依頼部門・担当者】 【業務目的】誰が、何に困っていて、何を改善したいか 【現在の動き】操作手順、入力条件、現在の出力 【変更後の動き】変更する値・表示・計算・処理条件 【対象】画面、帳票、バッチ、ファイル、CSV・外部連携 【対象外】今回変更しない業務・画面・出力 【既存データ】過去分の更新・再出力の要否 【受入条件】入力例、期待結果、照合先、確認者 【希望日・理由】締め日など動かせない条件 【未確定事項】質問、確認担当、回答期限 --- 以下は保守担当と合意して記入 --- 【調査対象】ライブラリ、オブジェクト、呼出し元・先 【影響範囲】関連処理、権限、実行時間、後続ジョブ 【反映手順】退避対象、反映順、確認方法、担当者 【中止条件】実施を見送る条件・連絡先 【戻し方】プログラム・データ・送信済み情報を分ける 【承認】仕様確認者、受入確認者、本番実施承認者
依頼票へ添付する画面や帳票には、調査に不要な顧客名、実データ、個人情報を含めないようにします。外部のAIへ相談する場合は、会社の利用規程に従い、架空の値へ置き換えた説明だけを使います。
記入例：出荷一覧へ希望納品日を追加する
以下は依頼の書き方を説明するための架空例です。実際の顧客案件や導入実績ではありません。仕様を決めた項目と、調査が必要な項目を分けて書きます。
| 項目 | 記入例 |
|---|---|
| 目的 | 出荷担当が一覧から希望納品日を確認できるようにし、受注画面を開き直す手間を減らす。 |
| 変更内容 | 出荷一覧の出荷日欄の右に希望納品日を表示する。未入力の場合は空欄とし、ゼロ日付を印字しない。 |
| 対象外 | CSV、EDI、請求書、納品日の自動計算は今回変更しない。ただし共通処理への影響がないかは調べる。 |
| 過去分 | 確定済み出荷の再出力は、出荷確定時の希望納品日を表示したい。履歴が保存されているかは未確認。 |
| 未確定事項 | 受注明細と出荷明細のどちらに値があるか、履歴がない場合にどう表示するかを保守担当と業務担当が確認する。 |
| 承認 | 業務担当が表示内容を確認し、保守担当が関連処理と性能を確認した後、本番実施責任者が承認する。 |
この例で先に決めるべきなのは、現在の受注データを読むのか、出荷確定時の値を読むのかです。ここが曖昧なまま開発すると、過去の帳票を再印刷した時に表示が変わる可能性があります。履歴がないことが分かったら、仕様と見積もりを合意し直します。
受入条件は入力と期待結果を対で書く
「問題なく印刷できること」だけでは合否を決められません。業務担当が判断できる値と、変更しない部分の確認も依頼票に残します。
| 入力・条件 | 期待結果 | 照合するもの |
|---|---|---|
| 希望納品日が2026年10月15日 | 合意した形式で2026/10/15を表示する。 | 確認済みの元データと印刷結果 |
| 希望納品日が未入力 | 空欄になり、異常終了やゼロ日付の印字がない。 | 未入力のテストデータとジョブログ |
| 確定後に受注側の日付を変更して再出力 | 確定時の値を表示するという合意仕様を満たす。履歴を保持できない場合は仕様確定まで保留する。 | 出荷時の記録と再印刷結果 |
| 既存の出荷データを出力 | 数量・金額・並び順が変わらず、追加欄で文字が欠けない。 | 同一条件の変更前後の帳票 |
| CSV・EDIを実行 | 今回の対象外である出力の項目数・内容が変わらない。 | 合意した回帰テストの結果 |
保守担当が調査して追記する範囲
同じ名前のオブジェクトでも、ライブラリが違えば別物です。環境とライブラリを特定し、RPG、CL、画面・帳票定義、使用ファイル、呼出し元、夜間バッチを確認します。DSPPGMREFの参照情報とDSPFFDのフィールド情報は調査の入口ですが、それだけで動的呼出しや実行時のオーバーライドまで網羅したとは判断しません。ソース、実行手順、ジョブログ、業務担当への確認を組み合わせます。
業務条件が決まらない場合は業務ヒアリングシート、ファイル定義の調査はDSPFFD・DSPPFMの確認手順を使って整理します。参照情報の範囲はIBM公式資料：プログラムが使用するオブジェクトの表示も確認してください。
本番反映と戻しを分けて合意する
プログラムを旧版へ戻しても、更新済みデータや送信済みのEDIは自動では戻りません。依頼票には、プログラムの退避、データ変更の有無、送信済み情報への対応、確認者を分けて書きます。データを変更しない帳票改修でも、共通処理や出力先への影響は確認が必要です。
- 仕様や受入条件が未承認なら、本番反映を見送る。
- 退避・復旧手順が確認できない場合や、締め・出荷処理と競合する場合は中止する。
- 反映後は、対象帳票だけでなく合意した関連処理とジョブログを確認する。
- 不一致が出た場合は証跡を残し、処理継続・戻し・補正のどれを選ぶか責任者が判断する。
実施前の確認は本番作業の確認手順、データ更新を伴う変更はジャーナルとコミットメント制御の確認と合わせて検討してください。
Codexを依頼内容の整理に使う場合
匿名化した依頼内容から「未確定の条件」「影響調査の質問」「受入テスト候補」を出す用途に使えます。たとえば「次の架空の帳票改修について、日付未入力・過去分再印刷・対象外出力の確認質問を列挙し、分からない仕様は補完せず質問として残して」と依頼します。実機調査や業務承認の代わりにはせず、提案された条件を担当者が確認して依頼票へ転記します。
