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
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド：効果的な意思決定を実現する秘訣とは？ -
製品資料
[株式会社リンプレス] 非デジタル／IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計：「判断と責任」を人に残すための2つの原則とは？ -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
2
ソフトウェア開発生産性向上に取り組む企業は4割 調査で学ぶ「停滞」の正体
-
3
クラウド資格コレクターは評価されない？ 年収1000万を分ける“OSの理解度”
-
4
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
5
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
6
高額な「AI PC」を一般従業員も使えたら？ 費用のハードルを一気に下げる方法
-
7
「コピペ運用の限界」に直面するAI活用 7割超が“別画面”のまま使う理由は？
-
8
「AIバブル」は崩壊するのか？ 熱狂の後に来る“尻拭い”と4つの防衛策
-
9
LLMの「過学習」、正しく説明している文章はどれ？
-
10
IT調達担当者が知るべき「IT機器 大インフレ時代の前向きな選択肢」
ホワイトペーパーランキング PR
-
1
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
3
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
4
DX／AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
5
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
6
生成AIで文書活用を進めるには？ 効率化と安全性をどう両立する
-
7
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには？
-
8
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは？
-
9
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
10
NTTドコモが実践したクラウド統合監視 業務量2倍でも残業削減を実現できた理由
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー