ServiceNowのPerformance Analyticsは何を測る？ 指標設計を5つのテーブルで決める手順

「インシデントの件数を可視化したい」その一言から始まった話が、半年後に「どの数字が正しいのか分からない」で終わることがあります。ServiceNowのPerformance Analytics（PA）は、母集団・測る値・切り口・見せ方を5つのテーブルに分けることでこの食い違いを防ぎます。標準で入っている442本のインジケータをZurichのPDIで実測し、そこから読み取れる設計の型を確認しました。

結論：5つのテーブルが役割を分けている

先に全体像です。

• PAは母集団（インジケータソース）・測る値（インジケータ）・切り口の出どころ（ディメンション）・割り方（ブレークダウン）・見せ方（ウィジェット）という5つのテーブルに役割を分けています。ここを混ぜると、似た指標が部署ごとに増えて数字が合わなくなります。

• 実測件数はインジケータ442件・インジケータソース141件・ブレークダウン108件・ディメンション107件・ウィジェット167件でした。

• 標準442本の分布を見ると、Automated中心・Daily中心・Count中心という偏りがあり、そこに設計の型が現れています。

色は状態を表しています。濃紺は最初に決める母集団（インジケータソース）、青は参照先のテーブル、緑は実際に動いている層（インジケータ・ブレークダウン・収集ジョブ）です。赤は止まっている層で、pa_scores は実測0件でした。紫のウィジェットは指標の計算そのものとは別系統の「見せ方」です。

各テーブルが設計で何を決め、誤るとどんな症状が出るかは上の表のとおりです。

この分かれ方には理由があります。母集団と測る値を別のテーブルに置くのが、PAの設計思想の中心です。「未クローズのインシデント」という母集団を1度定義しておけば、そこから「件数」「平均経過日数」「担当グループ別」といった指標をいくつも作れます。母集団の定義を指標ごとに書くと、条件の食い違いが必ず起きるのが実務の落とし穴です。分けておけば、母集団は1箇所で直せます。

標準442本の型：4つの軸で見る偏り

標準のインジケータを4つの軸で数えると、はっきりした偏りが出ました。

type は Automated が325件、Formula が117件。Manual と External は0件です。素の集計が基本で、比率や差分は数式で作る、という分け方になっています。

frequency は Daily が440件、Monthly が2件。ほぼすべてが日次でした。

direction は Minimize 201件、None 165件、Maximize 76件。「減らしたい」指標が最も多く、良し悪しを持たない指標も4割弱あります。

aggregate は Count が300件で圧倒的多数。次に Sum 86件、Count Distinct 41件。Average は9件しかありませんでした。

実機で気づいたこと

• 収集ジョブ（pa_job_logs）は2週間で1,915件から2,178件に増えていました。ジョブは毎日確実に走っています。それでも pa_scores（実際の値）は依然として0件のままでした。ジョブが「動いている」ことと、値が「残っている」ことは別だと実感します。

• ウィジェット（pa_widgets）は167件で、インジケータ442件の4割弱でした。標準の指標すべてがダッシュボードに直接使われているわけではなく、大半は他の指標を計算するための材料として存在しているとみられます。

• ディメンションの実例には、参照先に業務テーブルを使わず pa_buckets（99件）という PA 自身のテーブルを指すものがありました（Active (Buckets) など）。切り口の元になるのは、必ずしも業務データそのものとは限りません。

購入すると何が手に入るか

ここから先は、この分布から読み取れる設計の原則8個を言葉にします。なぜ日次に寄せるのか、なぜ平均を避けるのか、母集団をどう切るのか。そして、実測したインジケータ1件を例にした指標設計シートと、避けるべき設計をまとめたアンチパターン表を載せています。次に自分たちの指標を設計するとき、そのまま項目を埋めながら使える形にしてあります。