.NETテクノロジーとSOAの関係（2/5 ページ）

[下村恭（ハンズシステム），ITmedia]

実際に即したSOAの定義

　ここまでの技術的アプローチは、あくまでも技術があっての設計技法で、言うならば「As Is」の関係にある。つまり、「あるがまま」の状態だ。しかし、冒頭で述べたように、SOAの考え方というのはWebサービスに縛られる必要はない。もっと広範なシステム設計としての考え方としてSOAを捉えるほうが、より実際的と言えるだろう。その意味で「To Be」（「あるべき姿」）のSOAを考えることが大切だろう。

今までは、どちらかというとIT技術側からSOAが進化してきた。言うなれば「あるがまま」（As Is）でSOAを実現しようとしていた。これからは、「あるべき姿」（To Be）として、ビジネス側の要求や実際の業務にしたがってSOAによる設計開発となっていく。それだけの環境が整いつつある（Microsoft Tech・ED 2005 Yokohamaのセッション「Visual Studio 2005によるSOAの実装、講師：森屋英治氏」から）

　では、あるべき姿を求めた場合のSOAの定義はどのようになるのだろうか。一般的なビジネスから考えてみることにしよう。

　どのような企業でも、ビジネスを行い利益を上げていこうとすると、何らかの企業活動が行われているはずだ。これは、例えば小規模商店であれ大手商社であれ同じことで、仕入れ、販売、経理などといった仕事（企業活動）はどのような規模でも存在する。こういった仕事をビジネスケーパビリティという。これに対し、仕事のやり方は各企業でまちまちだ。例え同じような規模の、同じような営業内容の企業どうしであっても、その仕事のやり方は決して同じではない。こうした仕事のやり方は、ビジネスプロセスという言葉で語られる。

　近年、ビジネスの変化のスピードは、ますます加速してきている。企業間の連携は当たり前、企業統合でさえ突然実行される場合もある。こうしたビジネスを取り巻く環境の変化に対して、ビジネスケーパビリティは変化が起きにくいが、ビジネスプロセスは簡単に変化してしまうと言ってよい。ここが、SOAでシステム設計を行う際の考え方の中心だ。つまり、ビジネスケーパビリティを単位として、大きなサービスを考え、これを細分化していく方法で、システム全体を設計する。ビジネスプロセスは、サービスの内部に隠蔽してしまい、ビジネスのやり方が変わったとしても、連携する外部のシステムに影響を及ぼさないようにしようというものだ。

　従来、企業システムは普遍であると考えられてきたため、銀行間の統合などの例を挙げるまでもなく、こうした近年のビジネスの変化にシステムが追いついていけないという事態になっている。このような変化に対して、柔軟性のあるシステム設計を行う方法の1つがSOAである。

　つまり、SOAとは、さまざまな企業活動を実際に即した粒度のサービスという単位に分割し、それぞれのサービスをコントラクト（契約）に基づいて、他に提供するための仕組みであり、その設計方法といえる。

.NETテクノロジーはどのようにSOAをサポートするのか