プログラムと言うものは、ロジックとフローで構成される。ロジックとはプログラム上で表現したいストーリーのことで、フローとはロジックの実行順序を意味する。
そして、業務アプリケーションにおいてロジックにあたる部分は所謂ビジネスロジックと言われる部分になる。で、この業務ロジックは何によって構成されるのかを考えた場合、それは業務ルールではないかと思う。
つまり、業務アプリケーションにおいては「業務ルールによって構成されるビジネスロジック」と「業務フローと同じシーケンスをもつロジックフロー」の２つの要素が複合的に絡み合って、アプリケーションが作られる。
で、SEの大敵である仕様変更というのは、多くの場合業務ルールの変更を意味する。
アレが足りない、これが足りない、判断条件が違う、検索条件が違う、あーたらこーたら。これらはフローの変更ではなくルールの変更だ。で、ルールが変われば当然ビジネスロジックが持つフローも変更を余儀なくされる。仕様変更がなぜ困るかと言えば、ルール変更によりルールもフローも変わってしまい、様々な箇所の修正・作り直し等を余儀なくされてしまうからだ。
つまり、業務アプリーケーションの設計に当たっては、「ビジネスルール＋それに付随するミクロなフロー」と「業務全体を捕らえたマクロなビジネスフロー」を何らかの適切な単位で分離するようなアプローチが求められる。
この辺りをソフトウェア的にカバーしようとするとオブジェクト指向の出番になるし、最近の流行では業務のアクティビティ（ルール＋フロー）とマクロのフローを分離するというBPMSの考え方がマッチする。
この考え方は整然としていてキレイな絵がかける部分だが、当然問題になるのがどういったプロセスをデプロイするのか、ということ。
ここについては多分喧々諤々の議論が必要になると思うが、BPMSにデプロイするフローは「粗すぎず細かすぎず」というセクシーなバランスが求められることは間違いないだろう。
細かすぎる作業単位のミクロなフローだとデプロイできないし、ざっくりとしすぎた業務単位だと細かいフローの制御条件を渡せないだろう。デプロイするアクティビティは、unit of taskになることは個人的に間違いないと思っているし、どこまでの業務がシステム化できるか、つまり自動化できるかを考えなくてはならない。同時に、階層化も重要になってくる。
最近はそんなことを考えてます。
