昨年インタビューさせていただいた、IBM i 開発責任者でありチーフ・アーキテクトのスティーブ・ウィル氏が第28回iSUC別府大会に参加のため再来日。今回はIBM i のプロダクト・オファリング・マネージャーであるアリソン・バタリル氏と一緒にお時間をいただきました。
Cognitive Systemに組み込まれたIBM i のコグニティブエリアで役割とは？
――最近のIBMの組織を知って驚いたのですが、これまではPower Systemsというブランドの中にあったIBM i が、今はCognitive Systemという新しいブランドの中にあるそうですね。コグニティブというエリアの中においてオフコンというイメージが強いIBM i の役割はどのようになるのでしょうか。
アリソン
Cognitive Systemとは、Power Systemsとそれに更なる機能拡張を加えたものの総称です。この新ブランドは2017年初めからスタートしたのですが、汎用のPower Serverに加えて特定用途向けのサーバーも展開しています。例えば新しいところでは、NVIDIAというCognitive Computing用のハードウェアを追加装備したサーバーを販売しています。もはやこれまでの単なるPowerではなく、そこにコグニティブという能力も備えたシステムという意味で Cognitive Systemと改称したのです。
スティーブ
IBMは、基本戦略のテーマとして、コグニティブ・ワークロードが今後10年のビジネスの成長にとって重要であると確信しています。一部のPower Systemに関してはコグニティブ・ワークロードに特化したものになります。AIX、IBM i などのPower Systemは既にビジネス・アプリケーションを動かしていますので、継続的にそれらを動かしつつ、コグニティブ・ワークロードを使ってビジネス・アプリケーションの機能強化を図る、といった両者を融合させる作業が必要になってくると考えています。既存のビジネス・ワークロードに対してコグニティブ・ワークロードというものがどんどん増えていく中で両者をうまくつなげていく、そしてそれによってビジネス拡大の手助けをすることを基本テーマとしているのです。
コグニティブ・ワークロードにおけるIBM i の位置づけ
――興味深いお話です。IBM i は、なんでも上に乗せるのが今までのスタイルだったように思うのですが、そうではなくて、IBM i やAIXに、コグニティブ・ワークロードをつなげていくというイメージですね。
アリソン
おっしゃる通りです。IBM i、AIX、Linux、これらすべてが同じパワー・サーバーの上に乗っています。コグニティブ・ワークロードはいろいろな方法で実行できますが、その実行過程で、人間の脳の機能のようなデータ解釈の手段を取ります。言い換えれば人間の脳の働きを真似ているとも言えます。IBM i は完全にビジネス用に設計されたシステムであり、IBM i の上でWatsonが動くということはありません。しかし、IBM i のお客様はそうした能力を必要としています。そこで、POWER上のLinuxで実行されるコグニティブとIBM i をつなぐ手段を提供するのが私たちIBMの仕事になります。今年の私たちの仕事の一つは、IBM i とWatsonおよびIBM Cloud（旧名称:Bluemix）、この三者間の会話方法に注力することでした。これはIBM i のお客様が、コグニティブがもたらす価値をビジネス・ソリューションに取り込むための重要な手段なのです。
スティーブ
私たちはいま、APIエコノミーまたはサービス・エコノミーと呼ばれる世界にいます。ソリューションは単一のシステムの上にあるものではありません。別のシステム上にあるサービスを呼び出すことで、完全なソリューションにするという世界です。これはコグニティブ以前から起こっていたことですが、IBM i はこうしたことを可能にするために、ありとあらゆるプロトコルを統合しています。コグニティブは単にその延長上にあるのです。これが、IBM i のお客様がコグニティブに容易に接続できるということをお見せできる理由の一つです。
アリソン
何年もの間、私たちはモジュラー型のビジネス・アプリケーションについて語ってきました。モジュラー型プログラムは、モジュールを寄せ集めて接続し、必要な機能を実現します。今まさにスティーブが話したように、APIエコノミーは、いろいろな場所で作られたモジュールをつなげ合わせて必要な機能を作り上げます。このモジュラー型のアプリケーションがあるからこそ、コグニティブやWatson、あるいはIBM Cloudなどにうまくつなげていけるのです。IBM i でこうしたことを実現するために、新しくプログラム製品や技術を買う必要はありません。
海外におけるRPG事情
――IBMがRPGⅢをRPGⅣにし、モジュラー化して、それと同時に、Java、PHP、最近でいえばNode.jsといった新しいWeb系の言語もサポートするというのは今の話にフィットする方向性だと理解しました。その中で日本の現状は、まだまだ8割方オールドスタイルのRPGを利用しているようです。一番の悩みは、RPGの後継者についてで、RPGⅢのプログラマーが定年を迎える年齢になり、RPGが分かる人がいないからIAサーバーやクラウドに移行する検討を始めたり、あるいはRPGを全部Javaにしてみようかといった極端な話もあるのが現状です。これは海外でも同じでしょうか。
アリソン
日本に限った話ではありません。海外でもいろいろなお客様が様々なステージのRPGをお使いになっていますが、IBMはRPGⅢでのコーディングはもうお勧めしないということを一貫して伝えています。というのも、RPGⅢのコーディングスタイルは巨大な一つのプログラムの中に機能をすべて詰め込む形であるがために、新しい機能を追加するのに不向きです。ですから、私たちはモジュラーコーディングに移行するようお勧めしています。一度モジュラー型のプログラムに移行してしまえば、例えば、グリーン・スクリーン・インターフェースをモバイル・インターフェースに置き換えることなど容易にできてしまいます。これは巨大な一枚岩のRPGⅢコーディングではできないことです。まずプログラム開発のモダナイゼーションの第一ステップとして、モジュラーコーディングへ移行することが肝要です。
次に私たちがRPGで行ったことは、フリーフォームの導入です。今年の初頭、IBMのブランドの一つであるRatioalが、フランスのARCAD社を通じて二つのツールをIBMに導入する契約をしました。これらのツールはまさにRPGのコードを現代化するためのものです。一つのツールがコードを読み込み、モジュールを探し出します。そしてもう一つのツールがRPGⅢのコードをフリーフォームRPG(以下、FF RPG)に変換します。
スティーブ
IBM i の戦略は、お客様の状況に合ったテクノロジーを活用する選択肢を提供することです。RPGⅢという巨大なプログラミング・スタイルから別の言語に移るつもりであれば、使用言語を変えるだけではなく、モジュラー型プログラムへの移行も考えましょう。確実に言えるのは、このモジュラー型プログラムへの移行が一番容易なのはFF RPGである、ということです。コスト的に他の言語より安く、IBMはFF RPGに投資を継続していきます。ですから、言語の将来性が心配ということであれば、このFF RPGをお勧めします。
また、FF RPGはとても学びやすい言語なので、RPGの経験がないPythonスキルを持つエンジニアが、入社してからFF RPGを学び、PythonとFF RPGを使いこなしているという例もあります。若手エンジニアが、極めて短期間に開発生産性が向上するという素晴らしい事象が、今、世界中で見られています。
アリソン
若手プログラマーは、グリーン・スクリーンをベースにした開発ツールを理解できませんが、世の中にはまだまだこうした開発ツールを使っているお客様がたくさんおられます。ですから、アプリケーション・コードを現代化すると同時に、開発環境もRational Developer for i (以下、RDi)のような現代的なツールにする必要があります。若手プログラマーは、ステートメント入力ユーティリティー（SEU）を使ってプログラミングをしているような会社には就職したがりませんから。
――開発環境をRDi だけではなく,OrionやGitもサポートの延長にある、ということですね。
スティーブ
RDi はIBM i の環境向けに作られた製品で、Orionよりずっと豊富な機能を持っています。しかし、多くの新卒社員は、学生時代にOrionやGitを開発用ツールやリポジトリとして使ってきています。ですから、彼らからすれば、会社がRDi の代わりにOrionやGitのようなオープンソース・ツールを選択するという動きは自然なことです。RDi はより多くの機能を持ち、私たちの開発スタイルに合わせて作られていますが、彼らにグリーン・スクリーンに代わるRDi 以外のもう一つの選択肢を提供しようということです。
アリソン
IBMはRDi とGitを統合すべく開発を行っています。若い開発者たちはOrionでコーディングをしてGitで保存していますが、同様にRDi を使っているRPGやCOBOLの開発者たちもコードをGitに保存できます。スティーブが話したように、機能性と堅牢性という点で優れているのはRDi です。それに対して、Orionはとても基本的な編集ソフトであり、Gitはとても基本的な保管メカニズムです。私たちは、オープンソースを使っている開発者とRPGやCOBOLの開発者が混在した環境にいますので、それらのツールの統合モデルを提供する必要があるわけです。
RPGのオープン系言語との共存
――IBM i をお使いの方が、いろいろな選択肢を持てるということが分かりました。20年ほど前にJavaがリリースされた時、IBMがアプリケーションロードマップを発表しましたが、RPGがどんどんJavaに置き換わるというようなことが書かれていたと思います。今では完全に置き換わってしまうのではなく、RPGもあり、Javaもあり、ほかの言語もあり、いろいろつなげていくというのがIBMの考えと理解しましたが、正しいでしょうか。
アリソン
実は、私はそのロードマップを書いたチームの一員でした。我々の元々の意図は、言語が共存するということを伝えたかったのですが、当時、大半のお客様はRPGしか知りませんでした。ロードマップにJavaが登場するやいなや、皆パニック状態になり、RPGからJavaに移行しなければいけないとIBMが言っている、と勘違いされました。20年前は、アプリケーションを組む言語としてRPG、COBOL、Javaの中から一つを選ぶという決断をしていましたが、今はそうではありません。今は個々のモジュールを異なる言語で作成し、それらを組み合わせてアプリケーションを作ります。ですから、もう「すべてかゼロか」というような択一的な決断をすることはありません。私たちがやりたいことに最も適した言語を適宜使用すればよいのです。あのロードマップで、私たちIBMはあくまでも言語の共存ということを言いたかったのです。
――今までIBM i の長所の一つとして、資産の継承というのがとても大きかったと思うのですが、そういう意味ではその精神は引き継がれていて、RPGもその中に含まれる。さらには、Javaをはじめとするその他の新しい言語とどうつなげていくかという点でRPGは今後もどんどん進化するし、IBMは投資を継続することがわかりました。
後編に続く
