担当割り当て運用設計書：スキルもAWAも無い前提で何を決めるか

この記事は、PDI（Zurich、2026-07-08 確認）のOOTB（初期設定）が示す担当割り当ての振る舞いを前提に、担当割り当て（Assignment）運用の「あるべき姿」を設計する運用設計書です。経路の使い分け・スキルや負荷分散の要否・グループ設計原則・役割分担（RACI）までを、具体値は一例として自社導入時のたたき台に使うことを想定しています。

1. 運用設計の目的と背景

登録されたレコードが、担当できるグループ・担当者へ確実に届き、どこにも届かないまま放置されない状態をつくることを目的として、本設計書では担当割り当て運用のあるべき姿を設計する。何を条件に、どの仕組みで、誰へ割り当てるかを標準として定め、拾いきれない領域を誰がどう受けるかまで決める。あとから運用を変えるときに判断の背景までさかのぼれるよう、決定とその理由をあわせて記録する。

担当が決まる仕組みそのもの（Assignment RuleとData Lookupで担当がどう決まるか）は「ServiceNow の自動割り当てを実機で読み解く記事」で確認済みである。スキルベース割当の実体（cmn_skillとプラグインの実態）は「ServiceNow のスキルとスキルベース割当を実機で読み解く記事」も確認済みである。本設計書は構造の説明を繰り返さず、その構造の上で運用をどう決めるかに重心を置く。

担当割り当て運用の設計が達成すべきことを、次のように置く。

• Assignment Rule・Data Lookup・人手の使い分けを設計する。条件が固定的な割り当ては自動化し、拾えない領域は明示的に人手へ委ねる。

• スキルベース割当とAWA（動的な負荷分散）の要否・導入トリガーを設計で定める。持たない機能を前提にした運用を組まないためである。

• 連動するBusiness Ruleを織り込んだ運用ルールを設計する。担当割り当ては単独で完結せず、状態遷移や更新可否に波及するからだ。

• グループとメンバーシップの整合を保つ設計原則を定める。割り当て先が実在し、受け手が定まっている状態を維持するための原則である。

• 役割分担（RACI）と代替案の採否基準を設計に含める。設定を変える人と、結果に責任を持つ人を結びつける。

操作の「やり方」は、対になる運用手順書「担当割り当て運用手順書」で扱う。incidentの担当グループ・担当者の設定から再割り当てまでを実機で回した記録である。手順書は「どの画面で何を選び、どのボタンを押すか」を順番に示す。本設計書は「どの仕組みで、何を条件に、誰へ割り当てると定めるか」を決める。やり方を先に知りたい人は手順書が入口になる。

対象範囲は、Assignment Rule（sysrule_assignment）とData Lookup（dl_definition）を軸とした担当割り当て運用の設計判断とする。経路の使い分け、カバレッジの設計、スキルベース割当・負荷分散の要否を扱う。あわせて、グループとメンバーシップの設計原則、連動Business Ruleを踏まえた運用ルール、RACI・代替案・非機能と境界までを対象に含める。Flow Designer Subflowの内部ロジックとAssignment Rule／Data Lookupを評価する内部エンジンの実体は、今回の実機検証範囲外である。AWA有効化後のスキルマッチング挙動も同様に検証範囲外とし、詳細は末尾に明記する。想定読者は3種類。担当割り当ての自動化と滞留に課題を感じている運用設計者、Incident/Problemの割り当てに責任を持つプロセスオーナー、割り当て漏れの一次対応を担うサービスデスク担当者である。

設計領域の全体像

担当割り当て運用設計で決めることを4つの領域に分け、この順で設計を進める。

• 割り当て経路の設計（3〜4章）… Assignment RuleとData Lookupをどう使い分け、拾えない領域を人手へどう委ねると定めるか。

• 要否の設計（5〜6章）… スキルベース割当と動的な負荷分散を有効化すべきか、どんな運用要件が出たら検討するか。

• 整合の設計（7〜8章）… グループとメンバーシップの整合、連動Business Ruleを織り込んだ運用ルールをどう定めるか。

• 役割・境界の設計（9〜11章）… 誰が責任を持ち、どの代替案を推奨し、どこまでをOOTBのまま使うか。

矢印の終点を役割・境界の設計から経路の設計へ戻しているのは、運用で見つかる割り当て漏れや偏りが、たいてい経路の使い分けやグループの切り方の設計に行き着くためである。4つの領域が一巡して閉じる構造を、設計の枠組みとする。

