特集　IBM i Project ExplorerとBobを使用したRPG開発　＜Part1＞ 今までのRPG開発の問題点　～SEU／PDM、Code for IBM i、iプロジェクトそれぞれの課題

「Visual Studio Code」（以下、VSCode）で「Code for IBM i」を使用しているなら、IBMから「IBM i Project Explorer」という拡張機能が無償で公開されていることをご存じだろうか。筆者は今年の初めに偶然、この拡張機能の存在を知った（図表1）。

筆者はVSCodeにCode for IBM iをインストールする際、「IBM i Development Pack」という拡張機能を利用している。これはIBM i開発に関連する拡張機能がまとめられたもので、インストールするだけでCode for IBM iをはじめ、Db2 for i、IBM i Debug、IBM i Languagesなどの拡張機能一式をまとめてインストールできるので、導入の手間を省けるのが大きなメリットだ（図表2）。

今年初めのある日、VSCodeを起動すると、IBM i Project Explorerという見慣れない拡張機能がインストールされていることに気付いた。これはIBM i Development Packが昨年末にバージョンアップし、パッケージのリストにIBM i Project Explorerが追加されたことによるものだった（図表3）。

IBM i Development Packに収録されている拡張機能をすべて使用していたわけではなかったので、初めはあまり気に留めていなかったのだが、興味本位でIBM i Project Explorerのドキュメントを読んでみると、これがRPG開発環境のモダナイズに非常に役立つツールであることが分かり、さっそく調査・検証することにした。

本稿では、これまでのRPG開発の現状および問題点に触れつつ、IBM i Project ExplorerとBobがそれをどう改善できるのかを解説する。

これまでのRPG開発環境について

2025年現在、VSCodeと、そのRPG開発用プラグインであるCode for IBM iを使用したことのある開発者も多いことだろう。これらのツールは誰でも無償利用できるので、筆者も数年前からこのツールを試している（図表4）。

ちなみに筆者はVSCodeを、RPG言語以外に、PHPやJavaScriptなどのオープン系言語の開発でも使用しており、動作が非常に軽快で、プラグインも豊富にあり、とても使いやすいと感じている。Web上で公開されているIDE（統合開発環境）の人気調査で、VSCodeが常に1位となっているのも当然と思える（図表5）。

SEU／PDMを使用した開発の問題点

SEU／PDMを使用した開発の問題点を以下に挙げてみよう。

◎若い世代にとって馴染みのないインターフェース

昨今、IBM iを使用している企業ユーザーでは、新しいRPG技術者の育成が急務となっている。IBM iを使用している多くの企業では、現在も1980年代から存在する伝統的な5250画面で、SEU／PDMを使用しながらRPG開発を行っているが、WebブラウザやExcel等のGUIに慣れた若い世代の技術者にとって、これらは全く馴染みがない。

筆者はRPG未経験の若い世代の技術者を対象にしたRPG研修の講師を務めた経験があるが、まずこの独特のインターフェースに慣れるのに時間がかかると感じている（図表6）。

使い方を教えてもらえる環境に恵まれていればまだよいが、そうでない場合はどうやって覚えればよいのだろうか。

◎手作業によるソースのバージョン管理

SEU／PDMを使用した開発環境では、ソースのバージョン管理作業を手作業に頼っているケースが多い（図表7、図表8）。

オープン系言語の開発経験者がRPG研修を受講するケースもあるのだが、彼らにはこのような運用がとても前時代的に映る。結果としてRPG開発に携わること自体が敬遠され、技術者の減少につながっていると筆者は感じている。

VSCodeとCode for IBM iを使用した
RPG開発の問題点

一方、VSCodeはGit連携を筆頭に、最新のエコシステムやツールとの親和性も高い。また無償であり、あらゆるプログラミング言語に対応した拡張機能が豊富に用意されているので、特に若い世代の開発者であれば、使用経験が多いのではないだろうか（図表9）。

このIDEを使ってRPG開発ができるようになれば、新しいRPG技術者の育成に大いに役立つだろうと考えて、これまでこのVSCodeでCode for IBM iを使ったRPGの開発手法、中でもソースのバージョン管理手法について調査・検証してきた。

しかし実際に使ってみると、以下のような理由により開発業務で使用するのは難しいと感じている。

◎RPGソースをGitでバージョン管理する際の制限

RPGのソース・コース・ファイルとしてIFS上のテキスト・ファイルを指定できるのは、RPGLE、CLLE、CBLLEなどのILE言語に限られる。

DDS（PF、LF、DSPF、PRTF）、RPG IIIなどのレガシー言語は、IFS上のテキスト・ファイルから直接コンパイルできない。その都度、テキスト・ファイルをソース物理ファイルへコピーしてからコンパイルしなければならないが、Code For IBM iにはこれを自動化する機能がサポートされていない（図表10）。

◎日本語への対応が不十分

IBM iの日本語EBCDIC環境の文字データは、全角文字列の始まりと終わりにそれぞれ1バイトのシフトコード（0x0Eと0x0F）を必要とする。5250エミュレータで文字を表示した際は、半角文字と全角文字の間に常に1バイト分の空白が表示される（図表11）。

しかしVSCodeのエディター上では、文字データがユニコードに変換される際にシフトコードが削除されるため、結果として見かけ上の桁ずれが発生してしまう（図表12はコンパイル・エラーにはならない）。これでは、RPGのような固定フォーマットのソース・コードの編集がとてもやりにくい。

◎エディターに構文チェック機能や入力プロンプト機能がない

SEUにはリアルタイムでの構文チェック機能があり、単純な記入ミスなどはコンパイル前にチェックされる（図表13）。

一方、Code for IBM iのエディターでは、項目ごとに色分け表示はしてくれるものの、構文チェックは全く行ってくれない（図表14）。

加えて、固定フォーマット仕様書に対応した入力プロンプト機能もないため、特にRPGに慣れていないプログラマーはコーディングがとても難しい（図表15）。

RDiのiプロジェクトを使用した
開発の問題点

RPGソースをGit管理するもう1つの方法として、IBM Rational Developer for i（以下、RDi）のiプロジェクトの使用がある。iプロジェクトとは、次のようなRPGのオフライン開発を実現する機能である。

●PC上にiプロジェクトを作成し、アプリケーションのソース物理ファイル・メンバー一式をPC上にダウンロードする。

●iプロジェクト内のソースの編集・検証を行う。この作業はRDiがIBM iから切断された状態でも可能である。

●IBM iに再接続し、ソースをIBM iへアップロードしてコンパイルを行う。

このとき、PC上のiプロジェクト内のソースはテキスト・ファイルに変換されており、RDiはGitに対応しているので、Gitによるバージョン管理が可能である。しかしこちらも以下のような理由により、実際に業務で使用するのは困難である。

◎iプロジェクトとライブラリーの紐づけが1対1

IBM iで稼働しているアプリケーションのライブラリーは、複数（たとえばデータ用、プログラム用、ソース用など）存在する場合がほとんどなので、1つのアプリケーションに対して複数のiプロジェクトが必要になる。結果として、アプリケーションではなく、ライブラリー単位にGitリポジトリで管理することになる。

◎増分ビルド機能がない

iプロジェクトへダウンロード後に変更されたソースを自動的に検出してアップロードする機能はあるが、それらを自動的にコンパイルする機能はない。結局、ソースを個別に指定してコンパイルしなければならない。

 

（PART2へつづく）