レガシーアプリケーションとモダンなアプリケーションの接点を、APIを用いて生成するソリューションを提供するOpenLegacyのCEO/共同創業者が来日、ThinkITのインタビューに応えた。OpenLegacyは元IBMのコンサルタントが2013年にイスラエルで創業、現在はアメリカに本社を置いている。今回は来日したCEOのRomi Stein氏と、日本支社であるオープンレガシージャパン株式会社代表の内田雅彦氏にリモートでインタビューを行った。
![インタビューに応えた内田氏(左)とCEOのStein氏(右)](https://thinkit.co.jp/sites/default/files/article_node/1956801.jpg)
インタビューに応えた内田氏(左)とCEOのStein氏(右)
OpenLegacyは元々IBMで働いていたStein氏とCTOであるRoi Mor氏が立ち上げた企業だ。OpenLegacyのソリューションは、レガシーなアプリケーションをモダナイズする際の工数が非常に大がかりになってしまうという問題を解決するために作られたものであるという。
OpenLegacyの対象になるのはレガシーなアプリケーションをまだ使い続けているユーザーということになりますが、それであればIBMの中でこのソリューションを開発して提供すれば良かったのでは?
Stein:IBMは良い会社だと今でも思いますし、私の妻は今でもIBMで働いています。しかし、実際にレガシーなアプリケーションを使っているユーザーは、IBMユーザー以外にも多く存在しているのです。弊社の顧客のうちIBMのシステムを使っている企業は、現在では40%くらいだと思います。他にはOracleのユーザーも多くいますね。また、UNIXのシステムで稼働しているレガシーなSOAのアプリケーションもたくさん存在しています。そこでIBMとはパートナーとして関係を築き、その他のベンダーともパートナーとして付き合うためには起業が最適な解答だったと考えました。レガシーなシステムとクラウドネイティブなシステムを接続するために、パブリッククラウドベンダーやRed Hatなどとも良い関係を築けていると思います。
![AWSのマーケットプレイスにはOpenLegacyが存在している](https://thinkit.co.jp/sites/default/files/article_node/1956809.jpg)
AWSのマーケットプレイスにはOpenLegacyが存在している
OpenLegacy Hubというのが製品名になりますが、実際にはレガシーなアプリケーションから必要な機能をRPCで呼び出す形で利用するということになりますよね? そのためのサーバーは必要ないのですか?
Stein:そうです。我々のソリューションは、ミドルウェアでも連携するための特別なサーバーでもありません。実際にレガシーなCOBOLのアプリケーションからAPIを使って機能を切り出して、すでに存在するAPI Gatewayに載せることで稼働します。つまり追加のサーバーもミドルウェアも必要ないのです。
これについて、Stein氏はスライドを使って追加の解説を行った。
![レガシーなシステムのモダナイズの流れ](https://thinkit.co.jp/sites/default/files/article_node/1956810.jpg)
レガシーなシステムのモダナイズの流れ
このスライドではレガシーなCOBOLからAPIを使って機能を切り出し、次のステップでクラウドサービスなどに移行することで既存のアプリケーションには極力手を加えずに、新しいモバイルアプリなどの開発が可能になることを示している。
では、どうしてデータベースの同期やメッセージ交換、バッチシステムによるデータ転送などではなくAPIなのか? この疑問に対する説明が次のスライドだ。
![アプリケーションのAPIを使う理由を解説](https://thinkit.co.jp/sites/default/files/article_node/1956811.jpg)
アプリケーションのAPIを使う理由を解説
リアルタイム参照が可能であること以上に、アプリケーションの改造やミドルウェアの追加を避けたいということも大きな理由となるだろう。
開発フェーズと運用フェーズのスライドを見比べれば、OpenLegacyの特徴がよくわかる。次のスライドは開発時のもので、メインフレームやデータベース、SOAサービスなどからデータ交換を行うためのコネクターを自動生成するのがOpenLegacyの役割だ。
Subscribe to get access
Read more of this content when you subscribe today.
レガシーアプリケーションとAPI Gatewayの中間に存在するコネクターが実体
そうして自動生成されたコネクターを既存のAPI Gatewayに載せて実行するのが運用時の形になる。
![API Gateway上で実行されるコネクターが実体](https://thinkit.co.jp/sites/default/files/article_node/1956813.jpg)
API Gateway上で実行されるコネクターが実体
より詳細に解説しているのが次のスライドだ。
Subscribe to get access
Read more of this content when you subscribe today.
多くのレガシーなシステムが左側に並んでいるが、ポイントは自動化だと言う
ここではソースコードを変更せずに多くのレガシーなシステムから機能を切り出してAPI化し、それをAPI Gateway上で実行することで連携が可能になることを解説した。
![このシステム例では勘定系システムをAWSのAPI基盤から利用している](https://thinkit.co.jp/sites/default/files/article_node/1956805.jpg)
このシステム例では勘定系システムをAWSのAPI基盤から利用している
このスライドでは勘定系システムからAWSに接続し、必要な機能をAWS上のAPI Gatewayを通じてスマートフォンアプリケーションから利用していることがわかる。
実際にレガシーなシステムをモダンなシステムの一部として利用する際の方法は理解できました。しかしそもそも日本のレガシーなシステムのユーザーはAPI Gatewayを自分で選んで使うということに慣れていないのでは? どちらかと言えばベンダーが全部用意してくれるのを待っていると思いますが。
内田:それに関しては約1年間、営業活動を続けてわかったことがあります。私自身は過去にApplication Performance Managementのツール(AppDynamics)の日本展開をやっていた経験もありますが、APIを用いてレガシーなアプリケーションを使うという点を理解した上で、それをAPI Gatewayに載せるというのを理解してもらう必要があったわけです。そこに難しさがありますね。やはりすべてベンダーがやって欲しいとおっしゃるユーザーさんもいらっしゃいます。
OpenLegacyはAPIのためのサーバーを使いませんが、レガシーなシステムのユーザーは例えばGoogleが提供するApigeeなどのモダンなAPI Gatewayには慣れていません。AWSも同様です。そういう状況で日本のユーザーを掘り起こすことは非常に難しいですね。そこで外資系の日本法人や、レガシーなアプリを持っていてもその辺りの発想が柔軟な企業を選択してアプローチしています。
日本法人の構成は?
内田:本社は120名という体制ですが、日本は社員4名という体制で活動しています。これからはパートナーを増やしていくというのが営業としての戦略ですね。島根銀行のようにすでに事例として公開しても良いというユーザー様もいらっしゃいますので、これからは拡大していけると思っています。
![導入事例として島根銀行が紹介されている](https://thinkit.co.jp/sites/default/files/article_node/1956814.jpg)
導入事例として島根銀行が紹介されている
島根銀行は、メインフレームとの疎通テストがわずか2時間で終了し、計画していた18本のアプリケーション開発とテストも予定通り完了したとして、OpenLegacyの効果を評価しているという。
レガシーなアプリケーションをモダナイズするためにAPI Gatewayを使う、特別なサーバーやミドルウェアを使わないというのが特徴のOpenLegacyだが、日本のユーザー企業にこの利点を理解してもらうのはなかなか難しいだろう。しかし島根銀行の事例のように「簡単にできて驚いている」といった顧客の声は、レガシーなシステムを簡単には処分できないエンタープライズ企業には響くのではないだろうか。今後の成長に期待したい。