メインコンテンツへスキップ
見出し画像

ServiceNow標準ダッシュボード全体像:どんなダッシュボードがあるか


    ServiceNow には、最初から使えるダッシュボードがいくつも入っています。ところが「どこに」「どんなものが」あるのかは、意外と整理されていません。自分でゼロから作る前に、まず標準で何が揃っているかを知っておくと、遠回りをせずに済みます。

    この記事は、その「標準で入っているダッシュボード」を1つずつ紹介していく連載の第1回です。今回は個別の中身に入る前に、全体像の調査に徹します。PDI(無料の検証環境)の中を実際に開き、REST で件数を数え、どんな系統のダッシュボードが何本あるのかを確かめました。

    読み終えたときに、「サブスクの利用状況を見たいならこれ」「対応の速さを見たいならこれ」と、目的から入口を引ける状態を目指します。次回以降は、ここで挙げたダッシュボードを1つずつ、実画面つきで取り上げる予定です。まずは地図を手元に置くところから始めましょう。

    ダッシュボードは、レポートを並べて「今どうなっているか」を1画面で見せる仕組みです。ゼロから作ることもできますが、その前に標準を眺めると、作らずに済むものが意外と多い。すでにある地図を無視して新しい道を引くのは、もったいない話です。だからまず、初期状態で何が用意されているのかを棚卸ししました。

    この記事は、ServiceNow の PDI(Personal Developer Instance、無料の個人検証環境)Zurich リリース・OOTB(初期設定)で確認した実測メモです。件数・項目は REST と実画面で確認しました(確認日 2026-07-20)。本番環境では設定が異なります。

    ダッシュボードは大きく3系統に分かれる

    調べてみると、ServiceNow の標準ダッシュボードは1か所にまとまっているわけではありませんでした。保管しているテーブルが違い、性格も違う。大きく3つの系統に分かれます。


    画像

    1つ目は「レポートダッシュボード」。sys_dashboard というテーブルに入っていて、実測で active が16本ありました。Incident や Change といった業務プロセスの現状を、レポートを並べて一望するタイプです。2つ目は「Performance Analytics(PA)」。pa_dashboards に3本あり、加えて PA 専用のホームページ群が別にあります。時系列の KPI やスコアカード、サブスクリプションや CMDB の健全性を扱う、分析寄りの系統です。3つ目は「ホームページ」。sys_portal_page に54本あり、gauge やレポートを並べた個人・管理者向けの画面が中心です。


    画像

    同じ「ダッシュボード」という言葉でも、指しているものが3種類ある。この前提を押さえておくと、あとで迷いません。以降は、この3系統をそれぞれ掘り下げます。

    レポート・ダッシュボード・ホームページの関係

    ここで、紛らわしい3つの言葉を整理しておきます。ServiceNow を触りはじめると、「レポート」「ダッシュボード」「ホームページ」が似た文脈で出てきて、どれがどれだか分からなくなりがちです。関係を一度整理すると、3系統の話もすっと入ります。

    いちばん小さな単位が「レポート」です。1つのグラフ、1つの表、1つの数字。特定のデータを1つの見え方で切り出したもの、それがレポートにあたります。棒グラフの「優先度別の未対応件数」も、一覧表の「今日作成された変更」も、どれも1枚のレポートです。

    その「レポート」を複数まとめて1画面に並べたものが「ダッシュボード」です。関連する指標を隣り合わせに置いて、一目で状況を掴めるようにする。Incident Overview なら、件数のグラフ、優先度の内訳、担当ごとの負荷といったレポートが、1画面に集まっています。今回数えた sys_dashboard の16本は、この「レポートの集合体」にあたります。

    「ホームページ」は、ダッシュボードの古い親戚のような存在です。gauge(ゲージ)と呼ばれる表示部品やレポートを並べた、ログイン直後に開く個人・管理者向けの画面を指します。ServiceNow の歴史では、この gauge を並べるホームページが先にあり、あとから多機能なダッシュボードが加わりました。近年は gauge がウィジェットに置き換わり、ホームページよりダッシュボードが前面に出てきています。とはいえ sys_portal_page に54本という数からも分かるとおり、ホームページの仕組みは今も土台として残っています。

    Performance Analytics は、これらとは少し毛色が違います。ある時点の断面を見せるだけでなく、指標を毎日ためて時系列で追う分析の基盤です。だから「先月と比べてどうか」「このペースだと目標に届くか」といった、時間軸の問いに強い。Subscription や CMDB 健全性のように、継続して溜めた数字を読むダッシュボードは、この PA 側に置かれています。

    レポートダッシュボード:sys_dashboard の性格

    まず sys_dashboard から。ここは「業務プロセスの状況を、複数のレポートで一望する」ための系統です。名前を見ると性格がよく分かります。Asset・Change・CMDB・Incident・Problem・Release・Service Catalog といった、ITSM でおなじみのプロセスが並びます。

    このタイプの良さは、1画面で「今どうなっているか」を掴めることにあります。たとえば Incident Overview を開けば、未対応の件数や優先度の分布が、いくつかのレポートとしてまとまって出る。個別のレポートを1つずつ探しに行かなくても、関連する指標が最初から集約されています。運用の朝会で「まずここを見る」といった使い方に向いた系統です。

    もう1つの特徴として、「プロセスごとに1枚ずつ用意されている」点が挙げられます。Incident には Incident の、Change には Change の Overview がある。担当する領域のダッシュボードだけを開けば、自分の守備範囲の状況が過不足なく見える設計です。複数プロセスを横断して1枚で見たいときは、標準のままだと物足りないこともあります。そういう場合に効くのが、Overview や Overview Wide という総合版です。まずはプロセス単位、必要なら総合版、という二段構えで捉えると迷いにくくなります。

    数を数えると active で16本。多すぎず、少なすぎない本数です。この16本を、名前の付き方で3タイプに整理できました。

    sys_dashboard の16本を3タイプで読む

    sys_dashboard の一覧を実機で開くと、16本の名前が並びます。各行には、そのダッシュボードのレイアウト(行数・列数)も表示されていました。


    画像

    名前をよく見ると、末尾の言葉に規則があります。「◯◯ Overview」「Weekly ◯◯ Trend」「Performance / Throughput」。この語尾で、ダッシュボードの役割が読み取れます。3タイプに分けて眺めます。

    Overview系:現状を一望する

    いちばん多いのが「◯◯ Overview」です。Asset Contract Overview、Asset Overview、Change Overview、CMDB Overview、Incident Overview、Problem Overview、Release Overview。加えて Overview、Overview Wide という総合版もあります。

    これらは「今の状態」を切り取るタイプです。未対応がいくつあるか、優先度はどう分布しているか、担当ごとの負荷はどうか。時点の断面を、複数のレポートで見せます。日々の運用で最初に開くのは、たいていこの Overview 系です。見たいプロセスの名前に「Overview」が付いているものを探す、と覚えておけば入口に困りません。

    Weekly Trend系:週次の推移を追う

    次に「Weekly ◯◯ Trend」。Weekly Change Trend、Weekly Incident Trend、Weekly Problem Trend の3本がありました。

    こちらは「時間の流れ」を見るタイプです。今週は先週より増えたのか減ったのか、傾向が上向きか下向きか。断面ではなく推移を追うので、Overview 系と組み合わせると「今どうか」と「どう変わってきたか」の両方が見えます。改善の効果を確かめたいときに役立つ系統です。週明けに先週ぶんを振り返る、といった定例の使い方にはまります。

    Performance・Throughput系:速さと処理量を見る

    3つ目が Incident Performance と Incident Throughput です。名前のとおり、対応の「速さ」と「処理量」に焦点を当てます。

    Performance は、対応にかかった時間や SLA の達成度など、質のスピードを扱う想定です。Throughput は、どれだけの件数をさばいたか、流量を扱います。運用チームの実力を測るとき、この2つは補い合います。速く回っているか、量をこなせているか。Overview で現状、Trend で推移、Performance と Throughput で速さと量。この4つの視点が揃うと、Incident 管理はかなり立体的に見えます。

    なお OLAP という1本もあり、これは多次元集計の枠組みに関する特殊な位置づけです。今回の調査範囲では中身の詳細まで踏み込んでいません。

    Performance Analytics と Subscription Overview

    2つ目の系統、Performance Analytics に移ります。pa_dashboards には Subscription Overview、Custom Table Subscription Overview、Custom Application Inventory の3本がありました。加えて PA 専用のホームページ群として、CMDB の健全性(Compliance / Completeness / Correctness)や、Incident の各種 KPI、Scheduled Jobs の状況などが用意されています。

    PA のホームページ群には、ほかにも見どころがありました。CMDB の健全性は Compliance・Completeness・Correctness という3つの軸で見られます。ほかにも、サービスやリレーションシップの健全性を見るもの、Incident を Overview・Open・Resolved・KPI・ヒートマップと角度を変えて見るものが並びます。CMDB を整えたい人にも、Incident を深く分析したい人にも、この PA 側の品揃えは心強い土台です。ただし、これらを開いて数字を読むには、Performance Analytics 側でデータが溜まっている前提が要ります。今回の PDI では溜まりが薄く、中身の紹介は次回以降に回しました。

    このうち、実機で開けたのが Subscription Overview です。


    画像

    画面には「Subscription Status」「Allocated」「Unmapped applications with custom tables」というカードと、「Subscriptions」の一覧が並びます。何をするダッシュボードかというと、保有しているライセンス(サブスクリプション)と、実際の利用状況を突き合わせて眺めるものです。契約したぶんをどれだけ使っているか、割り当てはどうか、といったライセンス管理の入口になります。

    ライセンス管理は、地味ですが効いてくるテーマです。使っていないぶんを払い続けていないか、逆に上限に近づいていないか。こうした「保有と利用のギャップ」を感覚ではなく数字で押さえられると、契約の見直しや増減の判断がしやすくなります。Subscription Overview は、その突合を1画面で見せる場所という位置づけです。本番で数字が入っていれば、割り当ての過不足がひと目で分かります。

    ただし今回は PDI なので、数値は空か 0 でした。画面の上部にも「In a non-production environment, your subscription allocation counts will not match with production」と注記が出ています。本番以外ではライセンスの数が本番と一致しない、という断りです。だから今回は「数字が読める」状態というより、「どんな枠組みで何を見るダッシュボードか」を確かめた、という位置づけになります。本番で開けば、ここに実際の保有数と利用数が入り、突合できます。

    気になるテーマ別・対応ダッシュボード

    ここまでを踏まえて、「こういうことを知りたいとき、どれを見ればいいか」を対応表にまとめました。目的から引ける形にしておくと、いざ必要になったときに探し回らずに済みます。代表的なテーマを4つ取り上げます。


    画像

    サブスクリプションの状況を知りたい

    Subscription Overview(Performance Analytics)が入口です。保有ライセンスと利用の突合を見る画面で、実画面は先ほどの sn-02 のとおり。ライセンスのコンプライアンスや使い切りの判断に使います。

    ジョブの実行状況を知りたい

    PA のホームページにある「PA CMDB Health Scheduled Jobs」が該当します。CMDB の探索や健全性チェックといった、定期実行ジョブの状況を見るためのものです。ジョブが滞っていないか、想定どおり回っているかを確かめる入口になります。

    パフォーマンスの状況を知りたい

    先ほどの Incident Performance と Incident Throughput(sys_dashboard)です。対応の速さと処理量を見ます。運用のスピードや負荷を掴みたいときは、この2本が近道です。

    ポータルの閲覧は標準に専用が無い

    正直に書きます。「ポータルの閲覧状況(誰がどれだけ Service Portal を見ているか)」を専門に見るダッシュボードは、この PDI の OOTB では見当たりませんでした。Service Portal の利用分析は、別のプラグインや機能を有効化して初めて揃うタイプの領域です。標準のまま探しても専用の1枚は出てこないので、そこは無理に「ある」とは言えません。必要なら、該当機能の有効化を検討する、という前提になります。

    本数(16 / 3 / 54)をどう受け止めるか

    3つの数字には、それぞれ意味の重みが違います。同じ「本数」でも、指しているものの粒度がそろっていない点は、最初に押さえておきたいところです。

    sys_dashboard の16本は、どれも「プロセスを一望する」目的がはっきりした、粒のそろったダッシュボードでした。この記事から始める連載で1つずつ紹介する主役は、ここになります。数が手ごろで、名前から役割も読める。特集の対象として扱いやすい集まりです。

    pa_dashboards の3本は少なく見えますが、Performance Analytics はこの3本だけではありません。PA 専用のホームページ側に、CMDB 健全性や Incident 分析など多くの画面が控えています。数字の3は「モダンビューアで開く PA ダッシュボード」の本数、と捉えるのが正確です。

    sys_portal_page の54本は、少し性格が異なります。この中には、役割ごとの既定ホームや、各機能が用意した個別ページが数多く含まれます。つまり54本すべてが「読者に薦めたい特集ダッシュボード」というわけではありません。土台として多く存在する、という事実として受け止めるのがちょうどよい読み方です。

    次回から1つずつ実画面で紹介する

    今回は地図づくりに徹しました。3系統があり、sys_dashboard に16本、pa_dashboards に3本、sys_portal_page に54本。名前の語尾で役割が読め、テーマから入口が引ける。ここまでが全体像です。

    次回からは、この地図の上を1本ずつ歩きます。まずは日々の運用でよく開く Incident Overview あたりから、実画面つきで中身を確かめる予定です。Subscription Overview のように、本番だと数字が読めるものは、枠組みと読み方を丁寧に取り上げます。個別回では、ダッシュボードを開いた画面をそのまま載せ、どのレポートが何を映しているかを1つずつ読み解きます。標準のまま使えるのか、少し手を入れると便利になるのか、その勘所も添える予定です。地図を手にした状態で個別を見ると、「これは3系統のどこの、どのタイプか」が分かるので、頭に入りやすくなります。

    その他、実機で確認した記録

    用語

    • sys_dashboard … レポートダッシュボードのテーブル。業務プロセスの Overview / Trend / Performance を保持(実測 active 16本)

    • pa_dashboards … Performance Analytics のダッシュボード(実測3本)。時系列KPIやサブスクを扱う

    • sys_portal_page … ホームページのテーブル(実測54本)。gauge やレポートを並べた個人・管理者ページ

    • gauge … ホームページに置く古くからの表示部品。近年はダッシュボードのウィジェットに置き換わりつつある

    • Subscription Overview … 保有ライセンスと利用を突合する PA ダッシュボード

    調べるときの入口URL(先頭に自分のインスタンスを付ける)

    • /sys_dashboard_list.do … レポートダッシュボードの一覧(16本の名前を確認)

    • /pa_dashboards_list.do … Performance Analytics のダッシュボード一覧

    • /sys_portal_page_list.do … ホームページの一覧

    実測の要点(再掲)

    • 標準ダッシュボードは3系統。sys_dashboard 16本 / pa_dashboards 3本 / sys_portal_page 54本(いずれも実測)

    • sys_dashboard の16本は Overview系・Weekly Trend系・Performance/Throughput系に整理できる

    • Subscription Overview は保有ライセンスと利用の突合を見る画面。PDI では数値が空/0

    • ポータル閲覧の専用ダッシュボードは本PDIのOOTBでは見当たらず

    検証範囲とおことわり

    • 件数・名称・テーブルは PDI(Zurich / OOTB)の REST と実画面による実測です。

    • 個別ダッシュボードの中身(各ウィジェットの数値)は、Subscription Overview 以外は本記事では未掲載です。次回以降に実機で開いて取り上げます。

    • Subscription Overview の数値は、PDI が本番でないため空/0でした。本番の数値そのものは検証範囲外です。

    • 「ポータル閲覧の専用ダッシュボード」の有無は本PDIのOOTBでの確認です。プラグイン有効化で増える可能性は範囲外です。

    関連記事

    参考リンク

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