BPMNとは 業務フロー図の書き方と5つの基本記号・フローチャートとの違い

「業務フロー図を作ったが、部門ごとに書き方が違って比較できない」「担当者が変わったら、図の意味が伝わらなくなった」。業務の可視化に取り組むと、必ずこの問題にぶつかります。

BPMNは、業務プロセスを決められた記号で図式化するための国際標準の表記法です。Business Process Model and Notationの略で、日本語ではビジネスプロセスモデリング表記法と訳されます。

最大の価値は、誰が書いても同じ意味に伝わるという点にあります。記号とその意味が標準として定義されているため、部門や企業の垣根を越えて同じ図を読み解けます。

この記事では、標準化の経緯を整理したうえで、まず覚えるべき5つの記号、書き方の手順、フローチャートとの違い、そしてつまずきやすい点までを順に扱います。

確認したいポイント	結論	詳細
BPMNとは？	業務フローの標準的な記法	業務の開始から終了までを、決められた記号で図式化する国際標準の表記法です。
最低限覚える記号は？	5種類で大半の業務が書ける	イベント、アクティビティ、ゲートウェイ、フロー、プールの5つが基本になります。
フローチャートとの違いは？	記号と意味が標準で定義済み	誰が書いても同じ意味に伝わります。担当者を表すプールの概念も特徴です。
何に使える？	業務改善とシステム化の土台	XML形式で出力できるため、ワークフローシステムへの組み込みにも使えます。

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

目次

この記事でわかること

• BPMNの定義と、国際標準として策定されるまでの経緯
• まず覚えるべき5つの基本記号と、記号全体の4つの分類
• 対象範囲の決定からレビューまでを通した書き方の6ステップ
• フローチャートやUMLアクティビティ図との違いと使い分け
• 記号の使いすぎや粒度のばらつきなど、つまずきやすい点への対処

業務可視化と自動化の進め方をまとめた資料を無料で配布しています どの業務から可視化すべきかの見極め方、改善から自動化につなげる手順、費用の目安を1冊にまとめました。検討段階の情報収集にご活用いただけます。 ▶ 資料請求はこちら※オンライン完結／しつこい営業は一切いたしません

BPMNとは

BPMNは、業務プロセスの開始から終了までのステップと手順を、フローチャートのような形で図式化する表記法です。決められた記号を使うことで、業務の流れを誰にでも同じ意味で伝えられます。

OMG（Object Management Group）というオブジェクト指向技術の標準化団体が維持しています。BPMN.orgが公式のBPMN情報サイトとして運営されています。

標準化の経緯とバージョン

成り立ちを押さえておくと、位置づけが理解しやすくなります。もともと別の団体が開発し、後にOMGへ引き継がれたという経緯があります。

• 2004年：BPMI（Business Process Management Initiative）がBPMN 1.0の仕様を発行
• 2005年：BPMIがOMGに吸収合併され、以降OMGが維持
• 2011年1月：BPMN 2.0が策定される
• 2013年：ISOとIECの合同部会が、標準規格ISO/IEC 19510を発行

現行はBPMN 2.0系です。OMGの公式仕様では、BPMNがビジネスプロセス図の事実上の標準になっていると述べられています。

2.0で名称が「Business Process Modeling Notation」から「Business Process Model and Notation」に変わりました。図として描くだけでなく、実行できる意味づけが加わったことを反映した変更です。

BPM・BPRとの関係

似た略語が並ぶため、整理しておきます。BPMNは手法、BPMは管理の営み、BPRは改革という関係です。

• BPMN：業務プロセスを図式化する表記法。可視化の手段
• BPM（Business Process Management）：業務プロセスを管理し、継続的に改善していく取り組み
• BPR（Business Process Reengineering）：業務や組織を根本から見直す改革

BPMNは、BPMを回すための道具という位置づけになります。現状を図にして把握し、問題点を見つけ、改善して再び図にする。この繰り返しを支える記法です。

