承認くん
← コラム一覧へ戻る
#決裁ルート・権限

決裁ルート(承認フロー)をどう決めればよいか

決裁ルート(承認フロー)をどう決めればよいか
※ 記事イメージ画像はAIで生成したものです

決裁ルートの設計とは、承認者を並べる作業ではなく役割と順序を決める作業です。承認・合議・回覧の違い、直列と並列で変わる滞留日数、承認段階数の目安、不在時の代理承認の定め方、実務チェックリストまで解説します。

決裁ルートの相談で最初に出てくるのは、たいてい「誰に回せばいいのか分からない」という声です。規程を開くと決裁者は書かれているものの、その手前に何人の確認が入るのか、法務や経理はいつ関与するのか、部長が不在のときは誰が代わるのかまでは書かれていません。結果として、申請者が過去の似た案件を探して同じ人に回す運用が続きます。

決裁ルートの設計とは、この曖昧さを取り除く作業です。誰が何をする役割なのか、順番に回すのか同時に投げるのか、何段階までにするのか、不在時はどうするのか。本記事では、ルートの構成要素の整理から、承認・合議・回覧の区別、直列と並列の使い分け、代理承認の定め方、整備の進め方、形骸化の原因、実務チェックリストまで解説します。

決裁ルートとは何を決めることか

決裁ルートは「承認者を並べたもの」と理解されがちですが、実際には役割の割り当てと順序の設計です。まず用語を揃えます。

ルートを構成する5つの役割

ルートに登場する役割は5つに整理できます。案件を起こす起案者、内容を確認するが可否の権限は持たない確認者、可否を判断して次へ進める承認者、その案件について組織として最終的な意思を確定する最終決裁者、そして自部署の観点から意見を述べる関係部署の合議者です。この5つを混ぜたまま「承認者」と一括りにすると、責任の所在が曖昧になります。

ルートが定まっていないと何が起きるか

ルートが明文化されていない組織では、申請者が「たぶんこの人」と判断して回すため、同じ種類の案件が案件ごとに違う人を通ります。ある発注は経理を通り、似た発注は経理を通らない。監査や振り返りの場面で、なぜその案件だけ手続きが違ったのかを説明できなくなります。稟議書の様式そのものの設計は稟議書のフォーマットを設計する際に押さえておきたい基本で扱っています。

ルート設計の外枠となる会社法上の制約

ルートは社内の都合だけで自由に組めるわけではありません。会社法第362条第4項は、取締役会は「重要な財産の処分及び譲受け」「多額の借財」などの重要な業務執行の決定を取締役に委任することができないと定めています。職務権限基準表で取締役会決議事項と定めた事項を、決議を経ずに決定することは同項違反となりうるとされています。

ただし「多額」「重要」の具体的な金額基準は法律に定めがなく、会社の規模・総資産・経常利益等に照らして個別に判断されます。したがってルート設計では、取締役会決議が必要な案件を最終段として明示的に組み込んでおくことが望ましいです。法令は改正されることがあるため、実際の運用にあたっては最新の公式情報や顧問弁護士・税理士等の専門家に確認してください。

「承認」「合議」「回覧」を分けて設計する

ルートが長くなる原因の多くは、この3つを区別せず全員を承認欄に並べてしまうことにあります。役割ごとに扱いを変えます。

3つの違いを整理する

承認は案件を止める権限を持ち、合議は自部署の観点から意見を返し、回覧は結果を知らせるだけです。混同したまま設計すると、単に知っておきたいだけの部署が承認欄に入り、その人の不在で案件が止まります。

種別 該当する人の例 何をするか 案件を止められるか 履歴の残り方
承認 課長、部長、担当役員、社長 内容を判断して可否を決め、次段へ進める 止められる(差し戻し・否決が可能) 承認日時と氏名が必須
合議(並行審査) 法務、経理、情報システム、人事 自部署の観点で条件・リスクを付記する 条件付きで止められる(要否は規程で定める) 意見内容と日時を残す
回覧(通知のみ) 関連部署の管理者、総務 決定内容を把握する。判断はしない 止められない 閲覧の事実のみ(任意)

承認は案件を止める権限を持つ人、合議は自部署の観点から意見を返す人、回覧は決定を知るだけの人です。通知が目的の関係部署を承認欄に並べると、その人の不在で案件が止まります。

合議に誰を入れるかを案件の性質で決める

合議者は「毎回全員」ではなく、案件の性質で入れどころを決めます。契約書を伴う案件は法務、支払条件や資産計上が絡む案件は経理、社内システムやデータの取り扱いが変わる案件は情報システム、要員数や労働条件に影響する案件は人事、という対応づけが基本形です。該当しない部署を惰性で入れないことが、滞留を防ぐ最短の方法になります。

