ServiceNowのProject（pm_project）は何を管理している？計画・進捗・費用を追跡して分かること

2026年8月15日 16:16

プロジェクトの進捗を聞かれて、Excelとメールを見比べてから答える運用になっていませんか。ServiceNowのPPMでは、計画日程・進捗率・費用の3つをpm_projectという1レコードから追えます。Incidentが継承するtaskにはこの3つが無く、Projectだけが最初から持っています。なぜそう作られているのか、Australia PDIの実機で確かめました。

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

PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。要望（Demand）を選別し、承認したものをプロジェクト（Project）にして人と費用を割り当て、ポートフォリオ単位で投資判断をする。この記事はその中心にあるProjectの中身だけを掘り下げます。

PPMの流れの中で、この記事が扱うのは実行を担うProjectです。他のモジュールは別の記事で扱うため、ここではProjectに絞って掘り下げます。

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

Projectは「task」でも「ただのplanned_task」でもない。進捗と費用を最初から持つ3階層目

pm_projectの継承元はtaskを継承したplanned_taskで、これをさらに継承しています。

この2段の継承には意味があります。taskは71フィールドでnumberなどの共通項目を持ちますが、進捗率や計画期間はplanned_task側が受け持つ設計です。planned_taskはstart_date・end_dateなどを足します。pm_projectはさらにproject_manager・phaseなどを足します。Incidentのようにtaskを直接継承するテーブルは、この進捗と費用の土台を持たず、共通項目だけの構成です。

Projectに何を期待して開くか

プロジェクトの状況を尋ねられたとき、担当者が本来知りたいのは3つです。今どのフェーズにいるか、いつ終わる予定か、いくらかかっているか。この3つが別々のファイルに散らばっていると、答えるたびに突き合わせが要ります。

Projectの一覧を開くと、この期待にどう応えているかが分かります。

Project manager・Portfolioなどが最初から列に並びます。プロジェクト64件に共通する項目だけで、担当者が聞かれそうな質問の大半に答えられる設計です。

他の機能と比べたProjectの位置づけは、taskの子がみな同じ土台ではない点に表れる

同じPPMの中でも、テーブルによって継承元が違います。pm_projectはplanned_task経由ですが、dmn_demand（Demand）はtaskを直接継承します。要望の段階では進捗率や計画期間を持たず、プロジェクトに転換して初めてこの土台に乗る設計です。

taskテーブル：ITSM全プロセスの共通の親で見たとおり、IncidentやProblemもtaskの直系です。Incidentのフォーム項目をtask由来かどうかで切り分けた記事と比べると、Projectは同じtaskの子孫でも一段深い場所にいることが分かります。

taskの直系にあるテーブルは、開始日と終了日を持っていても「計画」と「実績」を区別する仕組みまでは持ちません。planned_taskを経由するテーブルだけが、計画値と実績値、そして進捗率をセットで扱えます。

Projectとは、期間・進捗・費用を1本にする仕組みである

Projectの役割は、期間・進捗・費用という3系統の情報を、1つのレコードから追えるようにすることです。担当者が個別に管理していたスプレジートを1画面に集約する、と言い換えられます。

進捗率を表すのはpercent_completeという専用の型です。費用はcost（計画）と後述のロールアップの仕組みでタスク側からも積み上がります。期間はstart_date・end_date・durationの3つが揃っており、実績との差分をあとから追えます。

公式ドキュメントはsys_documentationのhintで何と言っているか

ServiceNowはフィールドごとに公式の説明文（hint）を製品に同梱しています。pm_projectには11件の記述があり、読むとフィールドの狙いがそのまま分かります。

project_managerのhintはこうです。

The person responsible for leading, coordinating, and overseeing the project to successful completion

（訳: プロジェクトを主導・調整し、完了まで監督する責任者）

phaseのhintはこうです。

Where the project currently is in its lifecycle (e.g., planning, execution, closeout). Helps track progress and reporting

（訳: プロジェクトが現在ライフサイクルのどこにいるか（計画・実行・完了など）を示す。進捗管理とレポート作成に役立つ）

