承認経路の設計｜直列・並列・合議の使い分けと、止まらない経路の条件

ワークフローシステムを入れたのに決裁が速くならない、という状況の多くは、紙の押印欄をそのまま経路に置き換えたことが原因です。押印欄が5つある申請書を、5段の直列経路として作れば、電子化しても回る速さは変わりません。変わるのは、紙を運ぶ時間がなくなるぶんだけです。

ここでは、承認経路をどう組み立てるかを、型の選び方、条件分岐の作り方、承認が止まる原因への対処、人事異動への備えという順で整理します。製品ごとの対応状況はワークフローシステム比較にまとめています。

経路を作る前に、決裁の基準を確認する

経路の設計は、システムの設定作業ではありません。誰がどこまでの金額を決められるか、という社内の決めごとを形にする作業です。したがって、最初に確認すべきは決裁規程や職務権限規程の側です。

ここで多いのが、規程に書かれた基準と、実際の運用がずれているケースです。規程では「30万円以上は部長決裁」となっているのに、現場では50万円まで課長が判断している、という状態でシステムを作ると、どちらに合わせるかの判断が設定作業の途中で必要になります。作業の手が止まるだけでなく、決め直しに時間がかかります。

先に確認するのは3点です。金額の基準がいくらで区切られているか、部署や案件の種類によって承認者が変わるか、複数人の合意が必要な決裁があるか。この3点が決まっていれば、経路の骨格は自動的に決まります。

承認の並べ方は3つの型に分かれる

紙の押印欄は、ほとんどが直列として作られています。しかし実際には、順番に意味がない確認が混ざっていることがあります。たとえば法務の確認と経理の確認は、互いの結果に依存しません。この2つを並列にするだけで、決裁にかかる日数は1日から2日縮みます。

合議の型は、対応できる製品が限られます。5製品の公表内容を確認したところ、コラボフローが「AND、OR、議決承認」を機能名として掲載し、グルージェントフローが条件によるルートの分岐に加えて複数人での合意（合議）と多数決での決定を設計できると説明しています。ジョブカンワークフロー、rakumo ワークフロー、X-point Cloudについては、公式の機能一覧で合議に相当する記載を確認できませんでした。役員会の決裁を電子化する予定があるなら、この点を選定の条件に入れてください。

条件分岐は「経路を分ける」か「経路上のステップを変える」か

金額や部署によって承認者を変える仕組みが条件分岐です。実装の考え方には2通りあり、運用への影響が違います。

グルージェントフローの公式ページでは、この2つが明確に分けて説明されています。ひとつは「条件によって申請ボタンの表示を変え、決まった経路にしか進めないようにする」方法。もうひとつは「1つの経路を作成し、条件によって経路上のステップを変える」方法です。同ページには、稟議書の申請金額が50,000円未満なら課長決裁、50,000円以上なら部長決裁という例が示されています。

実務上の違いは、申請する側の負担です。経路そのものを分ける方法では、申請者が「どの経路で出すか」を選ぶ必要が出てきます。社内規程を都度確認しないと選べないなら、申請の段階で誤りが混入します。同ページも「経路中の決裁者のみが変わるのが一般的」として、申請者側の負担を減らす考え方を挙げています。

分岐の条件として使えるものは製品によって異なります。金額、申請内容の種類、申請者の所属といった項目が一般的です。コラボフローは「申請時自動条件分岐」に加えて「判定時自動条件分岐」を持ち、承認段階で追記・変更されたデータに応じて経路を分岐させられると説明しています。承認の途中で金額が変わる案件が多いなら、この違いは大きく効きます。

分岐の数を増やしすぎない

条件分岐は便利ですが、増やすほど維持の手間が増えます。金額で3段階、部署で5通り、案件の種類で4通りの分岐を掛け合わせると、経路の組み合わせは60通りになります。人事異動のたびに、この60通りが正しく動くかを確認することになります。

現実的な落としどころは、分岐の軸を2つまでに絞ることです。金額と部署の2軸なら、確認すべき組み合わせは十数通りに収まります。3つ目の軸を足したくなったら、それは別の様式として分けたほうが管理しやすくなります。

