申請内容に応じて承認ルートを切り替える

承認フローが「規程」と「運用」でずれやすい理由

決裁権限は、申請の内容によって異なるのが一般的

多くの企業では、職務権限規程や決裁権限基準表などによって、「一定金額以上の支出は部長決裁とする」「新規の契約締結には法務部門の確認を必要とする」といった形で、申請内容に応じた決裁者を定めています。

また、上場企業を対象とする財務報告に係る内部統制報告制度（いわゆるJ-SOX）の基準でも、統制活動には「権限及び職責の付与、職務の分掌等の広範な方針及び手続」が含まれるとされています。承認経路を規程どおりに運用できているかどうかは、業務効率だけでなく、ガバナンスの観点からも確認しておきたいテーマといえます。

一律の承認フローや、人の判断による回付が生む課題

申請・承認をシステム化する際、承認フローを1本だけ用意し、条件によって異なる部分は申請者や事務局が判断して回付する、という運用がとられることがあります。導入時の設定がシンプルになる一方で、運用を続けるうちに次のような課題が生じる可能性があります。

• 少額・定型的な申請も上位の決裁者を経由するため、承認待ちが滞留しやすい
• 申請者が経路を選ぶ運用では、選択の誤りや規程からの逸脱が起こりうる
• どの経路で回すかの判断が担当者の経験に依存し、属人化しやすい
• 監査や振り返りの際に、「なぜこの経路で承認されたのか」を説明しにくい

規程の見直しにシステムの設定が追いつかない

組織改編や決裁権限の見直しは、多くの企業で定期的に発生します。承認経路の判定がプログラムや複雑な設定に組み込まれている場合、規程を改定するたびに改修の手配や動作確認が必要になり、システムへの反映までに時間がかかることがあります。反映までの期間を運用でカバーすると、前述の課題が改めて生じやすくなります。

条件別の承認ルートを設計する際の3つの考え方

承認ルートを条件によって切り替える仕組みを検討する際は、利用するツールにかかわらず、次の3点をあらかじめ整理しておくと、運用開始後の見直しがしやすくなります。

「承認ステップ」と「経路」を分けて定義する

「課長承認」「部長承認」「経理確認」といった承認ステップを部品として定義し、経路はその部品の並べ方として表現する考え方です。経路ごとに承認者を個別に設定する方法と比べて、承認者の交代や担当変更があった場合の修正箇所が1か所で済み、設定の重複や修正漏れを抑えやすくなります。

評価の順序と「どの条件にも当てはまらない場合」を決めておく

条件が複数あると、1件の申請が複数の条件に当てはまることがあります。たとえば「金額が100万円以上」と「予算を超過している」の両方に該当する申請です。どの条件を優先するかを曖昧にしたままだと、判定結果が担当者によって変わる原因になります。

上から順に評価して最初に一致したルートを採用する、といった評価順のルールを定め、より限定的な条件を上位に置くのが一般的な設計です。あわせて、どの条件にも当てはまらない申請をどの経路で処理するか（既定のルート）を決めておくことで、判定の抜け漏れを防ぎやすくなります。

「承認不要」とする範囲を明文化する

誤字の修正や軽微な区分変更など、承認を省略しても統制上の影響が小さい申請もあります。承認を省略できる条件を規程と合わせて明文化し、システム上でも処理の記録が残る形にしておけば、統制と業務スピードの両立を図りやすくなります。

RapidTableの「承認ルート設定」でできること

ここからは、上記の考え方をRapidTableでどのように実現できるかをご紹介します。

RapidTableは、エクセルやスプレッドシートを扱う感覚でデータベースを設計できる、SaaS型のノーコード・ローコードデータベースです。登録したデータ（レポート）1件ごとに、編集中・承認待ち・承認済み・差し戻し・保留・却下といった承認ステータスを持たせる承認機能を備えており、多段承認、承認期限の設定、メールによる依頼・結果通知、承認者が記入する入力フォームなどに対応しています。承認ルート設定は、この承認機能に「申請内容に応じて承認順を切り替える」仕組みを加えるもので、プロジェクト設定画面の承認設定から設定します。

参考：RapidTableのレポート承認機能で、もっと業務フローをスマートに！

承認設定を部品として、ルートごとに承認順を組み立てる

RapidTableでは、承認ステップにあたる「承認設定」を1プロジェクトあたり最大10個まで定義できます。承認設定ごとに、プロジェクト全体で共通の承認者（ユーザーやユーザーグループ）を指定する「全体承認者」と、レポートごとにユーザー型のフィールドで承認者を指定する「個別承認者」を選択できます。

