或る SIer 様から、Wagbyのパートナーになるにあたって、次の文書を用意していただきたいというお申し出がありました。
ジャスミンソフトが ”メーカー” の立場で考える Wagby の今後のロードマップ（中長期計画）
ジャスミンソフトの ”企業” としての今後のビジョンと、私が考えているリスクヘッジ策
この情報を経営層に示す予定があるとのことでしたので、それならいっそ私の考えをブログに書いてもいいですか？と打診したところ、ご快諾いただきました。PowerPoint ではなくブログで大丈夫、というのはいい時代になったものです。
Wagby の今後のロードマップ（中長期計画）
2019年の計画はこちらに記載していますので、そのあとの話を書きます。
https://wagby.com/product/roadmap.html
Wagbyは（たまたまですが）2018年9月に公開された経済産業省発の “DXレポート” のメッセージと良く合っています。具体的には、これからレガシーシステムを刷新するなら次の要件を盛り込むことが重要と考えています。
- パブリッククラウドで動作すること。
- マイクロサービス化、すなわち部分的なモジュールの入れ替えを可能なアーキテクチャとすること。
- 回帰テストを含めた、システムの入れ替えを数日で完了できる DevOps 体制を敷くこと。
何のために？それは DX 時代は SoE と SoR の連携が必須であり、SoR は SoE を支えるアプリケーションのインフラという役割を担うためです。より具体的に書くと、例えばこういう視点で説明できます。
- 社内システムだからセキュリティは多少甘くても大丈夫、は許されなくなります。SoE層はパブリッククラウドで動作しており、そこからオンライン系は REST API で、非同期処理系はメッセージキューで SoR 層と連携されます。おのずと SoR 層もパブリッククラウドで動作させることになり、セキュリティは SoE と同じレベルが求められます。
- もちろん SoR なので安定稼働かつ無停止運用という要件はこれまでもありましたが、これに加えて SoE 層からのビジネス要求の変化に追随し、部分的なシステムの入れ替えを行えることが必要です。全入れ替えは SoR 層ももちろんですが、SoE 層にとっても負荷が大きすぎます。もちろん、変更に対して再テストに何ヶ月もかかるというのも許されません。回帰テストを充実させ、問題があればすぐに戻せる、かつ迅速に修正して再び回帰テスト、というルーチンを実現することになりますが、この点は SoE の文化を SoR が取り入れることになるでしょう。
その実現のために Wagby はいくつも布石を打っています。
まず Wagby の基盤です。Java ベースであることはもちろん、Spring の方向性に沿っていくとはっきり表明しているのは Wagby くらいでしょう。その上で 2020 年以降ですが、Spring が提案するリアクティブプログラミング時代に私たちも乗って行こうと考えています。
現在の Web の仕組みは残しつつ、新しくリアクティブ対応を図ることで、SoE 層からの大量リクエストに耐えられる SoR のインターフェースを提供します。このためには Wagby の古いコードが技術的負債になっていることがわかっており、Spring についていくために Wagby の見えないところもアップデートしていくことが求められています。難易度は高いですが、実現できれば Wagby 利用者は安心して SoE 層との連携に Wagby を選んでよかったといえることでしょう。
もちろんこれと並行して Wagby のより一層のモジュール化、マイクロサービス化、そしてパブリッククラウドで動作させるための細かい使い勝手の向上といったテーマが山積みです。しかし超高速開発ツールはこのような視点をもつ必要があると考えており、Wagby は王道を進むつもりです。
そしてもう一つは、回帰テストのためのフレームワークの提供です。すでに Wagby Testing Framework として製品に同梱しています。回帰テストの開発のしやすさまでを含めて Wagby という製品をアピールしており、地味ですが競合製品に対して優位性があるテーマと考えています。（実際には WTF があるから、という理由で Wagby を選んでいただくようなことは、今のところありません。ですがあとで "なるほど！ WTFは便利だ！" とおっしゃっていただけるようになると信じています。）
最後はカスタマイズのしやすさをさらに高めることです。Wagby は生成された Java コードのカスタマイズ性が高いことをうたっていますが、これに加え最近は「（サーバサイド）JavaScript」によるカスタマイズに人気があります。この分野ではやはり Graal VM に注目です。Wagby が Java ベースであることに変わりはなく、それでいて Graal VM を土台とすることでスクリプトでのカスタマイズが一層容易に、かつ高速に動作することが期待できます。
まとめますと今後の Wagby は「Springのリアクティブ対応に合わせる」「回帰テストの書きやすさをアピールする」「Graal VMへの対応」という方向で進んでいきます。これらはすべて SoE と SoR の融合を意識した次世代基幹系を支える重要な基盤技術ですので、私たちの視点にズレはないと考えています。
ジャスミンソフトのビジョンとリスクヘッジ策
ジャスミンソフトは Wagby の製造ベンダーに徹します。私は株式上場を考えていません。それにかかる時間があれば、すべて製品開発と海外展開にあてたいと希望しており、実際に日々、そのように活動しています。
大手ベンダーや海外製の著名ツールからみると、まだ Wagby は発展途上と思われるかもしれません。しかし私たちが体験してきたこの数年は十分に実りあるものでした。日本紙パルプ商事株式会社というユーザー企業が当社の株主になって支えていただけるようになり、大手ユーザ企業による採用事例が着実に増え、海外展開も始まりました。そして日本だけでなく世界的にみて、システム開発自動化のトレンドがあります。（日本では「超高速開発」で知られていますが、海外では「Low Code Platform」と呼んでいます。）
このブログを書いている時点でWagbyの採用社数は370社を超えましたが、これを1000社にすることが直近の目標です。少なくともそれまで私と当社の開発チームはWagbyに注力します。第三者割当増資によって無借金で経営できる基盤ができたため、財務上の不安もなく、ひたすら開発に集中できる環境にあるというのは大変ありがたいです。もちろん Wagby がこけたら会社もこけるという意味ではリスクかも知れませんが、一つも成功させずにあれもこれも手を出すほど私は器用ではないので、Wagby に集中します。
（ちなみに当社を支えるもう一つの製品「住所正規化コンバータ」もあり、こちらも順調に大手ユーザ企業の導入が進んでいます。国内のカード、ポイント経済、物流で扱う住所の正規化というテーマで少なからずお役に立っているのですが、今回のテーマとずれるので語りません。正確には当社は二つの製品がある、ということを付記しておきます。）
ということで私自身、世界のトレンド、技術的な方向性、会社運営の手堅さ（新株主には “堅すぎる” と思われている節もあります）といった点を意識しながら Wagby を成長させ、Wagby のパートナー企業、そしてご利用いただいているユーザ企業のお役に立ちたいと希望しています。このような話でご納得いただけたかどうかはわかりませんが、そういう私たちなので、是非とも末長くお付き合いをいただけることを願っております。
