WDD2018レポート - DXを支える情報システム部門がこれから進むべき方向性

年一回の Wagby 開発者の祭典として企画した Wagby Developer Day も最初に沖縄で開催した WDD2012 から数えて 7 回目を迎えることができました。今年のテーマは「DXを支える情報システム部門がこれから進むべき方向性」とし、特別ゲストとして次の方々にご登壇いただきました。

  • 積水化学工業株式会社 元・情報システム部部長 寺嶋 一郎 様
  • グロース・アーキテクチャ&チームス株式会社 代表取締役社長/日本Javaユーザーグループ会長 鈴木 雄介 様
  • Starlight & Storm 代表/日本 Spring ユーザ会会長 長谷川 裕一 様

寺嶋様には35年にわたってユーザー企業の立場で実践してきた「内製」を語っていただき、それをふまえてDX時代には情報システム部門こそが中核となって活動すべき、というお話をいただきました。

f:id:ynie:20181127103728j:plain
寺嶋一郎様ご講演

鈴木様、長谷川様はそれぞれ技術的な視点から、エンタープライズアプリケーションが今置かれている状況ならびにSoE分野の技術体系を語っていただき、今後、情報システム部はどういうトレンドを理解すべきか、をまとめていただきました。

f:id:ynie:20181127130256j:plain
鈴木雄介様ご講演

f:id:ynie:20181127142354j:plain
長谷川裕一様ご講演

今年は業界全体のトレンドの中で Wagby をどう位置づけるかという「立ち位置」を明確にすることが必要な時期でした。寺嶋様、鈴木様、長谷川様には Wagby と少し離れて、中立的な目線で業界の全体像を語っていただき、その上で Wagby が必要となるところをそれぞれ指摘いただけので、とてもよかったです。個人的にはこの3名が集うイベントというのは他ではお目にかかることがないだろうと思っています。ご快諾いただき、改めて感謝です。

これに加え、今年はJP情報センター様、東京ガス様、横河ブリッジ様、インフロント様の Wagby 活用事例をはじめ、パートナー企業、出展企業様のご発表を含む合計17のセッションを開くことができました。昨年に続いて300名を超えるお申し込みをいただき、最後の懇親会も100名を超えるご参加で大いに盛り上がりました。かかわっていただいたすべての方々にこの場を借りてお礼申し上げます。昨年に続いて登場した Wagbee も大人気でした。

f:id:ynie:20181127134534j:plain
出展ブースで大人気のWagbee

すべての発表資料はこちらからダウンロードできます。ご参加いただけなかった方もダウンロードできます。
https://wagby.com/event/wdd2018/download.jsp

何のために基幹系を刷新するのか

私が当日発表した内容をかいつまんで紹介します。DX時代に対応するための基幹系刷新の考え方を次のように整理しました。

まず EA について。EA は本来、アーキテクチャのあるべき姿を関係者で共有するものですが、日本は残念ながらベースの見直しをせずに建て増しを繰り返してきたため、このような実情になってしまいました。

f:id:ynie:20181210101858p:plain
日本的 Enterprise Architecture の実情

改めて DX 時代とは、SoE がリードして SoR と連携するため、SoR の一部はパブリッククラウドにのっていくことが必要と考えています。

f:id:ynie:20181210101943p:plain
目指すべき形

ではどこから手をつけたらいいのか。アプローチの一つとして、ERPの解体と再構築を提案します。

なぜユーザー企業はERPのカスタマイズを行わざるをえないのか。ERPはもともと法律に基づいて業務を進める財務会計が得意ですが、これに業務部門の原価管理に必要な管理会計を混ぜようとすることが遠因です。部門ごとのニーズを Wagby で吸収することで ERP を軽くしましょう。ERP を素のままで利用できるのがベストですが、カスタマイズするにしても Wagby で開発した部分とのデータ連携だけにとどめることができれば可搬性は大いに向上します。

f:id:ynie:20181210102007p:plain
ERPの解体と再構築

もう一つのアプローチは、メールに Excel を添付して業務を回すというやり方を「やめる」ことです。

この方式はデータの手動転記処理や、巨大マクロによる保守不可能な業務を生み出してしまいます。そしてファイルであるため、セキュリティ上の問題(ファイルが盗まれてデータが流出してしまう)と隣り合わせです。この問題の解決で RPA を使うのは悪手です。問題の業務フローを固定化してしまうことにつながるためです。

根本的な解決は Wagby で Web アプリケーション化することです。権限によってデータの閲覧と編集制約をサーバで集中管理でき、データ流出についても監査ログがすべて残るということを担保に、悪意を持った操作を抑制することにつなげることができます。もちろん Wagby ベースなので開発したアプリケーションの変更や、開発者の引き継ぎ容易性も高まります。

f:id:ynie:20181210102034p:plain
脱Excel+メール

そして三つ目のアプローチは、SoE とのゲートウェイを提供することです。同じような業務ロジックを SoE と SoR のそれぞれで実装するという愚は避けなければなりません。トランザクション整合性を担保するべき業務処理は SoR に集中させ、SoE は UI に集中できるようにするのがよいと思います。

f:id:ynie:20181210102108p:plain
SoEへのゲートウェイ

この3つのアプローチから導かれるのは、経費としての基幹系から、SoEを支えることによる「稼ぐ基幹系」に転じることです。この実現こそが、DX時代の基幹系のあるべき姿と考えています。

f:id:ynie:20181210102151p:plain
稼ぐ基幹系へ

2019年のWagbyロードマップ

私たちはこのような姿を見据え、Wagby の開発を行なっていきます。Wagby R8 のテーマを一言で表現すると「マイクロサービス対応」ですが、具体的には次のようなステップを踏んでいきます。

  • REST API サービス提供に特化した形でのマイクロサービス対応。
  • UI 提供を含んだマイクロサービス対応。

前者は UI を切り離す形で、先行して提供します。UI はそのあとに対応します。Wagby の UI 実装技術は現在 JSP ですが、もう一つ Thymeleaf 版も用意します。Thymeleaf 版では jar 形式の Spring Boot 対応アプリケーションになるため、Cloud Foundry などの PaaS での動作がより容易になります。

f:id:ynie:20181210102403p:plain
今後の出荷スケジュール

マイクロサービス対応で具体的な開発ロードマップを掲げることができたのは今回の Wagby Developer Day 2018 の大きな成果でした。Wagby の優位性というかどうかはともかく、Wagby は次世代の基幹系で使ってもらうためにこういう方向に向かっている、ということをはっきりと示すことには意味があると考えています。