ServiceNowのPPM（プロジェクトポートフォリオ管理）とは何か？ 需要・プロジェクト・資源をどうつなぐのか

プロジェクトの一覧はあるのに、なぜ着手前の要求を管理する場所が別にあるのでしょうか。PPMは、思いついた案を段階的に選別してから初めてプロジェクトにする仕組みでした。中心となる9つのモジュールが何をするのかを、Australia PDIの実機で確認します。

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

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

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

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

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

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

• ⑥Demand：9状態の選別

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

• ⑧Resource：要員の割り当て

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

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

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

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

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

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

PPMは「やるべきか」を決めてから「やる」仕組み。モジュールは問いごとに分かれている

PPMという名前から、ガントチャートを描くツールを想像するかもしれません。実機で構造を追うと、それだけでは足りない仕組みだと分かりました。ServiceNowのPPMは、思いつきを一度Demandで選別してからプロジェクトにする仕組みを持っています。Idea（思いつき）をDemand（需要）として受け付け、実行する価値があるかを選別します。承認されて初めてProject（プロジェクト）に昇格する仕組みでした。

PPMは「やるべきか」だけでなく、複数の問いをモジュールごとに分けて管理しています。

• どうやるか：Project

• 誰がやるか：Resource Plan

• いくらかけて何を得るか：Cost PlanとBenefit Plan

• 全体で見て正しいか：Portfolio

1つの巨大な管理画面ではなく、問いごとに担当を分けた9つのモジュールの集合として設計されている。これがPPMの実体でした。

Ideaが承認されてPortfolioに積み上がるまでの流れ

図の流れを、文章でも説明します。現場の思いつきは、まずIdeaとして記録されました。評価されたIdeaはDemand（dmn_demand）に変わり、需要マネージャーが実行する価値を選別します。承認されたDemandだけがProject（pm_project）に昇格し、Project Task（pm_project_task）という実行単位に分解されます。

関連する複数のProjectはProgram（pm_program）で束ねられ、ProgramとProjectはどちらもPortfolio（pm_portfolio）という投資テーマの器に所属します。これとは別の軸として、DemandとProjectにはResource Plan、Cost Plan、Benefit Planという3つの計画がぶら下がる仕組みもあります。それぞれの計画は、Fiscal CalendarとTime Cardという会計期間・工数の基盤の上に成り立っていました。

PPMを「プロジェクト管理ツール」だと思うと選別の仕組みを見落とす

プロジェクト管理と聞くと、ガントチャートや進捗率を管理する画面を思い浮かべる方が多いはずです。実際、Project（pm_project）にはそうした画面が用意されています。

ですが、Projectの手前にDemandという選別の段階があることが、PPMでいちばんの特徴でした。組織に持ち込まれる要求は、実行できる数よりいつも多く出てきます。全部を同時にプロジェクト化すると、優先順位が崩れ、予算も人も足りなくなるからです。PPMが本来解決したいのは、この「全部はやれない」という前提を仕組みとして先に処理することでした。

だからDemandには9段階の状態があります。代表的な流れはこうです。

Draft（下書き）→ Submitted（提出）→ Screening（審査）→ Qualified（合格）→ Approved（承認）

合格したものだけが、この順で先へ進みます。プロジェクト管理ツールを探している人がPPMにたどり着くと、この選別の層に戸惑うことがあります。実はここがPPMの主役でした。

似た仕組みと比べるとPPMの守備範囲が分かる

ServiceNowには「何かを判断してから進める」仕組みが複数あります。混同しやすいので比べておきます。

ServiceNowのCIMとは何かは「まだ問題になっていないが良くできる余地」を扱う、継続的な改善管理の仕組みです。こちらもPlanned taskを継承する計画物でした。ServiceNow 変更管理（Change）完全ガイドは「決まった変更を安全に通す」実行の仕組みです。選別よりも実施のリスク評価に重心があります。

PPMが扱うのは「やるべきか」という判断そのものです。CIMやChangeが個別のタスクを実行する仕組みだとすれば、PPMはその実行タスクを生み出す前段の判断を担当します。ちなみにアジャイル開発でよく使うStory（rm_story）やScrum関連のテーブルは、このPDIには入っていませんでした。Agile Development系のプラグインを別途有効化しないと使えない範囲で、今回は検証していません。

