ビジュアルパラダイムによるBPMNガイド

1. BPMNとは何か

業務プロセスモデルと記法（BPMN）は、業務がプロセスを通じてどのように移動するかを記述するための標準化された視覚的言語です。これは、ビジネス関係者、アナリスト、および技術チームが、一貫した記号を使用して同じワークフローについて議論することを支援します。BPMNはオブジェクト管理グループによって維持されており、BPMN 2.0.2はISO/IEC 19510として公開されています。

BPMN図は単なるフローチャート以上のものです：その記号には定義された意味があり、接続ルールはプロセスの流れと参加者間のメッセージを区別します。有用なモデルは、現在のプロセス（「現状」）を文書化し、提案されたプロセス（「将来像」）を明確にし、チームが遅延、引き渡し、手直し、または見逃された例外パスを特定するのを支援できます。

2. BPMNの核心概念

BPMNの主要な構成要素は、フローオブジェクト、接続オブジェクト、スイムレーン、データ、およびアーティファクトです。

イベント

イベントの輪郭とマーカーは、その役割とトリガーを伝えます：

• 開始イベント：プロセスパスを開始します。

• 中間イベント：プロセス中に発生します。例えば、メッセージの受信やタイマーの期限切れなどです。

• 終了イベント：パスを終了します。異なる終了イベントタイプは、正常な完了やエラーなど、異なる結果を示すことができます。

• 境界イベント：アクティビティやサブプロセスに付随し、タイムアウトなど、それを中断または影響を与えるイベントを示します。

次の場合に「メッセージイベント」を使用します。プロセスが通信に応答する場合、また「タイマーイベント」を、期限などタイミングがプロセスルールの一部となる場合に使用します。

アクティビティ

アクティビティには明確な「動詞 + 目的語」形式で名前を付けます。例えば、「在庫確認」、「支払い承認」、「確認送信」などを使用します。次を使用します：

• タスクを単一のステップに使用します。

• サブプロセスを、ステップが個別にモデル化できる十分な詳細を持つ場合に使用します。

• 呼び出しアクティビティを、グローバルに定義されたプロセスを再利用する場合に使用します（モデル化のアプローチがそれをサポートする場合に限ります）。

一般的なタスクマーカーは、ユーザー実行、手動、または自動化された作業など、作業の種類を指定できます。読者や実装に役立つ場合のみ、そのような詳細を追加してください。

ゲートウェイ

プロセスロジックに基づいてゲートウェイを選択してください。描きたい形状だけでなく、です：

• 排他的（XOR）： 出力パスのいずれかを選択します。例：「在庫あり？」→ はいまたはいいえ。

• 並列（AND）： すべての出力パスを開始します。対応する結合は、必要なすべてのパスが完了するまで待機できます。

• 包括的（OR）： 条件に応じて、1 つ以上の出力パスを選択します。

• イベントベース： 次のパスは、どのイベントが最初に発生するかによって決定されます。例えば、支払い応答またはタイムアウトなど。

出力する意思決定フローに条件をラベル付けします。例：はい / いいえ または 承認 / 却下 ゲートウェイがフローを分割する場合、結合ロジックを明確にしてください。排他的な結合は代替パスを再び統合し、並列結合は並列に開始されたパスを同期させます。

オブジェクトとプールの接続

「シーケンスフロー はプロセスの順序を示し、通常は1つのプール内に留まります。「メッセージフロー は、独立したプール間の通信を示します。例えば、顧客が企業に注文を送信する場合などです。メッセージフローを使用して次の内部タスクを示したり、シーケンスフローを使用して独立した参加者間の通信を描いたりしないでください。

プールは、顧客、企業、支払いプロバイダーなど、独立した参加者を表すことができます。プール内のレーンは、役割や部署を示します。責任の境界を意味のあるものに保ってください。レーンは、誰が作業を行うかを明確にするべきであり、単に図を装飾するものではありません。

3. 実践的なモデリングワークフロー

1. スコープを設定する。 プロセスのトリガー、結果、および境界を明確にします。例：「注文の受領から出荷の確認まで」

2. 参加者と役割を特定する。 どの参加者が独立したプールを必要とし、どの責任がレーンに属するかを決定します。

3. ハッピーパス（通常の成功パス）を記述する。 ゲートウェイや例外パスを追加する前に、通常のステップを順序立ててリストアップします。

4. イベントと意思決定を追加する。意味のあるトリガー、結果、ビジネスルール、および代替パスを表示します。

5. 引き継ぎとデータを追加します。理解を深める場合に、参加者間の通信や必要な情報、生成される情報をマークします。

6. 完全性を確認します。開始から終了までの各パスを追跡します。ゲートウェイに理解可能な条件があることを確認し、例外パスが曖昧に消滅しないことを確認します。

7. プロセスユーザーとレビューを行います。作業を実行する人々や作業を受け取る人々とモデルを検証します。実際の運用と異なる場合は修正します。

8. 図を読みやすく保ちます。一貫した命名を使用し、線の交差を最小限に抑え、必要に応じて詳細なサブプロセスを別の図に移動します。

ビジネスの問いに答えるモデルから始めます。すべての BPMN 記号や実装詳細を一度に追加すると、図のレビューが難しくなることが多いです。

4. 例：オンライン注文の履行

範囲：顧客からの注文提出から出荷確認まで。この例は会社のプロセスに焦点を当て、受信する注文と送信する確認を示すために、顧客プールを別に使用しています。

プロセスの物語

1. 顧客が注文を提出します。

2. 会社は注文を受け取り、在庫を確認します。

3. 商品が利用できない場合、会社は顧客に通知し、その注文パスを終了します。

