ServiceNowのPPMでつまずく点と直し方：実機で再現して確かめる

2026年8月15日 16:08

PPM Standardを導入し、Demand・Project・Resourceを実機で1件ずつ動かしていく過程で、「画面どおりに進めたのに想定と違う」という場面に何度も遭遇しました。検索しても本体が見つからない、通知を有効にしたつもりでも来ない、ボタンが本来止めるべき場面でも押せてしまう。原因はどれも実機で特定できています。この記事は、それぞれの症状に対して同じ状況に遭遇した読者がすぐ切り分けられる手順として、原因と直し方をまとめたものです。

検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo）をデモデータ込みで導入した状態を対象にする

PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。要望（Demand）を受け付けて選別し、承認したものをプロジェクト（Project）にして、人と費用を割り当て、ポートフォリオ単位で投資判断をする。ここまでを1本につなぐアプリケーション群です。

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

つまずきは「見た目の判断基準」と「実装が公開していない情報」に集中する

10件を並べると、原因のパターンは2種類でした。

1つ目は、画面が見せる情報だけで判断すると早すぎる、または過小評価するケースです。プラグインのActiveフラグ、Review Installation Detailsダイアログの依存件数、DO NOT USEと書かれていないロールの活性状態。これらはどれも「見えている値」と「実際の状態」がずれています。

2つ目は、実装は正しく動いているのに、その動作条件が画面のどこにも書かれていないケースです。Create ProjectがDraftから押せること、Demandが自動でCompletedになること、通知がすべて無効で出荷されていること。設定ミスではなく、標準の挙動です。

この2つのパターンを軸に、実機で確認できた10件を1つずつ見ていきます。

Application Managerで「PPM」を検索しても本体が出ない

症状：Application Manager（/now/app-manager/home）の検索欄に「PPM」と入力しても、目当てのプラグインがすぐには見当たりません。

原因：検索結果は「Store applications」「Family plugins」「ServiceNow products」の3セクションに分かれています。「PPM」だけで検索すると、Store applications（サードパーティ製を含むストア掲載アプリ）が先に9件並びます。目当ての本体があるのは、その下のFamily pluginsセクションです。さらに「PPM Standard」で絞り込むと、本体とATFテスト版（IDの末尾が.atfかどうかで区別）の2枚のカードが並び、名前も似ているため取り違えやすくなります。

直し方：カードのPlugin id欄を確認します。末尾に.atfが付いているかどうかで見分けられます。プラグインIDが分かっているなら、検索を経由せず/now/app-manager/home/plugin/id/com.snc.financial_planning_pmo/detailsを直接開くほうが確実です。手順書にはこの直リンクを書いておくと、次に同じ作業をする人が検索で迷わずに済みます。

Activeになった直後は、まだ数字が合わない

症状：プラグインの管理画面がActive表示に変わった直後にテーブルやロールを数え始めると、増えているはずの件数が届いていません。

原因：v_plugin.activeが立つタイミングと、裏側で動くCICDPluginManagerWorker（sys_progress_worker）が完了するタイミングは別です。今回のPPM Standard導入では、Installを押してからv_plugin.activeになるまでが186秒、ワーカーが消えるまでが1,878秒（31分18秒）でした。差はおよそ28分です。activeになった時点で有効だった依存プラグインは監視対象のうち3件だけで、ワーカーが消えた時点では6件でした。

直し方：完了判定は2条件をどちらも満たすまで待ちます。

v_pluginの対象プラグインがactiveになっている
sys_progress_workerから*PluginManagerWorkerが消えている

/sys_progress_worker_list.do?sysparm_query=nameLIKEPluginManagerWorker^ORDERBYDESCsys_created_onを開けば、ワーカーの状態履歴を確認できます。プラグインの規模が大きいほどこの差は開くので、影響調査の着手前に必ず確認します。

ダイアログの「Will be installed」3件を鵜呑みにすると影響範囲を見誤る

症状：Review Installation Detailsダイアログには依存プラグインが3件としか書かれていないのに、導入後に数え直すと10件のプラグインが有効になっています。

