今回は、プロセス設計・I/O設計・データベース設計について考えてみましょう。要するに設計方法が従来と変わるのかどうかということです。技術的な詳細については語るスキルもないのでここではコンセプチャルな面から捉えていきます。

まず重要なのは、“画面・帳票設計から入るな”ということです。これはけっこう象徴的なことで、従来からやられているのは、画面・帳票設計や業務フロー、データフロー設計といった外部設計があり、そしてプログラム仕様を作る内部設計といったやりかたです。（この外部と内部の設計という考え方がよく分からないのだが）

プロセス志向はあくまでプロセス中心でみていくわけで、プロセスありきから入っていきます。ですから、I/Oもプロセスが機能するためにどうあるべきかが問われてきます。データを登録するためにどんな画面が必要かという見方ではないのです。

もちろん、プロセスを回すためには、データを入力することがトリガーにはなるのですが、あくまで主体はプロセスで画面や帳票の存在意義は相対的に低くなってきます。

プロセスを回すためには、そのプロセスの構成要素であるアクティビティ（あるいはタスク）での処理の仕方がやりやすい、あるいは早くできるなどを重視した設計になるわけです。そうなると、従来型の画面では限界があるのがわかると思います。より自然な仕事のやりかたに近づけたいのです。

今はここのところがWebで実現できるようになったおかげで、単にデータを登録する画面ではなく、個人あるいはグループでコミュニケーションをとりながら処理（意思決定）を行なうことができる場が提供されるようになったのです。こうしたやり方は通常の仕事の進め方なわけで、ITがあろうとなかろうと行なわれていたことです。

昔はだれかの机のまわりに集まってワイワイガヤガヤやりながら、場合によっては電話やFAXを使って仕事をしていたわけです。今は電子メールが大きなウエイトを占めるようになり、隣に座っているひとともメールで会話するなんてことにもなっています。

このような仕事のやり方をネット上の共有的な空間でやれば、遠くの人も参加できるし、仕事がどう進んでいるかが見えるようになります。そうした時の画面と帳票はどうあるべきでしょうか。

まずは情報伝達のためだけの帳票は不要になると思いませんか。それと、少なくとも一人で画面に向かって作業して、それが終わったのでメールしてあるいは紙を流して承認を依頼するようなことは自然ではないように思えるのですがいかがでしょうか。

さて、次にデータベースの設計ですが、この領域でもプロセス志向だと変わるように思います。それを考えるときに、「データ志向」との対比の中でみるとわかりやすいかもしれません。

DOA（Data Oriented Approach）の場合のデータベース設計は、まずは画面や帳票からデータを抽出します。大ざっぱに言うとそこからリソース系のデータとイベント系のデータに分け、それぞれにリレーションをはり、ER図を書くということを行ないます。

ただ、これだと既存のシステムがベースですから、基本的にIT化の範囲で設計するということになり、非システム化領域をどうするのかという課題が残ります。また、イベントデータを時系列で並べるとプロセスになるかもしれませんが、やはりそれではフロー図になれた人にとってはわかりずらさは残ります。

ですから、今言ったようにデータ志向はどうしても画面・帳票主体になってしまい、プロセスの意識が薄いままであり、ビジネスの実相がつかみずらくなります。そういったことでプロセス志向のほうがユーザにとってわかりやすいものになっているのだと思います。

さて、そのプロセス志向におけるデータベース設計はどうなるのでしょうか。プロセスの目的と構造を考えてみましょう。そもそもそのプロセスが存在するのは何のためでしょうか。そのプロセスで処理した結果をビジネスの成果として蓄積することです。その成果はほとんどの場合「データ」として格納されます。

データには、イベントデータとリソースデータの２種類がありますが、まさしくイベントデータはこうして生成されます。リソースデータ（マスタデータ）の生成も、同じようにプロセスを経ることには変わりありませんが、それはデータ管理のためのプロセスです。

ですから、設計という観点から言うと、マスタは、プロセスとは離して、独自に設計した方が言いように思います。マスタというのはその会社の活動のもととなるリソースですから、もちろん様々なプロセスにも使われるし、戦略的な意味も込められる。それは、最初にきちんと分析して設計しておくことが大事であると考えています。

話はイベントデータに戻ると、プロセス志向だとデータをプロセスごとにもつのかという問題が出てきます。それだと、データの重複や管理の煩雑さがおこると言われそうです。

しかし、重要なのは、“プロセスの正規化”をきちんと行なうということで、重複するプロセス、似て非なるプロセス、標準化されないプロセスなどを排除することなのです。そうすれば、分散してデータをもってもかまわないし、必要に応じて仮想化で統合すればいいのです。こうした考え方に依拠したデータベース設計方法論が望まれるのだが、これをだれか作ってくれないだろうか。