ServiceNowのグラフ定義はどこに入る？ analytics_visualizationとsys_reportの併存を実機で確かめる

作ったはずのグラフが一覧に出てこない。あるいは、同じような画面が2つあってどちらを使えばいいか分からない。ServiceNowのレポート機能を調べていて、グラフの定義を持つテーブルが2系統あることに気づきました。従来のsys_reportが636件ある一方で、analytics_visualizationという別のテーブルに766件が入っています。どちらも空ではありません。

結論：新旧が併存している

先に構造です。

図の色は意味を持たせています。紺が起点、青が従来のテーブル、緑が新しく増えたもの、赤が空になったものです。

グラフの定義を持つテーブルが2つ、ダッシュボードを持つテーブルも2つあります。どちらか一方に統合されたわけではなく、両方に実データが入っている状態でした。

新しいテーブルには766件が入っている

まずanalytics_visualizationを開きます。

名前を見ると、実務で使いそうなものが並んでいました。「Active Changes > 7 days」は7日を超えた変更の件数。「Business Services by Location」は拠点別のサービス分布です。「Requestor API Usage (Monthly)」なら月次のAPI利用状況が見られます。

標準で766件が用意されているという点が重要です。自分でゼロから作らなくても、まず既存のものを探すという順序で使えます。

この数がどれくらいかというと、1日1件ずつ確認しても2年かかる量です。全部を把握するのは現実的ではありません。だからこそ、絞り込む方法を先に決めておく必要があります。

標準で入っていることの意味

数が多いこと自体は目的ではないでしょう。用意されている内容を見ると、ServiceNowが「この製品を使う組織はこういう数字を見たいはずだ」と考えた結果が並んでいます。

7日を超えて滞留している変更。拠点別のサービス分布。月次のAPI利用状況。どれも特定の業種に限らず、ITサービス管理をしていれば知りたくなる数字です。

自分の組織で何を見るべきか迷っているなら、この766件が参考になります。 標準で用意されている＝一般的に必要とされている、と読めるからです。ゼロから指標を設計するより、既存を眺めて取捨選択するほうが早い場面は多いはずです。

19種類のグラフ形式に分かれる

種別で集計すると、内訳がはっきりしました。

縦棒グラフが199件で最多、次いで単一数値の表示が132件、一覧形式が108件と続きます。

上位3つで439件、全体の6割弱を占めます。棒グラフと数値と一覧。この3つがあれば大半の用途は足りる、ということでしょう。

少数派の形式に目を向ける

面白いのは下位のほうです。地図表示のGeomapが3件。カレンダー形式とゲージが各2件。ダイヤルと半円ドーナツは1件ずつでした。

こうした形式は、標準では数件しか使われていません。裏を返すと、存在は知られていないが使える形式があるということです。拠点別の数値を地図に載せる、稼働率をゲージで見せる。ダッシュボードの見栄えを変えたいとき、選択肢として持っておくと役に立ちます。

表記ゆれが1件だけある

集計していて気づいたことがあります。Vertical barが199件ある一方で、vertical_barという値が1件だけ存在していました。

表示用の名前とシステム内部の名前が混在している、という状態です。1件だけなので実害は小さいでしょう。ただ、種別で絞り込んで一覧を作るときには漏れます。自分で集計するときは、この1件が抜けることを頭に置いておく必要があります。

ダッシュボードは28件

ダッシュボード側も見ておきます。

28件の名前を見ると、対象領域が分かります。インシデント管理、ナレッジ管理、サービスカタログ、要求管理といった業務系。MID Server、Instance Scan Results、Workflow Operationsといった基盤系。そして本番環境と非本番環境それぞれのセキュリティ状況を見るものが分かれて用意されていました。従来のダッシュボードにどんなものがあったかは標準ダッシュボード全体像で扱っています。

「Analytics Usage Overview」や「Legacy Usage Overview」という名前も目を引きます。分析機能そのものの利用状況を見るダッシュボードです。どの機能が使われているかを把握する用途でしょう。

メタデータが本体と同じ件数ある

テーブルの件数を並べていて気づいた点があります。

analytics_visualizationが766件で、analytics_visualization_metadataも766件。ぴったり同じです。

1対1で対応していると考えるのが自然でしょう。定義本体とは別に、メタデータを保持する場所が用意されている構造です。何を分けているのかまでは確認していません。列構成を見ていないためです。

