ServiceNow CSAのPlatform Analytics対策｜Reporting・Indicator・Dashboardの使い分けガイド

ServiceNow CSAの業務機能では、Platform Analyticsが出てきます。Reporting・Performance Analytics・Indicator・Data visualization・Dashboard…と似た言葉が並び、「結局どれをいつ使い、単発の集計と継続的なKPI追跡をどう区別し、試験でどう判断するのか」が掴みにくい——そう感じている方は多いはずです。

この記事は、CSAで問われるPlatform Analyticsを、①そもそも何をする仕組みか → ②これがないと現場で何が起きるか → ③やりたいことから使う要素を選ぶ早見表の順で理解するための記事です。用語の暗記ではなく、模試で迷わない判断軸を持ち帰ることをゴールにします。

▶ この分野の模擬試験を無料・登録不要で解く
CMDB・データ移行など分野別に分けた、AI生成のCSA模試です

そもそもPlatform Analyticsとは

Platform Analyticsは、運用データをグラフやKPIとして可視化・分析するための新しい分析体験です。従来の Reporting（単発の集計レポート）と Performance Analytics（継続的なKPI追跡）を、1つのダッシュボード体験にまとめたものだと考えると整理できます。主な構成要素は次のとおりです。

• Data visualization：1つのグラフや数値として表示する「個々の部品」。旧来のReportやPA widgetを統合した表示単位
• Dashboard：複数のData visualizationやFilterを並べて共有する「入れ物（画面）」
• Indicator（Performance Analytics）：定期的にスコアを収集して蓄積するKPI。時系列の傾向を追える
• Data source：可視化の元データ。table（現在のレコードを直接集計）か indicator（収集済みのKPIスコア）かを選ぶ
• Breakdown：indicatorのスコアを部門・カテゴリなどの軸で分解して見る切り口
• Inline editor / Technical editor（UI Builder）：ダッシュボードの作り方。標準ウィジェットを並べるなら前者、scriptやdata bindingが必要なら後者でtechnical dashboardを作る

CSAで繰り返し問われる本質は、「今の状態を1回見る（集計）」と「継続的にKPIを追う（傾向）」の違い、そして「部品（Data visualization）と入れ物（Dashboard）の役割の違い」です。次の事故を見ると、分析の仕組みがないと何が起きるか分かります。

これがないとどうなる ——「数字が人によって違い、悪化に半年気づけなかった話」

ある運用チームは、Incidentの件数やSLA達成率を、各自がReportやExcelでその都度集計して会議に持ち寄っていました。ところが、同じ「今月のSLA達成率」が、集計した人によって数字が違う。条件の取り方がバラバラだったのです。さらに、毎回「今の状態」を出すだけで過去を保存していなかったため、「先月より良くなったのか悪くなったのか」が誰にも答えられませんでした。

結果、対応時間がじわじわ悪化していたのに、誰も傾向に気づけず、経営から指摘されて初めて半年分の悪化トレンドが見えたのです。これは継続的な分析の仕組みがないと起きることの典型です。Platform Analyticsがあれば、定義をそろえたKPIを定期収集し、傾向と内訳を1画面で共有でき、悪化のサインに早く気づけたはずでした。

だからCSAはPlatform Analyticsを問う ——鍵は「集計か、継続的なKPI追跡か」

こうした「数字のばらつき」「傾向の見落とし」を防げるかを確認するため、CSAの試験範囲にPlatform Analyticsが含まれています。問われるのは画面操作の暗記ではなく、「今を1回見れば十分なのか（table直の集計）」「継続して傾向を追いたいのか（indicator＝Performance Analytics）」を選び分けられるか、そして新しいPlatform Analytics体験で、どの部品をどこに置くかを理解しているかです。

この先は、(1)迷ったとき立ち返る判断早見表、(2)主要な要素を「事故 → 放置するとどうなる → どう使い分けるか → 改善後」で、の順に、模試で迷わない判断軸を作っていきます。

Platform Analytics 判断早見表（迷ったらここに戻る）

Platform Analyticsの問題は、やりたいこと（問題文）と使う要素を結べれば解けます。次の早見表が、この記事全体の地図です。各要素は後の章で事故付きで深掘りします。

ここからは、主要な要素を「実際に起きがちな事故」から見ていきます。事故の形を知っていると、選択肢の言い換えに惑わされなくなります。

