［IT Architect連動企画］
サービス指向アーキテクチャの未来を考察する（前編）
SOAはエンタープライズ・システムを変革するか？
多くのEAIベンダが次々とサービス指向アーキテクチャ（SOA）に名乗りを上げている。WebサービスとSOAの関係は？ サービス指向とオブジェクト指向とはどう違う？ そしてSOA時代が到来すると、エンジニアは必要なくなる？ SOAを取り巻く多くの疑問に、最新情報をもとにした回答をお届けしよう。（編集局） |
ITコンサルタント
安田 正義
2004/2/14
主な内容 SOAとは何か?エンタープライズ・システムにおけるSOAのメリット・（1）モノリシック・アプリケーション・モデルの特色 ・（2）SOAの特色 ・（3）モノリシック・アプリケーションのオープン・サービス化戦略
|
IT投資を行う企業の価値基準は確実に変わってきている。ITサービスを提供するシステム・インテグレータやパッケージ・ベンダもまた、顧客企業の動向に大きく影響を受けながら、自らのマーケティング戦略を変えていくことが迫られている。次の言葉は今後のエンタープライズ・システムおよびITサービスのあり方を占う言葉として、適切なポイントを突いていると思う。
The move to SOAs and the offshore outsourcing trend are a true
double whammy for developers in the next few years. |
ウォールストリート紙は、IBMの内部文書として、同社が3000人規模の社内プログラマの仕事を、インド、中国、ブラジルといったオフショアに移動することで、2006年度から年間1億6800万ドルのコスト削減を計画していると報じている[18]。Wipro、Infosysといったインド発のシステム・インテグレータはすでにNASDAQ上場を果たし、その株価は50ドル、88ドル（2月2日現在）と海外投資家の高い評価を受けている。インド国内ではコールセンター業務のアウトソーシング請負も盛んだ。グローバルでのオフショア・アウトソーシングの動きは止まらない。
では、オフショア・アウトソーシングと並ぶプログラマーへの脅威として位置付けられている「サービス指向アーキテクチャ」（以下、SOA）とはいったい何であろうか。
筆者はビジネスの観点から、SOAは次のように定義できると考える。あらかじめ断っておくが、この定義は一般になされているソフトウェア工学的なSOAの定義とは一見、大きく異なっている。一般的な定義については後述したい。
- サービス指向アーキテクチャの定義
- ビジネス・プロセスを実装したサービスを単位として、再利用可能なサービスを積極的に活用することで、ビジネス・モデルに従ったバリューチェーンの構築と変更を極めて迅速に（アジャイルに）かつフレキシブルに実現することを可能にするITアーキテクチャ
 |
