注目されるモダナイゼーションー ARCAD CTOインタビュー

IBM i ユーザーの一番の悩みは、古いRPGの資産継承だと、よく耳にします。スティーブとアリソンのインタビュー でも、RPGをどうモダナイズするかがキーポイントだと話がありました。そのような中で、今、非常に注目を集めているARCADについて、ARCAD Software CTOであるミシェル・ムーション（Michel Mouchon）氏にお話を伺いました。 ※ArcadとはIBM i で稼働するアプリケーション、データベースなどの情報資産の分析と見える化を提供するツールです。詳細はコラム【Arcad活用術】をご覧ください。 ――本日はお時間をいただき、ありがとうございます。早速本題に入りますが、ARCADの優位性、あるいは一番のセールスポイントを教えてください。 ミシェル 製品の優位性は、開発しているアプリケーションの新旧を問わず、DevOpsプロセスをエンドツーエンドで完全にカバーしていることにあります。IBMはIBM i 上での新しい開発スタイルやRuby、Node.js等の言語を推進しており、新たなツールが必要です。しかし、大半のお客様はレガシー・アプリケーションを抱えているのも事実です。私たちはARCADを使ってどちらの開発スタイルであっても同じレベルのアプリケーション開発ができるようにしたいと考えています。一般的に見ても、今日DevOpsが注目されている理由はその開発スピードにあります。あらゆることをすぐに手にしたいという思いが原動力となり、DevOpsで多くのレガシー・アプリケーションを1か月で機能拡張したり、変更を加えたりする方法を提供しているのです。 私たちの目標は、さらに開発のスピードを短縮することです。実際のところ、新しいテクノロジーを使えば ―例えばFacebookやAmazonのように― 数分でそれを行うことができます。 ARCADはRPGのモダナイゼーションとアプリケーション・ドキュメンテーションの機能を提供しています。これらはIBMが採用した製品です。IBM i  ユーザーにとって、この選択は大変よいものと思います。 IBM i のアプリケーション開発を現代的なものにするには、モダンな言語を提供することです。IBMはJavaにとても近いFF RPGを作り、プラットフォームをモダナイズし、その上で動くJava、Node.js、Ruby等の新しい言語を導入しました。レガシーなプログラムはFF RPGコンバーターでモダナイズします。これは世界的な現象ですが、IBM i の開発者の高齢化が進んでおり、私たちはお客様の現在の環境のモダナイゼーション及び、ドキュメンテーションを目指すべきと考えています。 ――IBM i の開発者の高齢化は、世界的に同じですか。 ミシェル そうです。世界中どこでも同じです。アメリカでもヨーロッパでも。新しい時代のアプリケーションを、新しい開発者たちに引き継ぐのは重要なポイントです。ですから、ARCAD製品は新しいテクノロジーを取り入れています。例えば、変更管理に関しては、自社の管理変更ツールであるARCAD AvenirにとどまることなくGitを使用しています。仮にARCAD Avenirがレガシー・アプリケーションとうまく調和したとしても、テクノロジーという観点での価値はもたらさないでしょう。これこそがARCADが評価されている進化のポイントです。私たちはすべての人が新しいテクノロジーを利用できるように、そしてIBM i 開発者、Java開発者、新しい世代の開発者全員が一緒に開発を行えるようにするためにあらゆるテクノロジーに対して扉を開いています。 ――とても興味深いお話です。ARCADをドキュメンテーション・ツールだと思っていたので、新しい技術との連携もできるとは思いませんでした。 ミシェル 例えばIBM i ではコンパイルを行いますが、すべての開発プロセスにはIBM i と密接な関係が存在します。新しいスタイルで開発する場合、そのプロセスはDevOpsでパイプラインと呼ばれる一連のブラックボックスになります。異なるブラックボックス群（つまり開発プロセス）を通過して、成果物は最終的に本番環境にデプロイされます。私たちの目標である製品作りは、これらのブラックボックスを生成することでしたが、同時に製品をオープンなものにしなければならないと私たちは考えました。DevOpsの観点から、それが正しい道だからです。私たちはこの開発を2011年に開始しました。あれからもう5年以上経っていますが、こうしたやり方をしているのは私たちだけだと思います。 ――それは素晴らしいことですね。ところで、ARCADはILE RPGはもちろんのこと、RPGⅢやIBM i のJava、その他の言語もサポートしますか。 ミシェル はい、新しいツールで既にサポートされています。Gitは、今やIBM i 上で使うことができます。私はクラウド上のプロジェクト管理ツール を使っていますが、IBMの開発者たちは他にもクラウド上で様々なツールを連係させ、それらを使ってIBM i の開発を行っています。私たちはこの大変ポピュラーなツール（2千万人ものユーザーがいる）を使い、Java開発だけでなく、場合によってはRPGによる開発も行っています。ARCADはIBM i とコネクションを共有し、ビルドを行っています。これこそが開発の要所であり、私たちが長年開発を行ってきた知識を余すところなく提供していると自負しています。 ――ARCADがすべてを管理するのですか。 ミシェル そうです。ただ、厳密にはARCADそれ自身はすべてを管理するツールではありません。私たちはIBM i を念頭に置いて、同じ方法でお客様がすべてを管理できるようにしています。例えばGit、 ラショナル・チーム・コンサート、Microsoftのチーム・ファウンデーション・サーバーを使い、あらゆる種類のシステム構成をIBM i で管理できます。 ――確かにドキュメンテーション・ツールといっても他とは違いますね。ドキュメンテーションのためだけのツールは私たちもたくさん見てきましたが、この違いが他社との差別化要因ということですね。 ミシェル 元々ARCADは変更管理プロセスの会社です。ですから、20年経ほど前に私たちがドキュメンテーション・ツールの開発を開始したとき、それ自体変更管理のツールになりました。ドキュメンテーションの目標は既存のプログラムに基づいた技術的ドキュメンテーションを提供することですが、同時にそれは現在あなたがやっていることにも基づいています。つまり、私たちの製品は変更管理プロセスにリンクされており、ドキュメンテーションは常に最新の状態にあるのです。すべてが変更管理の下にあると同時に、正確性を担保するためにすべてのものが変更管理の情報を使います。ですから、あなたは異なるバージョンのソフトウェアそれぞれのドキュメントを生成できます。それらは同じではないでしょうが、すべては私たちが最初に組み込んだデータベースの知識に基づいて生成されるのです。 ――面白いですね。ところで、今朝のインタビュー でアリソンはARCADには2つの機能があって、１つはドキュメンテーション機能で、もう1つはRPGからFF RPGへの移行機能だと言っていたのですが。 ミシェル はい、私たちには１０の製品がありますが、IBMは特に２つの製品を求めてきました。IBM社内ではRPGコンバーターと呼ばれています。 この製品を依頼してきたのは、私たちが20年以上に渡って古いアプリケーションを極めてきたことや、技術の高さがあることを知っていたからだと思います。私たちはコンパイラーチームと密接な連携の下で仕事をしました。IBMはコンパイラー、私たちはドキュメンテーション・ツールを担当し、お互いの製品をテストしました。実にこの仕事はIBMと私たちの稀なエンドツーエンドの関係でした。 ――IBMからリクエストがあったとは知りませんでした。アリソンはFF RPGのユーザー数が増加しているとも言っていましたが、そう思われますか。 ミシェル そのとおりです。売り上げは伸びています。販売部門に所属していないので販売実績の詳細については分かりませんが、販売が好調なのは実感しています。既に10万件を超えるコンバージョンの実績があり、それは10万件分のプログラムが変換されているということです。販売があるたびに私にはEメールが届くのですが、今朝もメールを受け取りました。ですから非常によく売れている製品であることは分かります。 この製品に関連して面白い話をしましょう。ARCAD RPGコンバーターを買って言語の勉強に使った人がいました。彼はJava言語も古いRPG言語も知らなかったのでプログラムを読めなかったのですが、FF RPGは読むことができたので、このツールを古いRPGからFF RPGに変換するのに使いました。それだけでなく、彼はこのツールを言語を学ぶため予備のドキュメントとして使ったのです。Java用に再開発されているので、もしFF RPGを.NetやJavaの開発者に与えれば、彼らは言語を学ぶことなく、元のソースを見ずに正確にプログラムを読むことができるのです。これは大変興味深いことです。 ――素晴らしいですね。私たちは言語をモダナイズするとともに、モジュール化することが重要だとも聞きました。 ミシェル モジュール化は機能の一部です。私たちはモダナイゼーションのための選択肢をいくつか持っています。例えば、サブルーチンをプロシージャに変換するというオプションがあります。こうすることで、このプロシージャを外部から見えるようにモジュール化し、資産として利用できるようなになります。モジュール化されたプログラムが作れるようになるわけです。 私たちの競合優位性は、おそらくこの領域で深化した製品にあると思います。100%とは言えませんが、99.9%の変換を保証します。これはとても高度な変換であり、投資効果が非常に高いのです。 ――RPGⅢをお使いのお客様のほとんどが、多くのサブルーチンを持った長いスパゲッティ・コードをお持ちだという点は同感です。それらのサブルーチンを外部プログラムに変換できたというのは驚きです。RPGプログラムをFF RPGに変換できるツールというのはARCADの他にはないのでしょうか？ ミシェル ARCADの他にもう一つありますが、ここで名前を言うのは差し控えます。ですが、それは私たちと同じ設計哲学に基づいて作られてはいません。私たちの製品は定義に注意を払い、コンバージョンを行う際にはプログラム全体の依存関係も含めてコンバージョンします。簡単な例として、MOVE命令が挙げられます。あなたはこれを単純にコンバージョンすることはできません。MOVE命令はフィールドサイズに依存して、フィールドの右側あるいは左側の一部のデータが切り取られたり、結果フィールドの余白部分をブランクで埋めたりしなければなりません。 ある場合には単純なコンバージョンでもうまく行くかもしれませんが、各フィールドのサイズとその依存関係を知らない限りうまく行くかどうかは分かりません。ですから、例えばIBMと私たちは一緒に仕事をしていますが、それはこれらすべての知識に基づいて私たちがしっかりと影響分析を行っていることをIBMは知っていたからです。私たちがツールを作り上げたとき、私たちは既にこの情報をデータベース化していました。あえて言わせてもらえば、このコンバージョンを行うのは私たちにとって朝飯前のことです。シンタックスの観点からは余計な仕事であるとしても、コンバージョンを行うためのすべての情報を持っています。ですから、単にシンタックスだけに基づいている競合他社の製品のほとんどはこれができないのです。 ――相当深いレベルまでコード変換をされていて、誰も競争相手にはなれそうもありませんね。最後に、ARCADの機能拡張や将来計画について教えていただけますか。 ミシェル はい。おそらく1か月以内に新バージョンをリリースします。新バージョンはRPGⅢ、RPGⅣ、FF RPGコンパイラー間のある特定の差異を考慮に入れており、フィールド管理にもいくつか変更があります。例えば、数値フィールドのサイズを小さくした場合、オーバーフローが発生する可能性があります。古いコンパイラーではこのオーバーフローはプログラマーの責任であり、コンパイルは通ります。しかし新しいコンパイラーはコンパイルを失敗させます。異なるコンパイラー間には違いがいくつかあります。私たちの実績から言えるのは、コンバージョンはうまく行きプログラムも問題なく動いたとしても、何かが動かないというわずかなリスクは依然として存在するということです。なぜなら、すべての開発者が正しいルールを用いているとは限らないからです。オーバーフローを生じさせないのではなく、私たちはオーバーフローをコンバージョンに利用します。コンパイラーがうまく動かないという事実（＝リスク）を使うのです。リスクを減らす、あるいはリスクを避けるために結果的にもう少し複雑なコードを生成する機能があります。私たちはこの分野で、現在FF RPGの下でフル・フリー・フォーマット（FFF）と呼ばれるものの開発に携わっています。新しいメカニズムではFFとFFF両方との互換性があります。FFFは古いスタイルのRPGコードを許しません。これこそが私たちの製品の優位性であり、コンバージョンの成功率を高めます。私たちの製品はFFFコンバーターであって、単なるFFコンバーターではないと言える点です。RPGに関しては、多かれ少なかれIBMのコンパイラーに起きる変化に対応します。私たちは生成されたコードを単純化できると考え直しており、そのことは確実に考慮に入っています。しかし何が起こるか分かりませんので、念のためラボと一緒に仕事をしています。 ――なるほど。今あなた方はIBMの開発チームとより密接な関係を持っているのですね。ちなみに、カナダのトロント・ラボはPOWER部門に属していますね。 ミシェル はい、トロント・ラボのほぼ全員を知っています。中でもRPGコンパイラー設計のチーフアーキテクトとはこれからも常に連絡を取り合うことになるでしょう。 ――トロント・ラボがPOWER部門下に置かれたということは、IBMがIBM i のアプリケーション開発に今後投資していくのでしょうか。 ミシェル そうですね。IBMは再投資を行わなければならないように思えます。IBM i については特に原点に戻ってモダナイゼーションに力を入れるべきでしょう。今回の動きにより、これらの投資は一部ですが効果を現しています。特にRDi チームに効果が表れており、RDi 開発メンバーをチームに取り戻すことに成功したのです。 最後に1点お話しておきたいことがあります。RPGコンバーターはRDi 上で利用できます。現代的開発について考えるなら、私たちは現代的ツールを使用するべきです。ポイントは、このツールはグリーンスクリーン上でも使用できますが、GUIで使うのがスタンダードです。Rationalの開発者はそれを支持しており、大半の開発者はそちらに移行しなければならないでしょう。フリー・フォーマットが使えるのはGUIを使ったツールだけです。RDi 上だけで利用可能であり、最早SEUでは利用できません。 事実、コードだけでなくツールもモダナイズするということは、モダナイゼーションに関して大変重要なポイントです。 ――RDi とはアプリケーション開発用のツールのことですね。ARCADは変更管理とドキュメンテーションのツールであり、両方の機能を連携させることができるということですね。 ミシェル おっしゃる通りです。 実際、私たちはIBMの開発部門と連携して仕事をしています。私たちの製品は開発に携わる人たちが利用でき、まさに彼らが欲する製品なのです。それはどんな場合にも、RDi と一体の製品であるかのように見えます。 ――なるほど、RDi で新しいコードを開発して、変更管理はARCADを更新するということですね。その機能はとても興味深いです。というのも、古いRPGプログラマーは変更管理という概念そのものを持っていませんから。 ミシェル これは大きな変化です。現代の言語やそれを管理するツールも変化しており、開発方法論も変化しているという事実を理解する必要があります。すべてが変化しているのですが、古い開発者たちにはそれを理解することが難しいのです。ですから、私たちはそれをスムーズに行う方法を提供しようとしています。しかし、同時に新しい開発者たちのことをもっと考える必要があるでしょう。私たちは新しい開発者たちを古い世界に連れ戻してはなりません。私たちは新しい世界に行かなくてはならないのです。この領域に関しては、他に選択肢はありません。 ――グラフィカル・インターフェースを提供するというのは、その一例というわけですね。若い開発者には使いやすく、面白くなってくることでしょう。 三和コムテック　中原様 そうですね、あくまでもDevOpsと言う概念の中でのドキュメンテーションとコンバージョンというのは、いわゆるスタートラインでしかありません。それ以外のライフサイクル・マネジメントの部分での変更管理や、ビルドしたりデプロイしたりと言う部分に関しても、ARCADはソリューションを持っていますし、オープンソースとの連係もしています。今後の展開も楽しみにしてください。 ――ARCADと言うとついそのコンバージョンの部分だけに目が行きがちですけれども、もっと大きな視点で捉える必要があるということですね。IBM i 以外で開発されている方も多いと思いますが、ARCADはそうした方々に対しても包括的にサポートできるツールだとわかりました。 本日はどうもありがとうございました。