オピニオン：いまなぜWebサービスか？
最終回　Webサービスインテグレーションと、それがもたらすもの

渡邊 純一
日本アイオナテクノロジーズ株式会社
パートナー・ストラテジー担当ディレクター
2002/5/22

　5月4日付の日経新聞の全面広告に、「ガンバレにっぽん経済 - ITによる経営革新の行方」と題して、国際大学グローバル・コミュニケーション・センター教授の中島洋氏と慶応大学大学院教授の國領二郎氏の対談が載っていた。國領氏の「1980年代後半に米国企業の業績が悪化した時代にオープン・システムを取り入れた。逆に日本はそのころ資金がありすぎて、メーカーの言われるままに金のかかる独自システムをそれぞれ作ってしまった。その後遺症がいま、企業統合が必要になった時代に桎梏（しっこく）になる」というお話を拝見し、思わず膝を打った。なぜインテグレーション（統合）が必要になるかを考えるうえで、ヒントを得たからだ。

■そもそもインテグレーションが必要になったわけ

　そもそも、なぜシステムのインテグレーションをしなくてはならないのか。システムがばらばらに分散しているからである。では、なぜシステムはばらばらに分散するのか。メインフレーム・コンピュータで包括的、一元的に管理しておけばよいではないか。この現状を、私は以下のように考える。

　対談にもあったように、米国では、1980年代後半から1990年代にかけて、システム化費用を低減させるために、情報システム・プラットフォームのダウンサイジング化が起こった。1980年代の企業業績の悪化に伴ってIT投資も減らす必要に迫られ、ミニコンやサーバを用いた低価格なシステムを構築することが急務になった。またメインフレームをベースとしたシステム開発体制では、部門ごとの細かいシステム化要求に応じていくための柔軟性もなく、部門ごとに必要なシステムを部門予算で導入していた。さらにいえば、まさにいま日本で起きているように、各企業が合併や買収の必要に迫られて、システム同士の統合を実現しなければならなかったのだ。その際には、旧来のシステムをすべてスクラップにして、1から作り直す予算など認められない。既存のシステムを何とかしてつながなくてはならなかったのだ。

　「システムの機能をオープンな形で標準化するということ、システム間のインターフェイスについても標準化された技術を使うということ」、これが米国の80年代を通じた経営環境の下で、情報システムに課せられた必然性であった。ERPもこうした時代の要請のたまものである。会計や人事、売上管理、在庫管理など共通性の高いバックオフィス系システムは、できるだけ標準化されたテンプレートをベースにしてシステムを構築しておいた方が、個別に開発するよりはるかに安価であり、経営環境が変わっても、比較的柔軟に対応できるという効果があった。経営環境の激変に伴い、経営のかじ取りの本質を考えるうえで、情報システムのあり方も一緒に考えておくことが重要であったわけだ。

■絶好調の経済がいまごろになって……

　翻って日本の状況はどうだろう。1980年代の日本の経済は絶好調であり、システム化投資も盛んであった。製造・金融・流通の各業界の大手企業では、競って大型汎用コンピュータを導入し、基幹業務システムを構築した。この時代に各企業の独自性の高い、カスタム・アプリケーションが数多く構築されている。西暦2000年問題の際にはこれらのシステムの多くをERPやオープン系システムへと移行させ、大半のレガシー・システムを捨てた企業もあったが、いまでもそれまで使っていたメインフレームを延命させている企業は少なくない。

　思うに、このようにシステムをカスタム・アプリケーションでがんじがらめにしていたのは日本人の凝り性ではないだろうか。日ごろの業務のやり方を忠実にシステム上で再現したいという気持ちの表れである。パッケージシステムでは、業務担当者が思うように使いこなすのは難しい。システムはかゆいところまで手が届かなくてはならない、みたいな思い入れがあったのだ。そして現在でもこうした思い入れは強いのである。またそうしたことが十分に日本企業の強みであったかもしれないのだ。会計だけでなく、広い業務領域をカバーするERPの導入でも、各企業はERPに手を加えて、企業独自のカスタム機能を植え付ける。しかし、残念ながら独自性の強いシステムはビジネス・プロセスの変革には対応できず、ましてや企業や事業の統合には弱い。先月のみずほ銀行の例は、昨今の銀行合併で生じるシステム統合において直面する、1つの様相ということもできよう。

