text：小川 誠 ティアンドトラスト
SEU に代わるエディタ
RDiとVSCode
それでは具体的に、これからのIBM iの開発環境について考えていこう。前述したソースコードのバージョン管理を想定しながら、理想的な開発環境を組み立てていく。
今回は基本的に、なるべくオープン（もしくはオープンソース）なツールを選択する。理由は単純で、情報量が多く、手軽に始められるからである。
SEU については、基本的に今後は利用しない方向を提案したい。すでに述べたように機能拡張されていない古いツールなので、より短い開発サイクルで作業ログを取りながら利用するのは困難だからだ。
それではバージョン管理ツールと連携しつつ 、SEUに代わるエディタとして何を選択すればよいか。まず考えるべきは、RPG Ⅲのコードを修正する必要があるかどうか、である。これの意味するところは以下の2点である。
・エディタがIBM iのソース・ファイル・オブジェクト（およびメンバー）にアクセスできるか
・各仕様書のプロンプト機能が提供されるか
RPG Ⅲ のコンパイラーは CRTRPGPGMコマンドで呼び出されるが、コンパイル元のソースはソース・ファイルおよびメンバーの指定しかできない。また、定位置記入形式の言語なので、常に使うというわけではないが、各仕様書のプロンプト機能（桁位置を覚えていなくても入力をサポートしてくれる機能）も必須である。
これを満たすツールは 「Rational Developer for i」（以下、RDi）のみである。RDi はエディタでなく統合開発環境なので、厳密にはそこで提供されるLPEX エディタが正しいが、ここではRDiと呼ぶことにする（図表7）。
これに対して、RPG Ⅲを保守しない場合は、選択肢として「Visual Studio Code」（以下、VSCode）が最有力候補になるだろう。
多彩な拡張機能が用意されており、FF RPGやCOBOLにも対応する。IBM i のソース・ファイルに直接アクセスはできないが、ソースコードをファイルとして IFS 上に配置するための拡張機能（SFTPなど）は用意されている。
ILE言語のコンパイラーは、コンパイル元のソース・ファイルの場所をIFS上に指定できるので、十分に利用可能である。図表8でもわかるように、RDi はソース・ファイルだけでなく、IFSにもアクセス可能であるという点が重要である。
RDiもVSCodeも、RPG ⅣやCOBOLだけでなく、JavaやPHP、PythonなどIBM iで稼働するプログラムのコードを記述できる。今後新たな言語が増えても、それ専用のエディタを用意して使い方を覚えねばならない可能性は限りなく低い。
バージョン管理ツール
Subversionとgit
それでは次に、ソースのバージョン管理ツール（Version Control System、VCS）について考えてみよう。現在、オープンソースでよく使用されているのは、Subversionとgitの2つである。
Subversionは初版が2000年、gitは2005年なので、git登場以前からバージョン管理を実施している企業は、現在もSubversionを使用しているケースが多いように思われる。ではこれからバージョン管理ツールを導入する場合は、どちらを選択すればよいだろうか。
エディタとの関係でいうと、RDiとVSCodeはどちらも両方のバージョン管理ツールと連携する拡張機能が用意されているので、その点ではどちらも候補になる。
仕組みについては、コードの変更履歴を保存する場所（リポジトリ）を共有するか、分散してもつかという違いがある。Subversionは前者で（図表9）、gitは後者である（図表10）。どちらも複数のクライアントがアクセス可能なサーバー上に共通のリポジトリを置いて運用する必要がある点は注意したい。通常サーバーOS は Linux で運用するケースが多いようだ。
Subversionもgitもオープンソースで利用できる。本稿では、以下の理由からgitを推奨したい（図表11）。
・情報量が多い
・リポジトリの分散化で運用の自由度が高い
・クラウドのサーバー（リポジトリのホスティングサービス）を利用できる
・各エディタ用の拡張機能が豊富である
・ブランチ機能を手軽に使える
まず情報量であるが、gitはもともとLinuxのカーネルコードを管理する目的で独自に設計・開発されており、オープンソース系の開発ツールとしてはすでにデファクト・スタンダードである。ユーザーが多いことは、関連書籍や Web 上の情報、YouTube の解説動画など情報量が多いことを意味する。使い方に困ってもすぐに調べられるし、解決できる。
続いてリポジトリの分散化だが、これは開発者のPCと共通サーバーのそれぞれにリポジトリを置いて管理する。開発者は、変更履歴はすべて自分のリポジトリに保管し、他の開発者とソースを共有する時のみ、サーバーのリポジトリと同期する。
リポジトリはローカルディスクに存在するので、ネットワーク接続していない状態でも変更を保存する（コミットする）ことが可能だ。専用リポジトリなので、他の開発者を邪魔することなく自由にコードを修正できる。
クラウドのサーバーについては、リポジトリのホスティングサービスであるGitHubを利用できる。こちらはクラウド上のサービスなので、サーバー運用の手間はない（基本的な機能は無料で利用できる）。
基幹システムのコードをクラウド上に置くのはセキュリティ的に問題がある場合は、Linux 等のサーバーを社内ネットワークに用意し、GitHubのクローンであるGitLabを導入して利用できる。こちらも無料版と有償版があるので、必要に応じて使い分けたい（その他のサービスもあるが、ここでは割愛する）。
次に各エディタ用の拡張機能だが、たとえばgitのリポジトリの変更履歴をグラフ形式で見やすく表示する機能がある（図表12）。これらをうまく利用すれば、コードの変更履歴を必要な時に参照できるようになる。
またブランチ機能は、とても便利である。詳細は別の機会に説明したいが、簡単にいうとソースコードの枝分かれ機能のことだ。たとえば、すでに本番環境で動いているコードを表すブランチをあらかじめ決めておき（通常はmasterかmainブランチ）、そこから別のブランチを作成して自由にコードを修正可能にする。
ブランチが複数ある場合は、別のブランチに簡単に移動（checkout）できるので、たとえば以下のようなことが可能になる（図表13）。
・新しい機能追加が必要になったので、新しいブランチを作成（①）
・コードを次々に変更して機能追加していたところ、本番環境で動いているシステムのバグ対応が必要になった
・作業ブランチを本番環境ブランチに変更（checkout）し、バグ修正作業を実施（②③）
・バグ対応が完了したら、作業途中のブランチに再度戻り、機能追加の続きの開発を実行（④）
・テスト等を終えて、問題がなければ本場環境に配置すると同時に、作業ブランチの変更を本番環境ブランチに反映（merge）（⑤）
・作業ブランチの作業が終わったら、そのブランチを削除
実際の開発現場では複数の機能拡張が同時並行で進んでいる。gitにはこれらの作業を自由に実行し、必要であればすぐ元に戻せる安心感があるので、ぜひ利用してほしい。
開発者の作業ログ管理
GitHubとRedmine
プログラム開発者が日々行っている記録（ログ）は、どのように考えていけばよいだろうか。Windows のメモ帳を使ってファイルに保存したり、さまざまなクラウドサービスを使ったりと、それぞれが工夫しながら記録していることだろう。
日々の作業ログは、将来参照するためにのみ記録する。参照するのは自分かもしれないし、プロジェクトの別メンバーかもしれない。また、将来仕事を引き継ぐ際に必要となるかもしれない。いずれにせよ、記録を他のメンバーと共有するには、個人しかアクセスできないPCのディスクやクラウドサービスへの保管以外の方法が必要になる。
まず候補の1つとしては、前述したgitリポジトリのホスティングサービスである GitHubやGitLabの課題（issue）管理機能を挙げたい（図表14）。
issueには多様な利用方法があるが、システムの改修要望として社内資料が起票されて（もちろん採番される）、開発者に担当が割り振られたら、その改修要望に対してissueを作成し、そこに作業ログを集約して書いていく。GitHubおよびGitLabはブラウザでアクセスするが、issueの記述はWiki記法が利用できるので、簡単で表現力豊かなログとして保存できる。
また、Redmine に代表されるバグトラッキングシステム（以下、 BTS）で記録する方法もある（図表15）。BTSを利用する場合は、改修要望などをチケットという単位で管理し（Redmine上で起票する）、そのチケットを担当者に割り当てて作業の進捗をトラッキングできる。チケット番号と、コード変更を実施したブランチ名を関連付けておくことで、何が実施されたのかを簡単に追跡できる。
新しい開発環境構築に必要な
接続ツールと認証方式
目指すべき IBM i の開発環境について、RDi と VSCode のそれぞれについて全体像を図表16にまとめた。
以下に、前述した開発環境を構築する際に知っておくべき情報について解説していこう。
IBM i への接続で真っ先に浮ぶのは、「Access Client Solutions」（以下、ACS）であろう。Java の実行環境が導入されたPCであれば、Windows だけでなく Mac などでも稼働するので、使用していなければぜひ試してほしい。
ACSで最も多く使われるのは、やはり 5250 エミュレータである。コマンドの実行にしても、基幹業務システムの実行にしても、この画面がまだ現役なのは前述したとおりである。これはあまり知られていないが、IBM iには5250以外に管理者がアクセスできる接続方法がもう1つある。Linuxの世界ではサーバーにアクセスする際の標準的なインターフェースである、SSH接続である。SSHはクライアントとサーバー間を暗号化して接続し、通信内容が外部に漏れないように保護する。接続時には互いを認証して、正しい相手と判断した場合のみ接続されるので、セキュリティ上も安心して使用できる。
SSHでのクライアント認証は、パスワード認証方式と公開鍵認証方式の2種類がある（図表17）。
パスワード認証方式は、接続相手が正しいかどうかをユーザー名とパスワードの組み合わせでのみ判断する。パスワードがネットワーク上を流れるが、SSHで暗号化された状態なので漏洩する危険性はかなり低い。
これに対して公開鍵認証方式は、事前に秘密鍵と公開鍵の鍵ペアを作成し、公開鍵のみをサーバーに事前に渡しておくことで、パスワードを送信することなく通信相手が正しいことを確認する。2つの鍵の関連性は数学的に必ず１対１になるように設計されているので、パスワード認証方式よりも安全に認証可能である。
IBM iが社内LANに存在している場合は、最初はパスワード認証方式で運用すると始めやすい。ただし、将来的には公開鍵認証方式への移行を推奨する。
IBM iは以下のライセンスが導入されていれば、SSHのサーバーとしてもクライアントとしても実行できる。
5770SS1 30 QSHELL
5770SS1 33 PORTABLE APP SOLUTIONS ENVIRONMENT（PASE）
5733SC1 *BASE IBM PORTABLE UTILITIES FOR I
5733SC1 1 OPENSSH、OPENSSL、ZLIB
ほとんどの場合、SSH のサーバーとして運用することが多い。開始方法は簡単で、以下のコマンドを実行するだけである。
**STRTCPSVR SERVER(*SSHD)**
接続するクライアントにもSSHクライアント機能が必要だが、Windows 10では OpenSSHという無料ソフトウェアを標準装備するので、簡単にIBM i へSSH 接続できる。
実行できるコマンドは Linux 互換のコマンドなので最初は戸惑うかもしれないが（図表18）、IBM iのオープンソース環境を構築するためのツールであるyum などはこのインターフェースを使って実行するので、この機会にぜひ覚えてほしい。またプロンプト機能はないが、IBM i のコマンドをこのインターフェースから実行することもできる。
さらにSSH はターミナル接続だけでなく、ファイル転送のための機能もサポートされる。もちろん通信経路は暗号化されている。
SSHでのファイル転送機能は、SFTP（SSH File Trans fer Protocol）という。今回紹介したエディタ候補である VSCode では、作成したソースコードをIBM iに送信する際にSFTPを実行する拡張機能が利用できる。
ファイルを転送するには無料ツールが多数存在するが、WinSCPなどSFTP対応のツールを使えば、安全にファイル転送を実行できるので、試してほしい。
SSHで接続するのは、IBM i の PASE 環境である。これはIBM i上でAIXまたはLinuxのアプリケーションを実行できるランタイム環境である。IBM i のネイティブ環境は知らなくても、Linux 環境で作業をSFTP実行できる技術者は数多く存在する。
IBM i以外の技術者でもSSH 接続によりIBM i のさまざまな機能を操作できるとあれば、IBM iの管理や開発に参加するハードルをかなり下げられる。DX 推進に向けた人材不足解消の一策になるかもしれない。
SSH接続する際のデフォルトのシェルは ksh（コーンシェル）だが、bash（ボーン・アゲイン・シェル）ももちろん利用できるので、こういったオープン系のインターフェース操作にもぜひチャレンジしてほしい。
DXの実現に向けて
開発環境を見直すことの重要性
モダナイゼーションを推進しながら、DX の実現に向けて IBM i を活用していくために、まずはシステム開発という観点で、将来に向けて必要な情報を自動的に蓄積していく仕組みが求められる。
これを実現するために、本稿では以下が重要であると述べてきた。
・ソースのバージョン管理ツールであるgitを導入する
・gitと連携できるエディタ（RDiかVSCode）を採用する
・作業指示の起票をツールで実施し、担当者を割り当てて作業ログを取る
・gitの変更履歴と作業チケットを常に連携して保存する
バージョン管理や作業ログは過去に戻って復元はできないが、1日も早く開始することで、ブラックボックス化したシステムを将来に向けて見える化することが可能になる。
git、RDi、VScodeなどそれぞれのツールの使い方や連携方法、注意点などは今後、機会があれば詳細に解説していきたい。
また開発言語としては、FF RPGを重視している。既存プログラムをすべてFF RPGに変更することは難しいだろうが、これから新しく作成するプログラムはFF RPG で記述すべきである。基幹業務でも、他システムとの連携や、モダナイゼーションのデータベース側の処理を実行するプログラムなどがこれに該当する。
DX の本質は、デジタル情報を活用して企業が生き残っていくために、企業の組織や経営者の意識改革により確実に実践することにある。単にレガシーシステムを別サーバーに移行すればよいという単純な話ではない。
既存システムをモダナイゼーションしながら、時代とともに、また時代に先駆けてビジネスに貢献できるサーバーとして、これからもIBM iの可能性を追求してほしい。
◎ IBM iの開発環境を見直そう
・IBM iとDX｜ IBM iはレガシーを継承しつつ、新しい技術基盤を併せもつ
・PDMとSEU ｜ IBM iの開発に欠かせない2つのツールがもつ強みと考慮点
・IBM iとモダナイゼーション｜ これからのIBM i開発に求められる機能とは（今回）
・これからの開発環境｜ ソースコード管理を起点に理想的な開発環境を考える
著者｜小川 誠氏
ティアンドトラスト株式会社
常務取締役
1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。
［i Magazine 2021 Summer（2021年7月）掲載］