ServiceNow自身は「idea to execution」の可視化と説明している

PPM Standardプラグイン（com.snc.financial_planning_pmo）の公式説明はこうです。

（訳: 需要やプロジェクト、ポートフォリオと資源を管理するアプリケーション一式が入ります。思いつきから実行までを一気通貫で可視化します。複数のワークベンチを通じて、資源やコスト、時間や予算の計画と追跡を支援する仕組みです。）

「idea to execution」、つまり思いつきから実行までを一気通貫で見せる、と製品自身が説明しています。個々のフィールドの説明にも、この設計思想が表れていました。Projectのphaseフィールドの公式説明はこうです。

（訳: プロジェクトが現在ライフサイクルのどこにいるか（計画・実行・完了など）を示します。進捗の把握とレポーティングに役立ちます。）

primary_portfolioフィールドの説明も分かりやすいものでした。

（訳: このプロジェクトが属するPortfolioです。経営層とPMOが戦略テーマや事業単位で仕事をグループ化するのに役立ちます。）

経営層とPMOが戦略テーマや事業単位で仕事をグループ化するのを助ける、とあります。Portfolioは個々のプロジェクトの集合というより、経営が意思決定するための単位だと公式が言っています。引用元: /v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo（プラグイン説明）、/sys_documentation_list.do?sysparm_query=name=pm_project^element=phase（phase）、/sys_documentation_list.do?sysparm_query=name=pm_project^element=primary_portfolio（primary_portfolio）

9モジュールは実は10個のプラグインとして分かれて実装されている

taskテーブル：ITSM全プロセスの共通の親で見たとおり、ServiceNowはIncident・Problem・Changeを共通のtaskテーブルから分けて設計しています。理由は、扱う問いと責任者と時間軸が違うからです。PPMも同じ理屈でモジュールが分かれていました。

継承構造を見ると、3つの性格に分かれます。

DemandはTaskを直接継承していて、開始日や進捗率を持たず、選別に必要な項目だけで構成されていました。選別対象であって計画物ではないという性格が、ここに出ています。一方Project、Project Task、ProgramはPlanned taskを継承し、開始日・終了日・進捗率を最初から持ちます。Portfolio／Resource Plan／Cost Plan／Benefit Planは継承を持たない、純粋なデータの器でした。

テーブルだけでなく、実装そのものも分かれています。PPM Standardを導入すると、実際には10個のプラグインが連鎖して有効になります。宣言されている依存は7件でした。導入ダイアログが名前を出すのは3件だけです（Project Portfolio Suite／Performance Analytics Content Pack／Ideation with PPM）。実際に有効になったのは10件でした。5つのプラグインが、画面に名前を出さないまま連なって入ります。Project Management／Resource Management／Cost Management／Fiscal Calendar／Time Card Managementです。導入時に何が増えるかを事前に知りたい場合は、別の方法が使えます。プラグインを入れると何が変わる？ 影響調査でチェックする27か所で紹介した手順です。

つまりPPMは、やるべきかを判断するプラグイン、どうやるかを計画するプラグイン、誰がいくらでやるかを管理するプラグインの集合として組み立てられています。1本の巨大アプリというより、問いごとに製品自体が分割されていました。これが「モジュールが分かれている」ことの、もう1つの裏付けです。

9モジュールの早見表

各論に入る前に、9モジュールを一覧にしておきます。以降の節で、この表の項目を1つずつ実機で確かめます。

Ideaは思いつきを最初に受け付けてDemandへ橋渡しするテーブルだった

Ideaテーブル（idea）は、フィールド数が13件と少ない構成です。business_case（説明）やsubmitter（提出者）、demand（変換先のDemand参照）といった最小限の項目だけで構成されています。あえて身軽に作られている、と読めます。

Ideaの役割はただ1つ、思いつきを検討の土俵に乗せることです。有効なUIアクションは6件で、SaveとSubmitが中心でした。承認や状態遷移の複雑な仕組みはIdea自体には無く、demandフィールドで実際の評価をDemandに引き渡します。次のDemandで、初めて「やるべきか」の判断が始まります。

