業務フローの書き方｜7ステップと記号・粒度の決め方

業務フローの書き方の話をする前に、どんな業務を扱うのかから始めます。業務が分からないまま図の話をしても、何も残らないからです。

題材は、中古車の買取販売です。車を買い取って、整備して、売る。店舗は1つ、月の取扱台数は60台ほどを想定します。

流れはこうです。

査定 → 買取 → 名義変更 → 整備 → 撮影 → 出品 → 商談 → 納車

1台あたり、買い取ってから納車まで平均3週間かかっています。在庫が長く寝るほど、資金が回らず、値落ちもする。社長は、これを2週間にしたい。

では、なぜ可視化から入るのかというと、どこが遅いかを、誰も知らないからです。

各担当者は、自分の工程については詳しく知っています。ところが、自分の前後で何が起きているかは知りません。 査定の担当者は、名義変更に何日かかるかを答えられない。整備の担当者は、車がなぜ2日待たされたのかを知らない。

全体を知っている人が、社内に1人もいない。 だから、まず全体を1枚にする。

業務フローとは、仕事がどの順番で、誰の手を通って進むかを表したものです。フローチャート、スイムレーン図、業務フロー図。呼び方はいろいろありますが、やることは同じで、担当者の頭の中にしかない手順を、他人が読める形にすることです。

そして近年、この作業には別の目的が乗りました。AIをどこに入れるかを決めるためです。どの工程を機械に渡せるかを判断するには、まず工程が見えていないといけない。「AI導入の前に、まず業務の可視化を」と言われるのは、これが理由です。

前置きはさておき、本題に入ります。

今日は、その可視化を教科書どおりにやって、そこで詰まったところから話をしていこうと思います。

① 教科書どおりに、フロー図を描く

業務フローとは

業務フローとは、ある業務が始まってから終わるまでの流れを、順番と担当者が分かる形で表したものです。図にしたものを業務フロー図と呼びます。

目的は説明ではなく、合意です。同じ業務について、部署ごとに違う理解を持っているのが普通なので、1枚に描いて、そこが違うと言ってもらうために作ります。

ワークフローとの違い

	表すもの	使う場面
業務フロー	業務全体の流れ。複数の部署にまたがる	現状の把握、業務改善、システムの要件定義
ワークフロー	申請から承認までの経路。1つの手続きの中の流れ	稟議、申請、決裁の設計

ワークフローは業務フローの一部です。システムの名前として「ワークフロー」が使われることが多いため、会話の中で指しているものがどちらなのかを確認してください。

マニュアル・手順書との違い

	何が書いてあるか	読む人
業務フロー	誰が、どの順番で、何を渡すか	関係者全員。全体を知りたい人
マニュアル・手順書	どうやるか（操作、判断の基準）	その作業をする人

1つの図に両方を書かないでください。手順まで書き込むと図が読めなくなり、全体を見るという目的が果たせなくなります。手順は別紙にして、図から参照する形にします。

ビジネスフロー・作業フローとの関係

ビジネスフローはほぼ業務フローと同じ意味で使われます。作業フローは、もっと細かい単位——1人の担当者が行う作業の順番——を指すことが多い言葉です。

言葉より、粒度をそろえるほうが大事です。同じ図の中に「営業部が対応する」と「システムのボタンを押す」が混ざっていると、読み手が迷います。

業務フロー図を作るメリット

• 業務の全体像を共有できる — 部署ごとの理解のずれが表に出る
• 改善する場所を探せる — 重複、手戻り、確認の往復が見つかる
• 属人化を防げる — 頭の中にあった流れが、資料として残る
• 引き継ぎと教育に使える — 新しい人が全体を先に把握できる
• システム化の土台になる — 要件定義の入口の資料になる

5つ目を目的にする場合は、描く粒度が変わります。システム化を前提にするなら、やり取りされる書類とデータを図に入れておく必要があります。

業務フロー図の主な種類と使い分け

種類	特徴	向いている場面
スイムレーン図	担当者・部署ごとに横の帯で分ける	複数部署にまたがる業務。いちばんよく使う
単純なフローチャート	処理と分岐だけを順に並べる	1部署で完結する業務
DFD（データフロー図）	データの流れを中心に描く	システムの設計
アクティビティ図（UML）	並行処理や条件を厳密に書ける	開発の仕様として使うとき

迷ったらスイムレーン図です。業務が止まるのは、たいてい部署と部署のあいだなので、担当が分かれて見える形が実務に合います。

業務フロー図で使う記号とルール

