「承認が遅いんです」は、だいたい誰のせいでもない
ある日、業務部門からこんな話を聞きました。
「承認フローがとにかく遅くて…
月末になると全部詰まるんですよね」
よくある話です。
でもここで不思議なのが、
-
承認者がサボっているわけでもない
-
フロー自体はシンプル
-
システムも一応動いている
なのに、なぜか遅い。
誰かが悪い感じもしない。
でも確実に業務は滞っている。
体感ベースの議論が、状況を分からなくしていた
よくある会話がこれ。
-
「部長の承認が遅い」
-
「いや、課長で止まってる」
-
「結局、承認フローが長すぎるんじゃ?」
全部、感覚の話。
どこで・どれくらい・どのタイミングで
止まっているのかは、誰も説明できない。
ここで思いました。
これ、感想じゃなくて
データで見たらどうなるんだろう?
使ったのはPython。理由はそれだけ
選んだ道具はPython。
理由はシンプルです。
-
承認ログはCSVで取れる
-
加工が楽
-
グラフにすぐできる
特別なAIでも、難しい分析でもない。
データはこんな感じ
ログはよくある形式。
| 申請ID | 承認者 | 承認依頼日時 | 承認完了日時 |
|---|---|---|---|
| A001 | 課長 | 2024/11/1 10:12 | 2024/11/1 10:30 |
| A001 | 部長 | 2024/11/1 10:31 | 2024/11/2 09:05 |
これを使って、
-
承認にかかった時間
-
時間帯
-
承認者ごとの滞留
を見てみました。
Pythonでやったこと(ざっくり)
やったことはこれだけ。
-
CSVを読み込む
-
承認完了 − 依頼 の差分を計算
-
時間帯ごとに集計
-
グラフ化
コードも難しくないです。
import pandas as pd
df = pd.read_csv("approval_log.csv", parse_dates=["承認依頼日時", "承認完了日時"])
df["承認時間(分)"] = (df["承認完了日時"] - df["承認依頼日時"]).dt.total_seconds() / 60
この時点で、もう「見える化」は始まってます。
見えてきた“本当の理由”
グラフにしてみて、正直ちょっと驚きました。
① 承認者別では、そこまで差がない
「〇〇さんが遅い説」は、
ほぼ否定されました。
平均すると、
-
課長:15〜20分
-
部長:20〜30分
極端な遅さはない。
② 遅延は“時間帯”に集中していた
一番きれいに出たのがこれ。
-
10:00〜16:00 → 早い
-
17:30以降 → 急激に遅くなる
-
翌朝まとめて承認
つまり、
夜に投げた承認は、翌朝まで寝かされる
当たり前だけど、
データで見ると納得感が違う。
③ 月末に遅くなる理由も、ちゃんとあった
月末だけ異常に遅い理由。
-
承認件数が2〜3倍
-
承認者の処理能力は一定
結果、
詰まるのは構造的に必然
誰のせいでもなかった。
ここで初めて、建設的な話ができた
この可視化を見せたあと、
議論のトーンが一気に変わりました。
-
「じゃあ夕方以降は翌営業日扱いにしよう」
-
「月末は承認者を一人増やそう」
-
「急ぎは別フローにしよう」
感情の話が一切出ない。
データって、やっぱり強い。
Pythonは“原因を責める道具”じゃなかった
今回やってみて思ったのは、
-
Pythonでやったのは
-
誰かを評価することじゃない
業務の構造を可視化しただけ
それだけで、
-
無駄な犯人探しが消え
-
話が前に進んだ
Power Automateと組み合わせたら、さらに楽だった話
ちなみにこのあと、
-
承認ログの自動取得 → Power Automate
-
可視化 → Python
という流れにしたら、
「承認が遅くなり始めたら、自然に気づける」
状態になりました。
ここでもまた、
Power Automate、現場で知られてなさすぎ問題
が顔を出すんですが、それはまた別の話。
総括:承認が遅い理由は、人じゃなかった
今回の結論はシンプルです。
-
承認フローが遅い
-
=誰かが悪い
じゃない。
-
時間帯
-
件数
-
構造
これを見える形にしただけで、
解決策は自然に出てきた。
最後に
「承認が遅いんです」と言われたら、
-
仕組みを疑う
-
タイミングを見る
-
数で見る
Pythonはそのための、
ちょうどいい虫眼鏡でした。