2. 設計の前提（OOTBの担当割り当ての性質）

設計判断の土台として、OOTBの担当割り当てが持つ「仕組みの性質」を、件数ではなく振る舞いの観点で押さえる。少なくとも今回確認したPDI（Zurich/OOTB）では、担当割り当ては性格の異なる2系統と、それに連動する複数のBusiness Ruleで構成されていた。スキルや負荷分散といった高度な割り当ては、初期状態では提供されていない。

2-1. 性格の異なる2系統（Assignment RuleとData Lookup）

担当を自動で決める仕組みには2系統がある。条件で1つの割当先を決めるAssignment Rule（sysrule_assignment）と、複数の入力列の組み合わせをマッチさせるData Lookup（dl_definition）である。両者は同じ「担当を決める」目的を持ちながら、条件の持ち方と割当先の決め方が異なる。

Assignment Ruleは、CIのクラスやbusiness_serviceといった単一の属性を条件に、割当先のグループや担当者を丸ごとセットする。1ルールが1つの割当先を持つ単位である。OOTBでもproblem向けに、CIクラス（cmdb_ci_databaseなど）を条件に振り分ける条件ベースのルールが有効になっている。振り分け先はDatabase・Network・Softwareの各チームで、条件ベース振り分けの実例である。

一方Data Lookupは、複数の入力列（category／subcategory／location／cmdb_ci）の組み合わせを1行ずつ持つマッチングテーブル型である。1つの定義に複数のマッチ行をぶら下げられる。incidentのAssignment Lookupは、category×subcategoryの組み合わせに対して担当者をセットする仕組みである。たとえば「Inquiry / Help × Email」の組み合わせに特定の担当者を割り当てる、という形で表現される。

この「単一属性の条件ベース（Assignment Rule）」と「複数入力列のマッチング型（Data Lookup）」という性質の違いが、割り当て経路の設計（3章）で使い分けを決める根拠になる。なお、incident向けのAssignment Ruleは無効化されている。割り当ての実装はFlow Designer側（Subflow）へ移っていると観察できるが、Subflowの内部ロジックは検証範囲外とする。

2-2. 担当確定に連動するBusiness Rule

担当割り当ては単独で完結せず、割り当ての設定が変わったときに連動して動くBusiness RuleがOOTBに複数用意されている。Incident State Active on Assignmentは、担当（assigned_to）が決まった時点でincident_stateをNewからIn Progressへ自動遷移させる。Populate Assignment Group based on CI/SOは、CI／service_offeringが空から変化したときに紐づくグループを自動セットする役割を持つ。Abort changes on groupは、assigned_toが新しいassignment_groupのメンバーでなければ更新を中止する。reassignment counterは、割り当てが変わるたびにreassignment_countを加算するカウンタとして働く。これらは、担当割り当てが状態遷移や更新可否に波及する性質を示しており、連動Business Ruleを踏まえた運用ルールの設計（8章）で扱う。

2-3. OOTBが提供しない割り当て（スキル・動的な負荷分散）

高度な割り当ての土台となる機能は、このPDIのOOTBでは提供されていなかった。スキルベース割当のためのcmn_skill／sys_user_skillは、テーブル自体が存在しない。Skills Management・Skill Determinationといった関連プラグインも、いずれもinactiveだった。

キューの空きや現在の担当件数を見て自動で振り分ける負荷分散の実体であるAdvanced Work Assignment（AWA）系プラグインも、すべてinactiveだった。担当者間を順繰りに割り振るラウンドロビン的なロジックも、Business RuleやScheduled Scriptを探索した範囲では見つからなかった。

つまり、このPDIのOOTBでは、スキル一致度によるスコアリングも、負荷を見た動的な振り分けも行われていない。担当の絞り込みは「条件ベース／マッチング型のルール」または「人手」で行う前提になる。この事実は、スキルベース割当の要否設計（5章）と負荷分散の方針（6章）を、機能ありきではなく「有効化すべきか否かの判断」から始める理由になる（AWA有効化後の挙動やSubflow内部は検証範囲外）。

ここまでの前提を土台に、ここから先は割り当て経路の使い分け・カバレッジの委ね方・スキルと負荷分散の要否を扱う。続けて、グループとメンバーシップの整合・連動Business Ruleの運用・RACI・代替案・非機能と境界も扱う。あるべき姿として、一つずつ設計していく。