メディア

ビジネス要件をBPMNで記述してみよう（後編）：BPMNを活用したビジネスプロセス・モデリング（4）

第3回「ビジネス要件をBPMNで記述してみよう（前編）」に引き続き、複雑なビジネス要件を表現するために必要なバリエーションを紹介します。今回は「ゲートウェイ」と「シーケンスフロー」を対象として、業務の流れを詳細に記述する方法について説明します。

» 2005年06月30日 12時00分公開

[構成谷古宇浩司（編集局），＠IT]

◆ ゲートウェイのバリエーション

　実際の業務においては、状況を判断して次に実行すべき作業を選択する、効率化を図るために複数の作業を分担して同時に実行するといったことが行われています。そのような事柄、まさに業務ノウハウとも呼べるような事柄を正確に表現することが業務の可視化において重要になります。そして、それらの事柄を表現するために使用するものが、シーケンスフローを複数に分流させたり、複数のフローを合流させたりするゲートウェイです。BPMNでは、複雑な業務であっても表現できるようにXORゲートウェイ、ORゲートウェイ、ANDゲートウェイといった3つのゲートウェイが用意されています（図1）。

図1 ゲートウェイのバリエーション

■ 判断（Decision）

　判断とは、複数の出力シーケンスフロー（分流するシーケンスフロー）の中から条件に合ったシーケンスフローを選択するものです。必ず1つのシーケンスフローだけが選択される場合を排他的判断（Exclusive Decision）と呼び、ゲートウェイの中に何もマークがないXORゲートウェイ（注）を使用して表します。1つまたは複数のシーケンスフローが選択される場合を包含的判断（Inclusive Decision）と呼び、ORの頭文字（O）が付いたORゲートウェイを使用して表します。図1において、XORゲートウェイを使用した例は「宿泊する」「宿泊しない」からの二者択一を表していますが、ORゲートウェイを使用した例では「航空機を利用する」と「レンタカーを利用する」の両方が選択されることも認められます。

［注］ XORゲートウェイは、XORであることを強調し、その頭文字（X）をゲートウェイの中に付けた表記でも良いものとされています。BPMN仕様書に記載されているサンプルモデルの多くは何もマークがないXORゲートウェイを使っていますが、BPMNで記述したモデルにおいてXを付けたゲートウェイを見かけたら、それはXORの振る舞いをするゲートウェイです。

■ 排他併合（Exclusive Merge）

　排他併合とは、複数の入力シーケンスフロー（合流するシーケンスフロー）のうち、最初の1つが流れてきたら次に進むものです。仮に2つ目以降が流れてくるような個所で排他併合を使用したとしても、次に進むのは最初の1つが流れてきたタイミングだけです。排他併合はXORゲートウェイを使用して表します。

■ フォーク分岐（Fork）

　フォーク分岐とは、複数の出力シーケンスフローのすべてに流すといった振る舞いをするものです。複数の作業を同時並列で実行することを表現するために使用します。フォーク分岐はプラス記号（＋）が付いたANDゲートウェイを使用して表します。

■ 結合（Join）

　結合とは、複数の入力シーケンスフローから流れてくるのを待ち、同期を取ってから次に進むものです。すべての入力シーケンスフローの同期を取る場合にはANDゲートウェイを使用し、複数の入力シーケンスフローから一部（例えば3つのうちの2つ）の同期を取る場合にはORゲートウェイを使用します。複数のうち一部の同期を取るという表現は少しあいまいですが、いい換えると、包含的判断などによって選択されたすべてのフローの同期を取るということになります。例えば、図1における「航空機とレンタカーの両方を利用する」といった場合には、両方の予約が完了するのを待ってから次に進みます。

■ イベント準拠（Event-Based）ゲートウェイ

　イベント準拠ゲートウェイは、図2に示すように複合中間イベントをゲートウェイの中に記述したものです。複数のイベントを待っている状態を表すものであり、受け取ったイベントによって複数のパス（フロー）の中から1つのパスが選択されるといった振る舞いをします。必ず1つのパスだけが選択されるため、排他的判断の一種として位置付けられています。なお、イベント準拠に対して、XOR、OR、ANDゲートウェイはデータ準拠（Data-Based）ゲートウェイとも呼ばれています。

図2 イベント準拠ゲートウェイ

◆ シーケンスフローのバリエーション

　シーケンスフローは作業の順序を表すものですが、単なる逐次的な実行を表現するだけではなく、もっと表現能力を持ったものになっています。条件判断や同時並列といった振る舞いを表現することもできるのです。BPMNでは、そのような振る舞いを表現できるように非制御フロー、制御フロー、デフォルトフローといった3つのシーケンスフローが用意されています（図3）。

図3 シーケンスフローのバリエーション

■非制御フロー

　非制御フローは、非制御という言葉が示すように、何も判断せず素直に後続へと流すものです。必ず後続に流すといった振る舞いから、ANDゲートウェイによるフォーク分岐と同様に、非制御フローを使って同時並列を表現することもできます。図3では「注文を受ける」タスクから2本の非制御フローが引かれています。「注文を受ける」タスクが完了したら、後続の2つのタスク、「在庫を引き当てる」と「出荷を指示する」が同時に実行されます。

