分析やビジネスモデリングのためのソフトウエアパターン

2009年5月27日(水)
羽生田 栄一

アナリシスパターンは漢方薬!?

 連載3回目の今回は、分析やビジネスのモデリングのためのパターンについて紹介したいと思います。M.ファウラーのアナリシスパターン、エリクソン・ペンカーらのビジネスモデリングパターン、そして最近注目されているPavel Hruby(パベル・フルービー)のREAビジネスパターンについてそのエッセンスをお伝えします。

 分析というものは、業務領域(ビジネスドメイン)を理解してシステム化のために必要な業務の概念構造を抽出する作業ですが、それを支援するためにアナリシスパターンが提案されています。

 ただし特定の業務分野ごとに整理してあるわけではなく、「組織構造と責任関係」「観測と測定」「コード体系・勘定と会計」「計画と実績」「取引とポートフォリオ」「派生商品」といった、ビジネスにおいて一般的なものごとのとらえ方をパターンとして抽出した形になっています。またGoFのデザインパターンのように、パターン名・状況・問題・解決策・結果といった定型的なフォーマットでカタログ化されているわけではなく、関連するパターンの説明がエッセー風にまとめられているので、問題にぶつかったときに調べてすぐに適用するというタイプのパターンにはなっていません。

 どちらかと言うと、このパターンを理解しようと苦労した人に対してじわじわと漢方薬風に効いてくるものです。

 またパターンの説明と並行して、ところどころに“モデリングの原則”が織り込まれていて、業務をモデル化する際の心得を学ぶことができますし、「最も頻繁に起こるモデルの変更が、最少のクラスの変更で済むようにモデル構造を作れ」「モデルを操作レベル(通常のオブジェクトの登場する世界)と知識レベル(いわゆるメタモデル)に階層化して管理せよ」……など、拾い読みするだけでも参考になります。

 ただ設計レベルの原則も混在しており記述が体系的ではなく、中には「開閉原則」や「Liskovの置換原則」と似た指摘も混在しているので、R.マーチンの設計原則と合わせて再整理するとよいでしょう。

アナリシスパターンの例

 ここでは、階層的な組織構造を組織変更にも柔軟に対応できるようにモデル化するためのアナリシスパターンとして「責任関係(Accountability)パターン」を取り上げます。

 組織とは会社、部門、ポジションといったものの管理関係で構成されますが、部門の新設や吸収合併など、経年で少しずつ構造が変化していきます。そうした変化に柔軟に対応するための分析パターンがこの責任関係パターンです(図1-1)。パーティーというのは、組織と人をどちらもビジネス主体として対等に扱うためのクラスです。このモデル部分だけでも、ちょっとしたアナリシスパターンの一種として「パーティー(Party)パターン」と言っていいかもしれません。

 責任関係パターンとは、組織階層関係を一般化したものです。この責任関係パターンの特徴は、実際の組織構造を表す操作レベル(具体的なオブジェクトレベル)とその構造の意味や制約を管理するための知識レベル(メタレベル)の2層のモデルを用意するというものです。

 知識レベルにある責任関係型によって、操作レベルにおけるパーティー間の関係の妥当性を制約(委託者と責任者の対応関係)として保証するのです。オブジェクトレベルのパーティーの委任者と責任者は、メタレベルにある責任関係型の委任者および責任者が許容する者でなければなりません。

 責任関係型に記された制約はパーティーが増減しても変わらないので、組織構造の変更はパーティー型や責任関係型のインスタンスやリンクの追加削除で対応します。このモデルを用いた実例として、「会社-部-コンサルタント」という階層構造のオブジェクトモデルを、図1-2に示します。

 実は、オリジナルのアナリシスパターンはUMLとは異なるモデル表記法が採用されているため、なかなか各パターンの意図を読み解くのが大変です。しかし、さまさまなビジネス領域で応用できる概念モデリングのコツの宝庫とも言えるので、ぜひチャレンジしてほしいと思います。その際、できるだけ具体例を示すオブジェクト図を自分の手で描いて、抽象的な概念構造の意味をサンプルで確認する努力が重要です。

