【第12回】エンジョイ -未来予想図：IBM i をもっと楽しもう！

 はじめに

IBM i のシステム開発を中心にお届けしてきた「IBM i 進化論　〜知っておきたい12のこと〜」。いよいよ最終回になりました。IBM i の特徴や機能、使用可能な言語やツール、そして最も大事な RDBMS の機能を解説する記事を通して、時間の経過とともに IBM i がどのように進化してきたか、また時代の要請にどのように応えてきたのかを出来る限りお伝えしてきたつもりですがいかがだったでしょうか？ 最終回のこの記事では、IBM i が置かれている現在の状況を少し冷静に見つめながら、これから先を予測していきたいと思います。キーワードは「エンジョイ」です。

これからどこに向かっていくのか

「クラウド」、「AI」、「IoT」。今年の初めに、この３つが2017年のキーワードになるという記事を、インターネットで読んだ記憶があります。今では誰もが口にしているこのワード。そろそろ2017年の終わりの足音が聞こえてきている今、皆さんはすでに取り組まれているでしょうか。それともこれから取り組もうと計画されているでしょうか。 AI は、一般的には「人工知能（Artificial Intelligence）」のことを指しますが、IBM は「拡張知能（Augmented Intelligence）」と定義しています。人間の知識を拡張し、さらに増強していくという意味ですね。こういう言葉は、何か新しいことができるのではないかという期待感を与えてくれるワードですね。 IBM i は長年に渡って企業システムを支えてきました。アクセスも社内からのみという使い方が一般的だとおもいますし、まだまだ閉鎖的な使われ方をしているのが現状です。そんな IBM i が、このクラウドや AI などとどのように連携していくのか、そもそもできるのか不安に思っている方も多いのではないかと思います。 しかし、クラウドにしろ AI にしろ、社外のネットワークにあるこれらのものと、今後は相互に連携できるシステム作りが必須になってくるのです。5250 の世界だけでは実現できない、様々な要求をひとつひとつ解決していかなければなりません。 2018年になると、IT 業界のクラウド化はますます進むでしょうし、ハードもどんどん安価になっていき、様々な情報を低コストで取得できるようになってくるでしょう。現時点では想像もできないようなサービスが生まれてくるかもしれません。そんな近い将来に向かって、IBM i はどういった立ち位置を演じていくのでしょうか。

基幹システムの問題点

第二回の記事でも触れましたが、IBM i は過去の資産の継承を愚直なまでにひたすら実現してきました。そのおかげで、メーカーの思惑や業界の流行り廃りに左右されることなく、最低限のコストで今現在でも基幹システムを運用することができています。これはユーザーにとっては本来必要でない変更や、それにかかる時間、コストを負担しなくても良いほど、安定的な運用を実現できる IBM i ユーザーならではのメリットだと思います。 しかし、それにともなって顕在化してきたデメリットもあります。それが「技術の継承問題」です。端的に言ってしまえば、RPGⅢの技術者不足です。良くも悪くも長い間大きな修正の必要もなく稼働してきたプログラムはRPGⅢで書かれています。私もそうですが、現在も使用されているシステムを開発した技術者は年齢を重ねて50歳を超える一方、RPGⅢを習得する若い技術者は年々減っています。 また、業務は日々変わっているのに、それに迅速に対応せず業務をシステムに合わせて使っている例も多く見受けられます。こうなった要因は色々と考えられますが、やはり資産がきちんと継承されるというところがこの状態を作ってきた一因でもあると思います。 通常は、メーカーの思惑により OS や言語のサポートが強制的に終了し、それに対応するために膨大なコストを掛けて新しいものに否応なしに対応することで、新しい技術や技術者の獲得が実現され、業務の変化に結果的に対応していくものです。しかし、IBM i ではそれがないためにこういったマイナスの面が近年特に目立ってきているのです。 もうひとつの問題は、システムの全体像を把握できていない（中身がわからない）ケースもあるということです。長期間に渡って使用されているシステムは、どのような経緯で設計および作成され、どのタイミングでどこが修正されて現在に至っているのかということを記録して、将来の変更の参照情報とするべきシステムのライフ・サイクル管理が弱いということが挙げられます。

