BPMNの書き方｜業務プロセスを5ステップで整理
目次
はじめに
「業務フローは描いたのに、開発会社へ渡すと質問が戻ってくる」。その原因は、作業の順番だけが見え、開始条件、担当、分岐条件、例外、完了条件が決まっていないことにある。
そこで役立つのがBPMN（Business Process Model and Notation）だ。BPMNは業務プロセスを共通の記号で表すための標準で、Object Management Group（OMG）のBPMN 2.0.2仕様では、イベント、アクティビテ ィ、ゲートウェイ、シーケンスフローなどの意味と接続規則が定義されている。
ただし、記号をたくさん使えば良い図になるわけではない。要件定義で必要なのは、業務担当者が確認でき、開発側が機能・権限・データ・テストへ展開できる図である。
この記事では「問い合わせを受け、内容を確認し、担当者が回答する」業務を題材に、BPMNの書き方を5ステップで整理する。
BPMNとは何を表す図か
BPMNが表すのは、業務の開始から終了までに、誰が何を行い、どの条件で経路が変わり、どんな情報をやり取りするかである。
MicrosoftのBPMN解説でも、BPMNは複雑な業務プロセスを視覚的に表現し、関係者の理解をそろえる方法として説明されている。業務部門と開発部門が同じ図をレビューできる点が大きい。
最初に覚える要素は次の5つで十分だ。
| 要素 | 形 | 意味 | 問い合わせ対応の例 |
|---|---|---|---|
| イベント | 円 | 開始、途中で起こる事象、終了 | 問い合わせ受信、回答完了 |
| タスク | 角の丸い四角 | ひとまとまりの作業 | 内容を確認する |
| ゲートウェイ | ひし形 | 条件による分岐・合流 | FAQで回答できるか |
| シーケンスフロー | 実線の矢印 | 同じプロセス内の実行順序 | 受付から確認へ進む |
| プール／レーン | 帯状の区画 | 組織や役割の責任範囲 | 顧客、一次担当、専門担当 |
アクティビティ図や一般的な業務フロー図と似ているが、BPMNではイベントや分岐、参加者間のやり取りに定義された意味がある。図を見栄えのために作るのではなく、曖昧な業務判断を発見するために使う。
BPMNの書き方：5ステップ
ステップ1：開始と終了、対象範囲を決める
最初に、プロセスの入口と出口を一文で決める。
- 開始：顧客から問い合わせを受信する
- 終了：回答を送信し、対応記録を保存する
- 対象外：回答後の満足度調査、契約変更、請求処理
対象範囲が曖昧なままタスクを並べると、図は際限なく広がる。「問い合わせ対応」の中に商談、契約、請求まで入れると、誰も全体をレビューできない。
開始イベントは、単に「開始」と書かず、何がプロセスを動かすのかを書く。フォーム送信、メール受信、定時実行など、きっかけを具体化する。終了イベントも「終了」ではなく、「回答済み」「エスカレーション受付済み」のように到達状態を書く。
終了は一つとは限らない。問い合わせ対応なら、正常回答、対象外案内、専門担当への引き継ぎなど、業務上意味が異なる終わり方を分ける。これにより、完了件数の数え方やSLAの終了時点も決めやすくなる。
ステップ2：プールとレーンで責任を分ける
次に、プロセスへ参加する組織や役割を整理する。
| レーン | 主な責任 |
|---|---|
| 顧客 | 問い合わせを送信し、必要なら追加情報を返す |
| 一次担当 | 受付、分類、既知回答の提示を行う |
| 専門担当 | 技術・契約など専門判断が必要な回答を作る |
| システム | 受付記録、通知、期限監視を行う |
レーン名に個人名を置くと、異動や担当変更で図が使えなくなる。原則として役割 名で書き、具体的な担当者は運用表で管理する。
また、「AI」が独立した責任主体とは限らない。AIが回答候補を生成しても、最終承認を一次担当が行うなら、AI生成はシステムレーンのタスク、承認は一次担当レーンのタスクとして分ける。誰が結果に責任を持つかを図から読めるようにする。
プールをまたぐ参加者間では、通常の順序を示すシーケンスフローと、情報交換を示すメッセージフローを混同しない。顧客と自社の間はメッセージ、自社内の処理順はシーケンスとして整理すると、外部との契約境界が見える。
ステップ3：タスクを「動詞＋対象」で書く
タスク名は「確認」「回答」のような名詞だけにしない。何をするかが分かるように、「問い合わせ内容を分類する」「回答案を承認する」と書く。
問い合わせ対応なら、通常系は次のように並ぶ。
問い合わせを受信する
→ 受付記録を作成する
→ 問い合わせ内容を分類する
→ 回答案を作成する
→ 回答案を承認する
→ 顧客へ回答を送信する
→ 対応記録を保存する
一つのタスクに複数の判断を詰め込まない。「内容を確認して必要なら専門担当に聞いて回答する」では、入力、担当、完了条件が分からない。分類、引き継ぎ、回答作成、承認を分ければ、それぞれに権限と期限を設定できる。
各タスクには最低限、次の4点を別表で持たせる。
- 入力：問い合わせ本文、顧客情報、関連契約
- 出力：分類結果、回答案、承認結果
- 実行者：一次担当、専門担当、システム
- 完了条件：必須項目が保存され、次の担当へ渡せる
BPMNは図だけで全項目を表すものではない。図は流れと責任を示し、詳細なデータ項目や業務ルールは仕様表へリンクする。
ステップ4：ゲートウェイの条件を排他的にする
分岐には、どの経路へ進むかを判定できる条件を書く。
悪い例は「簡単／難しい」「必要に応じて」「問題あり／なし」である。人によって判断が変わり、AIにも実装にも渡せない。
問い合わせ対応なら、次のように観測可能な条件へ変える。
| 分岐 | はいの場合 | いいえの場合 |
|---|---|---|
| 必須情報がそろっているか | 分類へ進む | 顧客へ追加情報を依頼する |
| 承認済みFAQと一致するか | FAQ回答案を作る | 専門担 当へ依頼する |
| 個人情報を含むか | 制限された保管先へ保存する | 通常の保管先へ保存する |
| 回答案が承認されたか | 顧客へ送信する | 作成者へ差し戻す |
排他的ゲートウェイでは、原則として一つの経路だけが選ばれるよう条件を設計する。複数の条件が同時に真になるなら、優先順位を決めるか、並列処理として別の構造にする。
分岐の出口には条件を書き、想定外を受け止める既定経路も用意する。「どの条件にも合わない」ケースを放置すると、実装後に処理が止まる。
ステップ5：例外、期限、受け入れ条件へ展開する
通常系が描けたら、業務で実際に詰まるケースを加える。
- 顧客から追加情報が返らない
- 専門担当が期限までに回答しない
- 回答送信に失敗する
- 同じ問い合わせが重複して届く
- 承認後に回答内容を修正する必要が生じる
BPMNでは中間イベントや境界イベント でタイマー、メッセージ、エラーなどを表せる。ただし、記号を追加する前に運用を決めることが重要だ。
たとえば「専門担当が2営業日以内に回答しない」場合、誰へ通知するのか、一次担当は顧客へ中間連絡するのか、期限はいつ再計算するのかを決める。タイマー記号だけでは要件にならない。
最後に、各経路を受け入れ条件へ変換する。
| 経路 | 受け入れ条件 |
|---|---|
| FAQ回答 | 承認済み版のFAQを参照し、送信者と送信日時が記録される |
| 専門回答 | 専門担当と承認者を追跡でき、承認前は送信できない |
| 追加情報待ち | 依頼内容、期限、再通知回数が記録される |
| 送信失敗 | エラー内容が保存され、重複送信せず再試行できる |
| 対象外 | 対象外理由と案内先が記録される |
この表まで作れば、BPMNは説明資料ではなく、機能要件、権限設計、通知設計、テストケースの入口になる。
レビューで確認する7項目
図が完成したら、業務担当者と開発側で次を確認する。
- 開始のきっかけと終了状態が具体的である
- レーンごとの責任が重複していない
- タスクが「動詞＋対象」で書かれている
- すべての分岐に判定可能な条件がある
- 外部との情報交換と内部の処理順が区別されている
- 期限超過、送信失敗、差し戻しの経路がある
- 各経路を受け入れ条件へ変換できる
レビューでは、図の正しさだけでなく、図から実装判断を引き出せるかを見る。担当者が「状況に応じて対応する」と説明した箇所は、条件、権限、例外のいずれかが未定義である可能性が高い。
BPMNをAIへ渡す前に必要なこと
生成AIは、タスク名の整形や不足候補の列挙には使える。しかし、責任者、承認基準、期限、例外時の判断を事実として決めることはできない。
AIへ渡すなら、BPMN画像だけではなく、次をセットにする。
- プロセスの目的と対象範囲
- レーンごとの責任
- タスクの入出力
- ゲートウェイの判定条件
- 例外時の担当と期限
- 用語集と関連データ定義
AIが読める仕様書の書き方で解説した構造化と、データフロー図の書き方を組み合わせると、業務の順序だけでなく、処理間を流れる情報も追える。
また、状態の変化を厳密に扱う業務では、状態遷移図の書き方を併用する。BPMNで業務参加者と流れを示し、状態遷移図でステータスと遷移条件を示すと、二重処理や不正な更新を防ぎやすい。
BPMNは合意を実装へ渡す中継点
BPMNの価値は、きれいなフロー図を完成させることではない。開始と終了、責任、タスク、分岐、例外を共通の記号で確認し、その合意を機能・データ・権限・テストへ渡すことにある。
まずは一つの業務を選び、開始と終了 を一文で決める。次に役割を分け、タスクを動詞で書き、曖昧な判断を条件へ変える。最後に例外と受け入れ条件を追加する。この順番なら、図の複雑さを抑えながら実装に必要な論点を残せる。
Atsumellは、業務フロー、データ、例外、権限、受け入れ条件をつなぎ、AIと人が同じ前提で読める仕様づくりを支援している。図を作るところで止まらず、開発へ渡せる要件へ整理したい場合は、お問い合わせから相談してほしい。
Kakusillで要件や仕様を整理する際にも、BPMNで確定した担当・分岐・例外を明記しておくと、開発側が確認すべき論点を共有しやすくなります。
