AS400 / IBM i の本番反映では、「準備したから実施する」ではなく、直前に止める判断を入れることが大切です。テスト、承認、バックアップ、戻し手順、夜間バッチ、利用部門確認がそろっていなければ、GoではなくNo-Goにする勇気が必要です。
Go/No-Goで見る項目
| 項目 | Go条件 | No-Go例 |
|---|---|---|
| 承認 | 利用部門と保守責任者が承認済み | 口頭だけ、確認者不在 |
| テスト | 正常系・異常系・帳票確認済み | 画面確認だけ |
| バックアップ | 戻しに必要な保存がある | 戻し先や媒体が不明 |
| 戻し手順 | 誰が何を戻すか決まっている | 失敗時に考える予定 |
| 業務影響 | 夜間バッチや締め処理と衝突しない | 重要処理中に反映する |
No-Goを責めない文化にする
直前に問題が見つかった時、止める判断ができる現場は強いです。本番反映は、実施することが目的ではなく、業務を安全に変えることが目的です。準備不足なら延期します。
Codexで直前チェックを作る
Codexには、匿名化したリリース内容、確認済み項目、戻し手順を渡し、Go/No-Go表のたたき台を作れます。実行判断は人が行い、AIは確認漏れ防止に使います。
本番反映の詳細は 本番反映・戻し手順チェックリスト、変更依頼は AS400変更依頼テンプレート、バックアップは バックアップ・復旧チェックリスト、AIでの確認漏れ防止は AS400本番反映前にAIでレビューするチェックリスト を参照してください。
No-Go後の連絡と再開条件
No-Goにした時は、単に延期するだけでなく、何が解消されれば再開できるかを残します。利用部門、保守担当、運用担当、外部連携先に、停止理由と次の判断時刻を共有します。
| 残すこと | 例 | 再開条件 |
|---|---|---|
| 停止理由 | 承認未完了、戻し手順未確認、バックアップ未取得 | 不足項目が確認済みになる |
| 業務影響 | 締め処理、夜間バッチ、外部送信との衝突 | 影響時間帯を避けられる |
| 連絡先 | 利用部門、運用担当、保守責任者 | 再開判断者がそろう |
| 次回判断 | 再実施日時、確認期限、再テスト範囲 | 再テスト結果と承認が残る |
No-Goにする具体的な条件例
チェック欄がほぼ埋まっていても、戻し担当や照合方法がない場合は反映を止める判断が必要です。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| バックアップ | 旧オブジェクトと必要データの退避が確認できない | No-Goとして準備をやり直す |
| 体制 | 業務承認者、作業者、確認者、障害連絡先がそろわない | 時間を優先して単独反映しない |
| 検証 | 本番相当データの境界テストや下流照合が未完了 | 未確認をリスク受容する決裁がなければ延期する |
Go判断には、開始条件だけでなく中止条件と切戻し開始条件を含めます。判断時刻、判断者、残課題を記録し、翌日の監視担当へ引き継ぎます。
関連するAS400確認ルート
本番反映のGo/No-Go判断では、手順があることより、止める条件が明確なことが重要です。影響範囲、戻し手順、確認担当、障害時連絡をそろえてから進めます。
Go/No-Go判断は、作業完了ではなく業務開始できるかで決める
AS400の本番反映では、プログラムを置き換えたら終わりではありません。反映後に業務を開始できるか、戻し手順が残っているか、夜間バッチや締め処理に影響しないかを確認してからGo/No-Goを判断します。特にRPG/CL、DDS、ファイル定義、JOBSCDE、外部連携を伴う変更は、反映後の確認順を事前に決めておく必要があります。
| 判断項目 | Goにできる条件 | No-Goにする条件 |
|---|---|---|
| 反映物 | 対象、世代、ライブラリ、権限が確認済み | 対象が曖昧、旧版との違いが不明 |
| 確認結果 | 起動、主要画面、バッチ、帳票、連携が確認済み | 主要確認が未完了 |
| 戻し手順 | 戻し対象と判断者が明確 | 戻せない、戻し確認がない |
| 業務影響 | 担当部署へ連絡済み、開始判断済み | 締めや出荷前に影響不明 |
| 記録 | 作業者、承認者、時刻、結果が残っている | 口頭だけで記録がない |
Go/No-Goの基準を持つと、作業者の勘や勢いで本番反映を進めることを避けられます。若手に本番作業を教える場合は、「反映する技術」だけでなく、「止める判断」を教えることが重要です。Codexを使う場合も、反映手順の抜け漏れ確認やチェックリスト作成に限定し、最終判断は人が行います。