| 図 SOAのアーキテクチャ |
「ビジネス・プロセスを実装したサービスを単位とする」とは、SOAの「サービス」が、信用照会、注文処理、在庫確認といった単位のビジネス・プロセスを実装していることを表している。
「再利用可能なサービスを積極的に活用する」とは、自前であらゆるビジネス・プロセスを新たに一から構築するのではなく、可能な限り社内外に存在する既存のビジネス・プロセスを再利用することを意味している。社外に存在するビジネス・プロセスを積極活用する場合には、ビジネス的にはアウトソーシング、IT的にはASP（Application Service Provider）、ユーティリティ・コンピューティングなどと呼ばれる。SOAはアウトソーシングの活用を促すITアーキテクチャである。
「ビジネス・モデルに従ったバリューチェーンの構築と変更を迅速かつフレキシブルに実現する」とは、経営戦略に基づいて設計されたビジネス・モデルを実現するために、製品開発・調達・生産・販売・物流といった一連のビジネス・プロセスを連結して、バリューチェーンを素早くかつ柔軟に構成することを意味する。
このように大胆にビジネスの観点からSOAを定義することには、エンジニアの方々からの反論が予想される。ここで補足をする形で、ソフトウェア工学的な観点からの一般的なSOAの定義を振り返っておきたい。この視点でSOAを定義する場合には、次のキーワードがまず重要になる。
- modularity（部品化）
- encapsulation（隠ぺい化）
- reusability（再利用性）
これらはプログラミングの基本原理と見なされており、SOAでそのまま引き継がれている。
modularityとは、複雑で大きな問題を解決可能な小さな部分に分解して実装していくことである[7]。encapsulationとは、内部で実装しているデータやロジックを外部から見えないように隠し、入出力インターフェイスだけが見えるようにブラックボックス化することである[7]。reusabilityは、いちいちすべてのプログラムを初めから作るのではなく、あらかじめ機能を実現している既存のプログラムの再利用を促す考え方である。
さらに次のキーワードになると、SOAが従来の分散オブジェクト指向とは異なったアプローチであることが明らかになってくる。いい方を変えると、「サービス」と「オブジェクト」の相違点がはっきりしてくる。
- service（サービス）
- coarse granularity（粗粒度）
- loose coupling（粗結合）
SOAで扱う対象単位はサービスであり、従来のオブジェクト指向で扱われる分散オブジェクトとは粒度が異なる。その粒度は、サービスの1つ1つのステップを実現していく分散オブジェクトに比べると、より粗いもの（coarse-grained）になる。分散オブジェクトでは、オブジェクトはデータとデータへのアクセス方法（メソッド）が一緒に定義され、オブジェクトへのアクセスはメソッドを通じてのみとなり、スタンドアロンのオブジェクト指向プログラムと同じく、分散オブジェクト間の関係は極めてタイトなものとなる（tight-coupling）。これに対し、SOAでのサービス同士は、それを実現する技術基盤であるWeb サービスの特質として、XML文書をやりとりするだけで済み、非常に緩やかな結合関係となる（loose-coupling）。オブジェクト指向というより文書指向（document-oriented）である[16]。
以上が、ソフトウェア工学的な観点で一般的に定義されているSOAの意味である。
それでは、SOAが従来優勢であったエンタープライズ・システム・モデルに比べて、どのようなメリットを持っているのかを確認していきたい。いままで主流を占めてきたエンタープライズ・システム・モデルは、SAPに代表されるパッケージ・アプリケーションであった。
高度経済成長が終わり、バブル経済も崩壊した日本で、とりわけ大企業において経営の難局を乗り切る現実的な解と見なされてきたのは、大幅な売り上げの増大が見込めない状況の中でいかにコストを削減することで利益を維持していくかという、守りの戦略であったと思われる。オペレーション・コストを下げるための思想的基盤と見なされたのは、マイケル・ハマーの『リエンジニアリング革命』[20]であり、ここで述べられている、ベスト・プラクティスに従ってテンプレート化された最適なビジネス・プロセスを実装したパッケージ・アプリケーションとして、SAPに代表されるERP（Enterprise Resource Planning）アプリケーションが登場し、エンタープライズ・アプリケーション市場を席巻した。
SAPが従来マーケティング戦略の基本としてきたのは、一言でいえば「すべての会社のビジネス・プロセスをSAPでシステム化しましょう」ということであり、さまざまな種類のSAPアプリケーション（「エンタープライズ・スイート」）でレガシー・システムを一挙に置き換える「ビッグバン・アプローチ」であった。また、このようなパッケージは自社内で自前で実装し、必要に応じた最小限のカスタマイズをする方式（「インストール＆カスタマイズ・モデル」）が標準の導入方法と見なされた。ここではこのような考え方を「モノリシック（一枚岩）・アプリケーション・モデル」と呼びたい。
しかしながら、昨今の変化が早いビジネス環境の中で、さらにはコスト削減というマイナスの考え方に立脚するだけでは勝ち組にはなれない状況となっている中で、モノリシック・アプリケーション・モデルが有効な領域はますます狭まっている（これはそもそもモノリシック・アプリケーションの存在意義としては自己矛盾である）。
まず第1の問題は、インストール＆カスタマイズ・モデルでは、長期間、高コスト（ライセンス費用およびコンサルティング・カスタマイズ費用）、高リスクでのプロジェクト運営を要求される点がある。SAPをビッグバン・アプローチで導入する場合には、ライセンス費用およびコンサルティング・開発費用を含めると最低10億円を上回り、導入期間は1〜2年にわたるのが標準である。巨額な投資をせねばならず、その回収期間は非常に長期にわたり、リターンの計算も難しいので、投資案件としては非常にリスクの高いものとなっている。
次に大きな問題は、「ベストプラクティス」や「フィット・ギャップ」といった言葉に代表される、パッケージに実装されている標準的なビジネス・プロセスで、現状の社内ビジネス・プロセスを大きく変えていくことの是非である。
多国籍にわたる巨大企業では、ビジネス・プロセスの標準化は社内オペレーション効率を高めるうえで効果があることは確かだが、他方で、コア・コンピタンス[19]と見なされる独自のビジネス・プロセスをなくすことで、企業の競争力を弱めてしまう危険も秘めている。このような場合には、アドオンという手法が用いられるが、基本的にはアップグレードを前提とするパッケージにおいてアドオン開発は矛盾するものであり、極力避けることが好ましい。そもそも、企業の戦略の根幹にかかわるビジネス・プロセスは各社独自なものであるはずで、このような領域においてテンプレートを前提とするパッケージを適用することは極めて危険なことであり、現実妥当性も低いのではないだろうか。
こうして最後に出てくる問題は、ほとんどのパッケージ導入企業には必ずパッケージを適用できない独自のビジネス・プロセスとそれを支える特別なシステムがあり、モノリシック・アプリケーションはこれらの異種システムとの接続性を保証しなければ全体オペレーション効率の最適化という目的を達成できないことになる。SAPなどのモノリシック・アプリケーションは従来、その語義どおり、異種システムとの接続を前提には作られておらず、システム統合が大きな問題としてのしかかることになる。
SOAでは、このような問題に対して、モノリシック・アプリケーション・モデルとはまったく異なったアプローチを取ることで解決を図っている。
これは筆者の独自見解だが、SOAモデルでは、コア・コンピタンスとなるビジネス・プロセスを創造し保持していく、いわゆる「イノベーション」の考え方を非常に重視していると思われる。イノベーションを重視する考え方は、オペレーション最適化とは正反対にあり、競争優位を築き、売り上げの大幅拡大を見込める製品およびビジネス・モデルの構築を狙いとしている。しかしながら、他方でコア・コンピタンス経営では、ノンコアなプロセスは積極的に手放し、パートナーなどの社外サービスを利用することでオペレーションの最適化とコスト削減を図ることも重要な手法とされている。
例えばパソコン産業を見れば、DELLがこのようなコア・コンピタンス経営を体現している先進的な例である。PCの各パーツは、EMS（Engineering Manufacturing Services）と呼ばれる部品製造パートナー企業に高品質かつ低廉な価格で生産を任せ、DELL自体はPCの顧客注文、組み立て、配送（納品）といったサプライチェーンの中核部分をハンドルし、全体を管理する立場にいる。
SOAのモノリシック・アプリケーション・モデルに対する第1の優位性は、システムが実現するビジネス・プロセスを「サービス」と見なし、サービスの連携によるバリューチェーンの構築を非常に柔軟にできる点にある。ソフトウェア導入という観点からいい換えると、サービスは必ずしも自社でインストール＆カスタマイズする必要はなく、既存のサービスで再利用できるものが社内外にあれば、積極的に活用していこうという小回りの利くアプローチを取っている点である。再利用可能なサービスがすでに存在する場合には、それとのインターフェイスが必要となるだけで、システム投資としても短期間、低コスト、低リスクで済む。
ビジネス・プロセスの取り扱いについては、ベストプラクティスのような標準モデルを強要することはなく、むしろコア・コンピタンスとなる特殊なビジネス・プロセスを保持し強化することにポイントを置いている。また、ノン・コアなビジネス・プロセスはアウトソースすることで会社を身軽にし、変化に柔軟に対応できる体制を構築することにポイントを置いている。
そして最後の大きな利点は、SOAのサービスはオープンスタンダードに従って相互の連結を前提として実装されているオープン・アーキテクチャである。1つ1つのサービスは、ソケットのように、付けたり外したりできる汎用性の高い部品として初めから設計・実装されている。これは先に述べたビジネス・アジリティが非常に高まるという利点のほかに、共通のサービスを異なった立場の利用者（オペレータ、顧客、セールスなど）が異なった場所（オフィス、自宅、ホテルなど）から異なったデバイス（ノートPC、携帯電話、PDAなど）を利用してアクセスする、マルチ・チャネルに対する一元的な対応をも可能にする[9]。
以上をまとめると、従来エンタープライズ・システムを席巻してきたモノリシック・アプリケーションと、新しいSOAの相違点は、次の表のようにまとめることができるであろう。
|
|||||||||||||||||||||||||||
| 表 モノリシック・アプリケーションとSOAの相違点 |
（3）モノリシック・アプリケーションのオープン・サービス化戦略
SAPやOracleなどに代表される、モノリシック・アプリケーションたることを標ぼうしてきたパッケージ・アプリケーションは、SOAの潮流の中で、大きくマーケティング戦略を変える岐路に立たされている。ガートナーは、今後企業がパッケージ・アプリケーションの選択を行うには、SOA的なアーキテクチャにどれだけ適合しているかを重要な評価基準の1つにすべきだという提言を行っている[11]。
CNETによれば、先日、米オラクルのCEO、ラリー・エリソンはOracle AppsWorldカンファレンスにおいて、従来Oracle製品のみでエンタープライズ・システムをすべて賄うべきであるとしてきたスタンスは誤りであったと認め、エンタープライズ・システムにおいてはシステム統合が必須となるという前提に立ち、SiebelやSAPといったほかのシステムとの連携をスムーズに行うために、Webサービスベースの「Customer Data Hub」というインテグレーション・ツールを提案したとのことである[21]。
同様に、SAPもWebサービスに準拠したNetWeaverと呼ばれる製品を昨年度リリースしている。NetWeaverは従来アドオン開発プラットフォームとされてきた独自規格のABAPに代わる統合アプリケーション・プラットフォームとして位置付けられており、Microsoft .NET製品やIBMのWebSphereなどのWebサービス準拠のアプリケーション・サーバとの相互運用性を確保している。NetWeaverの登場で、SAPも従来のモノリシック・アプリケーション・モデルを大きく改めようとしている。
CRMソリューションの分野ではSalesforce.comの登場をきっかけに、より先行した形で各アプリケーション・ベンダのSOA対応が求められている状況にある（Salesforce.comのCEO、マーク・ベニオフのIT業界展望は非常に面白い見方なので、ぜひ一読されることをお勧めする[22]）。
CRMのトップ・ベンダであるSiebelは、UAN（Universal Application Network）を提唱することで、Siebel製品とほかのアプリケーションとの統合の問題を解決しようとしている。UANは、まさにSOAでいうサービス（ビジネス・プロセス）をテンプレート化し、Tibco、webMethods、Microsoft BizTalk ServerなどのBPM／EAI製品にこれらテンプレートを取り込むことで、外部からSiebelの各種サービスをプラグインして簡単に利用することを可能にする統合アプローチである。
しかしながら、Salesforce.comの登場はインストール＆カスタマイズ・モデルに立脚するSiebelのマーケティング戦略そのものに動揺を与え始めている。Salesforce.comはCRMソリューションをASP形態で顧客に提供していくビジネス・モデルを採用しており、ソフトウェアはユーティリティとしてインストールする必要なく利用可能であるという点を強調する。実際にSiebelなど大手エンタープライズ・パッケージ・ベンダのライセンス収入がここ3年で低下する中で、Salesforce.comはライセンス収入を2000％伸ばし、シリコン・バレーでは、Googleと並ぶ新しい有望IPO銘柄として投資家の注目を集めている。
Salesforce.comの成功とマーケット・シェアの侵食に対抗し、SiebelはUANに加え、IBMと組んでCRM OnDemandというASPサービスを開始した。しかしながら、ベニオフも指摘するように、ユーティリティ・コンピューティング・モデルとインストール＆カスタマイズ・モデルは、そもそもビジネス・モデルとして両立し得ない部分があり、Siebelは自分自身のビジネスを食い殺すことになるであろうと手厳しい。今後、SiebelがCRM OnDemandという新しいビジネス・モデルをどのように融和させていくのかは、見どころである。
CRMという、通常、各社において営業・マーケティング戦略というコアで独特であるはずのビジネス・プロセスでさえ、ユーティリティ・コンピューティング・モデルの適用が成功しだしている点は注目に値する。企業内のビジネス・プロセスでは、会計管理、人事管理など、より一層標準化・汎用化されたビジネス・プロセスが存在しており、今後これらの領域でユーティリティ・コンピューティング・モデルを標ぼうした競合ベンダが登場してくる日も近いのではないだろうか。
◇
今回はモノリシック・アプリケーションに対するSOAの優位性を明確にし、エンタープライズ・システムで起こりつつあるオープン・サービス化の流れを解説した。後編では、エンタープライズ・システムにSOAを導入するに当たって課題となっている諸問題を考察しよう。（後編に続く）
| Index | |
| ［IT
Architect連動企画］ サービス指向アーキテクチャの未来を考察する |
|
 |
前編 |
後編 |
|
| 筆者プロフィール |
| 安田 正義（やすだ まさよし） 株式会社Agathon（アガトン）代表取締役兼コンサルタント。SOAを中心に業務プロセスを支えるシステム統合基盤の要件定義・分析・設計・開発に従事しているITコンサルタント。 連絡先はmasayoshi.yasuda@agathon.co.jp |
＜この記事へのご意見は、「XML & Web Services 会議室」へお寄せください＞
 |
サービス指向アーキテクチャの未来を考察する |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