原因：ダイアログが表示するのは、PPM Standardがrequiresに直接書いた相手だけです。そのうちのProject Portfolio Suite自身がさらにproject_management_v3 resource_managementなどを必要とし、それらがさらにCost ManagementやFiscal Calendarを連れてきます。依存の依存は、導入前の画面には出てきません。v_plugin.requiresの宣言も7件でしたが、そのうち4件（com.snc.financial_planning com.snc.rate_model com.snc.app.widgets com.snc.app_diagnostics_tool）はv_pluginにレコードそのものが存在しませんでした。宣言・ダイアログ・実測の3つの数字が、どれも一致しません。

直し方：ダイアログの表示件数を影響範囲の全部だと思わないことです。本番導入前に検証環境で一度実際に入れて、v_pluginを導入前後で数え直す作業が必須です。/v_plugin_list.do?sysparm_query=active%3Dactive%5EORDERBYnameで現在有効なプラグイン全体を確認できます。同じ「前後の件数を突き合わせる」やり方はServiceNowでプラグインを入れると何が変わる？影響調査でチェックする27か所にまとめています。

通知を有効にしたつもりでも、1通も来ない

症状：承認や完了、期限超過といった節目でメールが来るはずだと考えて運用を始めても、実際には1通も届きません。

原因：PPMの主要テーブル（pm_project dmn_demand pm_portfolio pm_program resource_plan cost_plan benefit_plan idea）を対象にした通知は4件だけで、しかも4件ともActive=falseで出荷されています。加えてこの4件はpm_project_task（Project Task）だけを対象にした、割当や着手などの通知です。DemandやProjectといった上位テーブルには、通知が1件もありません。

導入前後の差分を見ても、通知の増加はわずか10件（うち主要テーブル向けは4件）です。一方でレポートは+145件、ダッシュボードは+8件、インジケータは+54件増えています。PPMは「知らせて呼び込む」より「画面を見に行かせる」設計だと分かります。

直し方：使いたい通知だけを個別にactive=trueへ変えます。承認・完了・期限超過のような上位テーブルの節目を知らせたいなら、既存4件のテンプレート構造が土台に使えます。対象の確認先は/sysevent_email_action_list.do?sysparm_query=collectionINpm_project,pm_project_task,dmn_demand,pm_portfolio,pm_program,resource_plan,cost_plan,benefit_plan,ideaです。通知定義が有効でも実際には飛んでいないケースがどれだけあるかは、ServiceNowの標準通知403件、実際に飛んでいるのはどれ？で棚卸しをしています。

Resource Planに人を追加しようとしても、候補に出てこない

症状：Resource Planの新規作成画面で担当者を検索しても、追加したい人がリストに出てきません。

原因：resource_plan.user_resource（User）とresource_plan.group_resource（Group）は、どちらもpps_resourceロールを持つ対象しか選べません。フィールドの公式説明にそのまま書かれています。

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

Only users with pps_resource role can be managed through resource management

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

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

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

Only groups with pps_resource role can be managed through resource management

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

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

実機で数えると、アクティブユーザー692人のうちpps_resourceを持つのは186人（27%）でした。プロジェクト管理者にit_project_managerを配っただけでは、その人自身が資源として動かせる対象にはなりません。管理系ロールと資格ロールは別物です。

直し方：資源として動かしたい人・グループへ、管理系ロールとは別にpps_resourceを個別付与します。/sys_user_has_role_list.do?sysparm_query=role.name=pps_resourceで現在の保有者を確認できます。導入初期のタスクとして、対象メンバーへのロール付与を独立したチェック項目にしておくべきです。誰がどのロールを持っているかを追う一般的な方法はServiceNowの権限は誰が持っている？ユーザー・グループ・ロールを中間表からたどるにまとめました。

権限棚卸しで、旧ロールをそのまま配ってしまう

症状：demand_managerやproject_managerのような、見るからにそれらしい名前のロールをそのまま利用者に配ってしまいます。

原因：これらはDO NOT USEロール8件で、descriptionに使用停止が明記されています。それでもロール自体はActiveのまま残っていて、Elevated privilegeもfalseです。説明文を読まなければ、名前だけで選んで配布できてしまいます。

