ServiceNowのPortfolioとProgramは何が違う？ アイデアから投資判断までの上位構造
ServiceNowでプロジェクト管理を始めると、Projectの上にProgramとPortfolioという2つの上位テーブルが出てきます。名前が似ていて、どちらに何を紐づければよいのか最初は迷うところです。答えは継承構造を見れば分かります。 Programは Planned task を継承し、自分自身も開始日から終了日までの期間と進捗率を持つ実行物です。Portfolioは継承を持たない独立テーブルで、実行ではなく投資判断のための棚です。Australia PDIに導入済みのPPM Standardを開き、Portfolio、Program、Ideaの実データからこの違いを確かめます。
検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo）導入後の pm_portfolio / pm_program / idea を対象にする
PPMの階層とは：ServiceNowのPPM（Project Portfolio Management）は、思いつき（Idea）を要望（Demand）に変え、承認したものをプロジェクト（Project）として実行し、複数のプロジェクトをプログラム（Program）で束ね、最終的にポートフォリオ（Portfolio）という投資テーマの単位で経営層が判断する、という構造を持ちます。この記事は上位の3つ、Portfolio、Program、Ideaを扱います。
PPM全体を構成する要素の中で、この記事が扱うのはProgramとPortfolioの2テーブルです（図の濃紺）。IdeaからProject Taskまでの実行側と、要員を受け持つResource Plan、費用対効果を受け持つCost PlanとBenefit Planは、いずれも別記事で扱う部品です。この記事では前提として位置づけを示すにとどめます。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
⑨PortfolioとProgram：投資判断の上位構造（この記事）
継承の有無がそのまま役割を分ける。Programは実行の束、Portfolioは判断の棚
先に言い切ります。PortfolioとProgramの違いは、継承元の有無にそのまま表れています。
pm_program は Planned task を継承します。だから開始日から終了日までの期間と進捗率を自分で持ち、Projectと同じように「動く」レコードになります。目的を共有する複数のProjectを束ねる、実行側の器です。
一方 pm_portfolio は継承元を持たない独立テーブルです。sys_db_object 上で Extends table が空、かつ Extensible=true という構造です。開始日も終了日も持たず、代わりに4段階の状態（Define / Analyze / Approve / Charter）だけを持ちます。実行を管理するテーブルではなく投資テーマを並べて評価するための棚だと分かります。
実機で確認する階層は、Idea→Demand→Project、そしてProgramとPortfolio
PPMの主要5テーブルを sys_db_object で横並びに見ると、継承構造の違いが一目で分かります。
この図の下敷きになっているのが、実機の sys_db_object の一覧です。
pm_portfolio の Extends table 列だけが空です。pm_program と pm_project は Planned task、dmn_demand は Task を継承しています。idea の列には「Idea」というラベルが表示されますが、これは実は別テーブル im_idea_core（Task継承）を指す表示です。この点は後の節で詳しく確かめます。
タスク系の継承構造そのものは、taskテーブル：ITSM全プロセスの共通の親で確認した仕組みと同じです。Planned task は Task を継承しています。そこにさらに Project、Program、改善イニシアチブが乗る構造は、ServiceNowのCIMとは何か（継続的な改善活動の管理）で見た sn_cim_register とも共通しています。
pm_portfolioには継承元が無い これは何を意味するか
実機のPortfolio一覧には5件が登録されていました。
5件とも「部門やテーマの名前」がついています。Application Modernization、HR、Sales。プロジェクトの名前ではなく投資の分野を表す名前です。Portfolioが個別の作業を表すテーブルではなく複数のProgramやProjectをまとめて評価するための箱だからだと分かります。
継承元を持たないという設計には理由があります。Task系のテーブルは「誰が」「いつまでに」「どんな状態で」作業するかを追跡するための構造です。Portfolioが管理したいのは作業ではなく投資テーマそのものなので、追跡機構を持たないシンプルな構造にしています。固有フィールドは16件あり、中心になるのはテーマの分類と責任者を表すものです。
portfolio_manager
business_unit
department
category
state
pm_programはPlanned taskを継承する だから進捗もスケジュールも持つ
Programの一覧を見ると、Portfolioとは違う顔つきになっています。
Planned start date、Planned end date、Percent completeという列があります。これはPlanned taskの継承によって最初から持っているフィールドです。Stateの列には「Work in Progress」「Pending」という値が入っていました。これはPortfolioの4状態とはまったく別の語彙で、Task由来の一般的な実行状態です。詳しくは後の節で比較します。
pm_program の固有フィールドは23件あります。schedule_status scope_status cost_status resource_status のように、進捗を複数の軸で持つ設計です。1つの数字ではなく複数のステータスに分けて持たせるのは、プログラムという単位が「日程」「範囲」「コスト」「資源」という異なる観点の健全性を同時に管理する対象だからだと読み取れます。
primary_portfolioが語ること 経営層とPMOのための束ね方
pm_project の primary_portfolio フィールドには、公式の説明が付いています。
The portfolio that this project supports. Helps execs and PMOs group work by strategic theme or business unit.
（訳: このプロジェクトが支えるポートフォリオ。経営層とPMOが、戦略テーマや事業単位で作業をグループ化するのに役立つ）
引用元: /sys_documentation_list.do?sysparm_query=name=pm_project^element=primary_portfolio
Portfolioが個々のプロジェクトの実行を管理するためのものではなく経営層とPMOが全体を見渡すための単位であることを、公式の説明文がそのまま裏付けています。
pm_program 側にも同じ構図があります。portfolio フィールドの公式説明は「Portfolio of this program」で、Programが必ず1つのPortfolioに属す設計だと分かります。逆にPortfolio側から見ると、pm_project.primary_portfolio と pm_program.portfolio の2つの参照が同じPortfolioに向かって集まってくる形です。
ProgramはPortfolio直下を飛ばせる 階層の抜け道
ここまでの説明だと、ProjectはProgramを経由してPortfolioにつながるように見えます。ところが実機のフィールド定義を見ると、Projectは Program を飛ばして直接 Portfolio につながれます。
pm_project には primary_program と primary_portfolio の両方が独立した参照フィールドとして存在します。どちらも任意項目です。小規模な投資で、複数プロジェクトを束ねるほどの規模がない場合は、Programを作らずにProjectから直接Portfolioへ紐づけることができます。
dmn_demand にも portfolio フィールドが単独で存在します。公式の説明は「Portfolio this demand falls under」で、要望の段階からPortfolioへの参照を持てる設計です。Programという中間層は、必要なときだけ使う任意の層だと分かります。
表で見るPortfolioとProgramの違い
ここまでの内容を1枚の表にまとめます。
状態の種類が4つと6つで異なる点、固有フィールド数が16件と23件で異なる点は、どちらも継承構造の差から来ています。次の節でPortfolioの4状態を詳しく見ます。
Portfolioの状態はなぜ4つしかないのか
pm_portfolio の state は sys_choice に4件だけ登録されています。
Define、Analyze、Approve、Charter。日々の作業の進み具合を表す値ではなく、投資判断が節目ごとにどこまで進んだかを示す値です。ラベルの意味を整理すると次のようになります。
この位置づけは公式のhintがまだ無いため、ラベルと業界一般のポートフォリオマネジメントの用語から読み取った推測です。一般的なガバナンスの流れに沿うと、4段階は次のように読めます。
Define：対象領域とテーマを定義する
Analyze：配下の候補を分析する
Approve：投資を承認する
Charter：正式な憲章として確定する
Portfolio専用のワークベンチ画面は、プロパティからは存在が分かる
ここまではリストとフォームだけで確認してきました。PortfolioにもDemandやProjectと同じように、一覧・フォーム以外の専用画面があるのかを実機で確かめました。
システムプロパティにcom.snc.project.portfolio_workbench.confirm_to_create_projectという項目が実在します。
Create project(s) on confirming demands from portfolio workbench
（訳: ポートフォリオワークベンチからDemandを確定する際に、プロジェクトを作成する）
引用元: /sys_properties_list.do?sysparm_query=name=com.snc.project.portfolio_workbench.confirm_to_create_project
この説明文から、「Portfolio Workbench」という専用画面がDemandをまとめて確定・プロジェクト化する場面で使われることは分かります。ただし、ナビゲータの「Workspaces」メニューを実際に開いて確認したところ、Portfolio向けのワークベンチは一覧に出てきませんでした。
このPDIに並んでいたのは次の8つです。
Asset Workspace
CMDB Workspace
ITOM Infra Services Workspace
Process Mining Workspace
Project Workspace
Request App Workspace
Resource Management Workspace
Service Operations Workspace
sys_app_moduleをPortfolioで検索しても、一覧・新規作成用の通常モジュールが見つかるだけです。
プロパティの存在から機能そのものはあると確認できますが、画面を開いて実機で確かめることはできませんでした。 別プラグイン（TeamSpaceなど、この記事の検証範囲外のもの）を有効化すると現れる可能性がありますが、そこまでは確認していません。この点は検証範囲外として扱います。
Programの状態はどこから来るのか Portfolioとの決定的な違い
pm_program の辞書定義を調べると、state フィールドは継承元のPlanned task、さらにその先のTaskで定義されています。
Task の state 選択肢は6値です。
Pending
Open
Work in Progress
Closed Complete
Closed Incomplete
Closed Skipped
実機のProgram一覧に映っていた「Work in Progress」「Pending」は、この共通の値でした。
つまりProgramの状態は「PPM専用に設計された値」ではなく「ServiceNow全体で共通の実行状態」です。Portfolioの4状態が投資ガバナンス専用に作られているのとは対照的です。この対比から、状態設計そのものがテーブルの性格を語っていると分かります。実行を管理するテーブルは共通の実行状態を使い、判断を管理するテーブルは専用の判断状態を持つという原則です。選択肢がどこに格納されているかの仕組みは選択肢Choice（sys_choice）：ドロップダウンの中身で確認した構造のとおりです。
Ideaは階層の起点 Demandへ昇格して初めて動き出す
idea テーブルには55件が登録されていました。
Demand列を見ると、多くの行が空欄で、一部だけリンクが入っています。これはIdeaが提出された時点ではまだ何も実行されておらず、Demandへ昇格した行だけが次の工程に進んでいることを表しています。idea.demand フィールドの公式説明はこうです。
Demand created for this Idea
（訳: このIdeaのために作成されたDemand）
引用元: /sys_documentation_list.do?sysparm_query=name=idea^element=demand
IdeaからDemandへの昇格が、階層全体における最初の関門だと公式の説明からも分かります。
逆方向の参照も用意されています。dmn_demand.idea の公式説明は「Idea related to this demand」でした。IdeaからDemandへ一方向に昇格するだけでなく、DemandからもとのIdeaを振り返れる双方向の参照になっています。さらに dmn_demand は primary_program フィールドも独立して持ちます。Projectがまだ無い段階でも、どのProgramに関係する要望かをDemandの時点で先に決めておける設計です。
Ideaを扱う3つのロール どこまでの変換権限を持つか
Ideaの新規登録フォームを開くと、Stateの初期値が「Submitted」になっていました。
新規作成の時点で最初から「提出済み」という状態が入っているのは意外でした。実は idea テーブルの state は idea 自身の定義ではなくその先の im_idea_core から受け継いだもので、11段階あります。
Draft
Submitted
Under Review
Need more information
In Backlog
Planned
In Development
Completed
Unlikely to implement
Duplicate
Already exists
一覧の見た目は「提出しただけ」に見えても、内部にはこれだけの選別プロセスが用意されています。
誰がこの選別と昇格を行えるかは、ロールで分かれています。
idea_manager と idea_manager_professional の対象は idea テーブルです。公式の説明を比べると権限の差がはっきりします。idea_manager は「Idea管理を通じて管理される対象」という基本の役割で、idea_manager_professional は「Demand・Projectを含む全エンティティへの変換ができる」という上位の役割です。つまり、Ideaを一つ上のDemandやProjectへ直接進められるのは professional 側だけです。
idea_admin だけは対象テーブルが違います。公式の説明は「im_idea_core テーブルへのCRUDアクセスと、Idea Managementの管理者権限を持つ」で、これは idea テーブルではなく im_idea_core を管理する役割です。同じ「Idea」という名前が付いた2つのテーブルに、別々の管理ロールが割り当てられている形です。
実務でPortfolio・Program・Demand・Ideaをどう使い分けるか
ここまでの構造を実務に置き換えると、判断の軸は次のようになります。
思いつきの段階では Idea に起票します。まだ投資判断の対象にすらなっていない状態です。検討する価値があると判断されたら Demand に昇格し、予算や優先順位の審査に入ります。承認されたら Project として実行に移ります。
複数のProjectが同じ目的を共有するなら Program でまとめます。逆に、単発のProjectをいきなり大きな投資テーマに紐づけたいだけなら、Programを作らずに primary_portfolio で直接 Portfolio へつなげます。
Programをどれだけ作るかの判断には、優先順位づけの仕組みも関わります。pm_program には score score_risk score_size score_value という4種類のスコアフィールドがあります。値、規模、リスクを別々に採点したうえで総合スコアを持たせる設計です。複数のProgram候補を並べて比較する土台になり、1本の数字だけで優劣を決めず内訳を残しておける点は実務でそのまま使えます。
Portfolioを新しく作るタイミングは、個別のプロジェクトの成否ではなく「この分野に継続して投資するかどうか」を経営層やPMOが判断したい単位が生まれたときです。誰にPortfolioの作成・編集を許すかはロールの設計次第で決まります。この中間表の仕組みはServiceNowの権限は誰が持っている？で確認しました。導入直後は it_portfolio_manager を必要な人数だけに絞る運用が実務では現実的です。
Portfolio単位の実績を経営層に見せる場面では Analytics Portfolio というUIアクションからPerformance Analyticsのダッシュボードへ遷移します。指標の作り方はPA指標設計の手順にまとめました。ダッシュボードの使い分けはレポート・ダッシュボード完全ガイドで扱った内容がそのまま使えます。
実機で気づいたこと
UI Actionの条件式が、今も「使うな」と言われている旧ロール名のままでした。 pm_portfolio の Analytics Portfolio と Portfolio Target は gs.hasRole('portfolio_manager')、pm_program の Program Budget は同じく portfolio_manager、Program Workbench は gs.hasRole('program_manager') を条件にしています。ところが portfolio_manager の公式説明は「DO NOT USE; refer it_portfolio_manager」です。実際に確かめると、it_portfolio_manager ロールの中に portfolio_manager が sys_user_role_contains で包含されていました。だから運用上は問題なく動いています。条件式のコードは何年も前のままでも、新しいロールが古いロールを飲み込む形で互換性を保っています。この包含の仕組みはServiceNowで付けたロールが想定外の権限を含んでいた理由で確認した構造と同じでした。ボタンが見えない相談を受けたら、ロールの説明文だけでなくUI Actionの条件式とロールの包含関係の両方を見る必要があります。切り分けの手順はServiceNowでボタンが出ないときの切り分けチェックリストにまとめています。
Portfolioの新規登録フォームは、16フィールド中3つしか出ていませんでした。
Name、Portfolio manager、Description。state や category、business_unit はフォームに配置されていません。これらは一覧のインラインや別のワークベンチから設定する前提の設計だと考えられます。特に category の選択肢を調べると、Transform business、Grow business、Run business という3値でした。俗に言うRun/Grow/Transformという、IT投資の分類でよく使われる枠組みがそのまま入っています。フォームには出てこない項目ほど、実は投資判断の骨格を担っていることに気づきました。
用語
PPM … Project Portfolio Management。Idea・Demand・Project・Program・Portfolioを1本につなぐ仕組み
Idea … 階層の起点となる着想の記録（idea）。Demandへの昇格で次の工程に進む
Program … 目的を共有する複数Projectの束（pm_program）。Planned taskを継承する実行物
Portfolio … 投資テーマを束ねる独立テーブル（pm_portfolio）。継承元を持たない
im_idea_core … ideaテーブルが継承する基底テーブル。Taskを継承し、11段階のstateを持つ
primary_portfolio … pm_project がProgramを経由せず直接Portfolioへ属すための参照フィールド
自分の環境で確認するときのURL
インスタンスのURLに続けて開いてください。
Portfolio一覧：/pm_portfolio_list.do
Portfolioの状態選択肢：/sys_choice_list.do?sysparm_query=name=pm_portfolio^element=state^language=en
Program一覧：/pm_program_list.do
Idea一覧：/idea_list.do
主要5テーブルの継承構造：/sys_db_object_list.do?sysparm_query=nameINpm_portfolio,pm_program,pm_project,idea,dmn_demand^ORDERBYname
Idea関連ロール：/sys_user_role_list.do?sysparm_query=nameLIKEidea
引用した公式説明を自分で開く
この記事で引用した文面は、ServiceNowが製品に同梱しているフィールドとロールの説明です。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINpm_project,dmn_demand,idea^hintISNOTEMPTY
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameINportfolio_manager,it_portfolio_manager,program_manager,it_program_manager,idea_manager,idea_manager_professional,idea_admin
検証範囲とおことわり
Australia PDI（Australiaファミリーリリース）に、PPM Standard導入済みの状態で確認しました。デモデータを含みます。件数と状態値は2026-08-15時点のこの環境のものです。
確認していない範囲は次のとおりです。
Portfolioの4状態に対応する公式のhintはまだ確認できていません。表の「位置づけ」は業界一般の用語からの推測です
Program・Portfolioの承認フロー（Flow Designer側の自動化）は今回の範囲外です
本番環境でのカスタマイズ（フォームレイアウトの変更）によって、この記事の画面とは見え方が変わります
TeamSpace機能を使った場合のPortfolio・Programの挙動は確認していません
関連記事
前提知識：taskテーブル：ITSM全プロセスの共通の親 … Planned task・Task継承の基本構造をまとめています
権限の仕組み：ServiceNowで付けたロールが想定外の権限を含んでいた理由 … 旧ロールが新ロールにどう包含されるかを実機でたどっています
実務編：ServiceNowでボタンが出ないときの切り分けチェックリスト … UI Actionの条件式が見えないときの調査手順です
