はじめに

ServiceNowには場所をあらわす情報を管理する所在地テーブル（cmn_location）があります¹。

デモデータを見ると何やら世界の国々が入っていたり、もっと大きな地域が入っていたり、小さなものになると事業所レベルのデータが入っていたりして、いまいち使い方が分かりにくいテーブルです。できるだけ有効に活用したいところですが、一方で凝りすぎると収拾がつかなくなる恐れもあります。

今日はこんな所在地テーブルの上手い使い方について考えてみたいと思います。

所在地テーブルとはどんなテーブルか

所在地テーブルには、初期状態でデモデータが入っています²。このデータを眺めながら、このテーブルの存在意義を考えてみたいと思います。

所在地テーブルの性質1

冒頭でも述べましたが、住所が入っていたり、アメリカの州の名前が入っていたり、と思ったらApac（Asia Pacificの略）だとかEmea（Europe, Middle East and Africaの略）だとかいう、グローバル企業っぽい広域組織の名前が入っていたり、国の名前が入っていたりと、結構散漫なデータが入ったテーブルです。

レベル感がまちまちなだけなく、あまり網羅的ではないのもこのデータの特徴です。それは「サンプルなんだからしょうがないだろう」という方もいらっしゃるかも知れませんが、網羅性がない地理情報が入っているのが所在地テーブルの本質と考えるべきだとわたしは思います。なぜかというとServiceNowにはもっと網羅的な「国（core_country）」というテーブルがすでにあるためです。こちらにはISO3166-1に基づく世界の国の一覧が入っています。このテーブルについては別の機会に書きたいと思うのですが、何はともあれ、所在地にテーブルに登録された「国」は、国テーブルの「国」とは少し意味が違うということです。

所在地テーブルの性質2

所在地テーブルには緯度（latitude）と経度（longitude）を管理するフィールドがあります。このフィールドの値は実は飾りではなくて、その値に基づいて、地図の上に情報をグラフィカルに表示する機能があります。これによって、例えば、CIの所在地だとか、インシデントが発生している場所だとかをグラフィカルに表示する可視化機能が利用できるようになります。今日は所在地テーブルにフォーカスして先を急ぎたいので、この機能の使い方についてもまた別の機会に調べていきたいと思います。

所在地テーブルの性質3

所在地テーブルは「親（parent）」フィールドを持っています。つまり、場所と場所に上下関係があり、階層構造をとれる構成になっています。この構造を持っているので所在地を参照するフィールドではツリーピッカーを使うことができます。

また、後述しますが「フルネーム（full_name）」というフィールドで、広域地域から拠点に至るまで、パスで辿ることができるような情報も持っています。

さらに、OOTBの状態では見えておらず、デモデータでもセットされていないのですが、所在地テーブルには「ロケーションタイプ（cmn_location_type）」というフィールド³があり、リージョン（ApacやEmeaなどという広い地域）から、地点（特定の住所）に至るまで、そのロケーションがどの階層にあるのかを管理することができます。

所在地テーブルの性質4

所在地テーブルがOOTBでどこから参照されているかというと、最も重要な参照元はCMDBの構成アイテムテーブル（cmdb_ciおよびその派生テーブル）です。要するに構成アイテムの所在地を登録するためのテーブルだということです。

構成アイテムの所在地として参照されるデータにはどのようなものが必要かと考えてみると、以下の性質は持っておきたいように思います。つまり、

会社が構成アイテムを置いている場所はもれなく持っていないといけない。
構成アイテムの管理に必要な粒度で場所の情報を持っていないといけない。あまりに粗いと意味がない。

このテーブルのデモデータに網羅性がないように見えるのは、それが世界の真実を網羅するためのテーブルではなく、組織が管理する場所を網羅するためのテーブルだからです。国やリージョンのような上位区分に意味があるのは、下位区分のデータを集計するためであり、事業に関係のない上位区分だけを単体で登録していてもあまり意味がないと言えます。

所在地テーブルの性質5

