【業務フローの作り方】仕事の流れを見える化してムダを見つけよう

「この仕事、なんでこんなに時間がかかるんだろう
「同じ情報を何回入力しているんだ？」
「この書類、結局誰が確認しているんだ？」
「担当者が休むと、仕事がどこで止まっているのか分からない」

仕事をしていると、こういうことがあります。

一つひとつの作業だけを見ると、それほどおかしくない。でも仕事全体をつなげて見ると、同じ内容を何度も入力していたり、承認待ちで止まっていたり、部署をまたぐたびに説明し直していたりすることがあります。

そこで使えるのが、業務フローです。
業務フローを作る目的は、きれいな図を書くことではありません。

仕事がどこから始まり、誰が何をして、どこで判断し、誰へ渡り、どこで終わるのかを見えるようにすること。

そして、仕事が止まっているところ、戻っているところ、重複しているところを見つけること。
そこまでできて、業務フローを作る意味があります。

中小企業向けの公的支援サイト「J-Net21」でも、属人化・ブラックボックス化した業務を見える化し、ボトルネックを見つける道具として業務フローが紹介されています。

この記事で分かること

業務フローを作る目的

現状フローと改善後フローの違い

担当者・判断・受け渡しをどう書くか

待ち・手戻り・重複・属人化の見つけ方

業務フローをマニュアルやチェックリストにつなげる方法

IT化・AI化の前に確認したいこと

業務フローは「仕事全体の地図」
最初から理想の業務フローを作らない
まず業務の始まりと終わりを決める
最初は細かくしすぎない
誰がやっているかを分ける
業務フローは記号を覚える試験ではない
判断があるところは分岐させる
誰が判断するかまで見る
作業より人から人への受け渡しを見る
待っている時間を見つける
一度進んだ仕事が戻っていないかを見る
同じ情報を何回作っているかを見る
「これ、誰の仕事？」を見つける
例外ばかりの業務にも注意する
部分だけ改善して全体を悪くしない
業務フローを作る基本手順
現場を知らない人だけで作らない
ただし一人の説明を正解にしない
現状フローと改善後フローは分ける
業務フローを作ったら6か所を見る
「どう早くする？」より「なくせない？」から考える
IT化・AI化は業務フローを見てから
AIに業務フローを作らせるなら現状を渡す
業務フローをマニュアルにつなげる
チェックリストは重要な確認だけ切り出す
業務フローは一度作って終わりではない
まとめ｜業務フローはムダを見つけるために作る
参考にした公的・標準資料

業務フローは「仕事全体の地図」

マニュアルやチェックリストは、一つひとつの作業を細かく見るための道具です。

業務フローは、もう少し上から仕事全体を見ます。

例えば、受注、在庫確認、製造・仕入、出荷、請求といった工程が、どの順番で、誰から誰へ流れているのかを見るものです。

道具	主に見るもの
業務フロー	仕事全体の流れ・受け渡し
マニュアル	作業方法・判断基準
チェックリスト	確認漏れの防止

この3つは別物ですが、つながっています。

最初から理想の業務フローを作らない

業務改善をしようと思うと、「もっと効率のいい流れを書こう」と始めたくなります。でも、最初にやるのはそこではありません。

まず、今、本当にどうやって仕事をしているのかを書きます。これを現状フローとして整理します。

例えば、本来は「受注→在庫確認→出荷」だと思っていた。でも実際に現場へ聞くと、営業が注文を受け、メールを印刷し、事務へ渡し、事務がExcelへ入力し、倉庫へ電話し、在庫回答を受けて営業へ戻し、営業が顧客へ回答しているかもしれません。

この現状を飛ばして理想だけ書いても、何を直せばいいのか分かりません。

まず業務の始まりと終わりを決める

業務フローを書こうとして難しくなる原因の一つが、範囲が広すぎることです。

「受注業務」をフロー化するのか。「受注から出荷まで」なのか。「問い合わせから入金まで」なのか。
最初に範囲を決めます。

