業務フローの作り方：記号・具体例・改善手順をわかりやすく解説

業務フローとは、仕事の開始から終了までを、担当・処理・判断・情報の受け渡しとともに見える化したものです。 作る目的は、関係者の認識をそろえ、引き継ぎや改善の論点を発見すること。最初に決めるのは図形ではなく、「どの業務を、誰が、どの開始条件からどの完了条件まで確認するか」という範囲です。

対象読者は、業務改善を任された現場リーダー、部門横断プロジェクトの担当者、手順を引き継ぐ人です。業務プロセスや手順書との違いから、基本記号、受注から納品までの具体例、As-Is／To-Beによる改善、レビュー、更新方法までを一つの流れで解説します。数値を使う例はすべて仮想ケースとして明示し、AFFiNEについても実際に確認した手動操作だけを記載します。

要点

• 目的、読者、開始・終了、対象部署を決めてから作図する。
• 処理、判断、入出力、担当、矢印を少数の規則で統一する。
• 正常系だけでなく、差し戻し、欠品、承認否決などの例外を描く。
• As-IsとTo-Beは同じ範囲・担当・測定項目で比較する。
• 公開日、オーナー、次回レビュー、修正窓口を付けて更新可能にする。

目次

1. 業務フローと似た用語の違い
2. 業務フロー図の基本記号とルール
3. 受注から納品までの具体例
4. 業務フローの作り方：7ステップ
5. As-Is／To-Beで改善点を見つける
6. 部門横断レビューの失敗と修正
7. AFFiNEで文書と視覚スペースを組み合わせる
8. コピーして使える確認リスト
9. よくある質問

業務フロー・業務プロセス・手順書・フローチャートの違い

似た言葉を混同すると、読み手が図に期待する情報がずれます。業務フローは「誰が、何を、どの順番で、どの情報を受け渡すか」を図で追うものです。業務プロセスは、顧客への価値や成果を生む活動全体を指し、図だけでなく目的、指標、責任、ルールも含みます。手順書は一つの作業を再現するための操作詳細、フローチャートは処理と判断の流れを表す一般的な図法です。

たとえば「与信を確認する」という箱だけでは、業務フローとしては不十分です。営業が申請し、経理が何を根拠に判断し、否決時にどこへ戻し、承認結果を誰へ渡すかまで示して初めて、部門横断の合意に使えます。一方、使用するシステムのボタン位置や入力例は、箱からリンクした業務マニュアルのテンプレートへ分離すると、全体図を読みやすく保てます。

ISOの品質マネジメント原則も、相互に関係するプロセスを一つの仕組みとして理解・管理し、データに基づいて改善する考え方を示しています。業務フロー図はその入口ですが、図を作っただけで品質や効率が上がるわけではありません。目的、指標、レビュー、更新までを業務プロセスとして運用する必要があります。

業務フロー図の基本記号と書き方のルール

記号は多いほど専門的に見えますが、読み手が覚える規則も増えます。社内の一般的な業務フローなら、開始／終了、処理、判断、入出力、担当レーン、矢印、文書の7種類程度から始めると十分です。ISO 5807は情報処理文書のフローチャート記号と使用上の規約を定める国際規格です。本記事は規格全文を代替せず、部門横断の実務で迷いにくい最小構成へ絞っています。

図形より大切なのが文言です。処理は「名詞＋する」ではなく、「担当が目的語に何をするか」が分かる動詞で書きます。「確認」より「営業が注文の必須項目を確認する」、「連絡」より「営業が欠品予定日を顧客へ通知する」の方が、責任と完了条件を確認できます。

判断の出口には必ず条件を書きます。「正常／異常」だけでは担当者ごとに解釈が変わります。「在庫数が注文数以上か」「与信限度内か」のように観察可能な条件へ直してください。線が交差する場合はレーンの順序を変え、戻り線には戻す理由と戻り先を示します。複雑になったら、全体図と例外詳細図を分けます。

業務フローの具体例：受注から納品まで

ここからは、架空の卸売会社を想定した具体例です。営業、在庫管理、経理、出荷の4部門、平日30件の注文、通常リードタイム2営業日という数値は説明用の仮定で、AFFiNEや実在企業の実績ではありません。 目的は、注文を受けてから納品通知を送るまでの担当、判断、例外をそろえることです。

正常系の流れ