　最新のテクノロジを搭載し、また業務機能が標準化されたERPやPDM、CRMシステムを導入するとなれば、システムはいやでも分散する。しかし、分散されたままではシステムは孤立した島である。それぞれのシステム間の情報がきちんと行き来しなくてはならない。一方、本来1カ所にまとまっているべき情報システムであるが、企業や事業の統合・分離など激変する経営環境に備えて、機能的に集約され、統合・分離がいつでも可能な形になっている必要がある。

図1　現在の企業システムは個別に分散している

　かくして、情報システムは分散したまま、統合できる形を必要としているのである。

■インテグレーション技術の潮流：EAI

　社内のシステムを統合しようという試みは、実は相当古くからあった。かつては、単一の環境であるメインフレーム・コンピュータでさえ数多くのシステムがばらばらに稼働しているという状態であった。このため、最初に考えられたのは情報（データ）の一元化である。そして広範囲な業務処理で対象とされるデータを可能な限り分析して、網羅性の高いデータベースを構築した。システムのプラットフォームが分散された環境では、分散データベース・システムを使って、データの一貫性を図ることも考えられた。その後に考え出されたオブジェクト指向理論では、データと業務処理（ビヘイビア）を一体化して、業務オブジェクトとして取り扱う。この方が柔軟性が高く、管理しやすいからである。かくして、業務オブジェクトごとに異なるプラットフォームへシステムは格納され、オブジェクト指向型の分散コンピューティング環境でのインテグレーションへと状況は推移する。

図2　インテグレーションプラットフォームを使って、システムを統合すべきだ

　現在有効なインテグレーション技術としては、以下のようなものがある。

（1） メッセージ・キュー型
IBMのMQSeriesがその代表例である。MOM（蓄積転送型）ともいわれる。それぞれ異なるシステム同士で、仲介役のシステムを通して、情報のやりとりを行う。仲介役のシステムは、それぞれのシステムからのノードをキューに蓄積し、非同期で相手方に送る。多量のトラフィックを持つ業務処理にも適している。

（2） RPC（リモート・プロシージャ・コール型）
代表例はCORBAであり、DCOM、Java RMIもこれに当たる。同期型通信の形態を取る。システム間をCORBAバスの形で結合し、システム同士をプラグインする形で利用することもできる。リアルタイムなリクエスト／リプライを要する業務アプリケーションに向いている。CORBAは当初パフォーマンスが悪いという指摘もあったが、現在では洗練され、海外の金融機関などでは、Web系システムとバックオフィスとの連携ミドルウェアとして使われることが多い。難しい技術ともいわれ、以下に説明するようにWebサービスに取って代わられるというのが欧米の動向だが、日本では通信、金融、官公庁関連などでまだまだ普及している。

（3） パブリッシュ・サブスクライブ型
異なるシステム間を相互非依存型でかつ疎結合な状態で連携させる業務アプリケーションに向いている。（1）のメッセージ・キューとの違いは、個別アプリケーションのPoint-to-Pointなメッセージ転送ではなく、1つのノードから発せられるイベント（メッセージ）を、それに関係している複数のノードがサブスクライブするということにある。例えば、複数の取引先に対して、一斉に「注文処理は完了した」、あるいは「登録処理が完了した」というようにイベントを通知できる。

　分散されたシステム間を接続する際に、やりとりするメッセージをどのように変換するかが問題となってくる。（1）や（3）型のEAIでは、それぞれにアダプタないし、それに類する特別の変換コネクタを要する。またEAIのコアな処理部分（インテグレーション・ブローカ機能部分）でも、各ベンダのプロプライエタリなテクノロジが採用されている場合が少なくない。ここ5年ほどの間に出てきたEAI製品でさえプロプラエタリな技術を持ち、導入も容易ではなく、かつ価格が高いという問題があったのである。

　先に述べたように、変化の激しい経営環境の下でカスタム性の高い独自システムを構築していれば、柔軟性に欠け、変化に対する適応力を失うであろう。インテグレーション・フレームワークでも同じことがいえる。広く業界で支持された、標準技術に基づく、汎用的かつ柔軟性の高いインテグレーション・テクノロジの採用が求められているのだ。

■Webサービスを使ったインテグレーションの特徴

　Webサービスは、すでに説明してきたようにXML、SOAP、WSDLをベースとし、HTTPやSMTPというインターネット・フレンドリなプロトコルに乗る。インターネット時代のユビキタスな環境ではうってつけの標準技術といえる。しかもこの技術は、IT業界各ベンダが支持した規格なのだ。手軽に電子メールを送るような感覚で、分散コンピューティング環境のシステム同士が情報の交換ができるのである。

