2026-08-07
承認を増やすほど現場が止まる——決裁フローに潜む「待ち時間」を計る
Argora編集部
承認フローを厳しくするほど統制が高まるとは限らない。現実には、誰も反対しないまま1週間止まることの方が多い。チェックを増やす前に、まず止まっている時間を数えることが先決だ。
承認は「統制」ではなく「通過儀礼」になっていないか
決裁を厳しくする動機は、たいてい統制の強化にある。不正を防ぐ、品質を担保する、責任の所在を明確にする。どれも正当な理由だ。しかし承認ステップを重ねるうちに、もう一つの現象が静かに起きる。誰も止めていないのに、案件が1週間動かない。
これを「通過儀礼」と呼ぶことにしたい。承認者は書類を受け取り、問題がないことを確認して押印する。却下も差し戻しも発生しない。にもかかわらず案件は、承認者のメールボックスの中で静止し続ける。この間、現場は次の手を打てないまま待つ。
問題は承認者の人柄でも、仕事の遅さでもない。「このステップは本当に必要か」という問いが、設計の段階で抜け落ちていることだ。
止まっている時間を、まず数える
改善を始めるなら、計測が先だ。感覚で「承認が遅い」と言う前に、事実を数字にする。
確認すべきは次の3点だ。
- 各ステップの滞留時間——申請が届いてから承認が完了するまで、実際に何日かかっているか。
- 却下・差し戻しの発生率——過去半年で、そのステップが案件を止めたのは何件中何件か。
- 承認者の実質的な検討時間——承認に使われた時間のうち、実際に書類を読んでいた時間はどれくらいか。
多くの現場でこれを計測すると、ある共通点が見えてくる。滞留時間は長いが、却下率はほぼゼロ。この組み合わせは、そのステップが事実上「通過儀礼」になっているサインだ。
承認の滞留時間と却下率を並べると、「本当に必要な承認」と「あってもなくても変わらない承認」が見えてくる。
「却下」を設計に組み込む——やらないことを決める、健やかなDXの土台でも書いたように、やらないことを明示的に設計に組み込む発想は、承認フローにも同じく適用できる。どのステップを「残さない」かを先に決めると、フロー全体の目的が整理されやすくなる。
承認の数ではなく、「重さ」を設計する
承認を減らすことが目的ではない。形式的な承認を減らし、実質的な承認を重くすることが目的だ。
そのために有効なのは、承認の基準を「案件の性質」で分ける設計だ。
- 金額基準——一定金額以下は一次承認のみ、上限を超えたら二次承認へ。
- リスク分類——新規取引先・初回発注・例外事項は丁寧に審議、定型案件は省略。
- 例外フラグ——過去の決裁履歴と照合し、標準パターンから外れるものだけを上位に回す。
こうした設計にすると、承認者は本当に判断が必要な案件にだけ集中できる。現場は日常的な案件を滞留させずに進められる。統制は失われるのではなく、機能すべき場所に集まる。
自動化はどこで止めるか——「手を残す仕事」の見つけ方で触れた問いと同じ構造がここにもある。すべてを人が見るのでも、すべてを流すのでもなく、「見るべき場所だけを見る」設計が、現場の速度と組織の統制を両立させる。
承認フローの再設計は、決して統制を緩めることではない。チェックを増やす前に、いまどこで・どのくらい止まっているかを一度数えてみる。その計測から見えてくるものが、次の設計の出発点になる。
フローの棚卸しや業務設計の整理を伴走しながら進めたい場合は、しぼる(DX伴走支援)からご相談ください。
FAQ
よくある質問
承認フローが多すぎると何が問題になりますか?
承認者が実質的な判断を行わない「通過儀礼」が増え、誰も止めていないのに案件が滞留し続ける状態が生まれます。
承認の待ち時間を減らすにはどうすればいいですか?
まず各ステップの滞留時間と却下率を計測し、誰も止めていないのに時間がかかっているステップを特定することが先決です。
承認を減らすと統制が弱くなりませんか?
必ずしもそうではありません。金額・リスク・例外性で承認の重みを設計し直すことで、形式的な承認を減らしながら実質的な統制を維持できます。
Related
Argo:デジタルの、ほかの読みもの
2026-08-11
自動化は業務フローを固定する——AIエージェントを乗せる前に確かめること
AIエージェントを業務に組み込む前に、問うべきことがある。自動化はフローを固定する技術であり、整っていないものを乗せれば、誰も読めない仕組みが生まれる。
2026-08-10
「非効率」と呼ぶ前に受け取るべきもの——現場の経験を失わないDXの進め方
アナログな業務を「非効率」と断じてデジタル化を進めると、現場が培った判断力と責任感ごと失いかねない。経験を受け取ってから設計することが、DXを根付かせる起点になる。
2026-08-10
ベンダーを動かすのは仕様書ではない——事業者が磨くべき「課題を語る力」
システム開発の失敗の多くは、技術ではなく「課題の伝わらなさ」から起きる。事業者がITを学ぶとはコードを書くことではなく、問いを立てる力を身につけることだ。