承認ルートには、次の3つの項目を設定します。

同じ承認設定は複数のルートで共有できるため、承認者の変更は承認設定を1か所修正するだけで、その承認設定を使うすべてのルートに反映されます。また、承認設定を並べ替えたり削除したりした場合は、各ルートの承認順もそれに合わせて自動的に追従します。

ルート条件を上から順に評価し、最初に一致したルートを適用

ルート条件では、レポートのフィールドの値に対して「等しい」「等しくない」「より大きい」「以上」「より小さい」「以下」「範囲」「含む」「値がない」「値がある」といった条件を指定できます。複数の条件はAND（すべてに一致）またはOR（いずれかに一致）で組み合わせられます。比較対象には固定の値（実値）のほか、同じレポート内の別フィールドの値（参照値）も指定できるため、「申請金額が予算残額より大きい」といった条件も表現できます。条件の設定画面はデータ変換機能と共通のため、すでにデータ変換を利用している場合は同じ操作感で設定できます。

承認ルートは上から順に評価され、最初に一致したルートの承認順で承認が依頼されます。評価順は画面上の上下ボタンで入れ替えられます。条件を設定しないルートは常に一致する既定のルートとして扱われ、後続のルートが評価されなくなることを防ぐため、最後のルートにのみ設定できます。なお、どのルートにも一致しない場合や、承認ルートが未設定の場合は、承認設定の並び順で承認が依頼されます。

承認順を設定しない「承認不要ルート」

承認順を空にしたルートは「承認不要」として扱われます。このルートに一致したレポートの承認画面には、承認不要の承認ルートに一致している旨のメッセージが表示され、申請者が［承認不要のため承認する］を実行すると、承認ステップを経ずに承認済みとなります。承認者が存在しないため承認依頼メールは送信されませんが、承認済みになったことは承認の履歴に記録されます。

設定内容を一覧で確認し、不備を適用前に検出

承認ルート設定画面では、各ルートが評価順の番号とともに一覧表示され、「条件なし」「承認不要」といった区分や、承認順の流れ（例：課長承認 → 部長承認 → 役員承認）をひと目で確認できます。タイトルの未入力、承認順の重複、比較する値の未入力、最後以外のルートでの条件なし設定といった不備がある場合は、該当するルートに警告アイコンが表示され、解消するまで設定を適用できません。

運用の信頼性を支える仕組み

申請時点でルートを確定し、進行中の承認には影響させない

承認ルートは申請のたびに評価され、確定した承認順はレポートの承認情報として記録されます。そのため、承認の途中で承認ルートの設定を変更しても、進行中の承認の順序は変わりません。差し戻しを受けて内容を修正し、再申請した場合は、再申請の時点の内容で改めてルートが判定されます。差し戻し先として選べるのは、確定した承認順の先頭から現在の承認ステップまでに限られます。複数のレポートをまとめて申請する一括申請でも、ルートはレポートごとに判定されます。

「誰が承認するか」の判定を確実にするための設計

承認ルートは承認者を決める仕組みであるため、判定の確実性を重視した設計としています。

• ユーザー・タグ・選択肢などのフィールドは、表示名ではなく内部の識別子で比較します。同姓同名のユーザーの存在や、表示名の変更によって判定が変わることを防ぐためです。
• フィールドの削除などで評価できなくなった条件は「不一致」として扱い、承認フローを止めずに判定を続けます。
• 申請時に指定された承認者が、承認設定から導出される候補に含まれるかどうかをサーバー側で検証します。
• 承認フロー中のレポートは編集がロックされ、承認に関する操作は履歴として記録されます。

まとめ

決裁権限が申請内容によって異なることは多くの企業に共通しますが、それをシステム上の承認フローに正確に反映し、規程の改定に合わせて維持し続けるには、設計と運用の両面で工夫が必要です。承認ステップと経路を分けて定義する、評価順と既定のルートを決めておく、承認不要の範囲を明文化する、といった考え方は、ツールの選定にかかわらず検討の出発点になります。

RapidTableの承認ルート設定は、これらの考え方を画面上の設定として表現できるように設計しています。規程の見直しに合わせて、業務部門や情報システム部門が自ら設定を更新しやすくなるため、反映までの期間短縮や改修コストの抑制、承認業務の内製化につながることが期待できます。

また、承認の対象となるデータと承認の記録が同じ場所に蓄積されるため、帳票への承認印の差し込み、REST APIによる外部システムとの連携など、DXの取り組みを段階的に広げていく基盤としてもご活用いただけます。

※ 記載の内容は、本記事公開時点の製品仕様に基づいています。機能の詳細は製品マニュアルをご確認ください。