申請・承認機能を持つ業務システムを作るとき、意外と難しいのが「承認者権限の設計」です。
単純なケースなら、
申請者
↓
課長
↓
部長
↓
承認完了
というワークフローで問題ありません。
しかし実際の企業では、
- 課長が休暇中なので代理承認させたい
- 1人が複数部署を兼務している
- 金額によって承認者を変えたい
- 部長自身が申請した場合は誰が承認するのか
- 組織変更で承認者が変わる
- 退職した社員の承認待ち申請が残っている
といった例外が発生します。
こうしたケースを考えずにシステムを作ると、運用開始後に承認が止まったり、想定していない人が承認できたりする問題が起こります。
結論からいうと、承認者権限を設計する際は、特定の「人」だけで承認ルールを作るのではなく、
組織・役職・権限・条件・例外ルール
を分けて考えることが重要です。
この記事では、承認者権限の基本的な考え方から、代理承認、兼務、自己承認、金額別承認、異動・退職まで、実際の業務システムを想定して解説します。
承認者権限とは
承認者権限とは、
「誰が、どの申請に対して、どの操作を行えるか」
を決めるルールです。
例えば購買申請であれば、
- 申請者は申請できる
- 課長は10万円未満を承認できる
- 部長は100万円未満を承認できる
- 100万円以上は役員承認が必要
といったルールがあります。
単純に「課長なら承認できる」とするのではなく、
- 対象部署
- 申請種類
- 金額
- 申請者
- 現在のステータス
などによって承認可否が変わることがあります。
そのため、承認権限は単なるユーザー権限ではなく、業務ルールの一部として設計する必要があります。
承認者権限の設計で最初に分けて考えたいもの
承認システムを設計するときは、いきなり画面やデータベースを考えるのではなく、まず次の要素を分けて整理します。
ユーザー
システムを利用する本人です。
例えば、
- 山田太郎
- 佐藤花子
- 鈴木一郎
といった社員を指します。
組織
ユーザーが所属する部署です。
例えば、
- 営業部
- 管理部
- 開発部
- 東京支店
- 大阪支店
などです。
役職
組織内での立場です。
例えば、
- 一般社員
- 主任
- 課長
- 部長
- 本部長
- 役員
があります。
権限
システム上で何をできるかを定義します。
例えば、
- 申請
- 承認
- 差し戻し
- 却下
- 代理承認
- 全件閲覧
- 設定変更
などです。
この4つを同じものとして扱ってしまうと、後から柔軟な運用が難しくなります。
「山田さんが承認する」という設計を避ける
承認システムでよくあるのが、承認者として特定の社員を直接設定する方法です。
例えば、
営業部の購入申請
↓
山田さん
↓
田中さん
という設定です。
一見すると分かりやすいですが、この方法には問題があります。
山田さんが、
- 異動する
- 退職する
- 長期休暇を取る
- 昇進する
たびに設定変更が必要になるからです。
可能であれば、
営業部
↓
営業課長
↓
営業部長
のように、組織や役職を基準に承認者を決定する設計を検討します。
実際の承認時には、
「現在、営業課長の役職についているユーザー」
をシステムが取得します。
こうすると、人事異動が発生しても組織マスタを変更するだけで承認者を切り替えやすくなります。
承認者権限を設計するときの8つのポイント
1. 人ではなく役割を基準にする
基本となる考え方です。
例えば、
申請者の所属部署の課長
↓
同じ部署の部長
↓
管理部長
というように設計します。
これにより、担当者が変わっても承認ルールそのものを変更する必要がありません。
ただし、中小企業では、
「この業務だけは社長が確認する」
など個人指定が必要なケースもあります。
その場合は、
- 基本は役職指定
- 特殊なケースのみユーザー指定
という設計にすると管理しやすくなります。
2. 承認金額を考慮する
購買、経費、見積、値引きなどでは金額によって承認権限が変わることがあります。
例えば、
10万円未満
→ 課長
10万円以上100万円未満
→ 課長＋部長
100万円以上
→ 課長＋部長＋役員
というルールです。
この場合、
「課長」
という役職だけでなく、
「課長は10万円未満まで承認可能」
という決裁限度額も管理する必要があります。
金額だけでなく、
- 値引率
- 契約期間
- 商品種別
- 顧客区分
などが承認条件になるケースもあります。
3. 自己承認を許可するか決める
見落とされやすいのが自己承認です。
例えば、営業部長本人が経費申請をした場合、
申請者：営業部長
承認者：営業部長
となってしまう可能性があります。
この場合、
「申請者と承認者が同一人物なら次の承認者へ送る」
といったルールが必要です。
例えば、
営業部長が申請
↓
営業部長承認をスキップ
↓
本部長承認
とします。
システム上では、
申請者IDと承認者IDが一致する場合の処理
をあらかじめ決めておく必要があります。
4. 代理承認を設計する
管理職が常に出勤しているとは限りません。
- 出張
- 有給休暇
- 育児休業
- 病気
- 長期不在
などが発生します。
承認者が不在になるたびにシステム管理者が承認者を変更する運用では負担が大きくなります。
そこで必要になるのが代理承認です。
代理承認はどう設計する？
代理承認では、
「誰が誰の代わりに、いつからいつまで承認できるか」
を管理します。
例えば、
代理元：営業部長
代理者：営業副部長
開始日：8月1日
終了日：8月10日
という設定です。
代理期間を必ず管理する
代理承認を無期限で設定すると、
本人が復帰した後も代理者が承認できる
という問題が起こる可能性があります。
そのため、
- 開始日時
- 終了日時
を持たせる設計が基本です。
代理できる業務を限定する
すべての承認権限を代理させる必要があるとは限りません。
例えば、
経費申請
→ 代理可能
契約承認
→ 代理不可
100万円以上の決裁
→ 代理不可
というルールも考えられます。
そのため、
「代理承認可能か」
を申請種別や決裁金額ごとに設定できると柔軟です。
誰の代理で承認したか履歴を残す
代理者が承認した場合、
「佐藤さんが承認した」
だけでは不十分です。
例えば、
承認者：佐藤花子
承認種別：代理承認
代理元：山田太郎
承認日時：2026/07/30 10:30
という形で保存します。
監査や後日の確認を考えると、
実際に操作した人と、本来の承認者を両方保存する
ことが重要です。
兼務している社員はどう扱う？
承認者権限の設計で難しいケースの一つが兼務です。
例えば山田さんが、
営業部長
兼
事業企画部長
だったとします。
単純に、
ユーザー
↓
部署
という1対1のデータ構造にすると、この状態を表現できません。
そのため、実際の組織では、
ユーザー
↓
所属情報
↓
部署＋役職
という関係を複数持てるようにする方法があります。
例えば、
山田太郎
├ 営業部 / 部長
└ 事業企画部 / 部長
という形です。
主所属と兼務を分ける
さらに、
- 主所属
- 兼務
を区別する企業もあります。
例えば、
主所属：営業部
兼務：事業企画部
という状態です。
この場合、
「交通費申請は主所属の上司へ送る」
一方で、
「案件承認は対象案件の部署に応じて送る」
など業務によって承認ルートが変わる可能性があります。
そのため、
どの所属情報を使って承認者を決めるのか
まで業務ごとに整理する必要があります。
役職が同じ人が複数いる場合はどうする？
例えば営業部に、
営業課長A
営業課長B
の2人がいるケースです。
単純に、
「営業課長へ送る」
だけでは、誰を承認者にするのか決まりません。
この場合には、さらに組織階層を使います。
例えば、
営業部
├ 第一営業課
│ └ 課長A
└ 第二営業課
└ 課長B
という構造にします。
申請者が第一営業課なら課長A、第二営業課なら課長Bを取得します。
つまり承認者は、
申請者の所属組織を基準に上位組織・役職を検索する
というロジックで決定できます。
同一役職者が複数いる場合のルールも必要
それでも、同じ部署に同じ役職者が複数いる企業もあります。
例えば共同部長制です。
その場合は、次のような選択肢があります。
全員承認
部長Aと部長Bの両方が承認する方式です。
いずれか1人が承認
部長Aまたは部長Bのどちらかが承認すれば次へ進みます。
担当領域によって分岐
商品A
→ 部長A
商品B
→ 部長B
というルールです。
システム設計時には、
「複数承認者が存在した場合どうするのか」
まで確認する必要があります。
順次承認と並列承認を分ける
承認フローには大きく2種類あります。
順次承認
課長
↓
部長
↓
役員
と順番に承認します。
前の承認者が承認しなければ次へ進みません。
並列承認
例えば、
営業部長
管理部長
法務担当
へ同時に確認を依頼する方法です。
この場合にも、
- 全員承認で完了
- 1人でも承認すれば完了
- 過半数で完了
などルールが必要です。
「承認者を設定する」だけではなく、
複数承認者がいる場合の成立条件
も権限設計の一部です。
差し戻し先も決めておく
承認システムでは、
「承認する」
だけでなく、
「差し戻す」
操作があります。
例えば、
申請者
↓
課長承認
↓
部長確認
まで進んだところで部長が差し戻したとします。
この場合、
申請者へ戻す
申請者
↓
課長
↓
部長
と最初から再承認する方法。
直前の承認者へ戻す
課長
↓
部長
だけをやり直す方法。
任意のステップへ戻す
部長が戻し先を選択する方法。
などがあります。
後から決めようとすると複雑になりやすいため、要求整理の段階で確認しておくことが重要です。
異動・組織変更はどう扱う？
承認システムでは、人事異動への対応も重要です。
例えば、
7月31日まで
営業課長：山田さん
8月1日から
営業課長：佐藤さん
となるケースです。
承認者はいつの組織情報で決める？
大きく2つの考え方があります。
申請時点で承認者を確定する
7月30日に申請した場合、
承認者：山田さん
として固定します。
8月1日に組織変更があっても、山田さんがそのまま承認します。
承認時点の組織情報を使う
8月1日に承認画面を開いた時点で、
営業課長：佐藤さん
を取得して承認者を切り替えます。
どちらが正しいかは会社の運用ルールによります。
ただし、システム開発ではこの違いを明確にしておかないと、組織変更時に問題が起こります。
退職した承認者の申請はどうする？
例えば、
課長承認待ち
の申請が残っている状態で課長が退職したとします。
そのままでは誰も承認できない可能性があります。
対策として、
- 後任者へ自動移管
- 管理者が一括移管
- 代理承認者へ移管
- 新しい役職者を動的に取得
といった方法があります。
特に長期間使う業務システムでは、
「ユーザー削除」
ではなく、
「在籍・退職ステータス」
として管理する方が適しています。
過去の承認履歴から退職者まで消してしまうと、
「誰が承認したのか」
分からなくなるからです。
権限は削除ではなく有効期間で管理すると柔軟になる
将来的な組織変更が多い場合は、
所属開始日
所属終了日
役職開始日
役職終了日
代理承認開始日
代理承認終了日
のように、有効期間を持たせる設計もあります。
例えば、
営業課長
山田さん
2025/04/01〜2026/07/31
営業課長
佐藤さん
2026/08/01〜
と管理します。
これにより、
「2026年7月時点の組織」
と
「現在の組織」
を区別できます。
承認履歴を長期間保持するシステムでは特に有効です。
承認権限と閲覧権限は分けて考える
承認できる人だからといって、すべての申請を閲覧できてよいとは限りません。
例えば営業部長には、
営業部の申請
→ 閲覧・承認可能
管理部の申請
→ 閲覧不可
とする場合があります。
一方、管理部門には、
全社申請
→ 閲覧可能
だが、
承認
→ 不可
という権限を持たせることもあります。
つまり、
- 閲覧
- 申請
- 編集
- 承認
- 差し戻し
- 却下
- 取消
- 管理
などは分けて設計する必要があります。
RBACを使った権限設計
業務システムの権限管理では、RBACという考え方がよく使われます。
RBACはRole-Based Access Controlの略で、日本語では「ロールベースアクセス制御」と呼ばれます。
ユーザーごとに直接権限を大量に設定するのではなく、
ユーザー
↓
ロール
↓
権限
という形で管理します。
例えば、
一般社員
- 申請作成
- 自分の申請閲覧
課長
- 申請作成
- 自部署申請閲覧
- 課長承認
部長
- 申請作成
- 部内申請閲覧
- 部長承認
システム管理者
- ユーザー管理
- 組織管理
- ワークフロー設定
という形です。
ただし、承認フローではRBACだけでは表現できない条件もあります。
例えば、
「営業部長なら、営業部の申請だけ承認可能」
という条件です。
そのため実際には、
ロール＋所属組織＋申請条件
を組み合わせて判定する設計が必要になることがあります。
承認権限は画面の表示制御だけでは不十分
権限設計で注意したいのが、
「承認ボタンを非表示にしているから安全」
と考えてしまうことです。
例えば画面上では承認ボタンを隠していても、APIへ直接リクエストすれば承認できる実装になっていると、権限管理として不十分です。
バックエンド側でも、
- ログインユーザーは誰か
- この申請の承認者か
- 現在承認可能なステータスか
- 代理権限は有効か
- 承認可能金額の範囲内か
などを確認する必要があります。
フロントエンドでの表示制御は使いやすさのためのものであり、
本当の権限チェックはサーバー側でも実施する
という設計が基本です。
承認履歴で保存したい情報
承認システムでは、現在の状態だけでなく履歴が重要です。
例えば承認履歴には次のような情報を保存します。
- 申請ID
- 承認ステップ
- 本来の承認者
- 実際の操作ユーザー
- 承認種別
- 承認日時
- 承認結果
- コメント
- 代理承認の有無
例えば、
申請番号：REQ-00125
承認段階：部長承認
本来の承認者：山田太郎
操作ユーザー：佐藤花子
承認方法：代理承認
結果：承認
日時：2026/07/30 15:30
という履歴です。
承認後に組織情報が変更されても、当時誰がどの立場で承認したのか確認できる設計が理想です。
【具体例】購買申請の承認者権限を設計する
実際の業務を例に考えてみます。
現状のルール
社員が備品を購入する場合、
5万円未満
→ 課長承認
5万円以上50万円未満
→ 課長＋部長
50万円以上
→ 課長＋部長＋役員
とします。
さらに、
- 課長が申請者なら課長承認はスキップ
- 部長不在時は副部長が代理承認
- 50万円以上は代理承認不可
というルールがあります。
システムで必要になる情報
この業務を実装するなら、少なくとも次の情報が必要です。
ユーザー
社員を管理します。
組織
営業部、管理部などを管理します。
所属・役職
誰がどの部署で何の役職なのかを管理します。
承認ルート
金額などの条件によって必要な承認段階を管理します。
代理承認
代理元、代理者、有効期間などを管理します。
承認履歴
実際に誰が承認したのか保存します。
このように分けて考えると、単なる「承認ボタン」の実装ではなく、組織ルールをシステムで表現する必要があることが分かります。
【コピペ用】承認者権限ヒアリングシート
承認システムを設計するときは、次の項目を整理すると要件をまとめやすくなります。
基本ルール
- 対象となる申請：
- 申請者：
- 第1承認者：
- 第2承認者：
- 最終承認者：
- 承認順序：
承認条件
- 金額による分岐：
- 部署による分岐：
- 申請種類による分岐：
- その他の条件：
自己承認
- 自己承認を許可するか：
- 申請者＝承認者の場合の処理：
- 次の承認者へスキップするか：
代理承認
- 代理承認を許可するか：
- 代理者を誰が設定するか：
- 代理期間を設定するか：
- 代理できない申請はあるか：
- 金額上限はあるか：
兼務
- 複数部署への所属があるか：
- 主所属と兼務を区別するか：
- どの所属を承認ルート判定に使うか：
複数承認者
- 同じ役職者が複数いるか：
- 全員承認が必要か：
- 1人の承認でよいか：
人事異動
- 異動時の承認待ち申請をどうするか：
- 退職者の承認待ち申請をどうするか：
- 過去の所属情報を保持するか：
差し戻し
- 差し戻し可能か：
- 誰まで戻せるか：
- 再承認はどこから開始するか：
履歴
- 承認者を保存するか：
- 代理元を保存するか：
- コメントを保存するか：
- 操作日時を保存するか：
この内容を事前に整理しておくと、開発開始後の仕様変更を減らしやすくなります。
承認者権限の設計でよくある失敗
ユーザー名を直接設定しすぎる
担当者変更のたびに設定変更が必要になります。
可能な範囲で部署・役職・ロールを利用します。
代理承認を後から追加する
開発後半で代理承認を追加すると、承認者判定や履歴設計まで変更する必要が生じることがあります。
不在時の運用は要件定義段階で確認することが重要です。
兼務を想定していない
ユーザーと部署を1対1で設計した後に兼務対応を追加すると、データ構造そのものを変更する可能性があります。
組織変更を考えていない
現在の組織図だけを見て設計すると、人事異動時に運用できなくなる可能性があります。
承認後の履歴を書き換えてしまう
現在のユーザー情報だけを参照して表示すると、組織変更後に過去の承認履歴まで違って見えることがあります。
承認時点の情報を履歴として残すことが重要です。
承認者権限の設計に関するよくある質問
承認者はユーザーと役職のどちらで設定すべきですか？
基本的には役職や組織を基準にした方が変更に強くなります。
例えば「山田さん」ではなく「営業部長」と設定します。
ただし、特定の担当者しか承認できない特殊業務ではユーザー直接指定が適している場合もあります。
代理承認と承認者変更は何が違いますか？
承認者変更は、本来の承認者そのものを別の人へ変更する方法です。
代理承認は、本来の承認者を残したまま別のユーザーが代わりに操作します。
監査や履歴管理を重視する場合は、誰の代理として承認したのか残せる代理承認の方が適するケースがあります。
兼務の場合はどちらの部署の権限を使いますか？
業務ルールによります。
主所属を利用する場合もあれば、申請対象となる案件・部署に応じて所属を切り替える場合もあります。
そのため「兼務を認めるか」だけではなく「どの所属を判定に使用するか」まで決める必要があります。
管理者ならすべて承認できるようにしてもよいですか？
運用上必要な場合は可能ですが、慎重に設計する必要があります。
システム管理者がユーザー設定を変更できることと、業務上の決裁権限を持つことは別です。
管理権限と承認権限を分離する方が適切なケースもあります。
異動前に申請されたものは旧上司と新上司のどちらが承認しますか？
企業の業務ルールによって異なります。
申請時点で承認者を確定する方式と、承認時点の組織情報から決定する方式があります。
システム開発前にどちらを採用するか明確にしておく必要があります。
承認者権限は後から変更できますか？
変更できるよう設計することは可能です。
ただし、現在進行中の申請へ変更内容を適用するのか、新規申請から適用するのかという問題があります。
そのため、承認ルートの変更時には適用タイミングも設計する必要があります。
hiro-dev-labでは承認フロー・権限設計から相談できます
承認システムを開発しようとしても、
「現在はExcelとメールなので正式なルールが整理されていない」
「代理承認や兼務まで考えると仕様が分からない」
「どこまで権限を分けるべきか判断できない」
「現在の業務フローをどうシステムへ落とし込めばよいか分からない」
というケースがあります。
hiro-dev-labでは、画面やプログラムを作る前の業務整理から相談できます。
例えば、
- 現在の承認フローのヒアリング
- As-Is（現在の業務）の整理
- To-Be（システム導入後の業務）の整理
- 申請・承認ルート整理
- 承認条件の整理
- ユーザー・組織・役職設計
- 権限設計
- 代理承認・兼務ルール整理
- 要件定義
- 画面一覧作成
- Webシステム設計・開発
- 既存Excel・メール業務のシステム化
といった形で、現在の運用に合わせて必要な範囲を整理できます。
特に承認者権限は、開発後に例外ケースが判明すると修正範囲が大きくなりやすい部分です。
最初から完璧な仕様書を用意する必要はありませんが、
「今は誰がどのように判断しているのか」
をヒアリングしながら整理しておくことが重要です。
まとめ
承認者権限の設計では、単純に「誰が承認するか」だけを決めるのでは不十分です。
実際の業務では、
- 組織
- 役職
- 承認金額
- 自己承認
- 代理承認
- 兼務
- 複数承認者
- 差し戻し
- 人事異動
- 退職
- 承認履歴
といった条件を考える必要があります。
特に重要なのは、
特定の人に依存しすぎない承認ルールを設計すること
です。
「山田さんが承認する」という設定より、
「申請者が所属する部署の課長が承認する」
という形にすることで、人事異動や組織変更にも対応しやすくなります。
さらに、代理承認や兼務、有効期間、承認履歴まで設計しておけば、長期間運用しやすいワークフローシステムになります。
承認機能は一見すると単純ですが、企業の組織ルールが集中する部分でもあります。
システム開発を始める前に、正常系だけでなく、
「承認者が休んだらどうするか」
「本人が申請したらどうするか」
「兼務だったらどうするか」
「異動したらどうするか」
まで整理しておくことが、後から困らない承認者権限設計につながります。