記号	意味
角丸の四角（端子）	業務の開始と終了
四角（処理）	作業、処理
ひし形（判断）	条件による分岐
書類の形	帳票、申請書、印刷物
円筒	データベース、システムに保存されるデータ
矢印	流れの向き

記号は増やさないでください。種類が多いほど、読む側に凡例の暗記を求めることになります。使う図形を絞り、図の中に凡例を置くのが実務的です。

作る前に決めておく4つのこと

• 目的 — 現状の共有か、改善か、システム化か。粒度がここで決まる
• 対象範囲 — どこから始まり、どこで終わる業務か
• 関係者 — 誰が登場するか。社外（顧客・委託先）も入れるか
• 記号と表記のルール — 図形、線、言葉の使い方をそろえる

1つ目が決まっていないと、粒度が定まりません。共有が目的なら粗く、システム化が目的なら細かく描くことになります。同じ図で両方を満たそうとすると、どちらにも使えない図ができます。

業務フロー図の書き方（7ステップ）

	やること	終わったと言える状態
1. 開始と終了を決める	何をもって始まり、何をもって終わりか	範囲が1文で言える
2. 主な流れを粗く並べる	5〜10個の箱で全体を置く	全体が1枚に収まっている
3. 処理と判断を書き込む	分岐の条件を明記する	「その他」の分岐先が決まっている
4. 担当を分ける	スイムレーンで部署・役割ごとに配置する	受け渡しの位置が見えている
5. 書類とデータを足す	何が渡されるかを図に入れる	渡すものが名前で書かれている
6. 関係者に見てもらう	経験者に確認し、抜けを直す	「実際は違う」が出尽くしている
7. 使って、更新する	見直しの担当と頻度を決める	更新のルールが決まっている

2で粗く置くのを飛ばさないでください。いきなり詳細から描き始めると、途中で全体の構成を変えることになり、描き直しになります。

抜け漏れを出さないための聞き方

図の価値は、抜けが無いかどうかで決まります。抜けを防ぐ方法は3つです。

• その業務の経験者に聞く — 管理者ではなく、実際にやっている人に
• 1件を頭から最後まで追う — 実物の案件で、作業をなぞる
• 例外から聞く — 「うまくいかなかったときはどうしますか」から入る

3つ目がいちばん効きます。正常な流れは誰でも説明できますが、例外の処理は聞かれないと出てきません。そして図が現実と食い違う原因は、たいてい例外の側にあります。

分かりやすい業務フロー図にするポイント

• 1枚に収める — 全体像が一目で入るようにする
• 開始と終了を明示する — どこから始まる話か迷わせない
• 分岐の条件を書く — 「はい／いいえ」だけでなく、判断の基準を
• 凡例を置く — 使った図形の意味を図の中に示す
• 線を交差させない — 交差は読み間違いのもと
• 時系列を一方向にそろえる — 左から右、または上から下
• 言葉をそろえる — 同じものを別の呼び名で書かない
• 詳細は別紙に逃がす — 図から参照する形にする

7つ目が、現場で最も多いつまずきです。「見積書」「御見積」「見積」が同じ図の中に混在すると、別のものだと読まれます。呼び名の一覧を先に作ってから描いてください。

粒度（詳しさ）の決め方と、図の分け方

粒度は、読み手が判断できる最小の単位に合わせます。

粒度	箱の中身の例	向いている目的
粗い（業務レベル）	「査定する」「納車する」	全体像の共有、経営への説明
中くらい（作業レベル）	「査定表に記入し、上長が承認する」	改善の検討
細かい（操作レベル）	「システムのAボタンを押す」	システム化、マニュアル

1枚に収まらなくなったら、粒度を落とすか、図を分けてください。分けるときは、粗い図を1枚作り、その箱ごとに詳細図を用意する形にすると、全体と細部の両方が読めます。

作成ツールの選び方

ツール	効くところ	気をつけるところ
表計算（Excel等）	誰でも開ける。配布しやすい	図形の管理が手作業になる
スライド（PowerPoint等）	説明の場でそのまま使える	大きい図は1枚に収まりにくい
作図の専用ツール	記号や整列が楽	相手が開けないことがある
クラウドの作図サービス	同時に編集でき、共有が速い	版の管理と、退会後の閲覧に注意

最初から専用ツールを使わないでください。叩き台の段階では、書き換えの速さのほうが大事です。構成が固まってから清書に移ると、手戻りが減ります。

作成でよくある失敗

失敗の型	何が起きるか	手前で防ぐ方法
いきなり詳細を描く	全体の構成を後から変えることになる	粗い図を先に置く
現場を巻き込まない	図と実態が食い違う	経験者に例外から聞く
粒度が混ざる	読み手が迷う	粒度を先に宣言する
更新されない	半年で使われなくなる	見直しの担当と頻度を決める
目的が無いまま描く	きれいな図ができるが、次の一手が決まらない	目的を1文で書いてから始める

