BPMNとは？業務フロー図の国際標準と記号・発注前の使い方
BPMN(Business Process Model and Notation)とは、業務プロセスを図で表すための国際標準の表記法です。
標準化団体OMG(Object Management Group)が策定しており、現在の最新版は2.0.2(2014年1月採択)です。
書き方が標準化されているため、社内の業務整理だけでなく、システム開発を外部へ発注する際の共通言語として使えます。
本記事では、基本記号の読み方と、発注前の業務整理にBPMNをどこまで使うかの判断を解説します。
出典：OMGのBPMN仕様ページ、BPMN 2.0仕様（いずれも2026年9月25日確認）。
BPMNとは。誰が決めた、何のための標準か
BPMNは、1989年設立の国際的な標準化団体OMGが仕様を管理しています。OMGの仕様ページでは、BPMNは業務プロセス図の事実上の標準になっているとされ、業務の設計・管理に関わる人がそのまま使える分かりやすさと、ソフトウェアの部品へ変換できる精密さの両立を目指した表記法だと説明されています。バージョン2.0が2010年12月に採択され、その後の改訂を経て2.0.2(2014年1月)が最新版です。OMG公式（2026年9月25日確認）。
「標準である」ことの実務上の意味は、書き手によって記号の意味がぶれないことです。自己流のフローチャートでは、四角や矢印の意味を毎回説明する必要がありますが、BPMNなら記号の意味が仕様で決まっているため、社内の別部署や外部の開発会社とも同じ図で会話できます。
基本記号の読み方。まず4種類だけ覚える
BPMNの仕様には多くの記号がありますが、業務整理の目的なら、まず次の基本要素を押さえれば読み書きを始められます。
| 要素 | 図での形 | 意味 |
|---|---|---|
| イベント | 円 | プロセスの開始・終了や、途中で起こる出来事 |
| アクティビティ | 角丸の四角 | 作業・タスク(「見積を作成する」など) |
| ゲートウェイ | ひし形 | 分岐・合流(「金額が10万円以上か？」など) |
| シーケンスフロー | 実線の矢印 | 作業の順序 |
これに加えて、担当者・部署ごとに図を横切りで区切る「レーン(スイムレーン)」を使うと、誰の作業かが一目で分かります。承認が部署をまたぐ業務や、顧客とのやり取りを含む業務では、レーン分けが特に有効です。
記号の網羅的な定義はOMGの仕様で公開されています。実務では、まず基本要素だけで書き、必要になった時点で詳細な記号を調べる進め方で十分です。
BPMN図を書く手順。5つのステップ
実際に書くときは、次の順序で進めると迷いにくくなります。
第1に、対象業務と図の目的を1行で決めます。「受注から請求までの流れを、システム化検討のために現状どおり描く」といった具合です。第2に、登場する部署・役割を洗い出し、レーンとして並べます。第3に、開始イベント(何をきっかけに業務が始まるか)と終了イベント(何をもって完了とするか)を先に置きます。第4に、開始から終了までの作業(アクティビティ)を担当レーンの上に順に並べ、矢印でつなぎます。第5に、判断が分かれる箇所にゲートウェイを置き、差し戻しや中止といった例外の流れを描き足します。
最初から清書を目指さないことも重要です。手書きやホワイトボードで一度描き、業務の当事者に「この通りか」を確認してから清書する方が、結果的に早く正確な図になります。確認の場では、図に描かれていない「たまにある例外」を引き出すことを意識してください。
発注前にBPMNで業務を整理するメリット
システム開発を発注する立場でBPMNを使う最大の目的は、「今の業務がどう流れているか」を、開発会社と誤解なく共有することです。
言葉だけの説明では、例外的な処理(差し戻し、キャンセル、担当者不在時の代行など)が抜け落ちやすく、開発の途中で「その場合の画面がない」と発覚しがちです。図にすると、分岐(ゲートウェイ)を書く過程で例外の存在に気づけます。
また、現状の業務(As-Is)と、システム導入後の業務(To-Be)を別の図として描き分けると、「システムで何が変わるのか」を関係者が確認できます。この描き分けの実務は本稿では概念の紹介にとどめます。
要件をまとめる段階では、図とあわせて文章の要件定義書も必要になります。要件定義の進め方と書き方と、発注先へ渡す資料としてのRFP作成の手順とテンプレートもあわせて参照してください。
書きすぎないための範囲の決め方
BPMNを学ぶと全業務を図にしたくなりますが、発注準備としては書きすぎに注意が必要です。維持されない図は、かえって誤った情報源になります。
範囲の決め方として、システム化の対象になる業務と、その前後のつながりまでに絞ることを提案します。たとえば受注管理システムの発注なら、受注から請求までの流れと、在庫・会計など隣接業務との接点だけを描き、隣接業務の内部までは描き込みません。
粒度は「1つのアクティビティ=担当者が一度に行う作業のまとまり」を目安にし、画面操作の手順(クリック単位)までは描かないようにします。操作手順は開発が進んでから画面設計で扱う内容で、発注前の図に入れると更新が追いつかなくなります。
描いた図には管理者を決め、業務が変わったときに更新する担当と保管場所も決めておきます。発注後は、要件定義の確定内容に合わせて図を直し続けるのか、図は検討時点の資料として凍結するのかを開発会社と合意しておくと、どの資料が最新かをめぐる混乱を防げます。
図を渡すときは、図が「いつ時点の、誰への確認済みか」を添えてください。現場に確認していない想像の図をベースに見積もりが進むと、後の手戻りが大きくなります。
BPMNに関するFAQ
BPMNとフローチャートは何が違いますか？
フローチャートは広い意味での流れ図の総称で、記号の使い方や粒度は書き手に委ねられます。BPMNは業務プロセスに特化して記号の意味が仕様で標準化されている点が違いです。社外と共有する業務図では、意味のぶれが少ないBPMNが向いています。
専用ツールがないと書けませんか？
表記法自体は標準仕様であり、特定の製品に依存しません。作図機能を持つ一般的なツールで基本要素を使って書き始められます。社内で共有するだけなら、誰でも開ける画像やPDFの形で配る方法でも十分です。本記事では特定ツールの機能・料金は確認していないため、ツール選定は各製品の公式情報で確認してください。
発注時にBPMN図の提出は必須ですか？
必須ではありません。開発会社は文章や打ち合わせからも業務を把握できます。ただし、部署をまたぐ業務や例外処理が多い業務では、図があると認識合わせが早くなります。完璧な図を目指すより、現状を正直に描いた図を早めに共有する方が有効です。
業務の流れの整理から一緒に取り組めます
ノーコード総研では、ノーコードやAIを活用した業務システムの受託開発をご相談いただけます。「業務フローを描き切れていないが、システム化を検討したい」という段階でも、現状の業務の聞き取りと整理から一緒に進められます。
どの開発会社に相談するか迷っている場合はシステム開発会社のタイプ別比較も参考に、まずは現状の業務資料を持ってノーコード総研に相談することから始めてみてください。