BPMNを描くこと自体が目的になりがちですが、描いた図を使って何を判断するのかを先に決めておく必要があります。

なぜBPMNを使うのか

自由に描いた業務フロー図でも、業務は表現できます。それでも標準記法を使う理由を整理します。

誰が書いても同じ意味に伝わる

最大の理由です。記号とその意味が標準として定義されているため、解釈のぶれが生じません。

自由形式のフロー図では、四角が作業を意味するのか判断を意味するのか、書いた人にしか分かりません。矢印の実線と破線の違いも、人によって使い方が変わります。

この曖昧さが、業務の引き継ぎや他部門との議論を妨げます。標準に従えば、図だけで正確に伝わります。公式仕様でも、文章によるプロセス記述の曖昧さを解消することが目的として挙げられています。

部門や企業をまたいで共有できる

プールという概念によって、誰が何を担当するかが図の中で明示されます。部門をまたぐ業務の全体像が、1枚で表現できます。

自社と取引先をまたぐ業務も描けます。受注から出荷までの流れに、顧客、営業、物流、外部倉庫が登場する。それぞれをプールとして並べれば、責任の境界が見えます。

境界が見えると、そこに潜む問題が浮かび上がります。部門間の受け渡しで滞留している、同じ確認を両方で行っている。こうした無駄は、部門単位の図では発見できません。

システムにそのまま活かせる

見落とされやすい利点です。BPMN 2.0はXML形式での出力と読み込みに対応しています。

つまり、描いた図が単なる絵ではなくデータとして扱えます。対応するワークフローシステムであれば、BPMNの定義をそのまま取り込んで動かせる場合があります。

業務要件の整理と、システム化の設計を同じ図で進められるという効果があります。要件の書き方については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

ツール間で図を交換できる

標準化のもう1つの効果です。異なるモデリングツール間で、図を標準化された形式で交換できます。

独自形式のツールで作った図は、そのツールがなければ開けません。ツールの提供が終了したり、社内で別の製品に切り替えたりすると、資産が使えなくなります。

標準形式で保存しておけば、この依存を避けられます。長期にわたって業務の記録を残す場合、この点は実務上の意味を持ちます。

まず覚える5つの基本記号

BPMNには数十種類の記号があります。ただし、実務で使う業務フローの大半は、次の5つで書けます。ここから始めれば十分です。

1. イベント｜開始と終了

円で表します。プロセスの始まりと終わり、そして途中で発生する出来事を示します。

開始イベント　：細い線の円（○）

中間イベント　：二重線の円（◎）

終了イベント　：太い線の円（●の輪郭）

線の太さで種類を区別するという約束です。これを知らないと、どれが開始でどれが終了か読み取れません。

開始イベントには、何によって始まるかを示す記号を入れられます。メールの受信、時刻の到来、条件の成立など。業務の起点を明示することで、フローの前提が伝わります。

2. アクティビティ｜作業

角の丸い四角で表します。人やシステムが行う作業そのものを示す、最も登場頻度の高い記号です。

中に書くのは作業の名称です。「動詞で終わる形」で書くと読みやすくなります。「注文内容を確認する」「請求書を発行する」といった形です。

複数の作業をまとめたものはサブプロセスと呼び、四角の中に小さなプラス記号を付けて表します。詳細を別の図に切り出すことで、全体の図を見やすく保てます。

3. ゲートウェイ｜分岐と合流

ひし形で表します。条件によって流れが分かれる箇所、あるいは複数の流れが合流する箇所を示します。

排他分岐（×）：どちらか一方だけを通る

並行分岐（＋）：すべての経路を同時に進む

包含分岐（○）：条件を満たす経路すべてを通る

最もよく使うのが排他分岐です。「金額が10万円以上か」で処理を分けるといった場面で使います。ひし形の外に条件を書き添えます。

並行分岐を排他分岐と混同しないことが重要です。「承認依頼を同時に2人へ送る」のは並行、「どちらか1人が承認する」のは排他です。意味がまったく違います。

