[技術情報]

エンタープライズモデリングへの誘い（いざない）
第3回 アクティビティ図によるワークフロー定義

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

エンタープライズモデリング本、訳書発売！

　ついにエンタープライズモデリング(以下、EM)本の訳書が出ました。その名も『企業情報システムの一般モデル  −UMLによるビジネス分析と情報システムの設計』です。翻訳をされた児玉さん、井関さん、加藤さん、河合さんに感謝致します。原書を読んだだけでは理解できなかったことが、この訳書を読むことで解決されました。ありがとうございます。この記事を読んでEMに興味を持った方は読んでみてはいかがでしょうか！

　さて訳書も出たことですので、本連載ではEMの基礎知識だけでなく、その根底にあるビジネスの理論や、モデリングの実践的なテクニックなど、幅広く論じていきたいと思います。
＃そうしないと、訳書のパクリになってしまいますから。。。

前回の復習

　皆さん、前回の内容を覚えていますか？ 前回から学習塾ビジネスモデルの構築を題材に、EMの実践が始まりました。忘れてしまった方、まだ読んでいない方は、 『エンタープライズモデリングへの誘い 第2回』をご覧下さい。

　前回はEMで提案されている目的や目標の概念について説明し、これを元に学習塾の目標モデルを構築しました。最後に目標モデルから学習塾に必要なプロセスを導き出すところで前回は終わりました。今回はその続きからです。それでは、今回も学習塾塾長に悩んでもらいましょう。

プロセスから目標モデルの見直し

「この前は俺が立てた目標を元に、どんなプロセスが学習塾に必要か考えていたんだったな。この前定義した目標にはこんなものがあったなぁ」

• 講義の進行状況
• 合格率
• (生徒の)学力

「この3つの目標に対応して定義したプロセスは確かこんな感じだったな。」

「でも、(生徒の)学力に対応して定義したプロセスが、『講義プロセス』と『学力テストプロセス』と『授業計画プロセス』の3つになってしまったけれど果たしてそれで良いんだろうか？『講義プロセス』は講義の進行状況という目標も持っているし。。。」

「まず『講義プロセス』から考えてみよう。確かに『講義プロセス』を実施することで(生徒の)学力はアップする。でも『講義プロセス』の直接の目標を生徒個々人の『学力』にしたとしても、講師は生徒の『学力』を測定できるのだろうか？それより測定しやすい『講義の進行状況』を『講義プロセス』の目標にした方がよさそうだ。」

「ただ前に書いた『講義の進行状況』モデルでは、『講義』でスケジューリングするものを『単元』にしていたけれど、『単元』＋『学力』に変えた方がいいかも。『単元』もどのレベルまで教えるかといった、分け方はあるからなぁ。」

「次は『学力テストプロセス』だ。そもそも、『学力テストプロセス』は生徒の学力を測定するためのプロセスだよな。生徒の学力を上げることには直接の関係はない。ということは現行の目標モデルには『学力テストプロセス』の目標は定義されていないことになる。『学力テストプロセス』が達成しなければならない目標とはなんだろう？」

悩むこと数十分。。。

「ああ、わかってきた気がするぞ。当たり前だけど『学力テストプロセス』の目標は”生徒の学力が測定できること”なんだ。そのためには生徒の学力に見合ったテストを作らなければならない。テストの結果が100点ばかりだったり、0点ばかりでは生徒の学力など測れないからな。目標モデルに『テスト』を加えなければならないな。」

「もう一つの『授業計画プロセス』は、生徒の学力を期限内に期待値まで上げる授業を計画するプロセスだ。『生徒』の『学力目標』の『期待値』を達成できるような『講義』の計画を立てなければならない。多くの『生徒』が学ばなければならない内容は『正規授業』で、一部の学生のみに必要な内容は『補講』で教えよう。結局、これも生徒の学力を上げることに直接の関係はないのか。」

「こうして考えてみると、学力という目標は一つのプロセスのみで達成できるわけではないのかもしれないな。授業の進行状況、テスト、授業計画の3つの目標を達成することで、初めて学力目標も達成できるわけか。」