primary_portfolioのhintはこうです。

The portfolio that this project supports. Helps execs and PMOs group work by strategic theme or business unit

（訳: このプロジェクトが属するポートフォリオ。経営層やPMOが戦略テーマや事業部単位で業務をグループ化するのに役立つ）

「エグゼクティブとPMOが戦略テーマや事業部でまとめて把握するために使う」と、用途まで書かれています。個人の作業管理ではなく、経営層の報告に使われる項目だと公式が明言しています。引用元：/sys_documentation_list.do?sysparm_query=name=pm_project^elementINproject_manager,phase,primary_portfolio

主要な7フィールドは次のとおりです。

実機のpm_projectは63件のフィールドが継承の上に積み上がる

pm_project自身が固有に持つフィールドは63件です。approved_start_date・phaseなど、経営報告やスケジュール管理に関わる項目が並びます。

この63件は、taskの71件とplanned_taskの58件の上に積み上がっています。実際にどこで何が足されるかを表にしました。

task → planned_task → pm_projectで何が足されるか

work_start・work_endという実績の開始・終了はtaskの段階ですでにあります。planned_taskが足すのは「計画」側の日程と進捗率です。実績はあってもゴールとの差分を測る手段が無かったところに、計画値が加わって初めて「予定通りか」が分かるようになります。

Planned task継承のグループはpm_projectだけではない

planned_taskを継承するテーブルは、pm_projectを含めて9つあります。

Program（pm_program）
Program Task（pm_program_task）
Project Task（pm_project_task）
Improvement Initiative（sn_cim_register）
CIM Task（sn_cim_task）
Coaching Assessment（sn_coaching_assessment）
Decision（dmn_decision）
Requirement（dmn_requirement）

継承関係を図にすると、pm_projectとpm_project_taskがどこに立っているかがつかめます。

ServiceNowのCIMとは何か？継続的な改善管理の仕組みを実機で読むで扱った改善イニシアチブ（sn_cim_register）も、同じplanned_taskの土台に立っています。改善活動とプロジェクトが、期間と進捗を測る仕組みを共有しているという意味です。

フェーズはInitiating→Planning→Executing→Delivering→Closingの5段階で進む

phaseフィールドは5つの選択肢を持ちます。

Initiating
Planning
Executing
Delivering
Closing

フォーム上部のバー表示は、この5値を横並びに描いたものでした（上のフォーム画像を参照してください）。

先に引用したhintのとおり「プロジェクトが今どこにいるかを追跡し、報告に役立てる」ためのフィールドです。ステータス（state）とは別に、ライフサイクル上の位置を示す専用の項目が用意されています。

誰が管理し、どのポートフォリオに属すか

project_managerは、hintのとおり「主導・調整・監督する責任者」です。1件のプロジェクトに1人が紐づき、実行時の判断はこの人に集約されます。

primary_portfolioは戦略テーマや事業部の集約に使う項目です。個々のプロジェクトの進捗だけでなく、ポートフォリオ単位で見たときに投資が計画どおり分散しているかを判断する材料になります。プロジェクト単体の管理と、経営層の投資判断は、同じテーブルの別の列として共存しています。

稼働カレンダーの正体はscheduleフィールドとcmn_schedule

scheduleのhintはこうです。

The working calendar for this project (workdays, holidays, non-working time)

（訳: このプロジェクトの稼働カレンダー（稼働日・休日・非稼働時間））
引用元：/sys_documentation_list.do?sysparm_query=name=pm_project^element=schedule

先ほどのフォーム画像では、既定で「Project Management Schedule」という稼働カレンダーが入っていました。これはcmn_scheduleへの参照です。土日や祝日を計画期間の計算から除くかどうかを、プロジェクトごとに切り替えられます。

稼働カレンダーがどう時間計算に効くかは、SLAが土日を飛ばす理由：営業時間（cmn_schedule）で扱ったSLAの仕組みと同じ土台です。SLAが残り時間から土日を除くのと同じ計算方法で、プロジェクトの計画期間も稼働日ベースで数えられます。