4. シーケンスフロー｜流れ

実線の矢印で表します。作業が進む順序を示します。矢印の先は塗りつぶした三角です。

区別すべきなのがメッセージフローで、こちらは破線の矢印に白抜きの三角を使います。プールをまたいでやり取りする情報を表します。

同じプール内は実線、プールをまたぐのは破線という使い分けです。ここを混同すると、責任の境界が正しく表現されません。

5. プールとレーン｜誰がやるか

長方形の枠で表します。BPMNを特徴づける概念であり、一般的なフローチャートにはない要素です。

プールは、プロセスが誰によって、あるいはどの部門によって処理されるべきかを示します。アクティビティやフローを長方形で囲って表現します。

プール内をさらに分けたい場合は、直線で分割します。これをスイムレーンと呼びます。部門をプール、その中の担当者やチームをレーンにするという使い方が一般的です。

この5つを押さえれば、実務の業務フローは大半が書けます。残りの記号は、必要になった時点で調べれば十分です。

どの業務から可視化すべきかからご相談いただけます 書き方は分かっても、自社のどの業務から着手すべきかの判断は別の問題です。業務の棚卸しからご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

記号の4つの分類

BPMNの記号は4つのカテゴリに整理されています。全体像を把握しておくと、必要な記号を探しやすくなります。

フローオブジェクト

プロセスの流れを構成する中核の記号です。3種類あります。

イベント（円）、アクティビティ（角丸四角）、ゲートウェイ（ひし形）。前章で挙げた5つのうち、最初の3つがここに含まれます。

この3種類だけで、処理の流れは表現できます。まずここを確実に使えるようにすることが、習得の第一段階になります。

接続オブジェクト

フローオブジェクトを結ぶ線です。3種類あります。

• シーケンスフロー：処理の順序を示す。実線の矢印
• メッセージフロー：プールをまたぐ情報のやり取り。破線の矢印
• 関連（アソシエーション）：注釈やデータを要素に結び付ける。点線

線の種類で意味が変わるという点が、フローチャートとの大きな違いです。自由形式の図では、線は単に「つながっている」ことしか示しません。

スイムレーン

誰が担当するかを表す枠です。プールとレーンの2種類があります。

プールは1つの参加者を表します。企業、部門、あるいはシステムです。レーンはプール内をさらに細分化したものです。

プールをまたぐ流れは、必ずメッセージフローになります。別の参加者へ処理が移るということは、情報の受け渡しが発生しているためです。

アーティファクト

補足的な情報を示す記号です。流れそのものには影響しませんが、図の理解を助けます。

• データオブジェクト：作業で使う、または生成される書類やデータ
• グループ：関連する要素をまとめて囲む。点線の四角
• 注釈（テキストアノテーション）：補足の説明文

注釈は積極的に使います。記号だけでは表現しきれない前提や例外を書き添えることで、図の実用性が上がります。

書き方の手順｜6ステップ

記号を知っていても、いきなり描き始めると混乱します。手順に沿って進めます。

ステップ1｜対象範囲と粒度を決める

最初に決めるのは、どこから始まってどこで終わるかです。ここを決めずに描き始めると、図が際限なく広がります。

「顧客からの問い合わせ受付」から「見積書の送付」まで、といった形で範囲を区切ります。前後の業務は、別の図として分けます。

粒度も同時に決めます。1つのアクティビティをどのくらいの大きさにするか。「メールを開く」レベルまで書くのか、「問い合わせ内容を確認する」でまとめるのか。目的によって変わります。

ステップ2｜登場する役割を洗い出す

プールとレーンを先に作ります。この業務に関わる部門、担当者、システム、外部の取引先をすべて挙げます。

洗い出した役割を、上から順にプールとして並べます。関わりの深い役割を隣に配置すると、線の交差が減って読みやすくなります。

システムも参加者として扱えます。「基幹システムが自動で在庫を引き当てる」という処理があるなら、システムのプールを設けます。