所在地テーブルのACLを見ると、基本的に追加、変更、削除ともにuser_adminの権限があれば可能で、参照はログインしているユーザーであれば誰でも可能です。user_adminというのは、ユーザーやグループ、ロケーション、会社の情報を管理するユーザーで、コアなマスターデータに対して大きな権限は持っていますが、逆に言うとシステム管理者とは違い、あくまで業務データの管理者です。例えば、国（core_country）テーブルは、 OOTB設定ではadminでないと変更ができないのとは対照的です。こちらはシステム管理者作業で変更することしか想定していないとても硬いハードマスターであるということになります。

所在地テーブルは意外とカジュアルに出し入れをするソフトマスターテーブルなのです。

活用方法提案

これらの性質に基づいて、所在地テーブルの有効な利用方法を考えてみましょう。

最初から入っているデータは一旦削除する

所在地テーブルは、デモデータをインストールしない設定でプロヴィジョニングしても、一定量のデータが入った状態になります。しかし、このテーブルの趣旨から言って、このデータは不要なので、まず全部削除して良いです。（修正の必要はあっても削除する必要がない国テーブルとはここが違います）

階層を意識する

所在地テーブルは、親フィールドを使った階層構造になっています。また、前述のように階層の種類を管理するロケーションタイプというフィールドもあるので、これは活用すべきです。

ロケーションタイプの最上位は「リージョン」です。リージョンというのは、国よりもさらに大きなレベルの地域区分で、先ほど登場した「Apac」と「Emea」以外に、南北アメリカ大陸を指す「Americas」の3リージョンで地球上を網羅的に管理するグローバル企業は多いと思います。

リージョンの下には国が入ります。例えば、会社組織として日本という国がアジア大洋州の下に属するのであれば、親をアジア大洋州のレコードに設定し、ロケーションタイプを「国」にしたレコードとして定義します。この定義はあくまで会社組織としての定義であり、外部の権威による分類（例えば国連がどう管理しているかとか）を表しているわけではないことに注意してください。自社では日本はアジアではなく独立したリージョンだというのであればそのように定義します。リージョンが複数階層に渡ることもあるでしょう。Americasが北米と南米というサブリージョンに分かれていたり、Emeaが欧州と中東とアフリカのサブリージョンで分かれているという企業も当然あると思います。

国から下をどう階層化するかは組織によって異なります。要らない階層は登録しなくて良いです。会社組織の地理的区分で都道府県の情報が必要なケースは少ないと思います。国の下にいきなり拠点（東京オフィス、大阪オフィス、など）が来ても全くおかしくありません。

ロケーションタイプの選択肢は部屋レベルまで持てるようになっていますが、ここまでの場所情報を登録する必要があるかというと通常はないと思います。

網羅的な地理情報マスターだとは考えない

所在地テーブルは、前述の通り事業に関係ある場所データを格納するテーブルですので、世界の地理情報を網羅的に格納しようとは考えないことです。ロケーションタイプ「国」のデータを格納するときも、世界の国を網羅する必要はありません。あくまで会社に関係する場所として必要なときのみデータを格納します。日本が本社で事業展開する国が海外10カ国である場合は、国のデータは日本を含めて11件あれば十分で、それ以上は必要ありません。それを網羅的に管理するのは国テーブルの役割です。

デモデータが米国の50州を網羅しているので惑わされがちですが、都道府県やそれ以下の行政区画を網羅する必要も通常はありません。そのようなデータに使途があるとしたら、都道府県ごとの集計データをレポートにしたいときくらいですが、そんなデータ集計があるのは政府機関くらいではないでしょうか。どうしても網羅的な都道府県マスタを持ちたいなら、場所テーブルよりも国テーブルを拡張してISO-3166-2の情報を持てるようにする方が良いと私は思います。前述のように、ハードマスターである性質が重要だからです。

OOTBで見えていないフィールドを活用する

この所在地テーブル。OOTBでは見えていないフィールドがたくさんあります。主だったものをフォームに表示させてみたものがこちらのイメージになります。

それぞれ、以下のようなフィールドです。