1. 開始：営業が注文を受領する。 注文番号、顧客、商品、数量、希望日を一つの受付記録へ入力します。
2. 判断：必須項目がそろっているか。 不足なら営業が顧客へ確認し、同じ受付記録へ戻します。そろっていれば在庫管理へ渡します。
3. 判断：在庫を確保できるか。 確保できれば引当結果を記録します。できなければ、在庫管理が入荷予定を営業へ返し、営業が分納、納期変更、キャンセルの選択肢を顧客と確認します。
4. 判断：与信条件を満たすか。 経理が限度額や支払状況を確認します。承認なら出荷へ、保留なら追加確認へ、否決なら理由コードを営業へ返します。
5. 処理：出荷を準備する。 出荷担当が商品、送り先、納期、梱包条件を照合し、発送記録を作成します。
6. 終了：納品通知を送信する。 営業または出荷担当が合意した責任分担に従って、顧客へ追跡情報と納品予定を通知します。

この例で重要なのは、成功する一本道より戻り先です。必須項目不足は営業へ、欠品は納期選択へ、与信保留は経理の追加確認へ戻します。「担当者が判断する」とだけ書かず、判断に使う情報と、結果を記録する場所を指定します。会議で決まった条件は、後から追えるようAI議事録の整理方法などを参考に、フローの版と決定記録を結び付けます。

コピー用の例外記録

• 例外名：何が通常条件から外れたか
• 発見点：どの処理または判断で分かったか
• 一次担当：最初に対応する役割
• 戻り先：どの箱へ戻すか
• 期限：いつまでに判断するか
• 顧客連絡：誰が、何を、いつ伝えるか
• 証跡：判断理由と承認者をどこへ残すか
• 再開条件：何がそろえば正常系へ戻れるか

デジタル庁の標準ガイドライン解説書は、企画後の業務フローで「誰が」「何を」「どのような手順で」行うか、人手か自動か、紙か電子データかを可視化し、企画前後をAs-Is／To-Beで比較する考え方を示しています。民間業務でも、担当と媒体を明示すると、二重入力や手待ちの原因を見つけやすくなります。

業務フローの作り方：現状整理から更新までの7ステップ

1. 現状を観察する

理想の手順ではなく、最近完了した3〜5件を入口から出口までたどります。メール、表計算、紙、口頭確認など、実際に使った媒体も記録します。担当者への聞き取りでは「通常はどうするか」だけでなく、「前回止まったのはどこか」「急ぎのとき何を省くか」を確認します。

2. 範囲と目的を決める

開始、終了、対象部署、対象外、読者、使う判断を一文にします。例は「注文受領から納品通知までを対象に、営業と在庫と経理と出荷が、差し戻し先と改善候補を合意する」です。開始が広すぎる「顧客対応」、終了が曖昧な「完了」は避けます。

3. 担当と入出力を並べる

部署または役割をスイムレーンにし、各工程で受け取る情報、行う処理、作る記録を付けます。組織図は上下関係、業務フローは仕事の受け渡しを示すため、役職の序列ではなく処理順にレーンを並べます。個人名ではなく役割名を使うと、異動後も更新しやすくなります。

4. 例外と判断条件を加える

正常系を描いた後、欠品、情報不足、承認保留、システム停止、期限超過を追加します。すべての例外を一枚へ詰め込まず、頻度または影響が高いものから選びます。判断にはYes／Noの意味と戻り先を付け、ループが無限にならない再開条件を決めます。

5. 部門横断でレビューする

各部署から実行者一人、前後工程の受け手、承認者を集め、実例を一件読み上げながら線を追います。「この箱が終わったと誰が判断するか」「次の担当は何を受け取るか」「不在時は誰へ渡すか」を確認します。発言しにくい人のため、レビュー後の非同期コメント窓口も用意します。

6. 公開して使い方を伝える

タイトル、目的、対象範囲、凡例、オーナー、公開日、版、修正窓口を付けます。全体図から詳細手順書へリンクし、画像だけでなくテキストでも主要経路を説明します。新しい担当者が口頭説明なしに一件を追えるかを公開前テストにします。

7. 測定して更新する

組織変更、システム変更、例外増加、重大な差し戻しは臨時レビューのきっかけです。定期レビュー日も置きますが、日付だけでなく、処理時間、待ち期間、差し戻し率などの観測値を持ち寄ります。古い版は履歴として残し、現行版が一つだと分かる状態にします。

As-Is／To-Beで業務フローを改善する

As-Isは現在の事実、To-Beは改善仮説です。先にTo-Beだけを描くと、現場が実際に処理している例外や非公式な確認を消してしまいます。まず実例と記録からAs-Isを作り、次に顧客価値、法令・統制、リスクを守りながら、不要な処理を減らします。

次の表は、前述の架空の受注業務を使った仮想比較です。件数、時間、目標値は説明用で、実測成果ではありません。

