業務フロー図は、作業名を順番に並べるだけでは完成しません。誰が処理し、次に誰へ渡し、何を条件に分岐し、不備があれば誰へ返してどこから再開するかまでつなぎます。最後に完了地点を決めれば、担当間で仕事が宙に浮く箇所を確認できます。
この記事では、架空の「社内の備品購入申請」を一つだけ使い、曖昧なメモから担当別の業務フロー図を作ります。人物、金額、必須項目、社内ルールはすべて説明用の架空設定であり、実在企業の規程や実務例ではありません。実務で作るときは、現在の規程、権限、承認条件を確認し、現場の担当者にも確かめてください。
完成した業務フロー図の例
最初に、この事例の範囲とルールを決めます。業務の開始は「申請者が備品を必要としたとき」、完了は「総務担当が購入手配を登録し、申請者へ受付完了を通知したとき」です。「上司が承認した」「総務へ送った」「総務が受け付けた」だけでは完了にしません。
架空のルールは次の三つです。
- 総務の在庫品で対応できる場合は購入申請を作らず、在庫品の受け渡しでこのフローを終了する。
- 申請には、品名、数量、用途、見込金額の四項目が必要である。
- 四項目がそろい、見込金額が3万円以下なら上司が承認できる。3万円を超える場合は、この図の対象外である別の購買相談へ移す。
実際の申請要否、金額基準、承認者は会社ごとに異なります。この設定をそのまま自社ルールにしないでください。
スマートフォンでも追えるテキストフロー
開始：申請者が備品を必要とする
↓
申請者が総務担当へ在庫を確認する
↓
【総務の在庫品で対応できる？】
├ YES → 総務担当が在庫品を渡す → 申請者が受け取る → 終了：購入申請不要
└ NO → 申請者が品名・数量・用途・見込金額を入力する
↓
上司へ提出する
↓
【必須四項目がそろっている？】
├ NO → 上司が不足項目を示して申請者へ差し戻す
│ ↓
│ 申請者が不足項目を修正する
│ ↓
│ 「上司が必須四項目を確認する」へ戻る
└ YES → 【見込金額は3万円以下？】
├ NO → 上司が申請者へ別の購買相談が必要と通知する → 終了：別フローへ移行
└ YES → 上司が承認する → 総務担当へ渡す
↓
総務担当が申請を受け付け、購入手配を登録する
↓
申請者へ受付完了を通知する
↓
終了：購入手配の登録・通知完了
この図で「終了」は三つあります。通常経路の完了、申請不要での終了、対象外の別フローへの移行です。どれも行き先を明示し、途中で矢印を切っていません。なお、通常経路の完了は備品の納品や代金支払いではなく、あらかじめ定めた「購入手配の登録・通知完了」です。
担当別の流れを表で確認する
| 担当 | 処理・判断 | 次の行き先 |
|---|---|---|
| 申請者 | 必要な備品を特定し、総務へ在庫を確認する | 総務担当の在庫確認へ |
| 総務担当 | 在庫品で対応できるか判断する | YES：在庫品を渡して終了 NO：申請者の申請作成へ |
| 申請者 | 品名・数量・用途・見込金額を入力する | 上司の必須項目確認へ |
| 上司 | 必須四項目がそろっているか確認する | YES：金額確認へ NO：不足項目を示して申請者へ |
| 申請者 | 指摘された不足項目を修正する | 上司の必須項目確認へ戻る |
| 上司 | 見込金額が3万円以下か判断する | YES：承認して総務担当へ NO：別の購買相談へ移す |
| 総務担当 | 申請を受け付け、購入手配を登録する | 申請者へ受付完了を通知して終了 |
使う記号は最小限でよい
- 開始・終了：業務の入口と出口を示す。
- 処理：「上司」ではなく「上司が必須項目を確認する」のように、担当と動作を書く。
- 判断：YES／NOなどで答えられる条件を書く。
- 矢印：次の処理、担当間の受け渡し、差し戻し後の戻り先を示す。
複雑な記号を覚えることより、同じ記号を同じ意味で使い、すべての経路を追えることが重要です。
元の説明だけでは業務フロー図にできない理由
Step 1：元の曖昧な説明
備品が必要になったら申請して、上司に確認してもらい、総務へ回します。不備があれば修正してください。
大まかな順番は分かりますが、このまま箱と矢印に置き換えると、判断条件と戻り先がない図になります。
Step 2：分からないことを洗い出す
- 誰が、何をきっかけに開始するのか。
- 在庫品がある場合も購入申請を作るのか。
- 申請者は何を入力するのか。
- 上司は何がそろっているか確認するのか。
- 何をもって承認できるのか。
- 不備があれば、誰が誰へ返すのか。
- 申請者が修正した後、どの確認から再開するのか。
- 総務へ渡った後、受付、購入手配、納品のどこを完了とするのか。
分からない点は、作図者が都合よく埋めるのではなく、規程や権限を確認し、担当者へ質問します。この記事では作成過程を示すため、前述の架空ルールで回答が得られたものとして先へ進めています。
Step 3：担当と処理を並べる
担当は「申請者」「上司」「総務担当」の三者に絞ります。そのうえで、「申請者が申請内容を作成する」「上司が必須項目を確認する」のように、各担当が行う処理を書きます。「上司」は担当名であり、処理名ではありません。
Step 4：判断点を加える
この事例では、「在庫品で対応できる？」「必須四項目がそろっている？」「見込金額は3万円以下？」の三つを判断点にします。単に「承認するか判断」と書かず、YESならどこへ進み、NOならどこへ進むかを決めます。
Step 5：差し戻しと再開地点を加える
必須項目が不足していれば、上司から申請者へ差し戻します。申請者は不足項目を直し、申請作成の最初からではなく、上司による必須四項目の確認へ戻ります。返す相手と再開地点の両方が必要です。
Step 6：開始から終了まで経路を確認する
- 通常：在庫なし → 申請作成 → 必須項目あり → 3万円以下 → 承認 → 総務が購入手配を登録・通知 → 完了。
- 差し戻し：在庫なし → 申請作成 → 必須項目不足 → 申請者が修正 → 上司の必須項目確認へ戻る → 以後は条件に応じて進む。
- 申請不要：在庫あり → 総務が在庫品を渡す → 申請者が受け取る → 終了。
- 金額基準外：必須項目あり → 3万円超 → 申請者へ別の購買相談が必要と通知 → この図は終了。
業務フロー図の作り方
1．開始と完了を決める
「備品購入」のような広い名前だけで始めず、何が起きたら開始し、何が確認できたら終わるかを書きます。納品まで扱わないなら、図の外にある納品工程を完了扱いにしないようにします。
2．登場する担当を絞る
処理や判断を実際に持つ担当だけを並べます。関係者を増やす前に、その人がこの図の中で何をするか確認します。役割や責任の種類を整理することが目的なら、後述するRACIが向いています。
3．処理を時系列に並べる
「申請者」「上司」のような担当名だけでなく、「申請者が必須項目を入力する」「上司が必須項目を確認する」と動作まで書きます。細かな画面操作や入力手順をすべて詰め込まず、流れが変わる処理と受け渡しを優先します。
4．判断条件を加える
判断は「確認する」「問題ないか」のような曖昧な言葉で終わらせません。確認対象と条件を文章にし、各出口へYES／NOなどのラベルを付けます。基準が不明なら、図の中で新しく決めず、規程や権限者へ確認します。
5．担当間の受け渡しを確認する
レーンや表の担当が変わる箇所で、何を渡すかを確認します。この例では、申請者から上司へ「四項目を入力した申請」、上司から総務へ「承認済みの申請」を渡します。矢印の先に受け取る担当の処理がなければ、誰が仕事を持っているか分からなくなります。
6．差し戻しと再開地点を書く
戻りの矢印には、戻す条件、返す相手、相手が直す内容、修正後の再開地点を書きます。「不備なら差し戻し」だけでは、申請者が修正後に上司へ再提出するのか、総務へ直接送るのか判断できません。
7．代表経路をたどる
通常経路だけでなく、差し戻しと主要な別分岐を開始から終了まで指でたどります。すべての判断に出口があり、途中で担当が消えず、定義した終了へ着くことを確認します。
差し戻しのあるフローを書くポイント
差し戻しは、仕事が逆向きに移る受け渡しです。戻り先が曖昧だと、修正されないまま止まるか、確認を飛ばして次工程へ進むおそれがあります。
悪い例
不備なら差し戻す。
不備の条件、返す相手、直す内容、再確認する担当が分かりません。
良い例
品名・数量・用途・見込金額のいずれかが不足していれば、上司が不足項目を示して申請者へ返す。申請者が不足項目を修正し、上司の必須四項目確認へ戻る。
良い例では、一周した後に同じ判断点へ戻るため、修正内容が再確認されます。「修正 → 総務へ」のように承認確認を飛ばしていないことも追えます。
差し戻しが多い事実を見つけても、原因を図だけで断定しないでください。どこで滞留しているか調べる場合は、件数や待ち時間を確認したうえでボトルネックの見つけ方へ進みます。
コピーして使える業務フロー整理用ひな形
図形を置く前に、次の項目を埋めます。分からない欄は推測せず、確認事項として残してください。
【業務名】
【開始条件】
【完了条件】
【担当1】
処理：
次の担当：
判断条件：
【担当2】
処理：
YESの場合：
NOの場合：
【差し戻し】
誰から：
誰へ：
戻す条件：
修正後の再開地点：
【確認する経路】
通常：
差し戻し：
その他：
業務フロー図を確認する方法
完成したら、開始地点から矢印を一つずつたどります。通常経路、差し戻し経路、別分岐をそれぞれ確認し、途中に次の状態がないかを見ます。
- 処理はあるが、誰が持っているのか分からない。
- 担当が変わるのに、渡す先または受け取った後の処理がない。
- 判断点のYESまたはNOに行き先がない。
- 「差し戻し」の後に、返す相手や再開地点がない。
- 「総務へ送る」などの中間地点で線が終わり、完了条件がない。
これは、書かれた架空条件を使った机上確認です。実際の利用者が迷わず処理できることを確かめた実利用確認ではありません。実務では、現場担当者と図を読み合わせ、現在の規程・権限・承認条件と一致するかを確認してください。
業務手順書・RACI・WBSとの使い分け
- 業務手順書：一つの定常業務を実行できるよう、準備、具体的な操作、判断、例外、完了条件を書く。業務フロー図には入りきらない担当内の細かな操作を補う。
- RACI：作業ごとに実行責任、説明責任、相談先、報告先を整理する。業務フロー図は、その担当間を仕事がどの順番で移るかを示す。
- WBS：案件の仕事や成果物を管理可能な単位へ分解する。業務フロー図は、作業の順序、判断、受け渡し、戻りをつなぐ。
- 業務棚卸し表：現在どのような業務があるかを一覧にする。棚卸し後、詳しく見る一つの業務を選んでフロー図にする。
担当交代時点の現在地・残件・次の一手を渡す資料は業務引き継ぎ表です。業務フロー図は、特定の交代時点ではなく、通常運用として仕事が担当間をどう流れるかを表します。
まとめ
業務フロー図の目的は、きれいな図形を並べることではありません。開始と完了を決め、担当と処理を分け、判断条件とすべての行き先をつなぎます。特に差し戻しは、誰から誰へ返すか、何を直すか、修正後どこから再開するかまで書いてください。
図にすべての操作を詰め込まず、流れが変わる処理、担当間の受け渡し、判断、差し戻し、完了を優先します。規程や判断基準が分からない箇所は勝手に補わず、現場担当者と権限者へ確認してから図へ反映しましょう。
