前回、コントロールという概念とそれを実行するコントローラーということを提示しました。さて、お気づきかもしれませんが、コントローラーと聞くとMVCモデルのCであるControllerを思い浮かぶ人がいるかもしれません。そこで、MVCモデルの業務プロセス適用を検討してみます。

ご存知のように、MVCモデルというのはソフトウエアの設計において、Model、View、Controllerという３つの要素から構成されるモデルのことである。Modelというのは処理のためのロジックやデータで、Viewは画面表示をする。そのModelとViewを制御するのがControllerである。

リクエストがくるとそれをControllerが受け取り、Modelに処理要求、Viewに表示要求を出します。Modelでは処理とデータベースの更新を行い、そのデータをViewが参照して表示するという動きになります。

これらの機能が別々に独立的に分離されていることが重要なのですが、このモデルを業務プロセスモデルに当てはめてみましょう。まずは、マクロフローの部分をみていきます。マクロフローというのは、依頼－依頼受付－単位意思決定－作業－報告・登録という動きになっています。

この場合、Viewの部分がどうなっているのかということがあります。別に画面でなくてもいいのですが、業務システムと考えると最近はWebブラウザというふうにみてよいと思います。ですから、依頼を受付けるWebページがViewになります。受付けるかどうか、あるいは受付けるとなったら、それを次の意思決定アクティビティに渡すのと、どういうふうに依頼に対する回答を用意したらいいのかを決めます。これはControllerの役目になります。そこで決められたロジックで処理され、データを確定します。まさにModelとなります。そして、ここで確定されたデータや作業結果をWebで表示します。

こうしてみるとシステムの基本的な構成がマクロレベルの抽象度でもMVCで表現できるのです。では、ミクロレベルではどうでしょうか。ミクロフローというのは、単位意思決定アクティビティのデータ確定処理です。

ここでのリクエストは単位意思決定アクティビティにこういうデータを確定してくれというふうに来ます。それを受けるViewは、マクロでは顧客との接点ですが、この場合は内部で処理するための画面です。そのリクエストをControllerがバリデーションやフィルタリングなどを行い、意思決定のためのWork Spaceに処理要求を出します。ここは誰がどんな情報を参照してデータ確定するのかというロジックとデータをもったModelになります。その処理結果が終わるとViewであるアクティビティの完了表示となります。

さらに、その下位レベルである参照情報の取得も同様にMVCで考えることができます。ただ、あまり厳密なものとせずに構成要素的に似たようなものだという解釈でいいと思います。こうしてみると、業務プロセス自体もMVCモデルのように記述できるわけで、そうしたほうが一貫性をもって、実装に落とせるような気がしています。

ただ、Controllerの役割と機能はアルゴリズム的な要素もあったりして難しいのですが、ここをうまく整理できると非常にわかりやすいシステム構造になり、ということは簡単に作れるし、何よりもビジネスモデルを埋め込みやすくなると思うのです。