ServiceNowのResource Management：誰をいつ何時間割り当てるかをどう管理するか

プロジェクトのタスクは決まったのに、「誰が」「いつ」「何時間」動くのかは別の話です。ServiceNowではこれを Resource Management が担います。プロジェクト側の要求（Requested）を資源マネージャーが確定（Confirmed）し、最後に割当（Allocated）へ進む2段階の合意で人を決定する仕組みです。Australia PDIでPPM Standardを導入した環境を実際に開き、この3段階がどのテーブルにどう記録されるかを確かめました。

PPMの流れの中で、この記事が扱うのは、DemandとProjectの要員計画を受け持つResource Planです。他のモジュールは別の記事で扱うため、ここではResource Planに絞って掘り下げます。

同じ実機検証の手法で改善活動の管理を追った記事にServiceNowのCIM（継続的な改善管理）とは何か？があります。PPM Standardは、このCIMと同じくPPMの一角を占めるプラグイン群の1つです。

PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。

• ①導入手順：PPM Standardを入れる

• ②影響調査：入れると何が増えるか

• ③PPMとは：モジュールの全体像（親記事）

• ④初期設定：プロパティ・ロール・カレンダー

• ⑤メニュー解説：どの画面から操作するか

• ⑥Demand：9状態の選別

• ⑦Project：計画・進捗・費用の管理

• ⑧Resource：要員の割り当て（この記事）

• ⑨PortfolioとProgram：投資判断の上位構造

• ⑩連携：IncidentやCIMとのつながり

• ⑪運用手順：Idea→Portfolio 22ステップ（有料100円）

• ⑫開発設計書（有料300円）

• ⑬運用設計書（有料300円）

• ⑭トラブル：つまずく点と直し方

Resource Planは「席の予約」で、「確定と割当」という2回の合意を経て決定する

先に全体の形を書きます。Resource Managementの中心にあるのは resource_plan というテーブルで、これは1件の「予約」です。プロジェクト側が「この期間、この役割の人が何時間欲しい」と要求し、資源マネージャーがそれを確定し、最後に個々の人へ割り当てる。この3段階がそのまま resource_plan.state の主要な値になっています。

一覧には30件のResource Planが並び、State列には次の4つが混在しています。

• Allocated（割当済み）

• Confirmed（確定）

• Requested（要求中）

• Planning（計画中）

Task列にはPRJ0010330のようなプロジェクトタスク番号が入り、Group列にはAnalystsやJava Developersなどのグループ名が並びます。つまり1レコードが「どのタスクに」「どのグループまたは個人が」「いつからいつまで」「何時間」を1行で表しているわけです。

ここから先は、この「予約」がなぜ2段階の合意を要求する設計になっているのか、公式の説明と実機の件数を突き合わせて確かめます。

Resource Managementは何のためにある仕組みか

プロジェクトのタスクを1件作れば「何をやるか」は決まります。しかし「誰がやるか」は別問題です。担当者を1人指定するだけなら pm_project_task のフィールドに人を入れれば済みますが、実務では次のような疑問が残ります。この人は来月まで空いているのか。同じ人が他の3案件にも入っていないか。時間の単位はどう数えるのか。

PPM Standardの公式説明にはこう書かれています。

（訳: 需要やプロジェクト、ポートフォリオと資源を管理するための一連のアプリケーションをインストールします。アイデアから実行までの完全な可視性を提供します。さまざまなワークベンチを通じて、資源やコスト、時間や予算の計画と追跡を支援します）

引用元: /v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo

「アイデアから実行までの完全な可視性を提供する」というのが公式の位置づけです。そのうえでプロジェクトと需要に対する資源やコスト、時間、予算を計画から追跡、管理まで一体で行う仕組みです。単に人を割り当てるだけでなく、時間とコストを一体で扱う仕組みだと製品自身が説明しています。Resource Managementはこの「resources, cost, time」の部分を専門に担うプラグインで、内部名は com.snc.resource_management です。PPM Standardを導入すると自動的に有効化されます。

プロジェクト管理だけでは「誰が」が確定しない理由

pm_project と pm_project_task には resource_assignee（Resource assignee）という簡易フィールドも存在します。これはUser型のリストで、値を入れるだけで担当者を並べられます。ただしこの方法は稼働状況をチェックしないため、同じ人を10案件に同時に入れることも可能です。

