ServiceNowにPPMを入れると何が増える？ テーブル・ロール・ACLを導入前後で数える
PPM（Project Portfolio Management）を本番に入れる前に、影響範囲を数字で知りたい。そう考えて公式Docsを読んでも、依存プラグインまで含めた増分は書かれていません。Australia PDIでPPM Standardを実際に有効化し、テーブル・ロール・ACLなど27項目を導入前後で数えました。結果はテーブルが+215件、ロールが+50件、ACLが+1,943件。以前CIMを入れたときの3倍を超える規模でした。さらに、確認ダイアログが見せた依存プラグインは3件だけなのに、実際に有効化されたのは10件でした。
検証環境：Australia PDI / OOTB / 2026-08-15 確認。有効化したプラグインは com.snc.financial_planning_pmo（PPM Standard）
PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。要望（Demand）の受付から、プロジェクト化、人と費用の割り当て、ポートフォリオ単位の投資判断までを1本につなぐアプリケーション群です。
PPMには導入するプラグインの選択肢が2つあります。com.snc.project_portfolio_suite（Project Portfolio Suite、PPS）と、com.snc.financial_planning_pmo（PPM Standard）です。PPSの公式説明にはこう書かれています。「Only upgrade is allowed for this plugin. Activation should be done through PPM Standard plugin.」。PPSを直接有効化するのではなく、PPM Standard経由で有効化すると、その裏でPPSが連れてこられる構造です。今回もPPM Standardから入れました。
PPM Standard自体の公式説明はこうです。「Installs a set of applications for managing your demands, projects, portfolios, and resources.」。要望から実行までを1本で見通せるようにする狙いが、続くProvides complete visibility from idea to executionという一文にも表れています。v_pluginのレコードでは、有償契約（licensable）がtrue、区分（license_category）がgeneralと記録されていました。これがどれだけの設定を連れてくるのかを、導入前後の実測で確かめました。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
②影響調査：入れると何が増えるか（この記事）
宣言7件・ダイアログ3件に対し、実際に有効化されたのは10件だった
v_plugin.requiresを見ると、PPM Standardが宣言する依存プラグインは7件です。ところがReview Installation Detailsダイアログが「Will be installed」と表示したのは3件だけでした。導入を終えて数え直すと、実際に有効化されていたのは10件です。宣言・ダイアログ・実測の3つの数字が、どれも一致しません。
濃紺の起点がPPM Standard本体です。緑の3件は宣言・ダイアログ・実測のすべてに出てきます。灰色の4件は宣言はあるのにv_pluginにレコードが無いプラグインです。橙の6件は、宣言にもダイアログにも出ないまま実際には有効化されていました。この橙の存在が、導入前の影響調査を難しくしています。
requiresが宣言する7件、実体があるのはうち3件だけ
v_plugin.requiresの値をそのまま並べると、com.snc.project_portfolio_suite com.snc.financial_planning com.snc.rate_model com.snc.app.widgets com.snc.pa.pmo_dashboards com.snc.app_diagnostics_tool com.snc.ppm_innovation_managementの7件です。プラグインの管理テーブルの仕組みはプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめています。
このうちv_pluginにレコードが存在するのは3件だけでした。financial_planning rate_model app.widgets app_diagnostics_toolの4件は、idを指定して検索してもレコードが見つかりません。それでもrate_model_adminやadt_adminといったロールは実際に増えていました。プラグインとしての実体が無くても、機能そのものは別の形で入ってきているとみられます。
Review Installation Detailsダイアログが見せなかったもの
導入前に開いたダイアログには「Dependencies（Will be installed）」欄があります。並んでいたのは3件です。Performance Analytics - Content Pack - PPM Standard、Project Portfolio Suite、Ideation with PPMでした。画面左側のTechnical detailsにも、同じ3件がidつきで表示されていました。
ダイアログを信じるなら、増えるプラグインは本体を含めて4件のはずです。ところが導入後にv_pluginをidで絞り込んで確認すると、10件がすべてActiveになっていました。
差の6件は次の通りです。
Project Management
Resource Management
Cost Management
Fiscal Calendar
Time Card Management
PA Content Pack - PPS Dashboards
先頭3件はPPSの連鎖で入ります。ダイアログにもrequiresにも名前が出ないまま、Project Portfolio Suiteが連れてきていました。
宣言にあったのに有効化されなかったものもある
Project Portfolio Suite自身のrequiresには、project_management_v3 demand_management resource_management program_managementの4件が書かれています。このうち実際に有効化リストへ出てきたのは、Project ManagementとResource Managementの2件だけでした。
demand_managementとprogram_managementは、v_pluginの有効化リストに現れませんでした。宣言と実測の食い違いは「入っていないのに増えた」だけでなく、「入ると書いてあるのに増えなかった」形でも起きています。この2件だけなぜ現れなかったのかは、今回の調査では確認できていません。
導入前後の27項目、どこが動いたか
依存の話はここまでにして、増減そのものを見ていきます。テーブル定義・フィールド定義など、「設定が増えたら必ずどこかに行が増える」27項目を、REST集計APIで導入前後に数えました。同じ手順は以前CIMでも使ったもので、詳しくはプラグインを入れると何が変わる？ 影響調査でチェックする27か所にまとめています。
増減がゼロだったのはワークフロー（wf_workflow）と公開ページ（sys_public）の2つだけです。残る25項目はすべて増えていました。
テーブルは+215件、CIMのときの3.2倍だった
テーブル定義（sys_db_object）は6,523件から6,738件に増えました。増分は215件です。新しく増えたテーブルをpm_ dmn_ resource_で絞り込むと、Demand・Decisionといった名前が並びます。
以前CIMを導入したときのテーブル増分は67件でした。PPMは同じ「プラグイン1つ」でも規模が3.2倍あります。導入後のテーブル総数は6,738件です。
フィールドは+3,914件、ACLは+1,943件で3.8倍
フィールド定義（sys_dictionary）は3,914件増えました。テーブル1件あたり平均18.2フィールドという計算になります。CIMのときの1テーブルあたり11.5フィールドより多く、PPMのテーブルは1つ1つの構造が大きいと分かります。
ACL（sys_security_acl）は44,689件から46,632件へ、1,943件増えました。CIMのACL増分515件と比べて3.8倍です。ACLは操作（read/write/create/delete）とフィールドの組み合わせで増えるので、テーブル数以上に膨らみます。試しにpm_project dmn_demand ideaまわりだけで数えても198件ありました。仕組みはロールを付けたのに見えない理由：ACL（sys_security_acl）にまとめています。
権限がどの層で決まるかの全体像はServiceNowで権限はどこで決まる？にあります。ACLの増加数は、権限設計の対象がそれだけ広がったという意味です。
ロールは+50件、ただし8件は「使うな」と公式が言っている
ロール（sys_user_role）は780件から830件に増えました。増分は50件です。名前をproject resource portfolio demand ideaで絞り込むと23件がヒットします。
ここに古いロールが混ざっています。次の8件は、descriptionに「DO NOT USE」と明記されていました。
demand_manager
demand_user
portfolio_manager
pps_admin
program_manager
project_manager
project_portfolio_user
project_user
現行の対応ロールはit_が付く名前です。it_demand_managerの説明は「User who manages the inflow, screening and facilitates the prioritization of IT demands」でした。it_project_managerは「User of the project management application, and manager of IT projects」です。名前が似ているだけに、ロール選択の画面でどちらを選ぶかを間違えやすい設計です。
ロールの包含関係で想定外の権限が広がる話はServiceNowで付けたロールが想定外の権限を含んでいた理由にまとめました。増えた50件は、そのまま棚卸しの対象になります。
自動化は作り込まれているのに、通知はわずか4件
ビジネスルールは+923件、スクリプトインクルードは+907件、UIアクションは+352件です。テーブルの増分215件に対して、自動化系の増分だけで2,000件を超えます。1件のインシデントが起票から解決まで13テーブルに書き込むのと同じで、PPMもプロジェクト1件の裏で多くのテーブルが動く設計だと分かります。
一方で通知（sysevent_email_action）は408件から418件へ、10件しか増えていません。PPM主要5テーブルに絞って数えると、通知はわずか4件、Flowは1件でした。ダッシュボード+8、インジケータ+54、レポート+145という増え方と比べると対照的です。PPMは「知らせる」よりも「画面で見て判断する」設計に見えます。
システムプロパティは+101件、既定値ごと読める
システムプロパティ（sys_properties）は3,701件から3,802件へ、101件増えました。このうち76件には公式の説明文が付いています。com.snc.project.calculate_roiの既定値はtrueで、説明は「Calculate ROI percentage based on a project's estimated cost and its net value」です。プロジェクトの見積コストと正味価値からROIを自動計算する設定だと分かります。
com.snc.project.task.max_task_durationの既定値は2600、説明は「Max duration (in days) allowed for a project/project task record」でした。com.snc.resource_management.average_daily_fteの既定値は8です。1人1日あたりの標準稼働時間を表しています。設定を変える前にこの既定値と説明文を読むだけでも、何を触っているかが分かります。
ナビゲータには7つの新アプリと17モジュールが並ぶ
アプリケーションメニュー（sys_app_application）は207件から220件へ、13件増えました。有効になったのは次の7つです。
Demand（プロジェクト側）
Ideas（プロジェクト側）
Project（プロジェクト側）
Project Administration（プロジェクト側）
Resource（リソース側）
Resource management workspace（リソース側）
Service Portfolio Management（リソース側）
主要テーブル向けの有効モジュールは17件でした。ProjectアプリにはAllとCreate New、DemandアプリにはMy DemandsとCreate Newが含まれています。ナビゲータを開いて何が増えたかを確認するなら、この7アプリの並びを見るのが早い方法です。
CIMの連携先テーブルが揃い、UIアクションが3件から6件に増えた
CIM（継続的な改善管理）には、改善案からプロジェクトやDemandへ出て行く導線があります。PPM導入前、この導線に対応するCreate系UIアクションは3件しかありませんでした。pm_projectとdmn_demandのテーブルが無く、CIM側の判定処理がテーブルの存在を確認できずに条件を弾いていたためです。
PPM導入後、この数は6件に増えました。増えたのはsn_cim_registerの「Create Demand」と「Create Project」です。CIM側の設定はそのままです。判定用のスクリプトは最初から書かれていて、テーブルができた瞬間に条件が真になりました。UIアクションのレコード自体はPPM側のプラグインが持ち込んだものです。CIMを先に導入していた場合、この変化は気づきにくいところで起きます。
状態はDemandが9段階、Portfolioが4段階
dmn_demand.stateの選択肢は9個です。
Draft
Submitted
Screening
Qualified
Incomplete
Deferred
Rejected
Approved
Completed
要望を受け付けてから承認するまでの審査プロセスが、この段階数から読み取れます。
pm_portfolio.stateは4個です。
Define
Analyze
Approve
Charter
pm_project自体は独自の状態選択肢を持たず、継承元のPlanned task由来の状態をそのまま使います。phaseフィールドの公式説明は「Where the project currently is in its lifecycle」でした。プロジェクトが計画・実行・終結のどこにいるかを、進捗管理とレポートのために保持するフィールドです。
主要テーブルはPlanned taskを継承する
pm_project（Project）、pm_project_task（Project Task）、pm_program（Program）は、いずれもPlanned taskを継承しています。開始日・終了日・進捗といった項目は、この継承元から受け継いでいます。task管理の共通基盤の仕組みはtaskテーブル：ITSM全プロセスの共通の親にまとめました。
一方でdmn_demand（Demand）はTaskを直接継承しています。Planned taskが持つ期間管理の仕組みを、Demandは持たず、Taskの基本項目だけで構成される作りです。要望の段階ではまだ期間を決めていない設計だと読めます。pm_portfolio（Portfolio）やresource_plan（Resource Plan）は継承なしの独立テーブルでした。
デモデータではpm_project_taskが1,228件、resource_allocationが1,595件でした。1件のプロジェクトに対して複数のタスクと配分がぶら下がる構成が、この件数比から見えます。
実機を見て気づいたこと
ダイアログが3件しか見せない理由を、最初は「表示の省略」だと思っていました。実際に追ってみると省略ではなく、依存の階層が違います。ダイアログが見せるのはPPM Standardが直接requiresに書いた相手だけで、Project Portfolio Suiteがさらに誰を必要としているかは表示の対象外でした。依存の依存は、導入後に実際の有効化リストを数え直して初めて見えてきます。
もう一つ意外だったのは、requiresに名前があるのにv_pluginにレコードが無いプラグインが4件もあったことです。プラグインidをそのまま検索窓に打っても何も出てきません。名前だけが残っていて実体が別の仕組みに統合されているのか、単に廃止されたidが残っているのかは、この調査だけでは分かりませんでした。ロールだけは増えていたので、機能自体は生きていると考えるのが自然です。
本番導入前に何を確認すればいいか
ダイアログの「Will be installed」を影響範囲の全部だと思わないことです。今回の場合、ダイアログが見せた3件の裏に6件が隠れていました。本番導入の判断材料にするなら、検証環境で一度実際に入れて、前後を数え直す作業が必須です。
ACLとロールの増加数は、セキュリティ担当が必ず聞く項目です。「ACLが1,943件増えます、テーブルが215件増えた結果としての自然な増分です」と件数の内訳を示せると、説明が早く終わります。増えたロールの一覧を見せて、使わないロールをどう扱うかを導入計画に書いておくと、後から棚卸しがスムーズに進みます。
増えた50ロールを棚卸しリストにどう足すか
CIM本体の4ロールが管理者・改善マネージャなど4階層だったのと同じように、PPMにもit_project_manager it_project_user it_demand_manager it_demand_user it_portfolio_managerという役割の階層があります。誰にどのロールを配るかは、この現行ロールから設計するのが安全です。
it_接頭辞とpps_resource resource_系だけを絞り込むと、現行ロールは12件でした。
demand_managerのような接頭辞なしの旧ロールは、既存ユーザーに付いていないかを確認したほうがよい対象です。ユーザー・グループ・ロールのつながり方はServiceNowの権限は誰が持っている？にまとめました。付いてきた10プラグイン分のロールは、使う機能から逆算して必要な分だけ絞り込んで配る判断が要ります。
用語
DO NOT USEロール：descriptionに使用を止めるよう明記された旧ロール。現行のit_接頭辞ロールへの置き換えが公式に案内されている。
requires（v_plugin）：そのプラグインが必要とする他のプラグインのid一覧。ここに書かれていてもv_pluginにレコードが無いことがある。
PPM Standard（com.snc.financial_planning_pmo）：PPM導入時に最初に有効化するプラグイン。Project Portfolio Suiteを含む複数のプラグインを連れてくる。
Planned task（planned_task）：計画タスクの基盤テーブル。開始日や終了日などの項目を持ち、Project・Project Task・Programが継承する。
自分の環境で確認するときのURL
自分のインスタンス名に続けて開きます。
有効なプラグイン一覧：/v_plugin_list.do?sysparm_query=active%3Dactive%5EORDERBYname
PPM関連の新規テーブル：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHpm_%5EORnameSTARTSWITHdmn_%5EORDERBYname
PPM関連のロール：/sys_user_role_list.do?sysparm_query=nameLIKEproject%5EORnameLIKEdemand%5EORDERBYname
PPM Standardのrequires：/v_plugin_list.do?sysparm_query=id%3Dcom.snc.financial_planning_pmo
主要テーブルのACL：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHpm_project%5EORnameSTARTSWITHdmn_demand
引用した公式説明を自分で開く
プラグインの説明（引用元）：/v_plugin_list.do?sysparm_query=idINcom.snc.financial_planning_pmo,com.snc.project_portfolio_suite
依存の宣言（引用元）：同レコードのRequiresフィールド
ロールの説明（引用元）：/sys_user_role_list.do?sysparm_query=nameLIKEproject%5EORnameLIKEdemand%5EdescriptionISNOTEMPTY
検証範囲とおことわり
Australia PDI（OOTB）で2026-08-15に確認しました。デモデータを入れた状態でPPM Standardを1つ導入しています。導入先は検証用のPDIで、本番環境ではありません。
数えたのは27種類のテーブルの件数だけです。これ以外にも増えているものはあります。網羅ではありません。システムプロパティとアプリケーションメニューは代表例を挙げただけで、増えた101件・13件のすべてを確認したわけではありません。
demand_managementとprogram_managementがなぜ有効化リストに現れなかったかは確認していません。requiresにレコードが無い4プラグインの実体がどこに統合されているかも未確認です。
アンインストール（ロールバック）は試していません。Project Portfolio Suiteを単体で有効化した場合の挙動も確認していません。
他のプラグインでは依存の構成も増える数も変わります。この記事の数字はPPM Standardの場合であって、一般化はできません。
関連記事
プラグイン（v_plugin/sys_plugins）の有効・無効と依存 — requiresフィールドの読み方の前提知識
ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所 — 同じ手順をCIMで実行した記事
ServiceNowで権限はどこで決まる？ — 増えたACL・ロールがどの層で効くかの全体像