Data visualization と Dashboard：部品と入れ物を分ける

現場で起きる事故：「ダッシュボードを作って」と頼まれたのに、グラフを1個だけ作って「できました」と共有。逆に、1つのKPIを見せたいだけなのに、毎回ダッシュボードごと新規作成して画面が増えすぎた。

放置するとどうなる：部品（個々のグラフ）と入れ物（画面）の役割を取り違えると、共有の単位がちぐはぐになり、似たダッシュボードやグラフが乱立して管理できなくなります。

CSAでこう使う：Data visualizationは、tableやindicatorのデータを1つのグラフ・数値として表示する個々の部品です。Dashboardは、そのData visualizationやFilter、タブを複数並べて共有する入れ物（画面）です。「1つの指標＝部品」「まとめて見せる画面＝Dashboard」と切り分けます。

改善後：再利用したい指標は部品として作り、用途ごとにDashboardへ並べ替えられ、共有とメンテナンスが整理されます。

早見表の該当行：「1つの指標を見せたい」→ Data visualization。「複数をまとめて共有」→ Dashboard。

Indicator（Performance Analytics）：傾向を追うなら収集して蓄積する

現場で起きる事故：冒頭で紹介した「悪化トレンドに半年気づけなかった」事故がこれです。毎回その場でtableを集計していたため、過去のスコアが残らず、時系列の変化を追えませんでした。

放置するとどうなる：「今の値」を出すだけでは、傾向（良くなっている／悪化している）は分かりません。スナップショットを蓄積していないと、改善活動の効果測定も、悪化の早期検知もできません。

CSAでこう使う：継続的に追いたいKPIは、Performance Analyticsのindicatorとして定義し、定期的にスコアを収集して蓄積します。これにより時系列の傾向や目標（target）との差を可視化できます。可視化の元データに「収集済みKPIスコア」を使うのがindicator data sourceです。

改善後：KPIの定義が1つにそろい、傾向と目標が共有され、悪化のサインに早く気づけるようになります。

早見表の該当行：「時系列の傾向を追いたい」→ Indicator（Performance Analytics）。誤答は「Reportを毎回作り直す」。

Data source：table（現在値）か indicator（収集済みスコア）か

現場で起きる事故：「今この瞬間の未割り当てIncident件数を一覧で見たい」だけなのに、わざわざindicatorを定義して収集を待った。逆に、傾向を見たいのにtable直集計で毎回スナップショットを取り直していた。

放置するとどうなる：元データの選び方を誤ると、「今を見れば十分」な場面で仕組みが重くなったり、「傾向を見たい」場面で過去が残らなかったりします。

CSAでこう使う：可視化の元データ（data source）は目的で選びます。tableは現在のレコードを直接集計する元データで、今の状態の把握に向きます。indicatorは収集済みのKPIスコアを元データにし、時系列の傾向に向きます。

改善後：「今を見る＝table」「傾向を追う＝indicator」と元データを選び分けられ、無駄な収集や情報の取りこぼしがなくなります。

早見表の該当行：「現在の状態を直接集計」→ table。「収集済みKPIスコアで傾向」→ indicator。

Breakdown：同じKPIを軸で分解して内訳を見る

現場で起きる事故：全社のSLA達成率は見えたが、「どの部署が足を引っ張っているか」が分からず、改善の打ち手を決められなかった。

放置するとどうなる：合計値だけでは、どこに問題があるかが見えません。内訳を切り替えられないと、原因の特定と優先順位づけができません。

CSAでこう使う：Breakdownは、indicatorのスコアを部門・カテゴリ・優先度などの軸で分解して見せる切り口です。同じKPIを、見たい軸で切り替えて内訳を確認できます。

改善後：「どの軸で悪いのか」が見え、改善対象を絞り込めるようになります。

早見表の該当行：「同じKPIを部署別・カテゴリ別で見たい」→ Breakdown。VTBのSwimlaneと似た“分ける”感覚だが、分析領域の用語はBreakdown。

Inline editor と Technical editor（UI Builder）：ダッシュボードの作り方を使い分ける

現場で起きる事故：ダッシュボードを作っていたが、途中で「条件をボタンで切り替えたい」「外部から取得した値で表示を変えたい」など、標準ウィジェットを並べるだけでは難しい要件が出てきた。Inline editorで粘って作り込もうとして、できないことに何時間も気づかず、結局やり直しになった。

