承認フローをシステム化する方法｜申請・承認・差し戻しの設計ポイント

社内の申請・承認業務について、

「申請書をExcelで作ってメールで送っている」

「紙の申請書を上司へ回覧している」

「誰の承認待ちなのか分からない」

「差し戻された後、どの書類が最新版なのか分からなくなる」

といった問題はないでしょうか。

申請件数が少なく、承認者も一人だけであれば、紙やメールでも運用できます。

しかし、申請件数や関係者が増えると、

承認待ちの見落とし
対応漏れ
最新版が分からない
承認者不在による停滞
過去の承認履歴を探せない
Excelや台帳への二重入力

などの問題が起こりやすくなります。

こうした場合に検討したいのが、承認フローのシステム化です。

例えば、

申請
↓
課長承認
↓
部長承認
↓
経理確認
↓
完了

という流れをシステム上で管理すれば、

「現在誰の承認待ちなのか」

「いつ申請されたのか」

「誰が承認したのか」

を確認できるようになります。

ただし、現在の紙やExcelの申請書をそのままWeb画面へ置き換えればよいわけではありません。

承認フローをシステム化するときは、

現在の業務整理 → 承認ルール整理 → ステータス設計 → 権限設計 → 通知・履歴設計

という順番で考えることが重要です。

この記事では、承認フローをシステム化する方法と、申請・承認・差し戻しを設計するときのポイントを具体例付きで解説します。

承認フローとは

承認フローとは、申請された内容を誰がどの順番で確認し、最終的に承認・却下するのかを定めた業務の流れです。

例えば経費申請なら、

社員が申請
↓
直属の上司が承認
↓
経理担当者が確認
↓
処理完了

という流れがあります。

稟議申請なら、

担当者
↓
課長
↓
部長
↓
役員

という複数段階の承認になる場合もあります。

承認フローでは、単純な「承認」だけでなく、

申請
承認
差し戻し
再申請
却下
取り下げ
完了

など、複数の状態を扱います。

システム化する場合は、これらをどのようなルールで遷移させるのかを整理する必要があります。

承認フローをシステム化するメリット

承認フローをシステム化すると、単に紙をなくせるだけではありません。

現在の承認状況を確認できる

紙やメールでは、

今、誰が持っているのか？

が分からなくなることがあります。

システム上で、

申請中
課長承認待ち
部長承認待ち
差し戻し
承認済み

といったステータスを管理すれば、進捗を一覧で確認できます。

承認漏れを防ぎやすくなる

承認依頼をメールだけで送ると、他のメールに埋もれる可能性があります。

システム上で未承認一覧を表示したり、通知を送ったりすることで対応漏れを防ぎやすくなります。

承認履歴を残せる

システムでは、

誰が
いつ
承認したか
どの内容を承認したか
どのようなコメントを残したか

を履歴として保存できます。

後から、

この申請は誰が承認したのか？

を確認しやすくなります。

差し戻し後の最新版を管理しやすい

Excelファイルをメール添付して承認する場合、

申請書.xlsx
申請書修正版.xlsx 申請書修正版2.xlsx
申請書_最終版.xlsx

のようにファイルが増えることがあります。

システム上で申請データを管理すれば、現在の情報と変更履歴を分けて管理できます。

リモートでも承認できる

紙・押印中心の業務では、承認者が出社しないと処理できない場合があります。

Webシステムであれば、利用環境やセキュリティ要件を満たす範囲で、オフィス以外から承認できる仕組みにすることも可能です。

集計・検索しやすくなる

申請をデータとして保存すれば、

部署別申請件数
月別申請件数
承認待ち件数
差し戻し件数
申請金額

などを検索・集計できます。

承認フローのシステム化を検討したいケース

特に次のような状態なら、システム化を検討する価値があります。

紙の申請書を回覧している
Excelをメール添付して承認している
承認者が複数いる
承認待ちの案件が多い
誰の確認待ちか分からない
差し戻しが頻繁に発生する
過去の承認履歴を探すことが多い
承認後に別システムへ転記している
複数拠点から申請する
承認金額によって承認者が変わる

一方、

月に数件しかなく、申請者・承認者が固定されている場合は、既存ツールや簡単な運用改善だけで十分なこともあります。

