Service Catalogが使われない理由　設計思想で解決する

Service Catalogはフォーム集ではなくサービス提供の入り口

Service Catalogを触り始めると、つい「申請フォームを作る機能」と捉えがちです。ですが、設計の出発点をそこに置くと、後からほぼ確実に崩れます。理由はシンプルで、Service Catalogは“入力画面”ではなく、組織が提供できるサービスを、ユーザーが迷わず選び、期待通りに受け取り、状況を追えるようにするための仕組みだからです。

ServiceNowのSuccess Guideでも、Service Catalogを「利用可能なサービスや提供物を、構造化して分かりやすく見せるもの」「ユーザーが製品やサービスを要求する入口」と定義しています。さらに、良いカタログは一度作って終わりではなく、顧客やビジネスの変化に合わせて見直し続ける“継続プロセス”だと強調されています。

設計思想の中核は期待値のマネジメント

ユーザーがカタログに求めているのは「申請できること」だけではありません。

• 何を頼めるのかがすぐ分かる
• どれくらいで届くのか、何が必要かが分かる
• 申請した後、いま何が起きているか追える
• 余計な入力が少ない
• 間違った申請をしにくい

ここが揃って初めて「使われるカタログ」になります。逆に、フォームだけ増やしても、検索性が悪い、説明が薄い、入力が重い、承認や作業が詰まる、結果として使われなくなる……という流れにハマります。

CSA学習者が押さえると理解が進むポイント

CSAでは細かい設定名の暗記よりも、「なぜその機能があるのか」を押さえる方が伸びます。Service Catalogはまさにその代表で、以下の整理ができると混乱しにくいです。

• ユーザーが注文する
• 申請内容が記録として残る
• 承認や作業が進み、クローズまで追跡できる

この一連の流れは、後半の「実行プロセス」の章で、Flow DesignerやWorkflow、Execution Planがどこにハマるのかまで繋げて説明します。

---

まず決める　カタログ構造と見つけやすさの設計

カタログ設計で最初にやるべきは、個別アイテムの作成ではなく「構造」です。構造が弱いと、検索できない、カテゴリが増殖する、似たアイテムが乱立する、といった運用事故が起きます。

Success Guideでは、カタログ構造がユーザー体験に直結するとしたうえで、トップレベルカテゴリは多すぎないこと、階層も深くしすぎないことをガイドしています。目安として トップレベルは6〜10程度、階層は3段まで という考え方が示されています。

カテゴリ設計のコツは「提供側」ではなく「利用側」の言葉

カテゴリを「ネットワーク」「サーバ」「アカウント」みたいに技術領域で切ると、ITに詳しい人は使えます。でも多くのユーザーは、そういう切り口で依頼しません。

利用者の頭の中はだいたいこうです。

• 入社や異動で必要なもの
• PCや周辺機器が欲しい
• アプリの利用申請をしたい
• パスワードやアクセスで困っている
• 施設や備品を手配したい

この“利用者の目的”で分けると、迷子が減ります。結果として、申請ミスや差し戻しも減り、運用コストも落ちます。

同じ名前の似たアイテムを作らないための最低限のルール

構造が固まったら、次はアイテム乱立を防ぐルールです。ここはガチガチに厳しくするというより、最低限の共通言語を持つのが効きます。

• アイテム名は「利用者が探す言葉」で
• 説明文に、対象者、前提条件、目安時間、成果物を入れる
• 似た申請は統合し、分岐は入力条件や実行プロセスで吸収する

この段階で「カタログはプロダクト」という意識に切り替えるのがポイントです。誰がオーナーで、どの指標で改善するかまで決めておくと、後から強いです。Success Guideでも、サービスオーナーなど複数の役割を含む設計チームや、継続改善の仕組みを推奨しています。

---

迷子を防ぐ　入力体験と変数設計の基本

