ServiceNowのDemand（需要管理）とは？ 思いつきを9段階で選別してプロジェクトにするまで
「システムをこう変えたい」という思いつきを、誰がどこで受け止め、どう選んでプロジェクトにするのでしょうか。ServiceNowのDemandは、この選別だけを担当するテーブルです。状態は9つあり、承認や差し戻しの分岐まで含めて1レコードで追えます。Australia PDIにPPM Standardを導入し、Demandの状態やフィールド、UI Actionを実機で確認しました。
検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo v1.0.0）を導入済み
PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。要望を受け付けて選別し、承認したものをプロジェクトにして、人と費用を割り当て、ポートフォリオ単位で投資判断をする。ここまでを1本につなぐアプリケーション群です。
Demandとは：PPMで最初に要望を受け止めるテーブルです。まだプロジェクトになっていない要望や改善案、変更案を1件ずつ受け付け、実行する価値があるかを判断してから、Project・Changeなど次の記録へ引き渡します。
PPMの流れの中で、この記事が扱うのは選別を担うDemandです。他のモジュールは別の記事で扱うため、ここではDemandに絞って掘り下げます。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
⑥Demand：9状態の選別（この記事）
Demandは9状態で選別する。ただし実機で件数が付いていたのは6状態だけだった
Demandの状態（dmn_demand.state）は次の9つです。
Draft（1）・Submitted（2）・Screening（3）・Qualified（-4）・Incomplete（5）・Deferred（10）・Rejected（7）・Approved（8）・Completed（9）
108件のデモデータを状態でグルーピングすると、出てきたグループは6つでした。
Qualified 15件
Draft 15件
Submitted 7件
Screening 4件
Approved 15件
Completed 52件
IncompleteやDeferredなど、残る3つの例外状態には1件も記録がありませんでした。
9つ定義されているのに、動いているデータでは6つしか埋まらない。この差がどこから来るのかを、フィールド・UI Action・ロールの3方向から実機でたどります。
思いつきを1件ずつ受け止める場所がほしい
新しいシステム化のアイデアは、会議やチャットから生まれます。困るのは、その思いつきをどこに書き留め、誰が「やる価値があるか」を判断するかが決まっていない状態です。声の大きい要望から着手すると、費用対効果の低い作業に人が取られます。
読者が本来ほしいのは、次の3点がそろった受付窓口です。
思いつきを1件のレコードとして残せる
予算感（capexかopexか、いくらかかりそうか）を最初から書ける
承認された分だけがプロジェクトとして走り出す
ServiceNowのDemandは、この3点を1つのテーブルに持たせる設計になっています。
PPMの中でDemandはどこに立つのか
PPMには複数のテーブルがあります。
pm_project（Project）
pm_program（Program）
pm_portfolio（Portfolio）
dmn_demand（Demand）
idea（Idea）
このうち、思いつきから実行までを橋渡しする3テーブルは、横一列の工程というより役割が違う場所です。Ideaは思いつきをゆるく集める場所で、承認の重さを持たない気軽な受付段階です。Demandは選別の場所で、財務情報と状態遷移を持ちます。Projectは実行の場所で、日程と進捗を持ちます。Demandを通らないと、Ideaは正式なProjectにもChangeにもなりません。
ProgramとPortfolioはさらに上位で、複数のDemandやProjectをまとめて投資判断をする層です。Demandは「個々の要望を審査する係」で、PortfolioやProgramは「審査を通ったものをまとめて経営判断する係」という違いがあります。
Demandは何のためのテーブルか。公式の記述から読む
PPM Standardのプラグイン説明には、この製品群の狙いがこう書かれています。
Installs a set of applications for managing your demands, projects, portfolios, and resources. Provides complete visibility from idea to execution.
（訳: 需要、プロジェクト、ポートフォリオ、リソースを管理するための一連のアプリケーション群をインストールします。着想から実行までを一貫して可視化します。）
引用元: /v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo
「idea to execution（着想から実行まで）の見通しを提供する」とあり、Demandはその最初の区間を担当します。
継承元はPlanned taskではなくTask
Project（pm_project）とProject Task（pm_project_task）の継承元はPlanned taskでした。日程・進捗パーセントを最初から持つ設計です。
一方でDemandの継承元はTaskでした。実機のsys_db_objectで確認したところ、dmn_demandのsuper_classはPlanned taskではなくTaskでした。taskテーブルの継承構造はtaskテーブル：ITSM全プロセスの共通の親にまとめています。
これは設計として理にかなっています。Demandはまだ「いつ・どれだけの期間で実行するか」が決まっていない審査対象です。日程を持つPlanned taskを継承すると、決まってもいない計画期間を最初から持たされることになります。Demandに期間管理の仕組みが無いのは省略ではなく、審査対象という位置づけそのものです。
9つの状態を1つずつ実機でたどる
Demand一覧を開くと、Number・Nameなど複数の列が並びます。108件のうち先頭20件は次のとおりです。
フォームを開くと、状態は上部の進捗バーとドロップダウンの両方で確認できます。
9つの選択肢はsys_choiceに登録されています。値の並びが不規則な点はsys_choiceの格納構造を知っていると理解しやすく、選択肢Choice（sys_choice）：ドロップダウンの中身で仕組みを扱っています。
状態を動かす条件は、UI Actionのスクリプトに直接書かれています。実機で条件式を1つずつ読み、誰が何を押すと状態がどう変わるかを表と図にまとめました。
Draft→Submittedは起票と提出
新規作成した直後はDraft（1）です。ここで書けるのはCategory（Strategic/Operational）、Type、概要程度で、審査に必要な情報はまだ揃っていません。
Submit demandボタンの条件はcurrent.state == 1 || current.state == 5でした。DraftだけでなくIncomplete（5）からも押せる、同じボタンです。押すとスクリプトがaction_name: submit_demandとして動き、状態はSubmitted（2）になります。
Screening→Qualifiedは選別と評価
Submitted（2）になると、Screenボタンが現れます。条件はgs.hasRole('demand_manager') && current.state == 2で、スクリプトはcurrent.state = '3'と1行だけです。押すとScreening（3）になります。
Screening中、あるいはSubmittedのまま直接、QualifyボタンでQualified（-4）に進めます。条件はcurrent.state == 2 || current.state == 3で、Screeningを経由してもしなくても評価フェーズに進める設計です。
Approved→Completedは承認と完了
Approveボタンの条件は(gs.hasRole('demand_manager') || gs.hasRole('demand_approver')) && (current.state == -4 || current.state == 10)でした。QualifiedかDeferredのどちらからでも承認できます。
Approved（8）になったあとはCloseボタンです。条件はcurrent.state == 8だけで、押すとCompleted（9）に進みます。デモデータでCompletedが52件と最多だったのは、Closeまで一気通貫で通った案件が多いことを示しています。
Deferred・Incomplete・Rejectedは正常系から外れた3状態
Deferボタンはcurrent.state == 2 || current.state == 3 || current.state == -4が条件で、SubmittedやScreening、Qualifiedのどこからでも保留にできます。DeferredはApproveの対象にも含まれているため、そこから審査に復帰できます。
Incomplete（5）は情報不足の差し戻しにあたる状態です。ここへ向かうボタンは見当たりませんでしたが、Submit demandの条件に含まれているとおり、Incompleteからは再提出でSubmittedへ戻れます。
Rejected（7）については、37件のUI Actionをすべて確認しましたが、状態をRejectedへ変更するボタンが1件も見当たりませんでした。 状態としては定義済みで、どのDemandにも設定できる値ですが、classic UI Actionの範囲では設定経路が確認できていません。Demand Workbenchという別画面（Angularベースのワークスペース）に審査用の操作が集約されている可能性がありますが、その中身は本記事の検証範囲外です。
フォームの進捗バーが6段階しか見せない理由
さきほどのフォーム画像をもう一度見てください。上部の進捗バーには、DraftからCompletedまでの6段階だけが並びます。残る3つの例外状態は表示されません。
この見た目は、実機のグルーピング結果とも一致します。進捗バーが見せているのは「順調に進んだ場合のルート」で、例外の3状態は意図的に別扱いにされています。 UI Actionの条件式を読むと、この3状態はどれも正規ルートから枝分かれする例外で、直列には並んでいません。フォームの見た目と条件式の作りが、同じ設計意図を裏付けています。
誰が状態を動かすのか。37件のUI Actionを条件式で読む
dmn_demandに登録されている有効なUI Actionは37件でした。フォームアクションの一覧を実機で見ると、条件列に状態番号とロール名がそのまま書かれています。
UI Actionの条件式の読み方自体は、ServiceNowのResolveボタンはどこで動く？で扱ったIncidentの例と同じです。ボタンが見えるかどうかは、Client側の条件式1本で決まります。
ScreenやQualifyなど、状態を直接動かす5つのボタンを実際に読むと、条件式の多くがgs.hasRole('demand_manager')を使っていました。ロールの一覧では「使うな」と指定されている旧ロールです（次章で扱います）。一方、Create Improvement Initiativeだけはgs.hasRole('it_demand_manager')と、現行ロールを直接チェックしていました。同じテーブルの中でも、ボタンごとにチェックしているロール名が違います。
3つのロールは何をする人か
Demandに関わるロールを、公式のdescriptionとあわせて確認しました。
it_demand_user：User who can create the IT demands in the system. Demand can be strategic or operational — 起票側のロールです
it_demand_manager：User who manages the inflow, screening and facilitates the prioritization of IT demands — 受付から優先順位付けまでを担当します
demand_approver：Approves Demand — Approveボタンの条件に、demand_managerと並んで書かれています
実務でDemandをどう設計に使うか
ここまでの実測をもとに、導入設計に反映すると次のようになります。推測を含む提案として読んでください。
起票ロール（it_demand_user）は現場の広い範囲に配ってよい。Draft・Incompleteでの操作しかできないためです
選別ロール（it_demand_manager）は、審査プロセスの責任者に絞る。Screen・Qualify・Defer・Close・Approveの一部をここに集約する設計です
demand_approverを個別に付与するかどうかは、承認をit_demand_managerと同じ人に持たせるか分けるかの組織判断になります。条件式が2つのロールをORでつないでいるため、承認の一段化も二段化もどちらも構成できます
Rejectedの遷移経路が確認できていない点は、本番導入前にDemand Workbench側の操作を必ず確認してから設計に反映してください
財務フィールドが最初から付いている
Demandのフィールドは73件あります。特徴的なのは、審査対象の段階から財務系フィールドがひととおり揃っていることです。
capital_budget（Capital budget）とoperational_budget（Operating budget）で、投資区分ごとの予算枠をあらかじめ分けて持てます。expected_roi（ROI %）やfinancial_benefit（Financial benefit）は、承認前の段階で期待効果を数値化するためのフィールドです。
厳密な見積もりがまだ立てられない初期段階のために、size（T-Shirt size）というフィールドも用意されています。公式の説明は次の1文です。
How big is the demand
（訳: このDemandはどのくらいの規模か）
引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=size
SmallやLargeのような粗い区分で規模感だけを先に共有し、正式な工数見積もりはProjectに変わってから詰める、という2段階の見積もり運用ができる設計です。
フィールド定義そのものは73件あり、一覧の先頭部分は次の画像のとおりです。
related_recordsとideaフィールドが示す関連付けの広さ
related_recordsフィールドの公式説明はこうです。
Related task records to this demand such as change, incident, problem, other demand and projects
（訳: このDemandに関連するタスクレコード。例: ChangeやIncident、Problem、他のDemandやProject）
引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=related_records
related_recordsは、次のようなレコードとの関連付けを想定しています。
Change
Incident
Problem
他のDemand
Project
Demandは新規の思いつきだけでなく、IncidentやProblemの調査から生まれた改善提案も扱う設計です。 IncidentとProblemの切り分け方はServiceNow 問題管理（Problem）完全ガイドで扱っています。両者がどこでDemandにつながるかはServiceNowのCIMはIncidentやProblemとどうつながる？にまとめました。
ideaフィールドの公式説明は次のとおりです。
Idea related to this demand
（訳: このDemandに関連するIdea）
引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=idea
Idea側にもdemandという参照フィールドがあり、Demand created for this Ideaという説明が付いています。IdeaとDemandは双方向に参照し合う設計です。
次にどの記録へ渡すかは、typeフィールドの値によって使えるUI Actionが変わります。3つの送り先を確認しました。
type=change … Create Changeボタンが現れる。詳しい経路はServiceNow 変更管理（Change）完全ガイド
type=project … Create Projectボタンが現れる
type=continual_improvement_management … Create Improvement Initiativeボタンが現れる。関連する仕組みはServiceNowのCIMとは何か
受け付ける経路も送り先も複数あり、Demandは合流と分岐が起きるハブです。
実機で気づいたこと
「使うな」と書かれたロールが、実際には現役のロールに組み込まれていました。 sys_user_roleの一覧でdemand_managerのdescriptionを見るとDO NOT USE; refer it_demand_managerとあります。ところがScreenやQualifyなど、状態を動かす主要なボタンの条件式は、このdemand_managerを直接チェックしていました。最初は「非推奨のロールに実装が依存したままなのか」と読めましたが、sys_user_role_containsを実機で確認すると、it_demand_managerはdemand_managerを内側に含む形で定義されていました。it_demand_managerを付与すれば、demand_managerの権限も自動的に付きます。ロールの包含関係を知らずに条件式だけを見ると誤解する場面で、ServiceNowで付けたロールが想定外の権限を含んでいた理由で扱った包含の仕組みそのものでした。承認の経路について詳しくはServiceNow 承認（Approval）完全ガイドも参考になります。
Rejectedへの遷移経路が最後まで見つかりませんでした。 37件のUI Actionを1件ずつ、他の状態変更ボタンと同じ書式のスクリプトを探しましたが、current.state = '7'のような1行を書いているアクションはありません。状態としては最初から定義されているのに、実行する手段がclassic UI Actionの中には無いことになります。「用意されているのに、通常の画面からは動かせない状態」に出会ったのは今回が初めてです。審査系のテーブルに珍しくない設計なのか、Demand特有なのかは、追加の調査が要ると感じました。
Reset to Draftは、どの状態からでも押せる設計でした。 スクリプトインクルードDemandDraftのcanResetToDraftを読むと、条件は次の3つだけです。
Draftではないこと
予算計画（project_funding）が未着手であること
Project・Change・Defect・Enhancementのどれとも未連携であること
QualifiedからでもDeferredからでも、この3条件さえ満たせば起票段階まで一気に戻せます。審査のやり直しを状態遷移のルールで縛らず、リンク先の有無という実データで縛っている点が参考になりました。
用語
Demand（dmn_demand） … PPMで思いつき・要望・改善案を受け付け、実行する価値があるかを審査するテーブル。継承元はTask
demand_manager … sys_user_roleで「使うな」と指定されている旧ロール。it_demand_managerに含まれる形で現役
PPS … Project Portfolio Suite。PPM Standardが連れてくる中核プラグイン
T-Shirt size … sizeフィールド。Small/Medium/Largeのような粗い規模感を、正式な見積もり前に共有するための区分
Demand Workbench … demand_managerロール保持者向けの専用画面。UI Actionからはgs.hasRole("demand_manager") && !RP.isRelatedList()の条件でリンクが出る
自分の環境で確認するときのURL
インスタンスのURLに続けて開いてください。
Demand一覧：/dmn_demand_list.do
Demandの状態でグルーピング：/dmn_demand_list.do?sysparm_query=GROUPBYstate
状態の選択肢一覧：/sys_choice_list.do?sysparm_query=name=dmn_demand^element=state^language=en^ORDERBYsequence
フィールド定義一覧：/sys_dictionary_list.do?sysparm_query=name=dmn_demand^elementISNOTEMPTY^ORDERBYelement
有効なUI Action一覧：/sys_ui_action_list.do?sysparm_query=table=dmn_demand^active=true^ORDERBYname
ロールの包含関係：/sys_user_role_contains_list.do?sysparm_query=role.name=it_demand_manager
引用した公式説明を自分で開く
この記事で引用した文面は、ServiceNowが製品に同梱しているフィールドとロールのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=name=dmn_demand^hintISNOTEMPTY
ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameINdemand_manager,demand_approver,it_demand_manager,it_demand_user
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo
検証範囲とおことわり
Australia PDIに、OOTBの状態からPPM Standard v1.0.0（デモデータ込み）を導入して確認しました。フィールド・UI Action・ロールの数値は2026-08-15時点のこの環境のものです。
確認していない範囲は次のとおりです。
Rejected（7）・Incomplete（5）への遷移経路。classic UI Actionの範囲では見つからず、Demand Workbench（Angularワークスペース）の内部は未調査
Demand Workbenchおよびタイムライン可視化画面の操作そのもの
本番環境でロールの割り当てを変えた場合の挙動
Multicurrency / TeamSpaceを導入した場合の差分
関連記事
前提知識：taskテーブル：ITSM全プロセスの共通の親 … Demandが継承するTaskの役割を扱っています
同じ構造を別の角度から：ServiceNowで付けたロールが想定外の権限を含んでいた理由 … it_demand_managerがdemand_managerを含む仕組みの一般形です
次に読む：ServiceNowのCIMはIncidentやProblemとどうつながる？ … related_recordsでつながる相手側にあたる記事です
