ケーススタディ#8 – ArcLibを使ってみました(1/4)

本ケーススタディの概要

　施設管理のクラウドサービスには多様なものがあり機能性・操作性・付随サービスなどでお互いに覇を競っています。一方共通データ仕様はオーナーと各種施設管理事業者とのやりとりや事業者間の情報共有に着目してそのデータ仕様を共通化する取り組みですから、各クラウドサービスが共通データ仕様に全て則って設計されている事はあり得ません。そこで、個々の施設管理のクラウドサービスで具体的にどの様に共通データ仕様を活用するのか、実際にサービスを使った操作例を紹介します。

　本ケーススタディでは、住友セメントシステム開発株式会社(以下、スミテム)が提供する施設管理のクラウドサービスArcLibを使ってみます。上記の様に共通データ仕様は関係者間での情報のやりとりをする際のデータ仕様を共通化しようとするものですが、ArcLibは法人間の情報のやり取りだけでなく内部管理や計画策定なども含めた多様な使い方ができます。従って、本ケーススタディはArcLibの機能のほんの一部だけを紹介しているものである事、そしてこのケーススタディの使い方はArcLibの利用法のごく一例だとご理解ください。ArcLibを導入する際に、本ケーススタディを単純に踏襲する事はお勧めしません。事前に同社とよく相談して自社の手順やお客様の要望に合わせて活用する事を強くお勧めします。尚、ArcLibの機能詳細は同社のホームページをご覧ください。

ArcLibの特徴と共通データ仕様との整合方法

　共通データ仕様は文字通りデータの仕様に過ぎませんし、その対象も事業者やオーナー等の法人間のデータのやり取りである事に対し、ArcLibは独立したシステムでありクラウドサービスなので単純に比較する事は無理があります。そこで、ここではArcLibのデータ登録などの各種画面やCSVへのダウンロードの機能をデータをやり取りするためのデータ仕様に見立てて比較します。

　「共通データ仕様の基礎知識」に記載しように、共通データ仕様は「多目的データモデル」であり、モノやコト単位にデータを登録する流儀で作成されています。ArcLibも同様にモノやコトを登録できるようになっています。

　設備管理で登録しなければならないモノは、事業者やオーナによりそれぞれ異なると思われますが、一般的には以下の様になっていると思われます。「共通データ仕様の呼び方」にはデータモデルの呼称を表示していますが、項目を表示する場合は「データモデルの呼称/項目の呼称」の形式で表示しています。

管理対象の「モノ」	共通データ仕様の呼び方	ArcLibの呼び方	説明
オーナー	法人	連絡先企業 (オーナー)	施設管理の対象施設群のオーナーです。 　共通データ仕様では、「法人(Organization)」というデータモデルで登録します。この「法人」はオーナーに限らずあらゆる団体を表現可能であり、「施設(Facility)」からオーナーの法人内の所管部門を示す項目「所管部門ID」でリンク1する事でその法人がその施設のオーナーであると認識できます。 　ArcLibでは法人は「連絡先企業」として登録します。連絡先企業にはその属性のひとつに「連絡先企業種類」があり、そこに「オーナー」を設定する事でオーナーの情報であると識別できます。
所管部門	部門	連絡先担当者	管理対象の個々の施設に対するオーナーの法人内の所管部門です。 　共通データ仕様では、「部門(Department)」と言うデータモデルで登録します。この「部門」はオーナーの「法人」をリンクする事でオーナーの部門であると認識できます。共通データ仕様には部門内の担当者に相当するデータモデルは無く、連絡先は部門の連絡先として登録します。これは、共通データ仕様が法人間の情報共有を念頭に策定されているためです。 　ArcLibではオーナーとして登録した連絡先企業内の「連絡先担当者」として登録します。連絡先担当者にはその属性として「担当部署名」があり、所管部門はこの担当部署名が対応します。共通データ仕様は個人名は登録しませんが、ArcLibでは業務の実情に合わせて個人名や携帯電話番号も登録できます。
施設	施設	施設 建物(建物)	ここでいう「施設」とは、建物や土地を含めた施設管理の対象です。例えば施設の法定点検や巡回点検を行う際の対象は「○○小学校」などの施設全体となります。「全体」と断っているのは、テナントとして入居している個々の「施設」ではないという意味です。 　共通データ仕様では「施設(Facility)」が対応します。共通データ仕様では「施設全体」も、テナントとして入居している施設も、避難所の様に一時的に設置される施設も表現できますが、ここでは施設全体を指します。 　ArcLibにおける施設とは後述する建物を束ねる単位であり、「○○小学校」などの施設を指すことも出来るし、もっと幅広く、例えば所管部門単位に束ねる事もできます。本ケーススタディでは共通データ仕様の考え方に合わせて、○○小学校などの単位とします。施設は建物を束ねる機能なで、例えば後述する「場所」などの登録はできません。そこで、施設の建物の中のひとつを主たる建物とし、そこに登録する運用とします。詳しくは後述します。
棟	建物 土地	建物(建物)	施設を構成する個々の建築物を指します。施設が複数の棟から構成されている場合、12条点検などの法的な点検報告では報告自体は施設全体で提出する必要があるものの、その報告書の中身については棟毎(建築物ごと)に帳票を分けて記載する事を求められる場合がありますのでこの情報が必要となります。 　共通データ仕様では二つの登録方法があります。ひとつ目は複数の棟をひとまとめにして「建物(Building)」として登録する方法と、ひとまとめにした「建物」に加えて棟毎にも「建物」を登録する方法です。「建物」複数が出てきたので混乱するかもしれませんが、詳しくは「施設管理における使い方」をご覧ください。 　ArcLibでは個々の棟をそれぞれ「建物」として登録します。
場所	施設/場所	建物(建物) 建物(構造物)	施設内に設備を設置する際や不具合が発生した場合、それが施設内のどの場所なのかを表現する必要があります。例えば部屋の壁が汚れているなどの事態が発生した場合、施設のどの部分で不具合が発生したのかを明確にする必要があります。例えば「”校舎”の”1階”の”音楽室”の壁が汚れている」や「”屋外”の”駐車場”の車止めが壊れている」などとなります。このため、施設の敷地や各棟の各部分の名称を登録しておき、作業者やオーナー間で呼称が食い違わない様にしておく必要があります。 　共通データ仕様では、「施設」の項目である「場所(zones)」に棟内や屋外の名称を登録しておくことが必要です。場所は三階層で登録でき、場所大分類・場所中分類・場所小分類という項目があります。場所のどの階層に棟を対応させるかについての規則はありませんが、本ケーススタディでは場所大分類に棟名を、屋外の場合は”屋外”という文字列を登録しています。例えば、「場所」に”屋外”-“駐車場”と登録しておくことで屋外の駐車場を表現する事が可能となります。 　ArcLibでは各棟内の場所は「建物」の属性として登録する事ができます。この属性は「棟」「階」「場所」の三階層になっています。本ケーススタディでは主たる建物を選択し、その建物に全ての場所を登録する事とします。この考え方について後で詳しく記載します。
入居施設	施設	連絡先企業 (テナント) 連絡先担当者	施設内に入居している施設です。施設カルテなどでは複合施設の場合には入居している施設(テナント)毎に分けてカルテを作成する事があります。 　入居施設は共通データ仕様では「施設(Facility)」が対応します。施設全体と同様に「施設」が出てきます。この点についても詳しくは「施設管理における使い方」をご覧ください。 　ArcLibでは連絡先として登録します。連絡先企業の連絡先企業種類」に「テナント」を選択する事により入居テナントである事を認識します。更に担当者も登録する事で、部門名や電話番号も登録可能です。
設備	設備	設備	文字通り設備です。設備は一つひとつ別のモノとして考えます。但し、どこまで細かく管理するのかは事業者やオーナーによって異なります。 　共通データ仕様では設備は施設に属し、その施設の中のどの「場所」に設置されているのかを表現できます。 　ArcLibでもそれぞれの設備を登録します。ArcLibの設備は建物に属します。そこで、施設の説明で記載した「主たる建物」に属する事とします。
部位	部位	建築	設備以外の施設の部分です。部位もどこまで細かく分類して情報を残すのかは事業者やオーナーによって異なります。