放置するとどうなる：ダッシュボードの作り方（エディタ）の選択を取り違えると、簡単な指標表示なのにUI Builderを引っ張り出して開発が膨らんだり、逆に高度な要件をInline editorで実現しようとして詰まったりします。

CSAでこう使う：Platform Analyticsには、ダッシュボードの作り方が2つあります。Inline editorは、標準ウィジェット（Data visualization・Filter・Tab）を並べて作る簡易エディタで、通常のダッシュボードに向きます。Technical editor（UI Builder）は、scriptやdata bindingを使った高度なtechnical dashboardを作るエディタで、UI Builderの上でDashboardを組み立てます。「標準を並べるだけ→Inline editor」「scriptで動かす／細かなdata binding→Technical editor（UI Builder）」と切り分けます。

改善後：要件の複雑さに合わせて作り方を選べるようになり、Inline editorで早く済む案件はそのままに、技術的な作り込みが必要な案件だけUI Builderへ切り出せます。

早見表の該当行：「標準ウィジェットを並べるだけ」→ Inline editor。「scriptやdata bindingが必要な高度ダッシュボード」→ Technical editor（UI Builder）＝technical dashboard。

「集計できた・点数が出た」で満足する罠

Platform Analyticsの判断問題は、「分析した気になる対処」と「実際に判断に使える分析」を見分けられるかが問われます。具体シナリオに翻訳して違いを見ます。

「最も適切なのは？」と問われたら、「集計か傾向か」「部品か入れ物か」「現在値か収集スコアか」の軸で選びます。これが迷わないための判断軸です。

Platform Analyticsの運用ベストプラクティス

運用判断に使える分析にするために、現場で押さえておきたいベストプラクティスは次の6つです。

1. 目的で元データを選ぶ。現在の状態はtable直集計、継続的な傾向はindicator（Performance Analytics）にします。
2. 追うKPIはindicatorで定義をそろえる。人によって数字が変わらないよう、収集の定義を1つに統一します。
3. 部品と画面を分けて再利用する。指標はData visualizationとして作り、用途ごとにDashboardへ並べます。
4. 内訳はBreakdownで切り替える。合計だけでなく、部署・カテゴリ軸で原因を特定できるようにします。
5. 新体験では新しい部品を使う。旧UIのReport widgetやHomepage gaugeを持ち込まず、Platform Analyticsの部品で統一します。
6. 作り方は要件で選ぶ。標準ウィジェット中心はInline editor、scriptやdata bindingが必要なtechnical dashboardはTechnical editor（UI Builder）で作ります。

PDIで手を動かして確認する場所

Personal Developer Instance（PDI）で実際の画面を触ると、早見表が記憶に定着します。

• Platform Analytics（Analytics Center / Dashboard）：Dashboardを作り、Data visualizationを複数並べてみる
• Data visualization：元データをtableにした場合とindicatorにした場合で、見え方の違いを確認する
• Performance Analytics（Indicator）：indicatorを定義し、収集（Data collection）でスコアが蓄積される様子を見る
• Breakdown：1つのindicatorを部署やカテゴリの軸で分解して内訳を切り替える
• Inline editor / Technical editor（UI Builder）：標準ウィジェット中心のダッシュボードと、UI Builder上で作るtechnical dashboardを作り比べる

まとめ：分析の「目的」で要素を選べると、判断問題に強くなる

• Platform Analyticsは「運用データをKPI・傾向として可視化・分析」する新しい体験
• 部品＝Data visualization、入れ物（画面）＝Dashboard
• 継続的に傾向を追うKPIはIndicator（Performance Analytics）で収集・蓄積する
• 元データは「現在値＝table」「収集済みスコア＝indicator」で選び分ける
• 同じKPIの内訳はBreakdownで軸を切り替えて見る
• 作り方は「標準を並べる＝Inline editor／scriptやdata binding＝Technical editor（UI Builder）＝technical dashboard」で使い分ける

Platform Analyticsは、CSAでも「集計か傾向か」「部品か入れ物か」を突く判断問題が多いテーマです。事故の形と早見表が頭に入ったら、実際の問題で手を動かして判断軸を固めましょう。