Demandは9段階の状態で「やるべきか」を選別する

Demand（dmn_demand）はTaskを直接継承し、73件の固有フィールドを持ちます。ここでの主役は状態（state）です。

Draft（1）からSubmitted（2）、Screening（3）、Qualified（-4）へと進みます。承認されるとApproved（8）、最終的にCompleted（9）に至ります。途中でIncomplete（5）、Deferred（10）、Rejected（7）に分岐することもありました。9段階のうち、合格ラインを超えたものだけがProjectに昇格します。

一覧のStage列には「Demand Screening」「Project Pending」のような表示が出ます。これはtypeやprojectとの組み合わせから作られる、表示専用の値です。related_recordsフィールドの公式説明はこうです。

（訳: このDemandに関連するタスクレコード（ChangeやIncident、Problem、他のDemandやProjectなど）です。）

引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=related_records

Demandは単体で完結せず、Change・Incident・Problemといった他の業務からも参照される選別の中継点でした。承認されたDemandはprojectフィールドで実際のProjectレコードとつながります。次はそのProjectを見ます。

Projectは承認された仕事を計画し、タスクに分解する

Project（pm_project）はPlanned taskを継承し、63件の固有フィールドを持ちます。開始日・終了日・進捗率という計画物に必要な項目が、最初から揃っています。

フォーム上部にはInitiating／Planning／Executing／Delivering／Closingという5つのフェーズがバーで表示されます。phaseフィールドの公式説明は「プロジェクトが今ライフサイクルのどこにいるか」でした。進捗の把握とレポーティングに使うとされています。

一覧にはPortfolio列があります。どのProjectがどのPortfolioに属しているかが、ひと目で分かります。primary_portfolioフィールドが参照先です。

Project本体には、フォームや一覧とは別にPlanning Consoleというガントチャート専用の画面も用意されています。タスクの帯をドラッグして日程を動かし、依存関係を線で結べるのはこの画面だけです。

Project Taskは計画ではなく実行の単位に絞られている

Project Task（pm_project_task）もPlanned taskを継承しますが、固有フィールドはわずか6件でした。project（親Projectへの参照）とlink（子タスクを持つかどうか）が中心です。Project本体が持つ財務やスコアリングの項目は引き継がず、計画の枠組みだけをProjectから継承して個々の作業をシンプルに保つ役割分担です。

Projectを承認したあとに残る仕事は、誰がいくらでやるかです。次はその2つを見ます。

Programは関連するProjectを束ねて進捗を見る

Program（pm_program）もPlanned taskを継承します。固有フィールドはgoals（目標）やscore（スコア）、related_portfolios（所属するPortfolio）など23件でした。Projectより経営寄りの項目が並びます。

program_managerフィールドの公式説明は「このプログラムの管理者」でした。portfolioフィールドは「このプログラムが属するPortfolio」です。複数のProjectをまとめて1つの投資判断の単位にする、というのがProgramの役割でした。Projectが個別の実行を管理するのに対し、Programはその束を管理します。

Portfolioは投資テーマ単位で全体が正しいかを見る

Portfolio（pm_portfolio）は継承を持たない、純粋なデータテーブルです。固有フィールドも16件と少なく、name・description・portfolio_managerといった基本項目が中心でした。

このPDIには5件のPortfolioがあり、次の事業テーマ単位で分かれていました。

• Application Modernization

• Digital/Business Transformation

• HR

• Product Development

• Sales

stateはDefine（定義）からAnalyze（分析）、Approve（承認）、Charter（憲章）という4段階です。portfolio_managerフィールドの公式説明は「このPortfolioの管理者」でした。activeフィールドの説明は「ホーム画面に追加できるかどうか」です。Portfolioの役目は、個々のProjectの進捗を追うことではなく、テーマ単位で予算を配分してよいかを判断することでした。予算配分の議論を可視化する材料としては、ServiceNow レポート・ダッシュボード完全ガイドで扱ったData VisualizationsとPerformance Analyticsが使えます。

Portfolio向けの専用ワークベンチも、システムプロパティ（com.snc.project.portfolio_workbench.confirm_to_create_project）からは存在が確認できます。ただしこのPDIのWorkspacesメニューには出てこず、画面そのものは検証範囲外でした。