エリクソンとペンカーのビジネス・モデリング・パターン

 では次に、UML記法を前提に、ステレオタイプを使って見た目を少し拡張してビジネスモデリングに適したダイヤグラムを追加したエリクソンとペンカーのビジネスモデリングに対する取り組みを見てみましょう。

 まず、対象となるビジネスを「ビジョン」「プロセス」「構造」「ふるまい」のカテゴリで順番にモデリングしていきます(図2-1)。アナリシスパターンでは取り扱わない、戦略定義を含むビジネスの超上流からモデリングを始めて、ビジネスゴールが達成されるように概念クラスやビジネスプロセスを識別していき、それぞれの目的に合った視点やそれを記述するためのダイヤグラムが、UMLないしはその拡張として用意されています。

 それらのダイヤグラムを作成する際に、「ゴール分析のためのパターン(3個)」「ビジネスプロセスのパターン(10個)」「リソースとルールのパターン(13個)」と全部で26個のパターンを用意して、ビジネスモデリングを誘導してくれます。

○ビジネスゴールパターン:ゴールの設定・分割・問題の識別
・Business Goal Allocation(ビジネス目標設定)パターン
・Business Goal Decomposition(ビジネス目標分解)パターン
・Business Goal-Problem(ビジネス目標-問題)パターン

○ビジネスプロセスパターン:プロセスの定義と実行を記述
・プロセスモデリングパターン7種:プロセスの実行を記述する
・プロセスインスタンスパターン1種:プロセスの実行形態を管理する
・プロセスサポートパターン2種:プロセスの運用を支援する

○リソースとルール・パターン:資源とそのルールに関する記述
・Contract(契約)パターン
・Employment(雇用)パターン
・Title-Item(タイトル-項目)パターン
 ……ほか全13パターン

ビジネスプロセスパターンの例

 プロセスパターンとは、あるゴールを達成するためにどのような入力オブジェクト群を、どのような出力オブジェクト群に、どのような手順=プロセスで変換すればよいのかを定義するためのパターンです。

 その基礎になるのが、図2-3で示した「基本プロセス構造」パターンです。これはUMLのアクティビティ図の拡張になっていますが、入出力以外に、<>でそのプロセスの目的や制約を、<>でそのプロセス実施の機構を与えているととらえると、IDEF0のプロセス構造を表現しているとみなすことができます。

□リソースとルールのパターン

 一方、ビジネスプロセスを実行する上で利用されるリソースとそれらの間で満たさなければいけない関係や制約は、13個ある「リソースとルールのパターン」をうまく適用することによって表現することができます。組織や従業員、ビジネス・契約文書、資源の性質、用語に関する定義、といったテーマでリソースとそれが持つべき関係・制約がパターン化されています。これらの半数はアナリシスパターンとかなり類似したものが含まれています。たとえば、リソースとルール・パターンの典型として、「ある組織の特定のポジションにあるヒトを雇用してアサインする」という状況を表現するのに便利な「雇用(Employment)」パターンを示しておきます(図2-4)。

 以上簡単に見てきましたが、エリクソンとペンカーの各ビジネスパターンはGoFデザインパターンと同じテンプレートで定形的に記述されていますし、ビジネス上流からユースケース定義を用いた要求定義までのビジネスモデリング全体を体系化しています。そのため、ビジネスモデリングのためのパターンランゲージを構成していると言ってよいでしょう。