• システムの機能が古く業務と合っていない部分が散見される
• ライフ・サイクル管理ができていない

こういった点が、すべての IBM i ユーザーが抱える共通の問題点だと思います。

システム刷新の危険性

企業が認識している基幹システムの問題は、この2つの要因（例えば長く使っているからこその古いシステムというイメージや、中身がブラック・ボックスでとにかくわからない）が起点となっています。 そして古いシステムだからだめだという蔓延したイメージを払拭するために、IBM i をやめて別のプラットフォームで再構築しようという動きに発展することがあります。システムを刷新することにより業務に合ったシステムに作りなおし、ソースコードのバージョン管理を基本とするライフ・サイクル管理も、あらたに開始するという目標が実現できるからです。 しかし、システムの刷新にはコストとリスクがかかることもしっかり認識しておかなければなりません。新しいシステム（別のプラットフォーム）に移行する場合、まったく一から設計し直すのであれば、現在のシステムを無視して開発できるかもしれませんが、現在できていることができなくなるのはやはり問題です。実際問題、現行システムがわからないと、システムの刷新を成功させることは不可能です。 これまで積み上げてきたものを一旦ゼロにして、再度積み上げていくには膨大な時間とコストがかかります。それでも100%満足のいくものが実現できるのであれば良いですが、なかなかそううまくは行きません。システムを刷新するということは、こういった色んなリスクを承知の上で、進めていく必要があるのです。

問題点の解決

この十二回の連載の中で、第四回から第十一回まで、IBM i を使い続けながら現在のシステムが抱える問題の解決ができることをお伝えしてきたつもりです。RPGⅢのシステムを使い続けながら、若い技術者の入り口として完全フリーの RPG は提供されていることを第四回で説明しました。また Java  や PHP などすでに多くの技術者のいる言語も IBM i はネイティブでサポートしていることを、第七回と第八回で紹介しています。 開発ツールとしては、第六回の記事で Web ベースのエディタである Orion やバージョン管理の git がネイティブで使用できることを説明しました。また、第五回で紹介した RDi を使えば、RPGⅢのプログラムを含めて、 すべてのバージョンの RPG ソースをバージョン管理できます。過去の変更記録はありませんが、一日も早く始めることで、ブラック・ボックスという状態から脱することが可能になります。ソースのバージョン管理だけではなく、バグトラッキング・システムや Wiki などを使って作業のログを取っていくようにしましょう。 IBM i のデータベースである DB2 for i は SQL インターフェースが標準です。もちろん過去の資産の継承により DDS を使用したファイルの作成も今まで通り可能ですし、プログラミング的にはレコードレベル・アクセスを今後も使用することももちろん可能です。 他のシステムやクライアントからのアクセスは Web API 経由だったり SQL（ODBC / JDBC）だったりするでしょう。また、他のシステムとの情報交換として XML や JSON 形式を採用することも今後は多くなっていくと思います。IBM i はどの技術も現時点で対応していますので、AI やクラウド・サービスとの連携も、機能レベルでの準備は済んでいます。 業務および開発用クライアントは Windows だけではなく、Mac でも実施できます。5250 業務ももちろん可能です。また、Webサーバーも標準で備えているので、アクセスするデバイスの幅もぐっと広がります。もちろんバックエンドで実行されるプログラムは Java でも PHP でも、そしてもちろん RPG でも可能です。 技術者の要員不足に関しては、オープン・ソースのインターフェースや Eclipse をベースにした RDi などのツールを積極的に利用することで、若い方や他のプラットフォームの技術者を取り込んでいくことが可能になります。Web 系のアプリであれば、IBM i + DB2 for i + PHP / Java + SQL で、5250 画面を使用しなくても開発を行うことも不可能ではありなせん。 このように技術者不足の問題を解決するための取り組みは、OS および ソフトウェア・レベルでは完了しています。後は、現在の IBM i の開発者が現状の問題点とそれを解決する仕組みをきちんと理解し、積極的に門戸を開く努力をすることが大切です。 IBM i の稼働システムは、いまの業務に合っていないから古いという評価があるのは既に述べた通りです。しかし、それはシステムの入り口（インターフェース）が 5250 であるというころが原因としては最も多いと思います。それはシステムの問題ではなく、すでに述べたように見た目の問題です。であれば、現時点ですでに様々なクライアントからの要求に答えるための仕組みを用意しているので、システム刷新ではなく、新しいデバイスのアクセス点を IBM i で開発すれば問題は解決しそうですね。IBM i には apache サーバーが標準ですから、システムの出入り口はこれを使いましょう。大量のアクセスが発生しそうな場合は、 Nginx（エンジンエックス）を使うことで対応可能だと思います。 長年使われているプログラム言語が RPGⅢ で古いから心配という意見も良く耳にします。確かに RPGⅢ は機能拡張が終わっていますが、RPGⅢ のコンパイラーは将来もサポートされます。V6.1 以降で実装された新しい機能を使う必要がない簡単な修正であれば、SEU + PDM + RPGⅢの三つのツールでいままで通り修正できます。 本来であれば既存の RPGⅢ のプログラムを RPGIV で書き直すのが王道だと思いますが、それにもコストはかかりますので、そのコストと RPGⅢ の技術者を育てるコストを比較し、どちらを選択するかを決めてください。 システムの中身がブラック・ボックスでわからないというのは、 IBM i だからという問題ではないはずです。どのプラットフォームを使っているかには関係なく、システムのライフ・サイクルの管理がなされていなければ結局システムはブラック・ボックス化していきます。すでに触れましたが、開発過程のログを全員で共有するためのツールはオープン・ソースのものがたくさんあります。とにかく一日でも早く記録をとることを初めましょう。明日からではなく、ぜひ今日から始めてください。