最後の1つは、描き上がるまで気づけません。図としては正しく、関係者も納得しているのに、そこから何を直せばよいかが決まらない状態になります。この記事の後半は、そこの話です。

業務フローの書き方についてよくある質問

Q. 業務フローとワークフローは何が違いますか。
業務フローは複数の部署にまたがる業務全体の流れ、ワークフローは申請から承認までの経路を指します。ワークフローは業務フローの一部です。

Q. 業務フローとマニュアルは、どう使い分けますか。
業務フローには「誰が、どの順番で、何を渡すか」、マニュアルには「どうやるか」を書きます。1つの図に両方を書くと図が読めなくなるので、手順は別紙にして図から参照してください。

Q. 業務フロー図は、どのくらい細かく書けばよいですか。
目的で決まります。全体像の共有なら業務レベル、改善の検討なら作業レベル、システム化なら操作レベルです。1枚に収まらなくなったら、粗い図と詳細図に分けてください。

Q. 抜け漏れを防ぐには、どうすればよいですか。
管理者ではなく実際にやっている人に聞き、実物の案件を頭から最後まで追い、「うまくいかなかったときはどうしますか」から聞いてください。図が現実と食い違う原因は、たいてい例外の側にあります。

Q. 作成ツールは何を使えばよいですか。
叩き台の段階は、書き換えが速い表計算やスライドで十分です。最初から専用ツールを使うと、構成を変えるたびに手戻りが出ます。構成が固まってから清書に移ってください。

担当者に聞き取りをして、工程を並べます。スイムレーンで部署ごとに分けて、矢印でつなぐ。

“`
[査定] → [買取] → [名義変更] → [整備] → [撮影] → [出品] → [商談] → [納車]
営業 営業 事務 工場 販促 販促 営業 営業
“`

きれいな図ができました。 A3に印刷して、事務所の壁に貼ります。全員が「そうそう、こういう流れです」と言います。

ここまでは、教科書どおりです。 そして、ここで止まります。

ここまでが、業務フローの書き方の教科書どおりの整理です。目的を決め、範囲を決め、粗く置いてから詳細を足し、現場に確認して、更新する。手順としては、これで揃っています。

この記事の後半で扱うのは、この手順どおりに描き上げた図を前にして、次に何をしようとして詰まったかです。図そのものは、誰からも間違いを指摘されませんでした。

② 図を見ても、どこを直せばいいか分からない

図を前にして、改善案を出そうとします。ところが、出てきません。

理由は明確でした。この図からは、どこが遅いのかが分からないからです。

→ 「整備」は1台1日なのか、3日なのか
→ 「名義変更」は即日なのか、書類が揃うまで待つのか
→ 「撮影」に回ってくる車は、毎回きれいになっているのか

この3つが書かれていない図は、業務の順番を再確認しただけです。そして順番は、もともと全員が知っています。

貼ってから1ヶ月後、誰も見ていませんでした。 剥がすのも気まずいので、そのまま貼ってあります。

③ 実際に測ったら、遅いのは工程ではなかった

そこで、工程ごとの所要時間を実測しました。1台ずつ、いつ次へ渡ったかを記録します。

結果は、予想と違いました。

工程	作業時間	手前の待ち時間
査定	分単位	—
買取	分単位	日単位
名義変更	分単位	いちばん長い
整備	日単位	日単位
撮影	分単位	次に長い
出品	分単位	1日未満
商談	—	—
納車	分単位	日単位

作業時間を全部足しても、数日にしかなりません。 ところが納車まで3週間かかっている。

残りは、どの工程にも計上されていない待ちです。 差のほとんどが「待ち」でした。

そして、いちばん長い待ちが名義変更の手前です。理由を聞くと、こうでした。必要な書類が、買取の時点でそろっていない。 印鑑証明、譲渡証明、委任状。どれか1枚が足りず、お客様に連絡して、郵送してもらって、届くのを待つ。

フロー図には「買取 → 名義変更」と1本の矢印しか描かれていません。 その矢印の上で、何日も消えていました。

④ 図に「量」と「待ち」が入っていなかった

原因は、図の書き方でした。

→ 四角は作業を表している
→ 矢印は順番を表している
→ 待ちを表す記号が、どこにも無い

そして、待ちが発生する理由も書かれていません。書類がそろっていないから待つ、という因果が、図の上に存在しない。