さらにややこしいのは、Screen・Qualify・ApproveなどDemandの主要UIアクションの条件式が、今もgs.hasRole('demand_manager')と旧ロール名を直接参照していることです。実害が出ないのは、現行のit_demand_managerがsys_user_role_containsの設定で旧demand_managerを包含しているためです。it_demand_managerだけを持つユーザーでも、この条件は真になります。同じ包含はit_portfolio_managerとportfolio_managerの間でも確認できました。

直し方：新規に配るのはit_接頭辞の現行ロールです。descriptionLIKEDO NOT USEで対象を検索し、権限棚卸しの一覧から外します。DO NOT USEロール自体を削除・無効化する必要はありません（むしろ避けるべきです）。UIアクションの条件文が今も旧ロール名を参照しており、role_containsによる互換の前提が崩れます。/sys_user_role_list.do?sysparm_query=descriptionLIKEDO%20NOT%20USEで一覧を確認できます。

日次の資源集計が、いつまでも0件のまま

症状：資源の稼働状況を日次で見たいのに、resource_aggregate_dailyを対象にしたレポートやダッシュボードがずっと空です。

原因：resource_aggregate_dailyは実測で0件でした。テーブル自体はPPM Standard導入時に作られていて、空ではありません。対応する集計ジョブGenerate resource aggregate dailiesを確認すると、active=trueながらrun_type=On Demandでした。毎日動きそうな名前を持ちながら、実際は誰かが起動しない限り動きません。週次（43,976件）・月次（10,199件）はどちらもデータが入っているのに、日次だけがこの状態です。

直し方：resource_aggregate_dailyを使ったレポートを作る予定があるなら、Generate resource aggregate dailiesを自社のスケジュールジョブとして起動する運用を組みます。標準のまま放置すると、この集計に依存する画面はずっと空のままです。/sysauto_script_list.do?sysparm_query=nameLIKEresource aggregate dailiでジョブの設定を確認できます。ジョブが本当に動いているかを見分ける方法はServiceNowのスケジュールジョブは本当に動いている？ run_countとnext_actionで見分けるにまとめました。止まっている原因を追う手順はスケジュールジョブが動かないときの調べ方：sys_triggerの読み方で扱っています。

Create Projectが、審査の途中でも押せてしまう

症状：DemandがまだDraftや Submitted の段階なのに、Create Project関連リンクを押すとProjectが作成されてしまいます。しかも押した瞬間、Demand自身がCloseボタンを一度も経由せずCompletedになります。

原因：Create ProjectのUIアクション（dmn_demand、Related Link）の条件を実機で読むと、次のとおりです。

GlidePluginManager.isActive('com.snc.project_management_v3')
&& gs.hasRole('demand_manager')
&& (current.type == 'project' && current.project.nil())

チェックしているのは4つだけです。プラグインが有効か、ロールを持つか、typeがprojectか、そして未変換かどうか。Demandが今どの状態（Draft、Submitted、Screening、Approvedのどこ）にいるかは一切問いません。Screenなど状態を進める側のボタンにはcurrent.state == 2のような条件が付いているのに、Create Projectだけは状態を見ない作りです。UIアクションの条件式の読み方自体はServiceNowのResolveボタンはどこで動く？ UI Actionの表示条件とClient/Server処理で扱ったIncidentの例と同じです。

もう1つの症状はDemandの自動完了です。close_demandの選択肢は3つあり、既定値は先頭の「On creation of project」（on_creating_project）でした。Projectを作成すると、この既定値どおりDemandは自動でCompleted(9)に進みます。Closeボタン（gs.hasRole('demand_manager') && current.state == 8で表示）は用意されているのに、一度も使われません。

直し方：システムがブロックしてくれない以上、「審査を経ずにProjectを作らない」というルールは運用で決めるしかありません。Create Projectを押せるロールを審査完了後にだけ付与するか、条件式にcurrent.state == 8のような状態チェックを追加します。Demand側の進捗もProjectの完了まで追いたい場合は、close_demandを「On closure of project」に変更する余地があります。ただしこの挙動自体は未検証のため、変更前にテスト環境で確認してください。

会計カレンダーの画面を開こうとして404になる

症状：Cost Planの会計期間を設定しようとしてfiscal_calendar_list.doを開くと、404になります。

