以下、図面に基づいて本発明の実施の形態を説明する。なお、本発明の情報処理装置、情報処理方法およびプログラムの一実施の形態を含む建物改修費用情報提供システムを例として説明するが、本発明はこの実施の形態に含まれるものに限定されるものではない。
1.建物改修費用情報提供システムの全体構成
図1は、本発明の情報処理装置、情報処理方法およびプログラムの一実施の形態を含む建物改修費用情報提供システムの全体構成例を示す図である。建物改修費用情報提供システムでは、サーバ1が、ハブ、ルータなどの中継機器(不図示)、ファイアウォール(不図示)、およびネットワーク2を介してクライアント端末3a,3b,および3cなど(以下、これらを特に区別せずに総称する場合「クライアント端末3」という。)と相互に通信可能に構築されている。サーバ1は、請求項の情報処理装置の一例であり、クライアント端末3は、請求項の第1の情報処理装置または第2の情報処理装置の一例である。
サーバ1は、いわゆる、SaaS(Software as a Service)と呼ばれる利用形態によってアプリケーションソフトウェア(以下、単に「アプリケーション」という。)の機能によって実現されるサービスを提供するサーバコンピュータである。建物改修費用情報提供システムでは、複数の企業または団体に共通したサービスを提供可能とする一方で、セキュリティ上の観点から、いわゆるマルチテナント型のアーキテクチャを採用し、1つのDB内に複数の企業または団体に対応するデータ領域(テナント)をそれぞれ明確に区別して管理している。
ネットワーク2は、コンピュータ間の通信を確立するための伝送路である。ネットワーク2は、一般的には、通信ケーブルによって実現され、通信プロトコルにはTCP/IP(Transmission Control Protocol/Internet Protocol)が使われる。なお、ネットワーク2の伝送路としてはケーブルだけに限定されるものではなく、それらの間の通信プロトコルが一致、または互換性のあるものであれば有線または無線の汎用回線または専用回線、有線または無線の複数のネットワーク、たとえば、LAN(Local Area Network)、WAN(Wide Area Network)、またはインターネットなどのIP(Internet Protocol)通信網、公衆電話網、携帯電話網などから構成される。
クライアント端末3は、サーバ1と通信可能な後述するWebブラウザ51(図3)が組み込まれており、本システムのサービスを提供する者との間でサービスの利用契約を締結した企業または団体に属するユーザによって利用されるクライアント・コンピュータである。クライアント端末3は、ユーザが建物の現状把握を行った結果の情報を入力するための入力画面データを、ネットワーク2を介してサーバ1から取得し、それぞれのユーザに提示することができる。また、クライアント端末3は、ユーザが現地調査を行った後に、建築物の概要、詳細、または部位別の仕様の情報などを入力するための入力画面データを、ネットワーク2を介してサーバ1から取得して、それぞれのユーザに提示することができる。
なお、本実施の形態におけるクライアント端末3は、たとえば図1に示すクライアント端末3a,3bに示すような、ノートパソコン、デスクトップパソコンなどパーソナル・コンピュータなどの他、クライアント端末3cのようなスマートフォン、携帯電話、PDA(Personal Digital Assistant)などの携帯可能な装置のいずれであってもよい。すなわち、このシステムにより提供されるサービスに対して、ネットワーク2を介してアクセスし、種々の実行の指示ができるものであればよい。
図2は、図1に示す建物改修費用情報提供システムにより実現される機能を概念的に示した図である。建物改修費用情報提供システムでは、現地において様々な調査(建物価値調査、劣化状況調査、その他の調査)を容易に行える形式による簡易な入力方法を採用することで、ユーザが情報を容易に入力することができるようにすると共に、入力された情報を各分野の把握情報としてデータベースに蓄積させて集約させている。
ここで、各分野の把握情報としては、たとえば、物件概要(床面積、スペース構成など)、建物劣化状況(外部仕上げ、内部仕上げなど)、設備状況(電気設備、建物設備など)、周辺状況(価値評価など)、エネルギー使用(光熱・水の費用など)、定期点検内容(年度別の定期点検内容など)、セキュリティ、インテリア、バリアフリー、既存不適格(消防設備など)、および耐震診断の情報などが挙げられる。
そして、分野別に把握された情報に連動して建物の実態把握報告書を作成することができる。この実態把握報告書には、クライアント端末3から入力され、データベースに蓄積されたデータから、現状の部位別、仕様、数量などが反映されると共に、現地調査における所見、撮影された写真が出力される。更に、この実態把握報告書は、概要シートと詳細シートといった、少なくとも2通りの出力方法を有し、閲覧するユーザが所望するレベルでの現地情報を呈示することができる。
また、この実態把握報告書の履歴についてもデータベースにより管理されており、過去に行われた実態把握報告書についても閲覧することが可能となっている。また、このような実態把握を行ったデータに基づく建替え、改修のシミュレーションを部位別、仕様、数量を変化させながら比較検討を行い、予算計画を立てることが容易に可能となっている。以下、これらの機能を実現するための詳細を説明する。
<各装置の構成>
図3は、図1に示すサーバ1を構成するWebサーバ10とDBサーバ20により実現される各機能およびクライアント端末3との関係を示すブロック図である。図1に示したサーバ1は、Webアプリケーションサーバ10(説明の便宜上、単に「Webサーバ10」とする。)およびデータベースサーバ20(以下、単に「DBサーバ20」とする。)により構成されている。
<Webサーバ10の構成>
Webサーバ10は、次のような機能を有するサーバコンピュータである。すなわち、Webサーバ10は、HTTP(HyperText Transfer
Protocol)、HTTPs(HTTP over Secure Socket Layer)、またはその他のプロトコルを利用して、クライアント端末3に組み込まれたWebブラウザ51に対して、HTML(HyperText Markup
Language)ファイル、オブジェクト(画像など)データの表示を提供するサービスプログラム、およびそのサービスプログラムが動作するWebサーバの機能、特定の業務サービスを提供するためのアプリケーションサーバの機能、ユーザがクライアント端末3を操作して本システムにアクセスしてきた場合に、どの企業または団体に所属するのかを判別して、対応するDB22へアクセスさせるマルチテナント制御を行う機能を有するサーバコンピュータである。
なお、ここでいう「アプリケーションサーバ」とは、システムをプレゼンテーション層、アプリケーション層、データ層の3つに分けて構成する、いわゆる3階層モデル(three tier model)において、アプリケーション層のプログラムを実行する役割を担うサーバのことである。
Webサーバ10は、上述した各機能を提供するために、通信制御部11、アプリケーション12、およびテナント制御部13を少なくとも有する。
通信制御部11は、クライアント端末3からの要求(HTTPリクエスト)を受信し、この要求に対する応答(HTTPレスポンス)を返信する。また、通信制御部11は、クライアント端末3からの要求に応じたアプリケーション12を起動させる。
アプリケーション12は、いわゆるWebアプリケーションであり、複数のテナント(つまり、複数の企業または団体など)により共通して利用される業務用のアプリケーションである。本実施の形態におけるアプリケーション12には、DBサーバ20を利用した建物に関する情報を収集するプログラム12A、建物の改修費用を算出するプログラム12Bが含まれる。プログラム12Aおよびプログラム12Bの詳細の機能については後述する。なお、アプリケーション12は、プログラム12Aおよびプログラム12B以外のプログラムを有するものであってもよい。
テナント制御部13は、テナント判定機能、データベースアクセス機能、およびAPI(Application Program Interface)機能を少なくとも有している。
テナント判定機能としてのテナント制御部13は、各テナントに属するクライアント端末3からの処理要求に応じて、DB22内のテーブルのうちいずれをアクセス先とするかを制御する。具体的には、テナント制御部13は、通信制御部11によって受信されるHTTPリクエストに含まれている情報(セッション識別情報、ユーザ名、パスワードなど)に基づいてこのHTTPリクエストの送信元のクライアント端末3が属するテナントを判定することができる。
データベースアクセス機能としてのテナント制御部13は、アプリケーション12に対してDBMS21へのアクセス用のインタフェース(関数、メソッド)を提供する。テナント制御部13は、このインタフェースを介したDBMS21へのアクセス要求に応じたSQL(Structured Query Language)文を生成し、DBサーバ20に送信する。また、テナント制御部13は、テナント判定により特定されたテナントに対応するテーブルをアクセス対象とする。
API機能としてのテナント制御部13は、クライアント端末3とのセッション(またはセッション情報)を管理するために後述するRAM33(図3)上に展開されるデータ(以下、「セッションオブジェクト」という。)に対するアクセス用のインタフェース(関数、メソッド)を提供する。なお、テナント制御部13は、テナント判定機能により特定されたテナントの識別情報をセッションオブジェクトに記録する。このテナントの識別情報は、テナント制御部13により各企業または団体が一意に識別できるように自動的に設定され、割り当てられる。テナント制御部13は、セッションオブジェクトに記録されているテナントの識別情報を参照することで、クライアント端末3から送信されてきたHTTPリクエストの送信元を毎回判定することなく、アクセス対象となるテナントを特定することができる。
<DBサーバ20の構成>
DBサーバ20について説明する。DBサーバ20は、DBMS(DataBase
Management System)21およびDB22を有するサーバコンピュータである。DBMS21は、DB22に登録されている情報を管理し、テナント制御部13から送信されるSQL文を解釈して各種処理を実行し、その処理結果をテナント制御部13へ戻すソフトウェアである。
DB22は、管理対象とされる情報を体系的に関連付けて記憶するデータベースである。DB22は、サービスを利用する企業または団体毎に対応する複数のテーブル(データ管理領域)を有している。なお、DB22は、いわゆる階層型データベースで構築することが好ましいが、リレーショナル型のデータベースであってもネットワーク型データベースで構築するようにしてもよい。
<サーバ1のハードウェア構成>
サーバ1のハードウェア構成例について説明する。図4は、図1に示すサーバ1のハードウェア構成例を示す図である。なお、図4に示したハードウェア構成は、あくまでも一例であり、これらに限定されるものではなく、サーバの構成、性能、用途、機能に応じて図4に示した構成以外のハードウェア構成となることもある。
図4に示すように、CPU(Central Processing Unit)31,ROM(Read Only Memory)32,RAM(Random Access Memory)33は、バス34により相互に接続されている。
バス34には、さらに、入出力インタフェース35が接続されている。入出力インタフェース35には、キーボード、マウス、マイクロホンなどで構成される入力部36、ディスプレイ、スピーカなどで構成される出力部37、ハードディスクや不揮発性のメモリなどで構成される記憶部38、ネットワークインタフェースなどで構成される通信部39、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリなどのリムーバブルメディア41を駆動するドライブ40が接続されている。
以上のように構成されるサーバ1(コンピュータ)では、CPU31が、たとえば、記憶部38に記憶されているOS(不図示)、プログラム12A,12B、その他の必要なプログラムなどを、入出力インタフェース35およびバス34を介して、RAM33に読み出して実行することにより処理が行われる。
CPU31が実行するプログラム12A,12Bは、たとえば、磁気ディスク(フレキシブルディスクを含む),光ディスク(CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)等)、光磁気ディスク、ブルーレイディスクもしくは半導体メモリなどで構成されるパッケージメディアであるリムーバブルメディア41に記録して、あるいは、ローカルエリアネットワーク、ネットワーク2、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。
そして、プログラム12A,12Bは、リムーバブルメディア41をドライブ40に装着することにより、入出力インタフェース35を介して、記憶部38に記憶することで、コンピュータにインストールすることができる。また、プログラム12A,12Bは、有線または無線の伝送媒体を介して、通信部39で受信し、記憶部38に記憶することで、コンピュータにインストールすることができる。その他、プログラム12A,12Bは、ROM32または記憶部38にあらかじめ記憶しておくことで、コンピュータにあらかじめインストールしておくことができる。
<主なテーブルの構成>
続いて、DBサーバ20のDB22に格納される主なテーブルについて説明する。図5は、図3に示すDB22におけるテーブルの構成例を示す図である。なお、便宜上、複数のテナントに共通するテーブルの構成例を示すが、これらのテーブルのスキーマ(データ構造)はテナント間で同一のものでもよいし、テナントによって異なるものであってもよい。
図5に示すように、DB22に格納されるテーブルには、部位情報記憶テーブル221、第1パッケージ情報記憶テーブル222、第2パッケージ情報記憶テーブル223、現状建物データ記憶テーブル224、規定データ記憶テーブル225、単価情報記憶テーブル226、および画面データ記憶テーブル227が格納されている。これらの各テーブルは、サーバ1が実行する後述する各処理の際に参照されるものである。以下、各テーブルについて説明する。
部位情報記憶テーブル221は、建物を建築するために項目分けされた部位、建物の構成材料および建物内の設備に関する情報が記録されるテーブルである。ここで、「部位」とは、建物の所定の箇所の意味ではなく、建物の構造上のユニットを建築作業の観点からまとめた単位を意味する。「部位」は、大分類、中分類、小分類のように階層をもってまとめられて記録されている。
第1パッケージ情報記憶テーブル222は、建物の仕様、部位の種類およびその数量、構成材料の種類およびその数量、ならびに設備の種類およびその数量を含む情報を少なくとも組み合わせた情報(以下、これを「第1パッケージ情報」とする。)を、入力情報の多寡によって複数のフォルダに分類して記憶しているテーブルである。
サーバ1は、第1パッケージ情報記憶テーブル222を参照することにより、ユーザが入力した情報の種類およびその数量に不足がある項目に対して適切な種類および数量情報を予測して補完することが可能となる。
第2パッケージ情報記憶テーブル223は、第1パッケージ情報に加えて、設備の種類(仕様)およびその数量を含む情報を、建物の全体もしくは一部あるいは設備の改修の種類に対応して組み合わせた情報(以下、これを「第2パッケージ情報」とする。)を、改修の種類に対応するように複数のフォルダに分類して記憶しているテーブルである。なお、改修の具体的な種類の例については後述する。
サーバ1は、第2パッケージ情報記憶テーブル223を参照することにより、ユーザが入力した情報の種類およびその数量に不足がある場合であって、ユーザにより選択された改修の種類に対して適切な種類および数量情報を予測して補完することが可能となる。
現状建物データ記憶テーブル224は、物件概要情報、物件詳細情報、階構成情報のほか、現地の情報を把握するためのプログラム12Aによって収集される種々の情報が記録されるテーブルである。具体的には、現状建物データ記憶テーブル224には、電気設備の観点からの現地状況、投資やM&A等を行う検討段階で、事前に投資対象の財政状況や法務のリスクマネジメント状況などを精査する作業(いわゆるデューデリジェンス)に用いられる周辺の現地状況、エネルギーの観点からの使用状況(建築物のエネルギーの使用量に関する指標値であるPAL(Perimeter Annual Load)またはERR(Energy Reduction Rate)など)、セキュリティの観点からの現地状況、耐震性といった観点からの現地状況(耐震性診断)など、建物の様々な観点からの情報が記録される。また、現状建物データ記憶テーブル224は、部位別の仕様情報を対応付けるロジック表が記録されている。
規定データ記憶テーブル225は、第1パッケージ情報記憶テーブル222により記憶された各情報を設計基準および/または統計にもとづき規定する規定データ(法規情報含む)を記憶している。規定データ記憶テーブル225には、オフィス、学校、病院などのような建物の種類(モデル)毎に、統計値および係数が記憶される。ここで、統計値とは、各モデルを構成する部位毎の単価の分布状況を示す情報である。
たとえば、オフィスを例にとると、統計値は、オフィスを構成する躯体、外壁、各部屋の壁・床の部材、およびそれらが複数の構成部材から成る場合には各構成部材の単価が個々のオフィスによってバラツキがある場合、そのバラツキを統計処理したときの値を意味する。また、係数とは、単価から建築コストを算出する際に参照される、モデル毎の調整用の数値である。なお、規定データ記憶テーブル225により記憶される、上述した統計値、係数の他に、構成材料あるいは設備の数または形態を計算する上で必要な設計上の計算式、そのような計算式を定める上で必要な法規上の条件式も記憶されている。たとえば、特定の耐震性を具備する建物を建てる場合には、構成材料の一例である鉄筋の数、その鉄筋の太さがどの程度必要かを計算するための計算式が規定データ記憶テーブル225に記憶されている。
単価情報記憶テーブル226は、構成材料のコストおよび設備のコストなどの各部位別のコスト情報を記憶している。なお、この単価情報記憶テーブル226に記憶されているコスト情報は、ユーザにより編集することも可能である。
画面データ記憶テーブル227は、クライアント端末3のWebブラウザ51に表示させるための各種画面を構成する画像データを記憶している。画面データ記憶テーブル227は、さらに、クライアント端末3のWebブラウザ51からの要求に応じて表示可能な1または複数種の出力画面データが記憶されている。また、過去に出力された、後述する現地把握シートの画面データが記憶されている。なお、画面データ記憶テーブル227に記憶されている出力画面データ例については後述する。
<主なプログラムにより実現される機能>
図3に示したプログラム12A,12Bにより実現される機能について説明する。図6は、図3に示すプログラム12AがCPU11によって実行されることによって実現される機能を示す図である。プログラム12Aは、建物の現状調査に関する処理全般を行うプログラムである。図6に示すように、プログラム12Aは、入力画面生成部311、情報取得部312、取得情報処理部313の各機能を実現する。
入力画面生成部311は、通信制御部11を介して取得したクライアント端末3からのHTTPリクエストに含まれる建物に関する様々な入力情報を受け付け、どのような分野の建物に関する情報を収集しようとしているのかを判定すると共に、その判定結果に基づいて画面データ記憶テーブル227を参照して、適切な入力画面データを生成して、クライアント端末3のWebブラウザ51に送信する。
情報取得部312は、入力画面生成部311が生成した入力画面データを送信し、ユーザがクライアント端末3を操作して、サーバ1に対してHTTPリクエストを送信してきた場合に、そのHTTPリクエストに含まれる建物に関する情報についての各種要求(データの登録、検索、削除など)を示す情報を取得してどのような処理を行うのか判定する。
取得情報処理部313は、情報取得部312が取得して判定された各種要求が、DB22を操作する必要がある処理の場合に、その要求に応じた処理の実行依頼をテナント制御部13に対して通知する。
図7は、図3に示すプログラム12BがCPU11によって実行されることによって実現される機能を示す図である。プログラム12Bは、ユーザから処理要求に応じてDB22を参照し、建物の改修費用の算出に必要な処理全般を行うプログラムである。
図7に示すようにプログラム12Bは、入力情報受付部321、アクセス対象判断部322、第1情報作成部323、第2情報作成部324、コスト算出部325、および出力部326の各機能を実現する。
入力情報受付部321は、通信制御部11を介して取得したHTTPリクエストに含まれる建物に関する様々な入力情報を受け付ける。入力情報受付部321が受け付けるものとしては、撤去部位の受付、撤去・仮設コストの受付、改修種類の受付、改修部位の変更指示の受付などを行う。
たとえば、入力情報受付部321は、クライアント端末3から撤去対象の部位の選択指示を受け付ける撤去部位受付手段として機能する。ここで、「撤去」は、「改修」の下位概念である。なお、入力情報受付部321は、撤去ではなく、洗浄、塗装、部品交換なども含む広義の改修対象の部位の選択指示を受け付けることもできる。
また、入力情報受付部321は、撤去対象の撤去部位の情報に基づき、撤去およびそのための仮設に要するコスト情報を受け付ける撤去・仮設コスト受付手段としても機能する。コスト情報は、クライアント端末3の他、1または複数の工事請負業者側の端末(不図示)から送信された情報をも含み得る。入力情報受付部321は、撤去対象の撤去部位の情報に限らず、改修対象の部位の情報に基づき、撤去および仮設に要するコストの情報を受け付けることもできる。
また、入力情報受付部321は、ユーザからの改修の種類を受け付ける改修種類受付手段としても機能する。
また、入力情報受付部321は、改修後の情報の内の一部の変更指示を受け付ける改修部位変更指示受付手段としても機能する。改修後の情報を検討した後、さらに改修コストの変動、改修形態の変更などが生じることがある。その場合でもさらに改修を変更できるようにしている。一部の変更指示の手法としては、改修後の情報の表示から変更したい部分を書き換える方法、別表示にて変更したい内容を入力する方法など、如何様な方法をも採用できる。
アクセス対象判断部322は、ユーザからの入力情報の多寡に応じて、第1パッケージ情報記憶テーブル222または第2パッケージ情報記憶テーブル223のいずれかに含まれるどのフォルダにアクセスするのか、またはコスト算出部325によりコスト算出を行わせるのかを判断する。
アクセス対象判断部322は、情報量の閾値を複数段階有しており、第1パッケージ情報記憶テーブル222または第2パッケージ情報記憶テーブル223のいずれかにアクセスする場合には、外部からの入力情報がどの閾値の間、あるいはどの閾値以下もしくは以上であるかを判断した上で、第1パッケージ情報記憶テーブル222または第2パッケージ情報記憶テーブル223に記憶されるフォルダを選択し、特定のフォルダからデータを読み出すことを可能にする。
たとえば、アクセス対象判断部322は、改修の種類を受け付けた場合、現状建物データ記憶テーブル224に記憶されたデータにアクセスして、現状の建物に関する情報の許容範囲内にて、第2パッケージ情報記憶テーブル223から、1または複数の第2パッケージ情報を選出する。「現状の建物に関する情報の許容範囲内にて」とは、現状の建物の全体の階数、延床面積、各階面積などの改修を行う際にどうしても制約を受ける範囲内において」という意味に解釈される。あるフォルダには、ある改修の種類に合致した改修部位のパッケージ情報が格納されており、そのパッケージの数は相当多い。しかし、そのパッケージ情報の中には、改修対象の現状の建物の構造からみて改修できないようなものも含まれている。アクセス対象判断部322は、そのような改修のあり得ないものを排除して、改修可能な1または複数のパッケージ情報のみを選出する。
また、アクセス対象判断部322は、ユーザの選択によって、改修コストの許容範囲を考慮して、その許容範囲内になるように1または複数の第2パッケージ情報を選出することもできる。
また、アクセス対象判断部322は、改修部位変更指示受付としての入力情報受付部321が改修後の情報の内の一部の変更指示を受け付けると、変更指示に対応するコストを選出する改修部位コスト選出部としても機能する。その変更指示の後の改修情報およびその変更指示の後のコストは後述するコスト算出部325により算出された費用が出力部326により出力される。
第1情報作成部323は、アクセス対象判断部322による判断に基づいて、複数のフォルダ内の特定のフォルダにアクセスすると共に、部位情報記憶テーブル221および規定データ記憶テーブル225に記憶されたデータにアクセスし、入力情報を満足する1種もしくは複数種の建物設計情報を作成する。第1情報作成部323は、各部位別の仕様を特定し、その仕様を考慮して建物の構成部材や設備の数量などを計算することができる。第1情報作成部323により作成された建物設計情報は出力部326に出力される。
第2情報作成部324は、アクセス対象判断部322による判断に基づいて、単価情報記憶テーブル226に記憶されたデータにアクセスし、建物設計情報内の構成材料および設備に関するそれぞれのコストを選出して、これらを建物設計情報に加え、新たに、改修対象の建物を新築した場合(つまり建替え)の建物設計情報を作成する。第2情報作成部324により作成された建物設計情報は出力部326に出力される。
コスト算出部325は、これから修繕しようとする建築物の構造および設備に関し、部位情報記憶テーブル221より全体的な物件概要情報等を取得し、外部仕上げなどの物件詳細情報を決定し、さらに、各階構成や部位別仕様などを計算するか決定し、建築物の建築または修繕の費用を算出する。コスト算出部325により算出された費用は出力部326へ出力される。
ここで、物件概要情報は、たとえば、物件名称、地域、主要用途、階数、敷地面積、建築面積、延床面積、主体構造、地盤状況、および全体グレードなどからなる。物件詳細情報は、高さ、建物周長、基準階、敷地余裕、堀削深さ、水位、基礎形式、エレベーターの有無または機械式駐車場の有無などの設備概要、全体工期などからなる。階構成とは、各階床面積、各階階高、各階天井高、各階構造種別、外壁長さ(平面形状)、各階用途などをいう。部位別仕様とは、外壁の仕上げ、避難用具や看板類などの有無、内部仕上げ、エレベーターや機械式駐車場の昇降機の台数や方式、電気設備、給排水設備、若しくは空調設備などの仕様や数などをいう。
物件概要情報は、物件詳細情報、階構成を示す階構成情報、または部位別仕様を示す部位別仕様情報に対して、より全体的な情報の例である。物件詳細情報は、物件概要情報に対して、より局所的な情報であり、階構成情報、または部位別仕様情報に対して、より全体的な情報の例である。階構成情報は、物件概要情報または物件詳細情報に対して、より局所的な情報であり、部位別仕様情報に対して、より全体的な情報の例である。部位別仕様情報は、物件概要情報、物件概要情報、または物件詳細情報に対して、より局所的な情報の例である。
図8は、図7に示すコスト算出部325の機能詳細を示すブロック図である。図8に示すように、コスト算出部325は、取得部325A、設計情報計算部325B、設計情報決定部325C、計算部325D、および設計情報修正部325Eを含む。
取得部325Aは、DB22より物件概要情報、物件詳細情報などを取得する。さらに、取得部325Aは、概要情報取得部325A1、詳細情報取得部325A2、階構成情報取得部325A3、および部位別仕様情報取得部325A4を含む。概要情報取得部325A1は、DB22より物件概要情報を取得する。詳細情報取得部325A2は、DB22より物件詳細情報を取得する。階構成情報取得部325A3は、DB22より階構成情報を取得する。部位別仕様情報取得部325A4は、DB22より部位別仕様情報を取得する。
設計情報計算部325Bは、物件概要情報から量により表される物件詳細情報を、物件詳細情報から量により表される階構成情報を、階構成情報などから量により表される部位別仕様情報を計算する。設計情報計算部325Bは、詳細情報計算部325B1、階構成情報計算部325B2、および部位別仕様情報計算部325B3を含む。詳細情報計算部325B1は、物件概要情報から量により表される物件詳細情報を計算する。階構成情報計算部325B2は、物件概要情報および物件詳細情報から量により表される階構成情報を計算する。部位別仕様情報計算部325B3は、物件概要情報、物件詳細情報、階構成情報などから量により表される部位別仕様情報を計算する。
設計情報決定部325Cは、現状建物データ記憶テーブル224に予め記録されているロジック表と物件概要情報などから方式で表される物件詳細情報を、ロジック表と物件概要情報と物件詳細情報などから方式で表される階構成情報を、ロジック表と物件概要情報と物件詳細情報と階構成情報などから方式で表される部位別仕様情報を決定する。ここで、方式とは、数値以外の、名称等で特定されるものを言う。
設計情報決定部325Cは、詳細情報決定部325C1、階構成情報決定部325C2、および部位別仕様情報決定部325C3を含む。
詳細情報決定部325C1は、現状建物データ記憶テーブル224に予め記録されているロジック表と物件概要情報などから方式で表される物件詳細情報を決定する。
階構成情報決定部325C2は、現状建物データ記憶テーブル224に予め記録されているロジック表と物件概要情報と物件詳細情報などから方式で表される階構成情報を決定する。
部位別仕様情報決定部325C3は、現状建物データ記憶テーブル224に予め記録されているロジック表と物件概要情報と物件詳細情報と階構成情報などから方式で表される部位別仕様情報を決定する。
計算部325Dは、取得されるか、計算されるか、または決定された物件概要情報、物件詳細情報、階構成情報、または部位別仕様情報から、単価情報記憶テーブル226に予め記録されている単価を参照して、建築物の建築または修繕の見積金額を計算する。
設計情報修正部325Eは、取得した部位別仕様情報が変更された場合、変更された項目と、変更された項目に関係する項目とを修正する。たとえば、設計情報修正部325Eは、部位別仕様情報の項目のうち熱源設備として冷凍機が選ばれていた場合、冷凍機に代わって冷温水器が選択されると、熱源設備が冷凍機から冷温水器に修正すると共に、配管設備が冷却水配管から冷温水配管に修正する。たとえば、設計情報修正部325Eは、部位別仕様情報の項目のうち熱源設備として冷温水機(たとえば、吸収式冷温水発生機)が選ばれていた場合、冷温水機に代わって冷凍機とボイラが選択されると、熱源設備が冷温水機から冷凍機とボイラに修正すると共に、配管設備が2管式の配管から冷水と温水同時使用の4管式配管に修正する。
出力部326は、第1情報作成部323により作成された建物設計情報を出力する第1建物設計情報出力手段と、改修部位およびそのコストを出力する改修部位コスト出力手段と、第2情報作成部324により作成された建物設計情報を出力する第2建物設計情報出力手段と、コスト算出部325が算出したコスト算出手段として機能する。出力部326は、画面データ記憶テーブル227に記憶されている各種画面データの中から適切な画面データを読み出して、HTMLファイルを生成し、上述した各部が出力する情報と共に、Webサーバ10のHTTPレスポンスとしてクライアント端末3に送信させる。なお、プログラム12Bは、ユーザからの処理要求が改修費用を算出するものであるが、入力情報が不足しているために、出力部326から第1情報作成部323または第2情報作成部324により作成された建物設計情報が出力された場合には、その建物設計情報をコスト算出部325へ受け渡し、改修費用の算出を行わせるものとする。
2.処理手順(情報処理方法)
続いて、クライアント端末3から処理要求(HTTPリクエスト)を受けたサーバ1が応答するまでの処理手順(つまりHTTPレスポンスを返すまで)について説明する。
図9は、クライアント端末3から処理要求を受けたサーバ1の処理手順を説明するためのフローチャートである。なお、以下の処理において、Webサーバ10は、クライアント端末3とのセッションの開設時にセッションを識別する情報(セッションID)を自動的に割り当て、そのセッションIDを特定の記憶領域(以下、「セッションオブジェクト」という。)に登録することによって管理すると共に、クライアント端末3にセッションIDを送信するものとし、クライアント端末3は、Webサーバ10から送信されてきたセッションIDをCookieなどに保持しておき、HTTPリクエストの度にWebサーバ10に対してそのセッションIDを送信するものとする。
クライアント端末3は、ユーザが操作することなどに起因してデータ要求をする際にHTTPリクエストをサーバ1へ送信する(S1)。たとえば、ユーザがクライアント端末3のWebブラウザ51に表示されているログイン画面からユーザID(ユーザを一意に識別する情報)およびパスワード情報を送信する。または、既にログインしている状態において、Webブラウザ51に表示されている画面を介して入力した情報を送信する。
Webサーバ10は、S1のHTTPリクエストに含まれるセッションIDに関連付けられているテナントIDの登録可否判定を行う(S2)。具体的には、Webサーバ10は、セッションオブジェクトにテナントIDが登録されているかを参照する。たとえば、初回ログイン時などは、セッションオブジェクトにテナントIDは登録されていない。
Webサーバ10は、セッションオブジェクトにテナントIDが登録されていないと判定した場合(S2でNO)、HTTPリクエストに含まれるユーザIDおよびパスワードの組み合わせとテナントIDとが関連付けられて登録されている管理テーブル(不図示)を検索して、特定されたテナントIDをセッションオブジェクトに登録する(S3)。
一方、Webサーバ10は、S2の登録可否判定において、セッションオブジェクトにテナントIDが既に登録されている場合(S2でYes)、HTTPリクエストの内容(たとえば、HTTPリクエストに含まれるURLなど)に応じたアプリケーション12を特定し、そのアプリケーション12を起動させる、または呼び出す(S4)。なお、HTTPリクエストの内容に応じたアプリケーション12の特定方法は、たとえば、URLとアプリケーション12との対応情報などを予め記録しておけばよい。
S4で起動、または呼び出されたアプリケーション12は、HTTPリクエストに含まれる内容に応じて特定の処理を実行し(S5)、この特定の処理を実行する過程においてDB22に対するアクセス(データの検索、登録、更新、又は削除などの操作)が生じた場合には、WEBサーバ10にアクセス要求を送信する(S6)。
S6のアクセス要求を受けたWEBサーバ10は、そのセッションIDに関連付けられているセッションオブジェクトよりテナントIDを特定すると共に、その特定したテナントIDに対応するテーブルをアクセス対象として特定する(S7)。WEBサーバ10は、S7でアクセス対象とされたテーブルに対してアプリケーション12より要求されたアクセスを実行するためのSQL文を生成し、SQL文をDBサーバ20へアクセス要求を送信する(S8)。なお、テナントIDに基づくアクセス対象とするテーブルの特定方法は、たとえば、保存されている各テナントIDと各テーブルのテーブル名との対応情報などを予め記録しておけばよい。
S8のSQL文を受け取ったDBサーバ20では、DBMS21が、DB22に対して処理要求を実行し(S9)、その処理結果(たとえば、検索結果など)をWebサーバ10へ送信する(S10)。
S10の処理結果を受け取ったWEBサーバ10は、その処理結果をアプリケーション12に通知する(S11)。S11の通知を受けたアプリケーション12は、処理結果を利用して特定の処理の続きを実行し、その処理結果を表示させるHTMLデータを生成する(S12)。そして、WEBサーバ10は、アプリケーション12によって生成されたHTMLデータをHTTPレスポンスに含めてクライアント端末3のWEBブラウザ53に送信する(S13)。クライアント端末3は、S13のHTTPレスポンスに含まれるHTMLデータをブラウザ53により表示させる(S14)。以下、Webサーバ10とクライアント端末3とは、S1〜S14の処理を繰り返すことによって、ユーザに対してクライアント端末3に所望の処理結果を表示させ、アプリケーション12の機能によるサービスを提供することができる。
3.出力画面例(実態把握)
続いて、図9の処理手順によってユーザが使用するクライアント端末3に表示される画面例について説明する。図10〜図18は、ユーザの使用するクライアント端末3のディスプレイに出力表示される画面の一例である。以下に説明する画面は、サーバ1に基本的な建物に関する情報が登録されたものについて実態把握を行う際に、クライアント端末3のディスプレイ(不図示)に表示されるものである。建物の実態把握をする際は、現地で直接建物の状況を確認しながらデータの入力をすることが好ましいため、クライアント端末3は携帯端末であることが好ましい。しかしながら、クライアント端末3は携帯できない装置または、据え置き型の装置であってもよい。なお、以下に示す画面例は建物が学校である場合の一例であるが、建物の種類によっては、これらの画面に含まれる入力項目以外の入力項目があるものとしてもよい。
図10は、ユーザがクライアント端末3で物件の概要を入力する際に出力表示される画面の一例である。図10に示す例では、建物の概要の現状把握を行うために必要な情報として「学校名」、「所在地」、「建物用途」、「敷地面積」、「構造種別」、「階数」、「建築面積(健ぺい率)」、「延床面積(容積率)」、「児童生徒数」、「保有学級数」、「竣工年月(西暦)」、「建物形状(平面形状)」、「竣工図の有無」などの入力が可能となっている。なお、この例では、「所在地」、「建物用途」、「構造種別」、「建物種別」の入力領域の右側にある逆三角のマークを選択すると、プルダウンメニュー(不図示)が表示され、複数の項目から選択できるようになっている。なお、他の図においても、特に説明しないが、プルダウンメニューによる選択ができるものについては、逆三角のマークが入力領域に表示される。
図11および図12は、ユーザがクライアント端末3で建物の現状のスペース構成の詳細を入力する際に出力表示される画面の一例である。図11および図12に示す例では、左側の領域に建物の現状のスペース構成の詳細を把握するために必要な情報として「室名」と「写真」が登録することができるようになっている。また、右側の領域に1つの教室あたりの「1室床面積」、「室数」、「床面積」、「主な現状仕様(天井の有無、照明器具の数量、空調機の台数、暖房の台数、換気扇の台数)」の入力が可能となっている。なお、この画面では、「室名」の一番左側にある項番(1〜95)のいずれかをクリックすることで、右側の領域にそのクリックした教室の詳細情報を入力することが可能となっている。また、図12の右側の領域の下端には、ユーザが入力した室数と床面積の合計が表示されるようになっている。
なお、各教室の写真をアップロードして登録するためには、「写真」の項目にある黒い四角ボタンをクリックすることで、アップロードする写真を選択する画面(不図示)が表示され、写真をアップロードして登録することが可能となっている。
図13は、ユーザがクライアント端末3で建物の現状の階構成の詳細を入力する際に出力表示される画面の一例である。図13に示す例では、建物の現状の階構成の詳細を把握するために、階ごとの「床面積(m2)」、「階高(m)」、「その他施工(バルコニー、吹き抜け)」、「外壁長さ(m)」の入力が可能となっている。なお、「施工床面積合計(m2)」および「延床面積」の合計については、階ごとの「床面積(m2)」、「階高(m)」、「その他施工(バルコニー、吹き抜け)」、「外壁長さ(m)」の入力情報に基づいて自動計算される。
図14および図15は、ユーザがクライアント端末3で建物の建築概要を入力する際に出力表示される画面の一例である。図14および図15に示す例では、建物の建築概要を把握するために必要な情報として「屋根・屋上防水の仕様」、「外壁の仕様」、「バルコニーの有無」、「屋外階段の有無」、「屋外階段、バルコニー以外の鋼製手摺等の有無」の入力が可能となっている。また、これらの項目についての修繕履歴の有無、修繕回数、直近の実施年なども入力可能となっている。さらには、「所見」の欄には、現地でユーザが調査した事項を直接記述することができる。また、「写真」の欄にある現状写真と記載されている領域をクリックすることで、現地で設備等を撮影した写真をそれぞれ入力(登録)することも可能となっている。なお、図15に示すように、「バルコニーの有無」において、バルコニー床面積は会構成のバルコニー面積の全階の合計値がデフォルトとして表示されるが、ユーザが任意で編集することも可能である。また、「屋上階段の有無」の鉄骨階段の初期値としては、図10に示した物件概要の地上階段に入力された値が自動的に表示される。
図16および図17は、ユーザがクライアント端末3で建物の電気設備の概要を入力する際に出力表示される画面の一例である。図16および図17に示す例では、建物の電気設備の概要を把握するために必要な情報として「キュービクルの修繕履歴」、「自家用発電設備の有無」、「無停電電源の有無」、「蓄電池の有無」、「幹線設備の修繕履歴」、「動力・電灯設備の修繕履歴」、「放送設備の修繕履歴」、「電話設備の修繕履歴」、「テレビ共聴設備の修繕履歴」、「インターネット設備の有無」、「自動火災報知器設備の有無」、「防排煙連動設備の有無」、「避雷針設備の有無」、「ガス漏れ警報設備の有無」、「セキュリティ設備の有無」の入力が可能となっている。また、これらの項目についての修繕履歴の有無、修繕回数、直近の実施年なども入力可能となっている。さらには、「所見」の欄には、現地でユーザが調査した事項を直接記述することができる。また、「写真」の欄にある現状写真と記載されている領域をクリックすることで、現地で設備等を撮影した写真をそれぞれ入力(登録)することも可能となっている。
図18は、ユーザがクライアント端末3で建物の給排水衛生設備の概要を入力する際に出力表示される画面の一例である。図18に示す例では、建物の給排水衛生設備の概要を把握するために必要な情報として「給水設備の仕様」、「給水ポンプ設備の仕様」、「給水管設備の修繕履歴」、「配水管設備の修繕履歴」、「排水ポンプの有無」、「ガス設備の仕様」、「消防設備の仕様」の入力が可能となっている。また、これらの項目についての修繕履歴の有無、修繕回数、直近の実施年なども入力可能となっている。さらには、「所見」の欄には、現地でユーザが調査した事項を直接記述することができる。また、「写真」の欄にある現状写真と記載されている領域をクリックすることで、現地で設備等を撮影した写真をそれぞれ入力(登録)することも可能となっている。
図19は、ユーザがクライアント端末3で建物の空調換気排煙設備の概要および昇降機設備の概要を入力する際に出力表示される画面の一例である。なお、図19では、建物の空調換気排煙設備の概要および昇降機設備の概要を便宜上一図で示したが、画面としては、同じ画面上に表示されてもよいし、別々に表示されるものであってもどちらでもよい。図19に示す例では、建物の空調換気排煙設備の概要を把握するために必要な情報として「空調設備の有無」、「暖房設備の有無」、「機械換気設備の有無」の入力が可能となっている。また、建物の昇降機設備の概要を把握するために必要な情報として「エレベーター設備の有無」、「ダムウェーター設備の有無」の入力が可能となっている。また、これらの項目についての修繕履歴の有無、修繕回数、直近の実施年なども入力可能となっている。さらには、「所見」の欄には、現地でユーザが調査した事項を直接記述することができる。また、「写真」の欄にある現状写真と記載されている領域をクリックすることで、現地で設備等を撮影した写真をそれぞれ入力(登録)することも可能となっている。
図10〜図18に示した入力画面を介してユーザが入力した情報は、その情報の分野およびその情報の細かさに応じて階層化して図5で示した現状建物データテーブル224に記録される。また、これらの情報が更新、編集された場合には履歴として記録され、管理される。
4.出力画面例(実態把握シート)
図20は、上述した図10〜図18に示した入力画面を介してユーザが入力した情報に基づいて表示される実態把握情報が出力された画面(実態把握シート)の概要の一例を示す図である。図20に示すように、ユーザが実態把握した結果の概要として、実態把握シートは、「物件概要」、「主要用途」、「敷地面積」、「建築面積」、「延床面積」、「児童生徒数・クラス数」、「保有学級数」が表示される領域と、「部位別階層」、「主な仕様・数量」、「所見」、「現状写真」が表示される領域とから構成される。
図21は、図20に示した実態把握シートをより詳細にした画面の一例を示す図である。図21に示すように、外部仕上げの更なる詳細として、「屋上」、「屋根」に区別され、特に「屋上」であれば、「PH階屋上」、「最上階屋上」、「その他屋上」といった具合に分類される。そして、防水仕様の種類、断熱材の方式、厚み、仕上げ材が何を使用しているのか、立ち上り仕様はどのようなものなのか、といった細かな部位別に調査した結果が表示される。
なお、図20および図21に示す画面はクライアント端末3のディスプレイ(不図示)に出力されるものであるが、印刷したものであってもよい。これにより、紙の方が確認しやすいユーザにとっては好ましいものとなる。また、図20および図21に示す実態把握シートのように、概要とその詳細として2通りの出力方法を採用しているが、3通り以上の階層に分けた実態把握シートをそれぞれ出力するようにしてもよい。また、実態把握シートの概要および詳細は、リスト項目にそれぞれリンクするように構成しているが、1つの画面においてタブ形式で切り替えが可能となるように構成してもよい。これにより、詳細と概要のそれぞれの画面を確認したい場合に2つの画面間を遷移させなくても、タブを切り替えるだけですぐに確認することが可能となる。また、実態把握シートの概要の項目をダブルクリックすると、その詳細が表示されるような構成を採用してもよい。これにより、ユーザがより詳細に知りたい部分のみ直接参照することが可能となる。また、実態把握シートの履歴一覧が参照できるようにリスト化してもよい。これにより、過去にどのような実態把握が行われていたのかを容易に参照することができる。
5.出力画面例(改修プラン等の作成時)
図22〜図30は、ユーザの使用するクライアント端末3のディスプレイ(不図示)に出力表示される画面の一例である。以下に説明する画面は、サーバ1が提供するサービスに基本的な建物に関する情報が登録する際に、クライアント端末3のディスプレイ(不図示)に表示されるものである。ユーザは、建物の実態把握を行った後に、改修条件を設定して複数の改修プランを作成するため、クライアント端末3は据え置き型の装置であることが好ましい。しかしながら、クライアント端末3は携帯端末などであってもよい。その場合、建物の実態把握を行う際に、クライアント端末3のディスプレイに、以下に説明するような画面を表示させて、操作するようにしてもよい。なお、以下に示す画面例は建物が学校である場合の一例であるが、建物の種類によっては、これらの画面に含まれる入力項目以外の入力項目があるものとしてもよい。
図22は、サーバ1が提供する本サービスにログインし、新たに建物(物件)を登録する際にクライアント端末3のディスプレイに出力表示される画面の一例である。図22に示す例では、図22の左側に、「ナビゲーション」ウィンドウの中に「メインメニュー」と「管理メニュー」が表示され、右側に「物件新規登録」ウィンドウが表示されている。「物件新規登録」ウィンドウでは、物件種別の選択(新築、改修)、主要用途の選択を行うことができる。ユーザは、これらを選択した後に「次へ」のボタンを押下すると更に詳細情報を入力することが可能となる。
図23は、図22に示す画面において、「次へ」のボタンを押下すると表示される「物件概要」を登録する画面の一例である。図23に示す例では、「物件概要」を登録する際に、「物件名称」、「所在地」、「建物用途」、「敷地面積」、「構造種別」、「階数」、「建築面積(健ぺい率)」、「延床面積(容積率)」、「児童生徒数」、「保有学級数」、「竣工年月(西暦)」、「建物形状(平面形状)」、「竣工図の有無」の入力が可能となっている。なお、図23に示す入力項目は、図10で示した画面内の同一名称の入力項目と対応している。ただし、図10の「学校名」は、図23の「物件名称」に対応している。ユーザは、これらを適宜入力、または選択した後に「登録」ボタンを押下すると建物の基本的な情報の登録が完了する。
図24は、建物の基本的な情報が登録された後に「物件概要」を表示させた場合の画面の一例である。図24に示す例では、図22,図23の画面により基本的な情報が登録された後に、図10〜図18に示した画面によって、細かなデータ入力がなされている。
なお、図24に示す画面例では、既に登録および現状把握がなされた物件についてのデータが各項目上で表示される。これらの数値は、図10〜図18までに示した画面において入力された情報などに基づいて表示されるが、この画面上において、各項目の編集、新規入力も可能である。図24に示す画面上部には、「現状把握」、「改修プラン」、「改修プラン(外部仕上げ)」、「改修プラン(共有設備)」、「改修プラン(内部仕上げ)」という項目が表示されている。このうち、「現状把握」を選択した場合には、入力項目として「物件概要」、「建築概要」、「電気設備概要」、「給排水衛生設備概要」、「空調換気排煙設備概要」、「昇降機設備」、「スペース構成」がリスト表示され、これらをいずれかを選択することで、後述する図25〜図27に示すような画面が表示される。なお、出力項目として「概要の出力」を選択すると、図20に示したような実態把握シートの概要が出力表示され、「部位別詳細」を選択すると、更にどの部位を指定するかを選択できる画面(不図示)を経由して、図21に示したような実態把握シートの部位別詳細が出力表示される。
図25は、図24に示される「現状把握」を選択すると表示されるリスト項目のうち、「建築概要」に関する項目を出力表示した画面の一例である。図25に示すように、建築概要として、「屋根屋上」、「外壁」の各項目の詳細情報が表示されている。詳細情報内に表示されている数値は、図14および図15で示した画面において入力された情報などに基づいて表示される。しかし、この画面上において、各項目の編集、新規入力も可能である。
図26は、図24に示される「現状把握」の項目のうち、「給排水衛生設備概要」に関する項目を出力表示した画面の一例である。図26に示すように、給排水衛生設備概要として、「給水設備」、「給水ポンプ設備」の各項目の詳細情報が表示されている。これらの数値は、図18で示した画面において入力された情報などに基づいて表示される。しかし、この画面上において、各項目の編集、新規入力も可能である。
図27は、図24に示される「現状把握」の項目のうち、「スペース構成」に関する項目を出力表示した画面の一例である。図27に示すように、スペース構成として、「分類」、「部屋種類」、「部屋名称」、「一室面積」、「室数」、「床面積」、「部屋別設備」、「画像」の各項目の詳細情報が表示されている。これらには数値が入力されていないが、図11および図12までに示した画面から遷移する詳細入力画面(不図示)において入力された情報などに基づいて表示される。しかし、この画面上において、各項目の編集、新規入力も可能である。
図28は、図27に表示した画面から改修プランを作成する際の画面遷移の一例である。図28に表示される画面の上部にある「改修プラン」を選択すると表示されるリスト項目から「改修プランの新規作成」を選択する。すると、図28の下部に示すように、改修プランの登録ウィンドウが表示され、改修プランの名前を指定して登録することができる。
図29は、図28で示した方法で複数の改修プランが登録された場合に、それらの一覧が表示されている画面の一例を示す図である。図29に示されるように、「改修プラン一覧」には、「改修プラン名」、「更新日」の項目があり、それぞれの改修プランについての更新日(なお、初期値は登録日)がわかるようになっている。また、「更新日」の右側にある欄には「決定」、「削除」のボタンがあり、それぞれの改修プランの更新を行う場合には「決定」のボタンを押下することで更新処理を行うことができ、「削除」のボタンを押下することで、「改修プラン」を削除することができる。なお、この画面内からでも「新規」ボタンを押下することにより、「改修プラン」の新規作成が可能であり、「検索」ボタンを押下することにより、既に登録されている「改修プラン」を検索することができる画面(不図示)へ遷移することができる。
図30は、図29に示される「改修案A」の項目を選択することで表示される画面の一例を示す図である。図30に示す例では、「改修プラン(外部仕上げ)」のリスト項目に含まれる「屋根・屋上」の「最上階」の改修条件を設定するための画面が表示されている。以下、改修プランの具体的な作成方法を説明する。
図30に示す表の列には、「現状 部位別仕様・数量」、「改修指定」、「改修 仕様・数量・コスト」の大きな分類の列と、これら列を更に詳細に分類した列が表示されている。「現状 部位別仕様・数量」の列は、更に「仕様」、「数量」、「使用年数」という列に区分されている。「改修指定」の列には、更に「実施の有無」、「グレード指定」という列に区分されている。「改修 仕様・数量・コスト」の列は、更に「名称/摘要」、「数量」、「単価」、「金額」、「備考」という列に区分されている。一方、図30に示す表の行には、外部仕上げの仕様として「保護防水」、「露出防水」、「シート防水」、「塗膜防水」、「シングル茸き」、「金属板茸き」、「屋根屋上雑」がそれぞれ表示されている。
「現状・部位別仕様・数量」に含まれる各列の数値が入力される領域には、図14に示した入力画面においてユーザが入力した数値が表示される。そして、ユーザが「数量」、「使用年数」の各列に入力されている値を見直し、「使用年数」の下にある「判定」ボタンを押下する。すると、「改修指定」の項目内にある「グレード指定」に、その判定結果が表示される。なお、ここでのグレードの判定は、部位別に使用年数とグレードがそれぞれ対応付けられているテーブル(不図示)がDB22に記録され、これを参照することで判定を行うようにしている。なお、ユーザは、仕様の各項目の「改修指定」の項目内にある「実施の有無」のチェックボックスにチェックを入れるか入れないかにより、部位別に改修の実施可否自体を決定することもできる。また、グレードの判定結果は、プルダウンメニューにより表示される他のグレードに変更することも可能である。
変更したグレードに設定したい場合には、判定結果が表示されている領域の下にある「変更」ボタンを押下することで、グレードの変更を確定できる。グレードが変更されると、「名称/摘要」のプルダウンメニューに表示されるリスト項目が自動的に変化する。ユーザは、「名称/摘要」のプルダウンメニューに表示されるリスト項目から所定の項目を選択し、「選択」ボタンを押下することで、改修の内容を選択することができる。なお、「現状・部位別仕様・数量」の列の上部にある「全グレードから選択」というボタンを押下すると、グレードに関係なく、すべての選択肢から改修の内容を選択することも可能である。
「改修 仕様・数量・コスト」に含まれる「数量」は、初期値として、「現状・部位別仕様・数量」に含まれる「数量」が入力されているが、ユーザの所望の値に変更することも可能である。ユーザは、改修費用を算出する場合には、画面の下部にある「更新」ボタンを押下することで、数量×単価の計算が行なわれ、この部位における改修費用が算出される。
図31は、図30に示される「改修案A」の改修プランを更新する際に「改修プラン(外部仕上げ)」、「改修プラン(共有設備)」、「改修プラン(内部仕上げ)」をそれぞれ選択することで、表示されるリスト項目画面の一例を示す図である。図30で示したような画面では、「改修プラン(外部仕上げ)」の改修費用の算出条件を設定したが、「改修プラン(共有設備)」のリスト項目に挙げられている各項目別に改修プランを細かく設定することができる。
図32は、図31に示す「改修プラン(内部仕上げ)」のリスト項目にある「改修対象部屋一覧」を選択した場合に表示される画面の一例である。
図32に示す表の列には、「改修後スペース構成」、「改修指定」の大きな分類の列と、これら列を更に詳細に分類した列が表示されている。「改修後スペース構成」の列は、更に「分類」、「部屋種類」、「部屋名称」、「一室面積」、「室数」、「床面積」という列に区分されている。「改修指定」の列には、更に「実施」、「仕様・数量」という列に区分されている。
ユーザは、図32に示す画面において、「改修指定」の列の「実施」の項目内にあるチェックボックスにチェックを入れることで、改修したい部屋を選択することができ、「仕様・数量」の項目内にある「選択」ボタンを押下することで、より詳細な改修内容の設定を行うことが可能となる。
図33は、図32で選択した教室の改修内容を指定するために表示される画面の一例である。ユーザは、選択した教室の「内装」、「閉鎖型教室の機能向上」、「照明設備」、「空調設備」などのそれぞれについて選択項目から自由に指定できるこれらを指定した結果は、改修指定の画面内にある「更新」ボタンを押下することで、設定することができる。なお、画面下部に表示されている「詳細仕様・数量」の「数量」を変更することでも改修費用を自由に変更することもできる。
図34および図35は、図5で示した単価情報記憶テーブル226に記録されている単価情報を編集する際に表示される画面例である。ユーザは、これらの画面で単価情報を自由に編集することも可能である。ユーザが編集した場合には、単価情報記憶テーブル226に記録されている単価情報は、そのユーザ独自のテーブルとして管理される。
6.改修費用算出処理例
次に、クライアント端末3からのアクセスに応じて、改修費用を算出する処理を説明する。図36〜図38は、改修費用算出処理を説明するためのフローチャートである。図36〜図38に示す各ステップの処理は、サーバ1とクライアント端末3の間において図9で説明した通信処理が行われて実現される。なお、以下の処理は、建築物の構造および設備についての省エネルギー対策に応じた改修費用を算出しようとする場合に、省エネルギーの効果を確認しながら改修費用を算出する例である。
ステップS21において、サーバ1は、クライアント端末3からのリクエストに応じてそのクライアント端末3に物件概要情報を入力するための物件概要入力画面データを送信して、表示させる。サーバ1からの物件概要入力画面のデータを受信したクライアント端末3は、物件概要入力画面を表示する。なお、ここでの物件概要入力画面は、図23に示した例とは一部が異なり、物件名称、地域、主要用途、敷地面積、建築面積、延床面積、階数の他、主体構造、地盤状況、全体グレード、PAL段階、およびERR段階のそれぞれが入力できる画面となっているものとする。
ユーザは、物件概要入力画面を表示しているクライアント端末3を操作することで、物件名称、地域、主要用途、敷地面積、建築面積、延床面積、階数の他、主体構造、地盤状況、全体グレード、PAL段階、およびERR段階の値を入力したり、メニューから選択することが可能となる。クライアント端末3は、ユーザが物件概要情報の登録を指示するためのボタンをクリックすると、ネットワーク2を介して、入力された物件概要情報が含まれるデータをサーバ1宛に送信する。サーバ1は、ネットワークインタフェースよりなる通信部39を制御して、クライアント端末3から送信されてきた物件概要情報が含まれるデータを受信する。
ステップS22において、入力情報受付部321を介して受け付けられた物件概要情報の多岐に応じて、アクセス対象判断部322により第1情報作成部323、第2情報作成部324、またはコスト算出部325へアクセスする。なお、この処理においてはコスト算出部325にアクセスすることとする。コスト算出部325に含まれる取得部325Aは、S21で送信された物件概要情報を取得する。コスト算出部325では、取得部325Aに含まれる概要情報取得部325A1が、供給されたデータから物件概要情報を抽出することで取得する。
ステップS23において、設計情報計算部325Bに含まれる詳細情報計算部325B1が、S22で取得した物件概要情報から、計算可能な、高さ、建物周長、基準階面積などの物件詳細情報を計算する。たとえば、詳細情報計算部325B1は、物件概要情報の階数から、予め定めた階高を乗算することで、高さを計算する。たとえば、詳細情報計算部325B1は、物件概要情報の延床面積を階数で割り算して、1階当たりの床面積を計算し、この床面積から予め定めた比率の長辺と短辺とを計算して、建物周長を求める。
ステップS24において、設計情報決定部325Cに含まれる詳細情報決定部325C1が、現状建物データ記憶テーブル224に記録されたロジック表(不図示)を参照して、物件概要情報の全体グレード、PAL段階、およびERR段階から、耐震性や外部仕上げなどの物件詳細情報を決定する。
なお、ここでいうロジック表には、PAL段階のそれぞれについて、形状、開口率、窓種類、壁、および屋根の仕様や値が対応付けられ、ERR段階のそれぞれについて、空調、照明、換気、給湯、およびエレベーターの仕様や値が予め対応付けられているものとする。なお、ロジック表には、全体グレードに対応付けて仕様や値が対応付けられているが、サーバ1は、PAL段階およびERR段階の仕様や値が優先されるように決定する。
ステップS25において、設計情報決定部325Cに含まれる詳細情報決定部325C1が、ロジック表を参照して、物件概要情報の全体グレード、PAL段階、およびERR段階から、物件詳細入力画面、階構成入力画面、または部位別仕様入力画面において選択可能なメニュー項目を決定する。
ステップS26において、設計情報計算部325Bに含まれる階構成情報計算部325B2が、ステップS22の手続きで取得した物件概要情報並びにステップS23およびステップS24の手続きで計算または決定した物件詳細情報から、計算可能な、各階の、面積、階高、天井高、外壁長さなどの階構成情報を計算する。
たとえば、階構成情報計算部325B2は、ステップS23の手続きで計算した基準階天井高を、そのまま各階の天井高とする。
ステップS27において、設計情報決定部325Cに含まれる階構成情報決定部325C2は、ステップS22の手続きで取得した物件概要情報並びにステップS23およびステップS24の手続きで計算または決定した物件詳細情報から、構造などの階構成情報を決定する。たとえば、階構成情報決定部325C2は、物件概要情報の主体構造をそのまま各階の構造に決定する。
ステップS28において、設計情報計算部325Bに含まれる部位別仕様情報計算部325B3が、ステップS22の手続きで取得した情報から、外部仕上げおよび内部仕上げなどの部位別仕様情報を計算する。たとえば、部位別仕様情報計算部325B3は、PAL段階から定まる開口率と、各階の周長と階高から、窓の面積を計算する。
また、たとえば、部位別仕様情報計算部325B3は、物件概要情報の主要用途が自社ビルである場合、ビルマル(ビル用マルチ空調)パッケージを採用するとき、α×延床面積(m2)×0.7×1000(αは後述する係数)からビルマルの能力(kw)を計算する。部位別仕様情報計算部325B3は、物件概要情報の主要用途がテナントビルである場合、ビルマルパッケージを採用し、テナント面積が不明であるとき、α×延床面積×0.7×0.7/1000からビルマルの能力(kw)を計算し、ビルマルパッケージを採用し、テナント面積が不明であるとき、α×(延床面積−テナント面積(m2))×0.7/1000からビルマルの能力(kw)を計算する。なお、この場合、αは、氷蓄熱槽を採用する場合、200とされ、外気処理エアコンを採用する場合、170とされ、全熱交換機を採用する場合、185とされる。
ステップS29において、設計情報決定部325Cに含まれる部位別仕様情報決定部325C3が、ロジック表を参照して、物件概要情報の全体グレード、PAL段階、およびERR段階、並びに計算または決定した物件詳細情報および階構成情報から、外部仕上げおよび内部仕上げなどの部位別仕様情報を決定する。たとえば、部位別仕様情報決定部325C3は、PAL段階から、熱反射ガラスまたは複層ガラスなどの窓の種類を決定する。
ステップS30において、計算部325Dは、物件概要情報、物件詳細情報、および部位別仕様情報で表される、建築物の構造と設備の数や仕様に、単価情報記憶テーブル226に予め記録されている、それぞれの数や仕様に応じた単価を乗じることにより、改修費用を算出する。
ステップS31において、サーバ1は、クライアント端末3からのリクエストが、図22に示した画面に配置されている「物件一覧」を選択し、その後に表示された物件の詳細入力画面の表示を指示するためのボタン(不図示)がクリックされることによりなされたものであるか否かにより、物件詳細入力画面を表示させるか否かを判定する。
ステップS31において、物件詳細入力画面を表示させると判定された場合、手続きはステップS32に進む。
ステップS32において、サーバ1は、クライアント端末3に、物件詳細情報を入力するための物件詳細入力画面を表示させる。すなわちサーバ1は、物件詳細入力画面のデータを生成し、ネットワークインタフェースよりなる通信部39を制御して、ネットワーク2を介して、物件詳細入力画面のデータをリクエストしてきたクライアント端末3宛に送信させる。サーバ1からの物件詳細入力画面のデータを受信したクライアント端末3は、物件詳細入力画面を表示する。
ユーザは、物件詳細入力画面を表示しているクライアント端末3を操作することで、建物高さ、建物外周、基準階面積、基準階天井高、敷地余裕の有無、N値で表される地盤状況、昇降機エレベーターの有無、またはエスカレーターの有無などの値を入力したり、ユーザがメニューから選択することが可能となる。クライアント端末3は、ユーザが物件詳細情報の送信を指示するためのボタンをクリックすると、ネットワーク2を介して、入力された物件詳細情報が含まれるデータをサーバ1宛に送信する。
ステップS33において、コスト算出部325に含まれる取得部325Aは、物件詳細情報を取得する。サーバ1は、クライアント端末3から送信されてきた物件詳細情報が含まれるデータを受信する。サーバ1は、受信した物件詳細情報が含まれるデータをコスト算出部325に供給する。コスト算出部325に含まれる取得部325Aの詳細情報取得部325A2は、供給されたデータから、物件詳細情報を抽出することで取得する。
ステップS34において、設計情報計算部325Bに含まれる階構成情報計算部325B2は、物件概要情報と、ステップS33の手続きで取得した物件詳細情報およびこれまでに計算または決定した物件詳細情報(取得した項目を除く)から、計算可能な、各階の、面積、階高、天井高、外壁長さなどの階構成情報を計算する。
ステップS35において、設計情報決定部325Cに含まれる階構成情報決定部325C2は、物件概要情報と、ステップS33の手続きで取得した物件詳細情報およびこれまでに計算または決定した物件詳細情報(取得した項目を除く)から、構造などの階構成情報を決定する。
ステップS36において、設計情報計算部325Bに含まれる部位別仕様情報計算部325B3は、取得した物件詳細情報、並びに計算または決定した階構成情報から、部位別仕様情報を計算する。
ステップS37において、設計情報決定部325Cに含まれる部位別仕様情報決定部325C3は、ロジック表を参照して、取得した物件詳細情報、並びに計算または決定した階構成情報から、部位別仕様情報を決定する。
ステップS38において、計算部325Dは、現在までに求められた物件概要情報、物件詳細情報、および部位別仕様情報で表される、建築物の構造と設備の数や仕様に、単価情報記憶テーブル226に予め記憶されているそれぞれの数や仕様に応じた単価を乗じることにより、改修費用を再計算することで、改修費用を修正し、手続きはステップS31に戻る。
ステップS31において、物件詳細入力画面を表示させないと判定された場合、手続きはステップS39に進む。
ステップS39において、サーバ1は、クライアント端末3からのリクエストが、階構成入力画面の表示を指示するためのボタン(不図示)がクリックされることによりなされたものであるか否かにより、階構成入力画面を表示させるか否かを判定する。ステップS39において、階構成入力画面を表示させると判定された場合、手続きはステップS40に進む。
ステップS40において、サーバ1は、クライアント端末3に、階構成情報を入力するための階構成入力画面を表示させる。サーバ1は、ネットワーク2を介して、階構成入力画面のデータをリクエストしてきたクライアント端末3宛に送信する。サーバ1からの階構成入力画面のデータを受信したクライアント端末3は、階構成入力画面を表示する。
ユーザは、階構成入力画面を表示しているクライアント端末3を操作することで、各階毎の、面積、階高、天井高、構造、外壁長さ、割合などの値を入力したり、メニューから選択することが可能となる。クライアント端末3は、ユーザが階構成情報の送信を指示するためのボタンをクリックすると、ネットワーク2を介して、入力された階構成情報が含まれるデータをサーバ1宛に送信する。
ステップS41において、コスト算出部325に含まれる取得部325Aは、物件詳細情報を取得する。サーバ1は、クライアント端末3から送信されてきた階構成情報が含まれるデータを受信する。サーバ1は、受信した階構成情報が含まれるデータをコスト算出部325に供給する。コスト算出部325に含まれる取得部325Aの階構成情報取得部325A3は、供給されたデータから、階構成情報を抽出することで取得する。
ステップS42において、設計情報計算部325Bに含まれる部位別仕様情報計算部325B3は、取得した、または決定した物件詳細情報および階構成情報から、部位別仕様情報を計算する。
ステップS43において、設計情報決定部325Cに含まれる部位別仕様情報決定部325C3は、ロジック表を参照して、取得した、または決定した物件詳細情報および階構成情報から、部位別仕様情報を決定する。
ステップS44において、計算部325Dは、現在までに求められた物件概要情報、物件詳細情報、および部位別仕様情報で表される、建築物の構造と設備の数や仕様に、単価情報記憶テーブル226に予め記録されている、それぞれの数や仕様に応じた単価を乗じることにより、改修費用を再計算することで、改修費用を修正し、手続きはステップS31に戻る。
一方、ステップS39において、階構成入力画面を表示させないと判定された場合、手続きはステップS45に進み、サーバ1は、クライアント端末3からのリクエストが、物件概要入力画面に配置されている、部位別仕様入力画面の表示を指示するためのボタン(不図示)がクリックされることによりなされたものであるか否かにより、部位別仕様入力画面を表示させるか否かを判定する。
ステップS45において、部位別仕様入力画面を表示させると判定された場合、手続きはステップS46に進む。
ステップS46において、サーバ1は、クライアント端末3に、部位別仕様情報の各項目を選択または項目の値を入力するための部位別仕様入力画面を表示させる。すなわちサーバ1は、部位別仕様入力画面のデータを生成し、供給する。サーバ1は、ネットワークインタフェースよりなる通信部39を制御して、ネットワーク2を介して、部位別仕様入力画面のデータをリクエストしてきたクライアント端末3宛に送信させる。サーバ1からの部位別仕様入力画面のデータを受信したクライアント端末3は、部位別仕様入力画面を表示する。
なお、部位別仕様入力画面の例については後述する。ユーザは、部位別仕様入力画面を表示しているクライアント端末3を操作することで、部位別仕様情報の各項目の値を入力したり、各項目をメニューから選択したりすることが可能となる。クライアント端末3は、ユーザが送信を指示するためのボタン(不図示)をクリックすると、ネットワーク2を介して、部位別仕様情報の選択された項目および入力された項目の値が含まれるデータをサーバ1宛に送信する。
ステップS47において、コスト算出部325に含まれる取得部325Aは、部位別仕様情報の選択された項目および入力された項目の値を取得する。サーバ1は、ネットワークインタフェースよりなる通信部39を制御して、クライアント端末3から送信されてきたデータを受信させる。サーバ1は、受信したデータをコスト算出部325に供給する。コスト算出部325において、取得部325Aに含まれる部位別仕様情報取得部325A4は、供給されたデータから、部位別仕様情報の選択された項目および入力された項目の値を抽出することで、取得する。
ステップS48において、コスト算出部325に含まれる設計情報修正部325Eは、取得された項目または項目の値が変更されたか否かを判定する。ステップS48において、取得された項目または項目の値が変更されたと判定された場合、手続きはステップS49に進み、設計情報修正部325Eは、部位別仕様情報の変更された項目と変更された項目に関係する項目とを修正する。たとえば、それまで、空調機として、冷水のみの空調機が選ばれていた場合に、冷温水の空調機が選択されると、配管設備は、冷却水配管から冷温水配管に修正される。
ステップS50において、計算部325Dは、現在までに求められた物件概要情報、物件詳細情報、および部位別仕様情報で表される、建築物の構造と設備の数や仕様に、単価情報記憶テーブル226に予め記録されている、それぞれの数や仕様に応じた単価を乗じることにより、改修費用を再計算することで、改修費用を修正し、手続きはステップS31に戻る。
ステップS48において、取得された項目または項目の値が変更されていないと判定された場合、部位別仕様情報の項目を修正する必要はないので、手続きはステップS31に戻る。
ステップS45において、部位別仕様入力画面を表示させないと判定された場合、仕様が決定されたので、手続きはステップS51に進み、コスト算出部325は、見積を表示させる。すなわち、コスト算出部325は、計算した改修費用データを通信制御部11に供給する。サーバ1は、ネットワークインタフェースよりなる通信部39を制御して、ネットワーク2を介して、データをクライアント端末3宛に送信させる。サーバ1からの改修費用を含むデータを受信したクライアント端末3は、その改修費用を含むデータを表示する。
ステップS52において、ユーザが改修費用を含むデータの印刷を希望する場合には、コスト算出部325はWEBサーバ10に印刷用のデータの生成を指示する。印刷用の改修費用を含むデータの生成を指示されたWebサーバ10は、ネットワーク2を介して、印刷用の改修費用を含むデータをクライアント端末3宛に送信させる。サーバ1からの印刷用の改修費用を含むデータを受信したクライアント端末3は、見積を印刷して、見積書を生成する処理は終了する(エンド)。
ここで、サーバ1が行う改修費用の算出過程について関係図を用いて説明する。
図39は、物件概要情報、PAL段階またはERR段階、物件詳細情報、階構成情報、および部位別仕様情報の関係を示す図である。なお、図39において、PAL段階またはERR段階を物件概要情報に含めて示すものとし、PAL段階またはERR段階は、ユーザにより予め設定されているものとして説明する。
まず、サーバ1は、図39に示されるように、物件名称、地域、主要用途、階数、敷地面積、建築面積、延床面積、主体構造、地盤状況、および全体グレードからなる物件概要情報と共に、PAL段階またはERR段階を取得する。
ここで、主要用途は、いわゆる自社ビルかテナントビルかを示す。階数は、地上、地下、および屋上階の階数を示す。また、主体構造は、鉄骨構造(S造)、鉄筋コンクリート構造(RC造)、または鉄筋鉄骨コンクリート構造(SRC造)などを示す。地盤状況は、良質、やや軟弱、または軟弱などを示す。全体グレードは、最もグレードの高いA〜最もグレードの低いEのいずれかを示す。PAL段階またはERR段階は、1〜5のいずれかとされる。
サーバ1は、物件概要情報と共に、PAL段階またはERR段階をDB22から取得すると、取得した物件概要情報、およびPAL段階またはERR段階から、物件詳細情報、階構成情報、および部位別仕様情報を計算し、また決定し、取得した物件概要情報、およびPAL段階またはERR段階、並びに計算し、または決定した物件詳細情報、階構成情報、および部位別仕様情報から、改修費用を計算する。
ここで、詳細な改修費用を算出する場合には、サーバ1は、ユーザによって入力された物件詳細情報、階構成情報、または法規に関する法規情報(規定データ)を取得する。たとえば、サーバ1は、図39に示されるように、物件詳細情報のうち、ユーザによって入力された、高さ、建物周長、基準階、敷地余裕、堀削深さ、水位、基礎形式、設備概要、または全体工期の値または方式を取得する。この場合、建物周長は、長辺および短辺の長さを示し、基準階は、面積および天井高を示す。また、設備概要は、エレベーターの有無または機械式駐車場の有無を示す。
さらに、たとえば、サーバ1は、図39に示されるように、階構成情報のうちの、ユーザによって入力された、各階床面積、各階階高、各階天井高、各階構造種別、外壁長さ(平面形状)、各階用途の値または方式を取得する。さらにまた、たとえば、サーバ1は、図39に示されるように、法規情報のうちの、ユーザによって入力された、スプリンクラーや消火栓などの消火設備の有無などを取得する。
サーバ1は、物件詳細情報、階構成情報、または法規情報を取得すると、取得した物件詳細情報、階構成情報、または法規情報に合わせて、物件詳細情報および階構成情報を修正すると共に、部位別仕様情報を修正し、物件概要情報、およびPAL段階またはERR段階、並びに修正した物件詳細情報、階構成情報、および部位別仕様情報から、改修費用を算出する。
さらに、より詳細な改修費用を算出する場合には、サーバ1は、部位別仕様情報を取得する。たとえば、サーバ1は、図39に示されるように、部位別仕様情報のうち、ユーザによって入力された、外壁の仕上げに関し、タイル、石、若しくはアルミパネルなどの仕上材、または、PC(Precast Concrete)板、押出成形板、ALC(Autoclaved
Lightweight Concrete)板などの中間材の方式を取得する。たとえば、サーバ1は、図39に示されるように、部位別仕様情報のうち、ユーザによって入力された、避難梯子や避難ハッチなどの避難器具、館名板や案内板などの看板類、タラップや屋上手すりなどの屋上周りの値または方式を取得する。さらに、たとえば、サーバ1は、図39に示されるように、部位別仕様情報のうち、電気設備、給排水設備、または空調設備についての値または方式を取得する。
サーバ1は、部位別仕様情報を取得すると、部位別仕様情報を修正し、物件概要情報、およびPAL段階またはERR段階、並びに物件詳細情報、階構成情報、および修正した部位別仕様情報から、改修費用を算出する。
<改修費用の具体的な算出例>
図40は、部位別に仕様情報を修正した場合の改修費用の一例を示す図である。図40に示されるように、地域、主要用途、階数、敷地面積、建築面積、延床面積、主体構造、および階数が同じであったとしても、グレード、PAL段階、またはERR段階によって、外部仕上げや電気設備、給排水衛生設備、空調換気排煙設備が変わるので、改修費用が変わることになる。たとえば、地域、主要用途、階数、敷地面積、建築面積、延床面積、主体構造、および階数が同じで、外部仕上げ、内部仕上げ、電気設備、衛生設備、空調設備がBグレードとされて、PAL段階が4とされて、空調、照明、換気、給湯、エレベーターに関するERR段階が4とされると、改修費用は、793,447,581円となるが、外部仕上げ、内部仕上げ、電気設備、衛生設備、空調設備がCグレードとされて、PAL段階が2とされて、空調、照明、換気、給湯、エレベーターに関するERR段階が2とされると、改修費用は、734,034,990円となる。この場合、躯体、外部仕上げ、内部仕上げ、設備、諸経費について、それぞれの延床面積当たりの費用がわかるので、全体のコストの構成比も比較することができる。
このように、たとえば、建物の現状把握を行った上で、省エネルギー対策の程度を考慮し、グレードに応じて簡単に建物の部位別に修正し、改修費用を求めることができる。つまり、簡単に建物の改修費用を求めることができるので、異なる省エネルギー対策の程度と費用とを突き合わせて確認することができ、より投資効果の高い建物の改修費用を得ることができる。
7.実施の形態の作用
本実施の形態に係るサーバ1(情報処理装置)、サーバ1が実行する情報処理方法およびサーバ1にインストールされているプログラムは、クライアント端末3(第1の情報処理装置または第2の情報処理装置)へ所定の入力画面データを送信して建物に関する情報の入力を受け付け(受付手段および受付けステップ)、その受け付けた建物に関する情報の分野およびその情報の細かさに応じて階層化して記憶部38に記憶させ(記憶処理手段および記憶処理ステップ)、記憶部38に記憶された情報から建物の実態把握に関する情報(所定の情報)を抽出して、抽出された情報の概要と詳細の少なくとも2通りの画面データを生成可能であり(画面データ生成手段および画面データ生成ステップ)、生成される画面データの履歴を記憶し(履歴情報記憶手段および履歴情報記憶ステップ)、記憶されている画面データに含まれる建物の実態把握に関する情報に基づいて建物の建て替え、または改修を行う際の費用の算出を行い(費用算出手段および費用算出ステップ)、生成された画面データ、履歴情報として記憶された画面データ、算出された費用データのいずれかをクライアント端末3へ送信する(送信手段および送信ステップ)ようにしている。
このため、ユーザは、建物に関する情報を収集する手段がまったくない場合であっても、建物の実態把握を行うことが可能となる。また、過去の実態把握について、サーバ1が提供するサービスを利用している場合には履歴として記録されているため、それらを参照することで、いつ、どの分野に関する現地調査が行われたのかを容易に知ることができる。すなわち、現状の建物に関する様々な情報を容易に収集して建物の実態を把握することが可能である。また、サーバ1に収集された情報の概要と詳細について少なくとも2通りの画面データを生成できるため、ユーザが所望するレベルで容易に収集した情報を閲覧することが可能である。さらに、ユーザは、サーバ1に収集された情報に基づいて改修費用を算出することができるため、現地調査に基づいた精度の高い改修費用を容易に算出できるという効果がある。
また、上述したサーバ1(情報処理装置)、サーバ1が実行する情報処理方法およびサーバ1にインストールされているプログラムの構成に加えて、クライアント端末3からのデータ送信要求が建物の部位別に改修条件を変更させた費用の算出を要求するものである場合、記憶部38に記憶されている建物の実態把握に関する情報から送信要求に応じた建物の部位別の情報を抽出し、その抽出した情報を建物の改修の条件として反映させて費用の算出を行い、算出された費用データを他の情報処理装置へ送信している。このため、現地調査に基づく精度の高い情報を前提とした上で、更に部位別に改修費用条件を設定して算出できることから、より細かい条件設定に基づく改修費用を算出できるという効果がある。
なお、上述したいずれかのサーバ1(情報処理装置)、サーバ1が実行する情報処理方法およびサーバ1にインストールされているプログラムの構成に加えて、上述した図で示した入力画面例(所定の入力画面)において建物に関する情報の入力を受け付ける際に、択一的に選択できる項目を複数表示させると共に、複数の項目の選択の組み合わせに応じて選択支援情報を入力画面に表示させるようにしてもよい。これにより、たとえばクライアント端末3を操作するユーザが調査対象となる建物に関する技術分野に精通していない場合であっても、どのような情報を入力すればよいか、どのような場所を確認すればよいかを示す画像、メッセージなどの選択支援情報を表示させることで、現地調査を行っているユーザが仮に技術的な事項がわからずに、まったく入力することができないといった事態を回避することができることから、収集される情報の質を、ある一定のレベルに保つことができるという効果がある。
さらに、このサーバ1(情報処理装置)、サーバ1が実行する情報処理方法およびサーバ1にインストールされているプログラムは、クライアント端末3を操作するユーザが収集しようとする建物に関する情報のカテゴリ種別およびそのユーザの専門性を判定する判定手段(不図示)を設け、判定手段の判定結果に応じて、クライアント端末3へ送信する入力画面データを変更するようにしてもよい。たとえば、サーバ1は、クライアント端末3を操作するユーザの技術的な知識レベル、経験年数、専門分野が十分な情報収集能力があると推測または判定した場合には、より詳細なデータを入力できる画面を表示させるようにする。一方で、十分な情報収集能力がないユーザであると推測、または判定した場合には、選択式でデータを入力できる画面および支援情報、またはヘルプファイルの表示など、なるべく情報収集を行いやすいユーザインタフェースを提供するようにする。これにより、熟練した専門家のようなユーザの場合には、より詳細な情報を提供してもらうと共に、初心者のようなユーザの場合には、必要最低限度の情報収集をしてもらうようにすることが可能となり、サーバ1により提供されるサービスをユーザのレベルに適した利用形態を提供することが可能になるという効果がある。なお、このような利用形態とする場合には、ユーザがサーバにログインする際に、技術的な知識レベル、経験年数、専門分野に関する情報を予めサーバ1側で保持しておき、これらを参照して判定するようにすればよい。なお、ユーザ単位ではなく、企業単位で判定を行うようにしてもよい。
また、上述したいずれかのサーバ1(情報処理装置)、サーバ1が実行する情報処理方法およびサーバ1にインストールされているプログラムの構成に加えて、クライアント端末3から受付けた建物に関する情報を他のシステムで利用可能となるデータ形式で出力することが可能なデータ連携手段(不図示)を備えるようにしてもよい。ここで、他のシステムとは、たとえば、ある自治体における財務管理システム、施設管理システム、資産管理システムなどを含むシステムなどである。
次に、上述した他のシステムと本実施例との関係の一例について他の実施の形態を示して説明する。この実施の形態では、その構成例の図示は省略するが、図1に示した構成に加え、サーバ等で構成される他のシステム(システム400)が、ネットワーク2を介してサーバ1、クライアント端末3と相互に通信可能に構成されている。
図41は、このシステム400とサーバ1が提供するサービスとが連携する場合の概念図である。システム400は、財務管理システム401、施設管理システム402および資産管理システム403を有している。サーバ1は、実態把握報告書として出力する書類(あるいはデータ表示画面)、システム400が有している各システムにて出力される書類(あるいは各システムが出力するデータ表示画面)に対応したデータの階層定義(データ構造)をDB22に有している。たとえば、システム400は、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408を出力する。公共施設一覧406、土地・建物概要書407、資産台帳詳細版408は、この順番でより詳細な情報を含んでいる。サーバ1のDB22は、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408のそれぞれの出力項目に応じた階層定義をDB22に有している。そのため、たとえば、ある自治体が管理している施設に関する詳細な情報がサーバ1に対して入力されて更新されると、その詳細な情報を記録すべきデータ階層はもとより、関連する上位のデータ階層、または下位のデータ階層に定義された項目についても、更新された情報に基づいて自動的に再計算される。そして、サーバ1のデータ連携手段により各システムに出力される書類(あるいはデータ表示画面)の項目に応じた情報が出力されることで、各システムにおいて情報が更新されるようになっている。すなわち、結果としてサーバ1が出力する実態把握報告書、施設管理システム402が出力する公共施設一覧406および土地建物概要書407、資産管理システム403が出力する資産台帳405および資産台帳詳細版408のそれぞれのデータとの関係は連動したものとなる。以下、各項目について具体的に説明する。
財務管理システム401は、ある自治体のいわゆる決算書404(たとえば賃借対照表、損益計算書など)及びその付属書類を作成し、出力するためのシステムである。決算書404は、後述する資産管理システム403が有する資産台帳405(固定資産台帳)に含まれる情報に基づいて固定資産に関する項目が作成される。この固定資産に関する項目の詳細は、決算書404の付属書類に記載される。決算書404の付属書類としては、たとえば、固定資産台帳兼減価償却計算表がある。この固定資産台帳兼減価償却計算表に記載される情報は、資産台帳405で管理されている情報に基づいて作成される。
図42は、図41に示す決算書404の付属書類として作成される固定資産台帳兼減価償却計算表に含まれる項目の一例である。図42に示すように、固定資産台帳兼減価償却計算表には、事業資産、インフラ資産などに区分ごとに前年度残高、本年度増加額、本年度減少額、本年度減価償却費、評価差額(本年度発生分)、本年度末残高などの項目が存在する。なお、これらの各項目には、後述する資産管理システム403が有する資産台帳405に記載される資産毎に合致する項目が予め定義されたルールに基づいて自動的に決定されて、計算し、その計算結果が入力されるようになっている。
施設管理システム402は、地方自治法および自治体が策定している公有財産規則などに基づいて自治体が保有する公共施設に関する情報を管理し、管理するこれらの情報を出力するためのシステムである。施設管理システム402は、公共施設一覧406と土地・建物概要書407とを作成し、これらに記載される情報を出力することができる。
図43は、図41に示す施設管理システム402が公共施設一覧表406として出力する情報の一例である。公共施設一覧表406は、自治体が管理する公共施設に関する情報が含まれる。図43に示すように、公共施設一覧表406には、たとえば、地区・団地名、所在地、施設名、所管課、用途種別、配置形態、棟名、建築年度、敷地面積、建築面積、延床面積、各面積、構造、階数などの施設の概要情報と、耐震診断の要否、耐震補強の要否に関する建物の性能情報と、土地の保有者、建物の保有者などの保有形態に関する情報が施設毎にまとめられている。
図44は、図41に示す施設管理システム402が土地・建物概要書407として出力する情報の一例である。土地・建物概要書407は、公共施設一覧表406にて管理される各公共施設の情報より、更に詳細な情報が含まれている。図44に示すように、土地・建物概要書407には、基礎情報、性能情報(棟別)、コスト情報およびその他という4つの項目により分類されている。
基礎情報は、概要、土地、建物という3つの項目により分類されている。概要という項目には、建物名、所在地、所管課、行政財産・普通財産の別、設置目的、配置形態、棟数、棟名、用途種別(施設名称)、運営主体(施設別)などの情報が含まれる。土地という項目には、都市計画区域の別、用途地域、その他の地域地区等、敷地面積、取得価格、現存価格、借地の状況などの土地に関する情報が含まれる。建物という項目には、建築年月、建築面積、延床面積、構造、階数、取得価格、現存価格、借地の状況、減価償却費、補助制度活用の有無などの情報が含まれる。
性能情報(棟別)は、劣化の状況、大規模改修履歴、耐震診断(要否、実施状況など)、耐震補強(要否、実施状況など)、バリアフリー化の対応状況、アスベスト対策、建物合計の余剰床(有無・客数・面積、活用状況など)、建物合計の環境負荷(敷地内の緑化、CO2排出量など)などの情報が含まれる。
コスト情報は、光熱費、業務委託費、各所修繕費などの総額の金額情報が含まれる。
その他には、受電方式、図面等の有無(竣工図、増築した際の図面、確認通知書、許可通知書、検査済証など)、備考などの情報が含まれる。
このように、施設管理システム402では、主に建物、土地に関する施設の情報についての管理がなされている。サーバ1は、公共施設一覧406、土地・建物概要書407用に定義されている階層定義(またはデータ階層構造)を有しており、これらの階層に記録されている情報を参照することにより、公共施設一覧406、土地・建物概要書407用に定義されている各項目に合致する情報を特定し、施設管理システム402が有する情報を更新することができる。これにより、階層定義の単位でどの階層定義に記憶された情報を出力すればよいのかが容易に把握可能であり、サーバ1とシステム400に含まれる施設管理システム402と間のデータ連動が容易に可能となる。
なお、公共施設一覧表406および土地・建物概要書407に含まれていない各公共施設の建築の部位別の詳細な情報、建物の部位別の評価価値などを表す金額情報などは、資産管理システム403によって管理されている。
資産管理システム403は、自治体が保有する固定資産に関する情報を管理し、固定資産に関する情報を出力するためのシステムである。資産管理システム403は、決算書404または付属書類に記載される固定資産に関する情報を有している。たとえば、資産管理システム403では、土地・建物・機械などの固定資産や繰延資産を固定資産の種類別に分類した上で、取得日・取得価額などの明細情報、減価償却が必要な資産に関しては償却額情報などを有している。また、資産管理システム403では、これらの情報を算出するための、固定資産についての概要情報および詳細情報、工事履歴情報なども有している。また、資産管理システム403では、シミュレーションにより算出した将来的なコスト予測結果情報、または将来的なコスト予測をシミュレーションするための情報を有している。上述したような情報を管理している資産管理システム403は、資産台帳405と、資産台帳詳細版408とを有している。
図45は、図41に示す資産管理システム403が有する資産台帳405に含まれる項目の一例である。図45に示すように、資産台帳405には、勘定科目(4)、件名(5)などの基本的な情報、取得額・取得額相当額(11)、増減異動前簿価(13)、減価償却額(28)の金額情報などの総数38項目の管理項目が含まれている。
図45に示す資産台帳405は、資産台帳詳細版408に記録されている情報に基づいて作成される。すなわち、これらの各項目には、後述する資産台帳詳細版408に記載される資産毎に合致する項目が予め定義されたルールに基づいて自動的に決定されて、計算し、その計算結果が入力される。
資産台帳詳細版408は、各施設の概要情報を有している施設台帳409と、施設台帳409よりさらに詳細な情報を有する資産詳細台帳410を有している。なお、施設台帳409は、施設管理システム402の公共施設一覧406と同様の情報を管理しているため、詳細な説明を省略する。なお、図41に示す施設台帳409と資産詳細台帳410とは、分離している構成としているが、単一の台帳として構成されてもよい。
資産台帳詳細版408では、建物の概要情報に加えて、建物、設備の部位別の詳細情報、竣工時、修繕時、改修時などにおける部位別の仕様、数量、評価情報などが管理されている。また、資産台帳詳細版408では、シミュレーションにより算出した将来的なコスト予測結果情報、または将来的なコスト予測をシミュレーションするための情報なども管理されている。
また、資産台帳詳細版408の詳細項目は、サーバ1のデータ連携手段から提供される建物の実態把握によって収集された建物の詳細情報に基づいて更新される。サーバ1のデータ連携手段は、資産詳細台詳細版408用に定義されている詳細項目に対応する階層定義(またはデータ階層構造)を有しており、これらを参照することにより、資産詳細台詳細版408用に定義されている詳細項目に合致する情報を出力することができる。
図46は、サーバ1のDB22に定義されている階層定義と図41に示す資産台帳詳細版408に定義されている階層定義との関係を説明するための図である。サーバ1のDB22には、たとえば図46の上段と下段に示すように、ある部位についての情報として2つの階層定義がなされている。そして、サーバ1へ入力されたデータに基づいて、適切な階層定義の項目が選択、あるいは計算され、部位の項目別の仕様情報、数量情報が記憶されるようになっている。さらに、サーバ1のDB22に記憶されている部位の項目別の仕様情報、数量情報と単価情報から部位別の金額情報が算出されるようになっている。図46に示す例では、上段に示す階層定義が、資産台帳詳細版408で管理される項目に対応する項目であり、下段に示す階層定義が、資産台帳詳細版408で管理される項目を更に詳細に定義したものである。なお、下段に示す階層定義がサーバ1に入力される詳細項目に対応したものであってもよい。
具体的には、図46の上段で示されるように、資産台帳詳細版408用の階層定義におおける外壁・開口部という部位に関する項目では、東面は仕上げと開口部という2つの仕様項目にまとめられて定義されるが、図46の下段に示されるように、更に下の階層における外壁・開口部という部位には、東面、北面、西面、南面という4つの仕様項目が定義されている。そして、これらの上下の階層定義領域の間では、数値が自動的に計算されて、まとめられるようになっている。
たとえば、図46の下段に示す4つの仕様項目において、外壁アルミスパンドレル張り厚2.0カラーという仕様の総金額情報は、8,122,500円、アルミサッシ(水平連続窓.Low-eガラス)の総金額情報は、73,319,644円など、それぞれの部位の4つの仕様毎にそれぞれの総金額情報が求められている。一方、図46の上段の2つの仕様項目では、1つ目の仕様である外壁アルミスパンドレルは下段の外壁アルミスパンドレル張り厚2.0カラーという仕様の総金額情報(8,122,500円)がそのまま記憶されているが、残りの3つの仕様については、アルミサッシF1X+片引き水平連続窓という項目で、すべて加算された総金額情報が記憶されている。
なお、図46の上段、下段に示した階層定義(またはデータ構造)およびこれらの階層定義に含まれる詳細項目は、もちろん一例にすぎず、自治体によって定義された資産台帳詳細版408の項目に応じて、サーバ1のDB22の階層定義について適宜、設計変更することができる。また、自治体によって定義された資産台帳詳細版408での項目に応じた階層定義をサーバ1側で予め設定しておき、自治体側から要求された階層定義情報を参照して対応する階層定義を求めるようにしてもよい。このように、サーバ1側で保持する建物の部位別の階層定義と資産台帳詳細版408の詳細項目の定義との関係は、同一あるいは対応する階層定義(データ構造)を有している。そのため、階層定義の単位でどの階層定義に記憶された情報を出力すればよいのかが容易に把握可能であり、サーバ1とシステム400に含まれる資産管理システム403と間のデータ連動が容易に可能となる。
図47および図48は、図41に示した資産台帳詳細版408から出力されるデータの一例である。図47に示すデータは、資産管理システム403の資産台帳詳細版408を管理するデータベース(不図示)がDB22の現状建物データ記憶テーブル224と同一あるいは対応する階層定義(またはデータ階層構造)に記憶されている建物の概要情報をサーバ1のデータ連携手段を介して取り込むことによって更新し、出力したものある。
たとえば、図47に示す建物概要という項目内の「建物名称」、「竣工年数」、「用途」、「構造」、「階数(地上、地下、PH)」、「建築面積」、「延床面積」という各列に示されるデータ(仕様、数量)、または、周辺配置図に示される画像や敷地内配置図に示される画像を示すデータは、DB22の現状建物データ記憶テーブル224の同一あるいは対応する階層定義(またはデータ階層構造)に含まれる物件概要情報などをサーバ1のデータ連携手段から資産台帳詳細版408を管理するデータベース(不図示)が取り込むことによって更新し、出力したものである。
また、同様に、図48に示すデータは、資産管理システム403の資産台帳詳細版408を管理するデータベース(不図示)がDB22の現状建物データ記憶テーブル224と同一あるいは対応する階層定義(またはデータ階層構造)に記憶されている情報を取り込むことによって更新し、出力したものである。
たとえば、図48に示す修繕・改修履歴という項目の新築時の建物の部位別に示される仕様・数量などの特記事項、および部位別の価格データ、大規模改修1という項目の部位別に示される仕様・数量などの特記事項、撤去、修繕、あるいは改修金額に示されるデータ、並びに今後30年にかかるコスト予測に示される費用データ、年間熱負荷などの項目に関するレーダーチャートなどは、DB22の現状建物データ記憶テーブル224の同一あるいは対応する階層定義(またはデータ階層構造)に含まれる建物の詳細情報、過去あるいは現在において算出された各部位別の見積金額データ、評価結果データなどをサーバ1のデータ連携手段から資産台帳詳細版408を管理するデータベース(不図示)が取り込むことによって更新し、出力したものである。なお、図47および図48に示す例は既存のデータを更新して出力したものとして説明したが、既存のデータが資産台帳詳細版408を管理するデータベースに記憶されていない場合には、そのまま取り込んだデータを出力するようにしてもよい。
このように、資産管理システム403の資産台帳詳細版408を管理するデータベース(不図示)は、サーバ1のデータ連携手段から取得したデータに基づいて資産台帳詳細版408の同一または対応する階層定義に記憶している既存のデータを容易に更新することができる。また、サーバ1のデータ連携手段は、資産管理システム403の資産台帳詳細版408を管理するデータベース(不図示)に定義される同一または対応する階層に記憶されているデータを出力するだけで、資産管理システム403との間で容易にデータ連携が図れる。
以上で説明したように、サーバ1が提供するサービスにより建物の実態把握が行われて収集されたデータを、システム400が有する資産台帳405、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408の階層定義(またはデータ階層構造)と同一または対応するように情報を記憶させ、それをシステム400へ出力するようにしているため、結果としてサーバ1が出力する実態把握報告書、施設管理システム402が出力する公共施設一覧406および土地建物概要書407、資産管理システム403が出力する資産台帳405および資産台帳詳細版408のそれぞれの関係は連動したものとなる。これにより、たとえば、図44で示した土地・建物概要書407の基礎情報の建物の取得価格に記載される総金額情報は、図48で示した資産台帳詳細版408の新築時の合計金額情報と同一の数字が記載されることになる(ただし、図44で示した例の施設と図48で示した例の施設とは異なるため、図面上では一致していない)。また、建物について改修が行なわれると、その改修に関しての部位別の仕様・数量などの詳細情報および改修後の現在価格が資産台帳詳細版408に記載されると共に、土地・建物概要書407の基礎情報の建物の現存価格(評価年度)欄に、資産台帳詳細版408に記載されている改修後の合計の現在価格と同一の価格が記載されることになる。
なお、サーバ1へデータの入力を行わないで、自治体側で施設管理システム402が管理している情報について直接更新する必要がある場合には、直接更新した情報を施設管理システム402からサーバ1側へ取り入れて、施設管理システム403へ更新した情報を出力することで、これらの間のデータ整合性を保つようにしてもよい。これにより、資産管理を行う際の土地・建物概要書407として出力させるため情報を管理しているデータベース(不図示)と資産台帳405と連動している資産台帳詳細版408に含まれる情報を管理しているデータベース(不図示)との間でデータの整合性をとる仕組みが仮になくても、サーバ1のデータ連携手段を経由して情報共有を図り、データの整合性を取ることが可能となる。以下、このような実施の形態について説明する。
図49は、図41に示す施設管理システム402が記憶している情報と、サーバ1が記憶している施設の階層定義別に記憶している情報と、図41に示す資産管理システム403の資産詳細台帳詳細版408が記憶している情報との関係を概念的に説明するための図である。
サーバ1は、施設管理システム402の土地・建物概要書407に記載される情報については、施設の階層定義別にDB22に記憶している情報から施設別実態把握シートとして容易に出力することが可能である。そして、サーバ1に入力された施設に関する情報(たとえば、竣工時の既存建物データ、毎年の定期健診データ、毎年の工事履歴など)に関しては、施設の階層定義別に記憶するべき領域に記憶されている情報を更新し、データ連携手段を介して土地・建物概要書407に記載される情報を更新することができる。更に、サーバ1は、施設管理システム402側で土地・建物概要書407に記載される情報の更新があった場合(たとえば光熱水道等に関する情報などの毎年更新する必要があるもの)については、資産管理システム402側から更新された情報を受け取り、施設の階層定義別にDB22に記憶している情報を更新すると共に、これらの履歴管理を行う。そして、サーバ1のデータ連携手段が図41で示したような資産管理システム403の資産台帳詳細版408を管理しているデータベース(不図示)へ更新情報及び履歴管理情報を渡す。これにより、土地・建物概要書407として出力されるデータ、サーバ1が記録、履歴管理をしているデータ、資産台帳詳細版408に記憶されているデータの3つすべてが連動したものとなる。すなわち、サーバ1は、建物の実態把握をして得た情報に加えて、土地・建物概要書407で管理され、更新される情報も取り入れた状態で、資産台帳405と連動する資産台帳詳細版408のデータ詳細を更新することができる。これにより、図49に示すように、サーバ1側で施設管理システム402におけるデータの更新履歴などが管理されることになるので、資産台帳405と連動する資産台帳詳細版408のデータ詳細は、施設管理システム402の毎年更新される情報を加味した建物の概要情報、部位別の仕様、数量、コストについてどのように遷移しているのかが容易に把握可能となる。
また、図49で説明した概念におけるサーバ1が保有する施設の階層定義は、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408の順番でより詳細な情報ウを含むように定義されている。そのため、たとえば、施設に関する詳細な情報がサーバ1に対して入力されて更新すると、その詳細な情報そのものが定義されている階層はもとより、関連する上位の階層、または下位の階層に定義された項目についても再計算されて、自動的に更新されるようになっている。
ところで、自治体の会計は、従来、いわゆる単式簿記で現金主義の会計を行っていたが、平成20年度の決算分より企業会計的な手法(いわゆる複式簿記および発生主義)による財務書類の作成(固定資産台帳)も同時に求められるようになった。しかしながら、自治体は公有財産台帳という主に固定資産を管理するための独自の台帳を保有していたため、必ずしも固定資産台帳として記載されるべき情報を十分に保有していない。たとえば、公有財産台帳では、固定資産台帳上では資産計上すべき資産(たとえば、下水道管、道路、河川など)が管理されていない場合がある。また、公有財産台帳では、既に管理されている固定資産であっても建物と土地の金額情報の区分把握がなされていない場合がある。更には、公有財産台帳では、過去の金額情報をさかのぼって検証できない場合などもある。そのため、従来の公有財産台帳のデータをそのまま流用して固定資産台帳を作成するには、不足している建物の区分別の金額情報や、改修履歴情報などの詳細情報を修正、または追加する必要がある。この点、本実施例のサーバ1が収集して保有する情報は、既に述べたとおり、これらの情報を専門家でなくとも容易に収集し、かつ算出し、履歴管理を行うことが可能な構成を有している。また、自治体が保有する複数のシステムとそれぞれとの連動を図ることにより、それぞれの目的に合致した項目を更新し、出力させるようにすることができる構成を有している。また、自治体が保有するそれぞれのシステムにおいて独自に入力された情報(毎年更新が必要な情報など)についてもサーバ1を介してデータの整合性を図ることにより、各システム内の独自の更新処理によって生じる不整合も容易に回避できる構成を有している。
8.その他の変形例
以上、本発明の実施の形態を説明したが、上述した例以外にも種々の変形が可能である。たとえば、サーバ1は、アプリケーションサーバとしての機能をWebサーバ10とは物理的に分離させて構築する、すなわち、アプリケーションサーバを別のコンピュータとして構築するようにしてもよい。これにより、機能単位による負荷分散、冗長化などを実現することも可能となる。また、サーバ1が提供するサービスを利用する利用者数、使用頻度から、Webサーバ10の処理能力が不足する場合は、不図示のロードバランサを設けて複数のWebサーバ10を構築して通信処理の負荷分散を図るようにしてもよい。あるいは、1つのWebサーバ10の通信処理能力で十分である場合は、DBサーバ20と1つの装置として構築するようにしてもよい。これにより、物理的な装置分のコストを低減することが可能となる。
また、SaaSの利用形態で他の企業、団体、または自治体に対してサービスを提供できるように、いわゆるマルチテナント型のアーキテクチャを採用したが、企業、団体、または自治体毎にDB22を別々に設けるような、いわゆるシングルテナント型のアーキテクチャ、またはデータセンターを構築して、サービスを提供する、いわゆる従来のASP(Application Service Provider)を採用して構築するようにしてもよい。これにより、利用する企業、団体、または自治体のセキュリティポリシーなどにより、他者のデータとは物理的に区分されて管理されることを望む場合には、好ましい利用形態となる。さらに、サービスの提供者および利用者が同一の企業、団体、または自治体に属するような場合(たとえば、自社グループ内で利用するためにシステムを構築してそれを自社グループ内のみで利用する場合)には、シングルテナント型のアーキテクチャを採用する場合にも、企業内の情報が外部に漏れないため、好ましい利用形態となる。
また、サーバ1が提供するサービスにより実態把握が行われて収集されたデータは、施設管理を行う際の土地・建物概要書407として出力させるためのデータベース、または資産台帳詳細版408を記憶しているデータベースなどに、即時に反映させるために出力するようにしていたが、この他にも、土地・建物概要書407として出力させるためのデータベース、資産台帳詳細版408を記憶しているデータベースをDB22に取り込むと共に、これらのデータベースを利用するプログラム、またはアプリケーションをサーバ1にインストールして、これらのすべてのサービスをユーザに対して提供できるようにしてもよい。これにより、サーバ1が有する機能と財務管理システム401、施設管理システム402、および資産管理システム403などを有するシステム400の機能が一つのシステムとなって構成される。すなわち、サーバ1がシステム400の機能を有するようにしてもよい。この場合、サーバ1からシステム400へ必要なデータを出力して連携させる必要がなくなる。
また、図41〜図49を参照して説明した実施の形態において、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408は、この順番でより詳細な情報を含んでいるとしたが、必ずしもこの順番でより詳細な情報を含んでいなくてもよい。すなわち、サーバ1のDB22は、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408の順番でより詳細な情報を含むような階層定義をDB22に有していなくてもよい。また、図41〜図49を参照して説明した実施の形態において、資産台帳405、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408は全てが連動するものとして説明したが、資産台帳405、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408のいずれかが連動するものとしてもよいし、資産台帳405、公共施設一覧406、土地・建物概要書407、資産台帳詳細版408のそれぞれの一部分(たとえば、建物の概要情報のみなど)が連動するように構築してもよい。これにより、各システムが保有する既存のデータを段階的に更新して、徐々に連動させるようにすることも可能である。
また、本発明の実施の形態において、クライアント端末3が建物の現地把握を行った結果として入力される情報をサーバ1に対して送信し、改修費用の算出などをサーバ1に要求するという利用形態を示したが、この他にも、これらの処理は、物理的に異なる場所に存在するクライアント端末3、あるいは使用される時間帯が異なるクライアント端末3において、それぞれが行なわれるような利用形態であってもよい。たとえば、建物の基本情報を入力するのが、デスクトップパソコンであるクライアント端末3bを操作して行う。そして、その建物の現地調査を行い、調査結果として入力される情報をサーバ1に送信する装置としては、ユーザが直接現地に赴いたときに所持している携帯端末であるクライアント端末3c(請求項の第1の情報処理装置)を操作して行う。更に、現地調査をして得られた情報に基づく現地把握シートの閲覧、出力、改修費用の算出などを行う際には、クライアント端末3bとは物理的に異なる場所にあるノートパソコンなどのクライアント端末3b(請求項の第2の情報処理装置)を操作して利用するようにしてもよい。すなわち、特定の装置で全ての処理を行う必要はなく、サーバ1により提供されるサービスを容易に利用することが可能となる。
また、図41〜図49を参照して説明した実施の形態において、サーバ1が提供するサービスとシステム400とが連携する点について述べたが、このような連携部分を建物の実態把握を行う際(情報を入力する際)の入力項目にまで適用するようにしてもよい。たとえば、資産台帳詳細版408に定義される項目単位でデータ入力画面を生成し、必要となるデータ項目について入力させるようにしてもよい。これにより自治体の資産台帳詳細版408に必要な項目を網羅して情報を容易に収集することが可能となる。また、資産台帳詳細版408に定義される項目すべてが含まれた入力画面を生成しない場合であっても、自治体の資産台帳詳細版408に必要な項目については強調表示(他の項目とは異なる色を着色、または囲い線をつける、入力が必須である旨のメッセージをポップアップ表示させる、入力がない場合にはエラー画面を表示させるなど)を行うようにしてもよい。これにより、自治体で管理するための建物の詳細情報の入力支援を行うことが可能となる。
また、本発明の実施の形態において説明した一連の処理の一部または全部は、ハードウェアにより実行することもできるし、ソフトウェアにより実行するようにしてもよい。また、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたときなどの必要なタイミングで処理が行われるプログラムであってもよい。