つまり、改善すべき場所が、図に描かれていなかったわけです。描かれていないものは、見ても気づけません。

⑤ 直してみる — 2枚の表に書き換える

図をやめて、2枚の表にしました。

表1：受け渡し

工程ではなく、工程と工程のあいだを主役にします。

渡す側	受け取る側	渡すもの	月の件数	そのまま進められた率
営業	事務	買取書類一式	60台	群を抜いて低い
事務	工場	車両＋整備指示	60台	高い
工場	販促	整備済み車両	60台	やや低い
販促	営業	出品済み情報	60台	高い

いちばん右の列が本体です。 渡されたものが、そのまま次へ進められた割合。

低いのは、営業から事務への受け渡しだけでした。 書類が足りない、記入が漏れている。だから事務は、車1台ごとにお客様へ連絡して、待つことになります。

いちばん長い待ちの正体が、この受け渡しでした。

表2：停止点

どこで人が判断するか。そして、その判断は処理を止めて待つのか、先に進めてあとから追認するのか。

工程	人が判断するか	止め方	理由
査定の金額決定	する	同期で止める	金銭が動く
書類の不備チェック	する	非同期にできる	差し戻せる
整備の要否判断	する	同期で止める	費用が発生する
出品価格の決定	する	非同期にできる	あとで変更できる
納車前の最終確認	する	同期で止める	取り消せない

「確認する」を全部同期で止めていたのが、待ちを積み上げていました。 差し戻せるもの、あとで変えられるものは、先に進めて後から直すほうが速い。

⑥ あとで知った — この2枚には、名前がついていた

素朴な整理のつもりでしたが、調べると両方とも確立した手法でした。

1つ目。工程だけでなく、待ち時間と受け渡しを一緒に描くやり方は、バリューストリームマッピング（VSM）と呼ばれています。工程の作業時間だけでなく、その手前の待ちや溜まっている仕掛かりを同じ1枚に並べて、価値を生んでいる時間とそうでない時間を分けて見るための道具です。

そして、「そのまま進められた率」と呼んでいた列には、正式な名前がありました。

%C/A（Percent Complete and Accurate） — 受け取った側が、差し戻しも問い合わせも追記もせずに、そのまま使えたものの割合です。

呼び方が違うだけで、同じものでした。 そして、この指標がVSMで受け渡しを見る項目として用意されているということは、受け渡しの欠損が主要な遅延要因であることが、とうに知られていたということです。

2つ目。制約理論（Theory of Constraints）。 ボトルネックは、手前に仕掛かりが最も溜まり、待ち時間が最も長く、稼働率が最も高い工程として現れる、とされています。

そして、いちばん効いたのがここでした。制約を狙って改善していくと、その工程はいずれ制約でなくなり、制約は別の工程へ移るとされています。

制約は、消えません。移動します。

だから、名義変更の手前の待ちを削っても、次は撮影の手前の待ちが最長になるだけです。改善は1回では終わらない。終わらないことを前提に、測り続ける仕組みを作るほうが先でした。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

営業から事務への%C/Aを上げるために、やったことは1つです。買取の場で、書類のチェックリストを画面に出して、そろうまで次へ進めないようにしました。

営業の手元では、買取1台あたりの作業がその分だけ増えました。代わりに、事務の待ちが目に見えて縮みました。

渡す側に少し足して、受け取る側の待ちを削っている。 交換としては、悪くありません。

そして予想どおり、制約は移動しました。 いま最長の待ちは、撮影の手前です。次はそこを測ります。

AIをどこに入れるかも、この表で決まりました。 書類の不備チェックは、撮影した画像から自動で判定できます。そのまま進められた率が低い受け渡しは、AIを入れる価値がある。高い受け渡しに入れても、意味がありません。

⑧ 現場で使うなら、この2枚

図を描く前に、この2枚を埋めてください。

表1：受け渡し（%C/Aの測り方）

列	何を書くか	測り方
渡す側／受け取る側	部署ではなく担当者の役割	—
渡すもの	書類・データ・現物	—
件数	月あたり	実績から
そのまま進められた率	%C/A	受け取る側に聞く。差し戻し・確認・追記が要らなかった割合
手前の待ち時間	前工程の完了から着手までの実測	日時を記録

測り方は、受け取る側に聞くのが確実です。 渡す側は「ちゃんと渡した」と答えるからです。

表2：停止点（同期／非同期の判定）

判定基準	同期で止める	非同期にする
金銭が動く	○
取り消せない	○
外部に送信される	○
上のどれにも当たらない		○

この4行だけで判定できます。 「念のため確認したい」は、非同期で足ります。

