ServiceNowのPPMはどのメニューから操作する？ 7つのアプリケーションメニューで何ができるか

PPM Standardを入れると、ナビゲーターに新しいメニューが並びますが、どこから何を操作すればよいのかは一目では分かりません。実際に確認すると、需要の起票からガントチャート、要員計画までの操作は7つのメニューに分かれて配置されていました。メニューの名前はDemand・Ideas・Projectなど7種類に分かれています。Australia PDIで1つずつ開き、Create Newを押した先の画面と、実際に保存した結果まで確かめます。

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

• ①導入手順：PPM Standardを入れる

• ②影響調査：入れると何が増えるか

• ③PPMとは：モジュールの全体像（親記事）

• ④初期設定：プロパティ・ロール・カレンダー

• ⑤メニュー解説：どの画面から操作するか（この記事）

• ⑥Demand：9状態の選別

• ⑦Project：計画・進捗・費用の管理

• ⑧Resource：要員の割り当て

• ⑨PortfolioとProgram：投資判断の上位構造

• ⑩連携：IncidentやCIMとのつながり

• ⑪運用手順：Idea→Portfolio 22ステップ（有料100円）

• ⑫開発設計書（有料300円）

• ⑬運用設計書（有料300円）

• ⑭トラブル：つまずく点と直し方

PPMを入れると、操作の起点はどう変わるのか

7つのメニューには、それぞれ異なるロールが割り当てられています。ナビゲーターの管理画面で確認すると、次のようになっていました。

7件のうち5件には現行のロール（it_demand_managerやit_project_managerなど）が設定されています。残る2件は毛色が異なります。Ideasにはロールの指定が一件もなく、Project AdministrationとResource management workspaceはpps_adminという同一のロールで絞られていました。このpps_adminが何者かは、この記事の後半で扱います。

7メニューの位置づけを図にすると、次のようになります。

需要を起票するDemand、それを育てるIdeas、実行するProjectとResource。管理側のProject AdministrationとResource management workspace、そしてサービス台帳を扱うService Portfolio Management。この7メニューを含め、PPM Standard導入全体でアプリケーションメニューは13件増えました。プラグイン導入がどこまで影響するかを数える方法はプラグインを入れると何が変わる？ 影響調査でチェックする27か所にまとめています。ここからは実際に使う順番に沿って、7メニューを1つずつ開きます。

Demand機能は何のためにあるのか

思いついた要望を、いきなりプロジェクトにはしません。ServiceNowのPPMでは、要望をまず「Demand」として起票し、リスクと価値で選別してから、承認されたものだけをプロジェクトに進めます。企画段階の玉石混交な要望を、実行段階に進める前にふるいにかける仕組みです。

dmn_demandテーブルの継承元はTaskで、開始日や進捗率を最初から持つPlanned taskとは別の系統です。選別に必要な項目だけで構成されているという設計になっています。フィールドの公式説明にはこうあります。

（訳: Demand managerは、このデマンドの担当マネージャーです。）

引用元: /sys_documentation_list.do?sysparm_query=name=dmn_demand^element=demand_manager^hintISNOTEMPTY

Demandメニューの3つのモジュールで何ができるか

Demandメニューには、All・Create New・Workbenchの3つが並びます。まずAllを開くと、登録済みのデマンド一覧が表示されます。

Stage列を見ると、デマンドが進む段階が分かります。順番は次の6段階です。

• Draft

• Submitted

• Screening

• Qualified

• Approved

• Completed

承認されたものはProjectと連動し、Pending、Work in Progressといった段階へ移ります。Score列には、リスクや価値から算出した評点が入ります。

Create Newを押すと専用の新規作成フォームが開き、Nameだけが入力必須で、CategoryやTypeなどには既定値が入っています。作成と保存の具体的な手順は、この記事の範囲外（手順書側で扱う内容）とします。

Demand Workbenchでは選別をどう進めるか

Workbenchモジュールを開くと、リスクと価値の散布図でデマンドを俯瞰する画面になります。

円の大きさはSizeを表し、右上に寄るほどリスクが高く、上に寄るほど価値が高いデマンドです。Qualified段階のデマンドがここに集まり、承認するか見送るかを判断する材料になります。デマンド管理者はこの画面を起点に、個別のフォームを開かなくても優先順位を決められます。

Self-ServiceのMy Demandsは何を映すか

Demandメニューとは別に、Self-Serviceにも「My Demands」というモジュールがあります。中身を確認すると、opened_byが自分自身か、collaboratorsに自分が含まれるデマンドだけに絞り込まれる設定でした。