システム化そのものを目的にせず、業務量・問題・費用対効果から判断します。

承認フローをシステム化する前に整理する7項目

いきなり画面設計を始めるのではなく、まず現在の承認業務を整理します。

1．何を申請するのか

最初に申請の種類を整理します。

例えば、

経費申請
購買申請
稟議
休暇申請
契約申請
アカウント発行申請
設備購入申請
値引き承認
発注申請

などです。

申請種類によって必要な入力項目・承認者・承認ルールは変わります。

2．誰が申請するのか

申請者についても整理します。

例えば、

全社員
営業担当者のみ
管理職のみ
特定部署のみ
社外ユーザーも含む

などです。

利用者によって、画面や権限設計も変わります。

3．誰が承認するのか

承認者を整理します。

例えば、

申請者
↓
課長
↓
部長

という固定ルートなのか、

申請者
↓
所属部署の上司

のように、申請者によって変わるのかを確認します。

4．どの順番で承認するのか

承認者が複数いる場合は、順序も重要です。

例えば、

課長承認
↓
部長承認
↓
経理確認

なのか、

課長と部長の両方が確認すればよい

のかによって仕組みが変わります。

一般的には、

直列承認
並列承認
条件分岐

などがあります。

5．どの条件で承認ルートが変わるのか

承認フローでは、条件によって承認者が変わるケースがあります。

例えば、

10万円未満
→ 課長承認

10万円以上100万円未満
→ 課長 → 部長

100万円以上
→ 課長 → 部長 → 役員

というルールです。

ほかにも、

部署
申請種類
金額
契約種別
リスク区分

などで分岐することがあります。

6．差し戻し時にどうするのか

承認フロー設計で忘れやすいのが差し戻しです。

例えば部長が差し戻した場合、

部長
↓
申請者へ戻す

のか、

部長
↓
課長へ戻す

のかを決めます。

さらに再申請時、

申請者
↓
課長
↓
部長

と最初から承認し直すのか、

申請者
↓
部長

と差し戻した地点へ直接戻すのかも決める必要があります。

7．承認後に何をするのか

承認フローは「承認されたら終わり」とは限りません。

例えば購買申請なら、

申請
↓
承認
↓
発注
↓
納品
↓
支払

と業務が続きます。

そのため、

承認後に誰が何をするのか

まで確認します。

承認済みデータを別システムへ再入力しているなら、データ連携も検討できます。

承認フローをシステム化する7ステップ

STEP1｜現在の承認業務を可視化する

まずAs-Is、つまり現在の業務を整理します。

例えば、

社員がExcelで申請書作成
↓
課長へメール送信
↓
課長が確認
↓
部長へ転送
↓
部長が承認
↓
経理へメール
↓
経理がExcel台帳へ入力

という流れです。

この時点では、理想的な業務ではなく、現在実際に行っている業務を書きます。

STEP2｜現在の課題を整理する

例えば、

承認者がメールを見落とす
誰の承認待ちか分からない
Excelファイルが増える
差し戻し後の最新版が分からない
経理が申請内容を再入力している

などです。

課題を明確にすることで、システムに必要な機能を判断しやすくなります。

STEP3｜不要な承認を見直す

システム化する前に、

この承認は本当に必要か？

を確認します。

例えば、

担当者
↓
係長
↓
課長
↓
部長
↓
役員

という承認フローがあっても、すべての申請で5段階必要とは限りません。

承認フローが長いほど処理時間も増えます。

システム化は、現在の承認手続きをそのまま電子化するのではなく、業務自体を整理する機会でもあります。

STEP4｜To-Be承認フローを作る

改善後の業務を設計します。

例えば、

社員がWebフォームで申請
↓
課長へ通知
↓
課長承認
↓
部長へ通知
↓
部長承認
↓
経理へ自動通知
↓
処理完了

という形です。

STEP5｜ステータスを設計する

承認フローでは、状態管理が重要です。

例えば、

下書き
申請中
課長承認待ち
部長承認待ち
差し戻し
承認済み
却下
取り下げ
完了

などがあります。

ただし、細かくしすぎると運用が複雑になります。

