業務コンポーネントの種類
これまで業務コンポーネントを書類のライフとみたてて議論を進めてきた。ほとんどの業務プロセスはこの書類のライフで組み立てられるが、それ以外の業務コンポーネントも定義しておかなくてはいけない。
業務コンポーネントの性格には大きく二つあると考えている。双務的なものと片務的なものである。すなわち、双務的というのは、BPMから依頼が来てそれを受け付けて、処理を行い、その結果をBPMに渡し、次の処理を依頼するというコンポーネントのことである。一方、片務的というのは、業務プロセスの端に位置するもので、その業務処理から、プロセスが始まるもの、例えばコールセンターみたいなところからクレームがくるとかいったものや業務プロセスが終わらせるアクション、例えば結果をレガシーシステムに登録するとか、掲示するとかいったものである。
さて、書類のライフ以外の双務的なものをみていくことにする。計算型というのは、代表的なものにEXCELで集計したり、縦横計算をさせた結果を戻したい場合などにこのコンポーネントを使う。EXCELを計算エンジンに使うというのは筆者の経験ではけっこうあり得る話であると思っている。ちょっと脇にそれるかもしれないが、縦横計算を駆使する原価計算のエンジンにはＥＸＣＥＬがパフォーマンスがいちばん出るし、最適ではないかと思うのである。
次に外部ルールをコンポーネントとしてみているが、簡単なルールについては、ＢＰＭに内臓するか、適正化機能で実現するのがよいが、「作業割付」、「例外処理」「差し戻し」などについては、外部化せざるを得ないだろう。本来はもっと上位概念的なビジネスルールを取り込まなくてはいけないのだろうが、これまでの議論の文脈から泥臭いところでいいのではないでしょうか。
でこのビジネスルールのことなのだが、最初はよく理解できなかった。ところが、それってデシジョンテーブルですよと言われたので少し調べたら、昔、もう２０年くらい前になるが、筆者が工場のプラント制御に関わっていたころにやっていたことと基本的には一緒のような気がした。例えば、発電所の選択遮断の仕組みって、ケースに応じて、系統を遮断するルールがデシジョンテーブルにセットしてあって、それに従って作動させるわけである。
さらに、例えば「ILOGJRules」というエンジンは人工知能ブームのときのAIエンジンから派生したというじゃありませんか。もう、人工知能だとかAIなんて言葉は聞きませんが、そのころははやったのです。かくいう筆者もエキスパートシステムと称して、プラントの異常検知のシステムをAIすなわちIf Then Elseの技術を使って開発したことがある。いくつかの事象をモニタリングしておいて、そこで異常が起きそうな予兆がでたらアラームを出すという仕掛けでした。何かこれはルールエンジンというよりBAMみたいな機能ですね。
少々脱線したのでもとに戻すと、書類ライフ以外の業務コンポーネントをあげてみましたが、今度はそれをどう作っていったらいいかということになると、書類ライフではオープンCMSの適用がフィットするとしたが、これだけがベストの選択肢ではない。
例えばさっき出てきた計算コンポーネントではEXCELがいいわけだし、コールセンターはそのための専用ソフトがしいし、単純なアクションだったら、それこそ「Tuigwaa（今はEscafeWebというそうだ）」でいけるだろう。ちょっとしたアプリケーションはＲｕｂｙ on Railsかもしれないし、コミュニティサイトはXoopsがいいとか、要は目的や要求機能にあったソフトウエア、フレームワークを選ぶことが大切になってくる。
なぜなら、できるだけ開発要素はなくし、最低限のカスタマイズで使うことが、開発生産性と保守性を向上させるからである。
