ServiceNowのProject Portfolio Management（PPM）の運用設計書 - 役割・体制・レビュー
PPM を導入したのに、需要が審査中のまま何週間も止まっている。プロジェクト管理製品でよく起きる詰まり方です。PPM は Idea から Portfolio まで5つのモジュールが連なる製品で、モジュールごとに状態モデルも担当ロールも違います。ひとつのレビュー会にまとめて回そうとすると、判断の周期が合わずに形だけ残ります。Australia PDI に PPM Standard を導入し、13の現行ロールと状態遷移、通知と Flow の有無を実機で確認したうえで、運用設計書の形に組み立てました。
検証環境：Australia PDI / OOTB / 2026-08-15 確認
PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。個々のプロジェクトを管理する仕組みにとどまらず、需要の受付から実行、資源の配分、投資判断までを1つの製品でつなぎます。プラグイン com.snc.financial_planning_pmo（PPM Standard）を有効化すると使えるようになります。公式の説明は「Installs a set of applications for managing your demands, projects, portfolios, and resources.」（訳: 需要、プロジェクト、ポートフォリオ、資源を管理するためのアプリケーション群を導入する）です。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
⑬運用設計書（有料300円）（この記事）
1. はじめに
誰にどのロールを配り、どの画面を何曜日に開き、どの会議体で何を決めるか。この設計書はそこだけを定めます。前提に置いたのは、実機で確かめた1つの事実です。PPM には人を呼び出す仕組みがほとんど入っていません。主要テーブル向けの通知は4件しかなく、出荷時点ではすべて無効でした。誰かが一覧を開くまで、需要も資源計画も動きません。
同じ型は他のプロセスでも使いました。インシデント運用設計書では、状態モデルと通知の設計を先に決めることで担当者任せの運用から抜け出す型を示しています。Continual Improvement Managementの運用設計書は、その型を CIM に当てはめた例です。
1.1 目的と位置づけ
運用の資料は3種類に分かれます。操作手順書はボタンの押し方を扱い、開発設計書はテーブルやスクリプトの作り込みを扱います。この設計書が扱うのは、どのモジュールを誰がどの頻度で見て判断するかという体制の側です。
3種類を分ける考え方は、PPM 以外の既存プロセスでも共通です。問題管理（Problem）運用設計書や変更管理（Change）運用設計書も、テーブル定義ではなく状態モデルとロールから運用の型を組み立てました。読む人も使う場面も違うため、分けて作るほうが機能します。
PMO やプロセスオーナーが導入直後に迷うのは、機能の使い方より運用の割り振りです。この設計書は、次の4つに答えを出します。
Idea と Demand のどちらから起票させ、選別を誰に任せるか
資源の確定作業を、誰が週次で回すか
節目の連絡が届かない前提で、会議体をいくつ置くか
ポートフォリオの投資判断を、どの周期で下すか
答えは ServiceNow の画面に正解として示されておらず、自社で決める領域です。ただし製品が用意したロール構成と状態遷移からは、設計者が何を想定していたかを逆算できます。
1.2 対象範囲
対象は PPM Standard（com.snc.financial_planning_pmo）で有効になる範囲です。プラグインを1つ押すと連鎖して10プラグインが有効になり、テーブルは215件増えました。この設計書は、そのうち日々の判断に関わる部分だけを扱います。
業務の5モジュール：Idea、Demand、Project（Project Task を含む）、Resource、Program と Portfolio
下支えの3系統：費用と効果の計画、稼働の集計、ロールとプロパティの設定
扱わない範囲も先に決めておきます。画面の操作手順は手順書、テーブルやスクリプトの作り込みは開発設計書の担当です。Time Card Management と Cost Management は連鎖で有効になりましたが、この設計書では運用対象から外しました。アンインストールの手順と、本番環境のライセンス条件も範囲の外です。
1.3 前提条件
運用設計に効く実測を4つ挙げます。どれも導入直後の既定値です。
1つ目は通知です。主要テーブル向けの通知は4件で、対象はすべて Project Task でした。Active はいずれも false です。Demand と Project、Portfolio と Program には、通知そのものがありません。承認、完了、期限超過という節目でも、標準は誰にもメールを送らない設計になっています。
2つ目は Flow です。PPM の主要5テーブルに関係する Flow とサブフローは1件だけで、それも Project workspace navigation という画面遷移の補助でした。Approve の中身は current.state = '8'; current.update(); の2行で、sysapproval_approver のような承認レコードは作られません。承認待ちの一覧を誰かが開いて初めて、Qualified の需要は次へ進みます。
3つ目は Approve の条件式です。dmn_demand の Approve ボタンを開くと、High Risk file という警告バナーが出ていました。
条件式はこうでした。
(gs.hasRole('demand_manager') || gs.hasRole('demand_approver')) && (current.state == -4 || current.state == 10)需要マネージャーと承認者が || で並ぶ条件式です。選別した本人が、そのまま承認も押せます。警告文には「Do not alter this file unless necessary」（訳: 必要がない限り、このファイルを変更しないこと）と書かれています。ServiceNow 自身が、この条件式の書き換えに慎重であるよう求める姿勢です。選別と承認を分けたい組織は、コードを直接変更せず、ロールの配り方で対応する運用方針とします。
引用元: /sys_ui_action_list.do?sysparm_query=table=dmn_demand^name=Approve
4つ目は、その条件式に出てくる demand_manager という名前です。接頭辞の無い旧ロールで、公式の説明には DO NOT USE と書かれているため、使用しない設計方針とする。
同じ書き方の旧ロールは8件ありました。it_demand_manager が role_contains でこれを含むため、現行ロールだけを持つユーザーでも条件は真になります。配るのは it_ の付いた現行ロールに統一し、旧ロールはそのまま残しておきます。
1.4 用語定義
処理の順に並べています。
PPM Standard：ServiceNow でプロジェクトポートフォリオ管理を有効化するプラグイン。id は com.snc.financial_planning_pmo。
idea：思いつきを記録するテーブル。承認や却下のボタンを持たず、Demand へ変換するかどうかだけを決める。
dmn_demand：需要を選別するテーブル。state は9個で、UI アクションで到達できるのは7つ。
demand_approver：Demand の承認だけを担う現行ロール。it_demand_manager も同じ条件で Approve を実行できる。
close_demand：Demand をいつ完了させるかを決める選択肢。既定は Project 作成時。
pm_project.phase：プロジェクトの進み具合を表す5段階。initiating から closing まで。
pm_project.state：Task から受け継いだ6つの状態。完了は phase ではなく Closed Complete で表す。
pm_project_task：プロジェクトの作業単位。期日と担当を持ち、参加者が日々更新する。
resource_plan：資源計画のテーブル。state は13個定義され、実機のデータに出るのは4個。
pps_resource：資源計画の対象者として管理されるための資格ロール。書き込み権限ではなく対象範囲を示すフラグ。
pm_program：複数の Project を束ねる単位。phase は Project と同じ5段階。
pm_portfolio：投資テーマのテーブル。state は define から charter までの4個。
cost_plan / benefit_plan：Project にひもづく費用と効果の計画。会計期間の単位で入力する。
fiscal_period：費用と効果を入力する会計期間。年度の行があって初めて、その年の計画を作れる。
resource_aggregate_daily：資源の日次集計を保存するテーブル。対応するジョブは既定で On Demand。
2. 運用対象のシステム構成
運用の話に入る前に、何がどのテーブルで動いているかをそろえます。PPM は5つの業務モジュールと、それを下支えする3つの系統でできています。
2.1 モジュールごとに、進み方を表す軸が違う
主要テーブルと、運用が開く画面を1枚にまとめました。
進み方を表す軸がモジュールごとに違う点が、あとの設計に効いてきます。Demand は state（9個）、Project は phase（5段階）と Task 由来の state（6個）、Resource は state（13個）です。Idea には進行の状態が無く、Demand 列が埋まったかどうかだけで判別します。全体を見るには、モジュールごとに別の一覧を開くことになります。
2.2 メニュー名とテーブル名は1対1ではなく、開く場所を先に決めておく
体制を配ったあと、担当者が最初につまずくのはメニューです。PPM の導入でアプリケーションメニューは13件増え、主要テーブル向けのモジュールが並びます。ところがモジュール名とテーブル名の対応は、1対1から外れていました。
Ideas メニューには Idea Portal と設定系しか並ばず、idea テーブルの一覧を開くモジュールは0件のため、アイデアの棚卸しは /idea_list.do を直接開くか、Idea Portal から辿る運用にします
Project メニューには All という同名のモジュールが3つ並びます。Projects と Programs、Portfolios という区切り見出しの下にそれぞれ1つずつあり、開く先は別のテーブルです
Resource メニューには Requested と Confirmed、Allocated という絞り込み済みのモジュールが最初から用意されています。資源の確定作業は、フィルタを組まずに開けます
会議体を設計するとき、この差はそのまま効きます。「Project の一覧を見る」と書くだけでは、参加者が Portfolio の一覧を開いてしまうでしょう。議題には Project > Portfolios > All のように、区切り見出しまで含めたメニュー経路を書きます。
2.3 Idea は誰でも登録でき、Demand へ上げるかどうかだけを決める
idea テーブルの有効な UI アクションは6件で、中身は Save と Submit、それに New に限られます。承認や却下のボタンを持たず、記録して次へ渡すだけの作りです。
一覧には Demand 列があり、変換済みかどうかが1列で判別できます。空欄のまま残る行は、まだ選別に上がっていないアイデアです。ここを週次で棚卸しする担当を決めておくと、思いつきが埋もれずに済みます。
2.4 Demand の9状態のうち、UIアクションで到達できるのは7つ
dmn_demand.state は9個定義されています。有効な UI アクション37件のうち、state を書き換えるものは7件でした。Submit demand が Submitted、Screen が Screening、Qualify が Qualified へ進めます。Defer は Deferred、Approve は Approved、Close は Completed、Reset to Draft は Draft へ戻します。
Incomplete（5）と Rejected（7）へ遷移させるボタンは、37件のどれにも見当たらないため、却下の記録を状態として残したい組織は、使い方を自社で決める運用にします。図の左下にあるグレーのノードは、次の図への引き継ぎ点です。Create Project で Project が生まれたところから先は、2枚目の図で追います。
条件列を読むと、押せる状態が明確に分かれています。Screen が使えるのは Submitted のときだけです。Qualify は Submitted と Screening から押せます。Defer が受け付けるのは Submitted と Screening、それに Qualified の3状態でした。Approve は Qualified と Deferred の2状態から実行できます。保留にした需要も、選別に戻さずそのまま承認できる作りです。
2.5 Create Project を押すのは需要マネージャーで、Demand はその場で Completed になる
Create Project の条件はこうでした。
GlidePluginManager.isActive('com.snc.project_management_v3') && gs.hasRole('demand_manager') && (current.type == 'project' && current.project.nil())必要なロールは demand_manager で、プロジェクトマネージャーのロールは条件に出てきません。プロジェクト化のボタンを押すのは需要マネージャーです。状態の条件も入っていないため、Draft のままでも Type が Project なら表示されます。
押した瞬間、Demand は Completed へ自動で進みます。close_demand の既定値が「プロジェクト作成時に閉じる」だからです。この項目の公式説明も確認しました。
The options for closing a Demand are available only when the value of the Type field is set as Project
（訳: Demand を閉じる選択肢は、Type フィールドの値が Project に設定されているときだけ利用できる）
引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=close_demand
2.6 プロジェクトが生まれたあとは、実行と資源の確保が並んで進む
上にあるグレーのノードが、前の図の Create Project につながる接続点です。ここから先はプロジェクトマネージャーと資源マネージャーの手番になります。
Project の phase は initiating から closing までの5段階です。公式説明はこうなっています。
Where the project currently is in its lifecycle (e.g., planning, execution, closeout). Helps track progress and reporting
（訳: プロジェクトがライフサイクルのどの段階にあるかを示す。進捗の追跡と報告に役立つ）
phase を進める専用のボタンは用意されておらず、フォーム上で値を選び直す形のため、誰かが定期的に見て判断して初めて phase が次へ動く運用になります。
資源は、要求する人と確定する人が分かれています。resource_plan.state は13個定義され、実機のデータに現れたのは4個でした。Planning から Requested までがプロジェクトマネージャーの手番で、Confirmed と Allocated が資源マネージャーの手番です。Confirm and Allocate という UI アクションもあり、2段階を一度に進める道も用意されていました。割り当てられる相手は pps_resource を持つユーザーとグループに限られます。
実行が始まったあとの組み替えにも、専用のボタンが並びます。Extend で期間を延ばし、Re-plan で計画を組み直し、Request Change で変更を出し直します。資源計画は確定したあとも動かす前提の作りです。期間の途中で人を入れ替える判断は、資源調整会の議題になります。
Portfolio の state は define から charter までの4個で、Program は Project と同じ5段階の phase を持ちます。この2つは1件ずつ動かす対象ではなく、四半期の単位でまとめて判断する対象です。
引用元: /sys_documentation_list.do?sysparm_query=name=pm_project^element=phase
2.7 完了は state で表し、資源計画の締めまでが1セットになる
phase の最後は closing です。ところが「完了した」という記録は、phase には残りません。pm_project は独自の state 選択肢を持たず、Task から受け継いだ6つの状態を使います。内訳は Pending / Open / Work in Progress の3つです。残る3つが Closed Complete / Closed Incomplete / Closed Skipped という完了系です。閉じるときは phase を closing にしたうえで、state を Closed Complete へ動かします。
Project 側の UI アクションを名前で絞ると、締めのためのボタンが2つ見つかりました。
Complete Resource Plans と Cancel Resource Plans です。プロジェクトを閉じるとき、ぶら下がっている資源計画をまとめて締める操作が Project 側に置かれています。Resource Plan 側にも、同じ意味のボタンがありました。
Allocate / Cancel / Complete / Confirm / Confirm and Allocate / Extend / Re-plan の7種類で絞ると、14件ありました。同じ名前が2件ずつあるのは、フォーム用と一覧用が別レコードだからです。締めを1件ずつ回すか、Project 側から一括で回すか。この選び方は運用ルールで決めておきます。
2.8 完了後は費用と効果を突き合わせ、次の投資判断へ返す
プロジェクトが閉じたあとにも仕事が残ります。見込んだ費用と効果が、実績とどれだけ違ったかの確認です。cost_plan と benefit_plan は Project にひもづき、会計期間の単位で入ります。2枚目の図にある「前の図へ返す」のノードが、この確認結果を次の選別と承認順へ渡す経路です。
一巡を回すかどうかで、PPM の使われ方は変わります。プロジェクトを作るところまでで止めると、投資テーマは増える一方です。完了後の効果確認まで含めて設計すると、Portfolio の判断に実績が乗ります。ここまでが、運用が面倒を見る範囲になります。
2.9 一覧・フォーム以外に4つの画面表現があり、使う役割で使い分ける
一覧とフォームだけで運用を組むと、資源の負荷やポートフォリオの傾向をひとつずつ数える作業が増えます。PPM には一覧とフォーム以外に、ガントとワークスペース、ワークベンチとロードマップという4つの画面表現があります。見せ方も更新の起点も違うため、どの場面でどれを開くかを先に決めておく運用です。
一覧は状態や絞り込み条件で対象を並べ、日常の確認に使う画面です。3.3 で挙げた画面のほとんどがこの一覧にあたります。フォームは1件のレコードを開いて入力し、Approve や Create Project のような状態遷移のボタンを押す画面です。この2つは、ここまでの各節ですでに扱ってきました。
ガント（Planning Console）は、プロジェクトの計画を組み替え、タスクの依存関係を調整する画面です。開発設計書で見たとおり、メニューからの起動は無効化されており、pm_project のフォームに置かれた Related Link『Planning Console』から開く動線だけが有効です。プロジェクトマネージャーが週次のプロジェクト進捗会の前に更新する画面とします。一括での日程変更は通常のフォーム保存と処理のされ方が異なるため、期日の大量変更はガントで行う方針とします。
ワークスペース（Resource Management Workspace）は、資源マネージャーが稼働の偏りを確認する画面です。Overview Dashboard には稼働超過や未活用を示す KPI カードが並び、数字を見てから個別の割当調整に入る動線になっています。
6.3 の資源調整会で色分けを見る画面も、このワークスペースです。KPI カードで全体の偏りをつかんでから一覧で対象者を絞り込む順に開く運用とします。
ワークベンチはワークスペースと役割が違います。ワークスペースが資源マネージャー1人の日常運転席であるのに対し、ワークベンチは複数の候補を並べて比較し、複数人が集まって選ぶ判断の場です。Demand Workbench はリスクと価値の散布図で需要を俯瞰する画面です。
需要選別会とポートフォリオレビューでは、この散布図を需要マネージャーとポートフォリオマネージャーが見比べながら優先順位を話し合う運用とします。Program Workbench はプログラムをカード形式で並べる画面で、複数プログラムの状況をプログラムマネージャーが束ねて見る場です。ポートフォリオレビューの準備として、プログラムマネージャーが月次で確認します。
ロードマップ（CIO Roadmap）は、ポートフォリオをレーンとして横に並べ、配下のプロジェクトを期間の帯で示す画面です。
この画面はポートフォリオとプロジェクトを結ぶ中間テーブルにレコードが無いと、レーンに何も表示されません。四半期の経営報告で使う前に、対象のポートフォリオとプロジェクトが結びついているかを確認する運用とします。経営層と PMO が投資枠の判断で参照する画面です。
6区分は、開く人数と使うタイミングで3つに分かれます。日常の一覧とフォームは担当者が個別に開き、ガントとワークスペースは1人が更新してから会議へ持ち込み、ワークベンチとロードマップは複数人が集まって比較する場で開きます。画面表現ごとに更新する人と見る人を分けておくと、会議で何を確認すればよいかが迷いません。
3. 運用体制
モジュールごとに持ち主を決めます。担当が1人に集まる形でも、決めてあれば運用は回ります。決まっていない状態が、いちばん止まりやすい形です。
3.1 体制図
PPM Standard を導入すると、ロールは50件増えます。そのうちモジュールに担当が対応する現行ロールを13件選び、体制図にしました。
図の色は領域を表します。水色が Idea、オレンジが Demand、緑が Project です。紫が Resource、濃紺が Portfolio と Program、グレーが横断管理を示します。太い矢印は領域をまたぐ受け渡しで、ここが設計の要になります。点線は日々の受け渡しに乗らない支援関係です。
起票の経路は2本あります。アイデア変換の担当が Idea を Demand へ変換する道と、起票者が Demand を直接登録する道です。どちらも需要マネージャーの手元に集まります。需要マネージャーは Screen と Qualify で選別し、承認だけを承認者へ回す形になりました。承認が下りたあと Create Project を押すのも需要マネージャーで、ここで初めてプロジェクトマネージャーへ渡ります。資源マネージャーはプロジェクトマネージャーからの要求を受け、割り当てを確定させます。ポートフォリオマネージャーとプログラムマネージャーは日々の受け渡しには登場せず、束ねた単位で投資を判断する立場です。
3.2 から先は、ここまでの実機確認をもとに組み立てた設計の本体です。有料部に入れた成果物は次のとおりです。
役割定義表：13ロールをモジュール、権限、実務内容、想定人数、兼任の可否で整理した表
画面と役割の対応表：13画面をメニュー経路、URL、開く役割、頻度、そこで分かることで並べた表
運用業務一覧：18のサービスを業務運用、基盤運用、運用管理の3分類で並べた表
運用スケジュール：23の実施項目を日次から導入時までの頻度で並べたカレンダー表
会議体設計：5つの会議体の一覧表と、代表3会議のアジェンダ表、モジュールとの対応図
監視設計表：15の監視対象を画面と絞り込み、頻度、異常のサイン、見る会議体、対応で整理した表
異常時対応表：14の症状を、気づく人と画面、一次切り分け、上げ先、判断する会議体、目安で整理した表
権限管理表：12の手続きを、きっかけ、付与するロール、実施者、確認画面で整理した表
兼任の判定表：13ロールの組み合わせ10通りを、判定と根拠、運用上の条件で並べた表
形骸化の9パターン：モジュールごとの兆候と対策を、担当する会議体にひもづけた表
表が13点、図が1点です。実機で確認した構造を根拠に組み立てた設計案で、自社の運用ルールの叩き台にそのまま使える分量にしています。
💰 ━━━━━ ここから先は有料エリア（¥300）━━━━━