ステップ3｜開始と終了を置く

枠ができたら、開始イベントと終了イベントを配置します。これが図の両端になります。

開始イベントは、何がきっかけでこの業務が始まるのかを表します。顧客からの連絡、決まった時刻、前工程の完了。起点を明示します。

終了イベントは複数あって構いません。承認された場合と却下された場合で、別の終了を置くという構成が自然です。

ステップ4｜作業を順に並べる

まず正常系だけを一直線に描きます。例外や分岐は後から追加します。

最も典型的なケースで、開始から終了まで何が起こるかを順に並べます。各アクティビティは、担当する役割のプールに置きます。

プールをまたぐところは破線のメッセージフローにします。この段階で、部門間の受け渡しが何回発生しているかが見えてきます。

ステップ5｜分岐を追加する

正常系が通ったら、条件による分岐と例外の処理を追加します。

「金額によって承認者が変わる」「在庫がない場合は取り寄せる」「内容に不備があれば差し戻す」。実際の業務で起こることを反映させます。

ここで業務の複雑さが明らかになります。分岐が想像以上に多いと分かることもあります。その事実自体が、業務改善の出発点になります。

ステップ6｜現場の担当者にレビューしてもらう

描いた本人だけで完成とせず、実務の担当者に確認してもらいます。これが最も価値のある工程です。

「この確認は実際にはやっていない」「ここで例外が頻発する」「この判断は別の人がしている」といった指摘が出てきます。図と実態のずれが、この場で見つかります。

指摘を反映して修正します。1回目の図は必ず実態と違っています。2回から3回のレビューを経て、使える図になります。

フローチャート・UMLとの違い

似た図法との違いを整理します。使い分けの判断に直結します。

フローチャートとの違い

一般的なフローチャートは、処理と判断を四角とひし形で表す簡易な図法です。記号の意味が厳密に定義されていない点が最大の違いです。

加えて、担当者を表現する仕組みがありません。誰がその作業をするのかは、図の外で説明する必要があります。部門をまたぐ業務では、この制約が効いてきます。

手軽さではフローチャートが上です。数ステップの単純な手順であれば、わざわざBPMNを使う必要はありません。複数の部門が関わる業務から、BPMNの価値が出ます。

UMLアクティビティ図との違い

UMLもOMGが管理する表記法です。図の見た目はBPMNと似ていますが、想定する用途が異なります。

UMLは主にソフトウェアの設計で使われ、読み手はIT技術者です。システムの振る舞いを表現することに重点があります。

対してBPMNは、業務の関係者全員が理解できることを目的としています。公式仕様でも、プロセスを設計し管理し実現する関係者が直接使えるものとして位置づけられています。

BPMNはUMLとは異なる標準であり、どちらかが上位というものではありません。業務を描くならBPMN、システム内部を描くならUMLという使い分けになります。

使い分けの基準

読み手と目的で決まります。判断の目安を整理します。

• 単純な手順を社内で共有する → フローチャートで十分
• 複数部門にまたがる業務を可視化する → BPMN
• 業務改善やシステム化の検討材料にする → BPMN
• システムの内部構造や処理を設計する → UML

業務側とIT側の橋渡しをしたい場合、BPMNが最も適しています。業務担当者が読めて、かつ技術者が設計に使える粒度を持つためです。

つまずきやすい点

描けるようになった後に起きる問題を整理します。

記号を使いすぎる

最も多い失敗です。BPMNには数十種類の記号があるため、覚えたものをすべて使いたくなります。

結果として、読み手が意味を理解できない図になります。BPMNを知らない人が見る前提であれば、5つの基本記号に絞るほうが伝わります。

目的は正確な記法の実践ではなく、業務を伝えることです。記号の網羅性より、読み手が理解できるかを優先します。

粒度が揃わない

同じ図の中に、「メールを開く」と「受注処理を行う」が並んでいるような状態です。詳しい部分と粗い部分が混在すると、読み手が混乱します。