つまりMy Demandsは、担当者が自分の提出物を追うための画面です。デマンド管理者向けのWorkbenchとは見せる範囲が異なり、一般ユーザーは自分が関わったものだけを見る導線になっています。

Ideasメニューは何を受け付けるのか

Demandの手前には、もう1つIdeasメニューがあります。PPM Standardの依存プラグイン「Ideation with PPM」の公式説明にはこうあります。

（訳: 需要、プロジェクト、ポートフォリオ、資源を管理するための一連のアプリケーションをインストールします。）

引用元: /v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo

ideaテーブルにはdemandという参照フィールドがあります。アイデアからデマンドへ昇格させる導線が、構造として用意されているわけです。Demandがすでに具体化した要望を扱うのに対し、Ideasはまだ評価前の思いつきを集める段階です。Ideation with PPM自体はPPM Standardの依存プラグインとして一緒に有効化されました。依存関係の仕組みはプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめています。

Ideasメニューには、他の6メニューと違ってロールの指定がありません。誰でもアイデアを投稿し、投票できる設計です。デマンドの起票にはロールが要りますが、その手前のアイデア段階は広く門戸を開いているという住み分けになっています。

Projectメニューはプロジェクトをどう管理するか

pm_projectの継承元はPlanned taskです。開始日・終了日・進捗率を最初から持つ系統で、期間管理の仕組みを持たないDemandとは別の性格を持ちます。同じPlanned taskを継承する例はServiceNowのCIMとは何か？で見た改善イニシアチブにもありました。フィールドの公式説明にはこうあります。

（訳: プロジェクトを成功に導くために、主導・調整・監督を担当する人物です。）

引用元: /sys_documentation_list.do?sysparm_query=name=pm_project^element=project_manager^hintISNOTEMPTY

Allモジュールを開くと、登録済みのプロジェクトが並びます。

一覧の中に、以前の検証でDemandから作成したプロジェクトが含まれていました。Approved start dateとApproved end dateには、元になったデマンドの承認期間がそのまま引き継がれています。Create Projectのリンクは名前だけの機能ではなく、実際に日付を引き継いだレコードを作る操作だと確認できました。AllのほかにCreate Newも並び、Project managerやExecution typeに既定値が入った状態でゼロから起票できます。フォームの詳しい入力手順は、この記事の範囲外です。

PortfolioとProgramはどこから作るか

Projectメニューの中には、PortfoliosとProgramsという区切りもあります。それぞれにCreate NewとAllが並び、pm_portfolioとpm_programを単独で作成・一覧できる作りです。ポートフォリオは継承のない独立テーブルで、プログラムはプロジェクトと同じくPlanned taskを継承しています。プロジェクトの上位にポートフォリオとプログラムを置き、投資判断を階層で扱う構造です。

Program Workbenchで何が一覧できるか

Programsの中のWorkbenchを開くと、登録済みのプログラムがカード形式で並びます。

カードにはプログラム名とOwned byの担当者名だけが表示され、詳細な状態はカードを開かないと分かりません。Demand Workbenchが散布図で優先順位を見せるのに対し、Program Workbenchは一覧性を優先した作りになっていました。

ガントチャートはどこから開くか

プロジェクトのフォームには「Planning Console」というUIアクションがあります。これを押すと、そのプロジェクトのガントチャートが開きます。実際にMobiChord Mobility Managementというプロジェクトで開いてみました。

WBSの各フェーズが横棒で表示され、期間をドラッグして調整できる作りです。画面上部には「Newer better experience is available to manage your projects」という案内も出ていました。この従来型のPlanning Console自体は現役ですが、後継のワークスペースへ移行を促す表示が組み込まれています。従来のフォームと新しいワークスペースの違いはワークスペースは従来のフォームと何が違う？で扱った内容と同じ構図でした。

CIO Roadmapを開くと何が見えるか

Projectメニューには、もう1つ可視化ツールとしてCIO Roadmapがあります。PPM Standardを導入した直後にそのまま開くと、パネルには「No panels available」という案内だけが表示され、実データは何も出ませんでした。

この画面の実体はroadmap_pageテーブル（ラベルはTimeline Visualization）の1レコードです。CIO Roadmapのレコードを調べると、縦の「レーン」にpm_portfolio（ポートフォリオ）を、横に並ぶ「アイテム」にpm_project（プロジェクト）を置き、end_dateを基準に配置する設定になっていました。レーンとアイテムはpm_m2m_portfolio_projectという中間テーブルで結びつく仕組みです。

