ServiceNowのProject Portfolio Management（PPM）の開発設計書 - テーブル・ロール・状態・自動化・UI
PPMを自社に入れると決めたあと、開発者が最初に欲しくなるのは設計書です。OOTBのアプリケーションに付いてくるのは機能の説明書までで、設計書は自分で起こすことになります。本書は、Australia PDIへ導入したPPM Standardの実装を読み取り、基本設計書の章立てで書き起こしたものです。標準がどう設計されているかを章ごとに確認し、自社で変える箇所だけを決められる形にしました。
検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo）をデモデータ込みで導入済みです。設定は変更していません
PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。個々のプロジェクトを管理するだけの仕組みではありません。思いつきの受付から選別、実行、投資判断までを1つの製品でつなぎます。ServiceNowではアイデア（Idea）、需要（Demand）、プロジェクト（Project）、資源（Resource）、予算（Cost・Benefit）が別々のテーブルに分かれ、それぞれ違う設計思想で作られています。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
⑫開発設計書（有料300円）（この記事）
1. はじめに
1.1 本書の目的と位置づけ
本書は、PPM Standardを既定のまま導入した状態から設計内容を起こした基本設計書です。これから作るシステムの設計書と違い、すでに動いている実装を読んで書いています。用途は2つあります。1つは、標準がどこまでを用意しているかを確かめ、自社で作り込む範囲を決めることです。もう1つは、標準の設計を変えると決めたときに、影響がどこへ及ぶかを見積もることです。
章の並びは次のとおりです。2章で全体の方式、3章で機能を扱います。4章から10章では、画面からパラメータまでの設計項目を1章ずつ並べました。11章に変更禁止事項、12章に設計判断のチェックリストを置いています。各章は一覧表を先に示し、そのあとで個別の定義や方針を書くという順で並べています。
図の色は章の性格を表します。濃紺が本書の中心となる機能設計、水色が構造を決める章、緑が挙動を決める章です。紫は人の触る面を扱う章、橙は導入判断で必ず読む章になります。
PPM Standardの導入がテーブルやACLにどれだけ影響するかを事前に見積もりたい場合は、プラグインを入れると何が変わる？ 影響調査でチェックする27か所で紹介した手順が使えます。
1.2 対象範囲
対象は、PPM Standard（com.snc.financial_planning_pmo）が導入する7つのモジュールです。
Idea … 案を受け止める
Demand … 実行するかを選別する
Project（Project Taskを含む）… 計画してタスクへ分解する
Program … 複数のProjectを束ねる
Portfolio … 投資テーマ単位で判断する
Resource … 人を配る
財務（Cost PlanとBenefit Plan）… 金額を配る
対象外は、画面そのものの操作性と、製品固有の運用導線です。ワークスペースとワークベンチの使い勝手、Idea Portalからの投稿導線、TeamSpace専用のロール体系は本書の外に置きました。画面の種類は、モジュールのリンク先URLから判別したところまでになります。
1.3 前提条件と制約
前提は3点です。Australia PDIへPPM Standardをデモデータ込みで導入した状態であること、本書のためにプロパティやビジネスルールを変更していないこと、記述はすべて導入直後の既定値に基づくことです。
記述の性格も分けています。継承元と選択肢の値、件数は実機で確認した事実です。既定値と公式のhintも同じく実機から取りました。「標準はこういう思想で設計している」という記述は、実装の構造から筆者が読み取った解釈になります。各節の末尾に置いた設計指針は、その解釈を前提にした提案です。確認していない範囲は、末尾の「検証範囲とおことわり」にまとめました。
1.4 用語定義
本書で使う用語を、案の受付から投資判断までの実行順に並べます。
2. システム概要
2.1 全体構成
PPM Standardを有効化すると、1.2に挙げた7つのモジュールがまとめて入ります。それぞれ別の画面と別のテーブルを持ちますが、土台は共有しています。
7つの関係は、案の受付から投資判断までの一本の流れとして設計されています。Ideaで案を受け止め、Demandで実行するかを選別し、承認されたものをProjectへ変換して計画に落とす流れです。ProjectはProject Taskへ分解され、上位ではProgramが複数のProjectを束ね、Portfolioが投資テーマ単位で全体を見ます。この流れと並走するのが、人を配るResourceと、金額を配る財務の2モジュールです。
図の色は継承パターンを表します。橙はTaskを直接継承して選別の対象になるもの、緑はPlanned taskを継承して期間と進捗を持つもの、青は継承を持たず値を保持するものです。灰色は既定のままだと中身が空になるテーブルで、Resource Aggregate Dailyだけがこれに当たります。
OOTBはモジュールごとに機能を作り分けるのではなく、共通の土台を4つ用意し、各モジュールはその上で必要な部分だけを選ぶという思想で組まれています。土台の中身は、テーブルの継承パターンとロールの階層、そして読み取り判定の集約と、画面と通知の役割分担です。このため自社導入でも、まず4つの土台に対する方針を決め、そのあとでモジュールごとの差分を決めると設計する。モジュール単位で個別に判断すると、同じ論点を7回議論することになります。
2.2 方式設計
PPMの主要テーブルは、継承元が3種類に分かれています。dmn_demandはTaskを直接継承します。pm_projectとpm_project_taskとpm_programはPlanned taskを継承し、pm_portfolioとresource_planとcost_planは継承なしの定義です。
OOTBは、選別の対象と計画して動かす物を、継承のレベルで分けるという思想で作られています。Taskは番号と担当者と状態を持つ最小の作業単位で、Planned taskはそこに開始日、終了日、進捗率を足した中間層です。DemandをTask直継承にとどめたのは、選別の段階で日程と進捗を持たせない判断です。Demandは実行するかを決める対象なので、決まってから工程を刻めば足ります。taskテーブル：ITSM全プロセスの共通の親で見たとおり、Incident・Problem・ChangeもTaskの直接の子です。同じTask直継承でも、ServiceNow 問題管理（Problem）完全ガイドで扱ったproblemは起きた事象へ対応する型で、Demandはこれから実行を選ぶ型という違いがあります。
3つ目の分類が、継承を持たないテーブルです。Portfolioと4つの計画テーブル（Resource Plan、Resource Allocation、Cost Plan、Benefit Plan）が該当します。これらはタスクとして開始も終了もせず、値を保持する器に徹した設計です。期間や進捗の概念を持たせない割り切りにより、Task系の状態遷移やSLAの仕組みを引きずらずに済みます。
例外が1つあります。fiscal_period（会計期間）だけはSchedule Entryを継承します。財務の概念に独自の日付管理を作らず、プラットフォーム標準のスケジュール機構へ相乗りさせた判断です。稼働日と休業日を管理する仕組みはSLAが土日を飛ばす理由：営業時間（cmn_schedule）で扱ったものと同じ土台で、その上に会計年度、四半期、月を表現しています。
自社導入時の設計指針
項目を追加する場合は、選別に使う項目をDemandへ、計画と実績の項目をProjectへ置くと設計する。Demandに進捗率や工数実績のような計画項目を足す設計は、Task直継承という前提と衝突するため対象外とします。独自のエンティティを足すときも、この3分類のどれに当たるかを先に決めると設計する。選別の対象ならTask、計画物ならPlanned task、集計値の器なら継承なしを選びます。pm_projectからPlanned task継承を外す変更は避けてください。日程計算とロールアップの処理が、この継承を前提に組まれています。
3. 機能設計
3.1 機能一覧
PPM Standardが提供する機能を、モジュール単位で7件に整理しました。機能IDは本書での通し番号です。
7件はどれも、2.2で見た3つの継承パターンのいずれかに乗っています。機能ごとに作りが違うように見えても、読み方は共通です。中核テーブルの継承元を確かめ、状態の持ち方を確かめ、自動化とロールを確かめれば、その機能の設計はおおよそ追えます。
3.2から3.7では、モジュールごとに「機能概要」「OOTBの設計方針」「自社導入時の設計指針」の3つを同じ順で記述します。
購入すると何が手に入るか
有料エリアには、3.2以降のモジュール別機能設計7節と、4章から12章までの設計内容が入っています。そのまま仕事に使える成果物は次の3つです。
モジュール別の設計判断シート（12.1）：どのモジュールで何を決める必要があるかを、標準の実装と変えるときの選択肢とセットで14行にまとめた表です。自社の設計会議にそのまま持ち込めます。
拡張ポイントの一覧（12.2）：標準のまま使える部分と自社で作り込む部分を11領域に分け、作り込みの重さの見立てを添えた表です。実装計画の見積もりに転用できます。
変更禁止事項の一覧（11章）：無効化や変更が他の仕組みへ波及するロールやUIアクション、プロパティ、ジョブを12件、対処とセットで並べました。
このほかに7枚の表が入っています。画面とテーブルの一覧、主要フィールド定義、状態と自動化の一覧、ロールとプロパティの一覧です。ここから先を読めば、標準のPPMをそのまま入れるか、どのモジュールのどこを変えて入れるかを、その場で判断できる材料が揃います。
💰 ここから先は有料エリア
