ServiceNowのPPMでプロジェクトを完了まで流す手順：IdeaからPortfolioまで22ステップを実機でたどる
ServiceNowのPPMで、思いつきを1件のプロジェクトに変えて完了まで持っていくには、何回ボタンを押すのでしょうか。実機で通すと、承認までは6回押すだけで進みました。ところがProjectを閉じる段になると、Closeに相当するボタンがどこにも用意されていません。Australia PDIにPPM Standardを入れた環境で、社内ファイルサーバの移行案を22ステップで最後まで動かします。
検証環境：Australia PDI / OOTB / 2026-08-15 確認。PPM Standard（com.snc.financial_planning_pmo）を導入済み
PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。要望をDemand（需要）として受け付けて選別し、承認したものだけをProject（プロジェクト）として実行します。使った費用と生んだ効果は、上位のProgramとPortfolioに集まります。
この記事で通す範囲：Idea（着想）からDemand（需要）を作り、Project（プロジェクト）に変え、Resource Plan（要員計画）とCost Plan（費用計画）とBenefit Plan（効果計画）を足し、ProgramとPortfolioに載せて完了させるまでです。読むだけでなく、実際にレコードを作りながら1本つなぎました。
PPMシリーズ（全14本） — 導入から設計・運用・トラブルまで通しで書いています。
⑪運用手順：Idea→Portfolio 22ステップ（有料100円）（この記事）
承認まで6回で進むのに、Projectを閉じるボタンは用意されていない
DraftからApprovedまでは、ロールさえあればボタンを押すだけで進みます。追加の必須入力が増える場面は一度もありませんでした。Project側に入ると、様子がはっきり変わります。1周させて分かったことは3点です。
Demandの審査は6回のボタンで終わり、Create Projectを押した瞬間にDemandは自動でCompletedになる。 Closeボタンは一度も押していません
Projectを閉じるためのボタンはOOTBに存在しない。 Phaseを手でClosingへ変えます。一方でStateのほうは、配下のProject Taskを3件とも閉じた時点で、Closed Completeまで勝手に動いていました
ProjectをProgramに紐づけると、その場でProgramの終了日が書き換わる。 画面に「Program end date has been changed to 2027-02-25 17:00:00.」（訳: プログラムの終了日を2027-02-25 17:00:00に変更しました）と出ました
PPMは、審査の型を最初に用意しておきながら、実行の締めくくりは運用側に委ねる作りでした。以降のSTEP1からSTEP22で、その22手順を画面で追います。
今回のシナリオと登場する8つの役割
場面：社内のファイルサーバーが老朽化し、保守期限が近づいている。運用負荷とハードウェア更新コストを減らすため、クラウドストレージへの移行を1件のプロジェクトとして立ち上げたい。
PPMは1人で回す仕組みではありません。8つの役割が順にバトンを渡します。
受け渡しの順番はこうなります。
Projectを中心に置くと、下にぶら下がるテーブルと、上に載るテーブルは次の形になります。
Demandの作り方は2通りある
Demandを作る道は2本あります。Ideaから変換する道と、最初からDemandとして登録する道です。前者はアイデア募集の窓口、後者は部門からの正式な申請という位置づけになります。この記事ではSTEP1とSTEP2でIdea経由を確かめ、STEP3以降は直接登録したDemand（DMND0001104）で最後まで通しました。Idea経由で作ったDemand（DMND0001107）はDraftのまま残しています。
STEP1：【現場の起案者】Ideaを起票する
Ideaはideaテーブルのレコードです。必須マークが付いているのはTitleだけでした。Submitted byには操作したユーザーが自動で入ります。
Stateの初期値はSubmittedです。この段階ではTaskフィールドが空で、Demandとの結びつきはまだありません。画面右上にCreate Taskボタンが出ているのが分かります。
STEP2：【現場の起案者】Create TaskでDemandに変換する
Create Taskを押すと、変換先を選ぶ小さなダイアログが開きます。
Select task typeでDemandを選び、OKを押します。ここで選べる種別がDemandだけかどうかは、導入しているアプリの構成で変わります。
IdeaのStateがIn Backlogに変わり、TaskにDMND0001107が入りました。idea.demandフィールドの公式説明は次のとおりです。
Demand created for this Idea
（訳: このIdeaのために作られたDemand）
引用元: /sys_documentation_list.do?sysparm_query=name=idea^element=demand
できあがったDemandを開くと、Ideaフィールドから元のIdeaへ戻れます。
CategoryはStrategic、TypeはProjectという既定値が入った状態で作られました。日付欄は4つとも空です。Related LinksにはCreate Projectが最初から出ていました。ここから先は、直接登録したDemandとまったく同じ扱いになります。
STEP3：【申請部門の担当者】Demandを新規登録する
ここからは本線のDemandです。新規作成の画面はこの状態から始まります。
必須マークが付いているのはNameとCategoryとTypeの3つだけです。今回はNameに「老朽化した社内ファイルサーバをクラウドストレージへ移行したい」、CategoryにStrategic、TypeにProjectを入れました。Business Caseタブには移行の理由を書いています。
TypeをProjectにしたのには理由があります。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
Demandを閉じる選択肢そのものが、Type=Projectでなければ現れません。プロジェクト化を前提にした案件では、最初にこの値を決めておきます。
入力したのはPlanned start dateとPlanned end dateの2つだけです。ところがApproved start dateとApproved end dateにも、同じ日付が既に入っていました。ボタンを一度も押していない段階での複製なので、作成時に動くビジネスルールの働きと見られます（推測）。
STEP4：【申請部門の担当者】Submit demandで提出する
入力を終えたらSubmit demandを押します。この段階のボタンは1つだけで、ロールの条件は付いていません。
条件式はcurrent.state == 1 || current.state == 5だけでした。demand_managerのようなロール判定はありません。起票した本人がそのまま提出できます。 ここから先の3つのボタンには、いずれもロール条件が付きます。
STEP5：【需要マネージャー】Screenで審査に入れる
需要マネージャーが引き継ぎ、Screenを押して審査段階へ進めます。
Screenの条件はgs.hasRole('demand_manager') && current.state == 2でした。スクリプト本体はcurrent.state = '3'; current.update();の2行だけです。追加の入力を求めるコードはどこにもありません。
ワークベンチから選別する場合
複数のDemandを見比べながら選別したいとき、需要マネージャーはDemand Workbenchという一覧画面を使う経路も持っています。Idea経由で作ったDraftのDemand（DMND0001107）で見え方を確認しました。
画面の上段はRiskとValueを軸にしたバブルチャート、下段はStageやSizeを列に持つ一覧です。DMND0001107はStage＝Demand Draftのまま一覧に並んでいました。
sys_ui_actionでScreenとQualifyとApproveの3つを調べると、list_context_menuとform_linkはどちらもfalseでした。この一覧やバブルからワンクリックで状態を進める仕組みは用意されておらず、選別の実行は対象のDemandを開いてフォームから行う設計です。 Demand Workbenchは判断材料を並べて見比べる画面であり、状態を動かす操作はフォーム側が担っています。
STEP6：【需要マネージャー】Qualifyで合格させる
続けてQualifyを押します。条件はcurrent.state == 2 || current.state == 3なので、Screeningを経由しなくても評価段階へ進められます。
状態はQualified（値は-4）になります。9つある状態の中で唯一マイナスの値ですが、UI Actionの条件式は数値の正負に依存していません。並び順はsequenceフィールドで別に管理されています。選択肢の格納構造そのものは選択肢Choice（sys_choice）：ドロップダウンの中身で扱いました。
STEP7：【承認者】Approveで承認する
承認者が内容を確認し、Approveを押します。条件は(gs.hasRole('demand_manager') || gs.hasRole('demand_approver')) && (current.state == -4 || current.state == 10)でした。QualifiedとDeferredのどちらからでも承認できます。
Related LinksにCreate Projectが出ています。ただしこのリンクの表示条件に、状態そのものは入っていません。Draftの画面にも最初から同じリンクが出ていました。Approvedまで順に進めるのは、システムが強制しているからではありません。審査を運用として守っているからです。
STEP8：【需要マネージャー】Create Projectでプロジェクト化する
需要マネージャーがCreate Projectを押すと、Projectの作成が始まります。
画面上部に「Project PRJ0010003 has been created.」と出ます。訳すと「プロジェクトPRJ0010003を作成しました」です。同時に状態インジケータが一気にCompletedまで進みました。1段階ずつの遷移とは違い、ApprovedからCompletedを1回の操作で飛び越えています。close_demandの既定値が「On creation of project」だからです。
NumberはPRJ0010003、PhaseはInitiatingから始まります。Project managerには、Create Projectを実行したユーザーがそのまま入りました。誰が実行するかを決めておかないと、意図しない人がProject managerになります。
完了したDemandはCategoryとTypeが編集できなくなり、Related LinksからCreate Projectも消えました。Demand側の役目はここで終わります。
ボタンが出ないときに最初に見るところ
STEP1からSTEP8のとおりに進めば、入力不足で止まる場面はありません。止まるとすれば、入力ではなくロールと状態とプラグインの組み合わせです。実機で読んだ条件をまとめました。
ボタンが見当たらないときは、まずロールを疑います。 状態を進める4つのボタンは、いずれもdemand_manager相当のロール（実体はit_demand_manager）かdemand_approverが要ります。起票した本人がこれらを持っていなければ、ボタンごと表示されません。エラーメッセージも出ないため、押せないのか見えていないのかを最初に切り分けます。切り分けの手順はServiceNowでボタンが出ないときの切り分けチェックリストにまとめています。
STEP1からSTEP8までの入力早見表
Idea起票からProject作成までを、テーブルと状態と入力の対応で1枚にしました。
先にTypeをProjectにしておけば、以降はボタンを押すだけで進みます。 ここまでが、Demandを扱う人の担当範囲です。
💰 ここから先は有料エリア
