ESB／EAIを利用し、データ連携とコンポーネントで成長するシステムを構築する

プロセスをESB／EAIへ導入する流れ

　まず、最初に考えなければいけないところは、どの機能からESB／EAIを導入していくかという点です。例えば、図1のようなECシステム（注文から発送とその関連業務）を行うシステム全体があったとします。

　しかし、最初はこれらの図の中にある単位の業務をESBやEAIのような連携システムで置き換えようと思わない方がいいと思います。

　このような業務の流れの一部を置き換えようとしても、どこから着手すればよいか、他のシステムとの連携する際に入出力データはどのようにすべきかなどさまざまな課題が生じます。経験がない時には、まずは全体に大きな影響がない一方、ESBやEAIを導入することでもっとも大きなメリットを得られる個所から導入すべきと考えます。

最初に導入する個所

　ESBやEAIの導入を検討するときに最初に導入を検討すべきは、外部へのデータ出力処理です。ここで言う「外部」とは、全体システムから見た時の外部と捉えてもよいですが、もっと簡単に捉えればインターネット側への出力と捉えた方が分かりやすいと思います。

　どうして、インターネットへの出力処理が導入の第一歩かと言えば、以下のようなことに気を付ける必要がないためです。

• 外部に公開すべきデータなのでセキュリティ的に考慮点が少ない
• 最終的に人が見るデータの生成部分なので、処理の成功と失敗の把握が簡単である

　そして、ESBやEAIツールの特徴である標準で保持しているさまざまなデータ変換機能などが利用でき、それらを独自開発しないメリットが非常に分かりやすく体感できます。

処理をブレークダウンする

　図1の業務全体から、1つの処理である月次レポートを作成するという処理の中身をさらにブレークダウンしていくと、図2のようになります。

　例えば、完了通知という機能1つをとっても、その通知方法は現在のシステム開発ではさまざまな方法があります。開発当初では開発コストを最小限にするために電子メールでとしても、システムを利用する運用スタッフの役割の変化だけではなく、時代のニーズにも影響されてしまうため、変更しやすいシステム構成が望まれます。

　当初は簡単な開発でよかったので、そのまま作り込んでしまうケースが多いかもしれません。しかし、これが、SNS通知にも対応、さらには「それぞれの担当者が希望する方法で通知してほしい」などの要望が広がった場合には、どんどん開発コストが膨らんでしまいます。そこで、この部分をESBやEAIのような機能に頼ることで図3のように処理の外部化ができます。

　このような通知機能は他の機能にも使えるはずです。電子メール通知を実装すればよいというレベルからは多少、冗長的で、また、開発コストも若干多くかかってしまうかもしれませんが、このようなちょっとした考慮を入れることで全体的には効率化と利便性が高められます。

処理を出力から逆算していく

　先ほどの通知処理をESB／EAI連携できるようになると、次はその前の処理である「ファイルの保存」を同じように出来ると思うはずです。そのように考えた結果が図4です。

　これで2つの連続処理が、ESB／EAIの部品化ができる対象になりましたので、図5のように複数の処理の流れができます。

　このように機能を汎用化していき、その連続処理を作っていくことができればESB／EAIが導入しやすくなります。一般的に入力データは業務特有の個別事情を持つことが多いため、入力部分から導入していこうとすると最初の時点でつまずいてしまいます。

　しかし、このような出力から逆算していくと、導入しやすい個所がより見つかりやすくなると思います。

入力情報の抽象化と設計

　これまでの図だけをみていると、誰でも簡単にESB／EAIが導入できそうな気がします。特にSaaS型やパッケージ型のESBサービスであれば、これらのフロー図を管理画面上で記述すれば簡単に保存先や通知先なども定義できますので「ノーコード」で実装が可能です。

　しかし、実際にはそのようにうまくいくケースはあまり多くはありません。その理由が図6のように処理に応じた入力情報が必要になるためです。

　そして、多くの場合、この図7のような処理の流れを考えるはずです。

　このような処理にしても多くのESB／EAIは対応可能です。また、今回のケースに限定すれば、ESB／EAI側でそれぞれの入力情報を管理できればこのような複雑さは持ちません。

　しかし、実際にはそううまくいくケースは多くはありません。これらの設定は頻繁に変わったり、または情報を一元管理しないと、システム全体がどのように動いているのかどんどんわかりにくくなるからです。

　また、内部で情報を用意する流れを作ると、それに合わせて条件分岐処理の部分がどんどん複雑になっていく傾向があります。こうなってしまうと、もう、実際にコードを記述してしまった方が簡単で確実だとなってしまいます。

　筆者はこの部分の難しさが、ESB／EAIが多くのシステムにおいて導入されない原因の1つだと思っています。

　このような複雑さをなくすために、前述した「出力から逆算していく」という考え方が重要になります。つまり、図8のようにその後に処理に応じて、入力をまとめて作れるとその後の分岐や新たな情報取得などの余計な記述がいらなくなります。

　また、その入力データ情報もより抽象化して、その後の処理が何をしたらよいのか分かりやすいようにする必要があります。

　しかし、幸いにも私たちはインターネットを使う上でこの入力データの抽象的な定義方法を頻繁にURIという形でつかっています。このURIには2つの意味があり、1つは文字列内自体が入力になり得ること。そして、もう一つが入力データ自体の存在場所を指し示すことができます。

　例えば、ファイルを保存し、その後、その保存したファイルは電子メールに添付するといった場合には、ファイル保存では出力する先の情報であり、メール添付では添付データの入力情報にもなります。

　このようにESB／EAIシステムへの入力情報設計がその後の成功につながるか、失敗につながるかを決めていると言っても過言ではないと思います。