前回は、SOAによる情報システム構築の一般的な流れについて説明しました。今回はその中でも特に重要なポイントとなる、システム設計時におけるサービスの抽出とそれに従ったシステムの階層化について解説します。

サービス抽出の考え方

サービスの抽出とは、サービスが提供する機能の洗い出しと、サービスの粒度（提供機能が及ぼす範囲）を決定することを言います。SOAシステム構築手法では、以下のようにサービスの粒度を設計の各工程で段階的に設計する点が特徴といえます。

要件定義：

サービスの初期抽出を行い、サービスの候補として位置づけます。

ビジネスプロセス設計：

ビジネスプロセスの階層化により、サービス粒度の見直しを行います。

サービスI/F設計：

サービスの粒度の決定とサービス I/Fの定義を行います。

たとえば図1で示すように、要件定義工程の段階では、作成した業務フローに基づき業務フローを構成する各業務をサービスの候補として位置づけます。これはあくまで候補であって、以降の工程においてより適切な粒度になるように見直しを行います。

サービス粒度の見直しは、主に業務の実施方法のバリエーションごとに、サービスを区分するかどうかを判断することで実施します。図2にサービス粒度の見直しの例を示します。「⁠発注」業務をさらにビジネスプロセスで表現して階層化することで、業務のバリエーションが洗い出されます。ここでは発注業務のバリエーションとして、計画発注業務、計画外発注業務というバリエーションが抽出されています。これらの業務のバリエーションに対応した粒度でのサービスは、業務の変化を局所化する単位としてより適切な場合があり、この粒度をサービスとするかどうかを決定します。

要件定義工程の段階で抽出したサービス候補をそのままサービスとして用いる場合もあります。要件定義工程で作成する業務フローにおける業務は、多くが「サブシステム」に対応するものであり、変化を局所化することを考えると、この単位をサービスとするのが適当な情報システムもあるからです。ここで、サブシステムとは、データベースを共有するアプリケーションの集合で構成されるシステムのことを言います。

サービスの粒度の選定に関する考え方を図3に示します。業務機能の階層構造では、上位の階層は変化が少なく、他から独立している基本的な業務を示し、下位の階層になるほど変化が多く、他との依存関係が複雑になる傾向を示します。

サービスの適切な粒度は、図3では中位階層の業務に対応したものです。これは、業務の変化が発生する単位に近く、サービスの独立性が高い粒度です。業務の変化に対するプログラムの変更をサービスという実装単位に局所化できます。これにより、当該業務と対応したサービスを組み替えることで、システム変更を行うことが可能となります。サービスの組み換えとは、サービスを新たな実装のサービスと入れ替えることです。なお、この中位階層のサービス粒度として、図3に示したように、前述した業務のバリエーションに対応したものが考えられます。

これに対して、最上位の階層で示すサービス粒度では、業務の変化に対して実装の単位が大きすぎる場合があります。プログラムの変更はサービス内に閉じ込められはしますが、本来は入れ替えなくてよい部分まで入れ替える必要があるため、開発や運用のコストがより大きくなってしまいます。ただし業務によっては、変化を局所化する実装単位として、この最上位の粒度が適切な場合もあり、前述したようにビジネスプロセス階層化の中での設計が必要です。また既存システムのオープン化やパッケージ製品の導入といったシステム計画レベルの変化に対しては、この最上位の粒度のサービスを組み替えの単位とするのが適切と考えられます。

最下位の階層のサービス粒度では、業務の変化に対して実装の単位が小さすぎます。サービス間の依存関係が強く、プログラムの変更が複数のサービスに跨ってしまい、システム変更が1つのサービスに局所化されないことになります。

ビジネスプロセスの階層化とサービスI/Fの設計

前節で述べたサービス抽出の考え方を踏まえ、要件定義工程からビジネスプロセス設計、サービスI/F設計に至る流れを説明します。

要件定義工程では、システム化計画に基づき、機能要件の洗い出しと新業務フローを設計します。業務フローでは業務に関わる組織・担当者ごとに、業務の流れと授受される情報を定義していきます。業務フローの記法としては、一般に経済産業省がEA（エンタープライズアーキテクチャ）策定向けに提案しているWFA（Work-Flow Architecture）があります。

基本設計工程におけるビジネスプロセス設計では、新業務フローをBPMN(Business Process Modeling Notation)記法に変換後、BPMN図による階層化を行います。新業務フローと同等のBPMN図を基本フローとし、アクティビティごとにその業務の流れをさらにBPMN図で記載します。階層化にあたっては、業務の実施方法のバリエーションを考慮して、下位のビジネスプロセスにおけるアクティビティを設計します。

たとえば図4で示すビジネスプロセスでは、発注アクティビティを一段階階層化する様子を示しています。発注業務に内在するバリエーションである計画発注処理と、計画外の発注処理についてのフローを設計し、ビジネスプロセスを階層化します。 このようなビジネスプロセスの階層化において、前節で述べたようなサービス抽出を実施することにより、適切な粒度のサービスを決定します。

図4の下部は、図4の上半分で階層化したビジネスプロセスに対応したサービスの例を示しています。要件定義工程では、「⁠発注」という業務全体をサービス候補としていましたが、この段階でサービスの粒度を見直し、階層化された下位のビジネスプロセスを構成する業務の「計画外発注処理」「⁠計画発注処理」等をサービス候補として定めています。

さらにビジネスプロセス設計では、最下層のビジネスプロセスに記載しているアクティビティについてユースケースシナリオを作成します。ユースケースシナリオは、アクティビティごとの業務処理詳細を処理の順序に沿って文章で記載した成果物です。ユースケースシナリオでは、人が行う作業とそれに関連したシステム側の機能を明確にします。このユースケースシナリオは、アクティビティを実現するサービスの実現形態の決定やサービスを実現するアプリケーションの設計を行う際に活用します。

基本設計工程のサービスI/F設計では、階層化されたビジネスプロセスを元に、メッセージの構造や例外などを明確化し、サービスI/Fの仕様を設計します。なお、分岐条件の詳細仕様等のBPMN 図で表現できない仕様については、BPMN図とは別に作成します。またビジネスプロセス設計で仮決定していたサービスを決定し、サービスI/Fが所属するサービスを確定します。

次回は、これまで説明してきたことをふまえ、今度はフロントシステムの設計の方法と、実際のバックシステムとの連携が効果的な例を紹介します。