4. 商品が利用可能な場合、会社は支払い処理を行います。

5. 支払いが拒否された場合、会社は顧客に通知し、そのパスを終了します。

6. 支払いが承認された場合、倉庫が注文をピッキングして梱包します。

7. 会社は荷物を運送業者に引き渡し、出荷確認を送信します。

テキスト図

顧客プール:
(開始) → 注文提出 ──メッセージ──▶

会社プール:
(メッセージ開始：注文受信)
  → 在庫確認
  → XOR: 在庫あり？
      いいえ → 顧客に通知：利用不可 → (終了)
      はい → 支払い処理
             → XOR: 支払い承認？
                 いいえ → 顧客に通知：支払い拒否 → (終了)
                 はい → 注文ピッキングおよび梱包
                         → 荷物を運送業者に引き渡し
                         → 出荷確認を送信 ──メッセージ──▶ 顧客
                         → (終了)

BPMN カスタム PlantUML コード (VPasCode エディタのみサポート)

@startuml
title 注文履行ビジネスプロセス図
<style>
    element { MaximumWidth 160 }
    start   { Backgroundcolor #00695C }
    stop    { Backgroundcolor #C2185B }
    activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
    diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
    arrow   { LineColor #424242; Fontcolor #000000 }
    swimlane{ Fontcolor #000000; FontSize 14 }
</style>

|#F0F8FF|顧客|
start
:<<SendTask>>
注文提出;

|#E8F5E9|会社|
:<<ReceiveTask>>
注文受信;
:<<UserTask>>
在庫確認;
if (在庫あり？) then (はい)
  :<<ServiceTask>>
  支払い処理;
  if (支払い承認？) then (はい)
    :<<ManualTask>>
    注文ピッキングおよび梱包;
    :<<SendTask>>
    荷物を運送業者に引き渡し;
    :<<SendTask>>
    出荷確認を送信;
  else (いいえ)
    :<<SendTask>>
    顧客に通知：支払い拒否;
  endif
else (いいえ)
  :<<SendTask>>
  顧客に通知：利用不可;
endif
stop
@enduml

使用シーケンスフローは社内の手順に、メッセージフローは顧客と企業のプール間で使用します。各XORゲートウェイの出力フローには、その条件をラベル付けします。Visual Paradigmでは、「在庫あり？」や「支払い承認済み？」という質問をゲートウェイのラベルとして配置でき、出力矢印には「はい」と「いいえ」を記載できます。

可能な拡張機能：支払い期限がある場合は、支払い処理にタイマー境界イベントを追加します。キャリアの引き渡し失敗に対する例外パスを追加するか、ピッキングやパッキングに独自の詳細なワークフローが必要な場合は、それをサブプロセスとしてモデル化します。

5. Visual Paradigmでのモデル構築

Visual ParadigmはBPMN 2.0モデリングツールを提供し、サブプロセスのドリルダウンをサポートしているため、高レベルのプロセスをより詳細なプロセス図にリンクできます。そのBPMN機能には、作業手順の文書化や現状（as-is）および将来像（to-be）のプロセスモデリングも含まれています。

実践的な構築手順：

1. 作成するBPMNビジネスプロセス図をVisual Paradigmで作成します。

2. 追加する顧客プールと企業プールを追加します。顧客サービス、倉庫、出荷など、責任が重要な場合は、企業プールをレーンに分割します。

3. 開始イベントとアクティビティを配置し、在庫ゲートウェイと支払いゲートウェイを追加します。

4. 企業プール内ではシーケンスフローを描画し、顧客とのやり取りにはメッセージフローを使用します。

5. タスクと条件付きパスは平易な言葉でラベル付けします。注文や支払い結果などのデータオブジェクトは、読者がプロセスを理解するのに役立つ場合のみ追加します。

6. メインフローが一貫して読みやすいように（通常は左から右へ）、図を配置し、交差するコネクタを最小限に抑えます。

7. ステークホルダーと図を確認します。ある手順の詳細がメインパスを隠してしまう場合は、その詳細をサブプロセス図に配置することを検討してください。

8. モデルをチームに適した形式とワークスペースで保存し、共有します。

Visual Paradigmは、BPMN図モデリング、プロセスのドリルダウン、作業手順の文書化、およびas-is/to-beモデリングを謳っています。特定の機能の利用可否はエディションによって異なる場合があります。

6. 一般的なモデリングの誤り

• 間違ったコネクタの使用：シーケンスフローは内部プロセスの順序を示し、メッセージフローは参加者間の通信を示します。

• 明確なロジックなしにゲートウェイを使用する：分岐とその出力条件にラベルを付ける。

• すべてのアクションを独立したプールとして扱う：1 つの参加者内の責任にはレーンを使用し、異なる参加者には別々のプールを使用する。

• 経路を不明確にしておく：却下、タイムアウト、情報不足、およびその他の関連する例外で何が起こるかを明示する。

• 1 つの図に情報を詰め込みすぎる：詳細な作業と概要を分離するためにサブプロセスを使用する。

• 現実ではなく理想をモデル化する：改善案を提案する前に、現在のプロセスを正確に文書化する。

• 目的なく詳細を追加する：モデル化やレビューの質問に答える場合にのみ、データ、イベント、タスクリストを含める。

7. 迅速なレビューチェックリスト

• 各関連パスに明確な開始点と終了点があるか？

• 読者が各アクティビティを実行する担当者を特定できるか？

• 分岐と出力条件は明確か？

• シーケンスフローとメッセージフローが適切に使用されているか？

• 例外や代替結果が表現されているか？

• 図は意図された表示サイズで読みやすいか？

• プロセスを実行する人々が、その正確性を確認したか？