ServiceNowのPPMはIncidentやCIM（継続的改善管理）などの他モジュールとどうつながる？ プロジェクトを起点にした連携
PPMを導入すると、すでに動いている他のアプリケーションの画面が変わることがあります。その代表例がCIMです。改善案の画面に、これまで無かったCreate DemandとCreate Projectのリンクが現れます。PPM側もCIM側も、設定は導入時のままです。なぜ勝手につながるのかを実機で確かめます。
検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo）を導入済み
PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。デマンド（要望）やプロジェクト、ポートフォリオ、資源計画をひとつのアプリケーション群で管理し、アイデアから実行までを一気通貫で見える化します。プラグイン com.snc.financial_planning_pmo（PPM Standard）を有効化すると使えるようになります。
CIMとは：Continual Improvement Management（継続的改善管理）の略です。ITILでいう継続的改善をServiceNow上で回すためのアプリケーションで、改善案を1件ずつレコードにし、KPIと目標値を付けて、効果が出たかどうかまで追います。プラグイン com.sn_cim を有効化すると使えます。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
⑩連携：IncidentやCIMとのつながり（この記事）
CIMが作れなかったDemandとProjectが、PPMを入れた瞬間にリンクとして現れる
CIMは、現場の「改善したい」という気づきを1件の改善案として記録し、効果を追うためのアプリケーションです。改善の実行そのものは、規模が小さければChangeやナレッジ、大きければプロジェクトとして、別の仕組みに委ねる設計になっています。CIMが改善案を起票できる経路と、Changeやナレッジなどへの作成先を持つことは、CIM連携の記事ですでに確認しました。そこで残っていたのが pm_project と dmn_demand という2つの作成先です。対応するテーブルが存在しないという理由だけで、リンクが表示されていませんでした。
つまりCIMは最初から「Demandを作る」「Projectを作る」という条件式を持ちながら、行き先のテーブルが無いために眠っていたことになります。PPMを導入するという出来事は、CIMにとって使えなかった作成先が有効になる瞬間にあたります。
Australia PDIにPPM Standardを導入し、Create系のUIアクションを数え直すと、導入前は3件、導入後は6件になっていました。増えた2件はどちらも sn_cim_register（改善イニシアチブ）に定義された Create DemandとCreate Project です。CIM側の設定は導入時のままです。テーブルが実在するようになった瞬間、すでに書かれていた条件式が真になっただけでした。
DemandとProjectだけ、なぜリンクが出なかったのか
前回の記事では、CIMIntegrationAPI.getOutboundIntegrationTables() が宣言する6テーブルのうち、実際に画面へリンクが出たのは3つだけだと確認しました。残る rm_story・pm_project・dmn_demand は sys_db_object に実体が無く、gs.tableExists() の判定で自動的に配列から落とされていたためです。
このとき同時に見つけたのが CIMUtil というスクリプトの中身でした。showDemandUIAction と showProjectUIAction という関数名がすでに存在していて、pm_project と dmn_demand を対象にした処理が書かれていました。使われていない関数です。なぜ用意されているのか、その答えを確かめるのがこの記事です。
PPMはServiceNowのどこに位置する仕組みか
ServiceNowのITSMプロセスを線で結ぶと、IncidentやProblemが「起きたことに対応する」層、CIMが「気づきを改善案に変える」層にあたります。この記事で扱うPPMは、その先にある「改善案を実行に移す」層です。改善案が承認されたあと、誰が・いつまでに・いくらで実行するのかを管理する仕組みがPPMだと位置づけられます。
改善イニシアチブは Planned task を継承していて、期間や進捗を持てる作りでした。PPMのProjectも同じ Planned task を継承しています。改善もプロジェクトも「計画してから実行するタスク」という同じ土台の上にあることが、両者をつなぎやすくしている一因だと考えられます。
IncidentからProblem、ProblemからChangeへ、そしてCIMの改善案へという流れは、これまでの記事群で確認してきました。PPMはこの流れの最終段階にあたり、改善案を「誰が、いつまでに、いくらで」実行するのかという資源配分の問いとして扱います。ITSMが起きたことへの対応、CIMが気づきの記録、PPMが実行の管理という三層構造だと整理できます。
PPMとは何をするアプリケーションか
PPM Standardプラグイン（com.snc.financial_planning_pmo）の公式説明にはこう書かれています。
Installs a set of applications for managing your demands, projects, portfolios, and resources. Provides complete visibility from idea to execution. It also helps you plan, track, and manage resources, cost, time, and budget on projects and demands in a portfolio through various workbenches
（訳: デマンドやプロジェクト、ポートフォリオ、リソースを管理する一群のアプリケーションを導入し、アイデアから実行までを完全に可視化します。さまざまなワークベンチを通じて、ポートフォリオ内のプロジェクトとデマンドのリソースやコスト、時間、予算も計画・追跡・管理できます。）
デマンドやプロジェクト、ポートフォリオ、資源管理のためのアプリケーション群を導入し、アイデアから実行までの完全な可視性を提供するという説明です。CIMが「改善案をどう拾うか」を扱うのに対して、PPMは「拾った案をどう実行に移し、資源とコストをどう管理するか」を扱う仕組みだと公式が説明しています。
Ideationに関連するプラグイン「Ideation with PPM」（com.snc.ppm_innovation_management）の説明にも同じ思想が繰り返されていました。
Enables you to manage ideas with full visibility from idea submission to execution. Collaborate with the idea submitter and other stakeholders to Identify ideas with the greatest potential and convert them into different work entities for execution.
（訳: アイデアの提出から実行まで、完全な可視性を持って管理できるようにします。提出者や関係者と協力して最も有望なアイデアを特定し、実行のためのさまざまな作業実体に変換できます。）
アイデアの提出から実行まで見通せるようにし、複数の「作業実体」に変換できるようにする、という説明です。この「変換できる複数の作業実体」にあたるのがDemandとProjectでした。
引用元: /v_plugin_list.do?sysparm_query=idINcom.snc.financial_planning_pmo,com.snc.ppm_innovation_management
Create系のUIアクションは実機で3件から6件に増えていた
導入前のAustralia PDIでは、sn_cim_task と sn_cim_register に定義されたCreate系のUIアクションは3件でした。導入後に同じ条件で数え直すと6件です。増えた2件の条件式は次のとおりでした。
Create Demand（sn_cim_register）: new CIMUtil().showDemandUIAction(current);
Create Project（sn_cim_register）: new CIMUtil().showProjectUIAction(current);
Create Change・Create Knowledge・Create Coaching Opportunityの3件は sn_cim_task 側にすでにありました。Create PA Indicator（PA指標の設計はこちら）も導入前から sn_cim_register 側にあります。変わったのは、新しく現れたCreate DemandとCreate Projectの2件だけでした。
CIM側のコードは無改造のまま作成先が増えた
CIMUtil のスクリプトは、前作で確認した時点のままです。showDemandUIAction と showProjectUIAction は、CIMIntegrationAPI.getValidTables() を呼んで pm_project と dmn_demand が実在するかどうかを判定するだけの単純な作りでした。テーブルが無ければfalseを返して非表示、テーブルができればtrueを返して表示する。PPM Standardを導入した瞬間、CIM側は何も触らずに判定結果だけが変わったことになります。
実際に改善イニシアチブ CIM0001003 を開くと、Related Linksに Create Demand と Create Project が新しく並んでいました。
このとき気づいたのは、Related Linksだけでなく画面下の関連リストのタブまで増えていたことです。導入前はCIM Phases、CIM Tasks、Impacted KPIs、Approversの4つでした。導入後はDemandsとProjectsが加わり6つになっていました。CIMのフォームを作り直すスクリプトはCIM側にありませんから、これもPPM側が持ち込んだ関連リストの定義が、テーブルの実在を条件に表示されるようになった結果だと考えられます。
Demandというテーブルは何のためにあるのか
dmn_demand は日本語画面で「Demand」と表示されるテーブルで、継承元は Task でした。改善イニシアチブや、あとで扱うProjectが Planned task を継承しているのとは異なる出発点です。期間管理の仕組みを持たず、まだ計画が固まっていない段階の器だと分かります。
Dictionary Entriesを開くと、dmn_demand には74件のフィールドが定義されていました。予算や投資分類、優先度、アセスメントなどプロジェクトになる前の検討段階に必要な項目が並んでいます。
Demand の Type には最初から「Continual Improvement Management」がある
dmn_demand.type の選択肢を開くと、5つの値がありました。
Continual Improvement Management
Change
Project
No Conversion（Operational）
No Conversion（Strategy）
CIMが選択肢の1つとして、ChangeやProjectと並んで最初から名指しで用意されていました。Demandの起点がCIMだったことを明示できる値です。新規のDemandフォームを開くと、CategoryとTypeの2つが必須項目でした。
Projectというテーブルは何のためにあるのか
pm_project の継承元は Planned task でした。改善イニシアチブ（sn_cim_register）と同じ継承関係です。開始日・終了日・進捗といった期間管理の仕組みを、CIMの改善イニシアチブと共通の土台からそのまま受け継いでいます。
Dictionary Entriesの件数は64件で、Demandの74件よりやや少なくなっています。参照型のフィールドを見ると、demand という項目がありました。参照先は Demand です。Projectは自分がどのDemandから生まれたのかを、自分のレコードの中に持っていることになります。
Idea・CIM・Demand・Projectは互いをどう参照しているか
この4つのテーブルがどう参照し合っているかを、実際に確認できた参照フィールドだけで図にしました。
一直線に見えますが、矢印の向きはテーブルによって違います。idea.demand はIdeaからDemandへの参照、pm_project.demand はProjectからDemandへの参照、dmn_demand.project はDemandからProjectへの参照です。DemandとProjectは互いを参照し合っていて、Ideaからの参照は一方通行でした。
Demandは起点をどう覚えているか（参照フィールドを実測する）
dmn_demand の参照フィールドをすべて洗い出すと、起点を記録するための項目が複数ありました。
前作でCIM側の起票元を source_table/source_id と parent の二重構造で持っていたと確認しました。同じ発想が、Demand側にも表れています。ただし今度は型が違います。table_name 型の汎用参照ではなく、起点ごとに専用の参照フィールドを1つずつ用意するやり方でした。汎用性より、画面上でどのフィールドが埋まっているかで起点が一目で分かる構成を選んだと読めます。
さらに related_records という項目もあり、sys_documentation の公式説明にはこうありました。
Related task records to this demand such as change, incident, problem, other demand and projects
（訳: このデマンドに関連するタスクレコードです。Change、Incident、Problem、他のDemandやProjectなどが対象になります。）
changeやincident、problemなど5種類の関連タスクを持てるという説明です。ProblemやChangeという単語が公式の説明文に直接出てくることから、DemandはPPM単体で完結せず、ITSMの記録と結びつく前提で設計されていると分かります。
引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=related_records
リンクが出る条件はCIMと同じ仕組み
Create DemandとCreate Projectがいつ表示されるかは、getValidTables() による判定のほかにロールも絡みます。前作で確認した、CIMが改善案を起票できる経路と作成先を判定する仕組みと同じ2段構えです。
操作している人が改善案を起票・実行できるロールを持っていること
開いている画面のテーブルが連携先の一覧に含まれていること
PPM側の実行フェーズに入ると、今度は it_demand_user や it_project_manager といったPPM専用のロールが必要になります。CIMのロールを持っているだけでは足りず、Demandの中身を編集する権限は別途付与する必要があります。
実機で気づいたこと
Create DemandとCreate Projectのレコードは、2018年から変わらずCIMプラグインに同梱されていました。Create Demandの更新日は2018-07-24、Create Projectは2018-07-18です。8年近く「条件式はあるが表示されない」状態のまま置かれていたことになります。機能を先に作っておき、依存するプラグインが入った瞬間にだけ動き出す設計です。プラグイン同士が疎結合であることの裏返しだと感じました。CIM側は自分がPPMと連携する日を待つ必要がなく、PPM側もCIMの存在を意識せずに導入できます。
Related Linksだけでなく、画面下の関連リストのタブまで自動で増えていたのは想定外でした。UIアクションが増えることは前作の内容から予想できましたが、関連リストのタブまでは考えが及んでいません。導入前はCIM Phases、CIM Tasks、Impacted KPIs、Approversの4つ。導入後はDemandsとProjectsが割り込んで6つに増えていて、これは実際に開いて初めて分かったことです。関連リストの表示条件も、同じ gs.tableExists() の考え方で作られているのだと考えられます。
Demandの type 選択肢に「Continual Improvement Management」が最初から用意されていたのは、CIM側からは見えない情報でした。CIMIntegrationAPI を読んでもこの選択肢には触れていません。PPM側の設計者が「Demandの起点はCIMもありうる」と見込んで選択肢を用意し、CIM側の設計者は「テーブルさえできればリンクは出る」という作りにする。双方が相手の実装を知らないまま、テーブルの存在という1点だけで噛み合っているのがこの連携の実体でした。
実務では、Create DemandとCreate Projectをどう使い分けるか
改善イニシアチブを開いたとき、Create DemandとCreate Projectのどちらを選ぶべきかは、規模と承認プロセスで判断するとよいと考えています。
Create Demandを使うべき場面は、投資額や優先順位をポートフォリオ側で検討してほしい改善です。DemandにはDraftからApprovedまで5段階の審査フローがあり、it_demand_manager が優先順位を精査したうえでProjectに進めるかどうかを判断します。改善案の件数が増えてきて、どれを先に実行するかの順位付けが必要になった段階では、Create Demandを起点にする価値が出てきます。
Create Projectを使うべき場面は、すでに規模とスケジュールが明らかで、審査を経ずに実行フェーズへ進めてよい改善です。Demandの審査を飛ばせる分、着手は早くなりますが、投資判断の記録を残さないまま進む形になります。
権限設計も判断材料になります。Demandを作成できるのは it_demand_user、Projectを管理できるのは it_project_manager です。改善イニシアチブを起票できる sn_cim.improvement_requester（CIMの初期設定はこちら）とは別物なので、CIMで起票できる人と、DemandやProjectを作れる人は重ならないことが多いと想定して権限を設計する必要があります。
リソース計画（resource_plan）には、さらに一段階制約があります。公式の説明にはこうありました。
Only users with pps_resource role can be managed through resource management
（訳: pps_resourceロールを持つユーザーだけが、リソース管理の対象として扱えます。）
pps_resource ロールを持つ人だけが、稼働率を管理する対象に選べます。抜け漏れが起きやすい設定です。Projectの担当者を稼働率で管理したいなら、先にこのロールを配る作業が要ります。
引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=user_resource
PPMはCIMより一回り大きいプラグインだった
PPMを入れるかどうかを判断する材料として、CIMとの規模比較を残しておきます。Australia PDIで実測した増分は、テーブル定義でCIMの3.2倍、ACLで3.8倍でした。規模がまるで違います。
CIMは「改善案を1件記録して効果を追う」という狭い範囲のアプリケーションでしたが、PPMは資源管理・コスト管理・タイムカード管理まで連れてくる10個のプラグインの集合体です。実際に導入ダイアログが「入る」と示したのは3件だけで、残り7件は連鎖的に有効化されていました。画面の説明だけを見て導入すると、実際に増える範囲を見誤ります。導入前に影響範囲を知りたい場合は、テスト環境で先に有効化し、前後の差分を取ってから本番へ展開する進め方をおすすめします。
用語
Idea（アイデア） … Demandの前段階にあたる着想。テーブルは idea
Demand（デマンド） … 実行するかどうかをまだ審査している要望。テーブルは dmn_demand
Project（プロジェクト） … 承認され実行フェーズに入った作業。テーブルは pm_project
改善イニシアチブ（Improvement Initiative） … CIMにおける改善案1件。テーブルは sn_cim_register
Planned task … Project・Program・改善イニシアチブが共通で継承する、期間管理を持つタスクの親
PPM Standard … この記事で導入したプラグイン。com.snc.financial_planning_pmo
自分の環境で確認するときのURL
インスタンスのURLに続けて開いてください。
Create系UIアクション（導入後）：/sys_ui_action_list.do?sysparm_query=tableINsn_cim_task,sn_cim_register^nameSTARTSWITHCreate^ORDERBYtable
Demandの参照フィールド：/sys_dictionary_list.do?sysparm_query=name=dmn_demand^internal_type=reference^ORDERBYelement
Projectの参照フィールド：/sys_dictionary_list.do?sysparm_query=name=pm_project^internal_type=reference^ORDERBYelement
Demandのtype選択肢：/sys_choice_list.do?sysparm_query=name=dmn_demand^element=type
改善イニシアチブのフォーム：/sn_cim_register_list.do
アプリメニューからは Demand > All、Project > All からも一覧に移動できます。
引用した公式説明を自分で開く
この記事で引用した説明文は、ServiceNowが製品に同梱しているプラグインとフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=idINcom.snc.financial_planning_pmo,com.snc.ppm_innovation_management
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINdmn_demand,pm_project,idea^hintISNOTEMPTY
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHit_^ORDERBYname
検証範囲とおことわり
Australia PDIにPPM Standard（com.snc.financial_planning_pmo）を導入した直後の状態で確認しました。デモデータは投入済みで、CIM側・PPM側とも設定は導入時のままです。記事中の件数と挙動はこの環境のものです。
確認していない範囲は次のとおりです。
Demandの審査フロー（Screening〜Approved）を実際に1件流す操作
Project側のリソース計画・コスト計画の入力操作
pps_resource ロールを付与した場合の画面の変化
本番環境での権限設計（PDIは管理者権限で操作しているため、ロールごとの見え方は条件式と公式説明から読み取ったもの）
PPS（Project Portfolio Suite）を単独で有効化した場合の挙動
関連記事
前提知識：ServiceNowのCIMはIncidentやProblemとどうつながる？ … 起票経路と作成先の考え方と getValidTables() の仕組みはこの記事が前提になっています
次に読む：ServiceNowのCIM（継続的改善管理）とは何か？ … 改善イニシアチブがPlanned taskを継承する理由をここで整理しています
実務編：taskテーブル：ITSM全プロセスの共通の親 … DemandがTask直継承、ProjectがPlanned task継承という違いの前提になる話です