resource_plan を経由すると話が変わります。要求した時間が本人の空き時間に収まるか、他の計画とぶつかっていないかを資源マネージャーが確認したうえで確定する仕組みです。pm_project には resources_from_resource_plan（Derive assignee list from resource plan）という真偽値フィールドもあり、これをオンにすると担当者一覧をResource Planから自動的に導出します。つまり「片手間の指名」と「稼働管理を経た割当」を、同じプロジェクトの中で使い分けられる設計です。

公式説明はResource Planの各フィールドをどう定義しているか

resource_plan には56個の固有フィールドがあり、そのうち16件には sys_documentation の hint として公式の説明が付いています。

いくつか読んでおきます。percent_allocated（% Plan）は「Percentage of Hours Allocated」です。distribution_type（Allocation spread）の公式説明はこうです。

（訳: 割当期間内の稼働日に対して、時間を前倒しで配分するか均等に配分するかによって、ユーザーの日次割当を作成します）

引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=distribution_type

前倒しで配分するか、稼働日に均等配分するかを選べるという意味です。planned_schedule（Planned schedule）の公式説明はこうです。

（訳: リソースプランの計画時間と要求された割当は、このスケジュールを使って計算されます）

引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=planned_schedule

この計画の時間計算がどの稼働カレンダーを基準にするかを指すフィールドだと分かります。稼働日や休日をどう数えるかの基本はSLAが土日を飛ばす理由：営業時間（cmn_schedule）で扱った仕組みと同じです。Resource Planもこのスケジュール参照を土台にしています。

ナビのメニューがそのまま Requested / Confirmed / Allocated になっている

Resource Managementのナビゲーションメニューを開くと、resource_plan を対象にしたモジュールが並びます。All・Create Newに加えて、次の3本が専用モジュールとして用意されています。

• Requested

• Confirmed

• Allocated

これは state値でフィルタしたビューにすぎませんが、メニュー名として3段階がそのまま出ている点は分かりやすい設計です。

新規作成フォームを開くと、上段の項目が並びます。Stateの初期値は自動的に Planning です。下段のタブは次の4つで構成されています。

• Resource Details

• Request Details

• Allocation Config

• Notes

ナビのメニュー名（Requested/Confirmed/Allocated）とタブ名（Request Details/Allocation Config）が対応している点も分かります。フォーム下部には Save・Submitに加えて Request ボタンがあり、これを押した時点でstateが2（Requested）に変わって資源マネージャー側の確認待ちに入ります。

Resource Management Workspaceは一覧操作とは別に集計を見る専用画面

resource_planにはここまで見てきたリストとフォームのほかに、Resource Management Workspaceという専用画面が用意されています。ナビゲータの「Workspaces」メニューから実際に開いて確かめました。

開いた先は/now/workspace/rm/homeで、「Overview Dashboard」という集計専用の画面が最初に出ます。並んでいたのは次の4枚のカードです。

• Resources over allocated（稼働超過）

• Resources under utilized（稼働不足）

• Unassigned assignment requests（未割当の要求）

• Pending resource requests（保留中の要求）

resource_plan_list.do?sysparm_query=GROUPBYstateのような一覧のグルーピングでも件数は数えられます。ただしWorkspaceは「稼働が超過している人」「まだ埋まっていない要求」という判断に直結する切り口を、あらかじめカードとして用意している点がリスト操作と違います。

このPDIではデモデータが実データの稼働期間と噛み合っていないためか、4枚とも0件でした。画面自体は実在し開けましたが、集計の中身が0件だったという事実だけをここでは報告します。0件の原因（フィルタ条件の期間指定など）までは検証範囲外です。左のサイドバーには資源カードを管理する画面もありましたが、こちらも対象データが無く「No resource cards are available」という空の状態でした。

pps_resourceロールが無いと候補にすら出ない

Resource Planに人やグループを載せるには、対象に pps_resource ロールが必要です。これは推測ではなく、フィールドの公式説明にそのまま書かれています。

resource_plan.user_resource（User）の公式説明:

（訳: pps_resourceロールを持つユーザーのみ、Resource Managementで管理できます）

引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=user_resource

resource_plan.group_resource（Group）の公式説明:

（訳: pps_resourceロールを持つグループのみ、Resource Managementで管理できます）

引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=group_resource

つまりResource Managementの候補に現れるのは、事前にこのロールを付けた相手だけです。ロール自体の説明も同じ趣旨です。

