ObjectSquare

[技術情報]


エンタープライズモデリングへの誘い(いざない)
第4回 組織ロールによるビジネスモデルの関心の分離

(株)オージス総研
オブジェクトテクノロジーソリューション部
そして
事業模型倶楽部
山内 亨和

前回の復習

 前回はアクティビティ図を用いたワークフロー定義について解説しました。詳しい内容については『エンタープライズモデリングへの誘い 第3回』をご覧下さい。

 学習塾のワークフローを定義することによって、学習塾にあるプロセスステップと組織ロールを見つけ出すことができました。今回はこの組織ロールに焦点を当ててみたいと思います

組織ロールによる関心の分離(Separation of Concern)

 モデルを書いていて、モデルが必要以上に複雑になってしまい悩んでしまうことはないでしょうか?この現象はモデリング対象の問題領域が複雑な場合に発生しますが、本質的な原因は問題領域が複雑なことではありません。

 本質的な原因は、複雑な問題領域には複数の異なる側面の問題が存在するにも関わらず、異なる問題を一つのモデルで表現しようとしていることにあります。だから、複雑な問題領域にアプローチする場合には、問題領域をどのような問題に分離できるか分析し、分離した問題ごとに適切なモデルを書かなければなりません。もしこれを怠ると、問題領域を正しく反映していないモデルができてしまい、それをもとに構築されるシステムも役立たずの代物となってしまいます。

 エンタープライズモデリング(以下、EM)手法は、ビジネスモデリングにおけるこの問題を解決するために、組織ロールという概念を導入しています。

 この聞きなれない概念、組織ロールとは何なのでしょうか。簡単に定義すれば「組織内にある機能の分類」となるでしょう。といっても具体的な例を見せないと何のことなのかさっぱりわからないかと思います。例えば以下のものを組織ロールといいます。「会計ロール、エンジニアリングロール、保守ロール、マネジメントロール、製造ロール、プランニングロール、出荷ロール。。。」なんとなくわかっていただけましたか。(というかそういうものと思ってください。これ以上は私も説明できないのです。)本当にビジネスの機能単位なのです。

 EMではこの組織ロール単位にビジネスのモデルを分離していきます。組織ロールは事業内に存在するプロセスとエンティティ(資源、資産、情報)を適度な単位に分離します。その結果、モデルは単純になります。前回の記事で解説したプロセスステップは、プロセスを組織ロール単位に分離した概念でもあります(それだけではありませんが)。そして、エンティティの情報や振る舞いを組織ロール単位に分離した概念をエンティティロールと呼びます。

エンティティロール

 実はまだエンティティについて説明していませんでした。エンティティとはビジネス中に存在する資源や資産や人や会社とそれらにまつわる情報のことをいいます。OOSEやロバストネス分析でいわれるエンティティを想像してもらうといいかもしれません。例をあげるなら、システム開発者、パソコン、顧客、銀行口座など様々です。

 それではシステム開発者エンティティがどのような情報を持つか考えてみましょう。まずはスキル。様々な種類のスキルとそのランクの情報があるでしょう。他にキャリア。これまで関わっていたプロジェクトの情報です。他にもまだあります。現プロジェクトの進捗。割り当てられたパソコンとアカウント。個人情報。銀行口座。単価。。。

システム開発者エンティティモデル

 ここで良からぬ方向に進んでいると気づいた人はモデリングに慣れている人ではないでしょうか。実は今行っていたエンティティ情報の洗い出し作業には重大な欠陥がありました。

 というのも今の情報洗い出し作業では、システム開発者モデルのコンテキスト(文脈、背景)を全く考慮していなかったのです。EMでは組織ロールがエンティティにコンテキストを提供します。組織ロールをもとに定義したエンティティの振る舞いと情報がエンティティロールの定義となります。組織ロールとエンティティロールとエンティティの関係をクラス図で表すと以下のように表現できます。

エンティティロール (注1、注2)

 組織ロール内では様々なエンティティが登場します(組織ロールからエンティティへの関連、多重度N)。エンティティは様々な組織ロールに登場し、その組織ロールはエンティティをモデリングするためのコンテキストとなります(エンティティから組織ロールへの関連、多重度N)。あるエンティティがある組織ロール中に登場するとき、エンティティは組織ロール特有のエンティティロールを提供します。

 具体的な例として、組織ロールをもとにシステム開発者エンティティのエンティティロールを定義してみましょう。
 まずはプロジェクトマネジメント組織ロールの観点から。プロジェクトマネジメントにとって開発者とはプロジェクトを成功裏に終わらせるためのプロジェクトメンバです。開発者のプロジェクトマネジメント組織ロールにおけるエンティティロールをプロジェクトメンバと名づけたとして、このロールに必要な情報はスキルと進捗と成果でしょう。
 営業組織ロールの観点から見た開発者エンティティのエンティティロールは商品です。商品の価値はキャリアの情報で決まり、その対価は開発者の単価となります。
 人事評価組織ロールの観点から見た開発者エンティティのエンティティロールは評価対象であり、その評価方法は組織によりまちまちですが、例えば現プロジェクトの成果から給料が決まります。