REAとビジネスパターン

 最後に、REAビジネスパターンについて見ていきましょう。これは最近登場した非常に斬新なビジネスモデリングの方法論です。UMLを用いますが、単なるモデリングノウハウというよりも、経済行為というものの意味(オントロジー)から出発して、R(Resource:資源)、E(Event:イベント)、A(Agent:エージェント)というモノ・コト・ヒトの3大基本要素が常に満たすべき制約条件と、それらの間に成立する相互作用をスケルトンとして実際のビジネスをモデル化します。

 一般にビジネストランザクションとは、経済リソースの交換であると認識します。「ある経済リソースの価値を増やすために、通常はいくつかの経済リソースの価値を下げる」というプロセスであり、後で示しますが、そこに必ず価値の「交換の双対性(そうついせい、duality)」が成立します(図3-1)。

 REAとはそれぞれ次のように定義されるビジネス要素です。
・R:経済リソースは、製品、サービス、お金、原料、労働力などのように交換の対象となるものです。経済エージェントにとって価値のある(希少性)ものであり、経済エージェントの管理下に置かれます。

・E:経済イベントは、経済エージェントが制御する、経済リソースの価値の増加および減少を表します。経済イベントは即時に発生するか(商品の販売など)、ある一定期間の間発生する(レンタルや労働力の提供など)ものかに分けられます。

・A:経済エージェントとは、経済リソースを管理し、ほかの個人や組織に制御を移管したり、ほかの個人や組織から管理を受けたりする個人や組織のことで、例えば顧客、ベンダー、従業員、企業などです。

 これらREAの組み合わせの仕方がパターン化されており、次のような3つのレイヤーで構成されています。

(1)業務レベルの構造パターン(REA基本原理:実際のビジネストランザクションを表現)
・REA交換プロセス、REA変換プロセス、REAバリューチェーン

(2)方針レベルの構造パターン(どのビジネストランザクションが起きるべきかを表現)
・タイプ、グループ、コミットメント、契約、スケジュール、方針、連結、責任、監督

(3)ふるまいパターン(特定のビジネスニーズに応じてREAをアスペクト指向で拡張)
・基本:識別、期日、説明、注釈、ロケーション、分類、通知、価値
・財務:転記、勘定、照合、実体化した請求権
・新規:考案者のパラドックス

 まず(1)業務レベルが経済活動の根底となる部分で、モデリングの基本要素とそれらの基本的な制約を定義し、業務を「交換プロセス」(異なる経済エージェント間の取引)と「変換プロセス」(自分が所有するリソースに対する生産や消費のモデル)としてとらえます。

 「現金販売」「返品」「貸与と賃貸」「融資」などが他者との交換プロセスの例であり、製品の「生産」やサービスの「使用」などは企業内部の変換プロセスの例になります。そして交換や変換がつながって大きな経済活動になったものが「バリューチェーン」です。

 (2)方針レベルでは、経済活動をビジネスルールで制約づけるためのモデルを与えます。顧客や商品の「タイプ」によってビジネスルールを適用、企業は「契約」を守り、「スケジュール」にもとづいて生産を行います。モノとモノが「連結」し、ヒトがヒトの「責任」をとり、ヒトがモノを「監督」します。つまり、エンティティ間の接続関係の文法を方針レベルで与えているのです。

 (3)ふるまいパターンのレベルでは、ビジネスに登場するさまざまな一般的な関心事(concerns)をパターンとして取り出し、アスペクトとしてベースのモデルに織り込んでいくことができるようになっています。

