業務改善やシステム導入の場面で、「今の業務の流れがよくわからない」「担当者によって手順が違う」「どこで承認が止まっているのかわからない」と感じることがあります。
業務は毎日行われているため、現場の人にとっては当たり前になっています。しかし、改めて整理しようとすると、誰が、いつ、何をしているのかが意外と見えにくいものです。
特に、部門をまたぐ業務では、営業、管理部門、経理、情報システム部門、外部取引先など、複数の関係者が登場します。そのため、文章だけで業務の流れを説明しようとすると、認識のズレが起きやすくなります。
そこで役立つのが、BPMNです。
BPMNは、業務プロセスを図で表現するためのフレームワークです。難しく見えるかもしれませんが、初心者はまず「業務の流れを見える化するための図の書き方」と理解すれば十分です。
BPMNを使うと、業務の開始から終了までの流れ、担当者、判断分岐、承認、例外処理などを整理しやすくなります。業務改善、DX推進、システム開発、業務マニュアル作成など、さまざまな場面で活用できます。
この記事でわかること
・BPMNとは何か
・BPMNは何に使うのか
・BPMNの基本的な考え方
・BPMNの使い方
・BPMNの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「BPMNは業務プロセスを見える化するための型だ」とつかめれば十分です。
BPMNとは？
BPMNとは、Business Process Model and Notationの略で、業務プロセスを図で表現するための記法です。
簡単にいうと、BPMNは「業務の流れを誰が見てもわかるように描くための共通ルール」です。
たとえば、社内申請業務を考えてみましょう。申請者が申請書を作成し、上司が確認し、必要に応じて差し戻し、承認されたら経理部門が処理する。この流れを文章だけで説明すると長くなります。
しかし、BPMNを使って図にすると、次のようなことが見えやすくなります。
・業務がどこから始まるのか
・誰がどの作業を担当するのか
・どこで承認や判断が入るのか
・差し戻しや例外処理はどこで起きるのか
・業務がどこで完了するのか
初心者向けに言い換えると、BPMNは「業務の地図」を作るための考え方です。
地図があると、今どこにいて、次にどこへ進めばよいかがわかります。同じように、BPMNを使うと、業務の全体像と流れが見えるようになります。
一言でいうと、BPMNは業務プロセスを図でわかりやすく整理するためのフレームワークです。
BPMNは何に使うのか
BPMNは、業務プロセスを見える化し、改善やシステム化につなげるために使います。
主な用途は次のとおりです。
・現在の業務フローを整理する
・業務のムダや重複を見つける
・承認や判断の流れを明確にする
・部門間の役割分担を整理する
・業務マニュアルを作成する
・システム化する前に業務を可視化する
・RPAやワークフローシステム導入の前提を整理する
・業務改善プロジェクトで関係者の認識を合わせる
・属人化している業務を標準化する
・例外処理や差し戻しのルールを確認する
BPMNは、単に図を描くためのものではありません。業務を見える化することで、どこに問題があるのか、どこを改善すべきかを考えるために使います。
たとえば、ある申請業務で承認に時間がかかっている場合、BPMNで業務の流れを描いてみると、承認者が多すぎる、確認タイミングが遅い、差し戻し条件が曖昧、紙とメールが混在している、といった問題が見えてくることがあります。
どんな人に向いているか
BPMNは、次のような人に向いています。
・業務改善を担当している人
・DX推進に関わっている人
・システム導入を検討している人
・業務フローを整理したい人
・部門間の業務連携を見直したい人
・業務マニュアルを作成する人
・RPAやワークフロー導入を進める人
・現場業務の属人化を解消したい人
・プロジェクトマネージャーやリーダー
・外部ベンダーに業務内容を説明する人
特に、現場業務とIT部門の橋渡しをする人にとって、BPMNは有用です。
システム開発では、業務の流れを理解しないまま機能を作ると、現場に合わない仕組みになりがちです。BPMNを使って業務プロセスを整理しておくと、どの工程をシステム化すべきか、どこは人の判断が必要かを考えやすくなります。
また、BPMNは業務部門の人にも向いています。専門的な記法をすべて覚えなくても、作業、判断、担当者、流れを図で整理するだけで、業務改善の質は大きく上がります。
BPMNの基本的な考え方
BPMNの基本的な考え方は、業務を「イベント」「タスク」「ゲートウェイ」「フロー」「プール・レーン」などの要素で表現することです。
難しく聞こえるかもしれませんが、初心者はまず次の5つを押さえれば十分です。
・イベント
・タスク
・ゲートウェイ
・シーケンスフロー
・プールとレーン
イベント
イベントとは、業務の開始、途中で起きる出来事、終了を表すものです。
たとえば、次のようなものがイベントです。
・申請が提出される
・注文が入る
・問い合わせが届く
・期限が来る
・承認が完了する
・処理が終了する
BPMNでは、業務の始まりと終わりを明確にすることが重要です。どこから業務が始まり、どこで完了するのかが曖昧だと、業務改善もしにくくなります。
タスク
タスクとは、業務の中で行う具体的な作業です。
たとえば、次のようなものがタスクです。
・申請内容を入力する
・上司が内容を確認する
・見積書を作成する
・在庫を確認する
・請求書を発行する
・顧客へメールを送る
タスクは、BPMNの中心となる要素です。業務の流れを整理するときは、どのタスクがどの順番で行われるのかを明確にします。
ゲートウェイ
ゲートウェイとは、業務の分岐や合流を表すものです。
たとえば、次のような判断がゲートウェイです。
・承認するか、差し戻すか
・在庫があるか、ないか
・金額が一定以上か、未満か
・顧客区分が既存顧客か、新規顧客か
・対応が完了したか、追加確認が必要か
業務では、すべてが一本道で進むわけではありません。条件によって処理が変わります。ゲートウェイを使うことで、その分岐を明確にできます。
シーケンスフロー
シーケンスフローとは、業務の流れを示す矢印です。
どのタスクの後にどのタスクが来るのか、どの判断の後にどの処理へ進むのかを表します。
初心者は、まず矢印の向きに注意しましょう。矢印の向きが曖昧だと、業務の順番がわかりにくくなります。
プールとレーン
プールとレーンは、担当者や組織を分けて表現するための枠です。
たとえば、社内申請業務であれば、次のように分けられます。
・申請者
・上司
・経理部門
・システム
各担当者や部門ごとにレーンを分けると、「誰がどの作業を担当しているか」が見えやすくなります。
業務改善では、この担当者の分け方が重要です。なぜなら、業務の停滞や手戻りは、部門間の受け渡し部分で起きやすいからです。
BPMNの使い方
手順1 対象となる業務を決める
まず、BPMNで整理する業務を決めます。
いきなり会社全体の業務を描こうとすると、範囲が広すぎて整理できません。最初は、1つの業務プロセスに絞ることが大切です。
たとえば、次のような単位で考えるとよいでしょう。
・備品購入申請
・見積書作成
・問い合わせ対応
・受注処理
・請求書発行
・採用面接の調整
・社内研修の申込受付
・顧客クレーム対応
対象業務を決めるときは、開始点と終了点もあわせて決めます。
たとえば、備品購入申請であれば、「社員が申請を作成する」から始まり、「購入手続きが完了する」までを対象にする、といった形です。
範囲を明確にすることで、図が大きくなりすぎるのを防げます。
手順2 登場する担当者や部門を洗い出す
次に、その業務に関わる担当者や部門を洗い出します。
たとえば、備品購入申請であれば、次のような関係者が考えられます。
・申請者
・直属の上司
・部門長
・総務部門
・経理部門
・購買担当
・システム
BPMNでは、担当者や部門をレーンで分けると、役割分担が見えやすくなります。
この段階で重要なのは、「実際に業務に関わっている人」を確認することです。理想の流れではなく、まずは現状の流れを正しく把握しましょう。
現場にヒアリングすると、公式ルールには書かれていない確認作業や、担当者の経験で補っている作業が見つかることもあります。
手順3 現在の業務の流れを書き出す
次に、現在の業務の流れを順番に書き出します。
最初からきれいな図にする必要はありません。まずは箇条書きで、実際の作業を並べます。
たとえば、備品購入申請なら次のようになります。
・社員が申請内容を入力する
・上司が内容を確認する
・金額が一定以上なら部門長が承認する
・総務部門が備品の必要性を確認する
・購買担当が発注する
・経理部門が支払処理を行う
・申請者に完了連絡をする
このとき、判断分岐も書き出します。
・承認される場合
・差し戻される場合
・金額が高い場合
・在庫がある場合
・予算が不足している場合
業務改善では、通常の流れだけでなく、例外処理も重要です。例外処理が整理されていないと、現場で混乱が起きやすくなります。
手順4 BPMNの記号に置き換える
業務の流れを書き出したら、BPMNの記号に置き換えます。
初心者は、まず次のように考えれば十分です。
・業務の開始と終了はイベントで表す
・作業はタスクで表す
・判断や分岐はゲートウェイで表す
・流れは矢印でつなぐ
・担当者や部門はレーンで分ける
最初から正式な記法を完璧に使う必要はありません。まずは、業務の流れが関係者に伝わることを重視しましょう。
ただし、図が複雑になりすぎないように注意が必要です。1枚の図にすべてを詰め込むと、かえって読みにくくなります。
複雑な業務では、全体図と詳細図を分けると整理しやすくなります。
手順5 問題点と改善ポイントを見つける
BPMNで業務を可視化したら、問題点を探します。
確認する観点は次のとおりです。
・同じような確認作業が重複していないか
・承認者が多すぎないか
・待ち時間が長い工程はないか
・誰が担当するか曖昧な作業はないか
・紙、Excel、メールが混在していないか
・差し戻し時の流れが明確か
・例外処理が属人化していないか
・システム化できる作業はないか
・人が判断すべき作業と自動化できる作業が分かれているか
BPMNの良いところは、業務のムダや詰まりが見えやすくなることです。
たとえば、図にしてみると、承認のために同じ内容を3人が確認している、メール連絡が多すぎる、入力作業が二重になっている、といった問題が見つかることがあります。
手順6 改善後の業務フローを描く
最後に、改善後の業務フローを描きます。
現状の業務フローを「As-Is」、改善後の業務フローを「To-Be」と呼ぶことがあります。
As-Isでは、今の業務をありのままに描きます。To-Beでは、ムダを減らし、より良い流れにした業務を描きます。
改善後の業務フローでは、次のような観点を考えます。
・不要な承認を減らせないか
・入力作業を一度で済ませられないか
・通知を自動化できないか
・判断ルールを明確にできないか
・ワークフローシステムで管理できないか
・担当者不在時の代替ルートを作れないか
・業務の完了条件を明確にできないか
BPMNは、現状把握だけでなく、改善案を検討するためにも役立ちます。
BPMNの具体例
例 社内申請業務を改善する場合
ある会社では、備品購入申請をメールとExcelで行っていました。
社員がExcelの申請書に必要事項を入力し、上司にメールで送ります。上司が内容を確認し、問題がなければ部門長へ転送します。部門長が承認した後、総務部門が内容を確認し、購買担当が発注します。
しかし、次のような問題がありました。
・申請がどこで止まっているかわからない
・メール転送が多く、見落としが起きる
・承認者が不在だと処理が止まる
・差し戻し時のルールが曖昧
・過去の申請を検索しにくい
・同じ内容を複数の資料に転記している
この業務をBPMNで整理すると、申請者、上司、部門長、総務部門、購買担当というレーンに分けて流れを描けます。
現状の流れは、次のように整理できます。
・申請者が申請書を作成する
・申請者が上司へメール送付する
・上司が内容を確認する
・不備があれば申請者へ差し戻す
・問題がなければ部門長へ転送する
・部門長が承認する
・総務部門が内容を確認する
・購買担当が発注する
・申請者へ完了連絡する
BPMNで図にすると、メール転送が多いこと、承認状況が見えにくいこと、差し戻しルートが曖昧なことがわかります。
改善後の流れは、次のようにできます。
・申請者がワークフローシステムに入力する
・システムが入力必須項目をチェックする
・金額に応じて承認ルートを自動判定する
・上司または部門長に通知する
・承認者が承認または差し戻しを行う
・承認済み申請を総務部門が確認する
・購買担当が発注する
・システムが申請者に完了通知する
このようにBPMNを使うと、現状の問題と改善後の姿を比較しやすくなります。
別の例 問い合わせ対応業務を整理する場合
別の例として、顧客からの問い合わせ対応業務を考えます。
ある会社では、問い合わせがメール、電話、Webフォームから入っていました。担当者が内容を確認し、わかる範囲で回答します。専門的な内容は技術部門に確認し、その結果を顧客へ返信します。
しかし、次のような問題がありました。
・問い合わせの受付経路が複数あり、管理しにくい
・誰が対応中なのかわからない
・回答期限が明確でない
・技術部門への確認が属人化している
・過去の回答履歴が活用されていない
・対応完了の判断基準が曖昧
この業務をBPMNで整理すると、顧客、問い合わせ窓口、担当者、技術部門、管理者というレーンに分けられます。
現状の流れは、次のように整理できます。
・顧客から問い合わせが入る
・問い合わせ窓口が内容を確認する
・担当者を割り当てる
・担当者が回答可能か判断する
・回答可能なら顧客へ返信する
・回答できない場合は技術部門へ確認する
・技術部門が回答案を作成する
・担当者が顧客へ返信する
・対応完了として記録する
BPMNで可視化すると、担当者割り当て、技術部門への確認、回答期限管理の部分に改善余地があるとわかります。
改善後は、次のような流れにできます。
・問い合わせを一元管理システムに登録する
・問い合わせ種別に応じて担当者を自動割り当てする
・回答期限を自動設定する
・担当者がナレッジベースを確認する
・必要に応じて技術部門へ確認依頼する
・回答内容を履歴として保存する
・顧客へ返信する
・管理者が未対応案件を確認する
このようにBPMNを使うと、業務の流れだけでなく、システム化やナレッジ活用のポイントも見つけやすくなります。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・BPMNは業務の全体像を見える化できる
・担当者や部門ごとに役割を整理できる
・承認や判断の分岐を明確にできる
・差し戻しや例外処理を整理できる
・業務のムダ、重複、待ち時間を発見しやすい
・現状業務と改善後業務を比較しやすい
・システム化や自動化の対象を見つけやすい
・業務マニュアルや引き継ぎ資料にも活用できる
BPMNは、単にきれいな業務フロー図を描くためのものではありません。業務を見える化し、改善につなげるために使うことが重要です。
BPMNを使うメリット
BPMNを使うメリットは、業務プロセスを誰にでも理解しやすい形で整理できることです。
主なメリットは次のとおりです。
・業務の全体像を把握しやすくなる
・担当者や部門の役割分担が明確になる
・業務のムダや重複を発見しやすい
・承認や判断の流れを整理できる
・例外処理や差し戻しを明確にできる
・システム化や自動化の検討がしやすくなる
・業務マニュアルや教育資料に使いやすい
・部門間の認識ズレを減らせる
・業務改善の議論が具体的になる
・外部ベンダーに業務内容を説明しやすくなる
特に大きなメリットは、「見えていなかった業務の問題」が見えるようになることです。
業務の問題は、現場では慣れによって見過ごされがちです。メールで確認する、Excelに転記する、上司に口頭で確認する、といった作業は、毎日行っていると当たり前に感じます。
しかし、BPMNで図にしてみると、重複入力、不要な承認、部門間の待ち時間、責任の曖昧さが見えてきます。
そのため、BPMNは業務改善やDXの第一歩として非常に有効です。
BPMNを使うときの注意点
BPMNは便利ですが、使い方を間違えると、読みにくい図になったり、実務に活かせない資料になったりします。
よくある失敗例は次のとおりです。
・最初から完璧な図を描こうとする
・業務範囲が広すぎて図が複雑になる
・現場に確認せず、想像で業務フローを描く
・例外処理や差し戻しを省略してしまう
・担当者や部門の役割が曖昧なまま描く
・図を作るだけで改善につなげない
・BPMNの記法にこだわりすぎて議論が止まる
・更新されないまま古い業務フローが残る
・理想の流れだけを描き、現状の問題を見ない
・読み手にとって細かすぎる図になる
特に注意したいのは、「現状業務を正しく描くこと」です。
業務改善を急ぐあまり、最初から理想の業務フローだけを描いてしまうことがあります。しかし、現状を正しく把握しないまま改善案を作ると、現場で使えない仕組みになる可能性があります。
また、BPMNは業務を見える化する道具であって、描くだけで改善が進むわけではありません。図にした後に、どこを減らすか、どこを自動化するか、どこにルールを作るかを考えることが重要です。
関連フレームワークとの違い
BPMNと関連するフレームワークには、UML、要件定義フレーム、DFD、CRUDマトリクス、ITILなどがあります。それぞれ目的が異なります。
UMLとの違い
UMLは、システムの構造や動きを図で表現するための記法です。ユースケース図、クラス図、シーケンス図など、複数の図があります。
BPMNは、特に業務プロセスの流れを表現することに向いています。
UMLがシステム設計全体に使える幅広い記法だとすれば、BPMNは業務フローの可視化に特化した記法です。業務部門との会話では、BPMNのほうが直感的に使いやすい場面も多くあります。
要件定義フレームとの違い
要件定義フレームは、業務要件、機能要件、非機能要件を整理するための考え方です。
BPMNは、その中でも特に業務要件を整理する場面で役立ちます。
たとえば、システム開発の前にBPMNで業務プロセスを可視化すると、どの工程をシステム化すべきか、どの機能が必要かを考えやすくなります。
要件定義フレームが「何を実現するか」を整理するものだとすれば、BPMNは「業務がどのように流れているか」を見える化するものです。
DFDとの違い
DFDは、データの流れに注目してシステムを整理する図です。
BPMNは、業務の流れ、担当者、判断分岐、作業順序を整理します。一方、DFDは、入力データ、処理、データストア、出力データの関係を整理します。
たとえば、受注業務を考える場合、BPMNでは「誰がどの順番で処理するか」を見ます。DFDでは「注文データがどこから入り、どの処理を通り、どこへ保存されるか」を見ます。
CRUDマトリクスとの違い
CRUDマトリクスは、データに対して作成、参照、更新、削除のどの操作が必要かを整理するための表です。
BPMNで業務の流れを整理した後に、CRUDマトリクスを使うと、どの工程でどのデータを扱うのかを確認できます。
BPMNは業務フローの整理に強く、CRUDマトリクスはデータ操作の抜け漏れ確認に強いと考えると分かりやすいです。
ITILとの違い
ITILは、ITサービス管理のベストプラクティスを整理したフレームワークです。
BPMNは業務プロセスを図で表すための記法です。ITILの中で扱うインシデント管理、変更管理、問題管理などのプロセスを可視化する際に、BPMNを使うことがあります。
つまり、ITILはITサービス管理の考え方であり、BPMNはそのプロセスを見える化するための手段として使えます。
BPMNはどんな場面で使うと効果的か
BPMNは、次のような場面で使うと効果的です。
・業務改善プロジェクトを始めるとき
・DX推進で現状業務を整理するとき
・システム導入前に業務フローを確認するとき
・ワークフローシステムを設計するとき
・RPA導入前に自動化対象を探すとき
・部門間の業務連携を見直すとき
・承認プロセスを整理するとき
・問い合わせ対応や受注処理を標準化するとき
・業務マニュアルを作成するとき
・新人や異動者向けに業務を説明するとき
特に効果的なのは、複数部門が関わる業務です。
部門をまたぐ業務では、どこで情報が止まっているのか、誰が判断しているのか、どこで手戻りが発生しているのかが見えにくくなります。BPMNを使うと、その流れを見える化できます。
また、RPAやAI、ワークフローシステムなどを導入する前にも有効です。業務が整理されていない状態でツールを導入しても、効果が出にくいからです。まずBPMNで業務を整理し、自動化できる部分と人が判断すべき部分を分けることが重要です。
まとめ
BPMNとは、業務プロセスを図でわかりやすく整理するためのフレームワークです。
業務の開始から終了までの流れ、担当者、作業、判断分岐、差し戻し、例外処理などを見える化できます。
BPMNを使うことで、普段は見えにくい業務のムダや重複、待ち時間、責任の曖昧さを発見しやすくなります。また、業務改善、DX推進、システム導入、RPA導入、業務マニュアル作成など、さまざまな場面で活用できます。
初心者が最初に覚えるべきことは、イベント、タスク、ゲートウェイ、シーケンスフロー、プール・レーンの基本です。これだけでも、業務の流れをかなり整理できます。
大切なのは、BPMNをきれいに描くことではなく、業務の実態を正しく見える化し、改善につなげることです。
まずは、自分の身近な業務を1つ選び、「誰が、何を、どの順番で行っているか」を書き出すところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
要件定義フレームとは？初心者向けに意味・使い方・具体例をやさしく解説
UMLとは？初心者向けに意味・使い方・具体例をやさしく解説
DFDとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
