業務プロセスの設計をすると、プロセスと機能とデータ、それに加えてルールの関係が複雑に絡み合ってくるので混乱する。従来のような密結合でプログラム的に処理する分には、重複さえ注意すれば難しくはない。ただし、作るまではいいがその後のメンテナンス性を考えると恐ろしくなる。

いま、ここで「プロセス」「ルール」「機能」「データ」と言っているが。これがなかなか一筋縄ではいかない。簡単に使っているがちゃんと定義していない。その意味するところは、人それぞれで違うし、狭くとるか広くとるかでも大きく違ってくる。だから、きちんと定義し、構造化していかなくてはいけない。

そこでそのあたりを見ていこうと思うのだが、プロセスについてはさんざん議論をして、ここではアクティビティの粒度を定義し、それを階層化することで、2段ワークフローという概念を提示した。それによって、定型・非定型の切り分けや、コントロール＆オペレーション重視という考え方も採りやすくなり、ビジネスに貢献できる形になると期待している。

一方、「データ」についてもデータベースの設計というアプローチではなく、ビジネス視点の考え方がるべきだと思っているが、これは後にして、ここでは「ルール」について議論してみましょう。

ちょっとその前に、ルールの重要性を強く感じたのでそのことについて書く。業務システムの構造は、以前から「機能とプロセスとデータ」から成っていると言ってきたが、このうちの「機能」というのが若干分かりずらいと思うので、「アクション」と言い換えたほうがいいかもしれないのでそうした表現を使うことにする。

そうすると、業務は“データを使ってアクションを起こし、それをつなげてプロセスにして、そこで新たなデータを生成させる”ことと言える。ところで、この一連の動作をどのように制御しているのだろうか。何をもって進行させているのだろうか。

それが最近、「ルール」であると思うようになったのである。ただ、このルールという言葉も範囲が広いので注意が必要であるが、その中身については次回お話しすることにして、ここでは“決めごと”くらいの感じで言っています。

データもその意味することはある決めごとで定義しますよね。例えば、「在庫」の定義もちゃんとしないと会社によって違ったりします。また、アクションはそれを誘導するためのきっかけが必要です。どういう事象があったらどういうアクションを起こすという決めごとが要ります。プロセスは、その順番や分岐させるためのルールがあります。

こうしてみていくと、プロセス、アクション（機能）、データという要素（コンポーネント）を“ルール”によってコントロールしている司令塔のようなイメージがわいてきます。これが「オペレーション志向」ということでもあります。ルールマネジメントの大切さがここにあります。