デジタル庁の実践ガイドブックは、実作業に必要な「時間」と、開始から終了までの待ちを含む「期間」を区別するよう説明しています。5日かかった処理でも実作業は30分だけかもしれません。承認待ちを改善したいなら、作業時間だけを短縮してもリードタイムは変わらないため、各受け渡しの到着時刻と着手時刻を別々に記録します。

改善チェックリスト

• 顧客または次工程に価値を渡さない作業を削除できないか
• 同じ情報を紙、メール、表計算へ二重入力していないか
• 承認者の不在で止まる箱に代理と期限があるか
• 順番に行う必要がない確認を並行化できないか
• 例外を工程の早い段階で判定できないか
• 判断条件が担当者の経験だけに依存していないか
• 自動化の前に、不要な工程を残していないか
• To-Beの目標値、測定方法、試行期間、撤回条件があるか
• セキュリティ、監査、法令対応を効率化の名目で外していないか

ISOの品質マネジメント原則は、プロセスアプローチ、改善、証拠に基づく意思決定を別々ではなく関連する原則として扱います。To-Beを公開したら、試行期間後に実測し、結果が悪化した工程を戻す判断も必要です。図を「正解」ではなく、検証可能な仮説として管理してください。

部門横断レビューでよくある失敗と修正

現場を呼ばず、管理者だけで完成させる

管理者は規程上の流れを説明できますが、例外時の実際の連絡や手作業を知らない場合があります。最近の案件を扱った担当者と、次工程で情報を受け取る人を必ず含めます。管理者は責任と統制、現場は実際の処理、システム担当はデータと制約を確認します。

正常系だけをきれいに描く

差し戻し、欠品、否決、期限超過が消えた図は、教育にも改善にも使えません。例外をすべて同じ重さで描く必要はありませんが、頻度が高いもの、顧客影響が大きいもの、統制上重要なものは戻り先まで示します。

箱の名称を部門ごとに解釈する

「確認」「処理」「対応」のような語は広すぎます。レビューでは一箱ずつ「入力は何か」「担当は誰か」「何をすれば完了か」「出力を誰が使うか」を読み上げます。答えが分かれる箱は、分割するか定義を追記します。

ツール導入をTo-Beと取り違える

システム名を箱へ書き換えただけでは改善になりません。二重入力や不要承認を残したまま自動化すると、速く同じ無駄を繰り返します。先に目的とルールを合意し、その後で支援ツールを選びます。候補を比較するときは、データの置き場所やオフライン要件も含めてセルフホスト可能なNotion代替などを参照できます。

公開後の修正責任がない

レビュー会議の終了を完成とせず、オーナー、次回日、変更履歴、修正窓口を決めます。更新依頼には「どの案件で、どの箱と実態が違ったか」を添える形式を用意します。資料を探せない問題は、保管場所の整理方法をノートアプリ比較から見直すこともできます。

AFFiNEで文書とEdgelessを組み合わせる手動整理例

AFFiNEでは、Pageに目的、範囲、判断条件、例外、版情報を書き、同じ内容をEdgelessの視覚スペースでカードや図形として手動整理できます。文書と図を別ファイルへ分断せず、レビューの前提と視覚的な流れを同じワークスペースで参照しやすい点が実務上の使い方です。

2026年8月5日、AFFiNE Webのブラウザ保存型ワークスペースで「業務フロー検証 2026-08-05」を作成しました。入力は「架空の受注3件／営業→在庫→経理→出荷」、判断は「在庫あり？」「与信承認？」、出力は「納品通知」です。Pageへ前提と制約を記述し、Edgelessへ切り替え、営業、在庫、経理、出荷の4カードを手動で配置できることを確認しました。Web画面には確認時のビルド番号は表示されていませんでした。

共有パネルには「Sharing docs requires AFFiNE Sync」と表示されました。したがって、今回の未同期ブラウザ環境では他者を招待した共同レビューまでは実施していません。AFFiNEの公式ホワイトボード説明はPage Docs、Edgeless Whiteboard、collaborative toolsを案内していますが、実際の共有にはサインイン、AFFiNE Syncの有効化、権限設定など利用環境の準備が必要です。

この確認は手動の文書化と可視化の証拠です。自動プロセスマイニング、自動フロー生成、BPMエンジンによる実行、業務システムとの自動連携は確認しておらず、AFFiNEの現行機能として主張しません。AFFiNEは本ブログの運営元であり、本節では自社製品を紹介しています。

AFFiNEの文書とホワイトボードで業務フローを手動整理する

コピーして使える業務フロー確認リスト

作成前

• 目的と読者を一文で書いた
• 開始条件と終了条件を決めた
• 対象部署、対象外、対象期間を決めた
• 最近完了した実例を3〜5件確認した
• 紙、メール、口頭、システムを含む実際の媒体を確認した