筆者の独白

　初めに定義した目標は往々にして抽象的になってしまいます。その上、この目標が抽象的だと気づかないこともあります。抽象的な目標がビジネスにとって重要なことには変わりませんが、実際にビジネスをするためにはより具体的な目標が必要です。

　より具体的な目標を見つけるためには目的を達成するためにどんなプロセスが必要か考えてみましょう。思いついたプロセスと達成すべき目標の間にギャップが存在するとき、そのプロセスに具体的な目標が潜んでいるかもしれません。思いついたプロセスが達成する目標を定義してモデルに加えましょう。

　このやり方は目標のモデリングだけでなく、モデリング全てに言えることかもしれません。「モデリングに行き詰まった時には、モデリング対象をそれまでと別の視点からモデリングしてみる。するとそれまでモデリングしていて見つからなかったモデル要素が見つかる。」

「今回、新しく見つかった目標とプロセスをまとめるとこんな感じかな。」

「学習塾に必要なプロセスが分かってきたから、次はプロセスそのものの定義をしよう。」

注1:『授業計画プロセス』のことを前回の記事では『カリキュラム企画プロセス』と呼んでいました。『授業計画プロセス』の方がプロセスの意図を的確に表現していると思いましたので、プロセス名を変更しました。

ビジネスプロセスとはなんぞや

　前回は目的の側面からビジネスプロセスについて説明しました。今回はもう少し掘り下げてみましょう。

　前回も説明したように、ビジネスプロセスとはビジネスの目的を達成するために行われる一連の作業です。一概に作業といっても様々な粒度のものがあります。ある作業はより厳密な、より小さな粒度の順序付けされた複数の作業からなります。このような作業を混合プロセスと呼びます。これ以上分割できない最小単位の作業をプロセスステップと呼びます。人が実際に行う作業はこのプロセスステップです。このプロセス構造をEMでは以下のようなモデルで表現しています。このモデルの親プロセスは混合プロセスを意味します。

　EMのプロセスの考え方はワークフローの影響を受けています。特にワークフロー標準化団体の WfMC（Workflow Management Coalition）が公開している 『The Workflow Reference Model』の影響を強く感じます。例えば、ワークフローにはプロセスをプロセスの作業の流れを定義したプロセス定義と、実際の作業の情報を記録するプロセスインスタンスを別のものとしていますが、同じ考え方をEMも取り入れています。EMの混合プロセス、プロセスステップもワークフローにも同様のサブプロセス、アクティビティという概念があります。

　ワークフローには組織ロールとワークフロー担当者という概念があります。EMにも組織ロールとアクターというほとんど同じ概念があります。これらの概念はプロセスがどうやって実行者に割り当てられ、実行されるかを定義します。下の図は組織ロールとアクターとプロセスの関係を表したクラス図です。

　組織ロールとは組織が担う役割です。例えば、販売、製造、マーケティングなどが組織ロールになります。プロセスステップはどの組織ロールで実行されるのか決まっています。例えば見積もりプロセスステップは販売ロールで実行されるでしょう。

　アクターはプロセスを実際に実行するリソースです。人、機械、ソフトウェアシステムはアクターになります。アクターは組織ロールのプロセスを実行するのに十分な資格、スキルを持っていなければなりません。そのようなアクターしか組織ロールのプロセスを実行できません。

　プロセスは開始されると始め組織ロールのワークプールにプールされます。そして組織ロールを担当するアクターに暇ができるまでプロセスは待機します。アクターに暇ができたとき組織ロールのワークプールからプロセスは取り除かれ、アクターのワークリストに追加されます。その後はアクターによってプロセスが実行されるわけです。

アクティビティ図を使ったワークフロー定義

　EMではプロセス定義の手始めとして、ワークフローの定義を行います。UMLにはワークフローを記述するためのダイアグラムとしてアクティビティ図(Activity Diagram)があります。EMもアクティビティ図を用いてワークフローを記述します。