表示されない原因を切り分けるため、データを用意して再現を試みました。 ポートフォリオの1つ「Application Modernization」に検証用プロジェクトを1件作成し（short_descriptionに「記事検証:」と付記）、中間テーブルにも関連付けのレコードを1件登録しています。ここに見落としがありました。pm_m2m_portfolio_projectのproject列はpm_projectを直接は参照していません。参照先はpm_portfolio_projectという別テーブルでした。プロジェクトをポートフォリオへ加えると、このpm_portfolio_project側に固有のsys_idを持つ集計用レコードが自動生成され、中間テーブルにはそちらのsys_idを登録する必要があります。最初はpm_project自身のsys_idをそのまま登録していたため参照が解決できず、パネルは空のままでした。

pm_portfolio_project側のレコードのsys_idに差し替えて登録し直すと、パネルにレーンとプロジェクト件数が表示されました。

state別の凡例には次の6項目があり、タイムライン上のドットの色に対応します。

• Pending

• Open

• Work in Progress

• Closed Complete

• Others

• Multiple Projects

エラーメッセージは一切出ません。参照するテーブルを1つ取り違えただけで、CIO Roadmapは「設定待ち」の空表示のまま静かに止まる作りでした。

Resourceメニューでは要員をどう計画するか

Resourceメニューには5つのモジュールが並びます。一覧のAllと、資源計画の段階で絞ったRequested / Confirmed / Allocated、そして起票用のCreate Newです。中身のResource Plansを見ると、次のようになっていました。

Task列を見ると、DMND0001155のようなデマンドの番号と、PRJ0010041のようなプロジェクトの番号が両方入っていました。資源計画は企画段階のDemandに対しても、実行段階のProjectに対しても作れる仕組みです。State列には次の段階が並び、要員が確保から確定まで進む過程を追えます。

• Requested

• Planning

• Allocated

• Confirmed

pps_resourceロールが無いと何が起きないか

資源計画に人を割り当てるには、条件があります。フィールドの公式説明にはこうあります。

（訳: pps_resourceロールを持つユーザーだけが、リソースマネジメントを通じて管理されます。）

引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=user_resource^hintISNOTEMPTY

pps_resourceロールを持たない人は、資源計画のUser欄で選べる対象にすら入りません。要員を割り当てる前に、対象者へこのロールを付与しておく手順が必要になります。

Resource management workspaceを開くと何が見えるか

Resourceメニューとは別に、Resource management workspaceというメニューも独立して存在します。開くと、稼働状況をまとめたダッシュボードでした。

指標はすべて0、下段の一覧も「No data available」でした。原因は集計期間の既定値が「This year」になっている一方、資源計画のデータは2022年から2023年にかけて作られたデモデータだったためです。集計期間を過去の年に変更すれば、割り当てのデータが見える見込みです。

管理ボード（Visual Task Board）はPPM専用の機能か

プロジェクトタスクをカンバン風の板で管理する「Visual Task Board」という機能もあります。これがPPM専用の仕組みなのかを確認しました。

結果は、PPM専用ではありませんでした。既存のボードはAustralia Patch 3という、PPMとは無関係な内容です。この機能はSelf-Serviceの中にあり、taskテーブルを継承するレコードであれば、pm_project_taskを含めてどのテーブルからでも「Add to Visual Task Board」で追加できる汎用機能でした。PPM7メニューの外側にある、taskテーブル全体に効く仕組みだと分かります。taskテーブルの継承関係はtaskテーブル：ITSM全プロセスの共通の親にまとめています。

Project Administrationでは何を設定するか

Project Administrationメニューには管理者向けの設定が並びます。主なモジュールは次の5つに分かれます。

• Rate Model

• Fiscal Calendar

• Cost Type Definitions

• Planning Console

• TeamSpacesRate Modelを開くと、単価計算の元になるモデルが1件登録されていました。

Group、User、Roleの優先順位で単価を決めるモデルで、通貨はUSDです。このほかFiscal Calendarでは会計期間を発行し、Planning Consoleのモジュールでは全プロジェクトの計画状況を横断的にグルーピングして確認できます。Project Administrationは、個別のプロジェクトではなく、PPM全体の前提条件を整える場所です。PPM Standard自体はグローバルスコープのアプリケーションで、GlobalとScopedの違いはアプリとスコープ：Globalとx_の違い（sys_app）にまとめています。

Service Portfolio Managementでは何を管理するか

最後のメニューは、少し性格が異なります。Servicesを開くと、提供中のサービス一覧が並びました。

