設計というと手順とかメソッドとかいった言い方の方が一般的であると思いますが、それだと何となく論理的なにおいがしないでもなく、ソフトウエア工学ですねみたいになります。しかし、よく考えてみると業務システム開発って工学的でしょうか？
少なくも、業務モデルは工学的モデルではないように思います。なぜでしょうか。それは人間が介在するものだからです。すなわち、恣意的であり、揺れたり、属人的であったりするのです。
とはいえ、全くカオスにできているわけでもない。厳密ではないにしても何らかの約束事はあるように思えます。別な言い方をすると、約束事ができるようなところとそうはできないところを分離して考えられそうだということです。
この考えが生まれた背景を少しお話しますが、ぼくは元々ケミカルエンジニアで化学プラントのオペレーションやプロセスエンジニアリングをやっていました。そのときの経験や考え方をときどきビジネスシステムにも重ね合わせて見ることがあります。そうですよね、同じプロセスという言葉を使っています。
それで、違いは何かということを考えたとき、真っ先に浮かぶのは、ビジネスプロセスにはオペレーションとかコントロールという概念が乏しいよねということなのです。それは、なぜかというと、どうもプロセスに人間が入っているかいないかの違いではないかと思ったのです。
ということは、人間が入ってくると、オペレーションやコントロールが難しいということを意味します。化学プロセスでは少なくともプロセスフローには人間が登場しません。人間が登場するのは、オペレーターとして、プロセスのオペレーションとコントロールを行います。ここが大きく違うように思えます。
そうであれば、そうしたことができるような構造にするには人間系をはずしてみたらいいのではないかと考えたわけです。
そして、ただはずしただけではいけないのでそれらはCMS（Contents Management System）に預けたわけです。ということでBPMSで扱うコンポーネント（アクティビティ）を書類という“箱”にして、ある程度約束ごとをもったものを登場させたというわけです。
化学プロセスも単位操作（加熱、冷却、圧縮等の処理）の連なりであり、それらが非人間系なので法則性があり論理的なプロセスが形成できる。ですから、書類を作成して発行するというのを化学プロセスの単位操作と同じようにハンドリングすればいいのです。しかも、組織というこれまた非論理的な要素もこれで排除できます。これはスイムレーンの問題なのであとで詳述していきます。
さて、おわかりになってでしょうか。ある切り出し方をすれば化学プロセスのように、あるいはエンジニアリング的にやれるのです。
そして、残った部分は人間系であり、恣意的な要素になりますが、これらは思い切って人間くさい“ゆるい”場所（情報共有の場）にもっていってしまうのです。こうした構造化がこの技法のポイントのひとつです。
一方、開発サイドからみると、上述のように工学的な問題に近づけたとしても、まだあいまいさは残り、そうしたモデルでも作るときはみなばらばらになっても困るわけで、それなりの集団としての秩序が維持されなくてはいけません。
そうした場合、これはいったい何をもってその秩序とやらを、また約束事を担保できるかと考えると、それは“お作法でしょ”ということになります。作法は「型である」と言えます。ですから、基本的な型を決めておくということになります。
よくある開発方法論などは、どうしても工学的なアプローチやプログラミング的なアプローチであり、ビジネスの観点からすると、すごくなじみがなくわかりずらい面があったように思います。「作法」というと、それほど確固としたものではなく、だいたいこんな風にしたらいいぐらいの感じで決めていけばいい。ただし、芯ははずさないようにすることが大事です。
ですから、作法に則ってやっていけば、誰でもほぼ同じような業務プロセスができてくるのです。ここが非常に重要なポイントになります。
こうして作られたものは、ある意味狭い範囲ではあるかもしれませんが、標準化されたものであるといえます。そうすれば再利用性が高まることは言うまでもありません。
作法は型なのでそれを表現するための様式も用意する。基本は書類に相当する“シート”ですが、そのほかにも“カード”、“サポートシート”があり、それらを綴じると“ブック”になり、これは業務プロセステンプレートになります。これらの“ブック”を集めたものが“ライブラリー”となります。それぞれの概要はつぎのとおりです。
こうした作法に即した体系で自分たちの業務プロセスをドキュメントとして残しておき、ビジネス環境の変化に迅速に対応していけるようにしていくことが重要となってきます。
さて、次回は前提となる考え方について書くことにします。