PART 6 SEUからVSCodeへの移行ロードマップ ～PDM/SEUの制約、VSCodeの障壁、移行の4つのステップ　｜特集　VSCode＋生成AIで加速するIBM i開発

本稿の最初で言及した、i Magazineへのこれまでの寄稿を再度振り返ってみたい。

・2021 Spring号：インタビュー記事「IBM iの若手技術者を育てたいなら5250開発環境の脱却からスタートする」
・2021 Autumn号：特集「Git入門」
・2022 Winter号：特集「Visual Studio Code入門」
・2023 Winter号：特集「Code for IBM i」
・2023 Summer号：特集「検証ChatGPT」

この一連のシリーズで最も伝えたかったのは、「PDM/SEUではソースのバージョン管理や他の開発ツールとの連携ができないので、VSCodeにできる限り移行していきましょう」ということだ。Code for IBM iは、記事を書いた当時（約2年半前）に比べれば日本での認知度も格段にあがり、RDiと同等とまではいかなくても、かなり機能拡張が進んでいる。

そして昨今の生成AIの盛り上がりは、IBM iユーザーとしても無視できないほど大きくなっている。2023 Summer号で検証したChatGPTは、現在ではVSCodeの拡張機能（GitHub Copilot）を使って直接参照でき、ローカルLLMもContinue拡張機能を通してアクセスできることを前章までで解説した。

PDM/SEUからの脱却は、もう待ったなしのところに来ている。先ほども触れたIBM watsonx Code Assistant for i（旧RPG Code Assistant）機能は、GitHub CopilotやContinueのインターフェースとほぼ変わらない形でまず提供されると筆者は予想している。来たるべき生成AIベースの開発環境に今のうちから移行し、慣れておくことが必要なのではないか。

IBM watsonx Code Assistant for iが発表されたらすぐに有効活用できるように、PDM/SEUからVSCodeへの移行ロードマップをあらためてまとめておきたい。

VSCode移行における課題と解決策

VSCode移行の障壁は、主にRPG Ⅲにある。PART2（VSCode+Code for IBM i復習）で記述したことと重複するが、移行に際しての課題とその解決策をあらためてまとめておく。

RPG Ⅲのサポートが不十分

SEUを使用してRPG Ⅲを編集する際に実現できている機能が、VSCodeでは提供されていない点がまず大きい。具体的には、次の3点である。

・プロンプト機能がない
・漢字の入力場所によっては桁位置ずれが発生する
・行単位の入力チェックがない

これについては、残念ながらVSCode + Code for IBM iで完全に解決することはおそらくないと思う。しかし、プロンプト機能については、RPG Ⅳであればカラム・アシストである程度カバーできる。幸いRPG ⅢからRPG Ⅳへの変換はCVTRPGSRCコマンドを使用して行えるので、修正が必要なRPG ⅢはまずRPG Ⅳにコンバートして、Code for IBM i経由で修正するという手順を踏む。これによりカラム・アシストが利用できるようになり、プロンプト機能がない問題にある程度対応できる。

また、RPG Ⅳにすることでコンパイラ（CRTRPGMOD）がIFSをソースの場所として認識できるようになる。Code for IBM iがPCに保存したコードをプッシュする先はIFSのみ（ソース・ファイルにはプッシュできない）。Git管理を前提にローカルでソースコードを管理できるようにするためにも、この実施は必須であると考えてほしい。　

漢字の扱いに関しては、RPG Ⅳにコードを変換すれば、演算仕様書のみを自由形式で記述できるようになり桁位置の問題がなくなるので、徐々にそちらに変換していくことで対応可能だ。

行単位のチェックが実装される可能性は不明だが、拡張機能RPGLEを使えばコードの色分け表示が可能になるので、ある程度間違った入力の判別（通常と異なる色で気づく）はできるようになる。

ソース・メンバーがロックされない

これもPART2で言及したが、Code for IBM iで直接ソース・ファイルのメンバーを開く場合、IBM i側ではメンバー・ロックは行われない。そのため、ソースをCode for IBM iで開いている際に、別のユーザーが同じソースを編集目的で開いていることに気づかずに、SEUで修正できてしまう。同じプログラムを同時に修正しないような運用を実現できないと、混乱を招くことになりかねない。

これについては、ソースコードをIBM iで集中管理（ソース・ファイルのメンバー）することをやめ、開発者のPCに関連するすべてのコードを保存して、それを管理することで回避できる。少なくとも万が一同じソースコードを修正したとしても、別のユーザーの修正で上書きされることはない。

もちろん、必要に応じて同じソースの異なる部分を複数人で修正するケースもあるだろう。そういったケースにも対応できるのがGitだ。ソースコードをGitで管理し、ブランチおよびマージ機能を活用することでSEUのようなロックモデルのソース管理では不可能なことが実現できる。2021 Autumn号特集「Git入門」を参考に、ぜひGitの導入を検討してほしい。

DDSはどうするのか

RPG ⅢはRPG Ⅳに機械的に変更することでソース・メンバーからIFSのソースのコンパイルが可能になるが、DDSで記述される物理・論理ファイル、表示装置ファイルおよび印刷装置ファイルはソース・メンバーへの保管が必須だ。これには各ファイルごとに異なる対応が必要となる。

まず、物理および論理ファイルだが、DDSからの作成ではなくSQLに変換することは1つの解決策になると思う。SQLであればローカルにコードを保存し、それをGitで管理できるようになる。

表示装置および印刷装置ファイルについてはDDSの利用が必須なので、オープンソースのCRTFRMSTMFコマンドを使用して、

・ローカルからIFSにコードをプッシュ
・IFSからソース・メンバーにコピー
・作成コマンドを実行

をこのコマンドに実行させることで、ローカルでの管理が可能になる（もちろんプロンプト機能がないという問題は残る）。

5250環境でのSDAおよびRLUのサポートは終了したが、VSCodeの拡張機能IBM i Rendererを使えば簡易的なイメージも可能だ。ただし漢字を含むものについては正しく表示されないなどの不具合はあるので、今後の機能拡張に期待したい。

移行ロードマップ

以上を踏まえて、図表35のステップでVSCode + Code for IBM iへの移行を計画し、早めに実施してほしい。