フィールド名	カラム名	用途
勤務タイプ	cmn_location_type	ここまでロケーションタイプと呼んできたものです。翻訳がひどすぎるので勝手な名前で呼んでいます。前述の通り、場所が示すものの階層を示す選択肢フィールドです。必ずしもこれを前提としている機能は無いようなので、選択肢を追加するなどの対応は可能だと思います。
場所のソース	cmn_location_source	OOTBでは「LDAP」「Workday」「Azure」という謎の3択ですが、これは他システムからの連携で場所データを取り込むときのソースを表すカラムです。そういう運用をするときは、しかるべきソースを選択肢に登録してデータを持たせるべきです。
管理担当者グループ	managed_by_group	この場所レコードを管理するグループが誰かを示します。
フルネーム	full_name	更新するたびに親子関係に基づいて自動で更新されます。手動では編集できないようにACLが入っています。業務での用途は考えづらいですが、読み方に慣れれば便利そうではあります。
ライフサイクルステージとライフサイクルステージステータス	life_cycle_stageとlife_cycle_stage_status	場所レコードのライフサイクル状態を管理できます。ライフサイクルステージが「デザイン」「稼働」「提供終了」の3択で、ステータスの方は3つのステージごとにさらにサブステータスを持っています。このステータスは所在地テーブルのためにわざわざOOTBで定義されていて、所在地情報のステータスを管理するのに利用できます。
複製とプライマリロケーション	duplicateとprimary_location	複製のチェックを入れるとプライマリロケーションが表示されて必須になります。これはつまり、同じ場所を示すレコードが重複したときに、優先して使うものと、劣後させて使わないものを示すためのフィールドです。

ロケーションタイプはすでに語っているので置いておくとして、意外と重要なのは「場所のソース」「複製」「プライマリロケーション」「管理担当者グループ」だと思います。これらのフィールドの存在意義は、複数のデータソースからのインポートでこのテーブルのデータを作成したときの重複を解決することです。データソース間でデータが重複したときは、複製フラグを立てて優先して使うレコードを示しておくことで重複を防ぎます。重複した時に不要なレコードを削除しても、次に連携処理が走ると、また同じレコードができてしまうので削除運用は困難になるためです。また、こういう状況整理のためには、レコードを誰が管理するのかを明確にする必要があります。OOTBにはありませんが、管理対象者グループに基づくACLを作ることも一つのアイデアです。

また、ライフサイクルステージの管理は、このテーブルのためにわざわざ定義されたリッチな機能です。隠されていますし、これを使っている既存機能もないように思いますが、実はRomeという比較的新しいバージョンで追加された機能です。この辺りはCSDM 4.0のホワイトペーパーに書かれています。（Draftという版しか公開されていませんが、このコミュニティページでは延々と議論が続いています）

上の表で、管理担当者グループがその拠点の管理者ではなくて、場所レコードの管理者であると断定的に書いているのも実はこのホワイトペーパーにそう書かれているためです。

まとめ

長い記事になってしまいましたが、（余計な話を刈り込んで改訂すると思います）ポイントのおさらいです。

所在地テーブルは......
- 位置情報によって地図表示を行うためのベースのテーブルである。
- 事業に関係のある場所を階層的に登録するテーブルである。世界の地理情報を網羅的に登録してハードマスターとして参照する用途には適さない。そういうときは国テーブルを使いましょう。
- どんな粒度で登録するかは、その粒度でデータを集計して管理したいかによる。
活用する上では......
- ロケーションタイプは階層の管理に有用なのでぜひ表示させて使おう。
- 他システムからの連携で所在地データを管理するときは、「場所のソース」「複製」「プライマリロケーション」のフィールドを有効に活用して、余計なメンテナンスの手間を省く。
- レコードの管理ステータスは「ライフサイクルステージ」で管理し、責任者は「管理対象者グループ」で管理する。

実は、最新のCSDMで考え方が洗練され、それに合わせて拡張された、新しい機能が多いテーブルです。ぜひ有効活用したいところです。

テーブル名の日本語ラベルは「所在地」なのに、アプリケーションナビゲーター上の日本語メニューは「場所」になっているという残念な翻訳についてはここでは脇に措きます。残念ですよね。 ↩
いわゆるデモデータをインストールしなくても、一定量のデータが入っています。 ↩
Washington DCのインスタンスで試しているのですが、和名がなぜか「勤務タイプ」という酷い名前になっていて意味が通じないので、本稿では「ロケーションタイプ」で通します。 ↩