REAとビジネスパターン入門(2)

2007.09.06

　前回から，「REA（Resource，Event，Agent）による新しいモデリング手法」について説明している。REAを使うことで，得られる効果は以下の三つである。

(1)モデルがわかりやすくなる
(2)モデルが作りやすくなる
(3)モデルを立体的に評価できるようになる

　今回は，(2)と(3)について説明しよう。

(2)モデルがつくりやすくなる

　REAでは，前回説明したように数多くのパターンが用意されている。特に，REAそのものである業務レベルの構造パターンは，交換そして変換（生産・分解）という，ビジネスの世界に密接に結びついたプロセスのパターンから構成されている。そのため，業務レベルの構造パターンを適用するためには，まず問題領域のREAに着目すればよい。つまり，その分野のリソース，イベント，エージェントに着目すればよいのだ。

　REAでは，モデリングのためのルールがしっかり決まっているため，モデルにエンティティを配置するときは，そのルールを厳密に守らなければならない。勝手に配置するわけにはいかないのだ。モデリングのルールについては，第3回以降の主要なテーマとして取り上げる予定だ。

　イベントを配置するには，それが増加イベントか，減少イベントかを決定しなければならない。そのためには，それがどのようなリソースを生み出すのか，または，失うのかを考えることになる。さらに，リソースを配置するためには，それを「供給する」エージェントと「受領する」エージェントを見極めなければならない。

　ルールが決められているということは，面倒でもある。しかし，パターンごとの手続きに則ってモデリングを進めることができるので，作業がリズミカルになるし，作業に先立って段取りを考えることもできるようになる。例えば，ユーザー企業を訪問して調査を行う場合でも，到着してから「さてどうしよう」ということがなくなる。ユーザーとのやり取りも引き締まり，モデラー側はプロとして見てもらえるようになる。

　従来型のモデリングならば，ユースケースなどをもとに，名詞に着目しながらエンティティを見つけて配置するというやり方になるだろう。そのようなやり方でできるモデルの品質は，モデリングする人の力量に大きく依存することになる。それに比べて，習熟にある程度の時間を必要であるとはいえ，REAのような，ルールに基づくモデリングは，属人性の少ない，一定の品質が確保されたモデリングを可能にする。

　ユーザーは，必ずしも自分のビジネスについてすべてを知っているとは限らないし，知っていることのすべてを語ってくれるとは限らない。そもそも知っていることのどの部分を語れば良いかがわからないのだ。したがって，「聞いていないのでモデル化しませんでした」などと安易に口にするとモデラーとしての信用を失いかねない。聞くべきことは，聞く側があらかじめ知らなければならない。REAの真の価値は，この「聞くべきこと」をルールの形で提供していることだ。

(3)モデルを立体的に評価できるようになる

　REAを使うことで，アプリケーション・モデルをバリューチェーンという視点から評価し，検証できるようになる。前述の(1)(2)とは違い，これはREA流のモデリングを実践しなくても得られる効果である。

　例えば，筆者は，受注出荷系システムの仕事では，図5の上部に示したようなクラス図（概念モデル）を書くことがある。これまでモデリングの仕事に従事してきた者として，このモデルが多くの場合に適用できると考えている。このまま使えないこともあるが，たいていのケースでは，このモデルを修正することで必要なモデルを得ることができる。しかし，なぜこれで良いと言えるのかと問われると，なかなか説明が難しい。もちろん，見積書や請求書のモデル化として説明することは可能なのだが，このモデル化による限界などはきちんとした話にならないのだ。

図5●受注出荷システムのモデル
[画像のクリックで拡大表示]

　図5の受注出荷システムのモデルは，筆者のオリジナルでもなんでもない。熟練したモデラーなら，誰でも似たような構造を描くものだ。これも筆者が監訳者の一人となっている書籍の話だが，ピーター・コード他が，『戦略とパターンによるビジネスオブジェクトモデリング』（ピアソン・エデュケーション発行）を著しており，その中でPOS（販売時点情報管理システム）に登場するオブジェクトのパターンを数多く紹介している（筆者のサイトでは，ピーター・コード氏の許可のもとにそれらのパターンをそのまま掲載している）。

