しきい値ベースのルーティングによる柔軟な承認ルール

ハードコーディングされた承認ルールがうまくいかない理由

ハードコーディングされた承認ルールは最初は問題ないように見えます。開発者がいくつかの条件を追加し、ワークフローが動き、チームは先に進みます。

問題が現れるのはビジネスが変わったときです。財務が支出限度を上げる、ある地域だけ別の方針になる、あるいは部門が特定のリクエストに追加の承認者を必要とする場合です。小さな更新に見えても、アプリロジックを変更し、テストし、リリースを待つ必要があります。

その遅れはコストになります。本来数分で済むポリシー更新が、技術作業に依存するために数日かかることがあるのです。その間、従業員は古いルールに従い、承認が停滞し、マネージャーはメールやチャットで例外対応を始めます。

さらに厄介なのは隠れた例外です。時間が経つと、チームは "金額が5,000を超え、部門がSalesならDirector Aに送る" や "リクエストがEuropeから来たらこのステップをスキップする" といった一回限りのルールを追加します。それらがワークフローの奥深くに埋もれると、見られるのはごく一部の人だけになります。

そうなると簡単な質問が答えにくくなります。

• ある金額以上の購買は誰が承認するのか？
• MarketingはOperationsと同じ方針か？
• 別の地域ではどうなるのか？
• どの例外が前四半期に追加されたのか？

全ルールセットが見えないとミスが起きます。ある人はポリシーに従っていると思っていても、アプリは古いルールを使っている。新しいマネージャーが見るべきでないリクエストを受け取り、本来の承認者は除外される。

だからこそ、ポリシーが頻繁に変わる場合はしきい値ベースのルーティングの方がうまくいきます。ルールをアプリの固定部分として扱うのではなく、見直しや更新が可能なビジネスデータとして保存するのです。

単純な経費ポリシーを想像してください。1,000未満はチームリード、1,000から10,000は部門長、それ以上は財務が承認するとします。これらの上限が来月変わるなら、ビジネスは承認を進めるためだけに開発者を必要とすべきではありません。

ハードコーディングは通常のポリシー更新をソフトウェアプロジェクトにしてしまいます。それが本当のコストです。

しきい値ベースのルーティングとは

しきい値ベースのルーティングは、あらかじめ定義した値に基づいて承認経路が変わることを意味します。しきい値とは、$1,000を超える金額、Finance部門からのリクエスト、あるいはEuropeでの購入など、境界を指す単純な概念です。

これらのルールをアプリに直接書く代わりに、テーブルに保存します。ワークフローはテーブルを読み、該当するルールを見つけて適切な人にリクエストを送ります。

基本的なセットアップは次のようになります。

• $500未満のリクエストはチームリードへ。\n- $500から$5,000までは部門マネージャへ。\n- $5,000超はディレクターへ。\n- HRのリクエストは一つの経路、ITは別の経路をたどる。\n- North AmericaとEMEAで承認者が異なる場合がある。

プロセスは同じままですが、それを制御する値を変更できます。

ロジックとポリシーを分離する

これが重要な考え方です。ロジックは「ルールをチェックして最初にマッチするものを選ぶ」部分です。ポリシーデータはルールの一覧そのもの：金額範囲、部門、地域、承認者、優先度です。

ロジックとポリシーが混ざると、小さな変更でもワークフローの編集が必要になります。分離されていれば、ワークフローは安定し、変更されるのはルール行だけです。

例えば、APACのSalesが$5,000以上ではなく$3,000以上でディレクター承認が必要になったら、テーブルの1行を更新するだけで済みます。承認プロセス全体を組み直す必要はありません。

これは管理が容易です。ポリシーはプロセス構造より頻繁に変わるからです。チームが再編成され、予算が変わり、地域に新しい責任者がつく。テーブルの方がハードコーディングより対応しやすいのです。

AppMasterのようなノーコードプラットフォームでは、通常ルールテーブルを作成しビジネスプロセスが実行時にそれをチェックします。このモデルは非技術チームにも理解されやすく、現実のポリシー記述（「この条件に当てはまればここへ送る」）と一致します。