開始：顧客から注文を受ける
終了：商品を出荷する

これだけでも、書く範囲がかなり明確になります。

最初は細かくしすぎない

業務フローを作るとき、いきなり「メールを開く」「添付ファイルを保存する」「Excelを開く」まで書く必要はありません。
そこまで細かい操作はマニュアル側の仕事です。

業務フローではまず、

注文受付 → 内容確認 → 在庫確認 → 出荷手配

くらいの粒度で構いません。

J-Net21でも、最初から細部へ入りすぎず、まず概要をざっくりまとめる考え方が紹介されています。

誰がやっているかを分ける

業務フローでかなり重要なのが、誰がその仕事をしているのかです。

営業	事務	倉庫
注文受付
内容確認
→	受注入力
	→	在庫確認
	←	結果回答
顧客へ回答

業務の流れを図で表す国際的な標準表記に、BPMN（Business Process Model and Notation）があります。

BPMNでは「レーン」を使って部署や役割ごとに作業を分け、誰が何を行うかを表現できます。

ただし、普通の社内業務を整理するだけなら、最初からBPMNを完璧に覚える必要はありません。

業務フローは記号を覚える試験ではない

業務フローというと、「四角は処理」「ひし形は判断」「丸は開始」など、記号を覚えなければならないように感じるかもしれません。

社内の業務整理なら、まずは次の4つくらいで十分です。

開始・終了
作業
判断
流れを示す矢印

J-Net21でも、業務フローの書き方に厳密なルールはなく、見た人が理解できることが重要としています。

複雑なシステム設計ではBPMNのような標準表記が役立ちますが、社内で仕事の流れを整理するなら、記号を増やしすぎない方が読みやすいこともあります。

判断があるところは分岐させる

実際の仕事は、いつも一本道ではありません。

例えば「在庫確認→出荷」だけでは、本当の仕事を表していないことがあります。

実際には「在庫はある？」という判断があり、在庫ありなら出荷手配、在庫なしなら仕入手配や顧客への納期確認へ進むはずです。

BPMNでも、こうした条件による分岐を表す考え方があります。

業務フローでは、どこで仕事が分かれるかを見ることが重要です。

誰が判断するかまで見る

例えば、「金額に問題あり？→YESなら承認を取る」となっていたとします。

でも、誰が承認するのかが分からなければ、実務では止まります。

担当者なのか。課長なのか。部長なのか。経理なのか。営業なのか。現場責任者なのか。

業務フローでは、作業だけでなく、判断の責任者も見えるようにすると使いやすくなります。

作業より人から人への受け渡しを見る

業務フローを作るとき、つい一つひとつの作業に目が行きます。でも、問題が起きやすいのは、人から人へ仕事を渡すところだったりします。

営業→事務→製造→物流→経理と渡っていく。そのたびに、情報不足、書式違い、口頭補足、再入力、確認待ちが発生することがあります。

業務フローを書くときは、「この人から次の人へ、何を渡している？」まで見ます。

渡す側	受ける側	渡すもの
営業	事務	注文書・納期・価格
事務	製造	製造指示
製造	物流	完成品・数量
物流	経理	出荷情報

待っている時間を見つける

業務改善というと、「この作業を5分短縮しよう」と考えがちです。でも実際には、作業時間より待っている時間の方が長いことがあります。

作業時間5分。そのあと上司の承認待ち2日。
それなら5分を3分にするより、なぜ2日待っているのかを見た方が効果が大きいかもしれません。

承認待ち
回答待ち
材料待ち
情報待ち
担当者待ち

こうした待ちが、仕事全体のボトルネックになっていることがあります。

一度進んだ仕事が戻っていないかを見る

もう一つ見つけたいのが、手戻りです。

例えば、受注→製造指示→製造開始まで進んだあとで仕様不足が判明し、営業→顧客へ確認して製造へ戻る。

この場合、問題は「製造が遅い」ことではないかもしれません。