製品によっては、経路の作り方そのものを簡素にする機能があります。コラボフローの「シンプル経路設定」は、1つの申請経路で全部署をカバーするという考え方です。部署ごとに経路を複製する運用と比べると、直す対象が1本で済みます。

承認が止まる3つの原因と、それぞれの対処

経路を短くしても、途中で止まれば意味がありません。止まる原因は3つに分けられ、それぞれ効く対処が違います。

1つ目は承認者の不在です。出張、休暇、退職で承認者が動けないと、そこで滞留します。対処は代理承認と代理申請の設定です。5製品すべてが代理の機能を公表しています。ただし機能があることと、使われることは別です。誰が誰の代理になれるのかを決裁規程の側で定義していないと、いざというときに設定できません。役職ごとに代理者を1人ずつ決めて、一覧にしておいてください。

2つ目は、承認依頼に気づいていないことです。通知がメールで届く設定にしていると、他のメールに埋もれます。普段使っているチャットへ通知を出せると、この問題は大きく減ります。連携先は製品によって分かれ、グルージェントフローはChatwork・LINE WORKS・Slack、rakumo ワークフローはSlack、コラボフローはLINE WORKSとMicrosoft Teamsを公表しています。あわせて、督促の間隔と、何日で上位者へ知らせるかを先に決めておきます。

3つ目は、判断材料が足りないことです。承認者が内容を確認できず、質問のために差し戻す。申請者が修正して出し直し、また最初から回る。この往復が最も日数を食います。対処は、承認を止めずに確認できる手段を用意することです。コラボフローの「相談機能」は、申請を回しながら相談や確認を行い、意思決定の履歴を残す機能として説明されています。rakumo ワークフローには「ディスカッション機能」と「コメント機能」があります。

3つ目は最も見落とされます。経路の段数を1つ減らすより、差し戻しを1回減らすほうが日数への効き方が大きい場面は珍しくありません。

差し戻しと版管理をどう扱うか

差し戻しを許容する設計にすると、次の問題が出てきます。「どの内容に対して承認されたのか」が曖昧になることです。

金額100万円で申請し、部長が差し戻し、80万円に修正して再申請し、承認された。このとき、記録の上では何が承認されたのかが分かる必要があります。監査や税務調査で申請の経緯を求められたとき、修正前と修正後が区別できないと説明ができません。

この点を機能として明示しているのは、rakumo ワークフローの「差し戻し時のVer管理機能」です。5製品の公表内容のなかで、版の管理を名前を付けて掲載しているのはこの製品でした。他の製品でも同等の記録が残る可能性はありますが、機能一覧からは確認できません。差し戻しが頻繁に起きる運用なら、トライアル期間中に実際に差し戻して、記録の残り方を確認してください。

あわせて決めておくべきなのが、差し戻しの回数が多い申請書への対応です。同じ様式で差し戻しが繰り返されるなら、原因は承認者ではなく様式にあります。必要な情報が入力欄として用意されていないか、入力の指示が分かりにくいかのどちらかです。入力内容の自動制御や段階別の入力制御といった機能で、申請の時点で誤りを止めるほうが根本的な対処になります。

人事異動に耐える経路の作り方

経路を役職者の氏名で固定すると、異動のたびに全経路を直すことになります。部署が20あり、様式が15種類ある会社では、修正対象が300件になることもあります。

これを避ける方法は2つあります。ひとつは、組織情報をもとにシステムが承認者を判定する仕組みを使うことです。rakumo ワークフローの「上長の自動表示機能」と「異動時の経路設定」がこれに当たります。Google Workspaceの組織情報を土台にできる製品の構造と噛み合った設計です。この方式では、組織情報が正確に維持されていることが前提になります。

もうひとつは、変更を予約する仕組みです。ジョブカンワークフローの「組織体制の変更予約」は、発令日に合わせて組織の変更を予約しておく方式です。組織情報の整備状況に依存しないぶん、どの会社でも使えます。

どの方式を採るにしても、異動の前に確認する手順を決めておくことが必要です。4月1日付の異動なら、3月中旬に対象となる経路を一覧で出し、承認者が空欄にならないかを確かめます。この確認を省略すると、期初の忙しい時期に申請が止まります。

