Data Visualizationsで時系列グラフを作る手順：ColumnとTrend byの設定
Data Visualizationsには、棒グラフや円グラフとは別に「Column」という種別があります。Time seriesグループに属し、横軸が分類ではなく日付になる種別です。優先度別の内訳を見るVertical barとは役割が違い、件数の推移を時間の流れで追うために使います。
この記事では、Incidentテーブルから週ごとの件数推移が読めるColumnグラフを、画面つきで最後まで作ります。PDIに最初から入っているIncidentは71件しかなく、しかもほぼ1日1件ずつ散った状態でした。このままColumnに変えても、棒は数年おきに細く立つだけでグラフとして読めません。そこで検証用のインシデントを過去120日に分散投入し、密度のあるデータでグラフを作ります。
Columnは棒グラフの仲間に見えますが、横軸の決め方がまったく違います。Vertical barは分類（PriorityやCategoryなど）で棒を分けるのに対し、Columnが分けるのは日付そのものです。この違いを知らないまま操作すると、後述する「Trend byの既定値」でつまずきやすくなります。
この記事で分かること
ColumnでTrend byを設定し、週次の推移グラフに仕上げる手順
Trend byの既定値が招く「棒が散らばる」つまずきの直し方
発生の推移・対応完了の推移など、目的に応じた日付フィールドの選び方
間隔8種類の使い分けと、Add custom conditionsでデータを絞り込む方法
検証環境はServiceNowのPDI（Personal Developer Instance）Zurichリリースです。実行はScripts - Background（書き込みあり・検証用データの投入）とPlatform Analyticsの画面操作の組み合わせです。画面や既定値はリリース・環境で変わることがあります。
準備：素のPDIには時系列に足りるデータがない
incidentは全件で71件でした。日付フィールドをopened_atにして直近90日を数えると3件、180日でも4件です。10年近い期間に71件しか無ければ、週や月で区切ったとき、ほとんどの区間が0件になります。Columnで横軸を日付にすると、棒が散らばって見えるのは、この分布どおりの結果です。
件数を増やせば解決します。ただし増やし方には条件があります。過去数年に均等にばらまいても、直近が薄いままでは「最近の傾向」を読むグラフにはなりません。今回は過去120日の平日に絞り、後半ほど件数が増える形でインシデントを作りました。曜日ごとに山ができるよう、月曜と金曜で件数を変える調整も加えています。
このあとの画面は、検証用にインシデントを276件追加した状態で撮影しています。追加後のincidentは全件347件、直近90日で227件です。手順そのものは件数に左右されないので、自分の環境のデータ量に読み替えてください。
手順1：データソースにIncidentを追加する
Platform Analytics > Data visualizations の一覧から、右上の「Create data visualization」を押します。するとVisualization Designerという作成専用の画面が開きます。
画面左の「Add data source」を押すと、データソースを選ぶダイアログが開きます。検索欄に「Incident」と入力すると、候補が絞り込まれます。
候補の中からIncident [incident]を選びます。角括弧の中がテーブルの物理名です。似た名前のIncident Taskなどと間違えないよう、物理名を確認してから選びます。テーブルを取り違えると、この先の手順を全部やり直すことになります。
手順2：ソースを確定する
Incident [incident]をクリックすると、右側にレコードのプレビューが表示されます。今回は条件を付けず、全件のまま右下の「Add this source」で確定します。
データソースを追加した直後は、既定でSingle scoreという種別が選ばれます。件数を1つの数字として大きく表示する種別です。ここから種別を変えて、日付を軸にしたグラフに切り替えます。
手順3：Visualization typeをColumnに変える
右パネル上部の「Visualization type」ドロップダウンを開くと、種別の一覧が検索付きで出ます。選択肢は思ったより多めです。検索欄に「Column」と打つと、Time seriesグループに属するColumnに絞り込めます。
Columnを選ぶと、キャンバスの表示が数値から棒グラフに変わります。同時に、右パネルのDataセクションに「Trend by」という新しい設定項目が現れました。分類で棒を分けるGroup byとは別の項目で、Columnを選んだときだけ表示される仕組みです。
手順4：Trend byを編集する
Trend byの右にある鉛筆アイコン（Edit trend by）を押すと、編集用のパネルが開きます。クリックは1回だけです。
このパネルで、横軸に使う日付フィールドと、区切る間隔（Date・Week・Monthなど）の両方を設定します。次の手順で、まず日付フィールドを選び直します。
手順5：日付フィールドをOpenedに選び直す
編集パネルのフィールド選択を押すと、日付型のフィールド一覧が出ます。
候補には日付型のフィールドが並びます。上のほうにはActivity due・Actual end・Actual start・Approval set・Closedがありました。続いてCreated・Due date・Expected start・Follow up・Last reopened atが並びます。下のほうにはOpened・Resolved・Updated・Work end・Work startが続いていました。この中からOpened（opened_at、インシデントの起票日時）を選びます。インシデントがいつ起きたかを見たいので、起票日を表すOpenedが今回の目的に合っていました。
手順6：間隔をWeekに変えてApplyする
日付フィールドをOpenedに変えた直後は、間隔がDate（日単位）のままです。棒はまだ細かいです。
投入したデータは過去120日に集中しているため、この時点で横軸は現実的な範囲に収まります。ただし日単位のままだと、棒の本数が多く細かすぎて山の形が見えにくい状態です。そこで間隔のドロップダウンを「Week」に変え、「Apply」を押します。
週単位に集計されたことで、後半にかけて件数が増えていく山の形がひと目で分かるようになりました。投入したデータは後半ほど件数が多くなるように作ってあるため、狙いどおりの結果です。ここまでで、週次の推移が読めるColumnグラフが完成です。
つまずきポイント：Trend byの既定は「Activity due」
原因はTrend byにありました。種別をColumnに変えた直後、Trend byは自動でDate by Activity due（activity_dueフィールド）になっていました。opened_atではありません。Activity dueはインシデントによって値が空だったり、何年も前の日付が入っていたりするフィールドです。SLAや次の対応期限に関わる日付だと考えられますが、フィールドの定義そのものは今回のPDIでは確認していません。この既定値のまま眺めると、横軸が2015年から2026年まで広がり、投入した276件はごく一部の棒にしか反映されません。
同じデータのまま、Trend byだけをDate by Opened（手順5で選んだ設定）に変えると、見え方はまったく違います。
2枚を比べると違いは一目瞭然です。データが足りないのではなく、見ている日付フィールドが違っただけでした。Columnを初めて使うときに棒が散らばって見えたら、まずTrend byの日付フィールドを確認します。3パターンの見え方を並べると次のとおりです。
どの日付フィールドを選ぶか
Trend byの日付フィールド一覧には15種類が並んでいました。上のほうにはActivity due・Actual end・Actual start・Approval set・Closedがあります。続いてCreated・Due date・Expected start・Follow up・Last reopened atが並びます。下のほうにはOpened・Resolved・Updated・Work end・Work startが続いていました。どれを選ぶかで、グラフが答える問いが変わります。正解は一つではありません。
狙いはシンプルでした。インシデントがいつ発生したかを見たかったので、起票日を表すOpenedを選びました。同じ目的ならCreatedも候補です。Openedはインシデントとしての起票日時、Createdはレコードがシステムに登録された日時という違いがあり、運用によっては値がずれることもあります。この違いを両方の値で見比べる検証は、今回は行っていません。
目的が違えば話は変わります。対応が完了した件数の推移を見たいなら、ResolvedやClosedのほうが目的に合います。「いつ起きたか」のOpenedと「いつ片付いたか」のResolved・Closedでは、対応に時間がかかる案件が多いほど、グラフの山がずれて出るはずです。件数の分布そのものより、どの時点を数えたいかを先に決めることが選び方の指針になります。
Due dateやExpected startは、対応の予定を表すフィールドです。今回投入した検証データはopened_atだけに値を入れており、この2つは空のままでした。空欄が多いフィールドをTrend byに選ぶと、棒がほとんど立たないグラフになると考えられますが、実際に試してはいません。Activity dueが既定のまま棒を散らばらせた理由も、値の欠けや古い日付が多いという同じ構造だと考えられます。
間隔8種類の使い分け
Trend byの編集パネルでは、日付フィールドとは別に間隔も選べます。実測した選択肢はDate・Day of week・Hour of day・Minute・Month・Quarter・Week・Yearの8種類でした。
日単位のDateは細かすぎて山が見えにくく、月単位のMonthは今回のような120日分のデータだと区切りが3〜4本しかできません。今回はWeekがちょうどよい粒度でした。データの分布に対して間隔が細かすぎると棒が薄く散らばり、粗すぎると変化が数本の棒に潰れてしまいます。手元のデータ量に合わせて、DateとWeekを両方試してから選ぶ進め方が現実的です。
Day of weekとHour of dayは、期間の推移というより「偏り」を見る間隔です。Day of weekは曜日別に対応件数を比べる用途に、Hour of dayは1日のうちどの時間帯に問い合わせが集中するかを調べる用途に向いています。どちらも横軸が7本または24本の固定になるため、期間を長く取っても棒の本数は増えません。Minuteはさらに細かく、分単位で発生頻度を見る間隔でした。イベントのような短時間に集中するデータには合いますが、今回のように1日数件のインシデントには細かすぎて向きません。QuarterやYearは、数年分のデータが積み上がった環境で長期の傾向をつかむ用途に合う間隔で、今回の120日分のデータでは1〜2本の棒にしかならず、判断材料としては不十分でした。
データを絞る：Add custom conditions
全件が常に正解とは限りません。特定の条件に合うインシデントだけをグラフの対象にしたい場面があります。その絞り込みは、データソースを追加するダイアログの「Add custom conditions」から行います。
押すと条件エディタが開きます。行は1本だけです。既定では「Opened」「on」「Today」という条件が入っています。フィールド・演算子・値の3つを組み合わせる作りです。日付フィールドを対象にしたときの演算子は、実測で16種類ありました。on not on before at or before after at or after between trend relative is empty is not empty is anything is same is different is more than is less thanです。
16種類は大きく4つに分けて考えると扱いやすくなります。特定の日を指すon・not on、範囲の前後を指すbefore・at or before・after・at or after・between、値の有無を問うis empty・is not empty・is anything、そして別のフィールドと比較するis same・is different・is more than・is less thanです。残るtrendとrelativeは、日付そのものではなく期間の考え方を指定する演算子でした。
値の入力欄には、カレンダーで日付を直接指定する方法のほかに、Days・Weeks・Months・Quarters・Years・Minutesを組み合わせた相対期間のメニューも用意されています。条件を組み立てたら下部の「Preview record list」で、対象件数がその場で表示されます。今回の検証では、条件を付けない状態で347件と表示されました。フィールドや演算子を変えるたびにこの件数が更新されるので、条件を保存する前に絞り込みすぎていないかをその場で確認できます。
同じ条件エディタで、フィールドをCategoryやPriorityに変えれば、種類別に絞った推移も出せます。条件は複数行に増やせるため、「直近の期間」と「特定のカテゴリ」の組み合わせも可能です。ただし複数条件を重ねた状態での描画は今回試しておらず、未検証のまま残しました。
よくある質問
Trend byの既定がOpenedにならないのはなぜですか
今回の検証で確認できたのは、Columnに切り替えた直後の既定がDate by Activity dueだったという事実までです。なぜOpenedではなくActivity dueが選ばれるのか、その判断基準はPDIの画面からは特定できませんでした。テーブルごとに既定の日付フィールドが決まっている可能性がありますが、断定はできません。Column を使うたびに、Trend byの日付フィールドを目で確認する習慣をつけておくと安心です。
間隔はDateとWeekのどちらを選べばよいですか
データ量と見たい期間で決めます。今回のように過去120日・347件程度であれば、Dateは棒が細かすぎて山が見えにくく、Weekのほうが推移を読みやすい結果でした。件数がもっと多い、あるいは対象期間が数日単位であれば、Dateのほうが適することもあります。判断に迷ったら、間隔を1つに決め打ちせず、DateとWeekの両方を実際に切り替えて見比べるのが早道です。まずWeekで全体像をつかみ、必要に応じてDateやMonthに切り替えて確かめる進め方をおすすめします。
Add custom conditionsで「先週」「過去3か月」のような相対期間を条件にできますか
先に答えを書くと、ここは未検証です。値の入力欄に相対期間のメニュー（Days・Weeks・Months・Quarters・Years・Minutes）があることは確認できました。ただし、実際に相対期間を設定した状態でグラフが描画されるところまでは、今回のUI操作で完了できず未検証です。試す場合は、条件を設定したあとPreview record listで件数が想定どおりに変わるかを確認してから、グラフ側に反映してください。
自分の環境でも棒が散らばります。データ量が原因ですか
先にTrend byを見てください。既定のActivity dueは、値が空だったり古い日付だったりするレコードが多く、データ量に関係なく棒が散らばって見えます。Openedなど発生日系のフィールドに変えても散らばるなら、そこで初めて件数や期間の偏りを疑う、という順番で確認すると原因を切り分けやすくなります。手元のデータが今回のincidentのように直近数か月に少ない場合は、間隔をWeekやMonthに変えるだけでも見え方が変わるはずです。
演算子が16種類もありますが、実務でよく使うのはどれですか
日付フィールドでは、範囲を区切るbetween、基準日より後を拾うat or after、当日を指すonあたりが使用頻度の高い演算子だと考えられます。相対期間と組み合わせるrelativeやtrendは、日々更新されるダッシュボードで「直近◯日」を自動的に保つ用途に向いていそうです。ただし、その組み合わせ自体は今回未検証のため、使う前に少数のレコードで期待どおりの結果になるかを確かめてください。
まとめ
今回の要点は次のとおりです。
incidentは全件71件・直近90日3件しかなく、Columnにするとそのままでは棒が散らばって読めなかった
Scripts - Backgroundで276件を過去120日に投入し、全件347・直近90日227まで増やした
Columnを選んだ直後、Trend byの既定はDate by Activity dueで、これが「棒が散らばる」正体だった
Trend byをDate by Openedに変え、間隔をWeekにすると、週ごとの山として推移が読めるグラフになった
間隔はDate・Day of week・Hour of day・Minute・Month・Quarter・Week・Yearの8種類から選べる
対象を絞りたいときは、Add data sourceのAdd custom conditionsで条件エディタを開く
用語
Column … Data visualizationsの種別の1つ。Time seriesグループに属し、日付を横軸にして推移を表示する
Trend by … 種別をColumnにしたときに現れる設定項目。横軸に使う日付フィールドと区切る間隔を指定する
Add custom conditions … データソース追加時に条件を絞り込むための条件エディタ
自分の環境で確認するときのURL
/now/platform-analytics-workspace/data-visualization-library（Data visualizations一覧、Visualization Designerの入口）
/sys.scripts.do（Scripts - Background。検証用インシデントの投入に使用）
参考リンク
ServiceNow レポート・ダッシュボード完全ガイド：Data VisualizationsとPerformance Analyticsの使い分け — 時系列グラフのColumnが、Data VisualizationsとPerformance Analytics全体のどこに当たるか確認できます
検証範囲とおことわり
確認した範囲：PDI（Zurich）のScripts - Backgroundで検証用インシデント276件を投入し、Platform AnalyticsでIncidentをデータソースにColumnを作成、Trend byの既定値確認・日付フィールドの変更・間隔の変更（Date/Week）、Add custom conditionsでの条件エディタと演算子一覧の確認までを実機で操作しました。本文の数値と画面はこの操作に基づきます
確認していない範囲（断定しません）：相対期間（Last 3 monthsなど）を条件に設定した状態でのグラフ描画はUI操作が完了できず未検証です。作成した可視化の保存やダッシュボードへの配置、Indicators・User Experience Analyticsをデータソースにした場合の時系列、本番環境の実データ量での描画性能、投入したデモデータの削除手順は、いずれも本記事の範囲外です
Trend byの既定値がなぜActivity dueになるのか、その判断基準はPDIの管理画面からは特定できていません
週次の推移が読めるようになったら、次はこのグラフをダッシュボードに置いて定点観測に使えます。置き方は別記事で扱う予定です。