　読者の中には「クラス図とかシーケンス図を使ったことはあるけど、アクティビティ図はない」とか、「アクティビティ図は使っているけど、詳しくは知らない。」という方が多くいるかと思います。そこで、EMでのワークフロー定義を説明する前に、アクティビティ図について簡単に説明しましょう。

　アクティビティ図は処理の流れを書くためのダイアグラムです。フローチャートの一般的な使い方であったプログラムの流れを記述するためにもアクティビティ図を利用できますが、それよりも作業の流れなどを記述することに効果的です。（今回のように！）

　UMLはアクティビティ図を状態遷移図(Statechart Diagram)の拡張として定義しています（注2） 。そのため、状態遷移図の状態（State）や遷移（Transition）に当たる要素がアクティビティ図には含まれています。

　上の図は販売の流れを記述したアクティビティ図の例です。

　長円はアクション状態（Action State）と言い、原子的な処理、作業の状態を表します。対して、内部にアクティビティ図を持つ長円をサブアクティビティ状態（Subactivity State）と言います。アクティビティの始まり、初期状態（Initial  Pseudostate）を黒丸で、アクティビティの終了、終了状態（Final State）を目玉で表します。これらの状態の順番を矢印で表し、この矢印のことを遷移（Transition）と言います。

　遷移は条件分岐や並行化することが可能です。条件分岐は決断（Decision）と呼ばれ、ひし形で記述します。並行して実行される処理を表現するために太棒で表される同期バー（Synchronization Bar）を用います。

　状態遷移図にはないアクティビティ図特有の要素としてスイムレーン（Swimlane)があります。スイムレーンを用いることでアクション状態やサブアクティビティ状態を分類することができます。 スイムレーンには組織単位を割り当てます。

　アクティビティ図の要素はEMの概念やワークフローの概念と共通するところがたくさんあります。下にEM、UML、ワークフローの概念の対応表を載せます 。

　基本的にはアクティビティ図をそのまま使ってワークフローを記述していけばよいのですが、スイムレーンについては少し補足をした方がいいかもしれません。UMLのスイムレーンは組織単位に定義しますが、EMでは組織ユニット、組織ロール単位に定義します。組織ユニットとはつまり組織単位のことです。会社や客、部や課などが組織ユニットです。組織ロールは組織が担う役割で、販売、製造、マーケティングなどです。

　アクティビティ図は書いているうちにどんどん大きくなり、複雑になる傾向があります。それは、ビジネス中にたくさんプロセスステップがたくさんあったり、イレギュラーケースのワークフローを書こうとして条件分岐が増えてしまったり、そもそもモデリング対象となるビジネスの範囲が広かったりと、様々な原因があることでしょう。
　この問題を解決するためのテクニックがEM本で紹介されています。これはEMに限らず、通常のシステム開発でアクティビティ図を使う場合にも有効なテクニックなので、ぜひ参考にしてください。

　アクティビティ図を整理するテクニックは大きく分けて2つあります。

• プロセスの分割
• プロセスの分離

　プロセスの分割とは複数のプロセスステップをまとめて、一つの複合プロセスを定義することです。UMLではサブアクティビティ状態を使うことになります。上のアクティビティ図でもサブアクティビティ状態を使っています。上の例ではサブアクティビティ状態中にアクティビティ図を表示していますが、これを非表示にすることで図は見やすくなるでしょう。
　プロセスの分割の利点はアクティビティ図を整理できることだけではありません。頻繁に使用される、または優れているプロセスを複合プロセスにすることでプロセスの再利用が容易になるでしょう。

　プロセスの分離とは組織ユニット間、組織ロール間をまたがるプロセスを別々のプロセスに分離して、分離したプロセスの間で受け渡しされるオブジェクトを定義するテクニックです。製造業の製造プロセスなどは自社で製造した加工部品をオブジェクトにすることで分離できます。