■制御フロー

　図3において、始点にひし形（◇）が付いているシーケンスフローが制御フローです。ORゲートウェイによる包括的判断と同様に、制御フロー上に記述された条件によって流れる、流れないを決定する状況を表すことができます。

　ただし、BPMNでは条件を記述するシーケンスフローをすべて制御フローと呼ぶため、排他的判断と包括的判断を表すゲートウェイからの出力シーケンスフローも制御フローになります。そのため、ひし形が付いているシーケンスフローが制御フローであるという表現ではなく、アクティビティから出力される制御フローにはひし形が付くという表現が正しいことに注意してください。

■ デフォルトフロー

　シーケンスフローの始点にバックスラッシュ（＼）を付けたものがデフォルトフローです。デフォルトフローは、制御フローと組み合わせて使用するもので、組み合わせたすべての制御フローの条件が満たされない場合に流れるものです。条件を判断した結果、流れる制御フローがない状況、まさに業務の流れが途絶えてしまうような状況を回避するために使用します。図1における「両方とも利用しない」、図4における「上記以外」のように業務要件の観点から流れる制御フローがないケースが想定される場合には、必ずデフォルトフローを記述しなければなりません。

■ なぜ、表現に冗長性があるのか

　ここまでの説明を読んで「条件判断や同時並列はゲートウェイでもシーケンスフローでも表現することができ、BPMNでは表現に冗長性があるのでは？」と感じた読者も多いのではないでしょうか。確かに、冗長性の「あり」「なし」を問われれば、答えは「あり」です。例えば、図4に示す例（1）と例（2）といった2つのプロセスは等価なものです。BPMNからプロセス実行言語であるBPEL4WSへのマッピングルールに従って変換してみても、やはり例（1）と例（2）は同じBPEL4WSになります。では、冗長性を持たせた理由は何か。図4を基に、シーケンスフローで表現する場合、ゲートウェイを使用して表現する場合を比較して、その理由を探ってみたいと思います。

図4 等価な2つのビジネスプロセス図

　例（1）のようにシーケンスフローによって記述するメリットは、使用する図形要素が少なくなること、すなわちシンプルなビジネスプロセス図が記述できることです。しかしながら、シーケンスフローでは表現できないケース、例（2）のようにゲートウェイを使用しなければならないケースもあります。

　例えば、あらかじめ商品が梱包されているケースを考えてみてください。例（2）ではタスク「商品を梱包する」を削除し、XORゲートウェイとANDゲートウェイとの間をシーケンスフローでつなぐことで表現できますが、例（1）では「商品を梱包する」を削除したとき、残ったシーケンスフローをどのようにつなぎ直せばよいのでしょうか。結局は例（2）のようにゲートウェイを使う方法しかありません。

　BPMNでは、少ない図形要素でプロセスを表現するための工夫が随所に見受けられます。その一方で、複雑なプロセスでも表現できる記述能力も求められます。工夫をしながら記述能力も求めた結果、冗長性が生じたのだと筆者は考えています。そのような観点でBPMN仕様書を確認してみると、フォーク分岐を表現する方法として、通常は非制御フローを使い、ほかのゲートウェイと組み合わせる必要がある場合にはANDゲートウェイを使うといった旨が明記されています。表現豊かなBPMNの表記法の中から最適なものを選び、シンプルで分かりやすいビジネスプロセス図を記述していく、まさにモデラーの腕の見せどころといえるのではないでしょうか。

　今回でBPMNの図形要素の説明は終わりです。早速、BPMNを使って自分の業務を可視化してみてはいかがでしょうか。次回は、モデルを記述した次のステップとして、モデル検証のポイントやモデルを実装する流れについて説明する予定です。

［終了イベントは結合の役割を持つ］

　停止終了イベントを除く終了イベントは、すべてのフローが終了イベントに到達するのを待ってからプロセスを終了します。つまり、「ゲートウェイのバリエーション」で説明した結合と同じ役割を持っているのです。そのことを踏まえて図4の例（1）のプロセスをもう1度見てみてください。終了イベントの手前の「結合を表すANDゲートウェイ」がなくてもよいことに気付くと思います。終了イベントではなく、それがタスクならば同期のためにANDゲートウェイが必要ですが、終了イベントも同期を取るのでANDゲートウェイがなくてもよいのです。

　例（1）では、なぜANDゲートウェイを付けたのか。それは単に、XORゲートウェイで分流して非制御フローで合流する、非制御フローで分流してANDゲートウェイで合流する、この2つの記述パターンをぜひとも読者に見てもらいたかったという理由だけです。この2つの記述パターンは、BPMN仕様書のサンプルモデルでも多くの個所で登場するシンプルで使い勝手のよいパターンなのです。

「BPMNを活用したビジネスプロセス・モデリング」バックナンバー