ダッシュボード側は少し違いました。analytics_dashboardが28件に対し、analytics_dashboard_metadataは29件。1件多いのです。

理由は分かりません。削除されたダッシュボードのメタデータが残っているのか、本体を持たないメタデータがあるのか。数が合わないという事実だけを記録しておきます。

空になっているテーブルがある

新旧の比較で、もうひとつ気づいたことがあります。

pa_dashboardsが0件でした。Performance Analytics用のダッシュボードを保持するテーブルです。

以前の環境では3件ありました。今回の環境では空です。ダッシュボードの管理先がanalytics_dashboardに移った結果と読めますが、断定はできません。別々に作られた環境同士を比べているだけなので、移行の結果なのか、単に環境の作られ方が違うのかを区別できないからです。

従来のsys_reportも残っている

一方で、従来のsys_reportは636件が残っていました。空になっていません。

つまり現状は、グラフの定義が2か所にあるという状態です。766件と636件。合計すると1400件を超えます。どちらか一方だけを見ていると、探しているグラフを見落とすことになります。

これが移行の途中なのか、役割を分けて併存させる設計なのかは分かりません。片方が旧式で片方が新式、という単純な話ではない可能性もあります。

名前の付け方から用途が読める

766件の名前を眺めていると、命名に規則があることに気づきます。

「Active Changes > 7 days」は条件を名前に入れています。「Business Services by Location」は軸をbyでつなぐ形。「Requestor API Usage (Monthly)」のように期間を括弧で補うものもありました。この3パターンが繰り返し出てきます。

この3パターンを知っていると、探すときに当たりを付けやすくなります。拠点別の何かを見たければby Locationで検索する。月次のものを探すなら(Monthly)で絞る。名前の規則は検索の手がかりになります。

自分で作るときも、この規則に合わせておくと後から探しやすくなります。標準が766件ある中に自作を混ぜるので、命名がばらばらだと自分のものを見失います。

ダッシュボードと可視化の比率

28件のダッシュボードに対して、766件の可視化。1つのダッシュボードあたり27件という計算になります。

もちろん均等に配分されているわけではないでしょう。使われていない可視化も多いはずです。ただ、この比率からは設計の考え方が読み取れます。

部品は多めに用意して、組み合わせは利用者が決める。 ダッシュボードは28件しかありませんが、そこに載せられる部品は766件ある。標準のダッシュボードをそのまま使うのではなく、必要な部品を選んで自分のダッシュボードを組む、という使い方が想定されています。

使われていない部品を見つけるには

766件のうち、どれがダッシュボードに載っているのかは今回確認していません。載っていない部品が多数あるはずです。

これを調べるなら、ダッシュボードと可視化を結ぶテーブルを探すことになります。今回の調査ではanalytics_dashboardとanalytics_visualizationの2つを見ただけで、両者を結ぶ中間テーブルまでは追っていません。ここは次の宿題です。画面から探す操作はAnalytics Centerの操作方法にまとめています。

似た構造は他にもあります。カタログアイテムが実際に注文されているかを調べる話と同じ考え方です。定義があることと、使われていることは別という観点は、どの機能でも共通します。

旧テーブルとの使い分けをどう判断するか

新旧が併存している状態で、実務としてどう判断するか。今回分かった範囲で整理します。

既存のレポートを触るならsys_report側です。636件がそこにあります。過去に作られたものは、まだこちらに入っている可能性が高い。

新しく作るなら、まず画面から1つ作って確かめる。これが確実です。どちらのテーブルに入るかは、使う画面によって変わる可能性があります。

両方を検索する。目的のグラフを探すときは、片方だけ見ると見落とします。766件と636件、合わせて1400件が候補です。

この「両方を見る」は地味に効きます。片方で見つからなかったから作った、というのがいちばん無駄な結末だからです。似たものが既にあるのに気づかず作ると、あとで重複に悩むことになります。

判断に迷ったときの逃げ道

どちらを使うか決められない場合、まず既存を流用するという選択があります。新規に作らず、近いものを複製して条件だけ変える。この方法なら、元のグラフが入っているテーブルに複製が作られるので、系統を意識せずに済みます。

完全に新しい観点のグラフが必要になったときだけ、どちらで作るかを判断する。頻度が下がれば、判断を誤るリスクも減ります。

移行期であることを前提にする

新旧が併存している状態は、たいてい移行の途中です。いずれ片方に寄る可能性があります。

