BPMNの排他・並列ゲートウェイの違い：注文確認の例

排他ゲートウェイは一つの経路を選びます。並列ゲートウェイは、出ていくすべての経路を開始します。この違いは、経路が再び合流する場所で特に重要です。排他ゲートウェイによる合流は並行する処理を待ちませんが、並列ゲートウェイによる合流は待ち合わせます。

共有のフローチャート作成ツールで業務を描くときは、ひし形を選ぶ前に業務ルールを書きましょう。ここでは注文の確認を例に、「店頭受け取りか配送か」と「支払いと在庫の確認」が、同じ二本の分岐に見えても異なる動作を必要とする理由を説明します。

ゲートウェイの動作を比べる

BPMNはBusiness Process Model and Notationの略です。ゲートウェイの記号は単なる図形ではなく、プロセスの動作を表します。分岐と合流の意味は、OMGのBPMN仕様で定義されています。

トークンは、プロセスの一回の実行がどこまで進んだかを考えるための概念です。以下では、有効な経路に沿って目印を動かすと考えてください。顧客レコードや在庫の商品を表すものではありません。

Camundaの排他ゲートウェイの説明では、一つの経路を選ぶ動作と、到着したものをそのまま通す合流を扱っています。並列ゲートウェイの説明では、すべての出力経路を開始し、合流時に各入力経路を待つ動作を説明しています。論理上の並行処理は、二人の担当者や二台の機械が厳密に同時刻に作業することを保証するものではありません。

受け取り方法の選択には排他ゲートウェイを使う

受け取り方法が「店頭受け取り」か「配送」のどちらかとして記録済みの注文を考えます。注文を受け付けた後、「受け取り方法は？」と判断します。一方の経路では店頭受け取りの案内を準備し、もう一方では配送情報を準備します。

この注文で実行するのは、どちらか一方だけです。経路に「店頭受け取り」「配送」とラベルを付け、排他ゲートウェイを使います。次の段階に進む前に、排他ゲートウェイで合流させられます。

店頭受け取りの注文を図に沿って追ってみましょう。一つの目印が店頭受け取りの経路を進み、合流点に着いて、そのまま先へ進みます。配送の経路は選ばれていないため、そこからの到着は待ちません。

データが未入力の場合や想定外の値の場合も決めておきます。受け取り方法が選ばれていないときに、意図せず「配送」になってはいけません。確認し直す経路を明示するか、この判断に入る前の条件を整えます。実行可能なモデルでは、条件やデフォルトフローを意図して設定してください。線のラベルだけでは実行ルールになりません。

支払いと在庫の確認には並列ゲートウェイを使う

次に、注文を準備する前に、支払い状況と在庫の両方を確認する場合を考えます。この例では、片方の確認を始めるために、もう片方の結果は必要ありません。並列ゲートウェイで「支払いを確認する」と「在庫を確認する」の両経路を開始します。

合流点では、両方の確認が完了するまで注文を待たせます。支払い確認が先に終われば、その目印は合流点で待ちます。在庫確認も終わると、合流点で二つの到着を消費し、一つの目印を次へ進めます。

完了と承認は同じではありません。在庫確認が完了しても結果は「在庫なし」かもしれず、支払い確認の結果は「未確認」かもしれません。合流後に別の判断を設け、記録された結果を調べます。合流点は完了を待ち合わせるだけで、注文を進めてよいと判断するわけではありません。

この段階を短く表すと、両方の確認を開始する → 両方の結果を待つ → 注文を進めてよいか判断するです。両結果が条件を満たせば注文を準備し、そうでなければ必要な問題解決の作業へ回します。

二つの誤った合流パターンを見分ける

作業自体は正しくても、合流の種類が誤っている図は見落としやすいものです。左右対称できれいかどうかではなく、一つの注文を追って判断しましょう。

これは見た目ではなく、動作の問題です。ひし形の記号を変えるだけで、処理が待ち続けたり、早く進みすぎたり、同じ作業を複数回始めたりする可能性があります。

ただし、「分岐と合流には必ず同じ記号を使う」とだけ覚えないでください。実際のプロセスには、入れ子の判断、ループ、別々に終わる経路もあります。どの到着が実際に合流点へ届くか、次へ進む前に何が必要かを基に合流を選びます。記号をそろえるだけでは、その検討の代わりになりません。

確認が通常どおり終わらない場合を考える

在庫サービスが使えない場合はどうなるでしょうか。その経路を図から消すだけでは、支払い側の目印が合流点で待ち続けます。結果を取得できない場合に「確認完了」とは何を意味するか、決める必要があります。

業務の概要図なら、在庫確認を「不明：要確認」という明示的な結果で終える形もあります。合流後の判断では、不明を在庫ありとみなさず、問題解決へ回します。実行可能なBPMNモデルでは、使用するエンジンと業務要件に合ったエラー、タイムアウト、キャンセル、再試行の処理が必要です。

先に決めるのは、注文全体を待たせるのか、人による確認へ回すのか、中止するのかという業務上の方針です。正式に認められた手順でない限り、確認に失敗した経路を合流点の外へ迂回させ、そのまま「注文を準備する」へつなげてはいけません。待ち合わせを飛ばすと、二つの確認を設けた目的が失われかねません。

Boardmixでチームと経路を追う

Boardmixのキャンバスに、明確に分かれた二つの領域を作ります。一つ目には、店頭受け取りと配送を排他的に選ぶ分岐と合流を置きます。二つ目には、支払いと在庫を並列に確認する分岐と合流、その結果を基にする判断を置きます。

作業名は何をするかが分かる短い表現にし、ゲートウェイの記号と選択経路のラベルを見やすくします。図の下には、手動で経路を追う余白を残します。小さな図形を一つ動かして店頭受け取りの経路をたどり、並列の確認では二つの図形を使います。ボードではロジックを話し合い、実行可能なプロセスはBPMNエンジンで動かします。

Boardmixでボードを開き、実際に確認作業をする人と一緒に例をたどってみましょう。どこで結果が得られない可能性があるか、独立して始められる作業は何か、次の作業までに何を知る必要があるかを考えます。

業務ルールが「該当する確認を一つ以上実行する」なら、単純な排他選択でも、無条件の並列分岐でも十分には表せません。そのルールを明示し、適切な条件付き分岐のモデルを検討します。二本の矢印を描くだけでは、一方か両方か、条件によって異なる組み合わせかは決まりません。