メインコンテンツへスキップ
見出し画像

ServiceNowでPPMを入れるにはどのプラグイン？ PPM StandardをApplication Managerから有効化する手順

    ServiceNow観察日記


    ServiceNowでプロジェクト管理を始めようとApplication Managerを開くと、似た名前のプラグインが3つ並びます。Project Portfolio Suite、Project Management、PPM Standard。どれを押せばいいのでしょうか。答えはPPM Standardの一択でした。残る2つには「ここから有効化するな」と公式の説明文に書かれています。Australia PDIで実際に入れて、押してから使えるようになるまでを確かめます。

    検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo v1.0.0）を導入

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

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

    PPM Standardから入れる。Project Portfolio Suiteを直接押してはいけない

    先に答えを書きます。有効化するのは com.snc.financial_planning_pmo（PPM Standard）です。

    理由は明確です。Project Portfolio Suiteの説明文に、製品自身がこう書いています。

    The Project Portfolio Suite (PPS) plugin activates an integrated set of applications for project portfolio management and IT software development. Only upgrade is allowed for this plugin. Activation should be done through PPM Standard plugin.

    （訳: PPS（Project Portfolio Suite）プラグインは、プロジェクトポートフォリオ管理とIT開発向けの統合アプリケーション群を有効化します。このプラグインはアップグレードのみ許可されており、有効化はPPM Standardプラグインから行う必要があります。）

    「このプラグインはアップグレードのみ許可される。有効化はPPM Standardプラグインから行うこと」。同じ文言が Project Management（com.snc.project_management_v3）にも入っていました。

    引用元: /v_plugin_list.do?sysparm_query=idINcom.snc.project_portfolio_suite,com.snc.project_management_v3


    画像

    紛らわしいのは、PPM Standardの依存関係にPPSが入っていることです。PPSは「自分から入れるな」と言い、PPM StandardはPPSを必要とする。つまりPPM Standardを押せば、PPSは自動的に付いてくるという関係です。

    Application Managerのどこにあるか

    Application Managerは /now/app-manager/home です。


    画像

    上部の「Search your licensed applications and plugins」に入力します。ここで最初のつまずきがありました。

    「PPM」で検索すると本体が出てこない

    検索結果は3つのセクションに分かれます。

    • Store applications … ストアに掲載されているアプリ。サードパーティ製も混ざる

    • Family plugins … ServiceNow純正のプラグイン。PPM Standardはここ

    • ServiceNow products

    「PPM」だけで検索すると、Store applicationsが9件先に並びます。Customer Project Management、SPM Retail、Strategic Spend Tracking for PPM。どれも名前にPPMが入っていますが、目当てのプラグイン本体はさらに下にあります。


    画像

    カードには Plugin id: が表示されます。 ここを見れば確実に判別できます。というのも、Family pluginsの9件には com.snc.financial_planning_pmo（本体）と com.snc.financial_planning_pmo.atf（ATFテスト）が両方並ぶからです。カード名も「PPM Standard」と「PPM Standard - ATF Tests...」で、区別の手がかりは末尾の.atfだけです。

    カードを押すと詳細ページに入ります。URLは /now/app-manager/home/plugin/id/com.snc.financial_planning_pmo/details でした。プラグインIDが分かっていれば、このURLを直接開けます。 検索を経由しなくて済むので、手順書に書くならこちらが確実です。


    画像

    Review Installation Detailsに何が書いてあるか

    Installを押すと確認ダイアログが出ます。ここに書いてある内容が、導入前にいちばん知りたい情報です。


    画像

    上から順に読みます。

    1. 課金の案内が2つ

    This plugin is associated with a for-fee subscription.

    You can view the list of your subscriptions on your production instance.

    （訳: このプラグインは有料サブスクリプションに紐づいています。契約状況の一覧は、本番インスタンス側で確認できます。）

    licensable が true のプラグインには必ずこれが出ます。PDIでは実際に入りますが、本番インスタンスでは契約の対象かどうかを先に確認してくださいという意味です。契約状況は本番側のサブスクリプション一覧で見ろ、と案内されています。

    引用元: /v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo（licensable=trueのプラグインに表示される案内）

    2. Dependencies（Will be installed）が3件


    画像

    3. 読み込まれないファイルの警告

    Some files will not be loaded because these plugins are inactive: Code Signing Signatures

    （訳: Code Signing Signaturesプラグインが無効なため、それに関連する一部のファイルは読み込まれません。）

    これは「Code Signing Signaturesが無効なので、それ向けのファイルは読み込まない」という意味で、正常な案内です。

    引用元: /v_plugin_list.do?sysparm_query=id=com.glide.code_signing.signatures（無効と案内された依存プラグイン）

    4. Installation schedule

    Install now（既定）と Install later が選べます。本番環境では業務時間を外して Install later を選ぶ設計になっています。

    5. Load demo data のチェックボックス

    既定はオフです。 ここを入れるかどうかは後から変えにくいので、判断はこの1回きりだと思って決めます。


    画像

    今回は学習目的なので入れました。デモデータが入ると、プロジェクト64件とそのタスク1,228件、需要108件とアイデア55件が最初から入った状態になります。空の環境で構造だけを見たい場合は、入れないほうが読みやすいという判断もあります。

    完了判定ではactiveフラグを信じない

    Installを押すと画面が「実行中」に変わります。ここからが本題です。


    画像

    完了をどう判断するか。ふつうは画面のメッセージか、v_plugin の active を見ます。ところが実測すると、この2つはまったく別のタイミングでした。


    画像


    画像

    差は28分です。 activeが立った時点で有効になっていたのは、監視していた依存プラグインのうち3件だけでした。ワーカーが消えた時点では6件です。

    つまりactiveフラグを見て「終わった」と判断すると、半分しか入っていない状態で次の作業を始めることになります。 導入直後に影響範囲を数えるつもりなら、ここを間違えると数字が狂います。

    正しい完了判定はこうです。

    1. v_plugin の対象プラグインが active になっている

    2. かつ sys_progress_worker に *PluginManagerWorker が残っていない


    画像

    この2条件を両方満たすまで待ちます。同じことはCIMプラグインをインストールする手順でも起きました。CIMのときは本体がactiveになった裏でATFプラグインがまだ処理中でした。プラグインの規模が大きいほど、この差は開きます。

    依存の連鎖は、3件と書いてあって10件入る

    ダイアログの「Will be installed」は3件でした。実際に有効になったのは10件です。この差はどこから来るのか。

    答えは依存の依存でした。

    PPM Standardが直接必要とするのは3件です。そのうちのPPSが、さらに2件を必要とします。

    • Project Management は Cost Management と Fiscal Calendar を連れてくる

    • Resource Management は Time Card Management を連れてくる

    • PPS 自身も Performance Analytics のコンテンツパックをもう1つ連れてくる

    こうして3件が10件になります。導入を1回で終わらせるための設計ですが、**画面に出ない部分で
    6件が増える**という点は、影響調査の観点で重要です。


    画像

    ダイアログが見せるのは1段目だけです。 2段目から先は画面に出ないので、影響範囲を知りたければ
    v_plugin を導入前後で数える必要があります。

    v_plugin.requires から分かるのは、宣言の範囲までです。PPM Standardのrequiresは7件を宣言していますが、そのうち
    com.snc.financial_planning com.snc.rate_model com.snc.app.widgets com.snc.app_diagnostics_tool
    の4件は v_plugin にレコードそのものがありません。存在しないIDが依存として書かれています。
    それでも rate_model_admin や adt_admin といったロールは増えているので、機能自体は入っています。

    宣言・ダイアログ・実態の3つが、どれも一致しない。 これがプラグイン導入の難しさです。
    スコープの考え方についてはアプリとスコープ：Globalとx_の違い（sys_app）も参考になります。

    押してから31分。何が入ったのか

    31分18秒で完了しました。有効になったプラグインは10件です。


    画像


    画像

    ダイアログが名前を出したのは3件でした。実際に有効になったのは10件です。 この差がどこから来るのか、増えたテーブルやロールが何件なのかはServiceNowにPPMを入れると何が増える？と同じやり方で数えたので、別記事にまとめます。


    画像

    ナビゲーションには新しいアプリケーションメニューが並びます。内訳は次の節で見ます。


    画像

    アンインストールはできるか

    supports_rollback は true でした。仕組みとしてはロールバックが用意されています。

    ただし今回は実行していません。 デモデータを入れた状態で戻したときに何が残るかは確認していないので、「戻せる設計になっている」以上のことは書けません。本番で試す前に、必ず検証環境で確かめてください。

    導入前に記録しておくと、あとで困らないもの

    導入前の状態を記録できるのは、導入前のこの1回だけです。 プラグインを入れたあとで「元は何件だったか」を知る方法は無いので、
    押す前に記録しておきます。実際に記録したのは次の3つです。

    1. 件数のスナップショット

    テーブル定義やフィールド定義、ロールやACLなど、増減が起きそうなテーブルの件数を数えて
    おきます。今回は27項目を記録しました。導入後にもう一度数えて引き算すれば、影響範囲が数字で出ます。

    2. 導入前の画面

    Application Managerのホーム、検索結果、プラグイン詳細ページ。それぞれ導入後は表示が変わります。
    特に詳細ページはInstallボタンが消えるので、撮れるのは押す前だけです。


    画像

    3. プラグインのメタ情報

    v_plugin の version requires licensable supports_rollback has_demo_data を控えます。
    requires は導入後も読めますが、手順書に書くなら押す前の値を根拠にしたほうが確実です。

    この3つを取っておくと、導入後に「何がどれだけ増えたか」を人に説明できます。
    あとから差分を出せるかどうかは、事前に記録した数字の有無だけで決まります。

    本番環境に入れるなら、どう段取りするか

    PDIでの実測をもとに、本番の作業計画に落とすとこうなります。推測を含む設計提案として読んでください。

    事前に決めること

    • 契約の確認。licensable が true なので、サブスクリプションの対象かどうかを本番側で確かめる

    • デモデータを入れるかどうか。本番に業務データを入れることはまずないので、通常はオフ

    • 作業ウィンドウ。PDIで31分かかった処理なので、本番ではそれ以上を見込む

    • 誰が実行するか。プラグインの有効化には管理者権限が要る

    当日の手順

    1. 導入前の件数を記録する（テーブルやロール、ACLやプラグイン）

    2. /now/app-manager/home/plugin/id/com.snc.financial_planning_pmo/details を直接開く

    3. Installを押し、Review Installation Detailsの内容を控える

    4. Install now か Install later を選ぶ

    5. v_plugin.active と sys_progress_worker の両方が完了条件を満たすまで待つ

    6. 導入後の件数を記録し、差分を取る

    Installを押すと進捗ダイアログが出て、PluginManagerWorker の進み具合を%で見せてくれます。ここで「Run in background」を押しても処理は止まりません。手順5で長時間待つことになる作業なので、当日の担当者には画面を開いたまま固定しなくてよいと伝えておくと段取りが楽になります。


    画像

    注意したいこと

    Install later を選ぶとスケジュール実行になります。今回は Install now しか試していないので、
    遅延実行したときの挙動は確認していません。

    権限の切り分けを検討しているなら、ServiceNowでadminを配らずに開発させるには？で
    扱ったDelegated Developmentの考え方が近い話になります。ただしプラグインの有効化そのものは
    委任の対象外なので、そこは管理者が実行する前提で組む必要があります。

    入れたあと、何ができるようになるか

    導入直後のナビゲーションには、次のアプリケーションメニューが増えていました。

    • Project … プロジェクト、プログラム、ポートフォリオの一覧と新規作成

    • Demand … 要望の受付と選別

    • Resource … 資源計画の作成と、割当状況（Requested / Confirmed / Allocated）の一覧

    • Ideas … アイデアの登録

    • Project Administration … 管理者向けの設定


    画像

    主要テーブルはこうなっています。

    • pm_project（Project）… 継承元は Planned task

    • pm_project_task（Project Task）… 継承元は Planned task

    • dmn_demand（Demand）… 継承元は Task

    • pm_portfolio（Portfolio）… 継承なしの独立テーブル

    • resource_plan（Resource Plan）… 継承なしの独立テーブル

    プロジェクトが Planned task を継承しているのは、次の3つを最初から持たせるためです。

    • 開始日

    • 終了日

    • 進捗のパーセント

    同じ土台に乗っているものが他にもあります。改善のしくみを扱うServiceNowのCIMとは何か？で見た sn_cim_register も、継承元は Planned task でした。
    継承の全体像はtaskテーブル：ITSM全プロセスの共通の親にまとめています。

    ロールも50件増えていました。プロジェクト管理を誰にどこまで開くかは、この一覧から決めます。


    画像

    接頭辞に規則があります。it_ で始まるものが現行の推奨ロールで、
    resource_ は資源管理側、idea_ はアイデア管理側です。**接頭辞の無い古いロールも残っていますが、
    そちらは説明文で「使うな」と指定されています。** どれを配るかは別記事で扱いますが、
    導入直後に無条件で admin を配って回避するのは避けたいところです。

    そして導入の副作用がひとつありました。 CIMの改善イニシアチブに、これまで出ていなかった
    Create Demand と Create Project のリンクが現れます。CIM側の設定は何も変えていません。
    この話はServiceNowのCIMはIncidentやProblemとどうつながる？の続きとして別記事で扱います。

    実機で気づいたこと

    「どれを入れるか」でいちばん時間を使いました。 テーブル名や機能名は調べれば分かりますが、プラグインの選択は候補が横並びで出てくるぶん迷います。今回の決め手はv_plugin.descriptionに書かれた1文でした。製品自身が説明文の中で運用上の指示を出していることがあります。Application Managerのカードには説明文が途中までしか表示されないので、判断に迷ったらテーブルを直接見るほうが早いと感じました。

    カード名だけで選ぶと本体とATFテストを取り違えます。 com.snc.financial_planning_pmo と com.snc.financial_planning_pmo.atf は、検索結果で隣に並びます。ATFテストのほうを入れても、有効になるのはATFテストだけです。IDの末尾を見るという一手間が要ります。

    31分という所要時間が分かったのは、実際に導入してからでした。 ダイアログに表示されるのは依存プラグインの件数までです。依存が3件と書いてあれば10分程度かと考えますが、実際には10プラグインぶんの処理が走ります。本番の作業計画を立てるなら、依存の宣言数ではなく、検証環境で1回測った実測値を使うべきです。

    デモデータの量は想像より多いものでした。 プロジェクト64件・プロジェクトタスク1,228件・
    需要108件・資源割当1,595件。学習用には十分すぎる量です。一方で、**自分が作ったレコードが
    埋もれる**という副作用もあります。手順を確かめるだけなら、デモデータ無しで入れて、必要な
    レコードを自分で1件ずつ作るほうが構造は見えやすいと感じました。

    用語

    • PPM … Project Portfolio Management。需要・プロジェクト・資源・ポートフォリオを1本につなぐ仕組み

    • PPS … Project Portfolio Suite。PPMを構成するアプリケーション群をまとめたプラグイン

    • Application Manager … プラグインやアプリを入れる画面。/now/app-manager/home

    • Family plugins … ServiceNow純正のプラグイン。検索結果でStore applicationsとは別のセクションに出る

    • supports_rollback … アンインストール（ロールバック）に対応しているかを示すv_pluginのフィールド

    • CICDPluginManagerWorker … プラグイン導入を実行する非同期ワーカー。sys_progress_workerに記録される

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

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

    • Application Manager：/now/app-manager/home

    • PPM Standardの詳細に直接入る：/now/app-manager/home/plugin/id/com.snc.financial_planning_pmo/details

    • PPM関連プラグインの状態：/v_plugin_list.do?sysparm_query=nameLIKEPPM^ORnameLIKEProject Portfolio^ORnameLIKEResource Management

    • 導入したプラグインの記録：/sys_plugins_list.do?sysparm_query=ORDERBYDESCsys_created_on

    • 実行中・完了したワーカー：/sys_progress_worker_list.do?sysparm_query=ORDERBYDESCsys_created_on

    • PPMのアプリケーションメニュー：/sys_app_application_list.do?sysparm_query=titleINProject,Demand,Resource,Ideas

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

    この記事で引用した文面は、ServiceNowが製品に同梱しているプラグインの説明です。次のURLで同じ記述を確認できます。

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

    検証範囲とおことわり

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

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

    • アンインストール（ロールバック）は実行していない

    • Install later を選んだ場合の挙動

    • デモデータを入れずに導入した場合との差

    • 本番インスタンスでのライセンス課金の扱い

    • PPM Standard Multicurrency / TeamSpace / Predictive Intelligence for PPM は導入していない

    • 所要時間はPDIの性能に依存する。本番環境では別の値になる

    関連記事

     
     

    ServiceNow観察日記

     
     
    ServiceNowのPDI（Personal Developer Instance）を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