⑨ この書き方が効き続ける理由

業務フローの可視化は、DXの第一歩として必ず出てきます。そして多くの現場で、きれいな図が完成した時点で終わります。

図が完成しても業務は速くなりません。図は業務ではないからです。

可視化の目的は、遅い場所と落ちる場所を特定することです。特定できるなら手段は付箋でも表計算でもいい。逆に、特定できない図は、どれだけ美しくても作った時間の分だけ損をしています。

そして、AIが入る時代の業務フローには、もう一つ役割が増えました。AIに渡す仕様書として機能することです。

%C/Aの低い受け渡しは、そのまま「AIを入れるべき場所」の一覧になります。 四角と矢印の図は、そうなりません。

絵を描くのをやめて、2枚の表を書いてください。

---

とはいえ、表は壁に貼っても映えません。

四角と矢印の図は、貼ると「ちゃんと整理している」感じが出ます。表は出ません。だから図が量産されるのだと思います。

壁が寂しい問題については、まだ解を持っていません。以上です。

業務フローの書き方 よくある質問

業務フローとワークフローは、何が違いますか？

業務フローは複数の部署にまたがる業務全体の流れ、ワークフローは申請から承認までの経路という、1つの手続きの中の流れを指します。ワークフローは業務フローの一部です。システムの名前として「ワークフロー」が使われることが多いため、会話の中で指しているものがどちらなのかを先に確認してください。

業務フローとマニュアルは、どう使い分けますか？

業務フローには「誰が、どの順番で、何を渡すか」を、マニュアル・手順書には「どうやるか」を書きます。読む人も違い、業務フローは関係者全員、マニュアルはその作業をする人が読みます。1つの図に両方を書き込むと図が読めなくなるので、手順は別紙にして図から参照する形にしてください。

業務フロー図は、どのくらい細かく書けばよいですか？

目的で決まります。全体像の共有なら業務レベル（「査定する」）、改善の検討なら作業レベル（「査定表に記入し、上長が承認する」）、システム化なら操作レベルです。同じ図で複数の目的を満たそうとすると、どれにも使えない図になります。1枚に収まらなくなったら、粗い図と、箱ごとの詳細図に分けてください。

業務フロー図の抜け漏れを防ぐには、どうすればよいですか？

管理者ではなく実際にその作業をしている人に聞くこと、実物の案件を1件、頭から最後まで追うこと、そして「うまくいかなかったときはどうしますか」と例外から聞くことです。正常な流れは誰でも説明できますが、例外の処理は聞かれないと出てきません。図が現実と食い違う原因は、たいてい例外の側にあります。

業務フロー図の作成ツールは、何を使えばよいですか？

叩き台の段階は、書き換えが速い表計算やスライドで十分です。専用の作図ツールは記号や整列が楽な一方、相手が開けないことがあります。クラウドの作図サービスは共有が速い代わりに版の管理に注意が要ります。最初から専用ツールを使うと、構成を変えるたびに手戻りが出ます。

業務フローとは何ですか？

仕事がどの順番で、誰の手を通り、どこで判断されて進むかを表したものです。フローチャートやスイムレーン図として描かれますが、図の形式そのものに意味はありません。目的は、担当者の頭の中にしかない手順を他人が読める形にして、遅い場所と落ちる場所を特定することです。

業務フロー図には何を書けばいいですか？

四角と矢印の前に、各工程の所要時間と、その手前の待ち時間、そして受け渡しの時点で情報がそろっている割合を入れてください。この3つが無い図は、順番を再確認しただけになります。順番はもともと全員が知っています。

可視化すればAI導入はうまくいきますか？

可視化だけでは足りません。よくある失敗は、既存のフローを残したまま1工程だけをAIに置き換えることです。前後の受け渡しが変わらないので全体は速くなりません。制約理論では、ある工程を速くすると制約は次の工程へ移動するとされています。だから1工程の高速化は、次の待ちを表に出すだけで終わることがあります。

AIを入れたのに全体が速くならないのはなぜですか？

制約が、プロセスの外側にあるからです。実装や作業が速くなっても、印刷物が現場に届いていない、権限の承認が下りない、契約の判断が止まっている、という理由で全体は止まります。生産性が上がると、ボトルネックは工程の内側から外側へ移動します。

情報がそろっていない割合は、どう測るのですか？

受け取る側に聞くのが確実です。渡されたもののうち、そのまま次へ進められたものが何割か。差し戻し・確認・追記が必要だったものが何割か。バリューストリームマッピングでは %C/A（Percent Complete and Accurate）と呼ばれ、下流で手戻りを起こさずに済んだ割合として定義されています。