Resource Planは誰がやるかをロールで縛って計画する

Resource Plan（resource_plan）も継承を持たない独立テーブルで、固有フィールドは56件です。user_resource（割り当てるユーザー）とgroup_resource（割り当てるグループ）が中核ですが、両方に共通の制約がありました。

（訳: pps_resourceロールを持つユーザーのみが、資源管理の対象として管理できます。）

引用元: /sys_user_role_list.do?sysparm_query=name=pps_resource

資源計画の対象になるのは、pps_resourceロールを持つユーザーだけです。割り当てられる人は、先にロールで絞られている設計でした。状態は13段階あり、Planning（計画中）からConfirmed（確定）、Allocated（配分済み）、Completed（完了）まで細かく分かれます。

資源管理にはResource Management Workspaceという専用画面もあります。稼働超過や未割当の要求を件数カードで見せる、一覧のグルーピングとは違う切り口の集計画面です。

どのロールがどこまで見えるかは、ServiceNowの権限は誰が持っている？で扱った中間表の考え方がそのまま当てはまります。

Cost PlanとBenefit Planはいくらかけて何を得るかを分けて管理する

Cost Plan（cost_plan）とBenefit Plan（benefit_plan）は、どちらも継承を持たない独立テーブルです。Cost Planは支出、Benefit Planは効果という、対になる2つの財務計画を別テーブルで管理します。

Cost Planのstart_fiscal_period、end_fiscal_periodは、どちらもFiscal period（会計期間）への参照で必須項目でした。ここで初めて、図の下段に置いたFiscal Calendarが実際に使われていることが分かります。会計年度をまたぐ計画は、この参照を介してFiscal Calendarの定義に乗ります。

Benefit Planにはmonetary（金銭的）とnon-monetary（非金銭的）の両方の効果を測る項目があります。measureフィールドの公式説明は「非金銭的な効果をどう測定するかを決める」ものでした。お金だけでなく、効果そのものを測定基準として定義する仕組みが最初から用意されています。

インジケータやレポートで効果を追いたい場合は、ServiceNowのPerformance Analyticsは何を測る？で扱った指標設計の手順が参考になります。

実機を見て気づいたこと

pm_projectは自分の状態選択肢を持っていなかった

Projectの状態（state）がどんな値を持つかを確かめようと、sys_choiceをtable=pm_project、element=stateで絞り込みました。

結果は0件でした。最初はデータの欠落かと思いましたが、Projectは継承元のPlanned taskが持つstateの選択肢をそのまま使っていました。pm_project自身の選択肢レコードを持たないのが正解です。フォーム上で「Pending」「Open」「Work in Progress」と表示されていたのは、この継承元の値でした。phase（5段階）は独自に持つのに、state（進行状態そのもの）はPlanned task任せ。継承構造を実機で追わないと気づけない設計です。

Demandの状態は、Qualifiedだけ値がマイナスだった

Demandの9つの状態を並べると、Qualified（合格）だけが値-4でした。ほかはすべて正の整数です。

• Draft=1／Submitted=2／Screening=3／Incomplete=5

• Rejected=7／Approved=8／Completed=9／Deferred=10

値そのものに意味はなく、選別の記録として振られた番号でした。

なぜQualifiedだけ負の値なのか、公式ドキュメントに明確な説明は見当たりませんでした。選択肢Choice（sys_choice）：ドロップダウンの中身で扱ったとおり、状態の並び順はsequenceで別管理されています。値ではなくsequenceというフィールドが表示順を決めます。それでも実務でスクリプトから状態を判定するときは、この値を決め打ちで書くと将来のバージョンで壊れる可能性があると考えたほうが安全です。

PPMを入れたら、CIM側のボタンまで増えていた

PPM導入の前後でCIM側のUIアクションを数えると、3件から6件に増えていました。増えたのはCreate DemandとCreate Project、それにCreate PA Indicatorです。

CIM側の設定は一切変えていません。CIMUtilというスクリプトにshowDemandUIActionとshowProjectUIActionという条件がもともと書かれていました。参照先のpm_projectとdmn_demandというテーブルが存在しなかったために、条件が働かなかっただけです。PPMを入れてテーブルが出現した瞬間、条件が真になりボタンが現れます。詳しい経緯はServiceNowのCIMはIncidentやProblemとどうつながる？にまとめました。モジュール同士は、思っている以上に静かにつながっています。

