稟議・申請承認ワークフローのシステム化：設計と導入の手順

稟議や各種申請の承認をシステム化するとき、設計の成否を分けるのは「通常の流れ」ではなく「例外の扱い」です。申請して、上長が承認して、決裁者が承認する。この基本の流れはどの製品でも簡単に作れます。難しいのは、承認者が不在のときの代理承認、内容に不備があったときの差し戻し、金額や部署によって変わる承認経路、組織変更のときの経路の付け替えといった例外です。これらを事前に洗い出して設計しておかないと、システム化した後も、例外のたびに紙やメールに戻ることになります。

結論として、まずは既製のワークフロー製品で自社の承認ルールが表現できるかを確認し、表現できるなら既製品を使うのが早く確実です。他の業務システムと一体で動かしたい、承認経路の条件が独特で設定では表現しきれない、承認後に会計や在庫など別システムへの処理を自動で走らせたい、といった場合に、個別開発を検討します。

この記事は、紙やメール、Excelで回している稟議・申請・承認をシステム化しようとしている総務・経理・情報システムの担当者や、業務システムの一部として承認機能を組み込みたい事業責任者に向けています。設計で決めるべきこと、例外処理の考え方、既製品と個別開発の比較、導入の手順を整理します。

ワークフローシステム化で解決できること

紙やメールでの承認には、次のような問題があります。

• 申請書が今どこで止まっているか分からない。承認者が出張中で何日も止まっている。
• 申請書の形式が人によって違い、必要な情報が欠けていて何度もやり取りが発生する。
• 承認の経路が人の記憶に頼っていて、本来必要な承認者を飛ばしてしまう。
• 過去の申請を探すのに時間がかかり、監査の際に承認の証跡を示すのに苦労する。
• 承認後に、経理や総務がその内容を別のシステムに手で入力し直している。

ワークフローシステムを導入すると、申請の形式が統一され、承認経路が自動で決まり、進み具合が見えるようになり、承認の記録が残ります。さらに、承認後の処理を他システムと連携させれば、転記の手間もなくせます。紙の書類をなくす取り組み全体の進め方はペーパーレス化の進め方でも解説しています。

ただし、ワークフローシステムは、現在の承認ルールを電子化する道具です。ルール自体が曖昧なまま導入すると、曖昧さがそのままシステムに持ち込まれます。システム化は、承認ルールを見直す機会でもあります。

設計の前に整理すべき承認ルール

システムの設定や開発に入る前に、次の項目を整理します。

申請の種類と項目

稟議、購買申請、経費精算、休暇申請、契約書の確認依頼など、対象とする申請の種類を一覧にし、それぞれの入力項目を決めます。項目ごとに、必須かどうか、入力形式（金額、日付、選択肢、添付ファイル）、入力の補助（マスタからの選択、自動計算）を決めます。

承認経路と分岐条件

申請ごとに、誰がどの順番で承認するかを決めます。多くの場合、承認経路は条件によって変わります。

• 金額による分岐：一定の金額までは部長決裁、それを超えると役員決裁、さらに超えると取締役会、といった段階
• 部署による分岐：申請者の所属部署によって承認者が変わる
• 内容による分岐：IT機器の購入なら情報システム部門、契約なら法務部門の確認を挟む
• 合議：複数の部門が並行して確認し、全員が承認したら次に進む

社内規程の職務権限表や決裁権限規程がある場合は、それを出発点にします。規程と実際の運用がずれていることも多いため、現場の実態も確認しましょう。現状の流れを図にする方法は業務フロー図の書き方を参考にしてください。

権限と閲覧範囲

申請の内容を誰が見られるかを決めます。人事関連の申請や、機密性の高い稟議は、関係者以外に見えないようにする必要があります。経理や監査担当が、承認済みの申請をすべて閲覧できるようにするかどうかも決めておきます。

例外処理の設計：代理承認・差し戻し・引き戻し

ワークフローの設計で最も時間をかけるべきなのが、例外処理です。代表的な例外と、決めておくべきことを整理します。

代理承認の設計

代理承認には、大きく二つの方式があります。承認者が自分で代理人と期間を設定する方式と、あらかじめ決めた代理人（たとえば同じ部署の次席）が常に代理できる方式です。前者は柔軟ですが設定忘れが起き、後者は確実ですが権限が広がりすぎることがあります。どちらの場合も、代理で承認されたことが記録に残り、本来の承認者が後から確認できるようにしておくことが重要です。

差し戻しの設計

差し戻しでは、「どこまで戻すか」と「修正後にどこから再開するか」を決めます。申請者まで戻して最初から承認をやり直すのが最も厳格ですが、軽微な修正のたびに全員の承認をやり直すのは負担です。修正した内容によって、再承認の範囲を変える設計もあり得ます。いずれにしても、差し戻しの理由をコメントとして残し、申請者に分かるように通知します。

組織変更への備え

組織変更や人事異動のたびに承認経路の設定を一つずつ直すのは、大きな負担になり、設定漏れの原因にもなります。承認者を個人の名前ではなく「申請者の所属部署の部長」のような役職や役割で指定しておくと、組織のデータを更新するだけで経路が自動的に変わります。誰がどの操作をできるかを役割で管理する考え方は、管理画面の権限設計でも解説しています。

