現在、企業のIT基盤に最も求められる要求とは何だろうか。それは、文字通り経営に役立ち、安く、そして早く提供される、いわば「業務に奉仕する基盤」である。そしてこれらがSOA(Service Oriented Architecture:サービス指向アーキテクチャ)に期待され、目指す目的である。
しかし、ITの世界でこれらの目的が掲げられることは決して新しいことではない。では、SOAというシステムアーキテクチャは従来と何が異なるのだろうか。それは、経営や業務に直接携わる人間が、自分の望むビジネスプロセスを自ら設計・定義し、ITから提供される「サービス」を直接定義していくという点である。
SOAではアプリケーションの機能を業務に必要な「サービス」という単位に分け、それを組み合わせて全体を構築するITの設計手法である。ここでまず、SOAでいう「サービス」について知っておく必要がある。
最今注目を集めているアプリケーションの新しい利用形態であるSaaS(Software as a Service)でも「サービス」という言葉が使われており混同されがちだが、SaaSでいうサービスとSOAのサービスは根本的に意味が違う。SOAでいうサービスとは「部品」のことであり、SaaSとはベンダーが提供するアプリケーションの機能をユーザーがサービスとして利用するという意味である。
SOAでいう「サービス=部品」は、例えば「受注処理サービス」や「在庫確認サービス」「住所変更サービス」「信用照会サービス」など、ビジネスプロセスで用いる言葉が使われ、一般に「ビジネスサービス」と呼ばれる。SOAのサービスは企業のITを構築する1つ1つの部品を意味し、それらはビジネスプロセスとの結び付きが強いことが特徴だ。
これまでのITプロジェクトを考えてみたい。業務部門はプロジェクトの過程において要件を提供する側であり、決してビジネスプロセスを作る側ではなかった。そのため、業務部門はITが分からない、IT部門は業務部門のニーズを引き出せないといった理由で発生するコミュニケーションエラーにより、最終的な成果物が結局経営や業務に役立たないという悲劇を繰り返してきた。そもそも、現代の企業で業務部門とIT部門がお互いのことを深く理解しようとするには、互いが複雑になり過ぎているのだ。それならば業務担当者が主体的に考えられるように範囲を限定し、ビジネスプロセスを作る権限を委譲すればよい。
SOAでは、下図のように業務担当者は自らが定義するビジネスプロセスに必要なビジネスサービスを選択していく。ビジネスプロセスの変更は自ら実施でき、必要なビジネスサービスに変更があれば、その部分だけを変更することで対応できるようになる。
一方IT部門は、業務部門が望むビジネスサービスを異種環境のアプリケーションの機能から抽出して組み合わせ、複合アプリケーションとして業務部門に提供する。各機能がアプリケーションやプラットフォーム環境に依存しないよう、WebサービスやJMS(Java Message Service)といった標準方式で呼び出せるように構築し、各機能を組み合わせてアプリケーションを構築しやすい環境を作っていく。

