業務フロー図なしに自動化を始めると何が起きるか

自動化を始めるとき、多くの現場では「どのツールを使うか」の議論が先行します。Zapier、Make、スプレッドシートのマクロ、RPAなど、ツールの選定は具体的な作業に見えるため議論が進みやすいのですが、その前に「今の業務がどう流れているか」を図にしておかないと、自動化後に多くの問題が発生します。フロー図がないまま進むと、三つの典型的な失敗パターンが起きます。

一つ目は「例外が想定外の頻度で発生する」問題です。フロー図を描くと、「通常パターン」の他に「月末のみの処理」「担当者が休みの場合」「データが欠けているときの扱い」などの分岐が浮かびます。これが見えていないと、自動化が例外に当たった瞬間にエラーが出て止まります。二つ目は「入口と出口が曖昧」な問題で、どのデータが来たときに動き出し、何を出力したら完了とするかが定まっていないと、後工程の担当者が「自動化されたのかどうか分からない」状態になります。三つ目は「責任が宙に浮く」問題です。自動化されると誰も確認しなくなりやすく、エラーに誰も気づかない状態が続くことがあります。

フロー図は完璧でなくてよいというのが実務上の重要な考え方です。A4一枚の手書きのフロー図でも、「今どこでどんな処理をしているか」を一枚に収めると、見落としていた分岐が共有されます。特に「誰が判断するか」を書き込むと、自動化できる領域と人が判断すべき領域の境界が自然に見えてきます。フロー図を描く過程で、「この分岐はAさんの経験則で処理していた」という暗黙知が表面化することも多く、それ自体がリスク管理になります。

自動化の設計で最初に決めるべきは、処理の「入力条件」「正常終了の定義」「異常時の通知先」の三点です。この三点が定まると、自動化の範囲が絞られ、実装しやすくなり、運用者が引き継げる構造が生まれます。多くの現場で「自動化したけど怖くて使っていない」という状態が起きますが、これはほぼ必ずフロー設計が不十分なまま実装が進んだ結果です。自動化に使う時間の3分の1を事前のフロー整理に充てることで、あとの実装と運用が大幅に楽になります。ツールの選定はその後で行うのが、長続きする自動化の順番です。