申請画面・承認画面・通知の設計のポイント

承認ルールと例外処理が決まったら、利用者が実際に触る画面と通知を設計します。ここでの工夫が、システムが使われるかどうかを左右します。

申請画面：差し戻しを減らす入力の工夫

差し戻しの多くは、必要な情報の不足や入力の誤りが原因です。申請画面では、取引先や品目をマスタから選ばせる、金額の合計を自動計算する、添付が必要な条件のときは添付を必須にする、といった入力の補助で、不備を申請の段階で防ぎます。また、過去の申請を複製して作成できるようにすると、定期的な申請の手間が大きく減ります。申請書の下書き保存も、項目の多い稟議では欠かせません。

承認画面：判断に必要な情報を一画面に

承認者は、多くの申請を短い時間で判断します。承認画面には、申請内容の要点、金額、添付ファイル、これまでの承認者のコメント、関連する過去の申請を一画面にまとめ、別の画面を開かなくても判断できるようにします。承認待ちの一覧では、申請日からの経過日数や金額で並べ替えられると、優先順位をつけやすくなります。

通知と滞留対策

通知は、承認依頼、差し戻し、最終結果といった「次に誰かが行動すべき」場面に絞ります。そのうえで、一定日数以上止まっている申請を承認者にまとめて知らせる、さらに日数が経てば申請者や管理者にも知らせる、という段階的な催促を設計すると、滞留を減らせます。通知の手段は、メールだけでなく、社内で日常的に使っているチャットツールに送るほうが気づかれやすい場合もあります。

既製品と個別開発の比較

ワークフローの仕組みを用意する方法は、主に3つあります。

既製品が向いているケース

稟議、購買、経費、休暇など一般的な申請が中心で、承認経路が金額や部署による分岐程度で表現できる場合は、ワークフロー専用製品が最も早く確実です。電子帳簿の保存や監査の観点で必要な機能も、製品側で用意されていることが多くあります。ただし、法令への対応状況は製品や時期によって異なるため、要件は専門家や公的機関の最新情報で確認してください。

個別開発が向いているケース

• 承認が、受注・発注・契約・在庫など、特定の業務システムの一部として行われる。たとえば、見積もりの値引き率が一定を超えたら上長承認が必要、といった場合
• 承認経路の条件が、取引先の属性、商品の種類、過去の取引実績など、業務データに依存する
• 承認後に、他のシステムへの登録や発注処理などを自動で実行したい
• 社外の取引先やパートナーが承認の流れに加わる

このような場合、汎用のワークフロー製品と業務システムを連携させるより、業務システムの中に承認機能を組み込むほうが、利用者にとっても管理者にとっても分かりやすくなることがあります。

比較するときの確認方法

既製品が自社に合うかどうかは、資料を読むだけでは分かりません。試用期間を使い、自社で最も複雑な申請を一つ選んで、実際に承認経路と例外処理を設定してみるのが確実です。金額による分岐、合議、代理承認、差し戻し後の再開、組織変更時の経路の付け替えを順に試し、設定で表現できない部分を書き出します。その書き出した部分が少なく運用で補えるなら既製品、業務の中核に関わるなら個別開発や併用を検討する、という判断ができます。

ワークフローシステムの導入手順

導入は、次の手順で進めます。

1. 対象の申請を選ぶ：すべての申請を一度にシステム化するのではなく、件数が多い、または滞留が問題になっている申請から始めます。
2. 現状の流れと規程を確認する：申請書の様式、承認経路、規程と実態のずれ、例外がどのくらいの頻度で起きているかを確認します。
3. 承認ルールを見直す：本当に必要な承認者か、形式的な承認が残っていないかを見直します。承認の段数を減らすだけで、処理の速さは大きく変わります。
4. 例外処理を設計する：前述の表をもとに、代理、差し戻し、引き戻し、組織変更への対応を決めます。
5. 方式を選び、設定または開発する：既製品で表現できるかを試用で確認し、難しければ個別開発を検討します。
6. 試行運用する：一部の部署で試行し、申請書の項目の過不足、通知のタイミング、例外処理の使い勝手を確認します。
7. 全社展開と紙の廃止：展開の日を決め、その日以降は紙やメールでの申請を受け付けないことを明確にします。並行期間が長引くと、紙とシステムの両方を確認する手間が残ります。
8. 定着後の見直し：滞留の多い承認者、差し戻しの多い申請書を確認し、項目や経路を改善します。

具体的な場面で考える：購買申請の例

架空の例として、複数の拠点を持つサービス業の会社で、購買申請をシステム化する場面を考えます。現在は紙の申請書に押印して回しており、拠点から本社への郵送で数日かかっていました。

現状を確認すると、規程では一定の金額以上は本社の役員決裁ですが、実際には拠点長の判断で事後に申請しているケースが多くありました。また、IT機器の購入には情報システム担当の確認が必要というルールがあるものの、紙の回覧では飛ばされることがありました。