ルールテーブルに入れるべきもの

良いルールテーブルは1つのシンプルな質問に答えるべきです：この条件に一致するリクエストは誰が承認するのか？

ルーティングがコード内に隠された値に依存していると、ポリシー更新がすべて作り直しに変わってしまいます。テーブルにすれば変更は可視化され、管理が容易になります。

実務的なルールテーブルは通常、リクエストを記述するフィールドから始まります：

• amount
• currency
• department
• region
• request type
• approver role

金額と通貨は重要です。同じ数値でも予算や国によって意味が違います。5,000 USDはある経路をたどり、5,000 EURや500,000 JPYは別の経路になるかもしれません。

部門と地域は企業の実際の働き方を反映します。Finance、HR、Operationsは同じ支出でも別の承認経路を持つことが多いです。地域はローカルルールや担当者の違いによって結果が変わります。

リクエストタイプも有効なフィルタです。出張、ソフトウェア購入、ベンダー支払い、値引き承認などは異なるレビュワーが必要になることがあります。このフィールドがないと無関係なリクエストが同じルールに当たってしまいます。

承認者は個人名ではなく役割を保存しましょう。Department Manager、Regional Director、Finance Controllerのような値を使います。人が移動したときは役割割り当てを一度更新すれば済み、すべてのルールを編集する必要はありません。

開始日と終了日を追加するのも役立ちます。特定の日に始まるポリシー、予算期の一時的ルール、次四半期の計画変更などに対応できます。期限を設けることで履歴を残し、期限切れのルールが有効なままになるのを防げます。

優先度フィールドも付ける価値があります。"EU + Finance + 10,000以上" のようなルールは "すべての部門 + 10,000以上" といった広いルールより優先されるべきです。優先度を明確にすることでルーティングが予測可能になります。

テーブルの構造

構造はシンプルに保ちましょう：1行が1つの承認ルールになるように。

例えば、Marketingの欧州で2,000以上の経費は地域マネージャが必要なら、それは1つのレコードにします。各行が一つの明確な意味を持つと、設定は更新、テスト、監査がしやすくなります。

メインのテーブルは2つのことに集中させます：ルールを発動させる条件と、ワークフローが次に何をすべきかを示す結果です。これにより、ビジネスユーザーとプロセス担当者の両方にとって読みやすくなります。

実務的なレイアウト

クリーンなテーブルには次のフィールドが含まれることが多いです：

• ルールIDまたはルール名
• 有効状態、必要なら開始日と終了日
• 条件フィールド（最小金額、最大金額、部門、地域、リクエストタイプなど）
• 結果フィールド（承認者の役割、承認者ユーザー、次のステップなど）
• 優先度とデフォルトルールフラグ

条件カラムには可能な限りフリーテキストではなく正確なフィールドを使ってください。毎回 "Finance" とタイプする代わりに部門IDを使う方が安全です。地域コード、リクエストタイプ、コストセンターも同様です。部門、地域、承認役割の小さな参照テーブルはスペルミスを防ぎ、フィルタを容易にします。

結果カラムではワークフローが何を返すべきかを決めます。チームによってはルールが特定の個人を指すべき場合もありますし、Regional ManagerやFinance Directorのような役割に送るべき場合もあります。一つの方法を選び、一貫性を持たせてください。

優先度は重要です。複数のルールが同じリクエストに一致する可能性があるからです。行の順番や作成日で依存せず、数値の優先度フィールドを追加して "1が先にチェックされ、100が後" といったルールを定義しましょう。

またフォールバックルールが必要です。これは特定の行に当てはまらないすべてのリクエストの安全網になります。デフォルトルールは未一致のリクエストをオペレーションマネージャや管理レビューキューに送るなどです。これがないとリクエストはルートが定まらず停滞します。

AppMasterで構築すると、これらのテーブルは視覚的に編集でき、ポリシー変更はデータで行われ、ハードコーディングされたワークフローブランチではなくなります。

セットアップ方法

