メインコンテンツへスキップ
見出し画像

ServiceNowのPPMを入れたら最初にやる設定は？ プロパティ・ロール・カレンダーを実機で確認する

    ServiceNow観察日記


    PPM Standardの有効化だけでは足りず、プロジェクトや需要を動かすには追加の設定が要ります。次に何を設定すればいいのか、画面を開いただけでは判断できないという声をよく聞きます。実際に確定させるべき設定は、ロールの配る相手と数件のプロパティ、そして会計カレンダーの3点に絞られていました。Australia PDIの実機で、増えたロール50件・プロパティ101件の中身を確認します。

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

    PPMとは：Project Portfolio Management（プロジェクトポートフォリオ管理）の略です。個別のプロジェクトの管理にとどまらず、要望（Demand）を受け付けて選別し、承認したものをプロジェクトにして、人と費用を割り当て、ポートフォリオ単位で全体の投資判断をする。ここまでを1本につなぐアプリケーション群です。

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

    配る相手を決めるロールと、6件のプロパティ、会計年度の3点で動き出す

    PPM Standardの導入でロールは50件、システムプロパティは101件増えます。件数だけを見ると手が付けられませんが、判断が要るのは一部です。ロールは12件の現行ロールを誰に配るか、プロパティは6件の初期値を自社に合わせるか、会計カレンダーは自社の会計年度をカバーしているか。この3点を確定させれば、現場にPPMを開放できる状態になります。残りは運用しながら詰めれば十分です。

    導入した直後、何が決まっていれば安心して開放できるか

    PPMを入れた担当者が知りたいのは、増えたテーブルやACLの一覧ではなく、このまま現場に触らせて事故が起きないかという1点です。プロジェクトマネージャーに何のロールを渡すのか、資源計画に誰が載るのか、コストは自動で集計されるのか、会計年度はいつからいつまでを想定しているのか。この4つが決まっていれば、DemandやProjectの画面を現場へ開放しても運用は安定して回ります。ここが未確定のまま開放すると、権限が足りず動けない人と、意図せず全件を編集できてしまう人が同時に出ます。

    プラグイン導入の続き、現場公開の手前にある工程

    PPM Standardをどのプラグインから入れるかは別記事で扱いました。この記事はその続きです。プラグインが有効化されたあと、実際にDemandやProjectの画面を現場へ渡す前に済ませておく初期設定の工程を扱います。プラグイン自体の依存関係は複雑で、PPM StandardはProject Portfolio Suiteという別プラグインを連れてきます。依存関係の全体像を追うのではなく、有効化されたあとに人が判断すべき設定だけに絞るのがこの記事の役割です。

    この設定は、権限・財務ルール・稼働時間を最初に決める工程にあたる

    PPM Standardの公式説明はこうです。

    Installs a set of applications for managing your demands, projects, portfolios, and resources. Provides complete visibility from idea to execution. It also helps you plan, track, and manage resources, cost, time, and budget on projects and demands in a portfolio through various workbenches.

    （訳: 需要（デマンド）、プロジェクト、ポートフォリオ、資源を管理するための一連のアプリケーションをインストールします。アイデアから実行までを完全に可視化し、各種ワークベンチを通じて、資源やコスト、時間や予算の計画と追跡ができるようにします。）
    引用元: /v_plugin_list.do?sysparm_query=id=com.snc.financial_planning_pmo

    要望から実行までを見渡し、資源やコスト、時間、予算を管理する仕組みだと分かります。初期設定で決めることも、この裏返しとして整理できました。誰が何を見て何を管理できるかというロール、コストと時間をどう計算するかというプロパティ、予算をどの期間で区切るかという会計カレンダー、という3系統です。実機ではこの3系統を順番に確認します。

    ロール50件のうち、配る相手を決めるべきは12件

    システムプロパティとロールの実機確認から始めます。まずはロールです。


    画像

    接頭辞なしの8ロールは公式が「使うな」と明記している

    該当したのは次の8件です。

    • demand_manager

    • demand_user

    • portfolio_manager

    • pps_admin

    • program_manager

    • project_manager

    • project_portfolio_user

    • project_user

    descriptionには、揃って同じ文言が入っていました。

    DO NOT USE; refer it_project_manager or TeamSpace specific role

    （訳: 使用しないこと。it_project_managerまたはTeamSpace専用ロールを参照してください。）
    引用元: /sys_user_role_list.do?sysparm_query=name=project_manager

    使うな、it_project_managerかTeamSpace専用ロールを参照せよという意味です。名前だけを見ると一番それらしいロールなのに、公式が使用を止めているという逆転が起きています。過去バージョンとの互換性のために残っているとみられますが、権限棚卸しでこの8件をうっかり配ると、公式が非推奨とした古い権限モデルをそのまま使うことになります。

    配るべきは it_ 接頭辞の現行12ロール

    同じ検索条件で it_ 接頭辞・pps_resource・resource_ 系を集めると12件でした。


    画像


    画像

    配るべき12件は、次の3つの階層に分かれます。

    • 管理者：it_project_manager・it_demand_manager・it_portfolio_manager・it_program_manager・resource_manager

    • 利用者・閲覧者：it_project_user・it_demand_user・it_project_portfolio_user・resource_user

    • 全体管理：it_pps_admin（4アプリの設定を横断管理）

    it_pps_adminはDelegated Developmentでadminを絞る考え方がそのまま使えます。特定の担当者だけに絞り、システム管理者以外には配らないのが安全です。


    画像

    pps_resourceを付け忘れると、資源計画にその人を載せられない

    12件の中で扱いが異なるのがpps_resourceです。resource_plan.user_resourceの公式説明にこうあります。

    Only users with pps_resource role can be managed through resource management

    （訳: pps_resourceロールを持つユーザーのみが、資源管理の対象として管理できます。）
    引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=user_resource

    resource_plan.group_resourceも同様です。

    Only groups with pps_resource role can be managed through resource management

    （訳: pps_resourceロールを持つグループのみが、資源管理の対象として管理できます。）
    引用元: /sys_documentation_list.do?sysparm_query=name=resource_plan^element=group_resource

    資源計画の対象者リストに出てくるのは、pps_resourceを持つ人だけです。 it_project_managerやit_pps_adminのような管理系ロールとは別に、工数を割り当てたい人全員へ個別に付与する必要があります。プロジェクト管理者にit_project_managerだけを配って満足すると、その人自身は資源計画に載らず、稼働率が計算されないまま資源管理が回ることになります。ロールの範囲がどこまで及ぶかを実機で追う方法はロールを付けたのに見えない理由でも扱いました。

    プロパティは101件のうち76件に公式説明がある。最初に見る6件

    ロールの次はプロパティです。増えた101件のうち、com.snc.projectで始まるものが33件、com.snc.resource_managementで始まるものが31件で、大半を占めます。


    画像


    画像

    システムプロパティの置き場所そのものは別記事にまとめたとおりで、値と公式説明が同じ画面から確認できます。101件のうち76件には公式の説明文がついていて、既定値とセットで読めるのが強みです。運用開始前に見ておきたいのは次の6件で、このうちdefault_scheduleはこのあとの会計カレンダーの節でくわしく扱います。


    画像

    average_daily_fteは1日の標準労働時間をどう定義するか

    com.snc.resource_management.average_daily_fteの既定値は8でした。公式説明は次のとおりです。

    Average Daily FTE Hours/Hours Per Person Day (This value is used for converting FTE and person days to hours in resource plans)

    （訳: 1日あたりの標準FTE時間・人日あたりの時間数。資源計画でFTEや人日を時間に変換する際に使う値です。）
    引用元: /sys_properties_list.do?sysparm_query=name=com.snc.resource_management.average_daily_fte

    FTE（フルタイム換算）や人日を時間に変換する基準値です。1日8時間労働の前提なら既定値のままで問題ありませんが、所定労働時間が7.5時間の会社では、この値を変えないと稼働率の計算がずれます。

    first_day_of_weekは週の起点をどこにするか

    com.snc.resource_management.first_day_of_weekの既定値は1（月曜）でした。

    First Day of Week (Monday = 1, Sunday = 7)

    （訳: 週の起点（月曜=1、日曜=7）。）
    引用元: /sys_properties_list.do?sysparm_query=name=com.snc.resource_management.first_day_of_week

    資源グリッドの週区切りに使われる値です。日本の業務では月曜起点が一般的なので、既定値のままで合う組織が多いはずです。

    calculate_roi と rollup.costは財務を自動計算するかどうか

    com.snc.project.calculate_roiは既定trueでした。

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

    （訳: プロジェクトの見積コストと正味価値をもとに、ROI（投資対効果）の割合を計算します。）
    引用元: /sys_properties_list.do?sysparm_query=name=com.snc.project.calculate_roi

    com.snc.project.rollup.costも既定trueでした。

    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

    どちらも有効なら、プロジェクトのコストやROIは自動で積み上がります。原価をどの単位で持つかは会社・部署・原価の3枚のテーブル構成とも関係するので、自社の原価センターの粒度と合わせて確認すると手戻りが減ります。

    3件とも既定はtrueで揃っています。実機の一覧で見ると、どれも同じtrue | falseの切り替え式です。


    画像

    project_task_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に設定すると、プロジェクトを削除する際に、カスケード削除が有効な状態でプロジェクトタスクも削除されます。）
    引用元: /sys_properties_list.do?sysparm_query=name=com.snc.project_task_cascade_delete

    プロジェクトを削除すると、配下のタスクも連鎖して削除されます。誤操作への耐性を優先するなら、この既定値を見直す判断もあり得ます。

    会計カレンダー（Fiscal Calendar）が前提になる場面

    プロパティの次に確認すべきなのが会計カレンダーです。PPMのCost Planは、いつからいつまでの予算かを会計期間の単位で持ちます。


    画像

    Fiscal Periodの一覧には、FY18からFY28まで11年分、187件の期間（年・四半期・月の3種類）がすでに登録されていました。Cost Planにはstart_fiscal_periodとend_fiscal_periodという2つの参照項目があり、この期間テーブルを直接指しています。Cost Planの期間指定は、自社の会計年度に合わせた会計カレンダーがあって初めて選べます。

    Fiscal Calendarプラグイン（com.snc.fiscal_calendar）自体の公式説明はこうです。

    Enables to generate and manage different kinds of Fiscal calendar which is used in various Financial applications.

    （訳: 各種の財務アプリケーションで使われる、さまざまな種類の会計カレンダーを生成・管理できるようにします。）
    引用元: /v_plugin_list.do?sysparm_query=id=com.snc.fiscal_calendar

    複数の財務系アプリケーションで共通に使われる会計期間の仕組みという位置づけです。自社の決算月が4月始まりでない場合は、既存のFY18〜FY28がそのまま使えるとは限りません。運用開始前に、この期間がどう生成されたのかを確認しておく必要があります。

    スケジュール（Schedule）とFiscal Calendarは別物

    紛らわしいのが、com.snc.project.default_scheduleが指すスケジュールとの違いです。


    画像

    pm_project.scheduleの公式説明はこうでした。

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

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

    こちらは稼働日・祝日・非稼働時間を決める稼働カレンダーです。SLAが土日を飛ばす理由で扱った営業時間の仕組みと同じ系統で、日々のタスク期限に影響する設定です。一方のFiscal Calendarは、予算をどの期間で区切るかという会計期間を扱います。似た名前の設定が2種類あると気づかずに触ると、直したい箇所とは別の設定を変更してしまいます。

    実機で気づいたこと

    default_scheduleは参照方法がプロジェクトと資源管理で違う

    com.snc.project.default_scheduleの値はスケジュールのsys_id（7aa3e10c8f70010040f82ab2f0f9234d）でした。ところがcom.snc.resource_management.default_scheduleの値は、sys_idではなく「Resource Management Schedule」という名前の文字列そのものです。Value列を実機で見比べると、この違いがそのまま画面に出ています。


    画像

    同じ既定スケジュールという役割のプロパティなのに、参照の持ち方が違います。スケジュールの名前を変更すると、資源管理側の既定スケジュールだけ見つからなくなる可能性があり、触るときは両方を確認したほうが安全です。

    Fiscal Calendarプラグインにデモデータフラグが立っていない

    com.snc.fiscal_calendarのhas_demo_dataはfalseでした。それにもかかわらず、実機には187件のFiscal Periodがすでに存在していました。PPM Standard側のデモデータ導入と合わせて入ってきたとみられますが、この経路までは確認していません。デモデータなしでPPMを導入した場合に同じ187件が作られるかどうかは未検証です。会計期間が空のままだと初期設定の意味は分かりますが、実際に空だった場合の挙動は自分の環境で確かめる必要があります。

    DO NOT USEロールは無効化されていない

    demand_managerなど8件の旧ロールは、descriptionで使用を止められているだけで、ロール自体はActiveのまま残っています。Elevated privilegeの列もfalseで、システム的に配布を防ぐ仕組みはありません。説明文を読まずに名前だけでロールを選ぶと、そのまま配布できてしまいます。 権限設計のレビューでは、この8件が誰にも割り当たっていないことを確認する項目を1つ加えておくと安心です。

    実務では何に使えるか

    ここまでの内容を、今すぐ決めることと後回しでよいことに分けます。


    画像

    今すぐ決めること

    • 配る相手を決める：it_project_manager・it_demand_manager・resource_managerなど12件の現行ロール

    • pps_resourceを付与する：資源計画に載せたい人全員に、管理系ロールとは別で

    • プロパティを合わせる：average_daily_fte・first_day_of_week・default_scheduleを自社の稼働実態へ

    • 会計カレンダーを確認する：自社の会計年度をカバーしているかどうか

    この4点は、Workbenchを現場へ開放する前に片づけておきます。

    後回しでよいこと

    calculate_roiやrollup.costのオン・オフは、既定のtrueで運用を始めて、必要になったら見直せば十分です。project_task_cascade_deleteのような削除周りの挙動も、業務要件が固まってから判断できます。DO NOT USEロール8件の棚卸しや、sn_ppm_read・sn_ppm_finance_readのような読み取り専用ロールの配布も、要望が出てから対応すれば間に合います。

    小さく始める順番

    1. it_pps_adminを担当者1名か少人数に絞って先に配る

    2. it_project_manager・it_demand_managerなど管理系ロールをプロジェクト責任者へ配る

    3. 資源計画に載せる全員へpps_resourceを付与する

    4. average_daily_fte・first_day_of_week・default_scheduleを自社の稼働実態に合わせる

    5. 会計カレンダーがカバーする年度を確認し、足りなければFiscal Periodの追加を検討する

    6. ここまで終わったらDemandとProjectの画面を現場へ開放する

    この4項目さえ決まれば、PPMは使い始められます。 残りは運用しながら詰めていけば十分な設定です。

    他のプラグインでも使える確認の順番

    ロールの配布方針を決め、財務や稼働時間に関わるプロパティを合わせ、会計や稼働のカレンダーが自社と噛み合っているかを確認する。この順番はCIMを入れたときに確認した4点とも共通しています。プラグインごとに増える件数は違っても、最初に見る場所の型は使い回せます。

    用語

    PPM Standard：ServiceNowでプロジェクトポートフォリオ管理を有効化するプラグイン。idはcom.snc.financial_planning_pmo。

    pps_resource：資源管理の対象者リストに載るために必要なロール。管理系ロールとは別に付与する。

    Fiscal Period：会計上の年・四半期・月を表すレコード。Cost Planの開始と終了の期間が参照する。

    Schedule（cmn_schedule）：稼働日・祝日・非稼働時間を定義する稼働カレンダー。Fiscal Calendarとは別の仕組み。

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

    自分のインスタンス名に続けて開きます（PPM Standardの導入が前提です）。

    • PPM関連プロパティ一覧：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.project

    • 資源管理プロパティ一覧：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.resource_management

    • DO NOT USEロール一覧：/sys_user_role_list.do?sysparm_query=descriptionLIKEDO%20NOT%20USE

    • 現行ロール一覧：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHit_%5EORname%3Dpps_resource%5EORnameSTARTSWITHresource_

    • Fiscal Period一覧：/fiscal_period_list.do

    • Schedule一覧：/cmn_schedule_list.do

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

    この記事で引用した説明文は、ServiceNowが製品に同梱しているロール・プロパティ・フィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。

    • ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHit_%5EORname%3Dpps_resource

    • プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHcom.snc.project^descriptionISNOTEMPTY

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

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

    検証範囲とおことわり

    Australia PDI（OOTB）で2026-08-15に確認しました。PPM Standardをデモデータ込みで導入した状態です。

    プロパティやロールの値を実際に変更する作業は行っていません。 既定値の読み取りと、一覧画面のスクリーンショットで確認した範囲です。average_daily_fteやfirst_day_of_weekを変更した後の再計算結果、calculate_roiをfalseにしたときの画面挙動は未検証です。

    デモデータなしでPPM Standardを導入した場合にFiscal Periodが同じ件数になるかどうかは確認していません。DO NOT USEロール8件を実際にユーザーへ割り当てて動作を確かめる作業も行っていません。会計年度をFY18〜FY28以外の範囲へ作り直す手順も検証範囲外です。

    関連記事

     
     

    ServiceNow観察日記

     
     
    ServiceNowのPDI（Personal Developer Instance）を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