　販売のアクティビティ図も同じように分離することが可能です。ただし、分離されたプロセス間で受け渡しされるものは製造業のような単なるモノではありません。販売 のアクティビティ図に書かれているワークフローは組織ロール間で相互作用しています。このような組織ロール間の協調作業は、（特に客が関わる場合は）組織ロール間で交わした契約に基づいて行われます。EMでは契約を目的のとしてモデリングし、組織ロール間で協調するために受け渡しされるオブジェクトは契約の内容に基づいたオブジェクトを記述します。ちなみに、このオブジェクトをEMでは三角のアイコンで記述します。下の図は契約で分離した販売ワークフローのアクティビティ図です。

注2：UML2.0では、アクティビティ図を状態遷移図の拡張ではなく、ペトリネットの考え方を採用した別の機構として実現しようという提案がなされています。

塾長、ワークフローを書いてみる

「そうか、ワークフローはアクティビティ図で書けばいいんだな。では『学力テストプロセス』を書いてみよう。」

「まずテストの基本仕様となるテスト範囲と難易度を決めてテスト範囲を塾の生徒に公示する。と同時にテストの基本仕様からテストの問題を作成する。問題ができたら、テスト用紙を作成する。テストを実施した後はテストの採点を行って、その結果から生徒の現在の学力を計算しなおす。」

「うん。ワークフローとしてはこんな感じでいいとは思うけれど、学習塾のプロセスステップをもう少し整理できないものだろうか。組織ロールを導入することで、プロセスステップを分類してみよう。」

「『テスト範囲・難易度設定プロセスステップ』はどんな組織ロールが担当するのだろうか。そもそも『テスト範囲・難易度設定 プロセスステップ』は、生徒が学力目標を達成しているか測定できるテスト範囲・難易度を設定するステップだよな。だから、このステップを実行できるアクターは生徒の学力について熟知していないといかないはずだ。『テスト範囲・難易度設定プロセスステップ』を担当する組織ロールを『学力管理組織ロール』と名づけよう。」

「他に『学力管理組織ロール』が担当するプロセスステップはあるだろうか？おそらく、『学力再計算プロセスステップ』もそうだろうな。『問題作成プロセスステップ』はどうだろう？このプロセスステップは生徒の学力について考える必要はないよな。その替わり、テスト問題に熟知していなければならない 。『問題作成プロセスステップ』を担当する組織ロールを『問題作成組織ロール』としよう。」

「しかし『テスト範囲・難易度設定』プロセスステップと『問題作成プロセスステップ』を別の組織ロールが担当するとなると、作成されたテスト問題が指定したテスト範囲・難易度に準じているか検査する必要が出てくるなぁ。『問題検査 プロセスステップ』を『学力管理組織ロール』に加えるとしよう。。。」

　組織ロールを定義するのなら、その組織ロールが担当するプロセスステップのアクターのがどのような資格やスキルを持っていなければならないか想像してみましょう。その資格やスキルに組織ロールを定義するヒントが隠されています。

「ワークフローを組織ロールに分類するとこんな感じになるのかな。」

「これで大体いいかな。『学力テストプロセス』に必要なプロセスステップと組織ロールも見つけられたことだし。さて、次はプロセスステップで使用されるエンティティ、つまり 情報や資源の定義をしなければならないのか。。。』

次回予告

　さて、次回は『エンティティモデリングによるプロセス洗練』です。エンティティ、つまりビジネス中に存在する情報や資源をモデリングすることがどのようにプロセスモデルに影響を与えるのか見てみたいと思います。
　どうぞお楽しみに！

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

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

参考文献

　[1] Chris Marshall 著 : "Enterprise Modeling with UML", Addison-Wesley, 1999 （邦訳：児玉公信 『企業情報システムの一般モデル―UMLによるビジネス分析と情報システムの設計』 ， ピアソン･エデュケーション）
　[2] 戸田保一， 飯島淳一， 速水治夫， 堀内正博 ： 『ワークフロー―ビジネスプロセスの変革に向けて』 ， 日科技連

関連ホームページ

　ワークフロー標準化団体　WfMC(Workflow Management Coalition)

© 2002 OGIS-RI Co., Ltd.

Prev. Index Next.