valueとrisk_costで、費用と回収を数字で見る

valueのhintはこうです。

Planned financial return of this project

（訳: このプロジェクトの計画上の財務的リターン（回収見込み額））

risk_costのhintはこうです。

Total cost of all risks associated with this project

（訳: このプロジェクトに関連するすべてのリスクの合計費用）

投資額に対する回収見込みがvalue、リスクが顕在化したときの費用がrisk_costです。この2つと後述の費用ロールアップが組み合わさって、ROIの計算材料になります。引用元：/sys_documentation_list.do?sysparm_query=name=pm_project^elementINvalue,risk_cost

プロジェクトタスクへの分解は、64件のプロジェクトに対して1,228件

pm_project_task（Project Task）もplanned_taskを継承します。テーブル固有のフィールドはわずか6件です（project・resource_assigneeなど）。進捗管理の実体は、ほとんどplanned_taskから受け継いだものです。

プロジェクト64件に対してタスクは1,228件、1件あたり平均19.2件です。top_taskのhintは「Highest level parent task（最上位の親タスク）」で、どのタスクも自分がぶら下がる最上位プロジェクトをたどれます。

タスクの費用が親に積み上がる仕組みはロールアップ

planned_taskのcostフィールドには、こういうhintが付いています。

protected if property is enabled to rollup costs and we have child tasks

（訳: ロールアップを有効にするプロパティがオンで、かつ子タスクがある場合、このフィールドは保護される）
引用元：/sys_documentation_list.do?sysparm_query=name=planned_task^element=cost

「ロールアップを有効にするプロパティがオンで、かつ子タスクがある場合、このフィールドは保護される（手入力できなくなる）」という意味です。フィールドの編集可否そのものが、システムプロパティの値で切り替わります。

そのプロパティがcom.snc.project.rollup.costです。

Enable project cost rollup (estimated and actual) - updating the cost of a project task will update the cost of its parent

（訳: プロジェクトの費用ロールアップ（見積り・実績）を有効にする。プロジェクトタスクの費用を更新すると、親の費用も更新される）
引用元：/sys_properties_list.do?sysparm_query=name=com.snc.project.rollup.cost

既定値はtrueで、実際にオンになっています。タスクの費用を更新すると親の費用が連動して変わるので、担当者が個別タスクのコストを入力していくだけで、プロジェクト全体の費用が自動で積み上がります。

com.snc.project.calculate_roiも既定でtrueです。

Calculate ROI percentage based on a project's estimated cost and its net value

（訳: プロジェクトの見積り費用と正味価値（value）を基にROI（%）を計算する）
引用元：/sys_properties_list.do?sysparm_query=name=com.snc.project.calculate_roi

先に見たvalue（回収見込み）と、ロールアップで積み上がったcost（費用）から、ROIが自動で計算される仕組みです。

期間とタスクの上限は2600日と10年

com.snc.project.task.max_task_durationは2600です。

Max duration (in days) allowed for a project/project task record

（訳: プロジェクト／プロジェクトタスクのレコードに許容される最大期間（日数））

com.snc.project.task.check_date_span_yearsは10です。

Max date span into future or past from the current date for the project/project task record

（訳: プロジェクト／プロジェクトタスクのレコードについて、現在日付から未来または過去へ許容される最大の日付差（年数））
引用元：/sys_properties_list.do?sysparm_query=nameINcom.snc.project.task.max_task_duration,com.snc.project.task.check_date_span_years

2600日はおよそ7年、date_spanは前後10年です。数十年単位の長期プログラムを1つのプロジェクトレコードで表現しようとすると、この上限に触れる可能性があります。分割する設計が前提だと読めます。

プロジェクトを消すとタスクも消える、cascade deleteの挙動

com.snc.project_task_cascade_deleteは既定でtrueです。

When set to true, while deleting a project, project tasks will be deleted with set cascade delete as true

（訳: trueに設定すると、プロジェクトを削除する際に、カスケード削除がtrueに設定されたプロジェクトタスクも一緒に削除される）
引用元：/sys_properties_list.do?sysparm_query=name=com.snc.project_task_cascade_delete