販売プロセスをREAモデルで記述

 ここでは原著でも説明に使っている、ピザ屋というエージェントが顧客というエージェントにピザを販売するプロセスをREAモデルで表現してみましょう。

 ここには2つの経済イベントが登場し、それらは双対の関係となります。1つは、ピザ屋から顧客へのピザの所有権が移転すること(「販売」というイベント)です。このビジネストランザクションにおいて、ピザ屋はピザを提供し、顧客はピザを受け取ります。

 もう1つの経済イベントは、顧客からのピザ屋へ現金の所有権が移転すること(「現金の受領」というイベント)です。このビジネストランザクションにおいて、顧客は現金を提供し、ピザ屋は現金を受け取ります(図3-2)。

 ピザ屋にとって販売は減少イベントです。ピザ屋が制御しているリソース(ピザ)の価値を減少させることになるからです。逆に現金の受領は増加イベントです。ピザ屋が制御しているリソース(現金)の価値を増加させるからです。逆に顧客の視点をとれば、ピザの移動は増加イベントであり現金の移動は減少イベント、という風に正負が反転します。

 いずれにしても、増加イベントと減少イベントは、必ず両方が同時に存在しなければなりません。これが<<交換の双対性>>で,REAエンティティ同士の関連のステレオタイプとして明示します。双対(そうつい、dual)とはお互いの立場を逆転しても(符号は反転するが)成立するという意味です。

 この例では店側の増加イベントと顧客の減少イベントが双対イベントとして同時に起こりましたが、ビジネスの世界では、売り掛け・買い掛けや手形・小切手といった支払いを遅延させる仕組みがあるのはご存じでしょう。そうなると、価値の増加イベントと減少イベントは同時に起こらないので、方針レベルのビジネス構造パターンである「実体化された請求権」を導入して、見掛け上の双対性が成立するようにモデルを構成することになります。この請求権がまさに手形や小切手に相当するわけですね。

 なお紙面の都合で詳しい説明は省略しますが、REAモデルではさらに、業務ドメイン制約を、方針レベルの構造パターンとふるまいパターンを織り込むことによって、モデルの中に正確に業務ルールや制約を定義していきます。またその際に、アスペクト指向的な視点でモデルを合成していくことになります。ですから従来のビジネスモデリング手法に比べて、このREAビジネスパターンにもとづいて作成されたモデルは妥当性検証やMDA(モデル駆動型アーキテクチャ)の実施に向いていると言えます。

 たとえMDAをやらないにしても、純粋に業務の意味論をどうモデルに反映すべきかという深い洞察部分に関して、非常に参考になるでしょう。

□まとめ
 アナリシスパターン、UMLビジネスモデリング、REAビジネスパターンと順に見てきました。最初はモデラーが自分のオブジェクトモデリングスキルに頼ってモデリングしていたのを、アナリシスパターンで概念モデリングTips集としてノウハウ化しました。UMLビジネスモデリングでは、より体系的にビジョン・概念・プロセス・ユースケースという階層的なパターンランゲージ化を目指してきたのですが、人間の概念モデリングの直感的スキルに根ざす点ではアナリシスパターンと同類のものでした。

 そしてREAモデルに至って初めて、ビジネスドメインが普遍的に持つリソース・イベント・エージェントの間にあるビジネストランザクションの双対性という原理にもとづいて、業務ドメインのオントロジーを定義することでアプリケーションのセマンティクスを導出できる可能性が視野に入ってきたと言えます。

 今後もパターンやモデリング方法論はさまざまなものが登場すると思いますが、このように、モデル駆動やドメイン駆動、アスペクト指向という潮流と合流することで確実に進化していくことが見て取れるでしょう。


【参考文献】

「アナリシスパターン―再利用可能なオブジェクトモデル」マーチン・ファウラー、2002(ピアソン・エデュケーション)
「UMLによるビジネスモデリング」エリクソン/ペンカー、2002(ソフトバンク)
「ビジネスパターンによるモデル駆動設計」Pavel Hrubyほか、2007(日経BP)

株式会社豆蔵
株式会社豆蔵取締役CTO、プロフェッショナル・フェロー。技術士(情報工学部門)。オブジェクト指向やソフトウエア工学の実践適用に関するコンサルティング,セミナー講師に従事し,後進の育成にあたる。 アジャイルプロセス協議会会長,IPA/SEC設計技術部会委員,情報処理学会ソフトウエア工学研究会パターンワーキンググループ主査,IPA ITアーキテクト・コミュニティ委員,等を務める。神社と富士塚・古書店等を巡る街歩きが趣味。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています