(57)【要約】      （修正有）【課題】より簡便に、建築物に対する検査の検査結果を管理する検査情報管理装置、検査情報管理システム及び検査情報管理プログラムを提供する。【解決手段】検査情報管理装置１０は、建築物に対する検査の検査結果を入力するための雛形を複数記憶する雛形記憶部１４と、雛形をユーザ端末に対して送信すると共に、送信した雛形に検査結果が入力されることにより作成された帳票を前記端末から受信し、受信した帳票を複数の提出先の何れかに提出するために管理する情報管理部１２と、を備える。雛形記憶部１４は、複数の提出先それぞれに対応する雛形を記憶する。【選択図】図２
2019032608.tif 000002
【特許請求の範囲】
【請求項１】
建築物に対する検査の検査結果を入力するための雛形を複数記憶する雛形記憶部と、
前記雛形を端末に対して送信すると共に、該送信した雛形に前記検査結果が入力されることにより作成された帳票を前記端末から受信し、該受信した帳票を複数の提出先の何れかに提出するために管理する情報管理部と、
を備え、
前記雛形記憶部は、前記複数の提出先それぞれに対応する雛形を記憶する検査情報管理装置。
【請求項２】
前記帳票の提出先とは、前記建築物が建築されている地域を管轄する自治体であり、
前記雛形記憶部は、前記複数の提出先それぞれに対応する雛形として、前記自治体それぞれで要求される書式に準拠した雛形を記憶する請求項１に記載の検査情報管理装置。
【請求項３】
前記雛形は、第１の検査項目について入力された検査結果に応じた値に基づいて、第２の検査項目についての値を算出する数式データを含む請求項１又は２に記載の検査情報管理装置。
【請求項４】
前記雛形は、前記検査結果に対応するテキストデータを含んでおり、前記テキストデータの文言の少なくとも一部が前記雛形毎に異なる請求項１から請求項３までの何れか１項に記載の検査情報管理装置。
【請求項５】
前記建築物の検査結果とは、前記建築物に設置された、防火扉、防火シャッター及び耐火クロススクリーンの少なくとも何れかについての検査結果である請求項１から請求項４までの何れか１項に記載の検査情報管理装置。
【請求項６】
請求項１から請求項５までの何れか１項に記載の検査情報管理装置と、前記端末とを備えた検査情報管理システムであって、
前記端末は、
前記検査に関する画像を撮像するための撮像部と、
前記帳票作成時に、前記撮像部が撮像した画像を前記雛形における所定位置に配置することにより、前記撮像部が撮像した前記画像と前記検査結果とを紐付ける帳簿作成部と、
を備える検査情報管理システム。
【請求項７】
前記端末は、前記建築物に対する検査を行うユーザによって、前記建築物にて利用される携帯可能な端末である請求項６に記載の検査情報管理システム。
【請求項８】
コンピュータを検査情報管理装置として機能させるための検査情報管理プログラムであって、
建築物に対する検査の検査結果を入力するための雛形を複数記憶する雛形記憶部と、
前記雛形を端末に対して送信すると共に、該送信した雛形に前記検査結果が入力されることにより作成された帳票を前記端末から受信し、該受信した帳票を複数の提出先の何れかに提出するために管理する情報管理部と、
を備え、
前記雛形記憶部は、前記複数の提出先それぞれに対応する雛形を記憶する検査情報管理装置として前記コンピュータを機能させる検査情報管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、建築物の検査についての情報を管理するための、検査情報管理装置、検査情報管理システム、及び検査情報管理プログラムに関する。
【背景技術】
【０００２】
建築物の設備（例えば、シャッターやドア等）に対しては、定期的に検査を行い、その機能が確保されていることを確認することが望ましい。特に、防火シャッターや防火ドアについては、火災発生時に確実に動作することを確認するために、これらが設置された現地での定期検査が必要となる。
【０００３】
従来、このような定期検査は、ユーザが現地に出向いて検査を行い、その検査結果を現地にて紙の帳票に記入することにより行われている。しかし、このように紙の帳票を用いた場合には、後日、事業所等において、紙の帳票の内容をコンピュータに入力して、集計するような作業が生じてしまう。
【０００４】
このような集計作業を簡略化するための技術が、特許文献１に開示されている。特許文献１に開示の技術では、ユーザに記入内容を電子化するための電子ペンを携帯させる。そして、ユーザに、電子ペンにて帳票へ記載を行わせることにより、検査結果の内容を電子化する。また、この電子化した検査結果の内容をサーバにて管理することにより、ユーザの手間を軽減することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２１３３５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に開示の技術を含めた一般的な技術では、検査結果の収集を簡略化することについては考慮しているが、この収集した検査結果の管理については十分考慮されてはいなかった。例えば、収集した検査結果の提出先について考慮していなかった。
【０００７】
そこで本発明は、より簡便に検査結果を管理することが可能な、検情報管理装置、検査情報管理システム、及び検査情報管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
（１）  本発明の検査情報管理装置（例えば、後述の検査情報管理装置１０）は、建築物に対する検査の検査結果を入力するための雛形を複数記憶する雛形記憶部（例えば、後述の雛形記憶部１４）と、前記雛形を端末（例えば、後述のユーザ端末２０）に対して送信すると共に、該送信した雛形に前記検査結果が入力されることにより作成された帳票を前記端末から受信し、該受信した帳票を複数の提出先の何れかに提出するために管理する情報管理部（例えば、後述の情報管理部１２）と、を備え、前記雛形記憶部は、前記複数の提出先それぞれに対応する雛形を記憶する。
【０００９】
（２）  上記（１）に記載の検査情報管理装置を、前記帳票の提出先とは、前記建築物が建築されている地域を管轄する自治体であり、前記雛形記憶部は、前記複数の提出先それぞれに対応する雛形として、前記自治体それぞれで要求される書式に準拠した雛形を記憶するようにしてもよい。
【００１０】
（３）  上記（１）又は（２）に記載の検査情報管理装置を、前記雛形は、第１の検査項目について入力された検査結果に応じた値に基づいて、第２の検査項目についての値を算出する数式データを含むようにしてもよい。
【００１１】
（４）  上記（１）から（３）の何れかに記載の検査情報管理装置を、前記雛形は、前記検査結果に対応するテキストデータを含んでおり、前記テキストデータの文言の少なくとも一部が前記雛形毎に異なるようにしてもよい。
【００１２】
（５）  上記（１）から（４）の何れかに記載の検査情報管理装置を、前記建築物の検査結果とは、前記建築物に設置された、防火扉、防火シャッター及び耐火クロススクリーンの少なくとも何れかについての検査結果であるようにしてもよい。
【００１３】
（６）  本発明の検査情報管理システムは、上記（１）から（５）の何れかに記載の検査情報管理装置と、前記端末とを備えた検査情報管理システム（例えば、後述の検査情報管理システム１）であって、前記端末は、前記検査に関する画像を撮像するための撮像部（例えば、後述の撮像部２４）と、前記帳票作成時に、前記撮像部が撮像した画像を前記雛形における所定位置に配置することにより、前記撮像部が撮像した前記画像と前記検査結果とを紐付ける帳簿作成部（例えば、後述の帳簿作成部２２）と、を備える。
【００１４】
（７）  上記（６）に記載の検査情報管理システムを、前記端末は、前記建築物に対する検査を行うユーザによって、前記建築物にて利用される携帯可能な端末であるようにしてもよい。
【００１５】
（８）  本発明の検査情報管理プログラムは、コンピュータを検査情報管理装置（例えば、後述の検査情報管理装置１０）として機能させるための検査情報管理プログラムであって、建築物に対する検査の検査結果を入力するための雛形を複数記憶する雛形記憶部（例えば、後述の雛形記憶部１４）と、前記雛形を端末（例えば、後述のユーザ端末２０）に対して送信すると共に、該送信した雛形に前記検査結果が入力されることにより作成された帳票を前記端末から受信し、該受信した帳票を複数の提出先の何れかに提出するために管理する情報管理部（例えば、後述の情報管理部１２）と、を備え、前記雛形記憶部は、前記複数の提出先それぞれに対応する雛形を記憶する検査情報管理装置として前記コンピュータを機能させる。
【発明の効果】
【００１６】
本発明によれば、より簡便に検査結果を管理することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態全体の基本的構成を示すブロック図である。
【図２】本発明の実施形態における検査情報管理装置の機能ブロックについて示すブロック図である。
【図３】本発明の実施形態におけるユーザ端末の機能ブロックについて示すブロック図である。
【図４Ａ】本発明の実施形態の基本的動作を示すフローチャート（１／２）である。
【図４Ｂ】本発明の実施形態の基本的動作を示すフローチャート（２／２）である。
【図５】本発明の実施形態における事業所選択時の表示例を示すイメージ図である。
【図６】本発明の実施形態における雛形選択時の表示例を示すイメージ図である。
【図７】本発明の実施形態における雛形例１への入力画面の表示例を示すイメージ図である。
【図８】本発明の実施形態における雛形例２への入力画面の表示例を示すイメージ図である。
【図９】本発明の実施形態における検査結果の入力画面の表示例を示すイメージ図である。
【図１０】本発明の実施形態における検査現場の例を示す模式図である。
【図１１】本発明の実施形態における入力中の表示例を示すイメージ図である。
【図１２】本発明の実施形態において出力される帳票の例を示すイメージ図である。
【発明を実施するための形態】
【００１８】
次に、本発明の実施形態について図面を参照して詳細に説明する。
＜実施形態全体の構成＞
まず、図１を参照して本実施形態である検査情報管理システム１全体の構成について説明をする。図１に示すように、検査情報管理システム１は、検査情報管理装置１０、複数のユーザ端末２０（図中のユーザ端末２０−１〜ユーザ端末２０−ｎに相当。ｎは任意の自然数。）、及びネットワーク３０を備える。以下の説明において、複数のユーザ端末２０の何れかを区別することなく説明する場合には、末尾の「−１」や「−ｎ」等の符号を省略して、単にユーザ端末２０と表記する。
本実施形態は、建築物に設置された防火シャッター等の設備に対して定期的に検査を行うユーザに利用される。
【００１９】
検査情報管理装置１０は、ユーザが行う検査に関する情報を管理する装置である。検査情報管理装置１０は、例えば、ユーザが検査結果を入力するための雛形や、雛形に検査結果が入力されることにより作成された帳票といった情報を管理する。検査情報管理装置１０は、ユーザが利用する事業所等に設置されることが望ましい。
【００２０】
ユーザ端末２０は、帳票を作成するための装置である。ユーザ端末２０は、検査情報管理装置１０から取得した雛形をユーザに対して提示する。なお、この雛形は、帳票作成時に通信によって検査情報管理装置１０から取得してもよいし、予め検査情報管理装置１０から取得しておき、ユーザ端末２０が記憶しておくようにしてもよい。このユーザ端末２０が記憶しておく期間は、任意に設定できるようにするとよい。
また、ユーザ端末２０は、この雛形への検査結果の入力をユーザから受け付ける。そして、ユーザ端末２０は、入力された検査結果に基づいて帳票を作成する。作成した帳票は、ユーザ端末２０から検査情報管理装置１０に対して送信され、検査情報管理装置１０において管理される。ユーザ端末２０は、ユーザが携帯可能な端末であり、ユーザが建築物に出向いて検査を行う際に携帯される。
これら検査情報管理装置１０及びユーザ端末２０の機能についての詳細は、図２及び図３を参照して後述する。
【００２１】
ネットワーク３０は、例えばインターネットや、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワークや、あるいはこれらを組み合わせたネットワークで実現される。検査情報管理装置１０とユーザ端末２０は、それぞれネットワーク３０を介して相互に通信を行う。なお、かかる通信における通信方式は、特に限定されない。
【００２２】
＜建築物の設備に対する検査＞
本実施形態は、上述したように防火シャッター等の設備に対して検査を行うユーザに利用される。次に、このような検査について説明をする。なお、本実施形態における検査は、点検や調査や保全管理といった呼び方で呼ばれる場合もある。
シャッター、ドア等の任意的検査として、管理用シャッター、防火シャッターといった区分を問わず、建築物の所有者又は管理者等と年間の検査回数等の取り決めを含めて任意契約を結び、外観及び機能検査を行うことが従来から行われていた。
【００２３】
ただし、火災等に係わる防火シャッターについては火災時において不作動が生じると人命にかかわる。そのため、これらについては任意検査とは分けて、定期的に法定の検査を行い、検査結果を報告する制度が国交省により施行された。
【００２４】
具体的には、建築物の規模及び用途等によって特定行政庁等が指定する建築物の対象となる防火シャッター等を、建築物の所有者又は管理者等が専門的知識を有する国家資格者に検査をさせる。そして、その検査結果を、特定行政庁等に報告する。この法定検査は、例えば、防火扉、防火シャッター、耐火クロススクリーン、ドレンチャーその他の水幕を形成する防火設備を対象として行われる。
なお、本制度についての詳細は、例えば以下の＜関連文献＞に記載されている。
【００２５】
＜関連文献＞
「定期調査・検査制度改正の内容（平成２８年６月１日施行）」、東京都都市整備局［ｏｎｌｉｎｅ］、［平成２９年７月２５日検索］、インターネット〈ＵＲＬ：http://www.toshiseibi.metro.tokyo.jp/kenchiku/chousa-houkoku/ch_02.html〉
【００２６】
上述したように任意検査に加えて、法定検査を行う制度も施行されたため、検査を行う事業者にとっては、検査対象となる建築物が増え取扱物件数が多くなった。そのため、事業者は、資格者を増員しなければならず、更に検査効率を上げるべく教育を行う必要もある。
そこで、例えばこのような事業者が、ユーザとして本実施形態を利用する。本実施形態では、より簡便に検査結果を管理することが可能となるので、事業者の負担を軽減することができる。
【００２７】
＜検査情報管理装置１０が備える機能ブロック＞
次に、より簡便に検査結果を管理することを実現するために、検査情報管理装置１０及びユーザ端末２０が備える機能ブロックについて図２及び図３を参照して説明をする。
図２に示すように、検査情報管理装置１０は通信部１１、情報管理部１２、帳票出力部１３、雛形記憶部１４及び帳票記憶部１５を含んで構成される。
【００２８】
通信部１１は、ネットワーク３０における通信規格に準拠した通信を行うための部分である。検査情報管理装置１０は、通信部１１を介して、各ユーザ端末２０との間で通信を行う。
【００２９】
情報管理部１２は、検査結果を入力するための雛形や、雛形に検査結果が入力されることにより作成された帳票といった情報を管理するための部分である。情報管理部１２は、ユーザ端末２０からの雛形の要求に基づいて雛形記憶部１４から雛形を読み出し、読み出した雛形を要求元のネットワーク３０に対して送信する。また、情報管理部１２は、各ユーザ端末２０から受信した帳票を帳票記憶部１５に記憶させる。また、情報管理部１２は、図示を省略した操作受付部等で、ユーザから帳票の出力要求を受け付けると、帳票出力部１３を用いて要求に対応する帳票を出力する。
【００３０】
帳票出力部１３は、帳票を出力する部分である。帳票の出力は、例えばディスプレイへの表示や、紙媒体への印刷により実現される。また、出力は、帳票をファイル形式としたデータの出力により行われてもよい。この場合、通信部１１を介して通信可能に接続されているユーザ端末２０や、ユーザ端末２０以外の他の装置が、帳票をファイル形式としたデータの出力先となってもよい。
【００３１】
雛形記憶部１４は、雛形を記憶する部分である。雛形記憶部１４は、上述した法定検査による帳票の提出を考慮して、提出先それぞれに対応する複数の雛形を記憶する。ここで、帳票の提出先とは、例えば、検査対象となった建築物が建築されている地域を管轄する自治体である。また、雛形記憶部１４は、複数の提出先それぞれに対応する雛形として、例えば、自治体それぞれで要求される書式に準拠した雛形を記憶する。
【００３２】
帳票記憶部１５は、情報管理部１２が各ユーザ端末２０から受信した帳票を記憶する部分である。なお、雛形及び帳票の具体的な例については、本実施形態の動作の説明と共に後述する。
【００３３】
＜ユーザ端末２０が備える機能ブロック＞
図３に示すようにユーザ端末２０は、通信部２１、帳票作成部２２、表示部２３、撮像部２４、操作受付部２５及び帳票記憶部２６を含んで構成される。
通信部２１は、ネットワーク３０における通信規格に準拠した通信を行うための部分である。ユーザ端末２０は、通信部２１を介して、検査情報管理装置１０との間で通信を行う。
【００３４】
帳票作成部２２は、帳票を作成するための部分である。帳票作成部２２は、操作受付部２５が受け付けたユーザからの操作により選択された雛形を取得する。
ここで、検査情報管理装置１０とユーザ端末２０とが常時通信できる環境下にある場合、帳票作成部２２は、検査情報管理装置１０の情報管理部１２に対して、ユーザに選択された雛形を要求する。そして、帳票作成部２２は、要求の応答として検査情報管理装置１０の情報管理部１２から返信されたユーザに選択された雛形を取得する。
一方で、検査情報管理装置１０とユーザ端末２０とが常時通信できる環境下ではない場合には、帳票作成部２２は、検査情報管理装置１０とユーザ端末２０とが通信できる場所にて予め検査情報管理装置１０から様々な雛形を取得して、後述の帳票記憶部２６に記憶させておく。そして、ユーザからの操作を受け付けた場合に、ユーザから選択された雛形を帳票記憶部２６から読み出すことにより取得する。なお、帳票記憶部２６の記憶容量に余裕がある場合等には、検査情報管理装置１０とユーザ端末２０とが常時通信できる環境下にある場合であっても予め雛形を取得しておくようにしてもよい。
【００３５】
そして、何れの場合であっても、帳票作成部２２は、取得したユーザの操作に対応する雛形を表示部２３に対して表示する。
更に、帳票作成部２２は、表示した雛形に対する検査結果の入力を操作受付部２５から受け取る。更に、帳票作成部２２は、撮像部２４にて撮像された検査対象の画像データを撮像部２４から受け取る。
【００３６】
そして、帳票作成部２２は、受け取った画像データや検査結果の入力の内容に基づいて帳票を作成する。また、帳票作成部２２は作成した帳票を、通信部２１を介して検査情報管理装置１０の情報管理部１２に対して送信する。
なお、帳票作成部２２は、検査情報管理装置１０とユーザ端末２０とが常時通信可能な環境にある場合に、作成中の帳票を、適宜、検査情報管理装置１０の情報管理部１２に送信して、検査情報管理装置１０の雛形記憶部１４に記憶させておいたり、読み出したりするようにしてもよい。一方で検査情報管理装置１０とユーザ端末２０とが常時通信可能な環境にない場合や帳票記憶部２６の記憶容量に余裕がある場合等には、帳票作成部２２は、作成中の帳票を、適宜、帳票記憶部２６に記憶させておいたり、読み出したりするようにしてもよい。
【００３７】
表示部２３は、例えば雛形や、雛形に対してユーザが入力を行うための各種のユーザインタフェースを表示する部分である。表示部２３は、液晶ディスプレイ等により実現される。
【００３８】
撮像部２４は、ユーザが検査対象を撮像するための部分である。撮像部２４は、撮像を行うことにより生成した画像データを帳票作成部２２に対して出力する。撮像部２４は、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ  Ｍｅｔａｌ  Ｏｘｉｄｅ  Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）センサ等を搭載したカメラにより実現される。
【００３９】
操作受付部２５は、ユーザの操作を受け付ける部分である。操作受付部２５は、自身が受け付けた操作の内容を、帳票作成部２２に対して出力する。操作受付部２５は、各種のボタンやキーボード等により実現される。なお、表示部２３及び操作受付部２５を、例えばタッチパネルにより一体的に実現するようにしてもよい。
【００４０】
帳票記憶部２６は、帳票作成部２２が検査情報管理装置１０から取得した雛形や、この雛形を用いて作成中の帳票や、完成した帳票を記憶する部分である。なお、帳票記憶部２６の記憶容量を考慮して、帳票記憶部２６が記憶しておく期間を、任意に設定できるようにしてもよい。
【００４１】
なお、上述した各機能ブロックは、本実施形態の処理に特に関連する部分のみであり、検査情報管理装置１０及びユーザ端末２０は、それ以外の様々な機能ブロックを有している。例えば、検査情報管理装置１０も操作受付部や表示部といった機能ブロックを有している。また、ユーザ端末２０は、携帯して駆動するためのバッテリ等の機能ブロックを有している。
【００４２】
以上、検査情報管理装置１０及びユーザ端末２０に含まれる機能ブロックについて説明した。
これらの機能ブロックを実現するために、検査情報管理装置１０及びユーザ端末２０のそれぞれは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）等の演算処理装置を備える。また、検査情報管理装置１０及びユーザ端末２０のそれぞれは、アプリケーションソフトウェアやＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）等の各種の制御用プログラムを格納したＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等の補助記憶装置や、演算処理装置がプログラムを実行する上で一時的に必要とされるデータを格納するためのＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）といった主記憶装置も備える。
【００４３】
そして、検査情報管理装置１０及びユーザ端末２０のそれぞれにおいて、演算処理装置が補助記憶装置からアプリケーションソフトウェアやＯＳを読み込み、読み込んだアプリケーションソフトウェアやＯＳを主記憶装置に展開させながら、これらのアプリケーションソフトウェアやＯＳに基づいた演算処理を行なう。また、この演算結果に基づいて、各装置が備える各種のハードウェアを制御する。これにより、本実施形態の機能ブロックは実現される。つまり、本実施形態は、ハードウェアとソフトウェアが協働することにより実現することができる。
【００４４】
なお、具体例として、検査情報管理装置１０は、例えばパーソナルコンピュータやサーバ装置といったハードウェアにより実現することができる。また、ユーザ端末２０は、例えばタブレット型の端末や、スマートフォン等といったハードウェアにより実現することができる。
【００４５】
＜本実施形態の動作＞
次に、図４Ａ及び図４Ｂに示すフローチャートと、図５〜図１２に示す表示例等を参照して本実施形態の動作について説明をする。本動作は、操作受付部２５がユーザから帳票を作成する旨の操作を受け付けたことを契機として開始される。なお、以下に説明する動作の前提として、例えばＩＤやパスワードを利用したユーザ認証等の処理を行うようにしてもよい。
【００４６】
ステップＳ１１にて、帳票作成部２２が帳票を“新規に”作成するか否かを判定する。この判定は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。
帳票を新規に作成する旨の操作を受け付けた場合には、ステップＳ１１においてＮｏと判定され、処理はステップＳ１２に進む。一方で、帳票を新規に作成するのではなく、既存の帳票に新たに検査結果を入力する旨の操作を受け付けた場合には、ステップＳ１１においてＮｏと判定され、処理はステップＳ１６に進む。ステップＳ１６以降の処理については後述する。
【００４７】
ステップＳ１２において、帳票作成部２２は、今回新規作成する帳票の提出先の自治体に対応する事業所を選択する。この選択は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。この事業所の選択をユーザが行うために、帳票作成部２２は、例えば図５に事業所選択用表示３１として示すように、各事業所名を一覧として表示部２３に表示する。ユーザは、この事業所選択用表示３１を参照することにより、事業所を容易に選択することが可能となる。
【００４８】
例えば、今回「東京都」の「○○区」建築物についての帳簿を新規作成する場合であれば、帳票の提出先の自治体は、東京都の○○区となるので、対応する事業所として「東京事業所」を選択する。
【００４９】
ステップＳ１３において、帳票作成部２２は、帳票を作成するための雛形を選択する。この選択は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。この事業所の選択をユーザが行うために、帳票作成部２２は、例えば図６に雛形選択用表示３２として示すように、ステップＳ１２で選択された事業所に対応する各雛形名を一覧として表示部２３に表示する。ユーザは、この雛形選択用表示３２を参照することにより、事業所を容易に選択することが可能となる。なお、雛形選択用表示３２として表示される各雛形はステップＳ１２にて選択された事業所に対応する各自治体についての雛形である。
例えば、上述の例のように、今回東京事業所を選択しているのであれば、東京都の各区や東京都の各市それぞれについての雛形の一覧が雛形選択用表示３２として表示される。
【００５０】
このように、本実施形態では、まず事業所の一覧を表示し、次に選択された事業所に対応する自治体の一覧を表示するという方法で絞り込みを行うことができるので、最初に自治体の一覧を全て表示して選択する場合に比べて、ユーザが容易に選択を行うことが可能となる。
【００５１】
また、ユーザの選択をより容易にするために、例えば図６に雛形サムネイル表示３３として示すように、仮選択中の雛形を縮小した画像を表示するようにする。そして、例えば図６に選択用ボタン３４として示すように、ユーザが選択を決定するためのボタンを表示するようにする。これにより、ユーザは、雛形選択用表示３２から雛形を仮選択し、仮選択した雛形を縮小した画像を雛形サムネイル表示３３として参照した上で、問題がないのであれば選択用ボタン３４を押下することで、雛形を間違いなく選択することが可能となる。
【００５２】
なお、ステップＳ１２において事業所選択用表示３１を表示するためのデータや、ステップＳ１３において雛形選択用表示３２や雛形サムネイル表示３３を表示するためのデータは雛形記憶部１４が記憶しており情報管理部１２にて管理されている。帳票作成部２２は通信により情報管理部１２からこれらのデータを取得して、表示を行う。なお、検査情報管理装置１０とユーザ端末２０とが常時通信可能な環境にない場合や帳票記憶部２６の記憶容量に余裕がある場合等には、帳票作成部２２は、これらのデータを予め取得しておいて帳票記憶部２６に記憶させておき、この記憶させたデータを表示するようにしてもよい。
【００５３】
ステップＳ１４において、帳票作成部２２は、ステップＳ１３において選択された雛形を取得し、帳票の作成を開始する。雛形は、上述したよう各表示用のデータと同様に雛形記憶部１４が記憶しており情報管理部１２にて管理されている。帳票作成部２２は通信により情報管理部１２から雛形を取得する。なお、帳票作成部２２の機能ブロックの説明の際に述べたように、ステップＳ１３において選択された雛形を帳票記憶部２６から取得する構成としてもよい。
ここで、上述したように本実施形態では、複数の雛形が存在するため、雛形に基づいて作成される帳票の形式も複数存在する。雛形の例として、図７に第１雛形例３５を示す。また、図８に第２雛形例３６を示す。
【００５４】
これらの雛形例は、帳票の提出先となる自治体それぞれで要求される書式に準拠したものとなっている。そのため、その書式がそれぞれ異なる。例えば、第１雛形例３５では、写真を添付する領域の数が２つであるが、第２雛形例３６では、写真を添付する領域の数が３つである。また、添付すべき写真の縦横比もそれぞれ異なっている。更に、特記事項を記載すべき箇所の行数等も異なっている。
【００５５】
一般的な技術では、検査結果を収集してから、このような自治体毎に異なる雛形に合うように写真や特記事項を入力して帳票を作成していた。この場合に、写真の縦横比や特記事項の内容が、必ずしも雛形の書式を意識したものではなかったので、帳票の作成には手間がかかっていた。また、検査結果の管理が容易ではなかった。
【００５６】
これに対して本実施形態であれば、予め提出先の自治体に対応する雛形に写真や特記事項を入力して帳票を作成することから、このような手間を省くことが可能となる。また、雛形に写真や特記事項を紐付けて管理できることから、検査結果の管理を容易とすることも可能となる。
【００５７】
続いて、これらの雛形を利用した帳票の作成について説明を続ける。
ステップＳ１５において、帳票作成部２２は、帳票の帳票名を入力する。入力は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。ユーザは、例えば、提出先の自治体の名称と、検査対象とする建築物の名称とを示す文字を帳票名として入力するための操作を行う。
【００５８】
ステップＳ１６において、帳票作成部２２は、工事名を入力する。工事名は、例えば、検査対象とする建築物の識別子、建築物の名称、及び建築物の住所等の情報である。入力は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。
【００５９】
ただし、これらの情報を、ユーザが逐一テキスト入力するのは手間となる。そこで、帳票作成部２２は、ユーザが所定の操作（例えば帳票内の「工事名」等の欄を押下する操作）を行った場合に、雛形の取得元の事業所に対応する工事名の一覧を表示部２３に表示し、ユーザがこの一覧から工事名を選択するようにしてもよい。例えば雛形の取得元の事業所が東京事業所である場合に、東京事業所にて検査対象としている建築物についての工事名の一覧を表示し、ユーザがこの一覧から工事名を選択するようにしてもよい。
【００６０】
ステップＳ１７において、帳票作成部２２は、帳票に対して検査結果の入力を行う。入力は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。帳票作成部２２は、ユーザが検査結果を入力するために、例えば図９に入力用画面３７として示すようなユーザインタフェースを表示部２３に表示する。
【００６１】
入力用画面３７には、図９に示すように、検査対象とする設備それぞれ（例えば第１扉〜第ｎ扉それぞれ）毎に検査結果の入力欄を設ける。検査項目としては、例えば図に示すように扉の寸法や、実測した閉鎖時間や、ドアの開閉や自動閉鎖装置の良否等の項目が設けられる。なお、これらの項目も提出先毎に異なっていてもよい。また、法定検査なのであれば、提出先に関わらず、法定検査において検査すべき全ての項目が設けられているようにする。
【００６２】
ここで、本実施形態では、他の検査項目の検査結果に基づいて算出できる検査項目については、雛形内に含まれている数式に基づいて帳票作成部２２が自動的に算出するようにする。
【００６３】
例えば、帳票作成部２２が、検査項目である「運動エネルギー」について、他の検査項目の検査結果に基づいて算出するようするとよい。以下では、一例として検査対象が扉である場合の運動エネルギーの算出について説明をする。
なお、この扉の運動エネルギーというのは、説明のための一例に過ぎず、例えば図１０等を参照して後述するように、検査対象がシャッターである場合には、シャッターについての運動エネルギーを算出するようにしてもよい。また、運動エネルギー以外の検査項目について算出するようにしてもよい。
ここで、扉の運動エネルギーは、以下の［数式１］に基づいて算出することができる。
【００６４】
［数式１］
運動エネルギー＝１÷２×ＭＶ２
但し、Ｍは扉の重量、Ｖは閉鎖速度であるとする。
【００６５】
ここで、扉の重量は実際に計測することは困難であるため、扉の面積１ｍ２についての重量を定めておく。例えば、扉の面積１ｍ２についての重量を４０［ｋｇ］と定めておく。なお、扉の材質等に応じて扉の面積１ｍ２についての重量を変更するようにする。そして、扉の重量は以下の［数式２］に基づいて算出することができる。
【００６６】
［数式２］
扉の重量＝扉の横幅×扉の横幅×扉の面積１ｍ２についての重量
【００６７】
図９の第１の扉の例であれば、扉の横幅であるＤＷ寸法が９００［ｍｍ］＝０．９［ｍ］であり、扉の横幅であるＤＷ寸法が１９５０［ｍｍ］＝１．９５［ｍ］であるので、［数式２］により扉の面積は、０．９×１．９５×４０＝７０．２と算出できる。つまり、図９の第１の扉の例であれば、扉の重量は、７０．２［ｋｇ］と算出できる。
また、閉鎖速度は以下の［数式３］に基づいて算出することができる。
【００６８】
［数式３］
閉鎖速度＝円周に沿った距離÷閉鎖時間
【００６９】
ここで、［数式３］における円周に沿った距離とは、戸先（吊り元と反対側の端部）の円周に沿った距離［ｍ］であって扉を開放した状態（例えば開放角度９０度の状態）から閉鎖する状態までの距離である。この円周に沿った距離は以下の［数式４］に基づいて算出することができる。
【００７０】
［数式４］
円周に沿った距離＝２×扉の横幅×円周率×扉の開放角度÷３６０
【００７１】
また、［数式３］における閉鎖時間とは、扉を開放した状態（例えば開放角度９０度の状態）から手を放して閉鎖する状態となるまでに要する時間［ｓ］（実測値）である。
【００７２】
図９の第１の扉の例であれば、扉の横幅であるＤＷ寸法が９００［ｍｍ］＝０．９［ｍ］であり、円周率を３．１４とし、扉の開放角度を９０度とした場合、［数式４］により円周に沿った距離は、２×０．９×３．１４×９０÷３６０＝１．４１３と算出できる。つまり、図９の第１の扉の例であれば、円周に沿った距離は、１．４１３［ｍ］と算出できる
【００７３】
また、図９の第１の扉の例であれば、閉鎖時間は３．０［ｓ］であるので、［数式３］により閉鎖速度は、１．４１３÷３＝０．４７１と算出できる。つまり、図９の第１の扉の例であれば、閉鎖速度は、０．４７１［ｍ／ｓ］と算出できる。
【００７４】
そして、［数式１］により、運動エネルギーは、１÷２×７０．２×０．４７１２＝７．７８６６１９１≒７．７９と算出できる。
以上より、図９の第１の扉の例であれば、運動エネルギーは、７．７９［Ｊ］と算出できる。
【００７５】
本実施形態では、雛形に上述の［数式１］〜［数式４］を含ませておく。これにより、帳票作成部２２は、ユーザが検査を行うことにより扉の寸法や閉鎖時間の項目について検査結果を入力すると、この入力された検査結果の値に基づいて扉の運動エネルギーの値を算出できる。
すなわち、本実施形態では、雛形が数式データ（例えば上述の［数式１］〜［数式４］）を含んでいることから、第１の検査項目（例えば上述の扉の横幅、扉の横幅、扉の面積１ｍ２についての重量、及び閉鎖時間）について入力された検査結果に応じた値に基づいて、第２の検査項目（例えば上述の扉の運動エネルギー）についての値を算出することが可能となる。
そして、帳票作成部２２は、扉の運動エネルギーの項目に自動で値を入力することができる。そのため、ユーザが自身で扉の運動エネルギーを算出する手間を省くことが可能となる。
【００７６】
ここで、仮に運動エネルギーが検査情報管理装置１０［Ｊ］を超える場合は、要是正として自治体に帳票で報告を行う必要がある。そこで、帳票作成部２２は、算出した運動エネルギーが検査情報管理装置１０［Ｊ］を超える場合は、検査情報管理装置１０［Ｊ］を超えたことが分かるような態様で表示部２３に表示を行う。
【００７７】
例えば、運動エネルギーの項目の文字や枠の色を赤色等の色にすることにより、検査情報管理装置１０［Ｊ］を超えたことが分かるように表示を行う。ユーザは、かかる表示を参照することにより、要是正として自治体に帳票で報告を行う必要があることを容易に把握することができる。なお、この場合に、帳票作成部２２は、表示を行うことに加えて、ユーザ端末２０が備えるスピーカ（図示省略）から警告音を出力する等の処理を行うようにしてもよい。
【００７８】
ステップＳ１８において、帳票作成部２２は、検査の結果、是正が必要であったか否かを判定する。判定は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。例えば、図７の第１雛形例３５に基づいて帳票を作成している場合に、「要是正」の欄がユーザにより押下される操作を受け付けていない場合は、ステップＳ１８においてＮｏと判定され、処理はステップＳ２２に進む。ステップＳ２２以降の処理については後述する。
一方で、「要是正」の欄がユーザにより押下される操作を受け付けた場合には、ステップＳ１８においてＹｅｓと判定され、処理はステップＳ１９に進む。
【００７９】
ステップＳ１９において、帳票作成部２２は、検査項目及び特記事項を帳票に入力する。入力は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。ここで、検査項目及び特記事項については、ユーザが任意の文章を入力するようにしてもよい。ただし、帳票の提出先となる自治体毎に、検査項目及び特記事項として入力すべき文章の文言が相違することがあるので、ユーザが任意に入力すると、その文章の文言が適切ではない場合がある。
【００８０】
例えば、スラットの片下りが発生したためにシャッターが閉まらないという事象があった場合を考える。この場合に、或る自治体では、検査項目の文章を「スラット及び座板の劣化等の状況」とし、特記事項の文章を「スラット片下り」と記載すべきであるとする。一方で、他の或る自治体では検査項目の文章を「スラット及び座板の劣化」とし、特記事項の文章を「スラットに問題有り」と記載すべきであるとする。このように、自治体毎に入力すべき文章の文言が相違することがあるので、ユーザが任意に入力すると、その文章の文言が適切ではない場合がある。
【００８１】
そこで、本実施形態では、対応する自治体にて検査項目及び特記事項として入力すべき文章の文言のテキストデータを雛形内に含ませる。そして、帳票作成部２２は、ステップＳ１９においてこのテキストデータの一覧をユーザに対して表示する。ユーザは、この一覧から事象に対応する項目を選択する。帳票作成部２２は、この選択を受け付けると選択された項目に対応するテキストデータを、検査項目の文章及び特記事項の文章として帳票の該当部分に入力する。
【００８２】
このようにすることで、本実施形態では、自治体に応じた文言が入力された帳票を容易に作成することができる。また、このようにすることで、本実施形態では、自治体に帳票を提出した場合に、文章の文言が不適切であると自治体に指摘されるような事態の発生を防止することができる。
【００８３】
ステップＳ２０において、撮像部２４は是正部位の画像を撮像する。撮像は、ユーザの操作に基づいて行われる。是正部位の例について図１０に示す。具体的には、図１０（ａ）スラット片下りによりシャッターが閉鎖しない状態を示す。また、図１０（ｂ）に障害物があることによりシャッターが閉鎖しない状態を示す。ユーザは、検査対象がこのような状況である場合に、この状況を自治体に報告するために撮像部２４により撮像を行う。
【００８４】
ステップＳ２１において、帳票作成部２２は、ステップＳ２０において撮像された画像を帳票の所定位置に配置して貼り付ける。このようにして作成中の帳票の一例を、作成中の帳票３８として図１１に示す。この作成中の帳票３８は、図７に示した第１雛形例３５に基づいて作成中の雛形である。
【００８５】
図１１に示すように、ステップＳ２１において撮像された画像は、帳票において写真を添付すべき箇所に配置して貼り付けられる。また、ステップＳ１９において入力された文章も帳票において適切な部分に入力される。なお、上述したように、雛形により添付すべき写真の縦横比は異なるが、ユーザは図１１に示すように実際に画像を貼り付けた状態を参照することができる。そのため、ユーザは、雛形に応じた縦横比とした場合に、是正部位が適切に撮像できているか否かを判断でき、必要であれば再度撮像を行うようなこともできる。
【００８６】
ステップＳ２２において、帳票作成部２２は、帳票の作成が完了したか否かを判定する。判定は、操作受付部２５が受け付けたユーザの操作の内容に基づいて行う。ユーザは、例えば帳票の作成が完了した場合に、作成した帳票を検査情報管理装置１０の情報管理部１２に対して送信（アップロード）する旨の操作を行う。操作受付部２５がこの操作を受け付けた場合に、ステップＳ２２においてＹｅｓと判定され、処理はステップＳ２３に進む。一方で、操作受付部２５がこの操作を受け付けない場合は、ステップＳ２２においてＮｏと判定され、処理はステップＳ１６に戻り、上述した処理が繰り返される。
【００８７】
ステップＳ２３において、帳票作成部２２は、作成した帳票を検査情報管理装置１０の情報管理部１２に対して送信（アップロード）する。情報管理部１２は、受信した帳票を帳票記憶部１５に記憶させる。そして、情報管理部１２は、ユーザからの操作頭囲応じて帳票出力部１３から帳票を出力する。
【００８８】
以上説明した動作により作成される帳票の一例を出力された帳票４１として図１２に示す。図１２に示すように、ステップＳ１３にて選択された雛形に、ステップＳ１９にてテキストが入力され、ステップＳ２１において画像が貼り付けられることにより完成した帳票が出力される。かかる帳票は、提出先の自治体それぞれで要求される書式に準拠したものとなっている。
【００８９】
以上説明したように、本実施形態によれば、帳票の提出先に応じた雛形を用意しておくことにより、容易な操作にて、帳票を作成することが可能となる。また、検査結果の入力時に、テキストや画像が入力された帳票を作成することができるので、事業所等でテキストや画像を管理して帳票を作成するような手間を省くことができる。そのため、本実施形態によれば、より簡便に検査結果を管理することが可能となる。
【００９０】
＜ハードウェアとソフトウェアの協働＞
なお、上述の検査情報管理システムは、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。また、上記の検査情報管理システムにより行なわれる検査情報管理方法も、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。
【００９１】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【００９２】
＜変形例＞
また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【００９３】
上述した実施形態では、建築物に設置された防火扉、防火シャッター、及び耐火クロススクリーン等を対象として法定検査を行うことを想定したが、本実施形態の適用範囲はこれに限定されない。ドレンチャーその他の水幕を形成する防火設備等の法定検査や、シャッター、ドア等の任意検査に本実施形態を適用するようにしてもよい。
【００９４】
また、上述した実施形態では、帳票の提出先が、建築物を管轄する自治体である場合を想定して説明したが、本実施形態の適用範囲はこれに限定されない。例えば、帳票の提出先が、検査を依頼した顧客であってもよい。この場合、各顧客に応じた雛形を用意することにより、提出先が自治体の場合と同様の効果を奏することが可能となる。
【符号の説明】
【００９５】
１  検査情報管理システム
１０  検査情報管理装置
１１  通信部
１２  情報管理部
１３  帳票出力部
１４  雛形記憶部
１５  帳票記憶部
２０  ユーザ端末
２１  通信部
２２  帳票作成部
２３  表示部
２４  撮像部
２５  操作受付部
２６  帳票記憶部
３０  ネットワーク
【図１】
2019032608.tif 000003
【図２】
2019032608.tif 000004
【図３】
2019032608.tif 000005
【図４Ａ】
2019032608.tif 000006
【図４Ｂ】
2019032608.tif 000007
【図５】
2019032608.tif 000008
【図６】
2019032608.tif 000009
【図７】
2019032608.tif 000010
【図８】
2019032608.tif 000011
【図９】
2019032608.tif 000012
【図１０】
2019032608.tif 000013
【図１１】
2019032608.tif 000014
【図１２】
2019032608.tif 000015