SOAとSaaSスイート、導入検討のポイント【SOA編】
業務部門とIT部門の協業を推進するSOAの考え方
ソフトウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携させてシステム全体を構築するSOA。そもそもSOAとは何なのか、その利点、どういった場合に導入が向いているのかを解説する。
企業がIT基盤に求めるものは
現在、企業のIT基盤に最も求められる要求とは何だろうか。それは、文字通り経営に役立ち、安く、そして早く提供される、いわば「業務に奉仕する基盤」である。そしてこれらがSOA（Service Oriented Architecture：サービス指向アーキテクチャ）に期待され、目指す目的である。
しかし、ITの世界でこれらの目的が掲げられることは決して新しいことではない。では、SOAというシステムアーキテクチャは従来と何が異なるのだろうか。それは、経営や業務に直接携わる人間が、自分の望むビジネスプロセスを自ら設計・定義し、ITから提供される「サービス」を直接定義していくという点である。
SOAとSaaSの「サービス」の違い
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）といった標準方式で呼び出せるように構築し、各機能を組み合わせてアプリケーションを構築しやすい環境を作っていく。
業務部門とIT部門との協業を促進する分業とは
SOAでは業務部門とIT部門の協業が円滑に進められるように、IT基盤を幾つかの階層に範囲化している。それは、下図のようなサービスの「利用」「提供」「組成（オーケストレーション）」「統治（ガバナンス）」という限定的な階層である。それぞれの階層に属する人をサービスの「利用者」「提供者」「組成者」「統治者」と呼ぶ。
SOAによる階層構造と各階層の役割
SOAでは、サービスの利用者（主に業務部門）はどのビジネスサービスを利用するかだけを考えていればいいし、サービスの提供者（IT部門）はサービスの利用者から求められるサービスをいかに効率よく提供できるかを考えていればいい。サービスの組成者（IT部門）はそうして社内にできていくサービス群をどう組み合わせて全体最適化するか、ということだけを考えていればいい。この階層構造は業務部門とIT部門の分業を円滑にする。
変化に強く、早く展開できるビジネスプロセス
業務担当者が自らビジネスプロセスを設計することで、新製品の導入や新制度への対応といった変化に対しても迅速に適応できる。SOAにおける階層構造は変化に対しておのおのの制約を極小化する効果もあり、「疎結合」と表現されるように、互いが影響し合う範囲は各階層内に限定される。サービスの利用者は自分が業務で必要とするビジネスサービスを定義し、サービスの提供者とのコミュニケーションを図る。サービスの組成者はサービスの提供者が提供するさまざまなサービスを組み合わせて全体最適を図る。範囲を限定することにより、機動的でスピード感のある開発が可能となるのだ。
プロジェクト横断的なコラボレーションによって全体最適を目指す
また、階層構造は従来のプロジェクト運営を変化させる。これまでのプロジェクトでは特定の業務領域を中心に組織化され、プロジェクトメンバーはその業務領域内で活動していた。一方、SOAの考えではプロジェクトが特定の業務領域であったとしても、各階層の範囲が限定的であるために、プロジェクト運営上もそれぞれが独立して行動することとなる。そのため、おのおののスキル（特にサービスの組成者のスキル）は専門特化され、同じ役割を持つ者同士による頻繁なコミュニケーションが知識を集積させる。
さらには、1人が並行して運営できるプロジェクトの数は多くなり、集積された知識をより効率的に活用できるだけでなく、プロジェクト自体のコストも低減する。サービスの組成者は利用者・提供者と積極的にコミュニケーションを図り、サービス群が全体最適となるように調整していく。結果として、このコラボレーションはサービスの再利用を促進し、IT投資の経済性を向上させる。つまり、利用回転率が高くなることで、企業のIT全体はより小さく、筋肉質になっていく。サービスの再利用が進むことで、複数のアプリケーションに重複していた機能が段階的に削ぎ落とされていくのだ。
サービスの提供には柔軟なソーシング戦略
一方、サービスの提供者が作成する各サービスは種類や数が増えているため、柔軟なソーシング戦略が必要だ。提供元がレガシーアプリケーションの場合は、その中で完結してしまっている機能をサービスとして提供可能にする製品を各ベンダーが提供していることに加えて、サービスの提供元をオフショア開発で実現することが有効となるだろう。IT投資を抑制するためにオフショアを検討しつつもなかなか踏み切れない企業は、まずは1つのサービス提供元としてオフショア開発を始めれば、リスクを最小化しつつコストを抑制できると思われる。
SOAが適しているケース：企業全体的な取り組みにはSOA
SOAは企業全体を見据えたコンセプトである。あくまで全体を構築するための「サービス＝部品」化であり、階層構造化である。当初は一部門の取り組みから始めるだろうが、企業全体への展開を視野に入れていなければその効果は出にくい。また、変化に乏しく、それへの適応があまり必要なく、単一の業務部門内でオペレーションやシステムが完結する場合や、部門ごとの情報共有やコラボレーションがそれほど求められない企業には有効ではないだろう。その場合は、特定業務に特化したサイロ型構造の方がかえってシンプルである。
SOAが適しているのはこの裏返しである。つまり、短期間で新しいサービスを次々提供していくような競争の激しい業界や、事業部制を敷き、各事業部単位で顧客との接点が存在するような企業に適しているといえる。例えば携帯電話業界を思い浮かべると分かりやすいが、新サービスのスタートはほかの業界と比べると明らかに早い。次々と新しいサービスを顧客に提供し、それらすべてを共存させていかなければならない。サービスは新旧かかわらず不具合が出れば顧客の満足度は下がる。それを支えるITの設計手法はSOAが適している。
機動性と柔軟性が求められるIT基盤。サービス組成者の役割が重要になる
IT基盤には、より機動性と柔軟性が求められている。SOAは階層型構造によりIT部門が担う仕事をより専門特化し、業務部門による主体的な参加を促し、自らが望むIT基盤の活用を実現する。業務部門が必要なビジネスサービスをいかに利用しやすくし、かつITコストを抑制するためには、サービスの組成者の役割が非常に重要だ。
サービスの組成者は柔軟なソーシング戦略を駆使し、企業の全体最適を視野に入れつつビジネスサービスを提供していくことにより、IT基盤はより経営や業務にとって高価値で経済的な存在となっていくだろう。
＜筆者紹介＞
織田新一
日本ティブコソフトウェア ソリューションコンサルティング部 部長
英国系通信社に入社後、マーケティング部所属、金融に関するマーケティング業務、事業開発の責任者を勤め、その後プロジェクトマネジャーや業務コンサルタントとしてシステム開発に取り組む。2004年より現職。SOA／BPMにおける事業企画、マーケティング、営業推進に従事。日本BPM協会運営幹事。SOA／BPM関連講演多数。経営学修士。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー