業務フロー図の書き方：システム化の前に現状を可視化する手順

業務フロー図は、きれいに描くことが目的ではありません。誰が、何をきっかけに、どんな作業や判断をして、どの帳票やデータを誰に渡しているのかを一枚に並べ、関係者の認識をそろえ、システム化すべき箇所を見つけるための道具です。書き方の作法より、「何を描き、何を描かないか」と「描いた図をどう読むか」を押さえることが大切です。

この記事は、社内業務のシステム化や業務改善を任された担当者で、これから業務フロー図を作ろうとしている方に向けて書いています。書き始める前の準備、使う記号とレーンの決め方、ヒアリングから清書までの手順、図からシステム化の対象を読み取る方法、よくある失敗と避け方を、具体的な例を交えて説明します。

結論を先に言うと、業務フロー図は「範囲を決める」「担当者をレーンに並べる」「作業と判断を時間順に置く」「帳票とシステムを書き添える」「例外の分岐を足す」の順に作り、完成した図を「転記」「待ち」「判断の集中」「同じ情報の重複入力」の四つの観点で読むと、システム化の対象が見えてきます。

業務フロー図とは何か、なぜシステム化の前に必要か

業務フロー図とは、業務の流れを、担当者ごとの作業と判断の順番として図に表したものです。用語としての説明は業務フロー図のページにまとめています。

システム化の前に業務フロー図が必要になる理由は三つあります。

• 認識をそろえるため：同じ業務でも、担当者、管理者、開発会社がそれぞれ別の姿を思い浮かべています。図にすることで、どこが一致していてどこがずれているかが分かります。
• 抜けている作業や例外を見つけるため：文章で業務を説明すると、当たり前すぎる作業や、たまにしか起きない例外が抜け落ちます。図にして順番に並べると、「この間に何をしているのか」という空白が目立ちます。
• システム化の対象を選ぶため：転記や待ち時間、確認の重複など、システムで解消できる箇所は図の上で見つけやすくなります。

業務フロー図は、業務を見える形にする取り組みの中心的な道具です。業務の可視化全体の進め方については、業務の可視化や業務可視化の方法：自動化の前に行う作業時間調査とヒアリングも参考にしてください。

書き始める前に決めておくこと

いきなり描き始めると、範囲が広がりすぎたり、細かさがばらついたりして、まとまらない図になります。描く前に次の四つを決めます。

1. 対象業務の始まりと終わり

「受注業務」のような大きな括りではなく、「顧客から注文のメールが届いてから、倉庫に出荷指示を出すまで」のように、始まりと終わりの出来事で範囲を決めます。範囲を決めておくと、話が前後の業務に広がったときに「それは別の図で扱う」と線を引けます。

2. 図の目的

認識合わせのための図なのか、システムの要件を決めるための図なのか、業務マニュアルとして使う図なのかで、必要な細かさが変わります。システム化の前段階であれば、画面操作の一つひとつまでは不要ですが、「どの情報をどこから見て、どこに書くか」は必要です。

3. 細かさの単位

一つの箱に書く作業の大きさをそろえます。目安は「一人の担当者が、一つのきっかけで、まとまって行う作業」です。「受注内容を確認する」と「メールを開く」「添付ファイルを開く」が同じ図に混在すると、読みにくくなります。

4. 記号のルール

社内で使う記号を最小限に決めます。標準的な表記法としてBPMN（ビジネスプロセスモデリング表記法）がありますが、関係者全員が知っているとは限りません。システム化の前の認識合わせであれば、次の表のような少ない記号で十分です。

色の使い方も決めておくと読みやすくなります。たとえば、課題のある作業は赤、システムで処理している作業は青、というように意味を持たせ、凡例に書いておきます。

記号を増やすほど正確に描けるように見えますが、読む人の負担も増えます。凡例を図の隅に必ず添え、それ以外の記号は使わないと決めておくと、複数の人が描いても図がそろいます。

業務フロー図の書き方：ヒアリングから清書までの手順

ここからは、実際に図を作る手順を順番に説明します。

1. 担当者・部署をレーンとして並べる：対象業務に関わる人や部署を洗い出し、上から順に横長のレーンとして並べます。顧客や取引先など社外の関係者も、業務のきっかけや受け渡し先になるなら一番上か一番下にレーンを設けます。システムをレーンとして扱う書き方もありますが、最初は人と部署だけで始め、システムは作業の横に書き添える方が分かりやすくなります。
2. 開始と終了の出来事を置く：範囲として決めた始まりと終わりを、該当するレーンの左端と右端に置きます。
3. 通常の流れの作業を時間順に置く：例外は後回しにし、最もよくある流れだけを、左から右へ時間順に並べます。各作業は「何を」「どうする」の形で、動詞で終わるように書きます。
4. 判断の分岐を加える：作業の途中で判断が入るところにひし形を置き、「はい」「いいえ」の分岐先を書きます。判断の基準が文書になっていない場合は、図の横に「判断基準：担当者の経験」とメモしておきます。
5. 帳票とシステムを書き添える：各作業で使う帳票、ファイル、システムを、作業の箱の横に書き添えます。「何を見て」「何に書くか」が分かるようにすることが、システム化の検討では特に重要です。
6. 例外の流れを足す：差し戻し、取り消し、急ぎ対応、情報不足時の問い合わせなど、通常の流れから外れるケースを足していきます。すべてを一枚に入れると読みにくくなる場合は、主要な例外だけを本図に入れ、残りは別紙にまとめます。
7. 時間と頻度を書き込む：作業ごとのおおよその所要時間、待ち時間、一日や一か月あたりの件数を書き込みます。正確な計測でなくても、担当者の感覚で構いません。
8. 関係者に確認してもらう：描いた図を担当者に見せ、「この順番で合っているか」「抜けている作業はないか」を確認してもらいます。確認の場で出た修正は、その場で図に書き込みます。
9. 清書して版を管理する：確認が済んだら清書し、作成日と版、作成者を記載します。業務が変われば図も更新するため、最新版がどれか分かるようにしておきます。

ヒアリングで図を使うコツ

最初から完成した図を持って行くより、付箋やホワイトボードを使い、担当者と一緒に作業を並べていく方が、抜けや誤解を見つけやすくなります。担当者が「この前にこれをやっています」と言いながら付箋を足していくと、説明だけでは出てこなかった作業が自然に出てきます。オンラインの場合は、共同編集できる作図ツールの画面を共有しながら進めます。

ヒアリングの場では、「普段はどうしていますか」と「うまくいかないときはどうしていますか」を必ずセットで聞きます。前者で通常の流れが、後者で例外の流れが出てきます。担当者が「たまに」と言った作業は、どのくらいの頻度なのかをその場で確かめておくと、後で優先順位を付けるときに迷いません。

架空の例：問い合わせから見積もり提出までのフロー

部品加工を請け負う会社の、問い合わせから見積もり提出までの業務を例に考えます。レーンは「顧客」「営業」「技術担当」「上長」の四つです。

通常の流れは次のようになります。顧客から図面つきの問い合わせメールが届く。営業がメールの内容を問い合わせ管理表（Excel）に転記する。営業が図面を技術担当に転送し、加工可否と工数の確認を依頼する。技術担当が図面を見て工数を見積もり、結果をメールで営業に返す。営業が工数をもとに見積書を作成する。金額が一定額を超える場合は上長が確認する。営業が見積書を顧客にメールで送り、問い合わせ管理表のステータスを更新する。

この流れを図にすると、いくつかの点が目に入ります。問い合わせの内容が、メール、問い合わせ管理表、技術担当への転送メール、見積書と、四か所に繰り返し書かれていること。技術担当の確認待ちの間、営業は進捗が分からず、顧客からの催促に答えられないこと。上長の確認が口頭で行われ、記録に残っていないこと。図にする前は「見積もりに時間がかかる」という漠然とした不満でしたが、図にしたことで、どこで時間がかかり、どこで情報が重複しているのかを具体的に指させるようになりました。

さらに例外を足していくと、別の事実も見えてきます。図面が不鮮明で技術担当が判断できない場合、営業を経由して顧客に問い合わせ直しており、その間の経緯がどこにも記録されていません。急ぎの案件では営業が技術担当に直接口頭で依頼しており、問い合わせ管理表の更新が後回しになっています。こうした例外は、通常の流れの図だけでは表に出てきませんが、システム化した後に「例外のときだけ管理表の外で処理される」という二重管理の原因になります。例外の流れまで描いておくことで、システムに必要な機能（差し戻しの記録、急ぎ案件の印など）が具体的になります。

完成した図からシステム化の対象を読み取る

業務フロー図は、描いて終わりではありません。システム化の対象を探す目で読み直します。次の四つの観点が特に有効です。

この四つの観点で印を付けていくと、システムで解消できる箇所と、運用ルールの見直しで解消できる箇所が分かれてきます。先の例であれば、問い合わせ情報の一元管理（転記の解消）、技術担当への依頼と回答の状況管理（待ちの見える化）、上長確認の記録（判断の記録）がシステム化の候補になります。一方、金額の確認基準を明文化することは、システムを作らなくてもできる改善です。

見つけた候補に優先順位を付ける

候補が見つかったら、すべてを一度にシステム化しようとせず、優先順位を付けます。図に書き込んだ件数と所要時間がここで役に立ちます。件数が多く一件あたりの時間も長い作業、ミスが起きると顧客や取引先に影響が出る作業、特定の人しかできず休むと止まる作業は、優先度が高くなります。反対に、月に数回しか発生せず、手作業でも困っていない作業は、後回しにしても問題ありません。

優先順位を付ける際は、「システムを作らないと解消できないか」も確認します。たとえば、同じ確認を二人が行っているなら、役割分担を決め直すだけで解消できるかもしれません。判断基準が人の頭の中にあるなら、まず基準を書き出して共有するだけで、判断の待ちが減ることもあります。図の上で印を付けた箇所を、「システムで解消」「運用の見直しで解消」「当面は現状維持」の三つに振り分けておくと、開発の範囲が過不足なく決まります。

現状の図（As-Is）からあるべき姿の図（To-Be）を描き、その差分を要件にしていく進め方は、As-Is/To-Be分析で業務システムの要件を固める進め方と注意点で詳しく説明しています。

業務フロー図を開発会社との打ち合わせで活かす

システム化を外部に依頼する場合、業務フロー図は最も役に立つ説明資料になります。文章だけの要望書では、開発会社は業務の流れを想像で補うしかなく、見積もりや提案の前提がずれやすくなります。業務フロー図があれば、どの作業をシステムに置き換えたいのか、どこは人の作業として残るのかを、図の上で指さしながら確認できます。

打ち合わせで図を使うときは、現状の図と、システム化後に想定している流れの図を並べて見せると効果的です。「この転記の作業がなくなる」「この待ちが通知に置き換わる」といった変化が具体的になり、開発会社からも「この判断は自動化できるが、この例外は人に残した方がよい」といった提案を引き出しやすくなります。また、図に書き込んだ件数や所要時間は、処理量の見積もりや、画面の操作性をどこまで重視すべきかの判断材料にもなります。

注意したいのは、図を渡して終わりにしないことです。図には描ききれない判断の背景や、例外が起きる事情があります。開発会社の担当者に図を説明する場を設け、質問を受けながら補足すると、認識のずれを早い段階でつぶせます。説明の場で出た質問と回答は、図の注記や別紙に追記しておくと、後から参加した人にも伝わります。

よくある失敗とその避け方

• 理想の業務を描いてしまう：現状の図のはずが、「本来はこうするはず」という手順で描かれ、実態とずれます。現状の図では、非効率に見える手順や例外もありのまま描くことを関係者と確認しておきます。
• 細かさがばらばら：ある部分は画面操作まで、別の部分は「処理する」の一言、という図は比較ができません。書き始める前に決めた細かさの単位を守り、迷ったら一段粗い方にそろえます。
• 例外を描かない：通常の流れだけの図は見やすいですが、システム化で問題になるのは例外です。主要な例外は必ず描き、残りは別紙で一覧にします。
• 一人で描いて終わる：担当者の確認を経ていない図は、作成者の理解を描いたものにすぎません。必ず関係者に見せて修正します。
• 図が更新されない：業務が変わっても図が古いままだと、誰も見なくなります。業務やシステムを変えたときに図を更新する担当を決めておきます。
• 作図ツールの使い方に時間を取られる：最初はホワイトボードや付箋、表計算ソフトで十分です。清書の段階で、社内で使い慣れたツールに移します。

業務フロー図の確認チェックリスト

図ができたら、次の項目を確認してください。

• 対象業務の始まりと終わりが明記されている
• 関係する担当者・部署がすべてレーンとして並んでいる
• 各作業が「何をどうする」の形で書かれている
• 判断の箇所に分岐先と、分かる範囲で判断基準が書かれている
• 各作業で使う帳票・ファイル・システムが書き添えられている
• 主要な例外（差し戻し、取り消し、急ぎ対応）の流れがある
• おおよその所要時間と件数が書き込まれている
• 担当者の確認を経ており、作成日と版が記載されている
• 凡例があり、凡例以外の記号を使っていない

よくある質問

Q. どのツールで描けばよいですか？

特定のツールである必要はありません。関係者が閲覧・編集でき、更新しやすいものを選びます。最初は付箋やホワイトボードで流れを固め、清書の段階で作図ツールや表計算ソフト、プレゼンテーションソフトなどに移すと、ツールの操作に気を取られずに中身に集中できます。

Q. BPMNのような標準の表記法を使うべきですか？

関係者がその表記法を理解しているなら、使うことで正確さが増します。ただし、現場の担当者に確認してもらう段階では、記号の意味を説明する負担が大きくなることがあります。システム化の前の認識合わせであれば、少ない記号の独自ルールで始め、必要に応じて標準の表記法に寄せる方法が現実的です。

Q. 一枚に収まらないほど大きな業務はどうしますか？

全体の流れを粗く描いた概要図を一枚作り、その中の各工程を詳しく描いた図を別に作る、という階層に分けます。概要図には詳細図の番号を書いておくと、行き来しやすくなります。

Q. 担当者によってやり方が違う場合は、どちらを描けばよいですか？

現状の図では、違いがあることを記録することが重要です。主要なやり方を本図に描き、違うやり方を注記として残します。どちらを標準にするかは、あるべき姿を検討する段階で決めます。

Otsumuに相談できること

対象業務が一つの部署の中で完結しており、関係者が数人程度であれば、この記事の手順で社内の担当者が業務フロー図を作ることは十分に可能です。付箋とホワイトボードから始め、担当者と一緒に作業を並べてみてください。図を作る過程そのものが、業務の見直しのきっかけになります。

一方で、複数の部署や社外の取引先が関わる業務、担当者ごとにやり方が大きく違う業務、図はできたもののどこをシステム化すべきか判断がつかない、という場合は、第三者が入ってヒアリングと整理を進めた方が早く進むことがあります。社内の立場からは聞きにくいことも、外部の聞き手であれば聞きやすくなる面もあります。

Otsumuは、現場ヒアリングと業務フロー図の作成から一緒に行い、図をもとにシステム化の対象と運用の見直しで解消できる部分を切り分けたうえで、目的に必要な機能に絞った開発につなげます。業務システムの開発については業務システム開発のページで紹介しています。費用は範囲に応じて個別にお見積もりします。

業務のどこから見直せばよいか分からないという段階でもご相談いただけます。30分の無料相談からご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01