案件と報告の登録
共通データ仕様では不具合を含む各種報告を登録するために「報告 (Report) 」をデータモデルを、不具合の補修や修繕を登録するために「案件 (Complaint) 」のデータモデルを提供しています。「案件」は不具合が発生してから修繕が完了してオーナー(自治体)の承認を得るまでの一連の流れを指します。これに対し、「報告」はオーナーへの報告を登録します。「報告」にはpdfなどのファイルになった報告書の格納位置を指す情報が登録されます。
不具合の登録において「報告」と「案件」の関係は1対1とは限りません。ひとつの不具合に対し何度も報告する事もあり得ますし、ひとつの不具合で、複数の修繕を実施する場合もあります。そこでここでは、各種パターンの登録方法を例示します。実際の運用はオーナーと事業者との間で協議して決めていくものですので、以下の例示の通りとなるとは限りません。
■不具合が無い事の報告
検査をしたのに不具合が無い事を報告する運用もオーナーや事業者によってはあるかもしれません。その場合は以下の様になります。仕様上は案件は登録してもしなくても構いません。
■一般的な不具合の修繕
報告書を伴う報告をどのタイミングで提出する必要があるかはオーナーや事業者によって異なると思われますが、一般論で言うとひとつの不具合に対し複数の報告があり得ます。その場合には下図のようにひとつの「案件」に対し複数の「報告」が登録される事になります。
■複数の案件を一括登録する場合
不具合を見つけた場合に処置が複数に分けられる場合があります。例えば階段のノンスリップ(滑り止め)が摩耗して剥がれている時、まずは危険を除去するために剥がれている段だけノンスリップを即日交換し、後日階段全段を交換する事が想定されます。この場合、修繕作業が二種類発生しますので、以下の様に「報告」に対して複数の「案件」が登録されます。この様にすることで、オーナーや事業者はそれぞれ別の作業として管理する事が可能となります。
■後から案件を追加登録する場合
案件の報告後にオーナーからの指示などにより案件を追加する場合もあります。前記の例と同様に部分補修を取り合えず実施し、後から恒久処置を追加実施する場合などです。その場合、改めて報告書を提出する方法もありますが、共通データ仕様では案件だけを追加する事も可能です。その場合、案件の「関連案件ID」で案件同士を繋いでおく必要があります。
■不具合が再発した場合
雨漏りの様に不具合の原因が複数あるかもしれない場合や原因の特定が難しい場合には、想定した原因に対うる修繕を行っても現象が再現してしまう場合があります。この場合は、「報告」と「案件」を再登録します。基本的に一度完了した案件を継続する事は避けるべきですし、技術的にも最初の不具合と再現した不具合の原因が実は同一であったと証明する事は困難なためです。
■12条点検の場合
12条点検であっても、通常の点検と同様に不具合があればオーナーに報告し、「報告」と「案件」のデータも登録する必要があります。オーナーによっては、この個別の報告とは別に12条点検の報告書も電子的に保存したいと考える場合があります。その場合、ひとつの不具合に関する「案件」が両方の「報告」からリンクする事が共通データ仕様では可能です。尚、12条点検の報告から案件をリンクるかどうかは共通データ仕様では定義しておらず、オーナーや事業者の判断によります。
用語の活用
共通データ仕様では各種用語を定義していますが、再委託先の作業者にまで徹底する事はなかなか難しいと思われます。共通データ仕様では、用語の徹底を図るために以下に例示する用語の利用法を想定しています。このため、用語はWeb上で仕様として公開する以外に、Excelファイルでも提供しています。MS ExcelでFMシステムに適する様に加工して、一括して設定する事が可能です。
| アプリのプルダウンメニュー | 表計算ソフトのプルダウンメニュー | ハンドブック等による周知 |
| FMシステムによっては、不具合報告等の画面で現象などの項目にプルダウンメニューを設定できるものがあります。その場合は、本共通データ仕様の用語を登録して使います | 包括施設管理事業者がExcel等の表計算ソフトを電子帳票として再委託先に配付している場合は、表計算ソフトが備えているプルダウンメニューの機能を使って再委託事業者が共通データ仕様に合致した用語を選択できる様にします。 この場合、用語が追加される度に表計算ソフトのファイルを配布しなおす必要があります | 包括施設管理事業者が再委託先に配布している資料に用語の一覧を掲載する形態です。 この場合も、用語が追加される度にハンドブック等を配布しなおす必要があります |