そう考えると、新しく作るものは新しい側に寄せておくのが無難でしょう。ただし今回の調査では、どちらが新しい標準なのかを断定できる材料が得られませんでした。テーブル名からanalytics_が新しいと推測はできますが、確証はありません。

判断を保留するなら、作ったものがどちらに入ったかを記録しておくことをおすすめします。後で移行が必要になったとき、対象が分かっていれば作業が早くなります。

標準の766件をどう棚卸しするか

自分の環境で使えるものを把握したいとき、766件を1件ずつ見るのは現実的ではありません。効率的な絞り方を考えます。

形式で絞る

まず形式を決めます。単一数値なら132件、円グラフなら58件。対象が一気に減りました。ダッシュボードの上部に置く数字を探しているなら、単一数値の132件だけ見れば足ります。

一覧のtype列でグループ化すると、件数が画面に出ます。ここから目的の形式をクリックすれば、その形式だけの一覧になります。

名前で絞る

対象の業務が決まっているなら、名前で検索したほうが早いでしょう。「Incident」で絞る、「Change」で絞る。標準の名前は英語なので、日本語で探しても出てきません。

両方を組み合わせる

実際には、業務で絞ってから形式を見るのが現実的です。インシデント関連の可視化が何件あって、そのうち棒グラフはどれか。この順序なら候補が十分に絞れます。

増えすぎたときにどうするか

766件という数字は、標準だけの件数です。ここに自社で作ったものが加わっていきます。

作りっぱなしにすると、数年で1000件を超えることになります。そうなると探すコストが上がり、結局「新しく作ったほうが早い」となって、さらに増えます。この悪循環はカタログアイテムでも起きる現象です。

対策として考えられるのは3つです。

命名規則を決める。 標準のbyや括弧のパターンに合わせておくと、検索で拾いやすくなります。自社独自の接頭辞を付ける方法もあります。

作る前に探す手順を決める。 「まず既存を検索し、無ければ作る」を運用ルールにします。手間に見えますが、重複を防ぐ効果は大きい。

使われていないものを定期的に見る。 どのダッシュボードにも載っていない可視化は、削除の候補です。ただし削除は影響が読みにくいので、まず「使われていない一覧」を作るところから始めるのが安全でしょう。

調べていて分からなかったこと

正直に書いておきます。今回の調査では判断できなかった点がいくつかあります。

新旧のどちらが正なのか。 テーブル名から推測はできますが、確証がありません。公式の情報を確認するか、実際に作って確かめる必要があります。

メタデータに何が入っているか。 件数が本体と同じであることは確認しましたが、列構成を見ていません。定義本体と何を分けているのかが分かれば、構造の理解が進むはずです。

766件のうち何件が実際に使われているか。 ダッシュボードとの紐付けを追っていないので、休眠している定義がどれだけあるかは不明です。

これらは次に触る機会があれば、そこから見ていきます。分からなかったことを分からないまま書くのは気持ちの良いものではありませんが、確かめずに推測を書くよりは読者の役に立つはずです。

実機を見て気づいたこと

いちばん引っかかったのは、新旧のどちらを見ればいいのか判断材料が無いことでした。テーブルの件数だけでは決められません。766件と636件、どちらも十分に多い。片方が明らかに使われていない、という状態ではありませんでした。

画面から作ったグラフがどちらに入るのかを確かめれば分かるはずですが、今回は読み取りだけにとどめています。ここは次に触るときの宿題です。

メタデータが本体と同数だった点も意外でした。766件に対して766件。設計として、定義とメタデータを必ず対にする方針なのだと読めます。ダッシュボード側で1件ずれていたのは、その方針から外れた例外があるということでしょう。きれいに揃っているものの中に1件だけ違うものがあると、そこに何かの経緯が隠れていることが多いと感じます。

vertical_barの表記ゆれも同じ性質です。198件がVertical barで1件だけvertical_bar。手作業で入れたのか、別の経路で作られたのか。1件だけ違うものは、たいてい理由があります。

こうした細部は公式ドキュメントには載りません。実際に一覧を開いて集計したときだけ見えます。件数を数えるという地味な作業に価値があるのは、こういう発見があるからです。

実務では何に使えるか

グラフを新しく作る前に、まず766件を検索することをおすすめします。

「変更の滞留を見たい」「拠点別の分布を見たい」といった要件は、たいてい誰かが先に考えています。標準で用意されているものが使えるなら、作る手間も維持する手間も省けます。

