サービスカタログ運用設計書

1. 運用設計の目的と範囲

この記事は、ServiceNow のサービスカタログ運用を「どう決めるか」という視点で整理した運用設計書です。承認をどの基準で分けるか、カタログや変数をどう増やし整理するか、履行の遅れをどう検知するか。こうした設計判断を、その理由とあわせて一つずつ決める。後から運用を変えるとき、判断の背景までさかのぼれるようにするためだ。土台には、ServiceNow が OOTB（初期設定）で備えるカタログ構造・変数の仕組み・承認ルーティングの機能を据えることを前提とする。

サービスカタログ運用の設計が達成すべきことを、次のように置く。

• 申請から履行までの流れを止めずに回すため、承認・履行・統制の役割分担を設計する。

• sc_request の金額しきい値承認と sc_req_item の部門長承認という2段階の承認ルートを設計する。支出の規模と部門の統制を両立させるためだ。

• 変数定義の重複を防いで保守性を保つため、変数セットの再利用方針とカタログ・カテゴリの構成基準を設計する。

• OOTBに用意されていない履行のSLAを自社で定義する。履行の遅延を早期に検知するためだ。

• 承認・アサインの各節目の通知設計を定める。承認・履行の停滞を関係者が見逃さないためだ。

ITIL の Request Fulfillment（要求実現）は、標準化された要求を効率よく提供し、利用者の期待に応えることを主眼に置くプロセスです。障害対応であるインシデント管理とは異なり、あらかじめ内容と価格が定まった申請を、決まった承認と決まった履行手順で流すことに重心があります。本設計書はこの前提に沿い、承認の統制と履行の可視化を中心に設計判断を積み上げます。

対象範囲はサービスカタログ運用です。中心に置くのは sc_cat_item（カタログアイテム）・sc_request（Request）・sc_req_item（Requested Item）・sc_task（Catalog Task）・sysapproval_approver（承認）です。申請から承認、履行までのプロセス設計と、sc_request と sc_req_item にまたがる2段階の承認ルールの設計を扱う。変数セット・カタログ・カテゴリのガバナンス設計、SLA・KPI の設計、承認・履行の通知設計も対象とする。さらに、自社で決める設計パラメータ、RACI、OOTB を変える/変えない判断基準も定める。既存の自動化資産（ビジネスルール・Script Include）の棚卸しと非機能観点まで踏まえる。カタログアイテムや Record Producer の個別項目の作り方、変数の入力画面の操作手順は、別記事の役割とし、本設計書では踏み込まない。

設計の起点は OOTB です。ServiceNow のサービスカタログは、何も作らない初期状態でも、承認ルーティング・変数セットの再利用の仕組み・Requested Item の期限設定が最初から組まれている。実際に Standard Laptop（$1,100）を注文すると、金額のしきい値に応じた承認グループが自動でアサインされる。

OOTB で用意済みの承認ルーティング・変数の仕組みのうち、どこをそのまま使い、どこを自社向けに足すかを決めることを方針とする。運用設計とは、この仕組みをゼロから作ることではない。OOTB が提供する基準、つまり金額しきい値による承認振り分けと変数セットによる再利用構造を土台にする。そのうえに、各社で決める運用ルール（しきい値・カテゴリ体系・SLA定義）を重ねる作業である。土台の確認に使った環境は PDI（Zurich / 2026-07-04 確認）です。

想定読者は、サービスカタログ運用の設計を任された運用設計者・カタログ管理者、承認ルールやSLAの根拠を説明できるようにしたい人です。カタログの3階層構造（Request / Requested Item / Catalog Task）の項目定義そのものは、別記事「ServiceNow Service Catalogの3階層構造を実機で読み解く」で扱っています。項目の意味から知りたい人はそちらをご覧ください。

2. 現状把握（申請〜承認の仕組みと規模）

設計に入る前に、現状を数値と実機の挙動で確認する。対象となる運用の規模と、OOTBが実際にどう動くかを把握するためだ。

カタログの規模は次のとおりだった。

• カタログアイテム（sc_cat_item）は全196件、うち active が146件。

• Record Producer（sc_cat_item_producer）は39件。