　問題は、なぜこのWebサービスを使って、インテグレーションをすることができるのかである。

　実は、Webサービスは先の分散コンピューティング・アーキテクチャを基盤とした（2）のRPCのCORBAやDCOMの発展型である。CORBAやDCOMのようにインターネット環境下でパブリックにコミュニケーションするために、XMLをベースにして、SOAP、WSDLが考え出された。それでは、Webサービスでシステムをインテグレーションするためには、社内のシステムをすべてXMLやSOAP対応に作り替えなくてはならないのだろうか。答えはノーである。

　ポイントはラッピング技術である。CORBAが既存アプリケーションをラッピングすることができたようにWebサービスもラッピング機能を持つ。以下の図を見ていただきたい。

図3　Webサービスによってシステムを統合できる

　まず、図の左側のJ2EEアプリケーション・サーバであるが、Webシステム系アプリケーションの構築によって作成されてきたEJBコンポーネントは、Webサービスとしてその処理を公開可能である。しかしながらEJBの処理機能単位は極めて粒度が小さく、これだけをWebサービスとして公開できたにせよ、その利用範囲はコード検索のような局所的なものになるだろう。こうしたEJBの処理を複数で構成させ、その上位層として処理ロジックを持たせたうえでWebサービスを構成するのがWebサービス・コンポジットである。Webサービス・コンポジットはEJBをWebサービスとして公開するだけでなく、ビジネス・オブジェクトとしての機能粒度を持たせたものであると考えてよい。

　次に右側のもう1つのサーバでは、CORBAを使ってJava、C++といったアプリケーションをラッピングしている。またメインフレーム上にCORBAインターフェイス機能を搭載させて、メインフレーム上のアプリケーションについても、CORBAでラッピングすることができるのである。このようにしてCORBAでオープン系やメインフレーム・システムのビジネス・ロジックをラッピングさせたうえで、それをWebサービスとして公開することも可能である。

　WSDLでインターフェイス化されたWebサービスは、HTTP上のプロトコルに乗って社内・社外を問わず、「Webサービス・インテグレーション・バス」として機能することができるのである。

■Webサービスを使ったインテグレーション・ブローカとは？

　各システムがそれぞれWebサービスのインターフェイスを持つことができるようになったとき、それぞれは「サービス指向アーキテクチャ」を持つ形として認識されなければならない。個々のプログラム・ロジック単位ではない、「サービスを単位とした」ビジネス・ロジックが1つのオブジェクトとして形成され、それがWebサービスの単位として公開されることが大事なのである。これができてこそ、初めてWebサービスが公開されることの意味を持つ。単一のコード検索程度の情報がWebサービスで公開されるのに比べ、サービスが単位として公開されることによって、真にシステム同士の相互依存性の低い、疎結合なインテグレーションが実現できるからである。これなくして柔軟性のあるインテグレーションは実現できない。

　さて、こうした形でさまざまなシステムがサービス単位でWebサービスのインターフェイスを持ったとして、これで万事うまくインテグレーションを進められるであろうか。実は、まだ十分ではない。それぞれのWebサービスを通したトランザクションをどのように組み合わせ、コラボレート（連携）させるかという一番大事な課題が残されているのである。以下の図を取って説明してみよう。

図4　Webサービスのシステム統合には、ビジネスプロセス・エンジンが必要だ

　取引先から何らかの商品の発注があると、社内のシステムではその顧客に対するさまざまなチェック処理が行われ、次いで在庫の確認、在庫引き落とし、発送、売上計上といった業務の流れが出てくる。こうした一連の業務の流れを取り扱うのがワークフローである。ワークフローの中にはそれぞれ個々の業務タスクがある。顧客確認の業務タスクでは、コアの処理部分をすでに公開したWebサービス（コンポジット）を通して、EJB上のさまざまな処理を利用して結果を返す。在庫に関する処理部分ではアダプタを介してSAP/R3との連携を取る（SAP自体も今後Webサービスでその処理機能を公開できるようになるだろう。その場合、「アダプタ」は不要となる）。さらに、決済処理の部分ではメインフレーム上のシステムと連携する必要があるが、これもCORBAを中継して、その上にラッピングされたWebサービスと連絡を取ることになる。

　では、ワークフローと何なのだろうか。この実体は、Webサービスのインターフェイスをベースとしたビジネスプロセス・エンジンであり、サーブレットのような処理プログラムとして構成することができる。しかもJavaコードをプログラミングするのではなく、GUIを使って、各コンポーネントをつなぎ合わせ、処理条件を指定する形で生成することができるような製品が出ている。このワークフローについても、ベンダ固有の技術ではなく、WSFL（Web Service Flow Language）のように、Webサービスとの連携を前提にした標準化が検討されている。

