0. 背景と結論
ServiceNowには、利用者が不在時などに承認・タスク処理・通知受領等の責務を他者に引き継ぐための標準機能（以下、Service Delegation）があります。
ただし、Service Delegationはすべてのタスクに関する承認や通知が委任されるため、機密情報を扱うHR領域では適さないケースがあります。
この課題を背景に実装されたのが、**Granular Delegation（詳細な委任）**です。
Granular Delegationを使うと、特定のタスクのみを委任できるようになります。HRSDを主対象とした機能ですが、他アプリケーションにも適用可能性があります。
本記事では、
- 従来機能の限界
- Granular Delegationの価値
- 実装手順と動作検証
- 他アプリへの展開時の注意点
を順に整理します。
1. 従来機能の限界（Service Delegation）
Service Delegationは、古くから提供されるプラットフォーム共通機能です。
「セルフサービス > プロファイル」から自身のプロファイルを開き、関連リスト「委任」で設定できます。
設定は簡単ですが、委任対象を業務単位で細かく分けられません。
そのため、次のような運用要件に対応しづらくなります。
- IT機器調達の承認は委任したいが、人事申請（休暇・昇格）は委任したくない
- IT機器調達の承認はチームリーダーに、人事申請の承認はレポートライン上司に委任したい
- オンボーディングケースの「上司向けタスクのみ」を委任したい
2. Granular Delegationの価値
Granular DelegationはRomeでHRSD向けに一般公開された機能です。
対象テーブルや条件を定義することで、特定レコードのみを委任できます。
さらに、誰が誰に委任できるかをクライテリアで制御できるため、統制要件に合わせた運用が可能です。
委任設定UIもEmployee Centerに用意されており、エンドユーザーが操作しやすい構成です。
従来機能との違い（要点）
| 観点 | Service Delegation | Granular Delegation |
|---|---|---|
| 委任粒度 | 広い（全体に効きやすい） | 条件付きで絞り込み可能 |
| 統制 | 限定的 | クライテリアで制御可能 |
| HRSDとの相性 | 要件次第で不足 | 高い |
3. 実装方法（検証シナリオ）
検証シナリオは、HRアカウントアクセス要求で上司承認が必要なプロセスを前提とします。
この承認を、別マネージャーへ委任できるように設定します。
3.1 プラグインをインストールする
com.glide.granular_service_delegation をインストールします。
3.2 委任ルールテーブルを設定する
「詳細な委任 > 委任ルールテーブル」で対象テーブルを登録します。
登録対象テーブルと同じアプリケーションスコープで設定する必要があります。
3.3 委任ルールを設定する
「詳細な委任 > 委任ルール」で、対象レコード条件と委任種別（承認 / 割り当て）を定義します。
3.4 委任者・委任先のクライテリアを設定する
作成したルールに対して、
- 委任者のユーザー基準
- 委任先のユーザー基準
を関連リストで設定します。
3.5 （オプション）委任ルールカテゴリを設定する
ルール数が増える場合、カテゴリ化で一括委任を可能にすると運用しやすくなります。
今回はスキップします。
4. 動作検証（HRケース承認）
登場ユーザーは次の3名です。
- Athena Cantu（起票者）
- David Loo（Athenaのマネージャー / 承認者）
- Beth Anglin（Davidの委任先）
4.1 [David] 委任を設定する
Employee Centerのプロフィールから「委任を追加」で、対象業務・委任先・期間を設定します。
設定後、委任先リストにBethが追加されます。
Bethには委任設定通知メールが届きます。
4.2 [Athena] HRアカウントアクセス要求を起票する
Employee Centerから起票します。
David宛に承認タスクが発行されます。
通知メールでは、承認依頼の宛先にDavidとBethの2名が入ります。
David画面上でも、承認タスクがBethに委任されていることを確認できます。
（事前設定がない場合でも、個別タスクからアドホック委任が可能です）
4.3 [Beth] 承認する
Employee Centerの「自分のタスク」から委任された承認を開き、承認を実行できます。
補足：アドホック委任
事前に委任設定がなくても、タスク画面から個別に委任先を設定できます。
5. 他アプリケーションへの拡張（要求アイテム承認）
公式ドキュメント上は、HRSD以外への適用可能性が示されています。
今回は要求アイテム承認（RITM）で確認しました。
事前に委任ルールを作成し、David側で委任設定を済ませます。
iPhone 13を注文し、David画面で承認リクエストを確認すると、委任自体は有効でした。
Bethは通知メール内リンクから、プラットフォームUIで承認できました。
未解決事項
Employee Centerの「自分のタスク」では、委任先に承認リクエストが表示されませんでした。
委任そのものは成立しても、チャネル（EC / Platform UI）で表示挙動が一致しないケースが確認されました。
「どのチャネルで処理させるか」を先に決めて検証するのが安全です。
まとめ
標準のService Delegationは手軽ですが、委任対象を細かく絞れないため、HRのような機密業務では統制上の課題が残ります。
Granular Delegationは、対象レコード・委任種別・委任者/委任先条件を定義できるため、必要な業務だけを委任できる点が有効です。
今回の検証では、HRケース承認はEmployee Center上で実用的に動作しました。
一方、要求アイテム承認では、プラットフォームUIでは承認できるものの、Employee Center表示に差異がありました。
そのため、Granular Delegationの導入時は、アプリケーションごとに処理チャネルを定義し、必要に応じて追加設計・追加検証を計画することが実務的です。
参考
公式ドキュメント: 詳細な委任
Youtube: HR Delegation Getting Started
コミュニティ記事: Empower Employees with Granular Delegation