プロジェクトを1件削除すると、ぶら下がる1,228件相当のタスクも連鎖して消える仕様です。falseにすれば、プロジェクトを消してもタスクは残る挙動に変えられます。削除の設計はcom.snc.project_task_cascade_delete1つで決まるので、本番導入前にどちらの挙動にするかを確認しておく価値があります。

UI Actionsから見える設計は、44件の中心がテンプレートと外部連携

pm_projectのUI Actionは44件が有効です。ボタンの並びを見ると、単純なCRUD以上の機能が用意されていることが分かります。

Apply Template・Copy Projectなどがテンプレート化の機能です。Export to MS Project・Import from MS Projectは、Microsoft Projectとの相互運用が組み込まれていることを示します。

Planning Console・Project Diagnosticsなどは、フォーム単体では見えない構造を別画面で可視化する導線です。

条件式にはProjectManagementUtilsというクラスが繰り返し登場します。共通ロジックをどう1か所にまとめるかは、共通ロジックをまとめて呼ぶ（Script Include）で扱った仕組みと同じ考え方です。

Planning Console（ガント）はタスクの帯を掴んで動かす専用画面

前段のPlanning Consoleは、フォームのボタン1つでは終わらない専用画面です。実際にデモデータの「MobiChord Mobility Management」プロジェクトを開き、Related Linkから遷移して確かめました。

開いたのは/now/workspace/project/home/sub/planning/以下のProject Workspaceで、左にWBS（作業分解構造）の行、右に月単位のガントバーが並びます。一覧やフォームでできるのは日付を1件ずつ数値で編集することだけですが、Planning Consoleはタスクの帯をドラッグして期日を動かし、タスク間の依存関係を線で結ぶための場所です。複数タスクの時期が重なっていないかを目で追えるのは、この画面だけの役割です。

ガント操作を支えるプロパティも実機で確認できました。

com.snc.project.gantt.exclude_list（既定値dmn_decision,dmn_requirement）：ガントチャートに表示しないテーブルを指定する
com.snc.project.planning_on_client（既定false）：ガントの計算をサーバ側ではなくクライアント側で行うかどうか
com.snc.project.fire_brs_from_planning_console（既定false）：Planning Console上での保存・削除でビジネスルールを発火させるかどうか

fire_brs_from_planning_consoleの公式説明はこうです。

Enables firing of business rules from planning console, applicable only for update and delete operation

（訳: Planning Consoleからのビジネスルール発火を有効にする。適用されるのは更新・削除操作のみ）

引用元: /sys_properties_list.do?sysparm_query=nameINcom.snc.project.gantt.exclude_list,com.snc.project.planning_on_client,com.snc.project.fire_brs_from_planning_console

3件とも既定はfalseかクライアント側実行寄りです。ガント上でタスクを連続して動かすたびに個々のビジネスルールをサーバ側で走らせると重くなるための配慮とみられます（推測）。

ロールで見る権限設計はit_project_manager・it_project_user・it_pps_admin

現行のロールはit_接頭辞が付きます。it_project_managerのdescriptionはこうです。

User of the project management application, and manager of IT projects

（訳: プロジェクト管理アプリケーションの利用者であり、ITプロジェクトの管理者）

it_project_userはこうです。

User of the IT project management application

（訳: ITプロジェクト管理アプリケーションの利用者）

it_pps_adminはこうです。

Use the it_pps_admin role to allow users to view or modify it project, it demand, it program, it portfolio and timeline visuation preferences/configs/settings

（訳: it_pps_adminロールを使うと、ITプロジェクトやIT要望、ITプログラムやITポートフォリオ、タイムライン表示の各設定を閲覧・変更できるようになる）
引用元：/sys_user_role_list.do?sysparm_query=nameINit_project_manager,it_project_user,it_pps_admin

接頭辞の無い旧ロール（project_manager等）も残っていますが、descriptionは「DO NOT USE; refer it_project_manager」という内容です。ロールを見るときの一般的な切り分け方はロールを付けたのに見えない理由：ACL（sys_security_acl）が参考になります。実際にどこまで権限を含むかはServiceNowで付けたロールが想定外の権限を含んでいた理由で確かめられます。