業務上必要な状態だけに絞ります。

STEP6｜権限を設計する

利用者ごとに何ができるのかを整理します。

例えば、

申請者

自分の申請を作成
自分の申請を閲覧
差し戻された申請を修正

承認者

承認待ち申請を閲覧
承認
差し戻し
コメント

管理者

全申請を閲覧
承認ルート設定
マスタ管理

などです。

STEP7｜通知・履歴・連携を設計する

最後に、

誰へ通知するか
いつ通知するか
何を履歴として残すか
他システムへ連携するか

を整理します。

ここまで決めると、必要な機能を具体化できます。

申請・承認・差し戻しの基本設計

承認システムでは、この3つの処理が特に重要です。

申請

申請者が必要事項を入力して承認フローを開始します。

例えば、

申請種類
件名
金額
理由
添付ファイル
希望日

などを入力します。

設計時には、

必須入力
入力形式
下書き保存
添付ファイル
入力チェック

なども検討します。

承認

承認者が内容を確認し、次の工程へ進めます。

承認時には、

コメントを入力できるか
承認後に取り消せるか
承認日時を保存するか

などを考えます。

特に監査・履歴確認が必要な業務では、

誰がいつ何を承認したか

を変更履歴として残すことが重要です。

差し戻し

申請内容に修正が必要な場合、申請者などへ戻します。

差し戻し時には、

差し戻し理由を必須にするか
誰へ戻すか
再申請後どこから承認を再開するか

を決めます。

例えば、

申請者
↓
課長承認
↓
部長が差し戻し
↓
申請者が修正
↓
課長から再承認

という方法があります。

あるいは、

申請者が修正
↓
部長へ直接戻す

方法もあります。

業務ルールに合わせて決めます。

却下と差し戻しは分ける

システム設計では、

差し戻しと却下

を分けておくと分かりやすくなります。

差し戻し

内容を修正すれば再申請できる状態。

却下

申請自体を承認しない状態。

例えば、

「金額の記載が間違っている」

なら差し戻し、

「この購入自体を認めない」

なら却下、

といった使い分けです。

業務によっては却下が不要なケースもあります。

直列承認と並列承認の違い

複数の承認者がいる場合、承認方式も整理します。

直列承認

一人ずつ順番に承認します。

課長
↓
部長
↓
役員

という方式です。

前の承認者が承認しなければ、次の承認者には回りません。

並列承認

複数人へ同時に承認依頼します。

例えば、

法務
＋
経理

の両方が確認するケースです。

さらに、

全員の承認が必要
誰か一人が承認すればよい

というルールもあります。

必要以上に複雑な承認方式を作ると保守・運用が難しくなるため、実際の業務に必要なものだけ設計します。

金額によって承認者を変える具体例

購買申請を例にします。

10万円未満

申請者
↓
課長
↓
完了

10万円以上100万円未満

申請者
↓
課長
↓
部長
↓
完了

100万円以上

申請者
↓
課長
↓
部長
↓
役員
↓
完了

この場合、システムでは申請金額を判定して承認ルートを自動設定します。

これにより申請者が、

誰に回せばよいのか

を毎回判断する必要がなくなります。

承認者が不在の場合をどうするか

実務では承認者が、

休暇
出張
退職
異動

しているケースがあります。

そのため、承認システムでは不在時の運用も考えます。

例えば、

代理承認者を設定する
上位承認者へ回す
管理者が担当変更する

などです。

特に承認者を個人IDで固定している場合、異動時のメンテナンスが必要になります。

可能であれば、

「営業1課の課長」

のように役職・組織から承認者を決定する仕組みも検討します。

承認システムに必要な主な機能

業務によって異なりますが、一般的には次のような機能があります。

申請一覧

自分が申請したものを確認します。

承認待ち一覧

自分が承認しなければならない申請を一覧表示します。

申請登録

申請内容を入力します。

下書き

申請前の内容を一時保存します。

承認

申請を次の工程へ進めます。

差し戻し

内容修正のため申請者などへ戻します。

却下

申請を終了します。

承認・差し戻し時に理由などを記録します。

添付ファイル

見積書・資料などを添付します。

ステータス管理

現在の処理状況を管理します。