システム化にあたって、次のように設計しました。承認経路は「申請者の拠点の拠点長」「金額に応じて本社の部長または役員」と役職で指定し、品目の区分がIT機器の場合は情報システム担当の確認を自動で挟む。緊急時の事後申請は認めるが、事後であることを明示する項目を設け、件数を毎月確認する。承認者が不在の場合は、あらかじめ設定した代理人が承認でき、代理であることが記録に残る。

さらに、承認された申請は発注データとして購買担当の一覧に自動で表示されるようにし、紙の申請書から発注書を作り直す手間をなくしました。このように、ワークフローの設計は承認の電子化にとどまらず、前後の業務とのつながりまで考えると効果が大きくなります。

よくある失敗と避け方

紙の運用をそのまま電子化する

紙の時代の承認経路や押印欄をそのまま再現すると、形式的な承認が残り、電子化しても処理は速くなりません。システム化の前に、各承認者が何を確認しているのかを問い直し、確認内容のない承認は減らしましょう。

例外を後回しにする

通常の流れだけを作って運用を始めると、代理や差し戻しが発生するたびに、システムの外でメールや口頭でのやり取りが発生します。例外の扱いが決まっていないと、現場はシステムを使わなくなります。試行運用の前に、少なくとも代理承認と差し戻しは決めておきます。

承認者を個人名で設定する

承認経路を個人の名前で設定すると、人事異動のたびに大量の設定変更が必要になり、漏れが起きます。役職や役割で指定し、組織データの更新で経路が変わるようにしましょう。

通知が多すぎて無視される

すべての操作で通知を送ると、承認者は通知を読まなくなります。承認依頼、差し戻し、最終結果など、行動が必要な通知に絞り、滞留している申請だけを定期的にまとめて知らせるなどの工夫が必要です。

承認記録を検索できない

承認の記録は、監査やトラブルのときに必要になります。誰がいつ承認・差し戻ししたか、代理だったかが監査ログとして残り、申請の種類や期間、金額で検索できるようにしておきましょう。

導入前のチェックリスト

• 対象とする申請の種類と、最初に取り組む申請を決めたか
• 申請ごとの入力項目と必須項目を決めたか
• 承認経路の分岐条件（金額・部署・内容）を整理したか
• 規程と実際の運用のずれを確認したか
• 形式的な承認を減らす見直しをしたか
• 代理承認の方式と記録方法を決めたか
• 差し戻し・引き戻し・却下の扱いを決めたか
• 承認者を役職や役割で指定できるか確認したか
• 申請の閲覧範囲を決めたか
• 承認後に連携したい業務やシステムを洗い出したか
• 紙やメールでの申請を廃止する日を決めたか

よくある質問

Q. 承認の段数はどのくらいが適切ですか？

一律の正解はありませんが、各承認者が何を確認しているかを説明できない段は、減らす候補です。金額や内容によって段数を変え、少額で定型的な申請は少ない段数で済むようにすると、全体の処理が速くなります。承認者の確認内容を申請書の項目として明確にすると、承認の質も上がります。

Q. 電子承認に法的な効力はありますか？

社内の承認手続きは、多くの場合、社内規程に基づいて行われるため、規程を電子承認に合わせて整備することが重要です。取引先との契約や、帳簿書類の保存に関わる場合は、別途法令上の要件があります。具体的な要件は、最新の情報を専門家や公的機関で確認してください。

Q. 既製品を導入した後で、個別開発に切り替えることはできますか？

できます。既製品で運用して承認ルールと例外処理が固まっていれば、個別開発の要件は明確になります。切り替える際は、過去の申請と承認記録をどう保管するか、既製品からデータを書き出せるかを事前に確認しておきましょう。

Q. スマートフォンで承認できるようにすべきですか？

承認者が外出や出張の多い職種であれば、スマートフォンでの承認は滞留の解消に大きく役立ちます。その場合、添付ファイルの確認のしやすさや、ログインの安全性も合わせて検討します。

Otsumuに相談できること

一般的な稟議や経費、休暇の申請が中心で、承認経路が金額や部署による分岐で表現できるなら、既製のワークフロー製品を導入するのが最善です。製品の試用期間を使い、この記事のチェックリストに沿って自社のルールが表現できるかを確認すれば、外部に依頼しなくても導入は進められます。

一方で、承認が受注や発注、契約といった業務システムの一部として行われる場合や、承認経路の条件が業務データに依存する場合、承認後に他システムへの処理を自動で実行したい場合は、既製品の設定だけでは難しくなります。どこまでを既製品で賄い、どこを個別に作るかの判断には、業務全体の流れを見る必要があります。

Otsumuでは、社内ツール開発として、承認ルールと例外処理の整理から、既製品と個別開発の比較、業務システムへの承認機能の組み込み、他システムとの連携までを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間で進めるため、まず一つの申請から始めて段階的に広げる進め方にも対応できます。既製品で十分と判断した場合は、そのようにお伝えします。

承認ルールの整理から相談したいという段階でもかまいません。30分の無料相談で、現在の申請と承認の流れをお聞きし、進め方の選択肢を一緒に整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01