IBM i のRPG資産で持続可能なITとDX実現を

記事をシェアする:

はじめに

経済産業省は2018年に、日本におけるデジタル・トランスフォーメーション（DX）を以下のように定義した。

「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」(出典: 「DX 推進指標」とそのガイダンス）

さらに、2025年までに「老朽化した既存の基幹システムを刷新しないと、それ以降膨大な経済的損失が発生する」と警鐘を鳴らしている。この老朽化した既存の基幹システムとは、いわゆるレガシーシステムと表現されているものであり、長期に渡って使用されてきたシステムのことを指す。
ユーザー企業によっては、IBM i もそのレガシーシステムの一つと捉えられており、「なんとかしないと大変なことになる」システムに数えられてしまっている。

前述の文書で指摘されている通り、旧態依然としたプラットフォームで、保守が困難なシステムでは上記の危機は乗り越えられない。1988年にAS/400として発表され、大幅な機能拡張がなされて現在は IBM i という名称で広く使われているこのシステムも、ユーザー企業がもしもDX に向けて何もしないのであればこの危機を乗り越えることができないことは明らかだ。

では、IBM i ユーザーはこの問題をどう捉え、どのように対応していけば良いのだろうか。

保守が困難になってしまう原因は、特に IBM i の場合には 主流のアプリケーション開発言語である、RPG にその責任を負わせる傾向が強いように思う。RPG 言語は古く、保守できる人が社内にも社外にもいないから、一日もはやく他の言語に移行すべきという意見を聞くことがある。

しかし、これは何も RPG 言語そのものの問題ではない。Windows や Linux のシステムでも、古い世代のコードで運用されているケースは枚挙に暇がないし、そのシステムを構築した言語が人気言語だからといって簡単に過去世代のコーディングに精通したアプリケーション保守エンジニアを調達できるわけでもない。特にWindowsやLinuxでのアプリケーション開発においては、プログラミング言語に付加して「フレームワーク」や多様な「ミドルウェア」「ユーティリティー」を利用することが多く、過去に作成したアプリケーション保守の問題をさらに複雑にしている。どのシステムでもどの言語でも長く使い続ければさまざまな問題を抱えてしまうのだ。長期に渡って安定的な運用を期待される基幹システムでは、これは避けられないのである。

重要なことは、長く使い続ける過程で、IT ベンダーの都合ではなく自社の意思でシステムを刷新していくことだ。そして他のプラットフォームと同様に、IBM i もそれを実現するための新しい機能追加は日々行われている。

IBM i を今後も安定的に使用してデジタル・トランスフォーメーションに取り組んでいくためには、何に気を付けて何を実践していけば良いか、そのヒントとしてもらえるように RPG 言語を中心にこの問いの答えを考えてみたいと思う。

 

DXにおけるIBM iの強み

IBM i は AS/400 として 1988 年に発表されてからすでに33年目を迎えている。その間も様々な機能拡張がなされており、先日も最新OS V7.4 の Technology Refresh 5（TR5）が発表されたばかりだ。V7.4 が2019年に発表された以来、2年間で5回ほど機能拡張されていることになる。

最近の注目は IBM i のオープンソース対応だろう。2014年に本格的にサポートを開始して以来、様々な言語（Python、Perl、Node.jsなど）や git などのバージョン管理システム、nginx などのWebサーバー機能を IBM i で利用可能にしている。また、Redhat 系の Linux ディストリビューションで利用されている RPM / yum がサポートされ、今後の OSS の導入と管理がより容易になった。

何かと注目されている Python言語で利用可能なライブラリも、主要なものは IBM i に対応したパッケージがリリースされている。

yum を、Access Client Solutions に含まれる GUI で操作したり、ssh で IBM i に接続してあたかも Linux マシン上にインストールしているように操作することも可能だ。

もちろん、IBM i のデータベース機能は OS 標準であり、企業が営利活動をする上で必要なデータを安定的に記憶および取り出しができる、優れた機能は前身の IBM S/38 以来変わらない。データベース作成および管理も、発表当時の DDS / CLコマンドから、現在では SQL インターフェースに移行しつつある。もちろん、DDS で作成されたファイルも SQL インターフェースで処理可能だ。もちろん、他のRDB製品同様、トリガー機能、参照整合性機能、ストアード・プロシージャー、テンポラル・テーブルなども提供している。

このように、IBM i は古い資産を継承できる機能を提供しつつ、新しい機能も貪欲に取り込んでいる。

現在の IBM i では、それが正しい選択かどうかは別にして、業務システムを RPGⅢ (S/38時代とAS/400発表当時のRPGバージョン。AS/400発表時には「RPG/400」と呼称していた) から Python や php で書き換えることもできるし、SQL インターフェースや Linux 系の様々なツール等を使用してクラウド・サービスと連携することもできる。

5250画面に代表されるキャラクター・インターフェースと、RPGⅢ で構築された基幹システムを運用する機能しかないのであれば「時代遅れの古いシステム」になってしまうが、IBM i には、過去の資産を現在も活かすことができる歴史ある基盤と、新しい機能や言語を実行できる新しい基盤とがすでに共存しているのだ。

企業にとって重要なのは、その時々で流行っている旬な言語を使ってシステムを構築することでも、技術者が多いプラットフォーム上でシステムを稼働させることでもない。最も重要なことは、持続的なDX 実現のためにデジタル・データを安定的に、最新技術で処理できることであり、それを実現できるのは IBM i をおいて他にない。

 

RPG Ⅲという言語

DX の文脈でよく言及される用語に「ブラックボックス化」がある。「ブラックボックス化してしまったシステム」などと否定的な意味で使われることが多い。

本来、「ブラックボックス」とは「内部の動作原理や構造を理解していなくても、外部から見た機能や使い方のみを知っていれば十分に得られる結果を利用する事のできる装置や機構の概念。」(出典: https://ja.wikipedia.org/wiki/ブラックボックス ) であり、ユーザーの視点から見れば、コンピュータ・システムはブラックボックスそのものである。

そしてシステムを保守する側は、当然このブラックボックス内部を知っていなければならない。しかし、IBM i 上のアプリケーションは長期に渡って使用されてきた結果、技術者からみてもその内部がブラックボックス化してしまった。度重なる変更でプログラムのソースコードが複雑になったり、変更履歴などのドキュメントが残されていないことなどがその理由だ。

このブラックボックス化の度合いは、使用している言語によって異なるものだろうか。あるいは言語によってブラックボックス化しやすいものとそうでないものとあるのか。

この観点で見ると、RPGⅢ のソースコードは、人によっては確かに読みにくい。言語の特性である、

• 定位置記入形式である（各桁の意味を知らなければ判読できない）
• 視認性が低い（メインで使用されているエディターが 5250 の画面サイズの制約をうける）
• すべてのロジックが書かれているわけではない（サイクルを使用して作成されている場合）

などがその原因である。この意味では、RPGⅢで書かれたプログラムはブラックボックス化しやすいといえるだろう。

そもそも RPGⅢ はいつから使用されてきたのだろうか。他の言語も含めた以下の年表を見ていただきたい。

初版は COBOL と同じ 1959年だが、RPGⅢは 1978年から（System/38）、AS/400では名前を変えて RPG/400 として 1988年から使用されてきた。C++ はその前の 1983年だからそれよりは新しい。

現在も IBM i 上で稼働している基幹システムを構成しているプログラムの多くが RPGⅢ で記述されていることを考えれば、 IBM i のシステムは 1988 年時点の技術で構築されていることになる（もちろん機能拡張はその後もされているがそれを利用しているかどうかはユーザー各社の対応による。現在はRPGⅢの後継である、RPGⅣ (ILE RPG) のみが機能拡張を継続している。RPGⅢは機能拡張はなされず、保守サポートのみがIBMより提供されている）。

この観点で RPGⅢ で書かれた基幹システムは、なんとかしなければならないレガシーシステムであることは間違いない。ではこのレガシーシステムから脱却するためにどのように取り組んでいけばよいのだろうか。

解決策のひとつとしてよく言われているのがオープンシステムへの移行だ。IBM i も RPG も古い (これは事実とは異なる) のだから、新しいオープンシステムへ変更すべきという考え方。そしてもう一つが、プラットフォームは IBM i のままで、RPGⅢ から別の言語に基幹システムを書き換えようという考え方だ。

どちらも RPG 言語からの脱却という路線になるが、これは言うほど簡単ではない険しい道を進むことになるはずだ。基幹システムはどの言語で書かれているかということ以上に業務ロジックの理解がかかせない。これはプログラミング言語が理解できるというのとは別の知識が必要であることを意味する。言語の文法が理解できても、処理するデータのライフサイクルの理解や、業務知識がなければ問題の解決はできない。言語が理解できる技術者の数は実は問題ではない、と先に述べたのは、このような事実があるからだ。

基幹システムを構築するのにどの言語が最適かは、

• 今後もサポートされるか
• 学びやすいか
• 古いコードをリメークする方法はあるか
• 技術者がそれについていけるか

を十分検討した上で判断する必要があると思う。そしてこれを実現できる言語は 「FFRPG (フリーフォーマットRPG)」  であると考えている。

 

FFRPGの良さ

IBM i は最新技術を取り込みつつ、過去の遺産を活かすことができる基盤も提供されているので、RPGⅢ で開発された現状のシステムをそのまま使い続けることはできる。ただし、それではブラックボックス化を解消することはできないし、すでに機能拡張を終了した言語で新規のプログラムを作成することは考えられない。既存のRPGⅢ資産は段階的に 機能拡張が継続されているRPGⅣ (ILE RPG) の固定フォーマット・エディションへの移行を実施し、新規開発についてはRPGⅣ (ILE RPG) の最新エディション（フリーフォーマットRPG。略してFFRPG）で作成すべきであろう。

それでは、FFRPG の良さについて考えてみたい。

 

フリーフォーマット形式で記述できる

RPGⅢが定位置記入形式 (固定フォーマット) の言語であるのに対して、FFRPG は桁位置に依存しないフリーフォーマットで記述できる。最初に学んだ言語が RPGⅢ である場合は定位置記入が当たり前だが、プログラミング言語ではかなりマイナーな存在である。現在主流の言語はすべてフリーフォーマットで記述されており、それが当たり前だから「フリーフォーマットで記述する」という表現すら使用されることがない。

日進月歩のコンピュータ業界においては、ほとんどのプラットフォームで日々量産されているコードはフリーフォーマットであり、若い技術者も最初に学ぶ言語はフリーフォーマットの言語であることは間違いない。そういった若い技術者が定位置記入形式 (固定フォーマット) の言語を目の当たりにした時、相当の違和感を感じるはずだし、RPGⅢ が古いと感じてしまうのもこのあたりに原因があると思う。

その点、FFRPG で書かれたソースコードは他言語の技術者も違和感なく読むことができるはずである。もちろん文法上の違いはあるので学習をする必要はあるが、RPGⅢ を学ぶよりも圧倒的に学習コストは低い。

 

Readable なソースコードを記述できる

オライリー・ジャパンが出版しているリーダブル・コードという書籍 (ISBN978-4-87311-565-8) をご存知だろうか。初版は2012年なので古い本ではあるが、読みやすいコードはどのように書くべきかを知る上でとても参考になる本だ。機会があればぜひ目を通していただきたい。

この本では第１章で「コードは他の人が最短時間で理解できるように書かなければいけない」と述べている。「他の人」とは将来の自分自身かもしれないし、プロジェクトの他のメンバーかもしれない。また、別の言語が得意な新しい技術者かもしれない。どんな人（もちろんプログラミングできる人という前提）でも、仕様書と見比べながら処理を理解するのではなく、本を読むようにソースコードを読んで理解できることが理想である。

ソースコードを読みやすくするための数多くの手法は書籍で確認していただきたいが、改善の第一歩として第２章で触れられているのが「名前に情報を詰め込む」ことだ。例えば、RPGⅢ の学習教材等で皆さん目にしたことがあるだろう「得意先コード」を保管する変数名は、

TKBANG

である。頭2桁の TK が「得意先 (ToKuisaki)」を表し、BANG が「番号」であることを意味する。この命名規則を理解している人は自動的に脳内で変換できるが、初めてこの変数名を見た人はどんな値が入っているかはおそらく判別できない。この名前そのものに情報が詰め込まれていないからだ。

では、次の変数名はどうだろう。

CustomerCode

これを見るとほとんどの人は「顧客コードが入っているんだな」と理解できるはずだ。この変数名は RPGⅢ では利用できない。なぜなら RPGⅢ の変数名はすべて大文字でかつ6文字までという制限があるからだ。

FFRPGであれば、変数名は 4,096文字まで利用できるので、名前そのものに情報を詰め込むことができる。これだけでもRPGⅢからFFRPGに移行するメリットは大きい。

 

繰り返し使用されるロジックを関数化（再使用）できる

RPGⅢではプログラム内部で繰り返し使われるコードの塊を、サブルーチンにしてまとめることができる。しかし、このサブルーチンは別のプログラムから直接呼び出すことはできない。

RPGⅣでは、サブプロシージャーというRPGⅢにはない概念が導入された。サブプロシージャーも繰り返し使われるコードの塊である点は同じだが、引数と戻り値を定義できて、さらに別のプログラムから呼び出すように構成できるところがサブルーチンと異なる。

サブプロシージャーでは、ロジックも内部で使用される変数の値も、呼び出し側のソースとは独立して記述できる。また、複数のサブプロシージャーをまとめた特別なオブジェクト（サービス・プログラム）を作成することもできるので、保守しやすいシステムを構築することが可能だ。

注）サブプロシージャーは RPGⅣ で導入された機能。もちろん FFRPG でも利用できる。

 

オープンソース・ツールとの相性が良い

これから IBM i の開発に携わる若い技術者には、これが最大の利点かもしれない。

IBM i のプログラム開発では、ソースコードは伝統的にソース・ファイルのメンバーに保管していた。このソースコードにアクセスできるエディターは実質 SEU と Rational Dveloper for i (RDi) の LPEX エディターの2種類しかなく、RPGⅢの開発では今でも SEU をメインツールとして使用している現場がほとんどだと思う。

現在、RPGⅣ (ILE RPG) などのいわゆるILE言語では、IFS 内にあるルート・ファイルシステムに保管されたテキスト・ファイルをソースコードとして指定することができる。V7.4 では ILE CL もソースコードとしてテキスト・ファイルを指定できるようになった。IFS のルート・ファイルシステムは、ftp / ftps / sftp でのアクセスが可能なので、これらのプロトコルをサポートするエディターであれば、どれでも利用することができるということになる。人気の高いエディターである Visual Studio Code（以降 VSCode と表記）などが IBM i の開発に使用できるということだ。

ツールについては後述する。

 

RPGⅢ のソースコードを FFRPG に変換可能

まったく新規で作成するのであれば、最初からフリーフォーマットで記述すればよいが、RPGⅢで書かれたプログラムはどうすべきだろうか。

最初に触れたが、今後も IBM i 上で RPGⅢ プログラムは稼働できるが、可能であれば FFRPG に変換しておきたい。IBM i はこの変換の一部を標準でサポートする。CVTRPGSRC というコマンドがそれだ。このコマンドにより、RPGⅢで記述されたソースを固定フォーマットのRPGⅣに変換できる。さらに RDi を使用すれば一部をフリーに変換できるし、ARCAD などのツールを使えばすべてを FFRPG 変換することもできる。

技術者視点でのブラックボックスを解消するという目的であれば、あえて手作業で FFRPG に変換し、その過程で得た知見を文書化することで見える化していくことも必要かもしれない。

 

FFRPG に最適な開発環境とは何か

RPGⅣ (ILE RPG) を含む ILE 言語のコンパイラーは、 IFS のルート・ファイルシステム上に配置したファイルをソースコードとして参照可能であり、エディターで生成したソースコードをそこにコピーすることができれば、実質どのエディターでも使える（Windows のメモ帳でも良い）ことはすでに述べた。

無償で使用できるものを含めれば多くのツールが使用可能ということになるが、ここでは FFRPG に最適なツールとして RDi と VSCode について紹介しておきたい。

RDi も VSCode も PC に導入して使用するツールなので、編集したソースコードは PC 上の ドライブに保存される（RDi は RSE を使えば直接 IBM i のソース・ファイルのメンバーを修正することも可能）。ソースコードは IBM i の IFS 上にないとコンパイルできないので、出来れば保存のタイミングで自動的にアップロードしておきたい。

RDi にはリモート・リコンサイラー機能があるので、これを利用すれば編集したソースコードを保存すると同時に IBM i にプッシュすることができる。VSCode には、sftp 対応の拡張機能を使えばこれと同等のことが可能だ。

VSCode は Microsoft の製品なので、当然桁位置依存のソースコードはサポートせず、実質 FFRPG 専用となる。その点 RDi は LPEX エディターが桁位置依存（RPGⅢ、RPGⅣ(ILE RPG)）のソースコードにも対応するため、RPGⅢを保守しつつ FFRPG の開発も行うことができる。

どちらかの開発環境を使ってほしい理由はいくつかあるが、ひとつにはこれらのツールがバージョン管理ツール（Version Control System：移行 VCS と記述）との連携をサポートしているところが大きい。プログラムがブラックボックス化してしまう要因の一つは、過去の修正履歴が存在しないことが挙げられるが、VCS があればソースコード単位で過去の修正回数や変更箇所などを参照することができる。これだけでもかなりの見える化は可能になるはずだ。VCS の使用を開始する以前の履歴は当然再現することはできないので、一日も早くソースコードのバージョン管理を始めることを強くお勧めする。

VCS のデファクト・スタンダードと言えば git だろう。もともと Linux のカーネルのソース管理用に開発されたツールであるが、現在ではプログラム開発にとどまらず、テキスト・ファイルの履歴管理を行うものとしてもさまざまなところで使われており、それだけ関連書籍もネットの情報も多い。また、RDi と git を連携すれば FFRPG だけでなく、RPGⅢのソースコードもバージョン管理できる点は注目に値する。

git を使用することにより、ソースの変更履歴を保存しているリポジトリーのホスティング・サービスである GitHub 等との連携も可能であり、関連会社とのソースコードの連携も簡単に実現できる。

そして何より、これらのエディター、開発環境および VCS を利用している技術者はたくさんいるので、そういった外部の技術者は使いなれたツールで IBM i のシステム開発に参加できる。もちろん使用する言語が FFRPG であれば、それだけハードルも下がるし、学習コストもぐっと下がるはずだ。

基幹システムは FFRPG で構築しつつ、外部インターフェースは PHP や Python などで構築（もちろん IBM i 上）して、RDB へのアクセスは SQL / ストアード・プロシージャーでまとめれば、IBM i を知らない技術者と連携してプロジェクトを進めることも問題ない。

IBM i の開発環境については、以下の拙稿も参照いただければと思う。

iMagazine 「IBM iとモダナイゼーション｜ これからのIBM i開発に求められる機能とは　～IBM iの開発環境を見直そう」

 

DX実現に向けて取り組むべきこと

DX のゴールはシステムのブラックボックスを解消すれば良いという単純は話ではない。ましてや、オープンなシステムに移行して、使用人口の多い言語でシステムを書き直せばDXへの取り組みがすべて完了するわけでもない。

システム開発時に重複して記述しがちな共通ロジックは関数化（再利用化）し、その関数をどのように使用して機能を提供しているかという部分をしっかりドキュメントにして見える化する。現在の基幹システムの機能を利用しつつ、必要な部分は適宜 FFRPG に変換し、将来の保守性を高めておく。さらに、プログラムのソースコードはバージョン管理ツールを使用して変更履歴も見える化しておく。

これらは最低限実施しなければならないことであるが、これができていれば「はじめに」で述べた

「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」（2018年、経済産業省）を実現するための様々な施策が実施できるようになる。

IBM i というプラットフォームは最新の技術を今後も取り入れて、ますます真の意味でのオープンシステムになっていく。さらに過去の資産を活かしつつIT資産を自由に活用するためには FFRPG への移行が欠かせない。

データベースに蓄えられた企業の現在までの情報と、これからの新しい技術を融合させるための持続可能なIT・DXプラットフォームとして、IBM i と FFRPG をどのように活用していくべきかの一例として、この記事を参考にしていただければと思う。

また、弊社では、IBM i ユーザーへ、持続可能なITやDX実現のためのコンサルティング・サービスを提供している。ご興味のある方は、下記までお問い合わせ願いたい。

https://www.tat.co.jp/cor/COR492P.php