業務フロー図の書き方｜記号一覧・スイムレーン例とMermaidテンプレート

業務フロー図は、「誰が（レーン）」「何を（作業）」「どの順で（矢印）」「何を使って（帳票・システム）」行うかを、1枚に並べた図です。 書くときは、①目的と範囲 → ②登場人物（レーン） → ③作業 → ④順番と分岐 → ⑤帳票・システム の順に決めます。

確認環境：この記事の Mermaid の図は、すべて Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0、Linux）で SVG に描画できることを確かめました。記号の名前は JIS X 0121:1986 と OMG の BPMN 2.0.2 で確かめています（確認日 2026年10月12日）。

業務フロー図とほかの図の違い

業務フロー図は「人と組織の仕事の流れ」を描く図です。 システムの中の処理の順番を描くフローチャートや、データの流れだけを描く DFD とは、見るものが違います。システム開発では、要件定義の前半で「今の業務（As-Is）」と「システム導入後の業務（To-Be）」を描くのに使います。

1つの処理の中の分岐や繰り返しは、関連記事「フローチャートの書き方と記号一覧｜分岐・繰り返しの例とMermaid」で扱っています。

記号一覧（JIS X 0121・BPMN・Mermaid の対応表）

業務フロー図の記号は、JIS X 0121（流れ図の記号）か BPMN（業務プロセスの記法）のどちらかに合わせると、読み手が迷いません。 どちらにも合わせない場合は、図の端に「凡例（記号の意味の一覧）」を置きます。

JIS X 0121:1986「情報処理用流れ図・プログラム網図・システム資源図記号」は、国際規格 ISO 5807 に対応する規格です。BPMN（Business Process Model and Notation）は OMG が定めた業務プロセスの記法で、2.0.2 版は 2014年1月の公開です。

業務フロー図でよく使うのは、上の表の「端子・処理・判断・書類・記憶データ・線」とレーンです。 ほかの記号は、必要になったときに足します。記号を増やすほど、読み手が覚えることも増えます。

• Mermaid の A@{ shape: ... } の書き方は、Mermaid のドキュメントでは v11.3.0 から使えると書かれています。表示するサイトやツールの Mermaid が v11.3.0 より前の版だと描画されないため、そのときは A[検品する（手作業）] のように、文字で補います。
• BPMN では、同じプール（組織）の中の順番はシーケンスフロー、プールをまたぐやり取り（顧客や取引先との注文・請求）はメッセージフローで描きます。

システム開発の例：受注から出荷・請求まで

例として、通販の受注から入金の消し込みまでを、5つのレーンで描きます。 「受注管理システム」もレーンの1つにして、どの作業でシステムを使うかを点線で示しています。

flowchart TB
  subgraph C["顧客"]
    c1([注文する])
    c9[請求書を受け取る]
  end
  subgraph S["営業"]
    s1[受注を登録する]
    s2{在庫はあるか}
    s3[納期を回答する]
  end
  subgraph W["倉庫"]
    w1[ピッキング・梱包する]
    w2[出荷する]
  end
  subgraph A["経理"]
    a1[請求書を発行する]
    a2([入金を消し込む])
  end
  subgraph SYS["受注管理システム"]
    d1[(受注DB)]
    d2[(在庫DB)]
  end
  c1 --> s1 --> s2
  s2 -- ある --> w1 --> w2 --> a1 --> c9
  s2 -- ない --> s3 --> c1
  a1 --> a2
  s1 -.-> d1
  s2 -.-> d2
  w2 -.-> d2

Mermaid にはスイムレーン専用の書き方がないため、subgraph（グループ）をレーンの代わりに使っています。 置き場所は自動で決まるので、レーンがきれいな帯に並ぶとは限りません。発注者に見せる清書は、draw.io などの作図ツールや BPMN のツールで描き、Mermaid は「設計書の中で、差分を Git で追える下書き」として使う、という分け方ができます。

同じ流れを表（業務記述書）にする

図だけでは、作業の中身（入力・出力・ルール）が書ききれません。 図の番号と対応させた表を一緒に作ると、要件定義書や画面設計書に引き継ぎやすくなります。

「（例）」と書いた数値は、説明のための架空のルールです。実際の値は、ヒアリングで決めて表に書き込みます。

例外の流れを別の図に分ける

キャンセル・返品・在庫不足のような例外を1枚に全部入れると、矢印が交差して読めなくなります。 正常の流れの図には分岐の入口だけを書き、例外は「定義済み処理（サブプロセス）」として別の図に分けます。

flowchart LR
  s1[受注を登録する] --> s2{与信は通るか}
  s2 -- 通る --> s3[在庫を引き当てる]
  s2 -- 通らない --> x1[[与信NGの対応<br>（別図 F-02）]]
  s3 --> s4{全数あるか}
  s4 -- ある --> s5[出荷を指示する]
  s4 -- 一部ない --> x2[[分納の対応<br>（別図 F-03）]]

業務フロー図を書く手順

いきなり図を描き始めず、先に「範囲・登場人物・作業」を文字で書き出します。 文字の段階で抜けを見つけたほうが、図を描き直す手間が減ります。

③の作業は、付箋や表で先に並べると速く進みます。 作業の名前は「受注」ではなく「受注を登録する」のように、目的語と動詞で書きます。名詞だけだと、誰が何をするのかが読み手によって変わります。

ヒアリングで聞く項目は、関連記事「要件ヒアリングの質問一覧60項目｜シートのテンプレートと記入例」で扱っています。

