コンポーネントの粒度
ここまででは、コンポーネントとして、業務サービスという言い方をした小さな単位の業務プロセス、例えば「受注」というようなものもコンポーネントとみなすと、こうした大きな括りの業務サービスコンポーネントがあって、その下に「受注受付」のようなアクティビティあるいはタスク主体の業務コンポーネントがあり、それを動かす共通基盤的な仕組みとしてのシステム機能コンポーネントがあると言ってきた。それでは、それぞれのコンポーネントの粒度をどう考えていったらよいのでしょう。
システム機能コンポーネントについては比較的考えやすいと思うので、ここでは、業務コンポーネントについて考えてみる。
まず、抽象的な言い方だと、ビジネスの環境や組織が変わっても、それ自体変わらない部分をコンポーネントの単位とすることなのだが、例えば、会計処理なんかはそのプロセスはそう大きくは変わらない（法改正、制度変更はあるが）から、業務パッケージそのものがコンポーネントと言えないこともない。こんな場合は、それをひとつのサービスとして括ってもかまわない。
最近Webサービスという形でネット上にもこうしたサービスが登場してきている。有名なSalesforce.comのオンデマンドサービスはまさにまるごと外部のサービスとして利用できる。だから、他社と差別化する必要のない機能は、できるだけ個別企業ごとに作るのではなく、外部のサービス利用という形態が望ましい。
こういうことができるようになったとというのがSOAのもたらした効果なのだ。企業は、システムを“作る”、“買う”（パッケージを買うという意味）、“借りる”のバランスをうまくとりながら構造化を図ることが大事である。
さて、もう少し具体的に見ていくと、一番問題となるのは業務コンポーネントの粒度をどうするかだ。この中には、単なるワンアクションのようなものから、ワークフローを含んだ処理までが想定されると考えられる。「生産量登録」みたいなものから「見積依頼」というようなワークフロー的なコンポーネントのことである。
例えばこの「見積依頼」という業務処理を考えてみよう。工事の見積を行なうと仮定するとこの処理は、「仕様書作成」→「仕様書承認」→「見積依頼書作成」→「見積依頼受付」→「見積依頼」のように流れる。このとき、「仕様書作成」のレベルを一つの業務コンポーネントとして、それらをBPMでつないでプロセスを作っていくというのもありですが、少し細かすぎるような感じがする。
そこで、BPMとWorkFlowについてだが、厳密な定義があるのかないのか知らないが、似ているように思うし、一緒のように言う人もいる。よくわからないというのが正直なところで別にそんなことを考えなくてもいいと思う。むしろ、WorkFlowって一体なんなのだろうかと見るほうが大切で、仕事というのは、ひとからひとへシークェンシャルに流れていくものであるという前提でWorkFlowという概念が成り立っている。
確かに、稟議決済なんて仕事が流れていく典型であるけど、大部分はその前提を崩して考えてもいいような気がする。すなわち仕事が流れるのではなく、“状態が遷移する”と考えるべきだということです。だから、ワークフローというのは、フロー制御とステータス制御の2通りあると捉える。
以前、.NETのフレームワーク上で動くコンポーネントを開発し、それを使ったアプリケーションを構築することを試行したことがあったが、そのとき業務というのは、書類をイメージした「データコンポーネント」が転記されて受け渡されることだと規定したことがあるが、これと似ている。
また最近、こうしたことを気づかせてくれたのは、あるCMSツールです。それは、Ploneといって、オープンソースのアプリケーションサーバーであるZopeとそのフレームワーク上に構築されたコンテンツ管理システムなのですが、そのなかにワークフローの機能があるというのです。で、よく見てみると、“オブジェクトの状態とユーザロール”を中心に構築されているのです。簡単に言えば、共通の場で情報を共有してそのステータスをコントロールすることで仕事ができると言っているのです。
このあたりはまた後述しますが、粒度の話に戻ると、ここにヒントがあって、ここで言うオブジェクト単位で粒度を設定すればいいのではないかということです。では、そのオブジェクトとは何だろう。筆者は上述したように、それは「書類」ではないかと考えている。すなわち、仕事の単位は、書類（必ずしも紙でなくてもいい）を作成してそれに追記・転記して完結するということではないかと考え、それをコンポーネントと捉えたらどうだろうか。このように考えてもいい業務処理はわりと多いと思われる。
従って、従来WorkFlowといっていた部分は、StatusControlとし、対象となるオブジェクトを書類（広義）とし、その単位でコンポーネント化する。コンポーネントは例えば、PloneのようなCMS（もちろん他のWebアプリケーションでかまいません）みたいなものでできて、それらのコンポーネントをBPMを使ってプロセスにしていくというのがざっとしたイメージになります。
ミクロなサブワークフローは軽量Webアプリで、マクロのメインワークフローはBPMという構成です。言ってみれば幹線道路はBPMで作るが支線や私道は軽量フレームワークでさくっと作ってしまい、ジャンクションは標準の取り決めに従ってつなぐという感じになりますがいかがでしょうか。全部がこれでできるとは思っていませんが、挑戦してみる価値はあるように思えます。