カタログが使われない理由の上位に「入力がしんどい」があります。入力が長い、質問が分かりにくい、同じ情報を何度も聞かれる。ここを減らすだけで、利用率は現実に上がります。

そのための設計思想は次の2つです。

• 必要な情報だけ聞く
• 同じ質問は再利用する

変数は質問であり、データ品質の入口

ServiceNowでは、カタログアイテムの質問は「変数」で表現します。変数には様々なタイプがあり、入力形式を適切に選ぶことで、後続の作業が一気にラクになります。例えば参照変数は別テーブルのレコードを参照でき、ユーザーを選ぶならUserテーブルを参照する、といった使い方が示されています。

ここで大事なのは、「入力が自由すぎると後で詰む」という現実です。

• 申請対象ユーザーは自由入力ではなく参照で選ばせる
• ソフト名は選択肢や参照で揺れを減らす
• 日付は日付型を使い、文章入力をやめる

こういう小さな積み重ねが、実行側の手戻りを消していきます。

変数セットで「共通質問」を部品化する

実務で強いのが変数セットです。複数アイテムで同じ質問を使い回せる仕組みで、変更があったときに一括で反映できるため、管理コストが激減します。ドキュメントでも、変数を個別に関連付けるのは反復作業でミスも増え、変数セットは再利用と変更反映を容易にすると説明されています。

さらに、変数セットにはクライアントスクリプトやUIポリシーを関連付けられる点も重要です。つまり「この一連の質問にはこの動きを必ず付ける」という標準化ができます。

よくある共通質問の例はこんな感じです。

• 申請者情報
• 申請対象者情報
• 連絡先
• 希望日
• 理由や背景

これらを部品化しておくと、カタログの拡張にも強くなります。

Order Guideは「まとめ買い」を設計する道具

入社時のPC、アカウント、ソフト、入館証…みたいに、セットで頼むことが多いものはOrder Guideが向きます。Order Guideは、条件を評価して注文すべきアイテムを決め、Order Guideで入力した情報を“共通情報”として各アイテムに渡せると説明されています。

設計思想としては、こうです。

• ユーザーの目的は「入社準備を終わらせたい」
• 提供側の内部都合では複数部署に跨る
• だからユーザー体験としては1回の入力で完結させる

Order Guideは、まさにこのギャップを埋める機能です。

---

届け切るための設計　承認と実行プロセス

カタログは「頼める」だけでは意味がありません。届くまでの流れが設計されていないと、結局メールや口頭に戻ります。

ServiceNowのドキュメントでは、ユーザーがカタログアイテムを注文すると要求が作成され、その要求は「実行プロセス」に従う、と説明されています。そして実行プロセスの定義には Flow Designerのフロー、Workflow、Execution Plan を使えること、準備として実行グループ設定やプロセス定義、アイテムへの割り当てが必要だと書かれています。

実行プロセス設計の考え方は三層構造

実務で分かりやすい整理は、次の三層です。

• 承認が必要か
• 作業は誰が何をするか
• 終了条件と通知はどうするか

承認を増やしすぎると遅くなる一方で、削りすぎると統制が崩れます。ここは「なぜ承認が必要なのか」を言語化して、必要最小限に落とすのが基本です。承認が必要なものは、金額、権限、リスクで判断しやすいです。

標準ワークフローを少なく保つ発想

Success Guideには、ワークフロー管理の黄金ルールとして、再利用できる標準ワークフローを最小限にする考え方が紹介されています。目安として小中大の3つの標準ワークフローを持つ、という発想です。

これ、かなり実務に効きます。

• 小　承認なし、タスク1〜2個、即時完了
• 中　承認あり、タスク複数、関係部署1〜2
• 大　承認多段、調達や外部連携、長期タスク

アイテムごとに専用フローを作り始めると、保守で破綻しやすいので、「例外は例外として扱う」意識が大事です。

Execution Planは直線的な作業を強くする