実務では何に使えるか

導入前にDemandの選別基準を決めておく

PPM Standardを入れる前に、Demandの選別プロセスをどこまで厳密にするかを決めておくと導入後が楽になります。9段階の状態をすべて使うのか、SubmittedからApprovedへ簡略化するのかは、dmn_demandのstate選択肢（sys_choice）や状態遷移を制御するBusiness Ruleで調整できる範囲でした。

自動化の量も事前に把握しておく価値があります。PPM主要5テーブルだけでビジネスルールが255件、UIアクションが128件動いていました。棚卸しの考え方はBusiness Rule・Script Include・Flowを一括棚卸しする読み取り専用スクリプトがそのまま使えます。

最初に触るモジュールをDemandに絞る

9モジュールを一度に使い始めると、入力項目の多さに現場が疲弊します。実機で見た限り、最初に触るべきはDemandでした。Idea／Resource Plan／Cost Plan／Benefit Planは、Demandで選別する文化が根付いてから広げるのが無理のない順番です。

Portfolioと予算配分の議論は、レポートやダッシュボードが揃ってから始めるほうが説得力を持ちます。PPM導入だけでレポートが145件、ダッシュボードが8件、インジケータが54件増えていました。

まずはServiceNowの標準ダッシュボード28本を全部開いたで紹介した既存の見え方を確認してください。それに乗せる形でPortfolioの数字を育てるのが現実的です。役割ごとに誰が何を担当するかは、上の表を出発点にしてください。

用語

PPM（Project Portfolio Management）：プロジェクトポートフォリオ管理。プラグインはcom.snc.financial_planning_pmo（PPM Standard）。

Demand（dmn_demand）：思いつきを実行する価値があるか選別するレコード。Taskを継承する。

Project（pm_project）：承認された仕事を計画・実行するレコード。Planned taskを継承する。

Program（pm_program）：関連する複数のProjectを束ねる単位。Planned taskを継承する。

Portfolio（pm_portfolio）：投資テーマ単位でProjectやProgramをまとめる器。継承なしの独立テーブル。

Resource Plan（resource_plan）：誰をどれだけ割り当てるかの計画。pps_resourceロールが前提になる。

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

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

• Demand一覧：/dmn_demand_list.do?sysparm_query=ORDERBYnumber

• Project一覧：/pm_project_list.do

• Portfolio一覧：/pm_portfolio_list.do

• Demandの状態別集計：/dmn_demand_list.do?sysparm_query=GROUPBYstate

• 主要テーブルの継承を見る：/sys_db_object_list.do?sysparm_query=nameINpm_project,pm_project_task,dmn_demand,idea,pm_portfolio,pm_program

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

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

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

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINpm_project,dmn_demand,pm_program,pm_portfolio,resource_plan,benefit_plan^hintISNOTEMPTY

• ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHit_

検証範囲とおことわり

Australia PDI（OOTB）でPPM Standardをデモデータ込みで2026-08-14に導入し、2026-08-15に確認しました。

Demand・Projectを実際に1件ずつ作成し、状態を最後まで進める操作は行っていません。テーブル構造、フィールドの公式説明、デモデータの見え方を確認した範囲です。

Multicurrency、TeamSpace、Predictive Intelligence for PPMは導入していません。アンインストール（ロールバック）も試していません。Fiscal CalendarとTime Card Managementは、連鎖的に有効化されたことのみを確認しました。個別の設定画面までは踏み込んでいません。Agile Development（Story/Scrum）系のプラグインは未導入で、比較表では検証範囲外としました。本番環境でのライセンス課金の扱いは確認していません。

関連記事

• taskテーブル：ITSM全プロセスの共通の親 — Demandの継承元を理解する前提知識

• ServiceNowのCIMとは何か？ — 同じPlanned task継承の仕組みとの比較

• ServiceNowでプラグインを入れると何が変わる？ 影響調査でチェックする27か所 — PPM導入前後の影響を自分で測る手順