粒度の決め方

粒度（1つの作業の大きさ）は、図ごとに1つの段階にそろえます。 同じ図の中に「受注業務」と「数量を入力する」が並ぶと、どこまで細かく見ればよいか分からなくなります。

粒度をそろえる目安として、次の3つを確かめます。

• 担当が変わるところで四角を分ける（同じ担当が続けて行う作業は、1つにまとめられないかを考える）
• 画面・帳票が変わるところで四角を分ける（1つの四角に2つの画面が入っていたら分ける）
• 1枚に収まらないときは、細かくするのではなく図を分ける（レベル0の1つの四角を、レベル1の別の図にする）

レベル0の四角を作業に分けていく考え方は、WBS の分解と同じです。関連記事「WBSの作り方｜システム開発の実例表と分解を止める判断基準」で扱っています。

よくある誤りのチェックリスト

描き終えたら、次の表で見直します。 上の行ほど、読み手が誤解しやすい誤りです。

DFD・アクティビティ図・As-Is/To-Be との使い分け

「何を決めたいか」で図を選びます。 1つの図ですべてを表そうとすると、どの図も中途半端になります。

DFD は関連記事「DFD（データフロー図）の書き方と記号｜コンテキスト図・レベル0の例」で、アクティビティ図は「アクティビティ図の書き方と記号一覧 スイムレーン例をPlantUMLで」で、ジョブフロー図は「ジョブフロー図の書き方｜ジョブ一覧と先行関係をMermaidで描く例」で扱っています。As-Is と To-Be を比べて課題を整理する手順は、関連記事「As-Is/To-Be分析のやり方｜業務フローと課題整理テンプレート」で扱っています。

コピペ用の Mermaid テンプレート

レーンの名前と作業を書き換えると、そのまま使えます。 subgraph の ID（L1 など）は英数字にし、表示名は ["..."] の中に書きます。

flowchart TB
  %% ===== レーン（担当）=====
  subgraph L1["顧客"]
    start([開始のきっかけ])
  end
  subgraph L2["担当部署A"]
    t1[作業1を行う]
    q1{条件を満たすか}
    t2[作業2を行う]
  end
  subgraph L3["担当部署B"]
    t3[作業3を行う]
    goal([終わりの状態])
  end
  subgraph L4["システム"]
    db[(データベース)]
  end
  %% ===== 流れ =====
  start --> t1 --> q1
  q1 -- はい --> t3 --> goal
  q1 -- いいえ --> t2 --> t1
  %% ===== システムの利用（点線）=====
  t1 -.-> db
  t3 -.-> db

Mermaid は、設計書を Markdown で書いている場合に、図とテキストを同じファイルで管理できるのが利点です。生成AIに業務フローの下書きを Mermaid で出させる方法は、関連記事「生成AIで設計書を作るプロンプト集｜要件定義から詳細設計まで」で扱っています。

よくある質問

Q. 業務フロー図は、どの工程で誰が書きますか。 A. 多くは要件定義の前半で、発注者側の業務担当と、開発側の要件定義の担当が一緒に書きます。今の業務（As-Is）は業務担当への聞き取りから、導入後の業務（To-Be）は要件を決めながら書きます。要件定義書との関係は、関連記事「要件定義書の書き方｜記入例と要件ID・受け入れ基準」で扱っています。

Q. レーンは縦と横のどちらにしますか。 A. どちらでも描けます。横に長い流れ（時間が左から右）ならレーンは横の帯、A4 縦の資料に収めるならレーンは縦の帯にすることが多いです。1つのプロジェクトの中では、向きをそろえます。

Q. BPMN で書くほうがよいですか。 A. BPMN は記号の意味が決まっているので、読み手が BPMN を知っていれば誤解が減ります。一方で、記号が多く、知らない人には読みにくいこともあります。発注者の業務担当が読む図なら、この記事の表の基本の記号だけに絞り、凡例を付ける方法もあります。

Q. システムの画面操作まで書くべきですか。 A. 業務フロー図（レベル1）には「受注を登録する」までを書き、画面の操作の順番は画面設計書や画面遷移図に書くと、図の粒度がそろいます。画面の項目は、関連記事「画面設計書の書き方｜項目一覧・テンプレート・記入例まとめ」で扱っています。

まとめ

• 業務フロー図は 「誰が・何を・どの順で・何を使って」 を1枚に並べた図
• 記号は JIS X 0121 か BPMN に合わせるか、凡例を付ける。よく使うのは 端子・処理・判断・書類・記憶データ・線とレーン
• 書く順番は 範囲 → 登場人物 → 作業 → 順番と分岐 → 帳票・システム → 確かめる
• 粒度は 図ごとに1つの段階にそろえ、収まらないときは 図を分ける
• Mermaid では subgraph をレーンにして描ける。A@{ shape: doc } などは v11.3.0 以降の書き方

参考・出典

確認日はいずれも 2026年10月12日です。

• JIS X 0121:1986 情報処理用流れ図・プログラム網図・システム資源図記号（本文の記号名）：https://kikakurui.com/x0/X0121-1986-01.html
• OMG「Business Process Model and Notation（BPMN）Version 2.0.2」：https://www.omg.org/spec/BPMN/2.0.2/About-BPMN
• Camunda「BPMN 2.0 Symbols - A complete guide with examples」：https://camunda.com/bpmn/reference/
• Mermaid「Flowcharts - Basic Syntax」（Expanded Node Shapes・subgraph）：https://mermaid.js.org/syntax/flowchart.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。