製造へ渡す前に必要な情報がそろっていない可能性があります。業務フローでは、矢印が前へ戻っている場所に注目します。

同じ情報を何回作っているかを見る

営業が顧客情報をExcelへ入力。事務が販売管理システムへ再入力。物流が送り状システムへ再入力。経理が請求システムへ再入力。

同じ情報を何度も作っているなら、改善余地があります。

経済産業省のものづくり白書でも、業務プロセスを見える化することで、どこをIT化すべきかが見え、仕事の流れは情報の流れでもあるとする企業事例が紹介されています。

業務フローでは、人の動きだけでなく情報の動きも見ます。

「これ、誰の仕事？」を見つける

フローを書いていると、「不足情報を確認する」「問題があれば対応する」「必要なら承認する」といった仕事が出てきます。

でも、誰がやるのか決まっていない。
日常業務では、「そのとき気づいた人」「いつもやってくれる人」が対応しているだけかもしれません。

これは属人化の一つです。

業務フローにすると、担当が決まっていない仕事も見えやすくなります。

例外ばかりの業務にも注意する

「基本はこうだけど、この顧客だけ違う」「通常はこれだけど、この製品だけ別」「急ぎの場合は別ルート」といった例外が大量に出てくることがあります。

もちろん、本当に必要な例外もあります。

でも、例外処理が多すぎること自体が業務を複雑にしている可能性もあります。

顧客ごとに違う書式
担当者ごとに違う方法
製品ごとに違う管理表
特定の人しか知らない処理

例外を書くだけで終わらず、「この例外、本当に必要？」も考えます。

部分だけ改善して全体を悪くしない

例えば営業部が自分たちの作業を早くするために入力項目を減らした。営業は楽になった。でも事務側で不足情報の確認が増えた。

会社全体では、むしろ時間が増えています。

経済産業省のものづくり白書でも、一部分だけを改善する「部分最適」ではなく、業務全体の流れを見直す重要性が紹介されています。

自分の仕事だけではなく、その前後まで見る。

これも業務フローを作る意味です。

業務フローを作る基本手順

対象業務を決める：例「受注から出荷まで」
始まりと終わりを決める：開始と完了を明確にする
関係する担当者・部署を出す：顧客、営業、事務、製造、物流など
実際の作業を書き出す：理想ではなく今やっている方法を書く
順番に並べる：矢印でつなぐ
判断を入れる：在庫あり？承認必要？規格内？など
例外と戻りを書く：NGならどこへ戻るか
担当を確認する：誰が作業し、誰が判断するか
問題点を書き込む：待ち、二重入力、手戻り、属人化など
改善後のフローを作る：問題を減らした状態を別に作る

現場を知らない人だけで作らない

管理職だけで会議室に集まり、「たぶん現場はこうやっている」と業務フローを書くのは危険です。

実際には、Excelへ転記している、紙に印刷している、電話で補足している、個人メモを使っている、独自チェックをしている、といった工程があるかもしれません。

J-Net21でも、同じ作業に関わる担当者をできるだけ集めて業務フローを作ることで、作業方法の標準化にもつながるとしています。

現状フローは、実際にその仕事をしている人へ聞く。

ただし一人の説明を正解にしない

Aさんに聞くと「うちはこうやっています」と言う。でもBさんに聞くと、「私はその方法ではやっていません」と言うことがあります。

それ自体が発見です。

同じ仕事なのに、担当者ごとにやり方が違うということだからです。

業務フローを作る過程で、「実は標準化されていなかった」ことが見つかることもあります。

現状フローと改善後フローは分ける

現状のフローへ直接修正を書き込むと、元々どうだったか分からなくなります。

そこで、現状フローと改善後フローを分けます。

現状フロー	改善後フロー
今、本当にどうやっているか	何をなくし、変え、追加するか
問題点もそのまま残す	改善策を反映する

こうすると、消した工程、自動化した工程、担当変更、承認削減、新しく追加した確認などが比較できます。

業務フローを作ったら6か所を見る

業務フローができたら、図を眺めて終わりではありません。