テーブルではなく、まず判断（decision）から始めてください。ワークフローが答える必要のある問いを正確に書き出します。ある購買が$5,000超ならマネージャが必要か？FinanceはSalesからのすべてをレビューするか？ある地域のリクエストは別経路か？

これらの選択が明確になれば、しきい値ベースのルーティングはずっと簡単になります。ポリシーを保存することで、後でロジックを推測する必要がなくなるからです。

シンプルなセットアップは通常5つのステップに従います。

まず、ルーティングに影響するフィールドを持つ承認ルールテーブルを作成します。一般的なカラムはamount_min、amount_max、department、region、approver_role、priority、active_statusです。

次に、どのフィールドを空欄にできるかを決めます。部門や地域が空欄の場合は "このルールはすべてに適用" を意味するようにできます。

三番目に、最も具体的なルールから一般的なルールへと追加します。"Sales + Europe + 10,000超" のようなルールは、"どの部門でも + 10,000超" のような広いルールより先にチェックされるべきです。

四番目に、ローンチ前に実際の例でテストします。ちょうど$5,000の場合、部門データが欠けている場合、ある地域にカスタムルールがない場合などのエッジケースを使ってください。

五番目に、テーブルを編集できる人を制限します。ポリシー変更は容易にすべきですが、誰でも編集できてよいものではありません。

簡単な例を挙げると、北米のHRから$12,000のリクエストが来たとき、まず "HRで10,000超" のルールにマッチしてHRディレクターへ送るか、もしHR特有のルールがなければ "どの部門でも10,000超" の幅広いルールにフォールバックして財務へ送る、という流れになります。

順序は多くのチームが予想するより重要です。広いルールが具体的なルールより上にあると、間違った人にリクエストが行き、システムを信用しなくなります。

本番前にルール変更の責任者を1人決め、簡単なポリシードキュメントを書き、更新ごとに再テストしてください。小さなルーティングの変更が大きな影響を与えることがあります。

実務例

ある会社がすべてのチームで共通の購買申請フォームを使っていると想像してください。各リクエストには金額、部門、地域が含まれます。システムはそれらの値をルールテーブルと照合して適切な承認者を選びます。

会社にはMarketingとITの2つの部門があり、どちらも$4,000のリクエストを出す可能性がありますが、承認経路は同じである必要はありません。

同じ金額でも2つのリクエストを比較してください。USのMarketingによる$4,000はMarketing Managerへ送られます。一方USのITによる$4,000はIT Managerを飛ばしてCTOへ行きます。なぜならITはより低い閾値を持っているからです。

地域も結果を変えます。USで$2,500のMarketingリクエストはMarketing Managerへ行きますが、同じ金額のEUからのリクエストはRegional Marketing Leadへ行きます。フォームは同じまま、マッチするルールだけが変わるのです。

これがルールテーブルの本当の価値です。ポリシーはデータにあり、ワークフローロジックの内部にあるわけではありません。

会社が来月ポリシーを更新するとしても、プロセス全体を再構築する必要はありません。ITが$2,000を超えるリクエストをCTOに送ることにしたなら、1行だけ編集します：

• 旧ルール: IT, US, $3,001+, CTO
• 新ルール: IT, US, $2,001+, CTO

その他はそのまま動き続けます。新しいリクエストは即座に新ポリシーに従い、アプリ構造には手を付けません。

避けるべき一般的なミス

しきい値ベースのルーティングで最も難しいのはコアアイデアではなく、後から現れる混乱したエッジケースです。ポリシーが変わり、なぜその人にリクエストが行ったのか誰も覚えていないときに問題が起きます。

一般的なミスの一つは優先度が不明瞭なままルールが重複することです。あるルールはMarketingの$3,000超を部門長へ送り、別のルールは$5,000超をFinanceへ送るとします。$6,000のMarketingリクエストは両方に一致するため、明確な勝者が必要です。優先度はルールテーブルに入れ、隠れたワークフローロジックには置かないでください。