作図中

• 各処理に担当、入力、完了条件、出力がある
• 判断の出口に条件がある
• 正常系と重要な例外の戻り先がある
• 線の交差と意味不明な双方向線を減らした
• 一枚が複雑なら全体図と詳細図へ分けた

レビューと公開

• 実行者、前後工程、承認者、システム担当が確認した
• 仮想値、目標値、実績値を区別した
• 図の内容を補うテキスト説明がある
• オーナー、版、更新日、次回レビュー、修正窓口がある
• 一件を入口から出口まで追い、例外でも行き止まりにならない

よくある質問

業務フローとフローチャートの違いは何ですか？

フローチャートは処理や判断の順序を図示する一般的な表現です。業務フローはその表現を使いながら、担当部署、受け渡す情報、例外、承認責任まで業務の文脈に結び付けます。手順だけを確認するならフローチャート、部門横断の役割まで合意するなら業務フローが向きます。

業務フロー図はどこまで細かく書けばよいですか？

目的から逆算します。改善会議なら待ち時間、二重入力、例外の戻り先が見える粒度にし、教育用なら新人が次の行動を選べる粒度にします。一枚に収まらない場合は全体図と詳細図へ分け、開始・終了・担当・入出力・判断条件が追えるかを基準にしてください。

業務フローの作成は誰が担当すべきですか？

作図担当だけで決めず、業務の実行者、前後工程の受け手、承認者、システム担当から小さなレビュー班を作ります。オーナーは版管理と更新判断を担い、現場担当は実際の例外を確認します。最終承認者と修正依頼の窓口も公開時に明記すると放置を防げます。

As-IsとTo-Beは同じ業務フロー図に描くべきですか？

比較しやすいよう、同じ開始・終了、同じ部署、同じ測定項目を使った二枚を並べる方法が安全です。一枚へ重ねると線が増えて差分を見失いやすくなります。To-Beには目標値と仮説を明示し、実績値のように扱わず、試行後に測定して更新してください。

AFFiNEは業務フローを自動生成できますか？

本記事で確認したのは、Pageで前提を文書化し、Edgelessでカードを手動配置して視覚的に整理する操作です。自動プロセスマイニング、自動フロー生成、BPMの実行機能は検証しておらず、現行機能として案内しません。共有レビューにはAFFiNE Syncの有効化など利用環境の準備が必要です。

出典と編集方法

Google JapanのSERPは2026年8月5日に「業務フロー」「業務フロー 作り方」「業務フロー図」「業務フロー 改善」「業務フロー 例」で確認しました。上位はfreee、Salesforce、クラウドサイン、Cacooなどの定義・作図ガイドが中心で、改善クエリではBPRやECRSの記事が別に並びました。本記事は、用語の違い、基本記号、部門横断の通し例、例外、As-Is／To-Be、測定、更新責任を一つの実務手順へつないでいます。

参照日はいずれも2026年8月5日です。

1. International Organization for Standardization, ISO 5807:1985 — Information processing — Documentation symbols and conventions for flowcharts：フローチャート記号と規約の一次資料。
2. デジタル庁, デジタル・ガバメント推進標準ガイドライン解説書（2024年6月5日版）：担当、手順、人手／自動、紙／電子、As-Is／To-Beの整理。
3. デジタル庁, 標準ガイドライン実践ガイドブック（2025年6月19日版）：実作業時間と待ちを含む期間の区別、ボトルネック分析。
4. International Organization for Standardization, Quality management principles：プロセスアプローチ、改善、証拠に基づく意思決定。
5. AFFiNE, Whiteboard：Page Docs、Edgeless Whiteboard、共同編集ツールに関する公式製品説明。

AFFiNEの記述は、同日のAFFiNE Webでの手動テストと公式ホワイトボード説明を照合しました。自社製品を紹介する利益関係、未同期環境で共同レビューを実施していないこと、未検証の自動化機能を主張しないことを明示しています。著者情報と検証方針は編集方針から確認できます。

まとめ：業務フローは描くことより、合意して更新することが重要

業務フローの作り方は、図形を並べる作業から始まりません。目的、開始・終了、担当、入出力、判断、例外を事実から整理し、部門横断で一件を追い、As-IsとTo-Beを同じ条件で比較します。改善案には目標と測定方法を付け、実績と混同しないことが大切です。

完成した業務フロー図には、オーナー、版、更新日、修正窓口を付けてください。現場と違う箱が見つかったら、それは失敗ではなく更新の入力です。図、手順書、決定記録を結び付け、次の担当者が迷わず仕事を引き継げる状態を維持しましょう。