SOAでは業務部門とIT部門の協業が円滑に進められるように、IT基盤を幾つかの階層に範囲化している。それは、下図のようなサービスの「利用」「提供」「組成(オーケストレーション)」「統治(ガバナンス)」という限定的な階層である。それぞれの階層に属する人をサービスの「利用者」「提供者」「組成者」「統治者」と呼ぶ。
SOAでは、サービスの利用者(主に業務部門)はどのビジネスサービスを利用するかだけを考えていればいいし、サービスの提供者(IT部門)はサービスの利用者から求められるサービスをいかに効率よく提供できるかを考えていればいい。サービスの組成者(IT部門)はそうして社内にできていくサービス群をどう組み合わせて全体最適化するか、ということだけを考えていればいい。この階層構造は業務部門とIT部門の分業を円滑にする。
業務担当者が自らビジネスプロセスを設計することで、新製品の導入や新制度への対応といった変化に対しても迅速に適応できる。SOAにおける階層構造は変化に対しておのおのの制約を極小化する効果もあり、「疎結合」と表現されるように、互いが影響し合う範囲は各階層内に限定される。サービスの利用者は自分が業務で必要とするビジネスサービスを定義し、サービスの提供者とのコミュニケーションを図る。サービスの組成者はサービスの提供者が提供するさまざまなサービスを組み合わせて全体最適を図る。範囲を限定することにより、機動的でスピード感のある開発が可能となるのだ。
また、階層構造は従来のプロジェクト運営を変化させる。これまでのプロジェクトでは特定の業務領域を中心に組織化され、プロジェクトメンバーはその業務領域内で活動していた。一方、SOAの考えではプロジェクトが特定の業務領域であったとしても、各階層の範囲が限定的であるために、プロジェクト運営上もそれぞれが独立して行動することとなる。そのため、おのおののスキル(特にサービスの組成者のスキル)は専門特化され、同じ役割を持つ者同士による頻繁なコミュニケーションが知識を集積させる。
さらには、1人が並行して運営できるプロジェクトの数は多くなり、集積された知識をより効率的に活用できるだけでなく、プロジェクト自体のコストも低減する。サービスの組成者は利用者・提供者と積極的にコミュニケーションを図り、サービス群が全体最適となるように調整していく。結果として、このコラボレーションはサービスの再利用を促進し、IT投資の経済性を向上させる。つまり、利用回転率が高くなることで、企業のIT全体はより小さく、筋肉質になっていく。サービスの再利用が進むことで、複数のアプリケーションに重複していた機能が段階的に削ぎ落とされていくのだ。
一方、サービスの提供者が作成する各サービスは種類や数が増えているため、柔軟なソーシング戦略が必要だ。提供元がレガシーアプリケーションの場合は、その中で完結してしまっている機能をサービスとして提供可能にする製品を各ベンダーが提供していることに加えて、サービスの提供元をオフショア開発で実現することが有効となるだろう。IT投資を抑制するためにオフショアを検討しつつもなかなか踏み切れない企業は、まずは1つのサービス提供元としてオフショア開発を始めれば、リスクを最小化しつつコストを抑制できると思われる。
SOAは企業全体を見据えたコンセプトである。あくまで全体を構築するための「サービス=部品」化であり、階層構造化である。当初は一部門の取り組みから始めるだろうが、企業全体への展開を視野に入れていなければその効果は出にくい。また、変化に乏しく、それへの適応があまり必要なく、単一の業務部門内でオペレーションやシステムが完結する場合や、部門ごとの情報共有やコラボレーションがそれほど求められない企業には有効ではないだろう。その場合は、特定業務に特化したサイロ型構造の方がかえってシンプルである。
SOAが適しているのはこの裏返しである。つまり、短期間で新しいサービスを次々提供していくような競争の激しい業界や、事業部制を敷き、各事業部単位で顧客との接点が存在するような企業に適しているといえる。例えば携帯電話業界を思い浮かべると分かりやすいが、新サービスのスタートはほかの業界と比べると明らかに早い。次々と新しいサービスを顧客に提供し、それらすべてを共存させていかなければならない。サービスは新旧かかわらず不具合が出れば顧客の満足度は下がる。それを支えるITの設計手法はSOAが適している。
IT基盤には、より機動性と柔軟性が求められている。SOAは階層型構造によりIT部門が担う仕事をより専門特化し、業務部門による主体的な参加を促し、自らが望むIT基盤の活用を実現する。業務部門が必要なビジネスサービスをいかに利用しやすくし、かつITコストを抑制するためには、サービスの組成者の役割が非常に重要だ。
サービスの組成者は柔軟なソーシング戦略を駆使し、企業の全体最適を視野に入れつつビジネスサービスを提供していくことにより、IT基盤はより経営や業務にとって高価値で経済的な存在となっていくだろう。
英国系通信社に入社後、マーケティング部所属、金融に関するマーケティング業務、事業開発の責任者を勤め、その後プロジェクトマネジャーや業務コンサルタントとしてシステム開発に取り組む。2004年より現職。SOA/BPMにおける事業企画、マーケティング、営業推進に従事。日本BPM協会運営幹事。SOA/BPM関連講演多数。経営学修士。