　図5にそれらのパターンから関係するものを二つ示した。「トランザクション－トランザクション明細」パターンと，「品目－明細」パターンの二つである。

　図5の全体をご覧いただくと，筆者の定石モデル（上部）やピーター・コードのパターン（下部）が，互いに関係していることがわかる。再利用性の高いモデルとは経験的にはどのようなものであるか，ある程度わかっているということだ。しかし，ピーター・コードといえども，なぜ彼のパターンが反復して利用できるのか，その限界は何なのかについての説明はしてはいないように思う。

　一方，REAを使えば，図5のモデルの正当性や限界を，バリューチェーンという視点からではあるが，評価することができる。前回説明した図2のモデル，つまり交換プロセス・パターンに基づいて作成した銀寿司のアプリケーション・モデル（交換プロセス・モデル）に，図5のモデルをマッピングしたものを図6に示した。

図6●REAモデルの例(2)
[画像のクリックで拡大表示]

　図6の中で，赤く示された部分が，図5のクラスのマッピングである。この図から，以下のようなことがわかる。

図5上部の受注出荷システムのモデルは，前回の図2（交換プロセス・モデル）の右半分に対応していて，左半分には対応していない。つまり，現金というリソースの扱いをモデル化していない。受注出荷システムの構築を計画する場合，請求や入金といった販売管理業務に関しては，別立てのシステムや会計システムが既存システムとしてすでに存在し，その再構築までを視野に入れる必要がないという場合も多い。しかし，いつでもそうなのか。販売管理と受注出荷は，例えば，与信に関して密に連携する必要はないのだろうか。
受注出荷システムには，明細として注文明細しかない。一方で，交換プロセス・モデルには，減少コミットメントとしての販売明細と，減少イベントとしての販売（明細）という二つの明細が存在する。この受注出荷システムと交換プロセス・モデルの差異は，どう説明すれば良いのか。これまで説明しなかったが，交換プロセス・モデルにある，契約や，コミットメントは，方針レベルのパターンに登場するエンティティの種別であり，未来の決まり事や約束を表す。つまり，減少コミットメントである販売明細は，銀寿司と顧客が交わした「現金と引き替えににぎり寿司を渡す」という契約を表している。これに対して，減少イベントである販売（明細）のほうは，とにかくにぎり寿司を銀寿司が顧客に引き渡したという事実を格納する場所なのである。したがって，知るべきは，「引き渡しを約束したにぎり寿司を何回かに分けて届ける（分納する）可能性があるか，そして，そのことを管理する必要があるか」とか，「何回かに分けて受けた注文をまとめて引き渡す可能性があるか，またそのことを管理する必要があるか」ということである。
受注出荷システムにおいて，顧客は注文とだけ関連している。しかし，交換プロセス・モデルでは，販売注文と，さらに，減少イベントである販売の二つのエンティティが顧客と関連している。この差異はどこから来るのか。交換プロセス・モデルでは，減少イベントである販売が顧客と関連している。なぜなら，業務レベルのモデリング・ルールでは，にぎり寿司を「流出」させる販売イベントは，必ずその供給エージェントと受領エージェントに関連しなくてはならないからである。もし，「契約」つまり注文に基づくことなく寿司を届けて販売すること，例えば，オフィス街でしばしば見られる出入りのお弁当屋のようなことをする可能性があり，そのときの販売もアプリケーションで管理する必要があるなら，交換プロセス・モデルの通り，販売は顧客と直接の関連を維持するべきだろう。

　受注出荷システムと交換プロセス・モデルをマッピングした図6を見るだけで，上述のような，差異の発見，気づき，要件分析上の注意点などが洗い出されてくる。そう考えると，REAの考え方は，モデリングの熟練者にも役立つものだと思う。仮に熟練者には必要ないものであっても，その熟練者のモデルの品質やモデル化対象範囲を確認するためには大いに役立つのではないだろうか。まして，モデリングの初心者には多くの学ぶべきものがあるだろう。