はじめに

本稿で扱う現場では、データ抽出とDatabase View作成において、手順の引き継ぎコストや権限差による作業停滞が継続して発生していた。そこで、GUIで生データエクスポートとDatabase View定義を支援するPowerShell Utilityを作成した。

本記事は、その背景・実装方針・得られた効果を整理した紹介記事である。


背景1: データエクスポートは「できる」が、運用は重い

ServiceNow標準UIでもデータエクスポートは可能である。しかし実運用では、次の課題が積み上がる。

  1. 部署ごとに必要な形式が違う(CSV/JSON/Excel)。
  2. 毎回同じ列構成で出したいのに、リストビュー変更の影響を受けやすい。
  3. 「全カラム + 内部名称込み」での定型取得を求めると、手順説明コストが跳ね上がる。
  4. 場合によってはCSV出力権限の追加説明や調整が必要になる。

結果として、保守側は「データの使い方」ではなく「取り出し方サポート」に時間を取られる。そこで発想を変え、API経由で定型列を各部署に自走出力してもらう構造を用意した。


背景2: Database View作成はRDB知識ギャップが顕在化しやすい

Database Viewは便利だが、非エンジニアやRDB経験が薄い利用者にとってはハードルが高い。

  • sys_db_viewsys_db_view_table の操作文脈が分かれ、画面遷移が多い。
  • 内部カラム名を同じ画面で一覧確認しづらい。
  • Admin権限がない環境では、別環境で内部名称を調査して持ち込む必要がある。
  • Where句やJOIN定義を手打ちすると、スペルミスや参照間違いが起きやすい。

このため、候補を見ながらGUIで組み立てる支援が必要だと判断した。


作ったもの: PS1 SNOW Utilities

PS1 SNOW Utilitiesは、以下3タブで構成した。

1. Exportタブ

  • 対象テーブル選択(または手動入力)
  • フィルタ指定(全件 / sys_updated_on 期間)
  • 出力形式選択(CSV / JSON / Excel)
  • 出力先フォルダ指定と実行ログ確認

狙いは、部署ごとのデータ利用を止めずに、抽出手順を定型化することである。

2. Database View Editorタブ

  • View内部名・ラベル入力
  • ベーステーブルとPrefix設定
  • JOIN追加(左右カラム、Variable Prefix、LEFT JOIN指定)
  • カラム候補再取得と表示対象選択
  • View作成と結果リンク表示

狙いは、ServiceNow標準UIの操作分断を埋め、定義ミスを減らすことである。

3. 設定タブ

  • インスタンス名
  • 認証方式(ユーザーID+パスワード / APIキー)
  • 言語設定

入力値は settings.json に保存し、繰り返し作業の初期入力を削減する。機密値はWindows DPAPI(CurrentUser)で暗号化し、同一ユーザー・同一端末前提で復号される実装としている。


実装上の割り切り

会社環境ではインストーラー配布や常駐アプリ導入のハードルが高い。そこで今回は、最悪テキストコピペでも動作可能なPowerShellスクリプト配布を優先した。

この割り切りにより、導入障壁を最小化しつつ、現場の即効性を確保できた。


導入効果

導入後に大きかった効果は次の3点である。

  1. 保守側の問い合わせが「抽出手順」から「データ活用相談」に移った。
  2. Database View作成時の定義漏れ・スペルミスが減った。
  3. 部署間でフォーマットが揃い、自動集計の前処理負荷が下がった。

特に、運用部門がExcelで一次分析し、連携チームがJSONを使う並行運用を同時に回せるようになった点は実務上の価値が大きい。


制約と注意点

  • テーブル一覧は sys_db_object 参照のため、ACL次第で取得できない場合がある(手動入力で回避)。
  • 環境によってはWhere句/JOIN定義の自動保存に制約があり、ServiceNow側で手動補完が必要な場合がある。
  • 本ツールはServiceNow社とは無関係であり、同社の承認・保証・サポートを受けない。

まとめ

今回のPS1 SNOW Utilitiesは、データ抽出とDatabase View定義に関する実務上の詰まりを減らす目的で作成したものである。

個人的な所感として、PowerShellでGUIを作れること自体は以前から認識していたが、実際に自力で着手する発想は持てていなかった。生成AIに支援を受け、ほぼノーコードに近い指示ベースでここまで形にできた経験は、AIの進化の速さを強く実感させるものだった。同時に、従来のローコード/ノーコードツールは優位性の再定義を迫られ、陳腐化圧力を受ける局面が避けにくいとも考えている。