承認フローの見直しは、承認者の人数を減らすところから始めると失敗します。先にやるべきなのは、いまある各段階の承認が何のためにあるのかを判定することです。承認の役割は、大きく「決定」「牽制」「専門の確認」「通知」の4つに分けられます。決定は1人に絞り、牽制は残し、専門の確認は並べて同時に回し、通知は承認から外して回覧に移す。これが見直しの基本の形です。
役割を判定せずに段階を削ると、不正や誤りを防ぐための牽制まで外してしまい、事故のあとで元より長い経路に戻ります。この記事では、棚卸し表の見本と役割の判定の仕方、見直しの手順、そして見直した経路が元に戻る原因を扱います。
承認が増え続ける構造
承認の段階は、事故やトラブルのたびに足されていきます。足す理由はそのつどありますが、外す手続きはどこにも書かれていません。その結果、経路は一方向に長くなります。
もう1つの原因は、各段階の承認者が何を見ればよいかが書かれていないことです。見る観点が決まっていないと、承認者は前の人が押したことを根拠に押すようになります。段階が多いほど、1人ひとりが「ほかの人が見ているだろう」と考え、実際にはだれも中身を見ていない状態が生まれます。
紙からワークフローシステムに移すときに、紙の経路をそのまま写すことも、長い経路を固定する原因です。移動の時間は減りますが、承認者の数と順番は変わりません。承認が長くなる原因そのものの分析は、承認プロセスが長い原因。例外管理と権限移譲で業務を高速化で扱っています。
各段階の承認の役割を判定する
| 役割 | 何のためにあるか | 見直しでの扱い |
|---|---|---|
| 決定 | その案件を実行するかどうかを決め、結果に責任を負う | 1件につき1人に絞る |
| 牽制 | 申請する人と承認する人を分け、不正や誤りを防ぐ | 残す |
| 専門の確認 | 法務・経理・情報システムなど、専門の観点で問題が無いかを見る | 決定の前に、並べて同時に回す |
| 通知 | 関係者に知らせる | 承認から外し、決裁後の回覧にする |
牽制の役割は、内部統制の考え方に沿ったものです。企業会計審議会の実施基準（2023年改訂）は、統制活動を「経営者の命令及び指示が適切に実行されることを確保するために定める方針及び手続」と定め、例として「取引の承認、取引の記録、資産の管理に関する職責をそれぞれ別の者に担当させること」で担当者間の相互牽制を働かせることを挙げています。申請者・承認者・記録する人・お金や物を扱う人を分けている段階は、短縮の対象にしません。
一方で、「部長も知っておいた方がよいから」という理由で置かれた段階は通知です。通知のために決裁を止める必要はありません。
決定の段階が複数ある経路も、よく見られます。課長・部長・本部長がそれぞれ「決定」のつもりで押していると、実際にはだれが決めたのか分からなくなります。決定する人を1人に決める方法は、稟議の責任の所在を明確にするRACIによる単独決裁の導入で扱っています。
見直しの手順
1. 経路を棚卸しする
申請の種類ごとに、いまの経路を表にします。見本は次のとおりです。
| 申請の種類 | 月の件数 | 経路（順番） | 各段階の役割 | 申請から決裁までの日数 | 差し戻しの件数 |
|---|---|---|---|---|---|
| 備品の購入 | （記入） | 課長→部長→経理→総務部長 | 決定→決定→確認→通知 | （記入） | （記入） |
| 業務委託の契約 | （記入） | 課長→部長→法務→経理→役員 | 牽制→決定→確認→確認→決定 | （記入） | （記入） |
| 出張の申請 | （記入） | 課長→部長→総務 | 決定→通知→確認 | （記入） | （記入） |
件数と日数は、ワークフローシステムの記録か、直近3か月の申請書から取ります。見直しの効果を後で説明するための、最初の数字になります。
2. 役割を判定する
表の各段階について、承認者本人に「この段階で何を見ていますか」と聞きます。答えが「前の人が見ているので形式的に」「知っておくため」なら、通知に分類します。答えが具体的な観点（予算の残高、契約条項、情報の持ち出し）であれば、確認か決定です。
3. 経路を組み直す
判定の結果をもとに、経路を組み直します。
- 決定は1人に絞る。金額や性質で決定者を分ける場合は、分岐の条件を書く
- 専門の確認は、決定の前に並べて同時に回す
- 通知は決裁の後の回覧に移す
- 牽制の段階はそのまま残す
金額で決定者を分ける場合の上限は、決裁権限規程と揃えます。規程の作り方は決裁権限の設計｜金額基準・性質基準と事後監査の作り方を参照してください。
4. 規程とシステムの両方を直す
経路を変えたら、決裁権限規程（または職務権限規程）と、ワークフローシステムの経路の設定を同じ日に直します。片方だけを直すと、監査のときに「規程ではこの経路だが、実際は別の経路で決裁されている」という食い違いが生まれます。
5. 試行する
いきなり全部の申請に当てはめず、件数の多い申請の種類を2〜3個選んで、1〜2か月試します。試行の間に出た問題は、承認者の不安（「知らないうちに決まっていた」）と、例外の扱いに分けて記録します。
6. 測って決める
試行の前後で、申請から決裁までの日数、差し戻しの件数、承認者1人あたりの処理件数を比べます。数字が改善していれば、ほかの申請の種類に広げます。
実行時の落とし穴
- 牽制の段階まで外す。 速さを優先して、申請者と承認者が同じ人になる経路を作ると、不正や誤りを見つける仕組みが無くなります。
- 通知に移した人の不安を放置する。 承認から外れた管理職は、「知らないうちに決まっていた」と感じると、別の場で事前の相談を求めるようになります。回覧が確実に届くことと、異論がある場合の申し出方を決めておきます。
- 例外の申請だけ元の経路に残る。 規程に当てはまらない案件を「念のため」全員に回す運用が残ると、例外の件数が増えるにつれて元の長さに戻ります。
- 外す条件を書かない。 見直した後も、事故のたびに段階が足されていきます。段階を足すときの判断者と、足した段階を見直す時期を規程に書いておくことが歯止めになります。
稟議の多段階の承認をまとめて見直す進め方は、稟議のスタンプラリーを廃止し決裁を高速化するBPRでも扱っています。