原因は、詳しく知っている業務を細かく書いてしまうことです。書き手の理解度が、そのまま粒度のばらつきとして現れます。

対策は、粒度の基準を先に決めることです。「1つのアクティビティは、1人が中断せずに行う作業とする」といった目安を置きます。詳細が必要な部分はサブプロセスに切り出します。

例外処理を書かない

正常系だけを描いて終わりにするケースです。実際の業務では、例外の処理が工数の大半を占めていることがあります。

差し戻し、再提出、代理承認、締め後の修正。こうした処理が図に入っていないと、システム化の検討に使えません。要件から漏れて、後で追加開発になります。

現場へのレビューで例外を拾います。「例外はどのくらいの頻度で起きますか」と聞くと、想像より多いという答えが返ってくることがよくあります。

図が大きくなりすぎる

1枚に詰め込みすぎて、印刷できない、全体が見渡せないという状態です。読めない図には価値がありません。

対策は、範囲を分けることとサブプロセスを使うことです。1枚がA3に収まる程度を目安にし、超えるなら分割します。

全体像を示す粗い図と、部分を詳しく示す図を分けるという構成も有効です。読み手によって必要な粒度が違うためです。

ツールと始め方

最初の一歩をどう踏み出すかを整理します。

ツールの選び方

BPMNに対応した作図ツールは多数あります。まず無償で使えるものから試すのが現実的です。

選ぶ基準は、BPMNの記号があらかじめ用意されているか、複数人で編集できるか、標準形式で書き出せるかの3点です。汎用の作図ツールにもBPMN用の記号が含まれていることが多くあります。

ワークフローシステムへの連携を考えるなら、標準形式での出力に対応しているかを確認します。図を描くだけなら、この機能は不要です。

最初に描く業務の選び方

問題が起きている業務から選びます。滞留が発生している、ミスが多い、担当者しか分からない。こうした業務を図にすると、効果がすぐ現れます。

規模は小さく始めます。5つから10のアクティビティで収まる業務が適しています。部門をまたぐ業務を選ぶと、BPMNの利点が実感できます。

すべての業務を網羅しようとしないことが続けるための条件です。1本描いて効果が見えてから、対象を広げます。業務の棚卸しの進め方は業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法も参考になります。

描いた後にどう使うか

描いて終わりにしないことが最も重要です。図を使って何をするのかを、描く前に決めておきます。

用途は主に3つあります。業務の引き継ぎと教育、改善点の洗い出し、そしてシステム化の要件整理です。目的によって、必要な粒度と注目すべき箇所が変わります。

改善に使う場合は、待ち時間、手戻り、重複した確認、人手による転記に注目します。図の上でこれらが見えたら、そこが改善の候補になります。

自動化の検討につなげる進め方についてはAI業務自動化・GAS開発で扱っています。

まとめ

BPMNは、業務プロセスを標準化された記号で図式化する表記法です。OMGが維持しており、BPMN 2.0系がISO/IEC 19510として国際標準になっています。

まず覚えるべきは5つです。イベント（円）、アクティビティ（角丸四角）、ゲートウェイ（ひし形）、シーケンスフロー（実線）、プールとレーン（枠）。これで実務の大半は書けます。

書き方は6ステップです。範囲と粒度を決め、役割を洗い出し、開始と終了を置き、正常系を並べ、分岐を追加し、現場にレビューしてもらう。最後の工程が最も価値を生みます。

フローチャートとの違いは、記号の意味が定義されていることと、担当者を表すプールがあることです。複数部門にまたがる業務から、BPMNの価値が出ます。

まずは問題が起きている業務を1つ選び、5つの記号だけで描いてみてください。そして現場の担当者に見せてください。図と実態のずれが、そのまま改善の出発点になります。

業務改善から自動化まで、無料で相談できます 図を描いたが改善につなげられない、業務が属人化しているといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら※オンライン完結／秘密厳守／助成金活用のご相談も歓迎