　最終的に、Webサービスをベースとしたインテグレーションを行ううえで、下記の図のようなフレームワークが必要になる。

図5　Webサービスによってシステムを統合する際に必要となるフレームワーク

　これがインテグレーション・ブローカといわれるものの姿である。インテグレーション・ブローカ・スイート製品の中には、BPM（ビジネス・プロセス・マネジメント）、イベント・マネジメント、トランスフォーメーション機能（Webサービスへの変換など）、ルーティング機能、マッピング機能、トランザクション・プロセシング機能、ビジネス・ロジックのメタデータ化機能、加えて、各トランザクションのセキュリティ化（SSL対応、XAML対応、デジタル署名対応）が用意されるようになってきている。

■Webサービス・インテグレーションによってもたらされるもの

　「第3回　Webサービスは、ビジネスの変革に役立つか」の後半で取り上げた、「企業情報システムの標準的機能は、ビルディング・ブロック化やモジュラー化されて、ほとんどがASPベンダ、もしくはグループ会社に存在し、それらを組み合わせた形で業務プロセスが存在することになる。つまり企業内の各ファンクションの『モジュール化・可換化』が進む」というくだりは、実は今回取り上げたWebサービスによるインテグレーションのスキームが実現することによって成り立つと筆者は考える。

　現実には、これまでにそうしたアーキテクチャは存在しなかったし、企業情報システムの各機能がビルディングブロック化するということ自体が夢物語であった。ERPのように業務への適用範囲の広いシステムを導入して、企業情報システムを機能的にビルディングブロック化するということは、ERP導入の1つの目的ではあったが、そこにはどうしても企業の独自性の高いアプリケーションを組み合わせなければならないという事態が発生する。導入したERP自体をカスタマイズして固有のシステムを構築してしまうというケースも少なくないと聞く。これは本末転倒である。このことによって、システムは柔軟性を失うばかりか、場合によっては、ERPベンダの製品アップグレードも受けられなくなる。しかし、現実には固有のビジネス処理機能を構築しなければならないケースは少なくない。このような場合には、これを個別に構築したうえで、可能な限り標準的なインターフェイス技術を使ってERPと統合していくべきである。こうしたスキームを実現するためのソリューションが、これまでベンダ側から十分に提供されていたとはいえなかったのが実情ではないだろうか。ユーザーは、常にシステム構築の場面でやむにやまれない思いだったのである。

　筆者は、Webサービスによるインテグレーションがそうした課題を乗り越えるドライバとして役に立つということを真に期待していきたい。この方向に向けたソリューション開発の動きは、すでにIT業界を挙げて始まっているからである。

　以上で、筆者がWebサービスについて、提言しておきたかった一連の話題を4回にわたって一通り掲載することができた。時として脱線気味の論調であったり、冗長な説明が続いたりして、読者の皆さまに読みにくい点があっただろうことは深くお詫びいたしたい。これまでの連載内容で、少しでもご参考になった部分があれば幸いである。今後とも、Webサービス・インテグレーションの動向がどのように推移していくか、ぜひ見守っていただきたい。

本連載コラム 第1回　Webサービスは、本当にブレイクするか？　　　　　 　（2002年2月） 第2回　Webサービスの事例と今後考えられる適応分野　　 （2002年3月） 第3回　Webサービスは、ビジネスの変革に役立つか　　　　 （2002年4月） 第4回　Webサービス・インテグレーションとそれがもたらすもの　　（今回）

筆者紹介

渡邊　純一（わたなべ　じゅんいち） 1957年生まれ、東京都出身。成蹊大学経済学部経済学科卒。CRC総研（現CRCソリューションズ）に入社。アーンスト＆ヤング コンサルティング（現キャップ ジェミニ アーンスト＆ヤング）を経て、2000年10月にシリコンバレーのBtoBベンダの1つであるNetfish Technologies Inc. リージョナル・ディレクター。2001年5月、IONA Technologies PLCのNetfish社買収に伴い、IONAへ移籍。現在、同社日本法人（日本アイオナテクノロジーズ株式会社）、パートナー・ストラテジー担当ディレクターとしてパートナ企業開拓に携わる。著書に「実践eコラボレーション」（共著）　同文舘 2001年10月がある。 メールアドレスは junichi.watanabe@iona.com

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）