原因：Fiscal Calendarプラグイン（com.snc.fiscal_calendar）という名前から、テーブル名もfiscal_calendarだと推測しがちですが、そのような名前のテーブルは存在しません。実テーブルはfiscal_periodです。sys_db_objectをfiscalで検索しても、ヒットするのはfiscal_periodとbusiness_calendar_group_fiscalの2つだけでした。

Fiscal Periodの一覧には、FY18からFY28まで11年分・187件がすでに登録されていました。Cost Planのstart_fiscal_periodとend_fiscal_periodはどちらもこのテーブルを参照します。会計カレンダーが自社の会計年度と合っていなければ、Cost Planの期間指定そのものが選べません。

直し方：/fiscal_period_list.doを開きます。継承元を見るとfiscal_periodはSchedule Entryを継承しており、稼働日・休業日を管理するのと同じプラットフォームの機構の上に会計期間が乗っている作りです。自社の決算月が4月始まりでない場合は、既存のFY18〜FY28がそのまま使えるとは限らないため、運用開始前に年度の内訳を確認します。

Ideaの継承元を見ても、手がかりが見つからない

症状：idea（Idea）テーブルの継承構造を調べようとsys_db_objectのExtends table列を見ても、「Idea」としか表示されず、それ以上たどれません。

原因：sys_db_objectのLabel列はideaテーブルにも、その継承元として表示されるテーブルにも、どちらも「Idea」というラベルが付いています。実体をName列で確認すると、継承元はim_idea_coreという別テーブルで、これはTaskを継承しています。

Label列だけを頼りに継承をたどると、「Ideaは独自の継承チェーンを持つ特別なテーブルだ」と誤解します。実際にはTask系の見慣れた仕組みに乗っていて、11段階の状態（Draft、Submitted、Under Reviewなど）もim_idea_core側の定義です。

直し方：テーブル一覧を読むときは、Label列だけでなくName列も必ず確認します。/sys_db_object_list.do?sysparm_query=nameINidea,im_idea_coreで2テーブルを並べて見比べられます。同じラベルを持つテーブルをまたぐ継承は、PPMの中でもここだけの作りでした。Task系の継承構造そのものはtaskテーブル：ITSM全プロセスの共通の親で確認した仕組みと同じです。

実機で気づいたこと

10件を1つずつ潰していく過程で、症状を追うだけでは見えてこない共通点が見つかりました。

「見えている値」を鵜呑みにすると、だいたい早すぎるか少なすぎます。 Activeフラグは早すぎ、ダイアログの依存件数は少なすぎ、DO NOT USEロールのActive状態は正しいのに意味を読み違えます。PPMは、画面の一次情報だけでは判断を誤りやすい設計になっているという印象を持ちました。理由は推測ですが、依存の連鎖が深く、テーブル同士の関係も複雑なため、1画面にすべてを出し切れないという事情はありそうです。

通知が4件しかない上に全部無効、というのは意図的な設計判断に見えます。 レポート・ダッシュボード・インジケータの増加数と比べると差が際立ちます。メールで知らせるより、ワークベンチやダッシュボードを見に行かせる方向へ製品が舵を切っていると読めました。

Create Projectが状態を見ないのは、最初はバグだと思いました。 ですが同じ設計はDemandの他のボタンにはなく、Create Projectだけが例外です。Screen・Qualify・Approveという審査の型は用意されていても、それを通ることをシステムは強制していません。型はガイドであって、ゲートではありません。この割り切りに気づくまで、しばらく「なぜここだけ緩いのか」を探していました。

実務では何に使えるか

冒頭の一覧表を、そのまま導入チェックリストとして使う想定で読み直します。

導入直後のチェックリストに「見た目より実測」を1項目足す

Activeフラグ、ダイアログの依存件数、DO NOT USEロールのActive表示。どれも見た目どおりに読むと判断を誤ります。導入判定や権限棚卸しの手順書には、「表示されている値をそのまま信じない」という注意書きを添えておくと、同じつまずきを防げます。

Create Projectと close_demand はセットで運用ルールを決める

システムが審査未完了のProject作成を止めてくれない以上、「誰がCreate Projectを押せるか」を審査完了後の担当者に絞る運用が現実的な対策です。あわせてclose_demandの既定値を自社の運用に合わせて確認しておきます。

通知とロールは「有効化リスト」を自分で作る