見る場所	問いかけ
待ち	ここで何を待っている？
手戻り	なぜ前工程へ戻る？
重複	同じ作業・入力をしていない？
受け渡し	情報不足で聞き直していない？
属人化	この人しかできない仕事はない？
判断	誰が、何を基準に決める？

「どう早くする？」より「なくせない？」から考える

改善するとき、「この工程をどう早くする？」だけで考えない方がいいです。
その前に、そもそも、この工程は必要？と考えます。

毎月30分かけてExcel報告書を作っている。そこでマクロを組んで10分にする。それも改善です。

でも、誰もその報告書を見ていないなら、作業そのものをなくす方が大きな改善です。

やめられないか
減らせないか
まとめられないか
順番を変えられないか
そのあと自動化できないか

IT化・AI化は業務フローを見てから

今なら、「AIで自動化しよう」「RPAを入れよう」「新しいシステムを導入しよう」という話も出てきます。

でも、今の業務が整理されていないまま自動化すると、ムダな仕事まで自動化する可能性があります。

例えば、紙へ印刷→押印→スキャン→PDF保存という業務。

「スキャンを自動化しよう」と考える前に、そもそも印刷と押印が必要なのかを確認する。

この順番が重要です。

AIに業務フローを作らせるなら現状を渡す

AIに「受注業務の業務フローを作って」とだけ頼めば、それらしいものは作れます。

でも、それはあなたの会社の業務フローではありません。一般的な受注業務をAIが補って作ったものです。

AIを使うなら、実際の現状を渡します。

顧客からメールで注文を受ける。
営業が内容をExcelへ記録。
事務へメール転送。
事務が在庫担当へ電話。
在庫回答後、営業へ連絡。
営業が顧客へ納期回答。

そのうえで、

担当者ごとに分けて業務フロー案にしてください。
判断箇所、手戻り、二重入力、待ち時間になりそうな場所を示してください。
入力情報にない工程は勝手に追加せず「要確認」としてください。

と頼みます。

文章や図の整理はAIに任せられますが、本当に現場がその流れなのかは人が確認します。

業務フローをマニュアルにつなげる

業務フローを作ると、「受注入力→在庫確認→出荷処理」といった全体の流れが見えます。

では、「受注入力はどうやるの？」となったときに使うのがマニュアルです。

業務フローで全体を見る。各工程の詳しいやり方はマニュアルを見る。

詳しい手順だけでなく判断基準や異常時対応まで残す方法は、こちらで解説しています。

【マニュアルの作り方】手順だけでなく判断基準まで残す

業務マニュアルの作り方を実務向けに解説。事務・製造・工事の具体例を使い、手順だけでなく判断基準、異常時対応、完了条件、写真やチェックリストの使い分けまで紹介します。

チェックリストは重要な確認だけ切り出す

在庫確認の中で、品番・数量・ロット・状態を必ず確認する。それなら、その部分はチェックリストにできます。

業務フローで全体、マニュアルで方法、チェックリストで確認。この3つは、一つの仕事を違う角度から見ています。

使われるチェックリストの作り方は、こちらで解説しています。

【仕事のチェックリスト】作って終わりにしない使える作り方

仕事のチェックリストの作り方を実務向けに解説。事務・製造・工事・物流の例を使い、確認項目、完了条件、使うタイミング、NG時対応、形骸化を防ぐ見直し方まで紹介します。

業務フローは一度作って終わりではない

仕事は変わります。

人が変わる
システムが変わる
顧客が変わる
商品が変わる
組織が変わる
自動化される

だから業務フローも更新します。

「昔はこの承認が必要だった」「昔のシステムのために残っている」といった仕事は、業務変更後も残り続けることがあります。

まとめ｜業務フローはムダを見つけるために作る

業務フローは、きれいなフローチャートを書くことが目的ではありません。

仕事がどう流れているのかを見えるようにして、問題を見つけるための道具です。

まず、今、本当にどうやって仕事をしているのかを書く。