AS400 / IBM i のRPGやCL保守では、ソースをライブラリやメンバーで管理している現場が多くあります。一方で、担当者交代、AI活用、レビュー、変更履歴、障害時の切り戻しを考えると、Gitやソース管理の考え方を少しずつ取り入れる価値があります。
この記事では、AS400現場でGit・ソース管理を始める前に確認することを、ソース所在、コンパイル手順、変更管理、レビュー、CodexなどのAI活用に分けて整理します。いきなり本番運用を変えるのではなく、まず「読める・戻せる・説明できる」状態を作るための入口です。
最初に棚卸しするもの
| 確認項目 | 見る理由 | 関連ページ |
|---|---|---|
| ソースライブラリ | どこが正本か分からないとGit化できない | 開発ツール比較 |
| ソース物理ファイル | QRPGSRC、QCLSRC、QDDSSRCなどを整理する | RPGの読み方 |
| コンパイル手順 | 変更後に同じ手順でオブジェクトを作れるようにする | RPG保守入門 |
| 参照関係 | 変更影響を確認する | DSPPGMREF影響調査 |
| バッチ・JOBD | コンパイル後の実行経路を把握する | JOBQ・JOBSCDE確認 |
Git化する前に決めること
Gitは便利ですが、AS400の運用にそのまま当てはめると混乱することがあります。ソースの正本、反映タイミング、レビュー担当、コンパイル責任、緊急修正時の扱いを決めてから始めるのが安全です。
- Git上のソースとIBM i上のソースメンバーのどちらを正本にするか
- 本番反映前にレビューを必須にするか
- 変更理由、依頼番号、障害番号をコミットに残すか
- コンパイルリストやエラーをどこに保存するか
- 緊急修正後にGitへ戻すルールをどうするか
いきなりやらない方がよいこと
- 正本を決めずに一部ソースだけGitへコピーする
- 本番ソースを直接書き換える運用のままAI生成コードを混ぜる
- コンパイル手順やライブラリリストを記録せずに変更する
- ジョブ、画面、帳票、外部連携の影響調査なしに反映する
- 担当者だけが分かるローカル手順を正式手順にしてしまう
AI活用とソース管理
CodexなどのAIをAS400保守に使う場合、ソース管理はさらに重要になります。AIにRPGやCLを読ませる前に、対象範囲、機密情報、変更禁止箇所、テスト観点、レビュー担当を決める必要があります。AIが出した修正案も、人間が差分を確認し、コンパイルと業務影響を検証してから反映します。
AI活用の進め方は、AS400向けCodex研修と、AS400保守にCodexを使う時の考え方も合わせて確認してください。
小さく始める手順
最初は、本番運用を変えずに読み取り専用の棚卸しから始めます。主要プログラム、主要CL、DDS、コンパイル手順、ジョブログ、夜間バッチの流れを整理し、Gitに置く場合も「現状記録」として扱うのが安全です。
- 変更頻度の高いRPG/CLを10本だけ選ぶ
- ソース、関連DDS、コンパイルコマンド、実行ジョブを記録する
- Gitへ保存し、変更履歴を見える化する
- レビュー観点を作る
- 次にCodexで読みやすい説明メモを追加する
まとめ
AS400のGit・ソース管理は、流行の開発手法をそのまま入れる話ではありません。ソースの正本、コンパイル手順、変更理由、レビュー、切り戻しを見える化し、RPG/CL保守を属人化から少しずつ外すための基盤です。AI活用やCodex研修を進める前にも、まずソース管理と変更管理を整えておくと安全です。