通知4件・DO NOT USEロール8件は、どちらも標準のままでは気づきにくい設定です。導入直後に「有効化を検討する通知」「配布から除外するロール」をリストアップしておくと、後から「知らなかった」を防げます。

症状から逆算する調査の型を持つ

今回の10件は、どれも「出てこない」「来ない」「押せてしまう」「404になる」という症状から、UIアクションの条件式やフィールドのhint、システムプロパティへ逆算する形で原因にたどり着きました。この型はPPMに限らず、他のアプリケーションのトラブル調査にも使えます。

用語

pps_resource：Resource Planの対象者リストに載るために必要なロール。管理系ロールとは別に付与する。

DO NOT USEロール：descriptionに使用停止が明記された旧ロール。Activeのまま残り、it_接頭辞の現行ロールにrole_containsで包含されている。

fiscal_period：会計期間を表す実テーブル。「Fiscal Calendar」という名前のテーブルは存在しない。

v_plugin.active：プラグインが有効になったかを示すフラグ。裏側のワーカー完了より早く立つ。

sys_progress_worker：時間のかかる処理の進捗を管理するレコード。プラグイン導入の完了判定に使う。

close_demand：DemandをどのタイミングでCompletedにするかを決める選択肢。既定は「Project作成時」。

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

自分のインスタンス名に続けて開きます（PPM Standardの導入が前提です）。

PPM Standardの詳細に直接入る：/now/app-manager/home/plugin/id/com.snc.financial_planning_pmo/details
実行中・完了したワーカー：/sys_progress_worker_list.do?sysparm_query=nameLIKEPluginManagerWorker^ORDERBYDESCsys_created_on
現在有効なプラグイン一覧：/v_plugin_list.do?sysparm_query=active%3Dactive%5EORDERBYname
PPM関連の通知：/sysevent_email_action_list.do?sysparm_query=collectionINpm_project,pm_project_task,dmn_demand,pm_portfolio,pm_program,resource_plan,cost_plan,benefit_plan,idea
pps_resourceの保有者：/sys_user_has_role_list.do?sysparm_query=role.name=pps_resource
DO NOT USEロール一覧：/sys_user_role_list.do?sysparm_query=descriptionLIKEDO%20NOT%20USE
日次資源集計ジョブ：/sysauto_script_list.do?sysparm_query=nameLIKEresource aggregate daili
Demandの Create Project 条件：/sys_ui_action_list.do?sysparm_query=table=dmn_demand^name=Create Project
会計期間一覧：/fiscal_period_list.do
idea/im_idea_coreの継承確認：/sys_db_object_list.do?sysparm_query=nameINidea,im_idea_core

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

この記事で引用した説明文は、ServiceNowが製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。

フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name%3Dresource_plan%5EelementINuser_resource,group_resource%5EhintISNOTEMPTY
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=descriptionLIKEDO%20NOT%20USE
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id%3Dcom.snc.financial_planning_pmo

検証範囲とおことわり

Australia PDI（OOTB）で2026-08-15に確認しました。PPM Standardをデモデータ込みで導入した環境が対象です。ここに挙げた10件は、このシリーズの制作過程で実際に実機操作・スクリプト確認を通じて見つけたものであり、想定される全てのつまずきを網羅したものではありません。

設定を変更して直したわけではなく、設定値と実装（UIアクションの条件式、フィールドのhint、プロパティの既定値）から原因を特定した範囲です。通知やDO NOT USEロールを実際に有効化・無効化して動作を確認する作業は行っていません。close_demandを「On closure of project」に変更した場合の実際の挙動、Create Projectの条件式に状態チェックを加えた場合の副作用は未検証です。

pps_resourceの保有率（27%）やDO NOT USEロールの件数（8件）はこの環境の値です。本番環境やバージョンによって数字は変わります。

ServiceNowのCIMでつまずく7つの点と直し方：実機で再現して確かめる — 同じ形式のトラブル対応集。CIMは無効なビジネスルールと必須でない項目が原因の中心だった
プラグイン（v_plugin/sys_plugins）の有効・無効と依存 — requiresフィールドと依存関係の読み方の前提知識
ServiceNowで付けたロールが想定外の権限を含んでいた理由 — DO NOT USEロールがit_系に包含される仕組みの一般形