基本的な考え方
ここではFMシステムに対し、施設管理業務が開始される前に登録する情報について記載します。施設をどう管理するのかはベンダーや施設管理事業者の戦略や大きく関わるため多様です。そこでシステム利用者はそのシステムに合う形で必要な情報を登録する必要がありますが、その検討の際には共通データ仕様も参考になるので以降情報の種類ごとに具体的に例示したいと思います。
FMシステムのデータは事業者が交替しても引き継がれる必要があります。また、FMシステムからCSVなどの加工用電子データを取り出して分析などを行う際、複数の電子データを突き合わせて分析するなどの活用方法も想定されます。その際に必要になるのが「主キー」と「用語の共通化」です。後者の用語の共通化については今まで記載してきましたので、ここでは改めて説明しません。
主キーとは全てのデータに割り振られる「重複が無い」「内容が変更されない」項目の事です。この主キーはそのデータが消失した後を含めて重複が無い事が必要です。例えばマイナンバーはその人が亡くなっても他の人に同じナンバーが割り振られては困ります。マイナンバーは人に対する主キーですが、人に限らすらコンピューターでデータを保存したり処理するためにはあらゆるモノやコトには主キーが必要です。FMシステム内の各データに対しても主キーがある必要があります。尚、主キーは本来はひとつの項目だけで重複が無い事が望ましいのですが、FMシステムに登録するデータとしては複数の項目を組み合わせて重複が無いこととしても運用上困らないとも思います。
以降、共通データ仕様に関係するモノやコトごとに共通データ仕様の何を参考にすると良いのか、どの様な主キーが望ましいのかを順番に例示していきます。
オーナー情報
オーナーとは公共施設の場合は例えば自治体です。公共施設管理では一般にオーナーはひとつに限定される事が多いので、この情報が必須であるとは限りません。広域管理が進展してくると必要性が増してくる情報です。
オーナー情報として何を登録すると良いのかについては、共通データ仕様のデータモデル「法人(Organization)」が参考になります。また、「法人」にはその所在地を示す「施設」のリンクがあり、「施設」には施設が入居する「建物」のリンクがあり「建物」の敷地を示す「土地」のリンクがありますので、参考にするのは結局「法人」「施設」「建物」「土地」の四つになります。各データモデルには多様な属性(項目)が定義されていますが、オーナー情報としては例えば以下の項目が候補でしょうか。詳細は各データモデルを参照してください。
| データモデル/呼称 | 説明 | データモデルの正式な項目名 | |
|---|---|---|---|
| 法人(Organization) | 自治体を含む法人のデータモデルです。 | ||
| 法人ID | この自治体(法人)の主キーです。法人番号などから組み立てられた文字列です。この項目は共通データ仕様のデータモデルで主キーとして定義しているので、そのままFMシステム内でも主キーとして使用可能です。主キーは必須なので、この項目かこれに代わる項目を選択する必要があります。 | id | |
| 法人名 | 自治体の名称です。 | name, nameKana, nameEn | |
| 県名 | 基礎自治体の場合に所在する都道府県名です。 | containedInPlace, | |
| 電話番号 | 法人の連絡先です。代表電話を想定しています。 | contactPoint | |
| 法人番号 | 13桁の法人番号です。不変であり重複もなく法人IDと機械的な変換が可能なので法人IDの代わりに主キーとして利用可能です | identificationGroup | |
| 自治体コード | 全国地方公共団体コードです。自治体以外の法人の施設も含めた情報を活用する局面を考えると主キーとしての利用は望ましくありません。 | identificationGroup | |
| 土地 (Land) | 自治体の本庁舎の建物の敷地のデータモデルです。 | ||
| 住所 | 自治体本庁舎の住所です。方書は含みません。 | address | |
| 建物 (Building) | 本庁舎の建物のデータモデルです。 | ||
| 建物名 | 住所の方書に使うビル名、または複合施設の場合の建物の名称です。施設が建物の一部に入居している場合は、記入が必要です。 | name | |
| 施設 (Facility) | 本庁舎の施設(市役所や役場)のデータモデルです。 | ||
| 施設名 | 施設名です。例えば「○○市役所」「○○町役場」などです。 | name, nameKana, nameEn, alternateName | |
| 管理通番 | 自治体が採番した施設の番号です。オーナー情報としては不要なようですが、本庁舎も施設管理対象である場合、この項目でどの施設なのかの区別をつけるのに必要です。 | facilityID | |
| フロア名 | 建物の一部に入居している施設の場合、フロア名。方書の一部になります | floor | |
所管部門情報
公共施設の場合は自治体内の各公共施設の所管課です。FMシステムによっては連絡先の情報として管理する場合もあります。
所管課情報として何を登録すると良いのかについては、共通データ仕様のデータモデル「部門(Department)」が参考になります。また、「部門」にはその所在地を示す「施設」のリンクがあり、「施設」には施設が入居する「建物」のリンクがあり「建物」の敷地を示す「土地」のリンクがありますので、参考にするのは結局「部門」「施設」「建物」「土地」の四つになります。各データモデルには多様な属性(項目)が定義されていますが、所管課情報としては例えば以下の項目が候補でしょうか。詳細は各データモデルを参照してください。尚、オーナー情報をFMシステムに登録しない場合は、これらに加えて前節の「オーナー情報」で示した項目も候補に加わります
| データモデル/呼称 | 説明 | データモデルの正式な項目名 | |
|---|---|---|---|
| 部門(Department) | 自治体を含む部門のデータモデルです。 | ||
| 部門ID | この所管課(部門)の主キーです。法人番号や部門コードなどから組み立てられた文字列です。この項目は共通データ仕様のデータモデルで主キーとして定義しているので、そのままFMシステム内でも主キーとして使用可能です。主キーは必須なので、この項目かこれに代わる項目を選択する必要があります。 | id | |
| 部門名 | 自治体内の部門の名称です。 | name, nameKana, nameEn | |
| 電話番号 | 部門の連絡先です。 | contactPoint | |
| 法人ID | オーナー情報の主キーです。オーナー情報を登録しないFMシステムの場合は前項のオーナー情報の表から必要な項目を選択して代わりに登録します。 | departmentOf | |
| (部門コード) | 共通データ仕様でき定義されていない項目ですが、部門IDを主キーとして採用しない場合には主キーの一部として必要な情報です。部門コードとは組織の中で一意となる文字列です。 | id | |
| 土地 (Land) | 部門が入居する建物の敷地のデータモデルです。 | ||
| 住所 | 部門の住所です。方書は含みません。 | address | |
| 建物 (Building) | 部門が入居する建物のデータモデルです。 | ||
| 建物名 | 住所の方書に使うビル名、または複合施設の場合の建物の名称です。施設が建物の一部に入居している場合は、記入が必要です。 | name | |
| 施設 (Facility) | 部門が入居する施設(市役所、支所、出張所など)のデータモデルです。 | ||
| 施設名 | 施設名です。例えば「○○市役所」「○○センター」などです。 | name, nameKana, nameEn, alternateName | |
| 管理通番 | 自治体が採番した施設の番号です。オーナー情報としては不要なようですが、入居施設も施設管理対象である場合、この項目でどの施設なのかの区別をつけるのに必要です。尚、テナント施設の場合は管理通番は無い可能性があります | facilityID | |
| フロア名 | 建物の一部に入居している施設の場合、フロア名。方書の一部になります | floor | |
