ビジネスプロセスモデルと記法、または「BPMN」は、作業がどのように行われるかを記述するための標準化された視覚的言語です。これにより、ビジネスアナリスト、マネージャー、開発者、およびプロセス関係者は、長大な書面の手順に頼ることなく、同じプロセスを理解することができます。
BPMN ダイアグラムは、4 つの主要なカテゴリから構成されています：
-
フローオブジェクト：イベント、アクティビティ、およびゲートウェイ
-
接続オブジェクト：シーケンスフロー、メッセージフロー、および関連付け
-
スイムレーン：プールとレーン
-
アーティファクト：データオブジェクト、グループ、およびテキスト注釈
このガイドでは、最も重要なカテゴリである「BPMN フローオブジェクト」に焦点を当てています。フローオブジェクトは、プロセスで何が起こるか、どのような作業が行われるか、そしてプロセスがどのように一つのパスから別のパスへ移動するかを記述します。
1. BPMN フローオブジェクトとは何ですか？
フローオブジェクトは、BPMN プロセスダイアグラムの中心的な要素です。これらはシーケンスフローによって接続され、プロセスの動作を表します。
3 つの種類があります：
| フローオブジェクト | 基本形状 | 主な目的 |
|---|---|---|
| イベント | 円 | 発生する事象 |
| アクティビティ | 角丸長方形 | 実行される作業 |
| ゲートウェイ | 菱形 | 分岐、分割、統合、または同期ポイント |
単純なプロセスは概念的には次のように見えるかもしれません：
開始イベント → 活動 → ギャウェイ → 活動 → 終了イベント
例えば：
注文受領 → 在庫確認 → 商品はありますか？
├── はい → 注文発送
└── いいえ → 顧客に通知
形状は単純ですが、その内部の記号は追加の意味を提供します。
2. イベント：起こる出来事
「イベント」はプロセスの進行中に起こる何かを表します。アクティビティとは異なり、イベントは人またはシステムによって行われる作業ではありません。プロセスをトリガーしたり、アクティビティを中断したり、条件を示したり、プロセスがどのように終了するかを示したりする可能性があります。
イベントは円で示されます。境界線はイベントがプロセス内でどこで発生するかを示します：
| イベントの種類 | 境界線の外観 | 意味 |
|---|---|---|
| 開始イベント | 細い単一の線 | プロセスがどのように始まるかを示す |
| 中間イベント | 二重線 | 開始と終了の間で発生する |
| 終了イベント | 太い単一の線 | プロセスパスがどのように終了するかを示す |
開始イベントは、受信メッセージやスケジュールされた時間などのトリガーを検出できます。中間イベントは何かを待機したり送信したりする可能性があります。終了イベントは、プロセスパスの最終結果を生成します。
2.1 開始イベント
「開始イベント」は、プロセスまたはサブプロセスを開始するトリガーを示します。
細い境界線を持つ円で描かれます。
一般的な例には以下が含まれます：
-
顧客が注文を提出する
-
従業員が休暇申請を提出する
-
タイマーが予定日付に達する
-
メッセージが到着する
-
システムが条件を検出する
-
新しいケースが作成される
なし開始イベント
単純な開始円は、プロセスが特定のトリガーを明示的にモデル化せずに開始することを意味します。
○
例：
○ → 申請書の審査
正確なトリガーが不明、無関係、または意図的に一般化されている場合は、なし開始イベントを使用してください。
メッセージ開始イベント
開始イベント内のメッセージ記号は、メッセージが受信されたときにプロセスが開始することを示します。
例：
◉ 封筒記号 → 顧客リクエストの処理
典型的な使用例：
-
メールの受信
-
APIリクエストの受信
-
注文書の受信
-
他の参加者からのリクエストの受信
タイマー開始イベント
開始イベント内の時計は、プロセスがスケジュールまたは日付に従って開始することを示します。
例：
-
毎月請求書の生成を開始する
-
有効期限の30日前に更新プロセスを開始する
-
毎日の照合プロセスを実行する
条件付き開始イベント
条件付き開始イベントは、ビジネス条件が真になったときに開始します。
例：
在庫レベルが再発注点を下回る
シグナル開始イベント
ブロードキャストシグナルが受信されると、シグナル開始イベントが始まります。メッセージとは異なり、シグナルは通常、特定の1人の受信者向けではありません。
例：
「緊急閉鎖」シグナルを受信 → すべての支店を閉鎖
複数開始イベント
複数開始イベントは、複数の異なるトリガーが同じプロセスを開始できることを示します。
例えば、サポートケースは以下の場合に開始されることがあります：
-
顧客がウェブフォームを提出する
-
エージェントがケースを手動で入力する
-
自動監視システムが問題を検出する
2.2 中間イベント
「中間イベント」は、プロセスが開始された後、終了する前に発生します。プロセスを一時停止する、何かを待つ、メッセージを送信する、例外パスを作成する、または条件に応答することができます。
二重の境界線で描画されます。
中間イベントは以下の種類があります：
-
捕捉型：何かを待機する、または受信する
-
放出型：何かを送信する、または生成する
捕捉型イベントは通常、空またはアウトラインのマーカを持ち、放出型イベントは通常、塗りつぶされたマーカを使用します。
タイマー中間イベント
タイマーイベントは、遅延、期限、期間、または定期的なスケジュールを表します。
例：
-
3営業日待つ
-
特定の日付まで待つ
-
24時間以内に返信がない場合はエスカレーションする
-
プロセスがアクティブな間、定期的なアクションを実行する
例：
見積もりを送信 → 3 日間待機 → 返信を確認
メッセージ中間イベント
メッセージ中間イベントは、メッセージを待機するか、メッセージを送信します。
例：
承認リクエストを送信 → 承認応答を待機
メッセージイベントは、プロセスが他の参加者、部署、組織、またはシステムと相互作用する際に特に有用です。
エラー中間イベント
エラーイベントは、通常のフローに影響を与えるエラー状態を表します。
これは、アクティビティまたはサブプロセスに付随する境界イベントとして一般的に使用されます。
例：
支払い処理
│
└── エラー → 支払い失敗への対応
エスカレーション中間イベント
エスカレーションイベントは、技術的な失敗を必ずしも表すものではないが、問題がより高いレベルでの対応を必要とすることを示します。
例：
顧客苦情の解決
│
└── エスカレーション → 監督者のレビュー
条件付き中間イベント
条件付きイベントは、指定された条件が真になるまで待機します。
例：
顧客アカウントが確認されるまで待機
シグナル中間イベント
シグナルイベントは、複数のプロセス参加者に関連する可能性のあるシグナルをブロードキャストまたは受信します。
例：
製品回収シグナルのブロードキャスト
リンク中間イベント
リンクイベントは、ページ全体にわたって長いシーケンスフロー線を引かずに、同じプロセス図内の2つの遠隔点を接続します。
リンクイベントは慎重に使用してください。図の可読性を向上させることができますが、過剰な使用はプロセスを追跡しにくくする可能性があります。
補償中間イベント
補償イベントは、以前のアクティビティを元に戻すか補償するための是正作業を開始します。
例：
ホテル予約のキャンセル
補償は通常のエラーパスとは異なります。補償は、完了した作業の取り消しまたは補正に特に関与します。
2.3 境界イベント
A境界イベントは、アクティビティまたはサブプロセスの縁に直接接続されています。これは、そのアクティビティが進行中に発生しうる何かを表します。
例：
┌────────────────────┐
│ 申請処理 │
└────────────────────┘
○
│
└── タイムアウト → 昇格処理
境界イベントは、以下のモデル化に役立ちます：
-
タイムアウト
-
キャンセル
-
エラー
-
昇格
-
受信メッセージ
-
補償
-
外部シグナル
中断型境界イベント
中断型境界イベントは、発生した際に接続されたアクティビティを停止します。
例：
支払い処理
│
└── 支払いエラー → 障害対応
エラーが発生すると、支払いアクティビティは終了します。
非中断型境界イベント
非中断型境界イベントは、元のアクティビティが継続する間に追加のパスを開始します。
通常、点線の枠で表示されます。
例：
申請処理
│
└── タイマーリマインダー → リマインダー送信
リマインダーパスが実行されている間、申請プロセスは継続します。
この区別は重要です：
| 境界イベントの種類 | 接続されたアクティビティへの影響 |
|---|---|
| 中断型 | アクティビティを停止する |
| 中断しない | アクティビティを継続する |
2.4 終了イベント
「終了イベント」はプロセスパスの終了を示します。太い境界線を持つ円で描かれます。
プロセスには複数の終了イベントが存在する可能性があります。これは、異なる結果がプロセスを終了させる可能性があるためです。
例:
-
注文完了
-
リクエスト拒否
-
支払い失敗
-
ケースキャンセル
-
顧客に通知
-
補償付きプロセス完了
なし終了イベント
通常の終了イベントは、特定の結果を指定せずにパスが終了したことを示します。
●
メッセージ終了イベント
メッセージ終了イベントは、プロセスが終了したときにメッセージを送信します。
例:
注文承認 → 確認送信 → メッセージ終了
エラー終了イベント
エラー終了イベントは、エラーを上位レベルのプロセスまたはハンドラーにスローすることでプロセスを終了します。
他の場所で処理する必要があるプロセスレベルの失敗条件に使用してください。
エスカレーション終了イベント
エスカレーション終了イベントは、現在のプロセスパスを終了し、エスカレーションが発生したことを伝達します。
終了（ターミネート）終了イベント
ターミネート終了イベントは、他のアクティブなパスも含めて、プロセスインスタンス全体を即座に終了します。
これは通常の終了イベントよりも強力です。残りのすべての作業を停止する必要がある場合に使用すべきです。
補償終了イベント
補償終了イベントは、プロセスパスが終了する前に補償アクティビティを開始します。
3. アクティビティ：実行される作業
「アクティビティ」は、個人、チーム、システム、または自動化されたサービスによって実行される作業を表します。アクティビティは角丸長方形として描画されます。
例は以下の通りです：
-
申請書の審査
-
請求書の承認
-
確認の送信
-
顧客情報の検証
-
送料の計算
-
アカウントの更新
-
レポートの生成
アクティビティは、時間、労力、コスト、責任が集中する場所を示すため、BPMNダイアグラムの運用上の骨格を形成します。
3.1 アクティビティの名付け
適切なアクティビティ名は通常、以下のパターンに従います：
動詞 + 目的語
例：
-
申請書の審査
-
請求書の承認
-
顧客レコードの作成
-
支払いの検証
-
確認メールの送信
以下のような曖昧な名前は避けてください：
-
処理
-
リクエストの処理
-
ステップ 1
-
その他の作業
-
管理
明確なアクティビティ名は、アクションとその対象を記述すべきです。
| 弱い名前 | より良い名前 |
|---|---|
| 処理中 | 支払い処理 |
| レビュー | 申請のレビュー |
| 顧客ステップ | 顧客本人確認 |
| メール | 承認メールを送信 |
| 更新 | 注文ステータスの更新 |
タスクは通常、これ以上分解できない、または分解すべきでない作業の単一単位を表します。サブプロセスは、関連するアクティビティの集合を表します。
3.2 タスク
Aタスクは最も単純な種類のアクティビティです。これは単一の作業単位を表します。
基本タスクは角丸四角形で示されます：
╭────────────────────╮
│ 申請のレビュー │
╰────────────────────╯
タスクには、実行されている作業の種類を識別するマーカーが含まれる場合があります。
ユーザータスク
ユーザータスクは、人間がシステムまたはアプリケーションを使用して実行します。
例：
-
経費精算書の承認
-
顧客情報の入力
-
契約書のレビュー
-
サポートケースの割り当て
手動タスク
手動タスクは、ビジネスプロセスエンジンまたはアプリケーションの支援なしに、人が実行します。
例：
-
機器を検査する
-
紙の文書に署名する
-
物理的な製品を梱包する
-
文書を直接手渡す
サービスタスク
サービスタスクは、システム、アプリケーション、Webサービス、またはAPIによって自動的に実行されます。
例：
-
信用スコアを取得する
-
自動メールを送信する
-
税金を計算する
-
データベースレコードを作成する
-
決済サービスに呼び出しを行う
スクリプトタスク
スクリプトタスクは、プロセス環境内でスクリプトまたはコードの断片を実行します。
例：
-
データを変換する
-
値を計算する
-
メッセージをフォーマットする
-
単純なデータルールを適用する
ビジネスルールタスク
ビジネスルールタスクは、ルールエンジンを通じてビジネスルールを評価します。
例：
-
与信限度額を決定する
-
保険料を計算する
-
注文が送料無料の対象かどうかを決定する
-
承認レベルを決定する
送信タスク
送信タスクは、メッセージを他の参加者またはシステムに送信します。
例：
-
請求書の送信
-
注文確認の送信
-
倉庫への通知送信
タスクの受信
受信タスクは、他の参加者またはシステムからのメッセージを待機します。
例：
-
署名済み契約書の受信
-
支払い確認の受信
-
配送状況の受信
3.3 サブプロセス
「サブプロセス」は、より詳細なプロセスを含むアクティビティです。
2つの方法で表示できます：
-
折りたたみサブプロセス：プラス記号付きの角丸長方形
-
展開サブプロセス：内部フローを表示するより大きな角丸長方形
複数のタスクが関連しており、すべてを表示すると高レベルの図が詳細になりすぎる場合は、サブプロセスを使用してください。
例：
╭──────────────────────────────╮
│ + 顧客オンボーディング完了│
╰──────────────────────────────╯
サブプロセスには以下が含まれる可能性があります：
情報収集
↓
本人確認
↓
アカウント作成
↓
ウェルカムメッセージ送信
サブプロセスの使用タイミング
以下の場合に使用してください：
-
一連のステップに明確なビジネス目的がある場合
-
そのグループが概念的に再利用可能である場合
-
メイン図が混雑し始めている場合
-
利害関係者が要約と詳細の両方のビューを必要とする場合
-
内部プロセスに独自の開始、終了、例外、または意思決定ロジックがある場合
埋め込みサブプロセス
埋め込みサブプロセスは、親プロセス内部で定義され、そのプロセスの流れの一部となります。
呼び出しアクティビティ
呼び出しアクティビティは、別途定義された再利用可能なプロセスまたはグローバルタスクを呼び出します。
同じプロセスロジックが複数の場所から呼び出される場合に使用します。例：
顧客本人確認
顧客確認が複数のビジネスプロセスに登場する場合、その内部ステップをすべて複製するよりも、再利用可能な呼び出しアクティビティの方が適切である場合があります。
イベントサブプロセス
イベントサブプロセスは、親プロセスまたはサブプロセスがアクティブな間に開始イベントによって起動されます。キャンセルリクエスト、緊急のエスカレーション、または受信された更新など、例外または並列的な状況を処理するのに役立ちます。イベントサブプロセスは、中断型または非中断型のいずれかになります。
例：
メインプロセス：注文履行
イベントサブプロセス:
キャンセルリクエスト → 履行キャンセル → 顧客への返金
3.4 アクティビティマーカー
アクティビティには、その動作に関する情報を追加する小さなマーカーが含まれる場合があります。
ループマーカー
ループマーカーは、アクティビティが条件が満たされるまで繰り返されることを示します。
例：
ドキュメントレビュー
↻
以下のようなアクティビティに使用します：
-
承認されるまでレビューする
-
成功するまで配送を試みる
-
顧客に連絡が取れるまで連絡する
並列マルチインスタンスマーカー
これは、同じアクティビティの複数のインスタンスが同時に実行されることを示します。
例：
3 つの承認を取得する
このアクティビティは、複数のレビューヤーによって同時に実行される場合があります。
逐次マルチインスタンスマーカー
これは、複数のインスタンスが順番に実行されることを示します。
例：
アイテムを1つずつレビューする
補償マーカー
これは、以前に完了した作業を補償するために使用されるアクティビティを識別します。
例：
顧客への返金
アドホックマーカー
アドホックサブプロセスは、チルダのようなマーカーで表されます。これは、サブプロセス内のアクティビティが、1 つの固定された順序に従うのではなく、柔軟または緩やかな構造の順序で実行される可能性があることを示しています。
4. ゲートウェイ：分岐、分割、および統合
Aゲートウェイプロセスフローがどのように分岐または収束するかを制御します。ゲートウェイは菱形として描かれます。
ゲートウェイは通常、タスクではありません。それ自体で意思決定の作業を実行するわけではありません。代わりに、意思決定、条件、またはイベントが評価された後にプロセスフローがどのように制御されるかを示します。
例：
申請書の審査 → 申請書は完了していますか？
審査アクティビティは情報を収集または評価します。その後、ゲートウェイは結果に基づいてプロセスをルーティングします。
ゲートウェイは以下を行うことができます：
-
1 つのパスを複数のパスに分割する
-
複数のパスを 1 つに統合する
-
並行作業を同期する
-
1 つ以上のイベントを待機する
-
条件またはルールに基づいて作業をルーティングする
4.1 排他的ゲートウェイ：XOR
A排他的ゲートウェイちょうど 1 つの出力パスを選択します。
通常は「X」を含む菱形として表示されますが、一部の図ではマーカーが省略されることもあります。
例：
┌── 承認 → アカウント作成
申請書チェック ─◇
└── 却下 → 却下通知を送信
1 つのパスのみが追跡されます。
一般的な用途：
-
支払いが承認された場合は続行し、そうでない場合は却下する
-
顧客が対象となる場合は、割引を提供してください
-
リクエストが完了している場合は処理し、そうでない場合は返却してください
出力パスには通常、明確な条件またはラベルを付与する必要があります:
-
承認済み
-
却下
-
完了
-
未完了
-
金額 > 10,000 ドル
-
金額 ≤ 10,000 ドル
排他的マージ
排他的ゲートウェイは、代替パスを1つのパスに統合することもできます。代替パスのいずれか1つしか選択されていないため、すべてのパスを待機しません。
デフォルトフロー
指定された条件のいずれも真でない場合、デフォルトパスを使用できます。
例:
承認済み
却下
デフォルト → 手動レビュー
デフォルトパスは、予期しないまたは分類されていないケースに役立ちます。
4.2 並列ゲートウェイ: AND
A並列ゲートウェイプロセスを並行して実行される複数のパスに分割します。
プラス記号を含むダイヤモンドで表されます。
例:
┌── 請求書作成 ──┐
注文承認 ─◇ ◇── 注文出荷
└── 在庫確保 ┘
両方のアクティビティが開始され、プロセスは後に両方の完了を待機する場合があります。
並列分割
並列分割は、すべての出力パスを開始します。
条件に関係なくすべてのアクティビティが発生する必要がある場合に使用してください。
例:
-
確認を送信し、在庫を更新する
-
財務部門に通知し、運営部門に通知する
-
セキュリティチェックと不正チェックを実施する
並列結合
並列結合は、すべての入力パスが完了するまで待機してから続行します。
これは時折、同期と呼ばれます。
請求書作成 ──┐
◇── 注文履行
在庫確保 ┘入力ブランチのいずれかが遅延した場合、結合はそれを待機します。
4.3 包括ゲートウェイ：OR
「包括ゲートウェイ」は、どの条件が真であるかによって、1 つ以上の出力パスを選択します。
これは、円を含むダイヤモンドで表されます。
例：
顧客が対象となる割引：
- 標準割引
- ロイヤルティ割引
- プロモーション割引複数の条件が満たされた場合、複数の割引関連アクションが選択される可能性があります。
包括ゲートウェイを使用するのは、以下の時です：
-
1 つ以上の条件が真である可能性がある
-
複数のパスが同時に実行できる
-
すべての選択されたパスが完了した後にプロセスを続行する必要がある
排他的ゲートウェイとは異なり、包括ゲートウェイは必ずしも1つのパスのみを選択するわけではありません。並列ゲートウェイとは異なり、すべてのパスを選択するわけではありません。
4.4 イベントベースゲートウェイ
「イベントベースゲートウェイ」は、最初に発生したイベントに応じてプロセスをルーティングします。
通常、中間イベントの捕捉または受信タスクが続きます。
例：
見積もり送信 → イベントベースゲートウェイ
├── メッセージ受信 → 受諾処理
└── タイマー期限切れ → 通知送信最初に発生したイベントのみがパスを決定します。
プロセスが既知のビジネス条件を評価するのではなく、外部の動作を待機している場合にイベントベースゲートウェイを使用します。例えば、プロセスは顧客からの応答またはタイムアウトのいずれかを待機する可能性があります。
イベントベースゲートウェイと排他的ゲートウェイの違い
| 質問 | 排他的ゲートウェイ | イベントベースゲートウェイ |
|---|---|---|
| 経路を決定するのは何ですか？ | 条件またはビジネスルール | 最初に発生するイベント |
| 典型的な質問 | 「リクエストは承認されましたか？」 | 「何が最初に起こりますか？」 |
| 一般的な後続要素 | アクティビティまたはシーケンスフロー | キャッチイベントまたは受信タスク |
| 意思決定の源泉 | データまたはロジック | 外部イベント |
4.5 複合ゲートウェイ
A 複合ゲートウェイは、標準的なゲートウェイタイプでは明確に表現できない高度なルーティングロジックを処理します。
例は以下の通りです：
-
3 つの承認のうち少なくとも 2 つが受信されたら続行する
-
条件の複雑な組み合わせに基づいて経路を選択する
-
カスタムルールに従って選択された経路を同期する
複合ゲートウェイは控えめに使用するべきです。多くの場合、いくつかの単純なゲートウェイまたは明確に名付けられたビジネスルールタスクの方が理解しやすく、保守しやすいです。
4.6 イベントベースゲートウェイのバリエーション
BPMN は、以下のイベントベースゲートウェイのバリエーションもサポートしています：
-
排他的イベントベースゲートウェイ
-
並列イベントベースゲートウェイ
-
インスタンス化イベントベースゲートウェイ
並列イベントベースゲートウェイは複数のイベント条件を待機できるのに対し、排他的イベントベースゲートウェイは最初に発生したイベントに基づいて進行します。正しいバリエーションは、プロセスが単一のイベントを待機しているのか、それともイベントの組み合わせを待機しているのかによって異なります。
5. フローオブジェクトの連携方法
BPMN ダイアグラムの意味は、イベント、アクティビティ、ゲートウェイ、およびシーケンスフロー間の関係性から生まれます。
注文プロセスを例に考えてみましょう：
開始
↓
注文受領
↓
在庫確認
↓
商品はあるか？
├── はい → 注文梱包 → 注文発送 → 終了
└── いいえ → 顧客に通知 → 終了
この例には次の要素が含まれています：
-
1 つの開始イベントで、プロセスを開始します
-
受領、確認、梱包、発送、および通知のためのアクティビティ
-
1 つの排他的ゲートウェイで、1 つの経路を選択します
-
2 つの終了イベントまたは、異なる結果を表す終了経路
より高度なバージョンは以下のようになるかもしれません：
開始
↓
注文受領
↓
在庫確認
↓
商品はあるか？
├── いいえ → 顧客に通知 → 終了
└── はい → 並列ゲートウェイ
├── 在庫確保
├── 請求書作成
└── 不正チェック
↓
並列結合
↓
注文発送
↓
終了
ここでは：
-
排他的ゲートウェイは、履行を継続できるかどうかを決定します。
-
並列ゲートウェイは、3 つのアクティビティを開始します。
-
並列結合は、3 つのアクティビティすべてが完了するまで待機します。
-
発送は、同期が完了してからのみ開始されます。
6. イベント、アクティビティ、およびゲートウェイ：簡単な比較
| 要素 | 重要な質問 | 例 |
|---|---|---|
| イベント | 何が起きたか、または何が起きるか？ | 支払い受領 |
| アクティビティ | どのような作業が行われるか？ | 支払いを確認する |
| ゲートウェイ | プロセスはどの経路を取るべきですか？ | 支払いは有効ですか？ |
有用なルールは次の通りです：
-
イベントが発生する
-
アクティビティが実行される
-
ゲートウェイが経路を制御する
どの記号を使用するか不明な場合は、次のように問い合わせてください：
-
これは作業として扱われない発生事象ですか？「イベント」を使用してください.
-
誰かが、または何かが行動を実行していますか？「アクティビティ」を使用してください.
-
プロセスが分岐、結合、またはルーティング条件を待機していますか？「ゲートウェイ」を使用してください.
7. フローオブジェクトの正しい接続
フローオブジェクトは異なる種類の線で接続されます。間違ったコネクタを使用すると、図が誤解を招く可能性があります。
7.1 シーケンスフロー
「シーケンスフロー」は、矢印付きの実線です。これは、同じプロセス内でフローオブジェクトが実行される順序を示します。
アクティビティ A → アクティビティ B
シーケンスフローを使用して接続するもの：
-
イベントからアクティビティへ
-
アクティビティからゲートウェイへ
-
ゲートウェイからアクティビティへ
-
アクティビティから終了イベントへ
シーケンスフローは通常、独立したプールの境界を横切ってはなりません。
7.2 メッセージフロー
「メッセージフロー」は、開いた矢頭を持つ点線で表されます。これは、独立した参加者間またはプール間の通信を表します。
例：
-
顧客が注文を販売者に送信する
-
販売者が確認を顧客に送信する
-
銀行が支払い結果を販売店に送信する
メッセージフローは、内部プロセスの順序を示すためではなく、通信のために使用してください。
7.3 関連付け
「関連付け」は、アーティファクト、注釈、またはデータ表現をフローオブジェクトに接続するために使用される点線です。
例：
-
ドキュメントをタスクに添付する
-
テキスト注釈をアクティビティにリンクする
-
タスクがデータオブジェクトを使用していることを示す
接続オブジェクトの3つの主要なタイプは、シーケンスフロー、メッセージフロー、および関連付けです。
8. プールとレーン
プールとレーンはフローオブジェクトではありませんが、各アクティビティを実行する主体を理解するために不可欠な文脈を提供します。
プール
プールは、プロセスにおける参加者を表します。
例：
-
顧客
-
サプライヤー
-
銀行
-
企業
-
政府機関
-
外部システム
プールは、プロセス全体を含めることも、内部の詳細を示さないブラックボックスの参加者として表示することもできます。
レーン
レーンは、責任、役割、部署、システム、または場所に基づいてプールを分割します。
例：
-
カスタマーサービス
-
財務
-
倉庫
-
マネージャー
-
支払いシステム
レーンは、次の質問に答えるのに役立ちます：
この活動の責任者は誰ですか？
また、引き継ぎ、遅延、重複作業、および不明確な所有権を明らかにすることもできます。
9. データオブジェクトおよびその他のサポート要素
データオブジェクトはフローオブジェクトではありませんが、活動によって使用、作成、または変更される情報に関する有用な文脈を提供します。
例：
-
申請書
-
請求書
-
発注書
-
顧客記録
-
承認書
-
配送ラベル
データオブジェクトは、以下のように活動に接続されることがあります：
申請書 → 申請の審査
データオブジェクトは関連する情報を特定しますが、プロセスによって処理されるすべてのデータ項目を必ずしも表すわけではありません。
その他のサポート要素には以下が含まれます：
-
データストア： データが保存される永続的な場所
-
テキスト注釈： 解説ノート
-
グループ：関連要素の視覚的整理
-
関連付け:支援要素とフローオブジェクト間のリンク
10. プロセスモデリングのための段階的アプローチ
ステップ 1: プロセスの範囲を定義する
プロセスの開始点と終了点を決定する。
例:
開始: 顧客が注文を提出する
終了: 注文が出荷されるか拒否される
1 つの図に組織全体をモデル化しないようにする。
ステップ 2: 参加者を特定する
関与する人、部署、システム、または組織をリストアップする。
例:
-
顧客
-
営業チーム
-
財務部門
-
倉庫
-
決済ゲートウェイ
これらはプールまたはレーンとなる可能性があります。
ステップ 3: 開始トリガーを特定する
問いかける:
このプロセスを開始させるものは何か？
適切な開始イベントを使用する:
-
メッセージ
-
タイマー
-
条件トリガー
-
シグナル
-
なし
ステップ 4: 主要な活動をリストアップする
各活動は動詞と目的語の形式で記述する:
-
注文を受領する
-
注文を検証する
-
合計を計算する
-
支払いを承認する
-
注文を出荷する
この段階では、すべての例外を心配する必要はありません。
ステップ 5: 意思決定を追加する
以下のような質問を探してください:
-
注文は完了していますか？
-
支払いは承認されていますか？
-
在庫は利用可能ですか？
-
顧客は資格を満たしていますか？
-
期限は過ぎましたか？
ゲートウェイを使用して、回答がプロセスにどのように影響するかを表してください。
ステップ 6: 並行作業を追加する
同時に発生する可能性のある活動を確認してください。
例:
-
在庫を更新する
-
確認を送信する
-
請求書を作成する
すべての分岐が完了または同期する必要がある場合、並行ゲートウェイを使用してください。
ステップ 7: 中間イベントと境界イベントを追加する
作業中に何が起こり得るか問い合わせてください:
-
その活動には期限がありますか？
-
キャンセルできますか？
-
エラーが発生する可能性がありますか？
-
外部からのメッセージが届く可能性がありますか？
-
プロセスに時間がかかりすぎる場合、エスカレーションすべきですか？
ステップ 8: 終了イベントを追加する
すべての意味のある結果を特定してください:
-
完了
-
却下
-
キャンセル
-
失敗
-
エスカレーション
-
補償済み
ステップ 9: データと注釈を追加
理解を深める場合にのみ、ドキュメント、システム、メモ、およびビジネスルールを含めてください。
ステップ 10: ダイアグラムを確認
以下を確認してください：
-
すべてのプロセスパスには明確な開始点がある
-
すべてのパスは最終的に終了する
-
ゲートウェイの条件は理解しやすい
-
アクティビティには明確な所有者がいる
-
シーケンスフローは実際の順序を示す
-
メッセージフローは参加者の間でのみ使用される
-
タスクとしてゲートウェイが使用されていない
-
ダイアグラムに不必要な詳細が過剰に含まれていない
11. BPMNモデリングでよくある間違い
間違い 1: 意思決定アクティビティとしてゲートウェイを使用する
ゲートウェイはプロセスをルーティングするものであり、分析を実行するものではありません。
弱いモデル：
◇ 与信スコアを確認
より良いモデル：
与信スコアを確認 → 与信承認？
アクティビティが確認を実行します。ゲートウェイは結果に基づいてルーティングします。
間違い 2: 独立したプール間でシーケンスフローを使用する
シーケンスフローは内部プロセスの順序を表します。独立した参加者間の通信にはメッセージフローを使用する必要があります。
誤った概念：
顧客プール ── 実線のシーケンスフロー ── 販売者プール
より良い概念：
顧客プール ── 点線のメッセージフロー ── 販売者プール
ミス 3: ゲートウェイパスにラベルを付けない
ラベルのないゲートウェイは曖昧さを生み出します。
代わりに:
◇ → パス A
→ パス B
使用:
◇
├── 承認
└── 却下
ミス 4: 並列作業に排他的ゲートウェイを使用する
すべてのアクティビティが発生する必要がある場合、排他的ゲートウェイを使用しないでください。
誤り:
◇ ├── 確認を送信
└── 在庫を更新
これは、1 つのパスのみが選択されることを意味します。
両方のアクティビティが発生する必要がある場合は、並列ゲートウェイを使用してください:
+ ├── 確認を送信
└── 在庫を更新
ミス 5: 条件付き作業に並列ゲートウェイを使用する
並列ゲートウェイは、すべての出力パスをアクティブにします。一部のパスのみを実行する必要がある場合は、排他的または包括的ゲートウェイを使用してください。
ミス 6: すべての細かな動作をモデル化する
すべてのクリック、フィールド入力、および内部システムアクションが含まれると、図は読みにくくなる可能性があります。
聴衆に適したレベルでモデル化してください:
-
経営陣には主要な段階が必要です
-
プロセス所有者には責任と意思決定が必要です
-
開発者には実装レベルの詳細が必要になる場合があります
-
監査人には統制と証拠が必要になる場合があります
ミス 7: 行き止まりパスを作成する
すべてのシーケンスフローパスは、最終的に適切な終了イベントまたは明確に定義されたサブプロセス境界に到達する必要があります。
ミス 8: 不必要にビジネスロジックと技術的実装を混同する
ビジネスプロセス図は、まずプロセスを説明すべきです。技術的な詳細は、意図された聴衆を支援する場合のみ含めるべきです。
12. 実用的な命名規則
一貫した命名により、図は読みやすくなります。
イベント
結果、発生、または条件を伴うイベントに名前を付ける：
-
注文受領
-
支払い確認済み
-
期限到達
-
顧客キャンセル
-
エラー発生
アクティビティ
使用：
動詞 + 目的語
例：
-
契約レビュー
-
リクエスト承認
-
アカウント更新
-
通知送信
ゲートウェイ
ゲートウェイは、質問に関連付けると最も明確になります：
-
申請は完了していますか？
-
支払いは承認されていますか？
-
在庫は利用可能ですか？
-
期限は過ぎましたか？
出力パスには回答を含める必要があります：
-
はい / いいえ
-
承認 / 却下
-
利用可能 / 利用不可
終了イベント
結果に応じて終了イベントに名前を付ける：
-
注文完了
-
リクエスト却下
-
支払い失敗
-
ケースキャンセル
13. 適切なゲートの選択
この意思決定ガイドを使用してください：
| モデリングの要件 | 使用するゲート |
|---|---|
| 条件に基づいて正確に1つのパスを選択する | 排他的ゲート |
| すべての出力パスを開始する | 並列ゲート |
| 条件に基づいて1つ以上のパスを選択する | 包括的ゲート |
| 最初に発生したイベントのパスに従う | イベントベースのゲート |
| 高度に専門的なルーティングルールを適用する | 複合ゲート |
簡単な頭の中のテスト：
-
1つのパスですか？排他的
-
すべてのパスですか？並列
-
いくつかのパスですか？包括的
-
最初のイベントですか？イベントベース
-
珍しいカスタムロジックですか？複合
14. 完全な例：顧客返金プロセス
顧客返金プロセスを検討してください。
開始：返金リクエスト受信
↓
返金リクエストのレビュー
↓
リクエストは対象ですか？
├── いいえ
│ ↓
│ 拒否通知を送信
│ ↓
│ 終了：返金拒否
│
└── はい
↓
返金を承認
↓
並列ゲート
├── 返金発行
└── 顧客アカウントの更新
↓
並列結合
↓
返金確認を送信
↓
終了：返金完了
このモデルは以下を示しています：
-
メッセージ開始イベント
-
ユーザーまたは手動アクティビティ
-
排他的ゲートウェイ
-
拒否パス
-
並列分割
-
並列結合
-
確認アクティビティ
-
異なる終了結果
返金サービスが失敗する可能性がある場合、境界エラーイベントを追加してください：返金発行:
返金発行
│
└── エラー → 手動レビューケースの作成
返金が5営業日以内に完了する必要がある場合、境界タイマーイベントを追加してください：
返金発行
│
└── 5日タイムアウト → 返金のエスカレーション
15. コンパクトなBPMNシンボルチートシート
| シンボルカテゴリ | 意味 | 一般的な用途 |
|---|---|---|
| 細い円 | 開始イベント | プロセスを開始する |
| 二重円 | 中間イベント | 待機、送信、受信、または反応 |
| 太い円 | 終了イベント | プロセスパスを終了する |
| 角丸長方形 | タスクまたはアクティビティ | 作業を実行する |
| プラス記号付きの角丸長方形 | 折りたたみサブプロセス | 詳細作業のグループ化 |
| X付きダイヤモンド | 排他的ゲートウェイ | 1つのパスを選択 |
| プラス付きダイヤモンド | 並列ゲートウェイ | すべてのパスを実行 |
| 円付きダイヤモンド | 包括的ゲートウェイ | 1つ以上のパスを実行 |
| イベントマーカー付きダイヤモンド | イベントベースゲートウェイ | 最初のイベントに従う |
| 実線矢印 | シーケンスフロー | 内部順序を表示 |
| 破線矢印 | メッセージフロー | 通信を表示 |
| 点線コネクタ | 関連付け | ノートまたはデータをリンク |
| プール | 参加者 | 組織またはプロセスを表す |
| レーン | 役割または責任 | 所有権を割り当てる |
| ドキュメント/データの形状 | データオブジェクト | 使用または生成された情報を表示する |
16. 最終モデリング原則
最も効果的な BPMN ダイアグラムは、いくつかの基本的な原則に従います：
-
発生する事象にはイベントを使用する。
-
人またはシステムが実行する作業にはアクティビティを使用する。
-
パスの制御または同期にはゲートウェイを使用する。
-
内部プロセスの順序にはシーケンスフローを使用する。
-
参加者間の通信にはメッセージフローを使用する。
-
意思決定と出力条件を明確にラベル付けする。
-
複雑さを制御するためにサブプロセスを使用する。
-
プールとレーンを使用して責任を示す。
-
タイムアウト、エラー、および中断には境界イベントを使用する。
-
聴衆に適したレベルでモデル化する。
-
意味のあるすべてのパスに明確な結果を与える。
-
過度に複雑な図よりも、シンプルで理解しやすい図を優先する。
これら3つの核心的な概念に慣れると—イベントが発生し、アクティビティが実行され、ゲートウェイがフローを制御する—ほとんどのBPMNダイアグラムははるかに読みやすく、作成しやすくなります。