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

サービスカタログの運用を任されると、最初に迷うのは体制です。誰がアイテムを公開してよいか、誰が承認しきい値を決めるか、履行が遅れたとき誰に報告が上がるか。ServiceNowはカタログ・カテゴリ・変数という入れ物と、金額しきい値による承認ルーティングを最初から備えていますが、運営の役割分担と品質基準までは決めてくれません。この記事は、Australia の PDI の構成を前提とした運用設計書のサンプルです。章立てと記述の粒度を、そのまま自社の設計書に流用できる形にしています。

本書に含む章

• 運用設計書に必要な章立て

• カタログオーナー・アイテムオーナー・承認者・履行チームが、整備から履行・クローズまでの4フェーズのどこを担うか

• SLA定義が0件という前提でのサービスレベル設計

• アイテム公開基準（履行エンジン未設定85件を出さない運用）

• 死蔵アイテムの棚卸しとKPI設計

設計の前提

• カタログ系ロール12件・Request Management系ロール4件が、体制設計の材料になっている

• SLA定義（contract_sla）はcollection=sc_request/sc_req_item/sc_taskのいずれも0件が標準であり、サービスレベルはSLA以外の設計に委ねられている

• カタログアイテム204件のうち履行エンジン（workflow・flow_designer_flow）を1つも持たないアイテムが85件（41.7%）存在し、運用ルールの起点になっている

運用設計書の章立て

ServiceNow のモジュール運用設計書は、次の構成とする。

章内容1本書の目的と適用範囲2前提条件3運用体制4役割分担（RACI）5運用ルール6サービスレベル7エスカレーション8通知と報告9品質管理10会議体11教育と引き継ぎ12運用開始の準備13用語定義

開発設計書が「どう作るか」を定めるのに対し、運用設計書は「誰がどう回すか」を定める。両者で項目は重複させない。承認ルーティングの内部構造は開発設計書に、承認しきい値を誰がどう変更するかは運用設計書に記載する。

第1章：本書の目的と適用範囲

本書は、ServiceNow のサービスカタログを日常運用するための体制・役割・ルールを定める。

本書が対象とするのは、カタログ運用の責任者と各役割の担当者とする。システムの設定値と実装方式は、別途の開発設計書で定める。

適用範囲は、カタログアイテムの新設からアイテムの廃止までの運営と、注文が承認を経て履行されるまでの日常運用とする。個々の申請フォームの作り方や承認フローの内部構造は、既存の子記事群に委譲する。

運用の目的は、入れ物を作って終わりにしないことにある。公開したアイテムが実際に注文され、リードタイム内に履行され、使われなくなったら廃止される。この循環を保つことを目的に据え、以降の章を定める。

第2章：前提条件

2-1. 製品が想定している役割分担

カタログ系ロール12件・Request Management系ロール4件の構成をもとに、体制を次のとおり定める。

本書が扱う役割分担は、カタログを整備するタイミングと、申請1件が処理されるタイミングとで、関わる人が入れ替わります。次の図は、カタログ整備フェーズ（随時）→注文フェーズ（申請ごと）→履行フェーズ→クローズ連鎖（自動）→月次報告という4フェーズの時系列に沿って、5つの役割を配置したものです。承認者は履行チームや他の役割から独立した存在ではなく、注文フェーズの中で承認レコードを確定させる担当として位置づけます。

以降の章の図は、この4フェーズ図のどこを詳細化したものかを本文中に明記します。

役割主に関わるフェーズ担当内容対応するロールカタログオーナーフェーズ1（整備）・月次報告の受け手カテゴリ新設・編集者割当・公開承認を担うcatalog_managerアイテムオーナーフェーズ1（整備）アイテムの作成・更新（下書き→バージョン）を担うcatalog_editor申請者フェーズ2（注文）ポータルでカタログ項目を注文する付与なし（User Criteriaで可視性を制御）承認者フェーズ2（注文）承認レコードを持つ場合のみ読み取り・承認できるsn_request_approver_read履行チームフェーズ3（履行）注文ごとのCatalog Taskを処理するitil（追加ロールなしでsn_request_writeを自動保有）カタログ管理者全フェーズ横断設定の変更・削除、Builder系の高度な操作を行うcatalog_admin

catalog_managerの権限範囲は、製品の説明に従う。