やはりベースとなるものは

企業が時間とコストをかけて積み上げてきたシステムの仕組みは、そんなに簡単に捨てるべきではありません。その歴史があって、今日皆さんの会社の業務が実行できているのですから。過去の資産を継承しつつ、新しい技術に果敢に挑戦できるシステムは IBM i をおいて他にないと思います。 IBM i は、システムのコアな部分はそのままで、新しいことにどんどんとチャレンジでき、様々なインターフェースのサポートにより外部システムと無限に繋がっていくことができます 。IBM i でできることはまだまだたくさんあります。ぜひ楽しみながら IBM i を見直してみてはいかがでしょうか。今かかえている問題の解決方法が、IBM i で必ず発見できると思います。

おわりに

先日、京都大学の山中伸弥教授が、NHK の「プロフェッショナル仕事の流儀」という番組に出演されていました。山中教授は皆さんご存知の通り、IPS 細胞の研究で2012年にノーベル生理学・医学賞を受賞されたのですが、今でも新しい研究に果敢に挑戦されています。そんな教授は、「鎖のひとつになる」という哲学を持って仕事に取り組んでいらっしゃるそうです。現在の様々な研究は、それまでに積み上げた多くの研究者の努力のおかげであり、その一つ一つの鎖がしっかりしているから、自分の今の研究も安心して続けることができるのだという考えです。だから、自分の研究も将来の研究のためになるよう、新しい鎖を壊れないようにしっかり作らなければならないということです。 我々の仕事の世界とノーベル賞受賞者の世界はもちろん違いますが、鎖の話は共通していると思います。今日我々がこうして日本で平和に暮らすことができるのもそうした先人の努力の積み重ねのおかげですし、企業のシステムも同じことだと思います。長い時間をかけてそれぞれの会社で繋いできた確かな鎖を大切に、そこに新しいしっかりとした鎖を我々も繋げていきたいものですね。 IBM i はこれからも、企業システムを実行するプラットフォームとして世界中で使われてくことでしょう。そして、現在できていることは将来も保証しつつ、新しい機能を貪欲に取り込んでいくという DNA も健在です。IBM i という真のオープンなシステムが、今後も皆さんの企業活動を支える基盤で有り続けるよう願わずにはいられません。 IBM i が「古い」という評価は単なるイメージでしかありません。どうか選択肢はたくさん持ちながら冷静な判断で、将来のシステムをどうすべきなのかじっくりと考えることが大事だと思います。そして、その選択する答えは IBM i で必ず見つかるのではないでしょうか。