誰も頼んでいないカタログを洗い出す手順：死蔵率98.6%の実測

サービスカタログに公開しているアイテムのうち、実際に注文されているのは何割でしょうか。答えを持たずに運用している現場は少なくありません。カタログは一度公開すると、削除や統合を後回しにしがちだからです。

このPDIでは、Active なカタログアイテム148件のうち、直近180日で注文があったのはわずか2種類でした。残り146件、比率にして98.6%が「公開されているが誰も頼んでいない」状態です。拍子抜けするほど低い数字です。この数字の中身を、公式ドキュメントの基本知識と実機の画面から順に説明します。

この記事で分かること

• サービスカタログのアイテム（sc_cat_item）と注文（sc_req_item）が公式にどう結びついているか

• Active な148件のうち、直近180日で注文があったのは何件か（実機の実測）

• 一覧のフィルタだけで分かること・分からないこと

• 自分の環境で同じ棚卸しをするための判定スクリプト（有料部）

サービスカタログの基本：アイテムと注文の関係

サービスカタログに並ぶ1件1件はsc_cat_itemというテーブルのレコードです。利用者が「注文する」ボタンを押すと、その申請はsc_request（リクエスト）と、そこにぶら下がるsc_req_item（リクエスト明細・通称RITM）として作成されます。RITMはcat_itemという参照フィールドで、注文元のカタログアイテムに1件ずつ紐づきます。つまり「あるアイテムが注文されたかどうか」は、RITM側のcat_itemを数えれば分かる設計です。

公式のService Catalog items（Zurich）では、カタログアイテムをハードウェア・ソフトウェア・サービスなど「注文可能な単位」として定義しています。アイテムには複数の種類があり、単純な申請フォームだけのものから、レコードプロデューサーのように別テーブルへ直接レコードを作るものまで幅があります。

詳しい分類はTypes of catalog items（Zurich）を参照してください。

sc_cat_itemには、棚卸しで手がかりになる2つのフィールドがあります。ひとつはowner（参照フィールド）で、そのアイテムの担当者を指します。

もうひとつは注文後の処理を決める仕組みです。レガシーワークフローを指すworkflowと、Flow Designerのフローを指すflow_designer_flowの2種類があります。どちらか一方でも設定されていれば、注文時に承認やタスク生成が走ります。

両方とも空だと、注文フォームだけが存在して裏側の処理が組まれていない状態になります。

ワークフローエディタの仕組みはWorkflow editor（Zurich）にまとまっています。Flow Designerの構造はFlow Designer Architecture Overview（Zurich）で説明されています。

実機で確かめる：Active なカタログアイテムの数

Catalog Items の一覧を開き、Active列で=trueを指定すると、公開中のアイテムだけに絞り込めます。

このPDIではsc_cat_itemが合計198件、そのうち Active が148件でした。一覧の左上パンくずにはAll > Active = trueと表示され、画面下部の件数表示でも148件であることを確認できます。

いっぽう、実際に申請されたRITM（sc_req_item）は合計8件しかありません。直近180日に絞ると3件で、対象になったアイテムの種類は2種類でした。148件のActiveアイテムに対して、直近180日で注文が付いたのはたった2種類。この対比が、次の死蔵率の土台になります。

カタログアイテムを新規作成する画面には、Ownerフィールドが標準で用意されています。

デフォルトのオーナーには作成者のユーザーが入りますが、値を空欄のまま保存することもできます。運用中のアイテムでこの欄が空だと、廃止や統合の判断を誰に確認すればよいかが分からなくなります。

この点は後半で数値を示します。

「注文が無い」＝「不要」と即断できない理由

98.6%という数字だけを見ると、「残り146件をまとめて非公開にすればいい」と考えたくなります。ただし、この判定には見落としやすい前提があります。理由は3つです。

まず、カタログアイテムには公開範囲を制御するUser Criteriaという仕組みがあります。特定の部署や役職にだけ見えるよう絞り込まれているアイテムは、そもそも大多数の利用者の目に触れません。注文が無いのではなく、見えていないだけという可能性があります。設定方法は公式のApply user criteria to items and categories（Zurich）で説明されています。

次に、この記事の集計はsc_req_itemのcat_itemフィールドだけを見ています。複数アイテムをまとめて注文するOrder Guideや、レコードプロデューサー経由で作られたリクエストは、cat_itemに直接ひもづかないことがあります。

この経路を通った注文は、今回の集計から漏れます。

さらに、180日という判定期間そのものにも前提があります。年に1回だけ申請されるような季節性のあるアイテム（年度末の機材更新など）は、180日という窓では「死蔵」に見えてしまいます。

これら3つの理由から、146件という数字は棚卸しの対象候補であって、即座に非公開にしてよいリストではありません。一覧のフィルタでどこまで裏付けが取れるか、そして画面だけでは足りない部分をどう補うかを、ここから先で説明します。