（訳: 部門内で新しいサービスカテゴリを要求し、編集者にサービスの作成・更新を割り当て、カタログへの公開を承認する担当）

catalog_editorは次のとおりである。

（訳: カタログマネージャのためにカテゴリ内のアイテムを作成・更新する。下書きとバージョンを作る）

引用元: /sys_user_role_list.do?sysparm_query=nameLIKEcatalog^ORnameLIKEsn_request

catalog_managerは「公開を承認する」役割、catalog_editorは「作成し、マネージャの承認を待つ」役割という位置づけである。本書ではこの2つの役割（いずれもフェーズ1）に加え、フェーズ2で承認レコードを扱うsn_request_approver_read保持者を承認者、フェーズ3で注文ごとの履行を担うitil保持者を履行チームとして区別する。role=itil^containsLIKEcatalogの検索は0件であり、履行チームは注文の処理はできてもカタログの運営権限は持たない設計になっている。

2-2. SLA が無い前提でのサービスレベル管理

contract_slaをsc_request/sc_req_item/sc_taskの3テーブルで絞ると、いずれも0件になる。dl_definition（Impact×Urgencyの優先度の自動計算）も3テーブルとも0件である。

この構図は、2-1図のフェーズ3（履行）からフェーズ4（クローズ連鎖）にかけて所要時間をどう測るかを表します。

SLA定義も優先度の自動計算も0件のまま維持する。カタログの申請は内容と価格があらかじめ確定しており、障害対応のように緊急度で優先順位を動かす性質を持たない。一律のSLAより、アイテム種別ごとの履行リードタイムを個別に定めるほうが実態に合う。

有効な仕組みとして残るのは2つだけである。sysrule_assignment（sc_req_item、1件「IT Hardware」）による初動の自動振り分けと、sysrule_escalate（sc_task、1件「Default Task Assignment Rule」）である。サービスレベルの管理は、次章以降で定めるアイテム種別ごとの目安リードタイムとstageの滞留監視に委ねる。

SLAが無い前提を体制設計に反映しないと、インシデント管理と同じ感覚で期限を約束してしまい、履行できない目標を掲げることになる。

• 参考：承認は2段構え：1段目だけでは履行が始まらない（RITM/Catalog Task） … 履行が始まるまでの承認構造はここで確認する

2-3. 通知の宛先方針

有効な通知はsc_request9件・sc_req_item18件・sc_task4件である。sc_req_itemの18件のうち13件（72%）はevent_name=activate.life.cycle.migrationで発火するApp Engine StudioのApp Intake申請系であり、カタログ本来の履行通知は残り5件にとどまる。

この内訳は、2-1図のフェーズ3〜4で発生する通知のうち、運用の対象とする範囲を切り出したものです。

本設計は、カタログ履行の通知（5件）だけを運用ルールの対象とし、App Intake系13件は対象外として扱う。同じテーブルの通知一覧を件数だけで見ると、カタログの通知がやたら多く複雑に見えるが、実際にカタログ運用が管理するのは3割に満たない。この区別を知らずに通知件数を評価すると、実態より過大な通知設計をしていると誤解する。

• 参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときはここから追う

第3章：運用体制

3-1. 基本方針

1. カタログオーナーの下にアイテムオーナーを置き、アイテム単位のオーナー制を採用する

2. カタログオーナーはカテゴリ・カタログ全体の統括と公開承認に専念し、個々のアイテムの作成には関わらない

3. 履行チームはassignment_groupの単位で編成し、専任のカタログ運用者は置かない

4. カタログ管理者は技術的な設定変更に専念し、公開の可否判断には関わらない

3-2. 概要図

この図は、2-1の4フェーズ図のうち誰が誰の指示・報告を受けるかという指揮系統だけを取り出したものです。注文・承認・クローズ連鎖の詳細は2-1の図を参照してください。

カタログオーナーがアイテムオーナーへ編集を割り当て、カタログ管理者へ技術的な実行を依頼する。履行チームは注文ごとの処理を独立して行い、結果だけをカタログオーナーへ報告する（ポリシー4、4-1参照）。

3-3. 設計項目