承認履歴

誰がいつ承認したか保存します。

通知

メールやチャットなどで承認依頼を通知します。

検索

過去の申請を条件検索します。

権限管理

利用者・承認者・管理者などの操作範囲を分けます。

【コピペ用】承認フロー整理シート

システム化を検討する場合は、以下の項目を整理すると進めやすくなります。

基本情報

申請名：

利用部署：

月間申請件数：

申請者：

申請内容

申請項目：

必須項目：

添付ファイル：

金額：

備考：

承認者

第1承認者：

第2承認者：

第3承認者：

最終承認者：

承認条件

金額による分岐：

部署による分岐：

申請種類による分岐：

その他：

差し戻し

差し戻し先：

差し戻し理由を必須にする：

再申請時の開始地点：

却下

却下を利用する：

却下後の再申請：

通知

申請時：

承認時：

差し戻し時：

承認完了時：

期限超過時：

履歴

残したい履歴：

承認日時：

承認者：

コメント：

変更内容：

権限

申請者：

承認者：

管理者：

閲覧のみ：

外部連携

連携したいシステム：

CSV：

API：

メール：

チャット：

現在の課題

承認漏れ：

承認待ち：

承認後の業務までシステム化する

承認フローを作るときは、承認完了後の業務も確認します。

例えば設備購入なら、

購入申請
↓
承認
↓
発注
↓
納品
↓
設備台帳へ登録

と続きます。

承認後に担当者が申請内容を別システムへ再入力しているなら、

承認済みデータ
↓
設備管理システムへ連携

とできないか検討します。

承認部分だけをシステム化し、その後に二重入力が残るケースは少なくありません。

前後の業務フローまで確認することが重要です。

紙・Excel・メールから承認システムへ移行する具体例

システム化前

担当者がExcel申請書を作成
↓
メールで課長へ送信
↓
課長が確認
↓
部長へ転送
↓
部長が承認
↓
申請者へ返信
↓
経理がExcel台帳へ転記

問題

メールに埋もれる
最新ファイルが分からない
現在の承認者が分からない
差し戻し時にファイルが増える
経理が二重入力する

システム化後

申請フォーム入力
↓
課長へ通知
↓
課長承認
↓
部長へ通知
↓
部長承認
↓
経理へ通知
↓
承認済みデータを保存

必要に応じて、経理システムへデータ連携します。

ワークフローSaaSと独自システムはどう使い分ける？

承認フローをシステム化するとき、必ず独自システムを開発する必要はありません。

既存ワークフローSaaSが向いているケース

一般的な経費申請
稟議
休暇申請
購買申請
標準的な承認フロー
他の業務と複雑な連携がない

既存サービスで要件を満たせる場合は、導入が早く保守負担も小さくなりやすいでしょう。

独自Webシステムが向いているケース

自社固有の承認条件が多い
承認後の業務まで一元化したい
顧客・案件・在庫など他機能と連携したい
独自の画面・入力項目が必要
既存SaaSでは業務に合わない
他システムとのAPI連携が重要

例えば、

案件登録
↓
見積承認
↓
受注
↓
発注
↓
請求

まで一つの業務システムで管理する場合などです。

承認フローを複雑にしすぎない

システム化すると、

「この条件も追加したい」

「この場合だけ別の承認者にしたい」

とルールが増えやすくなります。

例えば、

金額
＋
部署
＋
役職
＋
商品種別
＋
取引先種別

など、条件を増やしすぎると管理が難しくなります。

承認フローを設計するときは、

本当にこの承認が必要か？

この条件は統一できないか？

も確認します。

システム化は、複雑な業務をそのまま再現するためではなく、業務を整理・標準化する機会でもあります。

承認フローのシステム化でよくある失敗

失敗1｜現在の紙申請をそのまま画面にする

紙にあるすべての項目をWeb画面へ移すだけでは、不要な入力も残ります。

本当に必要な項目を整理します。

失敗2｜現在の承認者をそのまま固定する

人の名前を直接ルートへ設定すると、異動・退職時の変更が増えます。

組織や役職から決められないか検討します。

失敗3｜差し戻しを考えていない

正常に承認されるケースだけでなく、