実測すると、アクティブユーザー692人のうち pps_resourceロールを持つのは186人でした。全体の3割弱です。この数を超えて割り当てたい場合は、まずロール付与から着手することになります。ロールをどのグループ経由で付けるかを追うプロパティも1つ見つかりました。com.snc.resource_management.filter_table の値は sys_user_grmember（Group Member）で、説明は「Resource Management Filter Table」です。つまり資源候補の絞り込みは、ユーザー、グループ、ロールの中間テーブルを経由しています。この中間テーブルの構造そのものはServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどるで扱った内容と同じ土台です。

時間は3層の器を通って積み上がる

Resource Planを1件作って終わりではありません。要求から割当までの合意は resource_plan に1行で記録されますが、実際の時間は日次・期間ごとに分解され、さらに週次・月次へ集計されます。

state値は実は13種類あります。そのうち「◯◯ in progress」という処理中を示す一時的な4値を除くと、業務上の意味を持つ状態は9つです。具体的な値は次の表のとおりです。

実際のデモデータ30件で値が入っているのはPlanning、Requested、Confirmed、Allocatedの4状態だけです。残り5つの状態はいずれも0件でした。定義上は取りうる状態が多くても、実務でよく通る道筋は限られているということが、件数から見えてきます。

resource_planは、30件が「計画」という単位を1つずつ表す

resource_plan 自体は継承なしの独立テーブルです。CIMの改善イニシアチブやProject/Program/Project Taskのように Planned task を継承する構造とは違い、単独で日付、時間、状態を持ちます。top_task フィールドは Planned task を参照するため、この計画がどのプロジェクト、プログラム、プロジェクトタスクに紐づくかをたどれます。task フィールドはより広い Task を参照するので、Project TaskだけでなくDemandに対しても計画を作れる構造です。

resource_allocationは1,595件が「日々・期間ごとの割当」を刻む

resource_plan 1件が確定・割当されると、その中身は resource_allocation に展開されます。

実測件数は 1,595件。resource_plan の30件に対して50倍以上に増えているのは、1つの計画が月ごと・週ごとの複数レコードへ分解されているためです。resource_allocation の start_date と end_date はどちらも必須項目で、resource_plan への参照も必須という制約が付いています。つまりこのテーブルは「親のResource Planを離れて単独では存在できない、期間ごとの明細」という位置づけになります。

resource_aggregate_daily / weekly / monthlyは集計の器で実機の意外な差が出た

resource_allocation の先にはさらに3つの集計テーブルがあります。PPM Standard導入時に新しく増えたテーブルで、日次、週次、月次の粒度で割当時間を積み上げます。

件数を数えると、週次43,976件・月次10,199件に対して、日次だけが0件でした。テーブル自体はPPM Standard導入時に作られていて空ではありません。原因を探すと、sysauto_script に「Generate resource aggregate dailies」というジョブが見つかりました。設定を見ると active=true ながら run_type=On Demand でした。つまり日次集計を作る仕組みは入っているものの、定期実行のトリガーは設定されていません。誰かが手動で実行するまで動かない状態だったわけです。スケジュールジョブが動いているかどうかを切り分ける方法は、次の2本で扱った手順がそのまま使えます。

• ServiceNowのスケジュールジョブは本当に動いている？ run_countとnext_actionで見分ける

• スケジュールジョブが動かないときの調べ方：sys_triggerの読み方

配り方を決める7つのプロパティ

resource_plan にどれだけの時間を、どう配分するかは com.snc.resource_management.* のシステムプロパティ側で制御されています。

主要なものを表にまとめました。

average_daily_fteが「時間」と「人日」の単位をそろえる

average_daily_fte の既定値は 8。公式説明はこうです。

（訳: 1日あたりの平均FTE時間／1人日あたりの時間数。この値はリソースプランでFTEや人日を時間に変換する際に使用されます）

引用元: /sys_properties_list.do?sysparm_query=name=com.snc.resource_management.average_daily_fte

FTEや人日で入力された量を時間へ変換する基準値だと分かります。resource_plan には fte（FTE）や man_days（Person days）、planned_hours（Planned hours）といったフィールドが並んでいます。request_typeの選択肢も Hours、% Capacity、FTE、Person Days の4通りです。プロジェクト側は「2人日ください」と要求できます。システムは average_daily_fte（既定値8）を基準に時間へ変換して資源側に伝える、という換算の橋渡し役がこのプロパティです。