• カタログは Service Catalog と Technical Catalog の2つ、アクティブなカテゴリは20件。

• active なカタログアイテム146件をカテゴリ別に集計すると、Peripherals が23件で最多だった。次いで Software 15件、Services 14件、Application and Account Access と Can We Help You? がそれぞれ11件。残りは1〜9件の小規模カテゴリに分散していた。

この分布は、一部のカテゴリにアイテムが厚く積み上がり、同時に多数の小さなカテゴリが併存する構成を示している。カテゴリの粒度をどう整理するかは、第5章のガバナンス設計で扱う。

変数の仕組みも、すでに再利用の実例を持っていた。item_option_new_set（変数セット）の "it_to_it" というセットは、別のカタログアイテムに共有されている。共有先は "VM Provisioning" と "Big Data Analysis" だ。Catalog Client Script は128件、Catalog UI Policy は99件、いずれも active な状態で、変数の表示制御や必須化がすでに広く実装されていた。共有と個別実装が混在するこの状態を、どこまで整理するかも設計対象になる。

承認の仕組みは、実際に Standard Laptop（$1,100）を注文して確認した。結果は、金額しきい値ベースの承認グループが自動でアサインされるというものだった。アサイン先は、承認者 Eric Schroeder が所属する「Catalog Request Approvers > $1000」である。承認理由のフィールドには "Request Total Price is more than $1000." という値が記録されていた。この注文のリクエスト者（admin）は manager フィールドが空欄だったが、承認は問題なく発生した。マネージャーへの承認ではなく、グループへの金額しきい値による承認という設計であることが、この一点からわかる。処理を進めるフローは Flow Designer の「Service Catalog item request」で、レガシーの Workflow ではなかった。

履行の期限にも、OOTBの既定値が働いていた。実機で注文した Requested Item は、注文日から自動で9日後が期限（due_date）に設定されていた。一方で、履行のSLAを定義する contract_sla テーブルを Requested Item・Catalog Task を対象に検索すると、該当が0件だった。金額による承認の振り分けと違い、履行の遅延をSLAとして定義し監視する仕組みは、このPDIには最初から用意されていない。この事実が、第6章のSLA・KPI設計の起点になる。

承認と履行の流れも、実際に2件目の注文を最後まで進めて確認した。承認は1段階では終わらない。sc_request（申請本体）に紐づく金額しきい値の承認が終わったあと、sc_req_item（申請明細＝RITM）に紐づく別の承認が発生する。この2段階目の承認者は、申請者の manager フィールドではなく、cmn_department（部門）の dept_head から決まっていた。2段階の承認がそろって完了すると、sc_task（Catalog Task）が自動で生成され、履行担当グループにアサインされる。この Catalog Task を完了させると、sc_req_item の stage が「Deployment」まで進む。

この一連の流れを通知の面から見ると、抜けがあった。sysapproval_approver（承認）の生成にあわせてメールが飛ぶ節目と、飛ばない節目が混在していたことが sys_email テーブルの実測でわかった。承認・履行のどこまでが通知され、どこが通知されないままになっているかは、第7章の通知設計で扱う。

有料部では、この現状把握を踏まえ、次の設計判断を固める。

• カタログ申請〜承認〜履行（Catalog Task）のプロセス設計と役割分担

• sc_request の金額しきい値承認・sc_req_item の部門長承認という2段階の承認ルール設計、代替案（マネージャー承認・無承認・カテゴリ別ルート）との比較と不採用理由

• 変数セットの再利用方針、カタログ・カテゴリ構成のガバナンス設計、カタログアイテムの可視性・ワークフロー選択・金額表示設定

• OOTBに存在しないSLAをどう自社で定義するか、KPIの設計

• 承認・履行の各節目で誰に通知するかという通知設計、通知が届いていない節目への対応方針

• 自社で決める設計パラメータ一覧、RACI、OOTBを変える/変えない判断基準

• 既存の自動化資産（ビジネスルール・Script Include）の棚卸し、非機能観点、本設計書で確定する成果物

ここから先は、一つひとつの設計判断を、根拠とともに固めていく。