別のミスは個人名をハードコーディングすることです。名前は変わります。チームも変わります。誰かが休暇に入るか部署異動すると、"Maria Lopezに送る" といったルールは何度も編集しなければなりません。Regional Finance ManagerやSales Directorのような役割にルーティングし、その役割を現在の担当者にマップする方が安全です。

フォールバック経路を省くと静かな失敗が起きます。いつかは金額が珍しい、新部門、またはフィールドが空欄のためにどのルールにも一致しないリクエストが出ます。その場合でもデフォルトキューや管理チームに送るなどの処理が必要です。

地域ごとの例外も弱点です。ある国で有効なポリシーが別の国では通用しないことがあります。地域ごとにテストしないと、EU、US、APACのリクエストが別々の経路をたどるべきケースを見逃します。

時間ベースのルールも忘れられがちです。四半期末や予算期間用の一時的ルールを作ったら、開始日と終了日を設定しておきます。期限切れのルールが残ると古い例外が有効なままになり、誤った経路を生みます。

ローンチ前の最終チェック

しきい値ベースのルーティングを有効にする前に、実際のユーザーの視点で見直してください。すべてのリクエストが誰もが理由を推測しなくても正しい承認者に進むべきです。

最終レビューはシンプルにします。

• 各通常のリクエストに対して一つの明確な一致があるか確認する。二つのルールが同時に適用されると一貫性が失われます。
• フォールバック経路があるか確認する。欠けた部門、新しい地域、珍しい金額でもどこかに送られるべきです。
• ファイナンスやオペレーションが限度、日付、承認者を開発者なしで変更できることを確認する。彼らがテーブルのレコードを編集できるべきです。
• 値だけでなく日付もテストする。昨日のポリシーと来月のポリシーが有効日で正しく動くか確認します。
• ルーティングロジックを一ページで平易な言葉で書く。マネージャーが明確に説明できないなら、複雑すぎます。

有用な最終テストは5つのサンプルリクエストを作ることです：通常ケース、エッジケース、期限切れポリシーケースを含めます。チームが実行前に結果を予測できれば設定は準備OKです。できないなら単純化してください。

次のステップ

小さく始めてください。今日最も遅延や混乱を引き起こしている承認フローを1つ選びます。例えば一定額以上の購買申請や部門別の経費申請などです。まずそれを構築し、実例でテストしてから他のルールタイプを追加します。

このアプローチはルーティングモデルへの信頼を築きます。人々はルールがどのように機能するか、どこに例外があるか、何を変更すべきかを見られるようになります。設定が大きくなる前に確認できることが重要です。

最初のローンチは次の4つの基本的な質問に答えるべきです：

• どのリクエストタイプを最初に自動化するか？
• どのフィールドがルーティングを制御するか（例：金額、部門、地域）？
• 現在各ケースは誰が承認しているか？
• ポリシー変更時に誰がルールを更新するか？

最後の点は非常に重要です。ポリシー更新の責任者が明確でないと、ワークフローは徐々に実際の業務からずれていきます。ルール変更をレビューし、編集を承認し、なぜポリシーが変わったかの短い記録を残す担当者または小さなチームを割り当ててください。

またレビューのスケジュールを設定するとよいでしょう。ポリシーが頻繁に変わるなら月次レビュー、安定しているなら四半期ごとで十分かもしれません。短いレビューで時代遅れの閾値、欠けた部門、地域例外を早めに見つけられます。

レビューは実務的に保ちます。簡単な質問を投げかけてください：承認は正しい人に行っているか、チームに組織変更はないか、現在の限度は財務ポリシーに合致しているか、手動オーバーライドが多すぎないか。

視覚的に構築したい場合、AppMasterはルールテーブル、ルーティングプロセス、非技術スタッフがポリシーを更新するための管理画面を作るのに適しています。フルノーコードアプリ向けに設計されているため、ビジネスチームが承認変更を開発者に返すことなく直接管理できます。

一つのフローがうまく動くようになったら、同じパターンを次のプロセスにも再利用してください。小さく明確なステップは全面的な作り直しよりもうまくいくことが多いです。