業務フローの可視化は何から始める？待ち時間・手戻りを見つける手順

「みんな忙しいのに、依頼した仕事がなかなか終わらない」。その理由を探そうとして、担当者ごとの仕事一覧を作っても、改善する場所が見えないことがあります。仕事が止まるのは、一人が作業している時間だけではないからです。

業務フローの可視化は、仕事の始まりから完了までをつなぎ、担当が変わる場所、待つ場所、やり直す場所を見えるようにすることです。最初から全社の業務を図にする必要はありません。遅延や差し戻しが続く仕事を一つ選び、実際の案件がどう流れたかをたどるところから始めましょう。

この記事では、部署をまたぐ申請業務を架空例として、可視化の範囲、記録項目、改善対象の選び方を説明します。最後に決めるのは「誰が遅いか」ではなく、「どの受け渡しを変えると、全体が進みやすくなるか」です。

業務一覧・マニュアル・業務フローは、見るものが違う

業務一覧は、どんな仕事があるかを整理します。マニュアルは、担当者がどう作業するかを説明します。業務フローは、入力から成果物まで、誰が何を受け取り、どの条件で次へ渡すかをつなぎます。

たとえば「申請内容を確認する」という一覧だけでは、その申請がいつ届き、確認できない理由は何か、差し戻した後にどこへ戻るかが分かりません。業務フローでは、その前後まで確認します。操作手順を細かく残したいときは、業務マニュアルの作り方を併用してください。

デジタル庁の自治体窓口DXでも、窓口だけでなく裏側の業務を含めて見直し、利用者と職員の双方の負担を減らす考え方が示されています。これは行政向けの取組ですが、企業の業務を考える際にも「受付だけ速くして、後工程を詰まらせない」という視点を参考にできます。出典：デジタル庁「自治体窓口DX」

最初は、始点・終点・対象案件を一つずつ決める

「購買業務を可視化する」では範囲が広すぎます。まずは「通常の備品購入で、申請を作り始めてから発注受付が完了するまで」のように、始点と終点を具体化します。受付後からだけ測ると、申請者が書類を用意する負担が消えてしまう点にも注意してください。

例外を対象外にする場合も、存在と件数は残します。「通常業務は速い」と結論づけても、実際には例外が多ければ、利用者の困りごとは解消しません。

実際の案件をたどり、担当者ごとの説明をつなぐ

手順書より先に、最近の案件を確認する

手順書は正式な流れを知る資料になりますが、現場では事前相談、チャットでの確認、表への転記などが追加されていることがあります。最近完了した通常案件と、差し戻しがあった案件を選び、「何を受け取り、何を確認し、何を渡したか」を担当者に聞きます。

件数は調査できる範囲で構いませんが、少数の案件を全体の平均とは扱わないでください。繁忙期、担当者不在、月末締めなど、観察した期間の条件も記録します。個人名や申請内容そのものは共有資料へ必要以上に載せず、案件番号を置き換えても工程の分析はできます。担当者が不在のときに止まる工程が見つかったら、担当者不在でも進められるようにする属人化対策で、代替担当と判断基準を整えます。

一つの工程には、一つの動作を書く

「購買対応」のような大きな箱を作ると、入力確認、取引先照会、発注登録が混ざります。「申請内容を確認する」「不足情報を申請者へ返す」「発注を登録する」と動作で分けましょう。分岐には「不備あり／なし」、矢印には「確認済み申請データ」など、次へ渡すものを書きます。

図の道具は紙や表計算でも十分です。担当者ごとに横の列を置き、工程を左から右へ並べると、部署間の受け渡しを見つけやすくなります。専用ツールの選定より、実際の担当者が「この流れで合っている」と確認できることを優先します。

1. 申請者：申請を作成
   用途・品目などを記入して、所属上司へ渡す。
2. 所属上司：用途・予算を承認
   承認済みの申請を購買担当へ渡す。
3. 購買担当：内容を確認
   不備がなければ発注受付へ。不備があれば、理由を添えて申請者へ戻す。
4. 不備がある場合：申請者が追記
   不足情報を補い、購買担当へ再提出する。
5. 購買担当：再確認・発注受付
   確認を終え、申請者へ完了を通知する。

この図は受け渡しを見るためのものです。待ち時間や作業時間は、次の表で別に確認します。

処理時間と待ち時間を分けて記録する

手を動かしていた時間と、着手されずに止まっていた時間を混ぜると、「確認をもっと速く」という対策に偏ります。次の表は説明用の架空データです。すべて営業時間内に換算した時間で、工程は順番に進み、並行作業はないものとします。

この1件では、実作業は50分、待ちは600分、合計650分です。入力を5分短くする案だけでなく、承認する時間帯や、用途の記入不足が起きる条件を調べる価値があると分かります。ただし、これだけで「承認者が原因」とは決められません。必要情報の不足で承認に着手できないケースも考えられます。

複数工程が同時に動く業務では、各工程の時間を単純に足して完了時間にしないでください。開始・終了の時刻から全体の経過時間を取り、各担当の作業時間は別に合計します。休日を含む暦日と営業時間も、同じ列では混ぜません。

待ちが長い場所で、何がそろわず止まっているかを見る

待ち時間は調査の入口です。次の質問で、原因の仮説を具体化します。

• 着手できる件数を超えて依頼が来ていないか。
• 次の担当が作業するための情報・権限がそろっているか。
• 受付の締切や、まとめて処理する時間帯が決まっているか。
• 不在時に引き受ける人がいるか。
• 差し戻し理由は、入力不足・判断の不一致・仕様変更のどれか。
• 急ぎの割込みで、通常案件が後回しになっていないか。

記録表には、案件区分、受付日時、着手日時、完了日時、差し戻し理由、次の確認先を残すと調べやすくなります。処理時間が短い案件だけを選ばず、止まったままの案件も確認してください。未完了分が抜けると、全体が実際より速く見えます。

担当者の人数や負担が偏っている場合は、業務分担の偏りを見直す手順が役立ちます。ただし、人を増やす前に、同じ情報の再確認や不要な受け渡しがないかも見ます。

改善対象は「影響・根拠・変えられる範囲」で選ぶ

フローができたら、気になる箇所をすべて改善しようとせず、次に検証する場所を一つ決めます。「待ち時間が長い」「差し戻しが多い」は候補ですが、件数、顧客への影響、変更に必要な権限を合わせて比べましょう。

この段階で承認を勝手に省略する必要はありません。なぜ必要かを確認できない工程は、「不要」とせず、確認先と期限を置きます。部門をまたぐ変更の合意が必要なら、他部署との優先順位・責任分担の調整方法へ進めます。

可視化の完成は、図ができたときではない

申請者と受け手にフローを見せ、通常案件と例外案件を一つずつ通してみてください。「この場合は図にない確認が入る」「ここで誰が決めるか分からない」と言われたら、調査すべき箇所が見えたということです。

最後に、調査対象、確認した期間、未確認の工程、最初に変える候補、判断者、次の確認日を残します。新しい図を保管するだけでなく、誰が更新するかも決めましょう。まずは今週、遅れた案件を一つ選び、最初の依頼から完了までを当事者とたどる。それが、忙しさの正体を共有できる最初の一歩です。現状が分かり、工程の廃止・統合を検討する段階になったら、BPRで工程を再設計する手順へ進めます。