施設管理のデジタル化の潮流
施設管理と呼ばれる分野のコンピュータシステムには各種設備や施錠などの状態を監視する「ビル管理システム」、建物や土地などの資産を管理する「資産管理システム」、そして各社や自治体の中で不具合の状況や修繕状況や予算消化状況などを把握するための「施設管理システム」などの多様なシステムが存在します。実際のシステムではこれらの各種システムはバラバラに存在するとは限らず、ひとつのシステムが多様な機能を兼ね備えています。
デジタル化の進展に伴い、これらの機能に加えオーナーや関係事業者間で情報共有やビジネスプロセスを回す仕組みを備えるものが出てきました。
複数の組織間でコンピュータを通じて情報共有する際に課題となるのが共通の言葉で会話する必要があるのに、共通の言葉が整備されていないという事です。コンピュータを使った組織間の会話には幾つかの形態がありますので、以下、それぞれの形態について見ていきましょう。
一つ目はひとつのFMシステムを組織間で共用する形態です。いずれかの事業者が保有するFMシステムや専門事業者から導入したFMシステムを各組織が利用して情報を共有します。この形態では画面や帳票はFMシステムが備えているものを利用しますから必然的に共通化されます。あとは、FMシステムに情報を登録する際の用語を共通化する必要があります。しかし、特定の組織が勝手に決めた用語を採用してしまうと他の組織はプロジェクトごとに使う用語が変わる事になるので得策ではありません。また、用語を決めた事業者が何年か後に他の事業者に交代すると用語が変わってしまうので、その観点でも望ましくありません。そこで共通データ仕様が提供している「用語」を採用する事で、プロジェクトが変わっても事業者が代わっても用語が共通化される事になります。
更に事業者が交替するときには、データをどうやって引き継ぐかという課題もあります。BIM (Building Information Modeling)では共通の形式としてIFCという仕様がありますが、施設管理にはその様な形式はありません。そこで、共通データ仕様の電子データの形式を活用してデータを引き継ぐ事が効果的です。
二つ目の形態は、FMシステムを共有するのではなく、電子データをやりとりする形態です。この形態では電子データの形式や用語を共通化する必要がありますが、一つ目の形態と同様に特定の組織の形式や用語を採用する事は望ましくありませんので、共通データ仕様の電子データの形式や用語を採用する事が望ましいです。
尚、この形態ではCSVでの情報共有が広く採用されていますが、ケーススタディ#1で説明する様にCSVには大きな制約があり、うまく設計しないと数多くの種類のCSVを部門や業務ごとに設計する必要が出てきます。CSVを設計する際には共通データ仕様の考え方に基づいてCSVの設計間で矛盾が無い様に検討する事が必要です。詳しくはケーススタディ#1をご覧ください。
三つ目の形態は「データ連携基盤」と呼ばれるシステムを置く形態です。各組織は必要に応じてこのシステムに情報を登録したり参照したりします。イメージとしては、大きなホワイトボードを置いておいて、各組織がそのボードに書き込んだり読んだりする感じです。デジタル庁ではこのシステムとして「エリア・データ連携基盤」を活用しようと考えています。従来は市区町村単位にこのエリア・データ連携基盤を設置する事が多かったのですが、デジタル庁はより早い普及を実現するために都道府県単位やそれ以上範囲で共同利用を進めようとしています。この形態では、用語の共通化に加えて電子データの形式をエリア・データ連携基盤のインタフェースの仕様1に準拠しておく必要があります。そこで、共通データ仕様のデータの形式はこの仕様に準拠してあります。
これらの形態は必ずしも独立のものではなく、組み合わせて実装します。例えば、外部からFMシステムを導入して普段はこのFMシステムの画面やアプリを通じて情報共有しつつ、電子データを施設のオーナーに提供して二次利用するなどの実装が幅広く見られます。今後は更にエリア・データ連携基盤も活用して観光や防災にも施設情報を活用する事が期待されます。
施設管理の形態
共通データ仕様はどの様な形態の施設管理でも適用可能です。以下、代表的な形態を例示します。ここに例示する形態以外でも勿論構いません。
■包括施設管理業務委託
包括施設管理業務委託は「業務への適用 (包括施設管理の場合)」に記載した様に自治体が行う施設管理業務を民間企業にアウトソースする形態です。民間企業は単に作業を代行するだけでなく、巡回点検などの付加価値を提供すると共にデジタル化を推進します。従って、FMシステムを選択し関係者に提供する立場となります。
■PFI
PFIでは代表企業がFMシステムを構築、または導入する事が多いと考えています。勿論、構成企業や協力企業がFMシステムを導入する事もあると考えます。 代表企業はFMシステムを活用する事で、自治体に新たな付加価値、例えばいつでも即時に状況確認できる、を提供する事が可能となります。また、情報共有を通じて代表企業自身の業務も高度化・効率化する事が可能となります。
想定するFMシステム
既に述べたようにFMシステムには多様な機能や形態があります。そこで、この説明で想定するFMシステムについて記載します。FMシステムとしては、どの様な形態でもどの様な機能を実装していても構いません。但し、少なくともFMシステム内に保存してあるデータを電子データの形で出力する機能を備えている事を想定します。電子データの出力とは以下形態を想定しています。
csvやExcelなどの表形式で出力
一般的なFMシステムではcsvファイルやExcelファイルでデータを出力する機能を備えている場合が多い様です。この機能を利用して、csvやExcelの形式で電子データを出力する形態です。
この形態では直接共通データ仕様の形式で出力することは出来ませんが、Excelやcsvに各項目に入力されている内容や用語は共通データ仕様を活用する事ができます。また、CSVを上手く設計しておくことで、ケーススタディ#2で掲載する様に、一旦出力した電子データを共通データ仕様の形式に変換する事も可能です。
FMシステムから直接共通データ仕様の形式で出力
FMシステムが直接共通データ仕様の形式で出力する機能を備えている形態です。
現在(2025-04-20)の時点でこの機能を備えているFMシステムの存在は確認できていませんが、沢山のcsvをお客様毎に設計する必要が無くなるなどのメリットもあり、幾つかの事業者が興味を示しています。事業者がFMシステムを自社で保有してある場合は、FMシステム自体を改造して共通データ仕様で出力する事も可能です。
尚、共通データ仕様はデジタル庁がエリア・データ連携基盤のブローカーとして推奨しているFiware/Orionの仕様であるNGSI V2に準拠しています。従って、この形態で出力した電子データを後でエリア・データ連携基盤に後で一括入力する事も可能です。
FMシステムから直接共通データ仕様の形式で出力
自治体がエリア・データ連携基盤を実装している場合は、エリア・データ連携基盤が持っているOpen APIを通じて電子データを登録する事が可能です。この形態の特徴はデータを多目的に活用できる事です。
デジタル庁を中心に政府はこの形式を将来的には普及させていきたいと考えていると思われます。
電子データの提供形態と時期
電子データを施設オーナー (下例では自治体) にお渡しする形態は色々あると思いますが、代表的な形態としては、前節に対応して以下の3っつの形態を想定しています。どの形態にするのかは、お客様が電子データをどう使いたいのか、事業者がどの程度システム的に対応可能なのかに依存しますので、最初に取り決めておく必要があります。
csvやExcelで渡す
FMシステムのcsvやExcelファイルでデータを出力した電子データを提出する形態です。お客様はcsvやExcelで分析や集計を行うことができます。
但し、csvやExcelのデータは表形式なので、提供できるデータには制約があります。従って、利用目的に合わせた電子データをお客様の要望に合わせて提供する必要があり、提供する電子データの種類が多くなってしまうという欠点があります。
この形態ても用語は業務開始当初から適用する必要があります。また、次の事業者に対しては、形式も共通仕様に合わせて変換して渡す必要があります。
この形態はケーススタディの1と2でも取り上げます。
共通データ仕様の形式で渡す
共通データ仕様はデジタル庁が推奨するエリア・データ連携基盤の仕様に合わせてあります。FMシステムが共通データ仕様に合致する電子データで提供する事で、csvやExcelでは表現できない情報も提供可能となります。例えば土地の形状をポリゴン(座標の列)で表現している場合などがあります。
提供された電子データは多目的に活用可能ですから、利用者は必要な部分を取り出して分析や集計を行う事が可能です。
次の事業者には、提供した電子データをそのまま渡す事が可能です。
データ連携基盤に直接登録
この形態はエリア・データ連携基盤などのシステムの実装が前提となります。報告書の提供と同時にシステムに電子データを登録します。共通データ仕様の報告書 (Report) のデータには、pdfなどの報告書の格納場所も登録可能ですので、報告書の提出自体を電子データで行う事もできます。
利用者はエリア・データ連携基盤が提供する機能(座標や距離で抽出するなど)を利用できるだけでなく、施設管理以外の業務にもそのまま利用可能となります。
前記の電子データの提供形態にも関係しますが、電子データをお客様にお渡しする時期についても幾つかの形態があります。代表的な提供時期としては以下の3っつを想定しています。
契約終了時に一括して電子データを提供
包括施設管理業務委託の契約期間の終了時に一括して電子データを渡す形態です。従って、電子データの目的は次の事業者への引継ぎの効率化となります。
この場合も、用語は業務開始当初から適用する必要があります。書類による報告は随時行われますし、事業者によってはお客様 (自治体) に端末やお客様専用のWebサイトを提供する場合がありますので、お客様の担当者は電子データが手許に無くても、共通データ仕様の用語に準拠した情報が得られます。
定期的に電子データを提供
例えば月末や年末などに電子データをまとめて提供する形態です。電子データには、公共施設の基本情報と不具合の情報が含まれますが、基本情報の方は初回から一括して電子データ化して渡す必要があります。
この場合も、用語は業務開始当初から適用する必要があります。
自治体側のメリットは最新の施設情報が手に入りますから、電子データを施設計画や分析に活用できる点です。
報告書と同時に電子データを提供
この形態はファイルサーバやエリア・データ連携基盤などのシステムの実装が前提となります。報告書の提供と同時にシステムに電子データを登録します。
お客様が電子データを他の業務にも活用しようとする場合には、最新の施設の情報が共有されるので、メリットが大きいと思われます。一方、エリア・データ連携基盤を実装する必要があります。
どの形態であっても、事前検討が必要です。以下、事前検討について記述します。
施設と建物
本題に入る前に「施設」と「建物」について少し考えてみましょう。
辞書を引くと、施設とは何らかの「目的」のために設ける構造物や建築物や設備を指すとの事です。例えば、商業施設であれば商業を営むための建物群や設備群でしょうし、公共施設であれば公共サービスを提供するための建物群や設備群ということなります。
この例では施設は建物と建物の敷地と設備を合わせたものというイメージですが、一般的には建物に入居しているテナントも施設と呼ぶことがあります。例えば、駅前のビルに「市民センター」などという窓口を設置している例や、下図のように複合施設に複数の公共施設が入居している例などがあります。
この様に施設は建物群や土地を含めた全体を表現する場合と、施設の中にある小さな施設を表現する場合があります。施設の点検や修繕を行う施設管理では前者を主にイメージしますが、施設カルテなどでは後者の小さな施設ごとにレポートしている場合もありますから、共通データ仕様としてはどちらの形態でも表現できるようになっています。
同様に建物も複数の意味を持ちます。例えば前出の小学校の図では校舎と体育館を合わせた全体を「建物」と言う場合もあれば、校舎と体育館を別の建物と言う場合もあります。多くの場合、後者の建物は「棟」と呼んだりします。建築基準法に定められている12条点検では、報告は前者の建物で行いますが、報告書の中を見ると棟毎に細かな報告を求められています。この様な事情から共通データ仕様の建物は建物全体も表現できますし、建物に含まれる建物(棟)も表現できるようになっています。
では、データ仕様から見て施設と建物との差は何かというと、施設は何らかの目的があって設置されているので、その目的を実現するための情報があるという事になります。例えば、入居組織、連絡先、収容人数、開館閉館時間、利用料、利用条件などです。これらは建物の項目(属性)ではなく、施設の項目(属性)ということになります。
■PFIや包括施設管理からみた共通データ仕様
PFIであっても包括施設管理であっても、どの様な情報を自治体や関係企業と共有するのかは業務の範囲・自治体の要件・事業者の考え方に依存します。以下、それぞれについて再掲します。
- 全体を表す「施設」
共通データ仕様としては、施設全体を代表するモノとしてはこの「施設」と「建物」の2種類から先手くできる様になっています。但し、「建物」は物理的な建築物を表現するデータモデルなので、開館時間や連絡先などの情報は登録できません。また、一般的に施設管理とは言いませんが、公園の様な施設では建物があるとは限りませんので、施設管理の場合もこの「施設」を中心にデータを組み上げておく方が得策でしょう。 - 個々のテナントを表す入居「施設」
入居組織や連絡先などのテナント情報を共有したり、次の事業者に引き継いだりする場合にはこの情報も必要です。必須という訳ではありません。但し、不具合発生時にテナントに連絡が必要な場合は、必要な情報となります。また、施設カルテや利用実績の集計などに有効な情報です。また、施設管理でも不具合発生時にテナントに連絡する必要がある場合は引継ぎ情報として有効です。 - 複数の棟をまとめた「建物」
既に記載した様に一般的に「建物」と言った場合、複数の棟をまとめた建物全体を意識する場合と個々の棟を意識する場合があります。このため、共通データ仕様の「建物」の項目にも全体を表す項目と個々の棟を表す項目の両方があります。全体を表す項目としては例えば建築基準法で決められている「用途」や「所有者」などがあります。棟を表す項目としては建築面積や延べ床面積などがあります。従って、共通データ仕様としては「建物」を少なくとも1件は登録する必要があります。この情報はどの様な施設管理形態でも必要です。全体を表す「施設」に対し全体を表す「建物」はひとつだけ存在します。12条点検が不要な施設や元々棟が1つしかない施設であれば、同じ「建物」に棟の情報も一緒に登録してしまえば、「建物」の登録はひとつだけで済みます。 - 一つひとつの棟を表す「建物」
12条点検などの報告のために棟に分けて不具合情報を蓄積する際には前記の棟の情報を登録した「建物」を作成することが有効です。但し、各棟の床面積などの細かな情報を共有する必要はなく、単に棟の名称を共有するのであれば別の方法もありますので、必須という訳ではありません。
この様に施設管理から見ると、共通データ仕様をどこまで利用するのかは、施設情報を共有するか共有しないかの判断次第という事になります。施設情報を共有しないと情報共有はシンプルになりますが、テナントなどの情報が欠落するので情報としての価値は低下し、施設管理以外には流用が難しくなります。
事前検討 — 施設や建物の整理
既に記載した様に、共通データ仕様は施設管理の情報共有を建物だけで行っても施設全体まで広げて行っても対応可能としてあります。共通データ仕様は施設管理に必要な情報を共有するための仕様ですから、施設情報をどこまで共有するかはFMシステムで施設情報をどの様に管理しているのか、或いはオーナーにどこまでの情報共有を期待されているかなどに依存します。以下、それぞれについて説明します。
■施設情報を共有する場合
施設情報を共有する場合です。つまり、包括施設管理事業者はテナント名や連絡先などの施設情報も共有が必要な場合などにこちらを選択します。施設管理とは関係ありませんが、都市公園の管理では施設と土地はあるけれど建物は無いという場合がありますので、それらのデータと親和性があるので、何も理由が無い場合は施設情報を登録できる様にしておくことをお勧めします。
この場合、共通データ仕様の「施設 (Facility) 」というデータモデルが情報共有の中心となります。情報共有の中心となるという意味は、建物、土地、設備などの各種情報が施設の情報から紐づけられているという意味です。また、「施設」には施設全体の各部分の名称を登録しておく「場所(zones)」という項目や他のシステムとの連携を容易にするための管理の単位に付与する通番である「管理通番(facilityId)」と言う項目も用意してあります。この「施設」は複合施設の様に施設の中にまた施設がある場合にも対応できる様に策定してあります。
〇基本的なパターン
建物がひとつの施設で占有されている場合や、複合施設の様に施設内に施設があっても全体をひとつの施設として考える場合です。自治体としてもひとつの建物と敷地をひとまとめに管理対象とする基本的なパターンです。
この場合は、共通データ仕様に特に考慮するべき点はありません。用語を守って情報登録するだけです。
一方、共通データ仕様の形式で電子データを作成する場合は、ひとつの施設につき、「施設」と「建物」と「土地」を1件ずつ作成する事になります。施設は建物や土地を含む概念ですが、データの形式上は「施設」には「建物」や「土地」の情報は含まず、「施設」から「建物」や「土地」を辿れる様になっているので、この3種類の電子データを作成する事で、ひとつの施設に関係する情報が揃う事になります。勿論、FMシステムの画面やオーナーの求めに応じて出力する電子データでは、施設と建物と土地を区別せず、ひとつの情報として表示したり出力する事も構いません。共通データ仕様上、敷地は「土地(Land)」と言うデータモデルが対応します。敷地が複数の土地に分かれている場合、全ての「土地」をバラバラに電子データ化する事も出来ます。
このパターンの問題点は、複合施設の様に複数の施設がテナントとして入居していても、連絡先などの情報は一つしか登録できない事です。また、施設カルテの元データや、各種オープンデータの元データとしても活用が難しいです。
〇施設の中の各施設も情報共有する場合
建物内に複数の施設がテナントとして入居していて、施設管理は施設全体で行いつつも、連絡先などのテナントの情報も共有したい、施設カルテの元データとしたい、施設管理以外にもデータを活用したいなどのニーズを満たしたいケースです。
右図では、全体の施設(複合施設)と建物内に入居する施設が2つあります。そこで、共通データ仕様の形式で電子データを作成する場合は、「施設」3件と「建物」と「土地」を1件ずつ作成する事になります。全体を表現する施設情報からは、前項の「基本的なパターン」と同様に「管理通番(facilityId)」や「場所(zones)」を登録するだけでなく、主管部門などの情報へのリンクが登録されます。この場合の連絡先とは、例えば警備員室など、テナント共通の連絡先です。テナントとなっている「施設」情報には入居フロアの情報も登録しておくと便利でしょう。例えば”1F”とか”本館”などの情報です。その施設だけに取得した個別郵便番号を登録しておいても便利かもしれません。一方、管理の単位ではないので「管理通番」という項目は登録する必要はありません。
〇主たる施設がある複合施設の場合
建物内に複数の施設がテナントとして入居していても、主たる施設が存在する場合があります。例えば、多くの学校には備蓄倉庫などが併設されていて、統計上は複合施設となつている場合が多いのですが、○○小学校などと呼んでも違和感はありません。同様に、災害時に避難所と言う施設を開設する場合には学校と言う施設と避難所という施設があり、それぞれ連絡先、収容人数、開館時間帯などの属性は異なりますが、普段から設置してある学校を主たる施設と考えても違和感はないでしょう。この様な場合は「基本的なパターン」で運用しつつ、副次的な施設を追加登録する事で表現可能です。
右図では、主たる施設と副次的な施設が1つあります。そこで、共通データ仕様の形式で電子データを作成する場合は、「施設」2件と「建物」と「土地」を1件ずつ作成する事になります。副次的な「施設」情報には入居フロアなどの情報を登録しておくと便利でしょう。但し、管理の単位ではないので「管理通番(facilityId)」という項目は登録する必要はありません。
〇建物の一部だけが管理対象の場合
施設の一部に施設が入居していて、共通データ仕様の形式で電子データを作成した場合です。例えば、民間の建物の一部に公共施設が入居しているケースなどです。建物の管理は貸し手の民間企業が行うと思われますが、例えば施設カルテの作成の際などに必要となると考えて、共通データ仕様はこのケースも表現できる様にしてあります。
共通データ仕様の形式で電子データを作成する場合は、基本的なパターンと同様に、「施設」と「建物」と「土地」を1件ずつ作成する事になります。「建物」や「土地」のデータも必要な理由は、住所やピル名が必要となるためです。従って、土地の面積や建物の床面積などの情報まで登録する必要性は低いと思われます。
■建物情報を中心に情報共有
施設情報は共有しない。つまり、包括施設管理事業者はテナントなどの施設情報は管理していない場合にはこちらを選択し、簡略化することもできます。但し、連絡先などの情報は登録できませんし、施設情報が必要となるオープンデータや施設カルテの元データとしての活用は難しくなるので、この形態を推奨はしていません。
この場合、共通データ仕様の「建物 (Building) 」というデータモデル が情報共有の中心となります。従って、「施設」同様に「場所(zones)」という項目や「管理通番(facilityId)」と言う項目を用意してあります。「場所」に登録する情報には建物外の場所、例えば学校のグランドにある照明設備などを登録して情報共有する事を可能としてあります。尚、この「建物」は公営住宅や学校の様に複数の棟を含む事が可能である様に共通データ仕様は策定してあります。
〇1棟で建物が構成されている場合
建物が一棟で構成され建物全体がひとつの施設で占有されている場合で、自治体としてもひとつの建物と敷地をひとまとめに管理対象とする基本的なパターンです。
この場合は、共通データ仕様に特に考慮するべき点はありません。用語を守って情報登録するだけです。
共通データ仕様の形式で電子データを作成する場合は、「建物」と「土地」を1件ずつ登録する事になります。敷地は「土地(Land)」と言うデータモデルで登録します。敷地が複数の土地に分かれている場合、全ての「土地」を登録する事も出来ます。その場合、一つ目の土地に建物の住所に一致する土地を登録します。
共通データ仕様では、このパターンに対応するために、「施設」の項目である「場所」と「管理通番」を「建物」にも策定してあります。
〇複数の棟で建物が構成されている場合
建物が複数の棟で構成されている場合は建物全体を表す「建物」と棟を表す「建物」の両方の登録が可能です。これは、12条点検などでは、棟毎に記載する項目があるためです。例えば右図の様に2棟ある建物の場合は合計3件の「建物」を登録する事が可能です。
繰り返しですが、棟の登録は必須ではなく、事業者やオーナーの判断に依存します。従って、棟毎の情報を登録する必要が無い場合、1件の「建物」で済ます事も共通データ仕様としては可能です。また、土地は棟毎に別の「土地」を登録する事も可能ですし、ひとつの「土地」で済ますことも可能です。
〇施設を複数の建物に分割する場合
ひとつの施設の建物が複数の棟が構成させる場合で、棟ごとに分けて施設管理を行うケースです。このケースについては現在の共通データ仕様では想定していません。これは、共通データ仕様が多目的データモデルであって、現実のモノやコトに対応して策定されているためです。前項の様に建物を一つ登録し、棟として分けて情報共有するか、棟毎に別の施設として「基本的なパターン」で管理する事を検討してください。
もし、この様な情報共有が必要になった場合は、データモデルの拡張を事務局に要求してください。
補足説明
■施設の定義について
政府がオープンデータのデータモデルとして定めている「自治体標準オープンデータセット」では、医療機関、観光施設、介護サービス事業所、子育て施設など、建物ではなく、サービスを提供する機能を表現しています。本共通データ仕様では、自治体標準オープンデータセットを踏襲し、サービスを提供する機能に対応して施設を定義しています。また、近年は民間のビルの一部に自治体のサービス窓口を設置する事の多いため、この観点でも建物と施設を区別してデータモデルを分けてあります。
- デジタル庁ではエリア・データ連携基盤のソフトウェアとしてFiwareのモジュールの幾つかを推奨しています。このインタフェースの仕様はNGSI V2と呼ばれています。 ↩︎