distribution_typeが前倒しか均等かを決める

割り当てた時間を稼働日にどう配分するかは distribution_type で選びます。選択肢は Even（均等） と Front load（前倒し） の2つです。公式説明は「front loading or evenly distributing hours across working days in the allocation period」でした。均等配分なら期間中の稼働日に平均して時間を割り振り、前倒しなら早い日に多く配分します。この配分計算の基準となる稼働日・休日の定義は planned_schedule が参照する cmn_schedule 側にあります。

percentage_allocation_normal / warningが稼働率を色で見分ける

percentage_allocation_normal は 50、percentage_allocation_warning は 90 が既定値です。公式説明を読むと、稼働率がnormalの値未満なら緑、normal以上warning未満ならオレンジで表示されると書かれています。数値そのものより、閾値を2段階持たせて色分けする設計に意味があります。緑は余力がある状態、オレンジは埋まりつつある状態を示し、どちらの範囲にも入らない高稼働のケースを画面上で目立たせる仕組みです。

fill_availability_first_in_allocationが「空きから埋める」順番を決める

既定値は true。公式説明は「When allocating hours, fill the available hours before over allocating」です。つまり割当処理は必ず空いている時間から先に埋め、それでも足りない場合にだけ超過配分へ進みます。allocate_more_than_24hours_per_day は既定 false なので、1日24時間を超える割当は通常許可されません。過剰配分を防ぐ側のガードがプロパティレベルに用意されているわけです。

resource_typeとrequest_typeが「誰に」「どの単位で」を分ける

Resource Planを新規作成すると、まず resource_type を選びます。選択肢は Group、User、Role、Attribute の4つです。個人を直接指名するだけでなく、グループ単位や役割（Role）単位、属性（スキルなど）単位でも要求できる設計です。実際に resource_plan には skills（Skill型のリスト）フィールドもあり、特定の技術を持つ人を条件として指定できます。スキルをどう定義し、どこで担当者に紐づけるかはスキル割当はどこにあるか（cmn_skill）で扱ったcmn_skillの仕組みと同じです。

request_type は前述のとおり Hours、% Capacity、FTE、Person Daysの4通り。「時間で欲しい」「稼働の何%が欲しい」「何人日欲しい」を要求側が選べるため、プロジェクトの性質に応じた単位で交渉できます。

Time Card Managementまで連鎖導入されている理由

resource_plan と resource_allocation には、どちらも actual_hours（Actual hours）・actual_cost（Actual cost）というフィールドがあります。計画（planned）・確定/割当（allocated）に加えて、実績（actual）を記録する列がすでに用意されているわけです。

PPM Standardを導入すると、Resource Managementの依存関係を通じてTime Card Management（com.snc.time_card）まで連鎖的に有効化されます。単体では気づきにくい連鎖ですが、actual_hours の列がフォームに存在する時点で、この製品が「計画するだけ」でなく「計画に対してどれだけ実際に働いたか」まで記録する前提で作られていることが分かる作りです。実績値の記録元をTime Cardに一本化することで、resource_plan の実績と pm_project_task の進捗を同じ根拠で説明できるようになります。

実務でどう使うか（設計提案として）

ここまでの実機確認をもとに、導入・運用の実務でどう活かすかを整理します。推測を含む提案として読んでください。

ロール付与を後回しにしない。Resource Planの候補に出るのは、pps_resource を持つ人だけです。プロジェクト管理者を先に育てても、資源として動かす人にロールが付いていなければ計画が作れません。導入初期のタスクとして、対象メンバー・グループへのロール付与を独立したチェック項目にしておくべきです。

resource_assigneeとResource Planを使い分ける基準を決めておく。稼働チェックが不要な小規模タスクには resource_assignee の直接指定で十分です。複数案件をまたぐメンバーや、稼働率を可視化したい役割にはResource Planを使う、という線引きをルール化しておくと運用が安定します。

日次集計ジョブの起動方法を事前に決めておく。resource_aggregate_daily はOn Demandのため、日次粒度でのレポートやダッシュボードを設計するなら、誰がどうやってこのジョブを起動するかを運用手順に含める必要があります。放置すると週次・月次は埋まっているのに日次だけ空、という状態が本番でも起こり得ます。

実機で気づいたこと