Execution Planは、シンプルで直線的なプロセスを記述でき、タスクを持てる仕組みだと説明されています。例えばPC提供のために複数タスクを順に実行する、といった使い方です。
また、Execution Planにはタスクテンプレートが含まれ、タスクごとに担当グループを定義できる、といった説明もあります。

「毎回ほぼ同じ手順で進む」ものはExecution Planの設計思想と相性が良いです。逆に分岐が多い、外部条件に左右される、承認が複雑、というものはFlowやWorkflowの方が扱いやすいことが多いです。

実行プロセスが弱いとカタログは信用を失う

ユーザーから見ると、申請後にこうなるのが最悪です。

• 申請したのにステータスが動かない
• 誰が対応しているか分からない
• いつ終わるか分からない
• 追加情報を後出しで求められる

これは設計の問題で、入力設計と実行設計が繋がっていないのが原因です。必要情報を先に集め、タスクの担当と完了条件を決め、通知のタイミングを整える。ここまで含めて「カタログアイテム」です。

---

運用と改善が本番　ガバナンスとメンテナンス設計

最後にいちばん大事な話です。Service Catalogは作った瞬間がピークになりがちです。放置すると、カテゴリ増殖、重複アイテム、古い説明、壊れたフロー、例外対応の山、という状態になります。

Success Guideは、世界水準のカタログは一度きりの成果物ではなく、継続的に最適化するための設計、ガバナンス、メンテナンスプロセスが必要だと明言しています。

変更要求を受ける入り口を決める

運用が荒れる原因のひとつは、「誰でも思いつきでアイテムを増やせる」ことです。だから、最低限これを決めます。

• 追加や変更の窓口
• レビュー観点
• オーナーと責任範囲
• 廃止の基準

「増やす」より「統合する」「廃止する」を当たり前にするのが、カタログを健康に保つコツです。

権限設計は小さく始めて段階的に広げる

Success Guideでは、編集権限を段階化する考え方が紹介されています。例えばカタログ管理全般を扱う管理者、カテゴリやアイテムを扱う管理者、編集者、といったレベル分けです。

そして変数セットでも、アクセスは変数セットレベルと変数レベルで検証され、セット側でブロックされると変数側の設定が上書きされる、といった挙動が説明されています。
このあたりは「権限をゆるくすると事故る」「厳しすぎると改善が止まる」のバランスなので、最初は狭く、運用が回ってから広げるのが現実的です。

どこを見て改善するか

改善は気合では続きません。見る指標を決めて、定期的に直す仕組みに落とします。考え方としてはこうです。

• 探せているか
• 入力で詰まっていないか
• 承認で止まっていないか
• タスクが滞留していないか
• 完了までの体感が悪くないか

Success Guideでは、成功指標や予兆指標を定義してギャップを特定する重要性にも触れています。

---

まとめ

Service Catalog設計の基本思想は、「フォームを作る」ではなく サービス提供の体験を設計する ことです。具体的には次の順で考えるとブレにくくなります。

• 入口としてのカタログを、利用者の言葉で構造化する
• 入力は必要最小限にし、変数と変数セットで標準化する
• Order Guideで目的ベースのまとめ申請を作り、迷いを減らす
• Flow DesignerやWorkflow、Execution Planで実行プロセスを設計し、届くまでの責任を持つ
• ガバナンスと継続改善を前提に、増やすより整える運用を作る

CSAの学習でも、Service Catalogは「機能名を覚える」より、「なぜその機能が必要なのか」「要求が作られてから何が動くのか」を筋で理解した方が伸びやすい領域です。理解の土台ができたら、あとはハンズオンで触るのが最短です。

体系的に学べる教材の一例としては、UdemyのServiceNow CSA向け講座や、Service CatalogとFlow Designerをまとめて扱う入門講座が役に立ちます。読むだけだと曖昧になりやすい「変数の設計」「実行プロセスの割り当て」「標準化の考え方」を、画面操作で確認できるのが強みです。