回覧を承認欄に混ぜない

「知らなかったと言われたくない」という理由で関連部署を承認欄に並べるのは、よくある失敗です。通知が目的なら回覧に置き、決裁後に自動で共有される形にします。承認欄に置くべきなのは、その人が「否」と言えば案件が止まるべき人だけです。この線引きを1回行うだけで、ルートの段階数は目に見えて減ります。

直列と並列の使い分けと段階数の目安

役割を整理したら、次は順序です。ここで滞留日数が決まります。

直列にするか並列にするかで日数が変わる

直列ルートは上長から部長、担当役員へと順に回す形、並列ルートは法務と経理に同時に投げる形です。各段階の処理に1営業日かかると仮定すると、直列4段階なら決裁まで4営業日かかります。このうち法務と経理の2段階を並列化すれば、同じ4人が関与しても3営業日で終わります。並列にできるものを直列にしている限り、待ち時間は人数分だけ積み上がります。

判断の基準は単純で、前の人の判断結果を見なければ意見を出せない関係なら直列、それぞれ独立に意見を出せるなら並列です。法務の契約条項レビューと経理の支払条件確認は互いに独立しているため、並列にして差し支えありません。

段階数は3段階を目安にする

承認の段階数は、3段階を超えたあたりから滞留が目に見えて増えます。段階が増えるほど「前の人が見ているだろう」という意識が働き、1人あたりの確認は浅くなります。人数を増やしても精度は上がらず、日数だけが延びるという構造です。4段階以上が必要に見える場合は、途中の誰かが確認者や合議者に置き換えられないかを先に検討してください。

承認の段階数は3段階を目安に収め、独立して判断できる段階は並列にします。4段階以上が必要に見えるときは、途中の誰かを確認者や合議者に置き換えられないかを先に検討してください。

ルート設計のパターン表

案件の性質と金額帯に応じて、あらかじめ数種類のパターンを用意しておくと、申請者が迷わなくなります。どの金額帯でどのパターンに乗せるかという線引きそのものは稟議の決裁権限(金額基準)をどう設定するかで扱っています。

パターン ルートの構成 所要日数の目安 向く案件 注意点
短縮型 起案者→課長(承認) 1営業日 少額の消耗品、定型の再発注 金額上限を明示しないと乱用される
標準直列型 起案者→課長→部長(承認2段) 2営業日 通常の購買、外注発注 部長不在時の代理を定めておく
並列合議型 起案者→課長→〔法務・経理を並列合議〕→部長 3営業日 契約締結、サブスクリプション契約 合議の回答期限を決めないと滞留する
役員決裁型 起案者→部長→担当役員→社長 4営業日 設備投資、高額の外注 段階が深く、緊急案件に向かない
取締役会付議型 上記に取締役会決議を追加 次回開催日に依存 重要な財産の処分・多額の借財に該当しうる案件 開催日から逆算した申請期限の周知が必要

代理承認と不在時の権限委譲

ルート設計でもっとも抜けやすいのが、承認者が不在のときの扱いです。ここを決めていないと、規程は正しくても現場は止まります。

誰が代理できるかをあらかじめ指名しておく

代理者は、案件が発生してから探すのではなく、役職ごとに第一代理者と第二代理者を規程上で指名しておきます。原則は同格または直上位の職位の者とし、部下が上司を代理する形は避けます。指名した代理者の一覧は、ルート図と同じ場所に掲示しておくと現場が迷いません。

代理時の権限範囲と事後報告を定める

代理承認では、通常の決裁権限をそのまま引き継ぐのではなく、金額の上限を一段下げる設計が実務的です。たとえば部長の代理者は部長決裁の上限額の範囲内であっても、一定額以上については本人の帰任後の追認を要する、といった形にします。あわせて、代理で承認した案件は本人へ事後報告することを必須にし、その報告記録も残す運用にしておくことをおすすめします。

よくあるつまずきと形骸化の原因

ルートは規程に書いた時点では整っていますが、運用の中で少しずつ実態と離れていきます。典型的なパターンは3つです。

規程では部長決裁だが、実際は社長が全件見ている

もっとも多いのがこのズレです。規程上は部長決裁で完結するはずの案件が、慣行として社長のところまで回っています。この状態では、部長は自分の判断が最終ではないと分かっているため踏み込んだ確認をせず、社長は件数が多すぎて一件ずつは読めません。二重に確認しているようで、実際にはどちらも確認していない状態が生まれます。規程を実態に合わせるか、実態を規程に戻すかを、経営層を交えて一度決着させる必要があります。

承認者が多すぎて誰も責任を持って読まなくなる

