承認を滞留させないための運用設計書：sysapproval_approverの状態設計と委任

承認の一覧を state で絞り込んでみたところ、Requested のまま止まっているレコードが半分を超えていました。確認できた771件のうち390件、割合にして50.6%です。承認まで進んだのは77件、対して却下はわずか2件でした。差は歴然です。

この数字だけを見ると「承認が形だけになっている」と考えたくなります。しかし原因を承認機能そのものに求めるのは早計です。承認という仕組み自体が壊れているのではなく、状態をどう設計し、どう検知するかという運用側の設計が抜けている実態が見えてきます。

この記事で分かること

• 承認レコード（sysapproval_approver）の仕組みと state の意味を、公式ドキュメントの定義と PDI の実機画面の両方で確認した内容

• 承認レコードの半分近くが Requested のまま止まっている実測と、状態が sysapproval_approver と change_request の2か所に分かれていて片方だけでは読み違えること

• 承認者を「人」で固定せず「役割・グループ」で決める設計と、不在時の委任（sys_user_delegate）の設計案

• 滞留を検知してエスカレーションする仕組みと、却下がほぼ0件という結果をどう設計に反映するか

承認という仕組みの基本（公式ドキュメントから）

ServiceNow の承認は、Change Request やカタログ申請などの対象レコードについて「先に進めてよいか」を承認者に問い合わせる仕組みです。公式ドキュメントの Classic approvals では、承認が誰に対して発生し、どんな状態を経て完了するかという基本の考え方が説明されています。承認をいつ・誰に求めるかという条件は Approval rules が担当する領域です。

承認レコードと対象レコードの関係

承認の実体は対象レコードの内部にはありません。専用のテーブル sysapproval_approver に、1人の承認者につき1レコードとして保存されます。承認者が3人必要な変更要求なら、sysapproval_approver に3行が作られる構成です。この生成を担うのが、Flow Designer の Ask for Approval action や、ワークフロー時代の Approval - Group workflow activity です。どちらも承認者を確定し、承認レコードを作る役割を持ちます。

承認対象の側にも、承認の状態を映すフィールドが用意されています。change_request であれば approval という項目で、承認がどこまで進んだかを表します。承認者ごとの詳細を持つ sysapproval_approver と、対象レコード側に要約された approval は別のフィールドです。この2つがどうずれるかは、有料エリアで実機の数字を突き合わせて確認します。

state が示す7つの状態（公式の定義）

sysapproval_approver.state の選択肢は7つあります。基本の意味は次のとおりです。

• Not Yet Requested … 複数承認者に順番がある場合など、まだ自分の番が回ってきていない状態

• Requested … 承認者に判断を求めている状態。承認待ちの中心にあたる値

• Approved … 承認者が承認した状態

• Rejected … 承認者が却下した状態

• Cancelled … 承認対象のレコード自体が取り消され、判断そのものが行われなかった状態

• No Longer Required … グループ承認などで他の承認者の判断により、自分の承認が不要になった状態

• Not Entitled … 承認レコードが作られた後、権限や条件の変化で承認者としての資格を失った状態

7つのうち、日常の承認業務でよく動くのは Requested・Approved・Rejected・No Longer Required の4つです。残り3つが実際にどんな場面で付くのかは、実機の選択肢定義とあわせて有料エリアで見ます。

実機で確かめる現状：承認の半分が「Requested」のまま

ここからは、PDI で実際に確認した画面です。sysapproval_approver を State でグループ化すると、次のように分かれていました。

771件の内訳を割合で整理すると、次のとおりです。

最多は Requested の390件で、全体の50.6%を占めます。次に多いのが No Longer Required の302件（39.2%）です。この値は、グループ承認で誰かが先に判断したため自分の分が不要になったときに付く値で、単独では滞留を意味しません。承認まで進んだのは Approved の77件（10.0%）、却下は Rejected の2件（0.3%）にとどまります。

却下はほとんど発生していない

判断がついた79件（Approved 77件＋Rejected 2件）のうち、却下の割合は2.5%です。承認プロセスを通ったもののほとんどが最終的に通っている計算になります。これが実務として妥当な数字なのか、それとも承認が判断の場として機能していないサインなのかは、件数だけでは判断できません。この解釈は有料エリアの設計案で扱います。

なお、Not Yet Requested・Cancelled・Not Entitled の3値は今回の集計で0件でした。承認順序がまだ回ってきていない、対象レコードが取り消された、承認者の権限が失われた、といった操作が今回のデータでは発生していないことになります。こうした操作自体が起きていないのか、別の理由があるのかは、この一覧だけでは切り分けられません。

承認はどこに集中しているか（対象テーブル別）

承認がどのテーブルに対するものかを Source table でグループ化すると、内訳ははっきり偏っています。

change_request が750件で全体の97%以上を占め、残りは標準変更提案・Service Catalog の申請・ナレッジ記事の公開承認などに散らばっています。承認の実態を読むうえで、change_request をどう見るかが要になります。

いつからの滞留か

Requested のまま残っている承認を作成日の古い順に並べると、次のように表示されます。

最も古い行の作成日は2023-06-24です。作成日と経過を整理すると、次のとおりです。

対象テーブルが記録されていない古いレコード3件と、change_request 向けの7件が、確認できた範囲でもっとも滞留期間の長いグループです。検証日から見て約3年が経過しています。この期間、承認者が不在でも代わりに処理できる仕組みが働いた形跡はありません。委任の設定そのものが0件だからです。代わりはいません。

ここで一つ断っておきます。もっとも古い滞留がPDIのデータであることを踏まえると、これが実際の業務放置なのか、検証用に投入されたデモデータの日付なのかは、この確認だけでは区別できません。自社の環境で同じ確認をするときは、この古さの分布がそのまま業務上の問題を示している前提で読まず、まず母集団の性質を確認するところから始める必要があります。