以上をまとめると、本ケーススタディでは管理対象の施設の各部分の情報をどこに登録するのかに関する共通データ仕様とArcLibに登録する施設情報の関係は以下の通りです。

この図の中で共通データ仕様の「施設」にある「場所」と言う項目は、既に記載した様に施設内の各場所の名前を登録しておく項目ですが、この項目にはケーススタディ#0にある様な名前のリストを登録する事が出来る仕様になっています。

　既に記載した様にArcLibでは棟毎に建物を登録する必要があります。そこで、本ケーススタディでは以下の様にしました。これ以外にも多様な方法があると思いますので、それぞれの事情に照らして工夫してください。

　次にコトの表現です。施設管理におけるコトには多種多様なものがありますが、本ケーススタディでは各種作業の計画や実行を指します。ArcLibは施設管理における多様なコトを柔軟に表現できます。例えば法定点検や巡回点検の様な日程が予め決まっている作業は「年次予定表」として登録できます。また、突発的な要望や不具合への対応は「作業」の「受付・処置」といて登録できます。

　これらを図にすると以下の様になります。ArcLibでは不具合は「受付・処置」に登録します。どの機器でどの様な症状が発生したのかなどの情報はこの受付内容の項目として登録します。また、設備や部位は後から登録できますので、必ずしも事前登録は必須ではありません。本ケーススタディは設備は事前登録する運用としています。

ケーススタディ詳細

　本ケーススタディでは、ケーススタディ#0に示した仮想的な施設を管理する事を想定します。

　実際にデータをArcLibに登録する作業についてはスミテムに必ず事前にご相談ください。ArcLibに限らず、全てのクラウドサービスは初期導入時のデータ登録や操作の修得がひとつのハードルです。そこで同社としても利用者の負担を減らす多様な対応を提供しています。従ってこのケーススタディでは、登録手順の詳細はイチイチ記載しませんので、実際の手順はスミテムにお願いするかマニュアルをご覧ください。繰り返しですが、皆様はスミテムとよく相談して効率よく、そして後で後悔しない導入を進めて下さい。

　では話をケーススタディに戻しましょう。

　本ケーススタディで想定する作業は下図のように巡回点検により不具合を見つけたけれど、まずは応急的な処置を実施し危険を取り除いたうえで恒久処置を計画する内容を想定します。恒久処置は予算の都合なのか実施されていないと想定します。尚、巡回点検の計画の登録や実施結果の登録もArcLibで実施可能ですが、残念ながら本ケーススタディでは割愛して、筆者の都合で不具合の登録と処置の登録のみ掲載します。将来的には更に執筆範囲は強化していきたいと思います。

　このケーススタディでは施設、建物、場所、および設備を事前に登録する運用とします。一方で部位(建築)は事前登録せず、不具合等が発生した都度登録する運用とします。