Business criticalityやOperational statusといった列があり、CMDBのサービスモデルと連動しています。プロジェクトを起票する前段階で、どのサービスに影響する取り組みなのかを紐づける台帳という位置づけです。サービス側からPPMを見るための起点になっていると分かります。

実機で気づいたこと

pps_adminロールの説明文には、はっきりと使用しないよう書かれていました。

（訳: 使用しないでください。it_pps_adminか、TeamSpace固有のロールを参照してください。）

引用元: /sys_user_role_list.do?sysparm_query=name=pps_admin

それにもかかわらず、Project AdministrationとResource management workspaceの2メニューは、今もpps_adminだけで絞られています。現行ロールへの置き換えは道半ばで、管理者向けメニューには古いロールが残ったままでした。ロールの包含関係を調べる方法はsys_user_role_containsで包含を実機でたどるで扱っています。

Resource management workspaceには、もう1つ意外な点がありました。このメニューにはモジュールが1件も紐づいていません。 実際にResourceで使う「Resource Management Workspace」を開くモジュールは、Resourceメニュー側に存在しています。メニューは立っているのに中身が空という状態です。

Demandを1件保存したときの挙動にも、見た目以上の動きがありました。番号はDMND0001105が発行されましたが、同じ番号を持つデモデータのデマンドがすでに存在していました。番号は連番で発行される目印であり、一意性を保証する仕組みではないという実態です。

さらに、保存の裏側では非同期の予約処理が2件登録され、投資計画側の連携チェックも走っていました。デマンドは起票された瞬間から、コスト計画やスケジュール実行の仕組みに接続されています。フォーム上はただの入力フォームに見えても、保存の裏では複数のテーブルが連動して動いています。

7メニューはどう使い分ければよいか

7つのメニューをあらためて並べると、次のようになります。

役割は4つに分かれています。企画段階を担うのがDemandとIdeas、実行段階を担うのがProjectとResourceです。管理者向けの設定を担うのがProject AdministrationとResource management workspaceです。サービス台帳を担うのがService Portfolio Managementになります。どのメニューを誰に開放するかは、ロールの割り当てだけでなく、pps_adminのような古いロールが混ざっていないかまで確認しておく必要があります。

用語

• Demand … 要望を起票し、リスクと価値で選別する段階のレコード。継承元はTask

• Idea … Demandより手前の、評価前の思いつきを集める段階のレコード

• Planned task … 開始日・終了日・進捗率を持つ系統。ProjectとProgramが継承する

• Rate Model … Group・User・Roleの優先順位で単価を決める設定

• Visual Task Board … taskテーブルを継承するレコードなら使えるカンバン風の板。PPM専用ではない

• pps_admin … 公式に非推奨と説明されている旧ロール。現行はit_pps_admin

• pm_portfolio_project … プロジェクトをポートフォリオに加えると自動生成される集計用レコード。CIO Roadmapの中間テーブルはこちらのsys_idを参照する

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

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

• PPMのアプリケーションメニュー一覧：/sys_app_application_list.do?sysparm_query=titleINDemand,Ideas,Project,Project Administration,Resource,Resource management workspace,Service Portfolio Management

• Demandの一覧：/dmn_demand_list.do

• Demand Workbench：/$demand_workbench.do

• Projectの一覧：/pm_project_list.do

• Resource Plansの一覧：/resource_plan_list.do

• Visual Task Boards：/$vtb.do

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

この記事で引用した文面は、ServiceNowが製品に同梱しているフィールドとロールの説明です。次のURLで同じ記述を確認できます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINdmn_demand,pm_project,resource_plan^hintISNOTEMPTY

• ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameINpps_admin,it_pps_admin^descriptionISNOTEMPTY

• プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo

検証範囲とおことわり

Australia PDIに、OOTBの状態でPPM Standardを導入した環境で確認しました。デモデータは導入時に入れています。記事検証用に作成したDemand・Projectの各レコードは、short_descriptionに「記事検証:」という接頭辞を付けて区別しています。

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

• Resource management workspaceのダッシュボードは、集計期間を過去に変更した場合の表示は確認していない

• Programワークベンチの個別カードを開いた先の詳細画面は確認していない

• 本番環境でのpps_adminロールの利用実態

関連記事

• 前提知識：左メニューもテーブルでできている（sys_app_module） … アプリケーションナビゲーターの成り立ちを扱っています

• 前提知識：taskテーブル：ITSM全プロセスの共通の親 … ProjectやDemandが継承する土台を扱っています

• 次に読む：ServiceNowのCIMはIncidentやProblemとどうつながる？ … PPM導入でCIM側に現れるCreate Demand・Create Projectのリンクを扱っています