修正
差し戻し
再申請
却下
取り下げ

も設計します。

失敗4｜通知だけで対応漏れを防ごうとする

メール通知だけでは再び埋もれる可能性があります。

システム内に、

自分の承認待ち一覧

を用意する方法が有効です。

失敗5｜ステータスを増やしすぎる

細かなステータスは管理負担になります。

必要最低限から始めます。

失敗6｜承認後の業務を考えない

承認後に別のExcel・システムへ再入力していては、二重入力が残ります。

後工程まで確認します。

失敗7｜監査・履歴を後から追加する

承認業務では、

誰が
いつ
何を

操作したかが重要になる場合があります。

必要な履歴を要件定義時点で確認します。

承認フローのシステム化に関するよくある質問

承認フローは何段階まで作れますか？

システム次第ですが、複数段階の承認を設計できます。

ただし技術的に作れるかではなく、業務上その承認段階が本当に必要かを先に確認することが重要です。

金額によって承認者を変更できますか？

可能です。

申請金額などの条件から承認ルートを分岐する設計があります。

部署・申請種類などを条件にすることもできます。

承認者が休みの場合はどうしますか？

代理承認、上位者への切り替え、管理者による承認者変更などを設計できます。

実際の会社の運用ルールに合わせます。

差し戻された場合、最初から承認し直す必要がありますか？

業務ルールによります。

最初の承認者からやり直す方法と、差し戻した承認者へ直接戻す方法があります。

システム開発前に決めておく必要があります。

紙の印鑑は必ずなくせますか？

対象業務や社内規程、契約・法令上の要件によって異なります。

単に技術的に電子承認へ変更できるかだけでなく、対象書類に必要な要件を確認します。

Googleフォームだけでも承認フローを作れますか？

単純な申請受付なら利用できます。

ただし、複数段階の承認、差し戻し、細かな権限、履歴、複雑な条件分岐などが必要になると、ワークフローサービスや業務システムの方が管理しやすくなる場合があります。

hiro-dev-labでは承認フローの業務整理から相談できます

hiro-dev-labでは、Webシステム開発だけでなく、現在の申請・承認業務を整理する段階から相談できます。

例えば、

現在の申請書・Excelの確認
業務棚卸し
As-Is承認フローの可視化
不要な承認工程の整理
To-Be承認フローの設計
申請項目整理
承認条件・分岐整理
差し戻し・再申請ルール整理
ステータス設計
権限設計
通知・履歴設計
要求整理
業務要件・機能要件整理
Webシステム設計・開発
他システムとのデータ連携

などです。

例えば、

Excel申請書をメールで承認している

誰の承認待ちか分からない

金額によって承認者を変えたい

差し戻し後のファイル管理が複雑

承認後に別システムへ入力している

といった場合でも、

現在の承認業務 → 課題 → 承認ルール → 改善後の業務 → 必要なシステム機能

の順番で整理できます。

まとめ｜承認フローは「電子化」だけでなく業務ルールから見直す

承認フローをシステム化する場合、現在使っている紙やExcelをそのままWeb化するだけでは十分ではありません。

まず、

何を申請するのか
誰が申請するのか
誰が承認するのか
どの順番で承認するのか
どの条件でルートが変わるのか
差し戻し・再申請をどう扱うのか
承認後に何をするのか

を整理します。

その上で、

申請 → 承認 → 差し戻し → 再申請 → 完了

という状態をシステム上で管理します。

さらに、

承認待ち一覧
担当者
ステータス
通知
承認履歴
権限
条件分岐
データ連携

などを必要に応じて設計します。

特に重要なのは、

現在の複雑な承認フローをそのままシステムへ持ち込まないこと

です。

「昔から課長と部長の両方に回している」

「念のためこの部署にも確認している」

といった工程が、本当に現在も必要なのか確認します。

承認フローのシステム化は、紙を電子化するだけでなく、申請・承認業務そのものを整理する機会です。

「紙やExcelの承認をなくしたい」

「誰の承認待ちか分かるようにしたい」

「差し戻しや再申請を管理したい」

「金額や部署によって承認ルートを変えたい」

という場合は、まず現在の承認フローを書き出すところから始めてみてください。