探すときの手がかり

名前から探すのがいちばん早いですが、種別で絞る方法もあります。

単一数値（Single score）が132件あります。ダッシュボードの上部に大きな数字を並べたいとき、この132件から探すと目的のものが見つかりやすい。一覧形式（List）の108件は、明細を見せたい場面で使えます。

地図やカレンダーのような珍しい形式は数が少ないので、全件見ても手間になりません。まず形式を決めてから中身を探すという順序が効率的です。作ったグラフを配布する方法はPowerPoint出力・共有・定期送信で扱いました。

作る前に決めておくこと

自分で作る場合、どちらのテーブルに入るのかを把握しておく必要があります。新旧が併存している以上、作った先によっては別の画面から見えない可能性があるためです。

検証環境で1つ作ってみて、どちらに入るかを確認する。これが確実です。本番で運用を始めてから「あの画面には出ない」と気づくと、作り直しになります。

従来の記事との関係

このテーマは以前にも扱っています。ダッシュボードが複数テーブルの組み合わせでできていることはダッシュボードは1枚のレコードじゃないで、レポートの4つの軸はレポートの仕組みで書きました。

今回の内容は、それらの続きにあたります。当時扱ったのはsys_reportとsys_dashboardという従来のテーブルでした。そこに新しい系統が加わった、という位置づけです。

グラフを画面から作る手順はData Visualizationsでグラフをゼロから作る手順にまとめています。今回の記事はテーブル側から見た構造の話なので、実際の操作はそちらを参照してください。

Performance Analyticsとの関係は指標設計を5つのテーブルで決める手順で扱っています。指標を定義する仕組みと、グラフとして見せる仕組みは別の層にあります。

この記事で確かめたこと

最後に整理します。

analytics_visualizationに766件、analytics_dashboardに28件が標準で入っていました。可視化は19種類の形式に分かれ、縦棒199件・単一数値132件・一覧108件が上位です。地図やゲージのような珍しい形式も数件ずつ用意されていました。

メタデータを持つテーブルが別にあり、可視化側は766件で本体と同数、ダッシュボード側は29件で本体より1多い。この1件の差は説明できていません。

従来のsys_reportは636件で残っており、新旧が併存しています。一方でpa_dashboardsは0件でした。

種別の値にVertical barとvertical_barの表記ゆれが1件だけあります。集計するときに漏れる可能性があるので、気に留めておくとよさそうです。

確かめられなかったことも4つあります。新旧のどちらが画面に出るのか。両者に参照関係があるか。メタデータの中身は何か。766件のうち実際に使われているものがどれだけあるか。次はここから見ていくつもりです。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• 可視化：数値をグラフや数字として画面に表示すること

• メタデータ：定義そのものではなく、定義に付随する情報

自分の環境で確認するときのURL

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

• /analytics_visualization_list.do … 新しいグラフ定義の一覧

• /analytics_visualization_list.do?sysparm_query=GROUPBYtype … 形式ごとの件数

• /analytics_dashboard_list.do … 新しいダッシュボード

• /sys_report_list.do … 従来のレポート定義

• /pa_dashboards_list.do … Performance Analytics用ダッシュボード

関連記事

• ServiceNow レポート・ダッシュボード完全ガイド — レポート機能の全体像から読む場合はこちらが入口です。

• ダッシュボードは1枚のレコードじゃない（pa_dashboards） — 従来のダッシュボード構造を扱っています。

• Data Visualizationsでグラフをゼロから作る手順 — 実際の作成手順はこちらです。

検証環境と未検証範囲

• 確認した範囲：Australia PDI（OOTB）におけるanalytics_visualization766件の種別内訳、analytics_dashboard28件の名前、analytics_visualization_metadata・analytics_dashboard_metadataの件数、および従来のsys_report636件・sys_dashboard16件・pa_dashboards0件との比較。すべてREST APIと画面の読み取りのみです。

• 確認していない範囲（断定しません）：新旧のどちらが画面に表示されるのか、両者の間に参照関係があるか、メタデータ側の列構成、実際にグラフを作成したときにどちらのテーブルに入るか、pa_dashboardsが0件である理由。これらは別途の検証が必要です。

• 比較対象のZurich環境は別々に作成されたインスタンスです。同一環境をアップグレードした結果ではないため、移行の挙動については何も言えません。