(ちなみにオブジェクトの広場組織ロールから見た開発者エンティティのエンティティロールは記事提供者であり、記事提供回数(モチベーション)とスキルで表現されます。)

 ここまでで開発者のエンティティロールとしてプロジェクトメンバ、商品、評価対象、記事提供者?が定義されました。これらは別々のエンティティロールですが、実際のデータ表現としてはシステム開発者エンティティの形を取ります。プロジェクトメンバの成果情報、商品のキャリア、評価対象の成果情報は全て同じ情報をもとに計算されるわけですから。

システム開発者エンティティロール

 このように組織ロール単位にエンティティをモデリングすることで、エンティティのモデルが過度に複雑化することがなくなるでしょう。
(ちなみにこのロールを用いるテクニックはビジネスモデリングだけではなくシステム開発時の概念モデリングでも有効なのでぜひ試してみてください。)

注1:元ネタの『企業情報システムの一般モデル −UMLによるビジネス分析と情報システムの設計』にはこのような図はありません。より分かりやすくするために私が作成しました。

注2:組織ロールとエンティティロールとエンティティの関係はUMLにおけるコラボレーションとクラシファロール(ロール)とクラシファ(クラス)に置き換えて考えられるでしょう。

プロセスステップはいかにして実行されるのか

 実は先ほどのシステム開発者のエンティティロールモデリングで一つ重要な組織ロールを取り上げていませんでした。それはシステム開発組織ロールです。この組織ロールに対応するシステム開発者のエンティティロールとは何でしょうか。

 結論をいってしまうと、それはアクターです。UP(Unified Process)風にいうとワーカーでしょうか。組織ロール中で定義されるプロセスステップの主たる実行者としてエンティティがいる時、そのエンティティのエンティティロールとしてアクターを定義します。アクターは情報としてスケジュールやスキル、成果を持っていることでしょう。アクターは人とは限りません。機械の場合もあればシステムの場合もあります。

 ちょっと視点を変えてプロセスステップを中心に組織ロールやエンティティ、エンティティロールの関係を考えてみましょう。

 プロセスステップは特定の組織ロール中に定義します。そして、プロセスステップはエンティティロールを介してのみエンティティの情報を操作できます。これが重要です。

プロセスステップとエンティティロール

 エンティティロールは大きく3つに分類できます。アクターとアーティファクトパーティーです。あるエンティティがプロセスステップの実行者となるとき、エンティティロールとしてアクターを定義します。あるエンティティがプロセスステップ中で使用されるとき、エンティティロールとしてアーティファクトを定義します。あるプロセスステップ中でプロセスステップの実行者ではない人、組織が登場する場合、エンティティロールとしてパーティー(注3)を定義します。システム開発者のエンティティロールモデリング時に発見した商品、評価対象はアーティファクト、プロジェクトメンバ、記事提供者はパーティーになります。

 オブジェクトの広場組織ロールの記事依頼プロセスステップをモデリングすると以下のようなモデルになるでしょう。

記事依頼プロセスステップ

 記事依頼プロセスステップの実行はシステム開発者エンティティの編集員アクターが行い、プロセスステップ中でのエンティティの振る舞いは記事提供者パーティー、掲載記事アーティファクトで定義します。システム開発者エンティティ、記事エンティティそのものは広場組織ロールから参照されることはありません。

注3:EMのパーティーには人、組織であることの他にもう一つ重要な定義があります。パーティーは組織間、組織ロール間で交わされる契約における登場人物です。契約に関する説明は次号行います。

EMのプロセスクラス図

 今まで説明したエンティティロールとプロセスステップEMでどのように記述するのか説明します。

プロセスステップモデルテンプレート

 クラス図の一番上にプロセスのクラスを定義します。このプロセスクラスは自身が使用するエンティティロールを参照します。各プロセスステップクラスはプロセスクラスを継承することで、プロセスで定義したエンティティロールを使用することが可能となります。今はプロセスステップは殺風景ですが、次号でプロセスステップにもう少し関連先が加わります。プロセスステップにおいてエンティティは重要でないのでこの図には書きません。あくまで重要なのはプロセスステップがどのエンティティロールを使うかなのです。オブジェクトの広場の記事依頼プロセスステップを定義すると下のようになります。

記事依頼プロセスステップクラス図

次回予告

 さて、次号は『バリューモデル構築と目的モデルへのリンク』です。次号はついに最終回!今回説明できなかったバリュー、組織ユニット、契約の概念について説明します。また今回は登場しなかった塾長が復活し、理想の学習塾モデルを完成させます。
 どうぞお楽しみに!

参考文献、及び関連ホームページ

 本稿は以下の書籍やホームページを参考にして執筆しました。このリストがみなさんのエンタープライズモデリングの理解に役立てば幸いです。

参考文献

 [1] Chris Marshall 著 : "Enterprise Modeling with UML", Addison-Wesley, 1999 (邦訳:児玉公信 『企業情報システムの一般モデル―UMLによるビジネス分析と情報システムの設計』 , ピアソン・エデュケーション)


© 2002 OGIS-RI Co., Ltd.
Prev. Index Prev.
Prev. Index Next.