関係者を漏れなく入れようとした結果、承認欄が6人、7人と並ぶことがあります。この状態では各人が「他の誰かが見ている」と考え、実質的な確認は誰も行いません。承認欄に名前があるのに中身を把握していない人が並ぶことは、責任の所在を曖昧にするという点で、承認者が少ない状態より危険です。

承認が出張中に止まり、口頭で先に発注してしまう

納期の都合で先に発注し、後から稟議を出す「事後稟議」が常態化している組織は少なくありません。一度これを許容すると、正規のルートを通す動機が失われ、決裁は形式だけになります。対策は、事後稟議を全面禁止にすることではなく、緊急時の暫定ルート(責任者への口頭承認+24時間以内の書面化)を正式に定め、その利用件数を月次で集計して見えるようにすることです。件数が多い区分は、通常ルートの段階数か代理指名に問題があります。

事後稟議を全面禁止にするのではなく、緊急時の暫定ルートを正式に定め、その利用件数を月次で集計してください。件数が多い区分は、通常ルートの段階数か代理指名に問題があります。

実務チェックリスト

自社の決裁ルートを点検する際は、次の項目を順に確認してください。「いいえ」が並ぶ箇所が、滞留と形骸化の発生源になっています。

  • 起案者・確認者・承認者・最終決裁者・合議者の役割が、規程上で区別されているか
  • 承認欄に並んでいるのが「否と言えば案件が止まるべき人」だけになっているか
  • 通知が目的の関係部署が、承認ではなく回覧として設定されているか
  • 合議に入れる部署が案件の性質ごとに定められ、惰性で全部署を入れていないか
  • 合議者からの回答期限が定められているか
  • 独立して判断できる段階が、直列ではなく並列に設定されているか
  • 承認の段階数が原則3段階以内に収まっているか
  • 役職ごとに第一代理者・第二代理者が指名され、一覧が現場から見える場所にあるか
  • 代理承認時の金額上限と、本人への事後報告の要否が定められているか
  • 取締役会決議が必要となりうる案件について、最終段が明示されているか
  • 規程上の決裁者と、実際に承認している人が一致しているか
  • 緊急時の暫定ルートが正式に定められ、その利用件数を月次で把握しているか

電子ワークフローに乗せるとどう変わるか

紙や口頭のままのルート運用には、規程の書き方では解消できない問題が残ります。第一に、いま誰の机で止まっているのかが誰にも見えないこと。第二に、承認者が不在のときにルートを切り替える手段が「探して声をかける」しかないこと。第三に、規程と実態がずれても、ずれていること自体が数字として現れないことです。

申請と承認を電子化すると、この3点が可視化されます。案件ごとに現在の滞留段階と経過日数が一覧で表示されるため、どの段階が遅いのかが特定できます。代理承認をあらかじめ設定しておけば、不在時に自動で代理者へ回るため、出張を理由に案件が止まることがなくなります。

加えて、誰がいつ承認・差し戻しをしたかの履歴が自動で残ります。この履歴は監査対応の材料になるだけでなく、ルートの見直しにも使えます。特定の段階だけ平均滞留日数が長いなら、その段階の権限が実態に合っていないか、代理指名が機能していない可能性があります。差し戻しの扱いについては稟議の差し戻し・修正ルールをどう運用するかで整理しています。

本記事で整理したパターンは、そのまま承認くんの承認ルートテンプレートとして設定できます。案件の区分ごとに標準直列型や並列合議型を用意しておけば、申請者は区分を選ぶだけで正しいルートに乗り、誰に回すかを毎回考える必要がなくなります。無料プランがあり、クレジットカードの登録なしでルートの試作から始められます。

まとめ

決裁ルートの設計は、承認者を並べる作業ではなく、役割を割り当てて順序を決める作業です。起案者・確認者・承認者・最終決裁者・合議者の5つを区別し、案件を止める権限を持つ人だけを承認欄に置く。独立して判断できる段階は並列にし、承認の段階数は3段階を目安に収める。各段階1営業日として、直列4段階の4営業日を2段階の並列化で3営業日に縮められる差は、年間の案件数を掛ければ無視できません。取締役会決議が必要となりうる案件は、最終段としてルートに組み込んでおくことが望ましいです。

着手するときは、規程を読み直すより先に、直近3か月に実際に流れた稟議が誰を通ったかを並べてみてください。規程上の決裁者と実際の承認者がずれている箇所、特定の人のところで日数が積み上がっている箇所が、そのまま見直すべき対象になります。そのうえで代理者の指名と緊急時の暫定ルートを定め、パターンとして数種類に整理します。ルートは一度決めたら終わりではなく、実態とのズレを定期的に確認して直し続けることをおすすめします。

承認くんを無料ではじめてみませんか? 無料アカウント登録はこちら(初期費用0円/すぐに使える/3人まで無料)

その運用、そのまま承認くんに設定できます。 料金プランを見る