stateは13種類あるのに、デモデータでは4種類しか動いていませんでした。 定義上は処理中の一時状態やRejected・Canceledまで用意されています。しかし実際に流通しているレコードはPlanning、Requested、Confirmed、Allocatedの4状態に収まっていました。

グルーピング表示でも4状態しか出てきません。「定義されている選択肢の数」と「実際に業務で使われている状態の数」は別物だと、この機能でも同じことが確認できました。他のテーブルでも似た現象は起きやすく、選択肢一覧だけを見て設計判断をするのは危険だとあらためて感じます。

pps_resourceロールの保有者は3割弱でした。 692人のアクティブユーザーに対して186人。「誰でも資源として割り当てられる」わけではなく、事前の準備が要る仕組みだと数字で裏付けられました。

日次集計が0件という発見が一番の収穫でした。 週次・月次はどちらも数万件規模でデータが入っているのに、日次だけ空です。テーブルは存在し、ジョブも用意されているのに、トリガーがOn Demandのため誰も起動していない。「テーブルがある」ことと「データが入る」ことの間には、ジョブの起動条件という見落としやすい段差があることを実機で確かめられました。

resource_assigneeという簡易フィールドの存在も意外でした。 Resource Managementの本格的な仕組みを見たあとだと、pm_project に稼働チェックなしの直接指定フィールドが残っていることに驚きます。ただしこれは「機能不足」というより、厳密な管理が要らない場面のための逃げ道として意図的に残されていると読むほうが自然です。

用語

• Resource Plan … 「席の予約」に相当する計画の単位。テーブル名は resource_plan

• Resource Allocation … Resource Planを日次・期間ごとに分解した割当明細。テーブル名は resource_allocation

• pps_resource … 資源として管理される対象（User/Group）に必須のロール

• FTE … Full Time Equivalent。常勤換算の人員量

• distribution_type … 割当時間を稼働日にどう配分するかを決めるフィールド（Even/Front load）

• On Demand（run_type） … スケジュールジョブの実行方式の1つ。定期実行ではなく手動または呼び出しで起動する

自分の環境で確認するときのURL

インスタンスのURLに続けて開いてください。

• Resource Plan一覧：/resource_plan_list.do

• Resource Allocation一覧：/resource_allocation_list.do

• Resource Planをstateでグルーピング：/resource_plan_list.do?sysparm_query=GROUPBYstate

• Resource Management関連プロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.resource_management

• pps_resource関連ロール：/sys_user_role_list.do?sysparm_query=nameINpps_resource,resource_manager,resource_user

• 集計テーブルの定義：/sys_db_object_list.do?sysparm_query=nameLIKEresource_aggregate

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNowが製品に同梱しているフィールドやプロパティの公式ドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が表示されます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name%3Dresource_plan%5EhintISNOTEMPTY

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.resource_management%5EdescriptionISNOTEMPTY

• プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=idINcom.snc.financial_planning_pmo,com.snc.resource_management

検証範囲とおことわり

Australia PDI（Australiaファミリーリリース）に、OOTBの状態からPPM Standardを導入した環境で確認しました。デモデータは導入時に投入されています。件数は2026-08-15時点のこの環境のものです。

確認していない範囲は次のとおりです。

• resource_aggregate_daily の集計ジョブを実際に手動実行した場合の挙動

• Resource Workbenchなど、UI Actionの存在だけを確認しリンク先の画面までは開いていない機能

• Time Card Managementでの実績時間入力から actual_hours へ反映されるまでの一連の流れ

• 本番環境での pps_resource ロール設計・大量ユーザーへの一括付与の運用

• Multicurrency・TeamSpace・Predictive Intelligence for PPMなど、未導入のPPM関連プラグインとの組み合わせ

関連記事

• 前提知識：SLAが土日を飛ばす理由：営業時間（cmn_schedule） … Resource Planの planned_schedule が参照する稼働カレンダーの仕組みを扱っています

• 隣接知識：taskテーブル：ITSM全プロセスの共通の親 … resource_plan.top_task が参照する Planned task や、task が参照する Task の継承構造を整理しています

• 同じ「誰が・いつ」を扱う別の仕組み：ServiceNowの深夜のアラートは誰が受ける？ On-Call Scheduling（cmn_rota）の当番表を実機で読む … ローテーション型の当番管理と、プロジェクト型の資源割当を見比べる材料になります