実機で気づいたこと

percent_complete（進捗率）はtaskの71件には無く、planned_taskで初めて登場します。 Incidentのフォームを思い浮かべながら「進捗何%」という発想自体が、task直系のテーブルには存在しない前提だと気づきました。進捗管理はITSM全体の共通機能ではなく、PPM側だけが持つ設計思想です。

costフィールドのhintに「rollupが有効なら保護される」という一文が入っていたのも印象的でした。com.snc.project.rollup.cost1つでフィールドの編集可否が変わる仕組みは、フォームだけを見ていても分かりません。値が入力できない理由を調べるときは、フィールドのhintと関連するシステムプロパティを両方見る必要があると実感しました。

pm_project_taskの固有フィールドがたった6件しかないのも意外でした。1,228件という規模のデータを支えているテーブルなのに、機能の大半は自分の列ではなくplanned_taskから受け継いだものです。テーブルの力は固有フィールドの数では測れないと分かります。

実務での使い方は、この仕組みをどう設計に活かすか

導入前に決めておくと運用が安定する点をまとめます。

ロールアップの有無は最初に決めます。com.snc.project.rollup.costをオフにすると、costフィールドの保護が外れて手入力できるようになりますが、タスク側の実績と親の数字がずれる余地が生まれます。

削除の挙動も同様です。com.snc.project_task_cascade_deleteをtrueのまま使うなら、プロジェクトの削除は取り消せない操作として運用する前提を関係者に共有しておく必要があります。

primary_portfolioは入力必須にしなくても機能しますが、空のままだと経営層向けの集計から漏れます。運用開始前にポートフォリオの体系を決め、プロジェクト作成時に必ず設定する運用ルールにしておくと、あとから集計し直す手間を避けられます。

用語

pm_project … Project。planned_taskを継承し、計画日程・進捗率・費用を1レコードで持つテーブル
phase … プロジェクトのライフサイクル上の位置（Initiating〜Closing）。stateとは別の項目
planned_task … taskを継承し、start_date・end_date・percent_complete・costなど計画管理の共通項目を持つ中間テーブル
rollup … 子タスクの値を親（プロジェクト）に自動集計する仕組み。com.snc.project.rollup.costで切り替える
cascade delete … 親レコードを削除したときに子レコードも連鎖して削除される挙動

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

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

Projectの一覧：/pm_project_list.do
Projectのフィールド定義：/sys_dictionary_list.do?sysparm_query=name=pm_project^elementISNOTEMPTY
Project Tasksの一覧：/pm_project_task_list.do
planned_taskを継承するテーブル一覧：/sys_db_object_list.do?sysparm_query=super_class.name=planned_task^ORname=planned_task
pm_project関連のシステムプロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.project.

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

この記事で引用した文面は、ServiceNowが製品に同梱しているドキュメントです。次のURLで同じ記述を確認できます。

フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINpm_project,planned_task^hintISNOTEMPTY
プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.project^descriptionISNOTEMPTY
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameINit_project_manager,it_project_user,it_pps_admin

検証範囲とおことわり

Australia PDIに、OOTBの状態からPPM Standard（com.snc.financial_planning_pmo）を導入したデモデータで確認しました。件数と設定値は2026-08-15時点のこの環境のものです。

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

Microsoft Projectとのインポート・エクスポートは実行していない（UI Actionの存在のみ確認）
ROIの計算式そのものは追っていない。calculate_roiがtrueであることのみ確認
rollup.costをfalseに変更した場合の実際の挙動は試していない
本番環境でのライセンス課金の扱い

前提知識：taskテーブル：ITSM全プロセスの共通の親 … pm_projectが最終的に継承する土台を扱っています
同じ土台を使う機能：ServiceNowのCIMとは何か？継続的な改善管理の仕組みを実機で読む … 改善イニシアチブも同じplanned_task継承です
次に読む：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … この記事で多用したフィールド定義の読み方をまとめています