5製品の経路まわりの対応

公式サイトの機能一覧で確認できた範囲を並べます。「記載を確認できず」は機能がないという意味ではなく、公表ページで確認できなかったという意味です。

例外処理をどこまで作り込むか

経路を設計していると、必ず例外が出てきます。社長が直接決裁する案件、緊急で当日中に通したい支払い、退職者が申請したまま残っている書類。これらを最初からすべて経路として作り込もうとすると、設定が終わりません。

現実的なのは、例外を2種類に分けることです。頻度が月に数回あるものは経路として作り、年に数回のものは運用でしのぐと決めます。年に一度の案件のために分岐を1本増やすと、そのぶん維持の対象が増えます。作らないと決めた例外は、紙で回すのか、管理者が経路を都度変更するのかを文書に残しておいてください。

製品によっては、申請や承認の時点で経路を変更できる機能があります。rakumo ワークフローの「申請・承認時の経路変更設定」がこれに当たり、例外的な決裁を経路の作り直しなしで扱えます。頻度の低い例外が多い会社では、この種の機能があるかどうかで設定の総量が変わります。

運用が始まってからの見直し

経路は一度作って終わりではありません。運用に入ると、想定していなかった使われ方が出てきます。見直しのきっかけになる数字は3つです。

• 申請から決裁までの日数：様式ごとに集計します。特定の様式だけ日数が長いなら、経路か様式のどちらかに原因があります。
• 差し戻しの回数：同じ様式で繰り返されるなら、入力欄の設計を見直します。
• 代理承認が使われた回数：多いなら、その承認者の負荷が高すぎるか、権限の委譲が必要な状態です。

これらを取り出すには、データ出力の機能が使えることが前提になります。多くの製品がCSV出力に対応しており、X-point Cloudにはクエリを定期実行して結果のCSVを出力するリモート出力機能があります。運用開始の時点で、この集計を月次で行う担当を決めておいてください。

見直しの周期は、最初の3か月は毎月、その後は半期ごとで足ります。ただし組織変更や規程の改定があったときは、その都度確認が必要です。

まとめ

承認経路の設計は、決裁規程の内容をシステムの形に置き換える作業です。紙の押印欄をそのまま直列で並べると、電子化しても速さは変わりません。順番に意味のない確認は並列へ、複数人の合意が必要な決裁は合議へと、型を選び直すところから始めます。

条件分岐は、経路そのものを分ける方法と、1つの経路の中でステップを変える方法があります。申請する側に判断させない設計のほうが、誤りが減ります。分岐の軸は2つまでに絞り、それ以上必要なら様式を分けてください。

承認が止まる原因は、承認者の不在、通知に気づいていない、判断材料が足りないの3つです。代理の設定、チャットへの通知、止めずに確認できる手段の3点で対処します。異動への備えは、氏名での固定を避け、組織情報からの判定か変更の予約を使ってください。

製品ごとの対応はワークフローシステム比較に、選定の手順はワークフローシステムの選び方に、決裁の基準そのものを見直す話は決裁規程と職務権限規程の見直しにまとめています。

参考にした一次情報

• グルージェントフロー 承認経路の条件分岐と自動振り分け（条件分岐の2つの方法、50,000円を境にした決裁者の切り替え例、経路中の決裁者のみが変わるという考え方）
• コラボフロー 機能一覧（申請時・判定時の自動条件分岐、AND・OR・議決承認、相談機能、段階別の入力制御、シンプル経路設定）
• rakumo ワークフロー 機能一覧（分岐設定、上長の自動表示機能、異動時の経路設定、差し戻し時のVer管理機能、ディスカッション機能）
• ジョブカンワークフロー 機能（承認経路の作成・分岐、代理承認、代理申請、組織体制の変更予約、承認とコメント）
• X-point Cloud 製品トップ（ノーコードでの経路設定、代理承認機能）
• X-point Cloud よくある質問（CSV出力とリモート出力機能）

機能と表記は変更されることがあります。この記事の内容は2026年9月6日に各公式サイトで確認したものです。公式サイトに記載がない事項については推測を書かず、確認できなかった旨を明示しました。導入の前に、必ず公式サイトと実際のトライアル環境で確認してください。