項目決定内容カタログオーナーの人数1名専任アイテムオーナーの割当単位カテゴリ単位（47カテゴリ、active34）カタログ本体の管理2件（Technical Catalog／Service Catalog）とも現状維持、新規カタログは作らない履行チームの編成単位assignment_group（ハードウェア・ソフトウェア・汎用申請の3系統を想定）承認者の割当金額しきい値・部門長の各承認グループに複数名を登録カタログ管理者の人数1〜2名評価のサイクル隔週のカタログレビュー会でまとめて評価

3-4. 詳細設計

カタログオーナーの人数

1名を専任として置く。カタログ運営で中心になるのは、公開承認とカテゴリ整理という、判断の一貫性が求められる場面である。複数人に分散すると、公開基準の運用がぶれる原因になる。

アイテムオーナーの割当単位

カテゴリ単位で割り当てる。本環境のカテゴリは47件（active34件）あり、1人がすべてのアイテムを個別に見る体制は現実的でない。カテゴリごとにオーナーを固定すれば、そのカテゴリの変数設計・価格設定の一貫性を1人が保てる。

カタログ本体の管理

sc_catalogは2件（Technical Catalog、Service Catalog）で、いずれもactiveである。したがって本設計では、両カタログとも現状維持とし、新規カタログの新設は既存カタログでは表現できない利用者層・承認ルートの違いがある場合に限る方針とする。カタログを増やすほど、利用者はどちらを見るべきか迷う。

履行チームの編成単位

itilロール保持者がCatalog Taskの割当対象になる。ハードウェア・ソフトウェア・汎用申請の3系統を想定したassignment_groupで編成し、専任のカタログ運用担当は置かない。専任を置くほど、日常業務（他モジュールの対応）との切り替えコストが増える。

承認者の割当

金額しきい値による承認グループ、部門長承認のいずれも複数名を登録する。承認の内部構造そのものは、既存記事で扱った2段階承認の仕組みをそのまま使う。

カタログ管理者の人数

1〜2名とする。カタログ管理者はUser Criteria・変数セットの技術的な設定変更を担当し、公開の可否という業務判断には関わらない立場とする。技術権限と業務判断を分けることで、設定変更の理由と公開判断の理由を別々に追跡できる。

評価のサイクル

隔週のカタログレビュー会（第10章）で、その期間に上がった公開申請・変更申請をまとめて評価する。申請のたびに個別評価すると、カタログオーナーの負荷が高くなる。

記入例（体制の運用イメージ）

本環境には、カタログアイテムが204件、アクティブなカテゴリが34件（全47件）登録されている。内訳をsc_cat_item.sys_class_nameで見ると、標準の通常カタログ項目が97件で最も多い。ハードウェア資産連携41件とソフトウェア資産連携13件を合わせた資産管理系は54件になる。Record Producer・複合Record Producer・標準変更用Record Producerを合わせたRecord Producer系は46件である。残りはコンテンツ項目4件・Order Guide2件・ウィザード型1件になる。Record Producer系は「サービスを注文する」だけでなく「資産のライフサイクルを起票する」役割も担っている。この構成は、カテゴリ単位でアイテムオーナーを割り当てる本設計（3-4項）と一致しており、資産管理系のカテゴリだけでも専任のアイテムオーナーを置く根拠になる。

• 参考：サービスカタログの概要 … 申請から履行までの全体の流れはここで確認する

この記事の有料部に含まれるもの

4章以降に、運用設計書の記述サンプルを掲載します。

• 第4章 役割分担：RACI（9作業ぶん）と作業ごとの割り当ての意図

• 第5章 運用ルール：アイテム公開基準（履行エンジン必須）・変数設計の標準・承認しきい値・カテゴリ整理基準

• 第6章 サービスレベル：SLA非採用の判断と、アイテム種別ごとの履行リードタイム設計・stage滞留監視

• 第7章 エスカレーション：滞留を起点にした報告基準6つ

• 第8章 通知と報告：通知18件の内訳と、報告設計の実態

• 第9章 品質管理：指標4つと集計方法、変数を含む指標のレポート設計

• 第10章 会議体：4種類の会議の頻度・参加者・議題

• 第11章 教育と引き継ぎ：教育項目と引き継ぎの書式

• 第12章 運用開始の準備：確認項目14件と分野別の完了基準

分量は本文の後半およそ11,000字です。自社で変えるのは公開基準の細部・目標リードタイムの日数・KPIの目標値の3つ。それ以外は据え置きでも運用設計書として使えます。

💰 ここから先は有料エリア