JP2020057425A - 建築物の管理システム及び管理方法 - Google Patents

Abstract

【課題】建物の新規施工時から取り壊しまでの、関連するすべての情報を一元的に管理できる仕組みを提供する。【解決手段】管理システムにおいて、建築物に関する情報を管理する統合管理システムであって、建築物または建築物が有する設備に関する情報であるモノ関連情報と、人に関する情報であるヒト関連情報と、工事内容に関する情報であるコト関連情報と、を対応付けたトランザクション情報を記憶する記憶手段と、複数の作業を含む工事案件について生じた事象を記憶手段に記憶するデータ登録手段と、を有する。データ登録手段は、所定の建築物に対する工事案件において生じた複数の事象に関する情報を、当該所定の建築物に関するモノ関連情報と当該工事案件に関するヒト関連情報と当該工事案件に関するコト関連情報として対応付けて、複数の事象が生じた時系列に基づいて記憶手段のトランザクション情報に記憶する。【選択図】図２２

Description

本発明は、建築物の管理システム及び管理方法に関する。

本技術分野の背景技術として、特開２００９−１２４６８５号公報（特許文献１）がある。この公報には、「施主、監理者及び施工業者を含めた総合的な建築物の施工管理システムを提供すること。施主側端末装置、監理側端末装置、施工業者側端末装置及びシステム管理サーバ１０を備えた施工管理システム。システム管理サーバ１０は、情報を処理するためのコンピュータ部１２と、情報を記録するためのサーバ部１４とを備え、サーバ部１４は、施工工事に関する情報を登録する記録データベース５６と、施工工事の承認情報を登録する承認記録データベース５８とを有し、施工工事段階において、施主側端末装置、監理者側端末装置及び施工業者側端末装置からの個別承認信号を受信すると、承認判定手段は、施主、監理者及び施工業者の三者が承認したと判定して合意承認信号を生成し、記録データベース５６の承認された施工工事情報が承認記録データベース５８に登録される」と記載されている。

また、特開２００２−２５９７７０号公報（特許文献２）がある。この公報には、「建築資材メーカー、運送会社、配送先、建築業者等を通信ネットワークを介して接続して、資材の注文及び配送手配をオンライン上で可能とする、資材注文配送システムを提供する。建築物を構築するために使用される資材に関する受発注業務を行う管理サーバと、前記管理サーバに資材の注文情報を送信する注文端末と、前記資材を提供する業者側に設けられ、前記管理サーバを介して注文情報を受信する業者サーバと、コンビニエンスストア、又は宅配業者の中継所の何れかである、前記資材の配送先に設けられた配送先端末と、がネットワークを介して接続されている資材注文配送システムの、前記管理サーバの確認手段が、注文端末からの注文情報の受信に基づいて、資材の提供が可能か否かを前記業者サーバに確認し、通知手段が、前記確認手段による資材提供の可否結果を、注文端末に通知すると、確認手段によって前記資材の提供が可能であると判断された場合に、配送情報送信手段が当該資材の配送情報を前記配送先端末に送信する」と記載されている。

特開２００９−１２４６８５号公報 特開２００２−２５９７７０号公報

前記特許文献１には、建築物の施工管理システムが記載されている。しかし、特許文献１の施工管理システムでは、建築物の新規施工の工程しか管理することができず、その後の建築物の取り壊しまでの工事履歴については何ら考慮されていない。
特許文献２には、資材メーカーと建築業者等との間の資材注文配送システムが記載されている。しかし、注文・配送に関するプロセスしか考慮されておらず、建築物の新規施工時から取り壊しまでの一貫した工事履歴や発注履歴を管理できるものではない。

そこで、本発明は、建物の新規施工時から取り壊しまでの、関連するすべての情報を一元的に管理できる仕組みを提供する。例えば、一連の工事案件に関して、どこの、どんな設備が、どうなっていて、何をすべきで、誰が、誰に、どんなことを、いつ、いくらで依頼したか、というような情報を時系列で蓄積するデータベースを備え、管理会社、工務店、資材問屋、入居者、仲介業者、施工管理者、デベロッパー等からの書き込みを受け付けて蓄積する仕組みを提供する。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、建築物に関する情報を管理する管理サーバであって、建築物または建築物が有する設備に関する情報であるモノ関連情報と、人に関する情報であるヒト関連情報と、工事内容に関する情報であるコト関連情報と、を対応付けたトランザクション情報を記憶する記憶手段と、複数の作業を含む工事案件について生じた事象を前記記憶手段に記憶するデータ登録手段と、を有し、前記データ登録手段は、所定の建築物に対する工事案件において生じた複数の事象に関する情報を、当該所定の建築物に関する前記モノ関連情報と当該工事案件に関する前記ヒト関連情報と当該工事案件に関する前記コト関連情報として対応付けて、前記複数の事象が生じた時系列に基づいて前記記憶手段の前記トランザクション情報に記憶することを特徴とする。

本発明によれば、建物の新規施工時から取り壊しまでの、関連するすべての情報を一元的に管理することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

全体の管理システム１の構成図の例である。 統合管理システム１０１のハードウェア構成の例である。 施工会社端末１０２のハードウェア構成の例である。 入居者端末１０５のハードウェア構成の例である。 ヒト関連マスタ情報５００の例である。 モノ関連マスタ情報６００の例である。 コト関連マスタ情報７００の例である。 フェーズ関連マスタ情報８００の例である。 メインＤＢ２２０に記憶されるトランザクション情報９００の例である。 メインＤＢ２２０に記憶されるトランザクション情報９００(続き)の例である。 トランザクション情報９００に記憶された情報の一部を抜粋した例である。 フェーズ開始終了条件情報１２００の例である。 フェーズ進行可否判定情報１３００の例である。 データ登録処理フロー１４００の例である。 フェーズ更新処理フロー１５００の例である。 案件起票時の入力画面１６００の例である。 新たな作業項目を追加する入力画面１７００の例である。 現場調査を実施する際の画面１８００の例である。 担当者が現場調査を実施する際の画面遷移の例である。 工事実施時の入力画面の例である。 Ｗｅｂブラウザで案件一覧を表示する場合の画面２１００の例である。 Ｗｅｂブラウザで案件一覧を表示する場合の別の画面２２００の例である。 検収・完了時のＷｅｂブラウザで案件一覧を表示する場合の画面２３００の例である。 ダッシュボードの画面２４００の例である。 工程表の画面２５００の例である。 案件検索画面２６００の例である。 データ解析処理フロー２７００の例である。 共通因子解析処理フロー２８００の例である。

以下、実施例を図面を用いて説明する。
建設/不動産においての「信頼」から生まれる「安心」「安全」「適正」は、過去情報の蓄積によって得られるものであるが、サービス間で情報は断絶されており、例えば仲介時に過去の不具合情報を知ることは不可能である。そして、オーナー、住人、管理会社、職人、管理人、建物にかかわる人は全て時間とともに変わっていくため、正確な情報は行政すら把握できていない現状がある。

巷にあふれる「仲介サービス」や「資材サービス」、「工程管理」は顕在化する在庫や需要、現象を“瞬間的に”結びつけているものである。
例えば仲介サービスでは、過去にトラブルを起こしていない入居者か、管理の行き届いた管理会社かを知ることはできなかった。修繕などの工事の場合にも、建物が継続的に抱える不具合があるのか、仕事を依頼する場合に職人が適正な仕事を丁寧にしてくれるかどうなのか、安心を得るすべはなかった。

建物を取り巻く「ヒト」「モノ」「カネ」は流動性が高い特徴があり、このような要素に軸足を置くと、オーナーが変わったり、賃借人が変わったり、職人が変わったりすることで先の情報の断絶が起きてしまう。

そこで、本実施例における建築物の管理システムでは、建物を中心にデータ・モデルを設計することで、断絶により全容を把握することが困難であった「不動産」に公正な情報、そしてこれに基づくマッチングを生み出すことを可能とする。

本実施例では、建物の新規施工時から取り壊しまでの、関連するすべての情報を一元的に管理する管理システムの例を説明する。
図１は、全体の管理システム１の構成図の例である。
管理システム１は、複数の施工会社端末１０２、複数のメーカー端末１０３、複数の管理会社端末１０４、複数の入居者端末１０５、複数のその他業者端末１０６を備え、それぞれがネットワークを介して統合管理システム１０１に接続されている。なお、ネットワークは有線、無線を問わず、それぞれの端末はネットワークを介して情報を送受信することができる。

管理システム１のそれぞれの端末や統合管理サーバ１０１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。あるいは、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。

施工管理会社端末１０２は、デベロッパー、施工会社、工務店、職人などが使用する端末である。
メーカー端末１０３は、資材メーカーや資材問屋などが使用する端末である。
管理会社端末１０４は、管理会社や仲介業者が使用する端末である。
入居者端末１０５は、入居者は建物の所有者が使用する端末である。
その他業者端末１０６は、建物の新規施工時から取り壊しまでの間に介在する上記以外の業者が使用する端末である。
統合管理サーバは、上記それぞれの端末から建物の新規施工時から取り壊しまでの間に生じる様々な情報の入力を受け付け、これらをメインＤＢ２２０の中に記憶する。

管理システム１のそれぞれの端末や統合管理サーバ１０１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。

主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。
本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。

補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、ＸＭＬなどのテキストファイルでもよい。

図２は、統合管理システム１０１のハードウェア構成の例である。
統合管理サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置２０１には、データ登録表示モジュール２１０、状態判定モジュール２１１、データ解析モジュール２１２等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで統合管理サーバ１０１の各機能要素が実現される。

データ登録表示モジュール２１０は、施工会社端末１０２、メーカー端末１０３、管理会社端末１０４、入居者端末１０５、その他業者端末１０６と連携して、これらの端末から受信した情報をメインＤＢ２２０に記憶し、また表示する。データ登録表示モジュール２１０は、データの登録および表示を共に行うが、これらは別々に分離して、データ登録モジュールとデータ表示モジュールとして実装してもよい。

状態判定モジュール２１１は、メインＤＢ２２０に記憶されるトランザクション情報９００を分析することで、各案件や工事や作業の現在の状態を判定し、各端末や出力装置２０５に出力・表示する。
データ解析モジュール２１２は、メインＤＢ２２０に記憶されている情報を解析することにより、各種有用な情報を抽出し、各端末や出力装置２０５に出力・表示する。

補助記憶装置２０２は、メインＤＢ２２０、ヒト関連ＤＢ２２１、モノ関連ＤＢ２２２、コト関連ＤＢ２２３等のデータベースを備える。
メインＤＢ２２０は、施工会社端末１０２、メーカー端末１０３、管理会社端末１０４、入居者端末１０５、その他業者端末１０６から受信した情報を、建物に対するトランザクション情報９００として記憶する。
ヒト関連ＤＢ２２１は、例えばユーザに関する情報、職人に関する情報など、人に関する情報、すなわち「ヒト」に関連する情報を記憶しており、ヒト関連マスタ情報５００を格納している。
モノ関連ＤＢ２２２は、例えば建物のタイプ、レイアウト、区画内の構成、内部の設備など、建物に関する情報、すなわち「モノ」に関連する情報を記憶しており、モノ関連マスタ情報６００を格納している。

コト関連ＤＢ２２３は、例えばプロジェクトの内容、プロジェクトに対するアクション、工事のタイプ、作業内容など、案件・工事・作業（まとめて工事内容と呼ぶこともある）に関連する情報、すなわち「コト」に関連する情報を記憶しており、コト関連マスタ情報７００を格納している。「案件」は「工事案件」と呼ぶこともあり、通常複数の作業を含んでいる。
また、コト関連ＤＢ２２３は、案件・工事・作業（工事内容）の進捗（フェーズ）を示すフェーズ関連の情報も記憶しており、フェーズ関連マスタ情報８００を格納している。

図３は、施工会社端末１０２のハードウェア構成の例である。
施工管理会社端末１０２は、例えばスマートフォンで構成される。
主記憶装置３０１には、統合管理システム連携モジュール３１０や修繕管理モジュール３１１が記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することで施工管理会社端末１０２の各機能要素が実現される。

統合管理システム連携モジュール３１０は、補助記憶装置３０２に記憶されている修繕管理データ３２０や、その他施工会社で取得・管理される情報を、定期的に、もしくは情報の更新があるたびに、または任意のタイミングで統合管理システム１０１に送信する。またアプリケーションのような形ではなく、単にＷｅｂブラウザ経由で統合管理システム１０１にアクセスして、統合管理システム１０１と連携することにより、Ｗｅｂブラウザの機能を用いて情報を送信するという形にしてもよい
補助記憶装置３０２は、施工会社が管理する建物に対する修繕管理データ３２０を記憶する。

図４は、入居者端末１０５のハードウェア構成の例である。
入居者端末１０５は、例えばスマートフォンで構成される。
主記憶装置４０１には、統合管理システム連携モジュール４１０や入居者メンテナンスモジュール４１１が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで施工管理会社端末１０２の各機能要素が実現される。

統合管理システム連携モジュール４１０は、補助記憶装置４０２に記憶されている入居者情報管理データ４２０や、その他入居者端末１０５で取得・管理される情報を、定期的に、もしくは情報の更新があるたびに、または任意のタイミングで統合管理システム１０１に送信する。またアプリケーションのような形ではなく、単にＷｅｂブラウザ経由で統合管理システム１０１にアクセスして、統合管理システム１０１と連携することにより、Ｗｅｂブラウザの機能を用いて情報を送信するという形にしてもよい
補助記憶装置４０２は、入居者の入居者情報管理データ４２０を記憶する。

図５は、ヒト関連マスタ情報５００の例である。
ヒト関連マスタ情報５００は、建物の新規施工時から取り壊しまでに関連するすべての「人」に関する情報のマスタ情報である。マスタＩＤ５０１、カテゴリＩＤ５０３、個別ＩＤ５０５はメインＤＢ２２０の外部キーであり、トランザクション情報９００の該当する箇所に値が記入される。それぞれの内容は参照情報５０２、５０４、５０６に記憶されている。

このヒト関連マスタ情報５００を使用することで、職人に関して、
・どのようなタイプの職人か
・対応可能な地域はどこか
・対応できる工事スキルは何か
・対応可能な仕事内容は何か
などの情報をメインＤＢ２２０のトランザクション情報９００に記憶して管理することができる。

図５の例では、職人に関する情報を記憶しているが、これ以外にも例えば、ユーザに関する情報、職人に関する情報、管理者に関する情報、施工会社に関する情報、管理会社に関する情報などのマスタ情報を記憶することができる。

図６は、モノ関連マスタ情報６００の例である。
モノ関連マスタ情報６００は、建物の新規施工時から取り壊しまでに関連するすべての建物や設備などの「物」に関する情報のマスタ情報である。マスタＩＤ６０１、カテゴリＩＤ６０３、個別ＩＤ６０５はメインＤＢ２２０の外部キーであり、トランザクション情報９００の該当する箇所に値が記入される。それぞれの内容は参照情報６０２、６０４、６０６に記憶されている。

このモノ関連マスタ情報６００を使用することで、建物に関して、
・建物（プロパティ）のタイプはどんなっているか
・建物の間取り（セクション）はどうなっているか
・レイアウトはどうなっているか
・専有部分か、共有部分か
・区画内の構成要素（ブロック）は何か
・どの設備（ファシリティ）に関するものか
などの情報をメインＤＢ２２０のトランザクション情報９００に記憶して管理することができる。

図６の例では、建物や設備に関する情報を記憶しているが、これ以外にも例えば、機器に関する情報、部品に関する情報、素材に関する情報、材料に関する情報などのマスタ情報を記憶することができる。

図７は、コト関連マスタ情報７００の例である。
コト関連マスタ情報７００は、建物の新規施工時から取り壊しまでに関連するすべての工事、作業の内容などの「事柄」に関する情報のマスタ情報である。マスタＩＤ７０１、カテゴリＩＤ７０３、個別ＩＤ７０５はメインＤＢ２２０の外部キーであり、トランザクション情報９００の該当する箇所に値が記入される。それぞれの内容は参照情報７０２、７０４、７０６に記憶されている。

このコト関連マスタ情報７００を使用することで、工事や作業などに関して、
・プロジェクトの内容はどのようなものか
・プロジェクトに対するアクションはどのようなものか
・工事の内容はどのようなものか
・作業の内容はどのようなものか
などの情報をメインＤＢ２２０のトランザクション情報９００に記憶して管理することができる。
なお図７は例示であり、これ以外の「事柄」に関するマスタ情報を記憶してもよい。

図８は、フェーズ関連マスタ情報８００の例である。
フェーズ関連マスタ情報８００は、メインＤＢ２２０のトランザクション情報９００に記憶されていく案件の進捗を管理するためのマスタ情報である。マスタＩＤ８０１、カテゴリＩＤ８０３、個別ＩＤ８０５はメインＤＢ２２０のトランザクション情報９００の該当する箇所の値として使用される。それぞれの内容は参照情報８０２、８０４、８０６に記憶されている。

このフェーズ関連マスタ情報８００を使用することで、案件の進捗に関して、
・現在「依頼・調査・手配・現場作業・完了報告・請求・完了」の７つのフェーズ８２１のうちのどのフェーズにいるのか（phase_name８１１）
・それぞれのフェーズの中で、どのような状況なのか（status_name８１２）
・上記各状況の中で、さらにどのような状態なのか（status_item８１３）
について細かく管理することができる。

status_name８１２とstatus_item８１３を組み合わせることで、案件のすべての状況を特定することが可能である。また、この組み合わせで特定された状況から、その時点の進捗がphase_name８１１で記載している７つのフェーズ一覧８２１のどれにあたるのかを判定することができる。
status_name８１２の個別ＩＤ８０５の値は、メインＤＢ２２０のトランザクション情報９００のステータス名９１１(status_name)に記憶され、トランザクションのレコードがステータス名一覧８２２のどの状況なのかを示す。
status_item８１３の個別ＩＤ８０５の値は、メインＤＢ２２０のトランザクション情報９００のステータス項目９１２(status_item)に記憶され、８２２の状況の中で詳細がさらにステータス項目一覧８２３のどの状況なのかを示す。

例えば、トランザクション情報９００の中で、ステータス名９１１(status_name)がproject_assign_statusで、ステータス項目９１２(status_item)がcompletedだった場合には、依頼が完了の状態であることを示す。ステータス名９１１がtachiai_statusで、ステータス項目９１２がassign_doneだった場合には、立ち合いが依頼済みの状態であることを示す。ステータス名９１１がinspection_statusで、ステータス項目９１２がongoinだった場合には、現場調査（現調）が実施中の状態であることを示す。

図９、図１０は、メインＤＢ２２０に記憶されるトランザクション情報９００の例である。
統合管理システム１０１は、施工会社端末１０２、メーカー端末１０３、管理会社端末１０４、入居者端末１０５、その他業者端末１０６とネットワークを経由してつながっており、これらの端末からの入力を受け付け、建物の新規施工時から取り壊しまでに関連するすべてのトランザクションをメインＤＢ２２０のトランザクション情報９００に記憶する。

このトランザクション情報９００は、基本的にはデータの更新はされず、トランザクションの発生毎に時系列にレコードが追加され続ける。
ヒト関連マスタＤＢ２２１、モノ関連マスタＤＢ２２２、コト関連マスタＤＢ２２３で管理されているように、「ヒト」「モノ」「コト」に関するすべての事象が、トランザクション情報９００として記憶され、「誰が」「どこに」「何をしたか」が１レコードで表現される。例えば、１部屋の原状回復工事案件で１００件以上のトランザクションデータが生成・記憶される。

トランザクション情報９００に記憶される情報は項番９０３、９１３のように１００項目以上あるが、ここに列挙するものに限定されず、これ以外の情報を記憶することとしてもよい。
記載される対象９０１、９０２、９１１、９１２は、プロジェクトに関する情報、時期に関する情報、モノ（建物や設備）に関する情報、コト（工事内容：状況、対応内容、金銭）に関する情報、ヒト（依頼元や依頼先）に関する情報を記憶する。
属性９０４、９１４は、各記憶できる情報の内容であり、それぞれが属性タイプ（クラス名）９０５、９１５として定義されている。それぞれについてデータ型９０６、９１６が決められている。

図１１はトランザクション情報９００に記憶された情報の一部を抜粋した例である。
モノに関する情報１１０３として、建物ＩＤ、建物名、建物住所、区画ＩＤ（部屋番号）が記憶されている。また、ブロックＩＤ、ブロック種別として、現場調査を行う対象の区画である洋室・トイレ・玄関などが記憶されている。さらに、ファシリティ種別ＩＤ、ファシリティＩＤ、型番、メーカーとして、調査の対象である設備（ファシリティ）であるエアコン、水栓、鍵やその型番やメーカーなどが記憶されている。１１０１は図１０の項番９０３、９１３に対応し、１１０２は属性タイプ９０５、９１５に対応する。

ステータス名１１１１(status_name)及びステータス項目１１１２(status_item)の値及びその参照先であるフェーズ関連マスタ８００のstatus_name８１２及びstatus_item８１３により、各レコードの状況を特定することができる。図１１の例は、特許アパート１０１号室の案件が開始し、立ち合い、調査、工事手配、材料手配、現場対応、案件承認が実施された場合のそれぞれのトランザクションの一部を抜粋したものである。

図１２は、フェーズ開始終了条件情報１２００の例である。
フェーズ番号１２０１、フェーズ名１２０２、フェーズ項目１２０３は、フェーズ関連マスタ８００のphase_name８１１に示される７つのフェーズ一覧８２１のどれに当たるのかを示す。
各フェーズにはそれぞれ開始条件１２０４及び終了条件１２０５が定められており、これらの条件の組み合わせにより、トランザクション情報９００に記載される各レコードの現時点の進捗状況（フェーズ）を判定する。

例えば、一つの原状回復工事を考えてみても、限られた期間の中で複数の工事や作業が並列して実施されていくのが通常であり、このそれぞれの状況をすべて把握して進捗を管理することは難しかった。

一方本実施例では、何かしらの事象（アクション）が発生した場合に、トランザクション情報９００にそれを逐一一行のデータレコードで蓄積していき、かつ、このトランザクション情報９００のレコードとフェーズ開始終了条件１２００とを比較することで、各トランザクションの属するフェーズを判定し、これをユーザに分かりやすく表示することができる。

図１３は、フェーズ進行可否判定情報１３００の例である。
フェーズ進行可否判定情報１３００は、複数並列して発生する工事や作業について、現フェーズから次のフェーズに移行してよいかどうかを規定するテーブルである。
表の縦軸に現フェーズ１３０２及びそのステータス１３０３が記載されており、これが横軸に記載されている次フェーズ・ステータスに移行してよいかどうかを「◎」「〇」「×」「−」で示している。

各符号の意味は以下のとおりである。
「◎」は、横軸のフェーズに進行可、かつ最も一般的な進行を示す。
「〇」は、横軸のフェーズに進行可であることを示す。
「×」は、横軸のフェーズに進行不可であることを示す。
「戻」は、現状よりも前のフェーズ（１３０１のフェーズ番号が小さい方向）に戻ることが想定されているものを示す。
「−」は、現状よりも前のフェーズに戻ることは通常ないが、特に戻ることを禁止しているわけではないものを示す。

例えば、２−１退去立会・２−２現場調査からは一般的に２−３作業承認に進行する。調査の２−３作業承認の次は、３−１工事手配か３−２材料手配に行くことが一般的だが、４現場作業に行く場合もあれば、そのまま５完了報告や６請求になることもある。４−１現場対応の次は４−２作業報告になる、但し、場合によっては再度２−２現場調査に戻らなければならない場合もある。
このように、フェーズ進行可否情報１３００により、各フェーズの進行可否を判定することで、誤った作業工程の進行を防ぐことが可能となる。

図１４は、データ登録処理フロー１４００の例である。
データ登録処理は、統合管理システム１０１のデータ登録表示モジュール２１０が、施工会社端末１０２、メーカー端末１０３、管理会社端末１０４、入居者端末１０５、その他業者端末１０６と連携して、これらの端末から生じた事象に関する情報（アクション内容）を受信・記憶する処理である。

データ登録表示モジュール２１０は、端末からアクション内容を受信する（ステップ１４１０）。なお、各端末からの入力内容を受信するのではなく、統合管理システム１０１の入力装置２０４によりユーザが直接アクション内容の入力を行ってもよい。
各アクション内容は、例えば、施工管理会社端末１０２の統合管理システム連携モジュール３１０がユーザからの入力を受け付けることにより生成される。又は、例えば入居者端末１０５の統合管理システム連携モジュール４１０がユーザからの入力を受け付けることにより生成される。

データ登録表示モジュール２１０は受信したアクション内容によるステータス変化が、禁則処理に当たらないかどうかを状態判定モジュール２１１に問い合わせることにより禁則チェックを実施する（ステップ１４２０）。

禁則処理に当たらないと判定された場合には、入力されたアクション内容を、メインＤＢ２２０のトランザクション情報９００に１レコード追記し（ステップ１４４０）、このアクション内容に関するステータス状況をステータス名９１１とステータス項目９１２に書き込む（ステップ１４５０）。書き込まれる内容は、フェーズ関連マスタ情報８００に記載されているステータス名一覧８２２及びステータス項目一覧８２３から選択される。

禁則処理に当たると判定された場合には、その旨のエラーをアクション内容を受信した各端末に送信し、各端末はエラー内容を表示する（ステップ１４６０）。もしくはエラー内容を統合管理システム１０１の出力装置２０５に表示する。

図１５は、フェーズ更新処理フロー１５００の例である。
フェーズ更新処理は、統合管理システム１０１の状態判定モジュール２１１が、トランザクション情報９００の記入に応じて、現時点のフェーズを判定する処理である。

状態判定モジュール２１１は、フェーズを判定したい案件の指定を受け付ける（ステップ１５１０）。
そして、当該モジュールは、指定された案件のトランザクション情報９００のレコードを取得し、各レコードに記載された最新のステータス情報を取得する（ステップ１５２０）。
例えば図１１の記入例では、案件ＩＤ１１１３が「１１」であり同一のものを抽出し、これらのレコードのステータス情報（ステータス名１１１１及びステータス項目１１１２）を取得する。

状態判定モジュール２１１は、取得した最新のステータス情報とフェーズ開始終了条件とを比較することで、現時点のフェーズを判定する。
具体的には、当該モジュールは取得したステータス情報（ステータス名９１１及びステータス項目９１２）が、フェーズ開始終了条件のフェーズ終了条件を満たしているか（ステップ１５３０がＹｅｓ）もしくは次フェーズの開始条件を満たしいている場合（ステップ１５４０がＹｅｓ）、次フェーズに進行してもよい場合であると判定する。

この場合、状態判定モジュール２１１は、さらにフェーズ進行可否判定情報１３００を参照し、次フェーズに進行してよいかどうかを判定する（ステップ１５５０）。
進行可能であると判定された場合には、フェーズを次フェーズに更新する（ステップ１５６０）。

フェーズ開始終了条件により、現フェーズ終了条件を満たしておらず、かつ次フェーズ開始条件を満たしていない場合（ステップ１５３０及びステップ１５４０がいずれもＮｏ）、フェーズ進行はないものとして、現フェーズのままにする（ステップ１５７０）。
また、ステップ１５３０又は１５４０がＹｅｓであり、次フェーズに進行してもよい場合であっても、フェーズ進行可否判定情報１３００によるフェーズ進行可否判定の結果（ステップ１５５０）がＮｏであった場合には、現フェーズのままとする（ステップ１５７０）。

状態判定モジュール２１１は、その結果更新された最新のフェーズ情報を、各端末や統合管理システム１０１に表示する。もしくは、トランザクション情報９００に最新のフェーズ情報を記憶する（ステップ１５８０）。

なお、本フローでは、特定の案件ごとにフェーズを判定することとし、ステップ１５１０で案件の指定を受け付けているが、案件ごとだけではなくユーザの指定する任意の情報毎にフェーズを判定することが可能である。
例えば、特定の作業に関するフェーズを判定したい場合には、当該特定の作業ＩＤを有するレコードを抽出して、同様のフェーズ判定処理を実行すればよい。また特定の建物や設備に関するフェーズを判定したい場合には、トランザクション情報９００のモノ１１０３に記載された、建物名や、区画ＩＤ、ファシリティＩＤなどでソートして、レコードを抽出し、同様のフェーズ判定処理を実行すればよい。

図１６〜図２５は、各端末や統合管理システム１０１の表示画面の例である。
トランザクション情報９００を記入する際の端末からの入力画面や、トランザクション情報９００から取得した情報を表示する画面の例を示す。

図１６は、案件起票時の入力画面１６００の例である。
統合管理システム１０１のユーザや、管理会社端末１０４のユーザ、施工管理会社端末１０２のユーザなど、案件を管理するユーザが、案件を起案する際に入力する画面の例である。統合管理システム１０１の場合には、データ登録表示モジュール２１０が出力装置２０５に画面を表示し、入力装置２０４を介してユーザからの入力を受け付ける。施工管理会社端末１０２や管理会社端末１０４など各端末の場合には、各端末の統合管理システム連携モジュールが、統合管理システム１０１のデータ登録表示モジュール２１０と連携して画面を表示する。統合管理システム連携モジュールは、スマートフォンのアプリのような形態でもよいし、統合管理システム１０１から受信した画面情報を表示するＷｅｂブラウザの形態でもよい。

１６０１は、起票する案件の種類を選択する選択欄である。
１６０２は、建物に関する情報を入力する欄である。
１６０３は、管理会社に関する情報を入力する欄である。
１６０４は、連絡先に関する情報を入力する欄である。
１６０５は、契約内容について入力する欄である。
１６０６は、案件の詳細について入力する欄である。
１６０７は、対応日程について入力する欄である。
１６０８は、工事依頼先について記入する欄である。

１６０９の保存ボタンがクリックされると、データ登録表示モジュール２１０は、入力されたそれぞれの情報を、メインＤＢ２２０のトランザクション情報９００の「プロジェクト」「時期」「モノ」「コト」「ヒト」のそれぞれの対応箇所に記憶する。また、図１１のレコードＩＤ100004の様に、ステータス情報１１１１、１１１２に、プロジェクトの「依頼」が「完了」したことを示す情報「project_assign_statu」「completed」が記入される。

図１７は、新たな作業項目を追加する入力画面１７００の例である。
１７０１は、案件の選択を受け付ける選択欄であり、既にコト関連ＤＢ２２３やトランザクション情報９００に記憶されている案件一覧の情報が表示される。
１７０２は、作業の種別の選択を受け付ける選択欄である。既にコト関連ＤＢ２２３やトランザクション情報９００に記憶されている作業一覧の情報が表示される。
１７０３は、工事の種類の選択を受け付ける選択欄である。既にコト関連ＤＢ２２３やトランザクション情報９００に記憶されている工事一覧の情報が表示される。
その他、作業や工事に関する情報の入力を受け付け、保存ボタン１７０４がクリックされると、データ登録表示モジュール２１０は、これらの入力情報をもとにトランザクション情報９００に１行レコードを追記する。
例えば、１７０２で退去立会代行が選択され、予定日時等が入力されて保存ボタン１７０４が押されると、図１１のレコードＩＤ10007の様に、ステータス情報１１１１，１１１２に、「退去立会」が「依頼済み」であることを示す情報「tachiai_status」「assign_done」が記入される。

図１８〜図２０は、現場調査や工事などを実施する施工管理会社端末１０２、管理会社端末１０４などの各端末が表示する画面の例である。例えば担当者が操作するスマートフォンなどの端末の統合管理システム連携モジュールが画面を表示する。統合管理システム連携モジュールは、スマートフォンのアプリのような形態でもよいし、統合管理システム１０１から受信した画面情報を表示するＷｅｂブラウザの形態でもよい。

図１８は、現場調査を実施する際の画面１８００の例である。
１８０１には、案件に関する情報が表示されている。統合管理システム連携モジュールは、統合管理システム１０１と連携し、トランザクション情報９００に記憶されている案件に関する情報や対象の建物に関する情報を、コト関連ＤＢ２２３やモノ関連ＤＢ２２２を参照しながら取得し、１８０１に表示する。
トランザクション情報９００に記憶されている住所に関する情報（項番２６）に基づき、地図上に表示を行ったり（１８０２）、鍵に関する情報（項番７３〜７６等）に基づき、カギ情報を表示する（１８０３）こともできる。

１８１１には、実施された現場調査の一覧が表示されている。ここに表示されている情報は、トランザクション情報９００に記載されている現場調査（現調）の情報を取得して表示している。例えば、コトに関する情報として、何をしたか詳細を記載した項番５０−７２等のような情報を表示することで、写真やその他の情報を表示することができる。

さらに現場調査情報を追加する場合には１８１２がクリックされ、図１９のような現調情報を追加する画面に遷移する。
すべての現場調査が終了した場合には、完了報告１８１３がクリックされ、データ登録表示モジュール２１０がすべての情報をトランザクション情報９００に記憶する。

図１９は、担当者が現場調査を実施する際の画面遷移の例である。
１９０１は、工事する部屋についての情報を入力する欄である。統合管理システム連携モジュールは、トランザクション情報９００及びモノ関連マスタ情報６００に基づき、すでに登録されている部屋の情報をプルダウン表示する。対応する部屋が無い場合には、「新規追加」の選択を受け付け、１９１０のような新規追加画面をポップアップ表示する。

１９０２は、工事する箇所についての情報を入力する欄である。統合管理システム連携モジュールは、トランザクション情報９００及びモノ関連マスタ情報６００に基づき、すでに登録されている箇所（区画や設備）の情報をプルダウン表示する。対応する箇所が無い場合には、「新規追加」の選択を受け付け、１９２０のような新規追加画面をポップアップ表示する。

１９０３は、工事の種別などの内容詳細を入力する欄である。さらに詳細な情報を入力する場合には、１９３０のような設備の詳細の記入を受け付ける。

なお、統合管理システム連携モジュールは、現場調査実施時に、工事が必要な箇所や現在の設備の写真などをトランザクション情報９００に登録することが可能である（１９０４）。
また、この際、同じ部屋や、同じ工事箇所に関する過去のトランザクション情報９００を検索することで、過去の状況や過去の写真などを取得して、１９０５の様に表示することが可能である。

図２０は、工事実施時の入力画面の例である。
左側の画面２０００は、工事実施時に担当者が情報を入力する入力画面の例である。右側画面２０１０は、その入力を受けて、検収者が検収を行う場合の入力画面の例である。
２００１には、トランザクション情報９００に記憶されている、同一設備の過去の写真が検索され、表示されている。
２００２には、今回の工事の対象についての情報が、トランザクション情報９００のモノやコト、ヒト、時期に関する情報から取得され表示されている。

２００３は、工事担当者が工事の状況を記入する記入欄であり、２００４の様に現在の設備の写真をアップロードし、トランザクション情報９００の写真欄（項番６６〜６８等）に記憶することができる。トランザクション情報９００の写真欄には、実際にはＵＲＬ等が記載されており、写真データの実体は統合管理システム１０１の補助記憶装置の中に記憶されており、当該ＵＲＬによりこのデータが参照されている。

作業が完了した場合には、２００５のボタンのクリックを受け付け、データ登録表示モジュール２１０は、記入された作業情報をトランザクション情報９００に記憶する。

次に、作業の検収者は、工事が完了した案件の設備に関する情報を表示する。検収者の使用するスマートフォンなどの端末の、統合管理システム連携モジュールは、統合管理システム１０１と連携することで、メインＤＢ２２０のトランザクション情報９００に記憶されている、工事の情報を表示する。

例えば２０１１には、トランザクション情報９００のトラブルの内容や原因（項番５３，５４等）を取得して表示される。
２０１２には工事実施前の写真がＢｅｆｏｒｅとして掲載され、２０１３には工事完了後の写真がＡｆｔｅｒとして掲載されている。いずれもトランザクション情報９００の添付写真（項番６６〜６８）から取得することで表示される。

検収者は、比較可能な状態で表示されているＢｅｆｏｒｅとＡｆｔｅｒの両方の写真も考慮しながら、検収作業を実施し、２０１４にコメントを記入して、検収報告の完了ボタン２０１５をクリックする。
すると、統合管理システム１０１のデータ登録表示モジュール２１０は記入された情報についてメインＤＢ２２０のトランザクション情報９００に１行レコードを追記する。

図２１〜図２６は、Ｗｅｂブラウザで案件を表示する場合の画面の例である。
統合管理システム１０１の場合のデータ登録表示モジュール２１０は、トランザクション情報９００及びヒト関連ＤＢ２２１、モノ関連ＤＢ２２２、コト関連ＤＢ２２３等の各種情報を取得することで、出力装置２０５に画面を表示し、ユーザからの操作を受け付ける。施工管理会社端末１０２や管理会社端末１０４など各端末の統合管理システム連携モジュールは、統合管理システム１０１のデータ登録表示モジュール２１０と連携して画面を表示する。統合管理システム連携モジュールは、スマートフォンのアプリのような形態でもよいし、統合管理システム１０１から受信した画面情報を表示するＷｅｂブラウザの形態でもよい。

図２１は、Ｗｅｂブラウザで案件一覧を表示する場合の画面２１００の例である。
統合管理システム１０１のデータ登録表示モジュール２１０は、メインＤＢ２２０のトランザクション情報９００に記憶されている情報をヒト関連ＤＢ２２１、モノ関連ＤＢ２２２、コト関連ＤＢ２２３を参照しながら呼び出し、各種画面を生成して、出力装置２０５に表示する。またインターネット経由で各端末に表示を行ってもよい。

２１０１および２１０２には、案件に関する基礎情報が記載されている。
例えば、建物に関する情報、管理会社に関する情報、工事会社に関する情報、連絡先に関する情報、受注済みの見積書、報告された不具合等が記載され、これらの情報はトランザクション情報９００および各種マスタＤＢの情報から取得をすることにより表示をすることができる。

２１０３の「現場調査」が選択されると、２１０１で表示される案件に関連する「現場調査」の情報がトランザクション情報９００から取得され、現場調査に関する情報が２１０４のように一覧表示されている。
それぞれの施工内容については、部屋や箇所（区画や設備）がどこなのか、行う工事が何なのか、どのような理由で工事するのか、等の情報をトランザクション情報９００から取得して２１０５のように表示することができる。
同様に２１０３で選ばれた項目に関する情報について、データ登録表示モジュール２１０は、トランザクション情報９００からヒト・モノ・コトマスタＤＢを参照しながら該当する情報を取得し、２１０４の欄に表示を行うことができる。

２１１２には、各作業の現在のステータス（依頼済みでこれから実施する旨）が、ステータス情報９１１や９１２により判断され、表示されている。またこれら並列して実施される複数の作業の総合的なステータスは２１１３に表示されている。なお、総合的なステータスとしては、最も遅れているステータスを表示してもよいし、複数の作業の最も遅れているものと最も進んでいるものを両方取得して、「調査実施中〜工事依頼済み」のようにレンジで表示してもよい。

並列して実施されている作業や工事の状況が、状態判定モジュール２１１により判定され、案件全体での進捗フェーズが特定されて、２１１１に表示される。２１１１の例では、依頼と調査が終了しており、現在手配のフェーズにいることが分かる。

アクションの下にかかれている鉛筆アイコンは、編集できることを示す記号である。この鉛筆アイコンをクリックすることで、ユーザは各項目の編集画面に進み、内容を編集することが可能である。アクションの下の鉛筆アイコンの右にあるゴミ箱アイコンは、個別の作業内容を削除するためのアイコンである。

図２２は、Ｗｅｂブラウザで案件一覧を表示する場合の別の画面２２００の例である。
ここでは、発注・手配する作業一覧を表示している。
例えば、エアコン工事、大工工事、検収工事等の各工事が記載され、それぞれの中に複数の作業が登録されている。

大工工事２２０１の例では、この工事は８月９日から１６日の間に完了する必要があり（２２０５）、これを展開表示すると、４件の作業２２０２が表示される。
各作業の対象や原因、依頼先、依頼内容などはトランザクション情報９００に記載された各項目から取得し、２２０３のように表示する。
まだ依頼されていない２件の作業２２０４については、手配ボタン２２０６のクリックに応じて、入力画面を表示し、手配に進むことができる。

工事の期間２２０５は、指定された期間の情報がトランザクション情報９００またはコト関連ＤＢ２２３に記憶されており、この情報を読みだして線表として表示する。
この中で、手配される各作業については、この工事期間の始期と終期の間に設定される必要があり、手配の際に工事の期間２２０５を超えた日程が規定されている場合には、エラーを表示してもよい。
また、各作業の日程について、現在のステータス情報や各作業の進捗を判断して、最適な作業日程を候補日としてあらかじめ表示するようにしてもよい。

図２３は、検収・完了時のＷｅｂブラウザで案件一覧を表示する場合の画面２３００の例である。
２３０１には、検収結果が表示されている。
２３０２には、完了報告書が表示されている
２３０３には、精算交渉の状況が表示されている。
データ登録表示モジュール２１０は、トランザクション情報９００のステータス情報９１１、９２２の内容に基づいて、現在の状況をそれぞれの項目のステータス２３１１、２３２１、２３２２として表示する。

図２４は、ダッシュボードの画面２４００の例である。
データ登録表示モジュール２１０は、関連する案件の作業情報をトランザクション情報９００からまとめて取得し、このステータス情報９１１、９１２でソートすることで、２４０１のように、見積書提出待ち、手配待ちの作業、未報告の現場対応、完了報告書の提出待ち、完了報告書の承認待ち、現場対応予定、のそれぞれの件数をカウントして、表示する。

２４０２には、ログインしたユーザのＩＤでトランザクション情報９００をソートし、今後一週間の現場対応予定に関する情報を取得し、表示する。
２４０３には、トランザクション情報９００に書き込まれた、同一案件に関する情報がログとして表示されている。

図２５は、工程表の画面２５００の例である。
データ登録表示モジュール２１０は、ユーザが対応しているすべての案件について、工程表を表示する。通常１つの案件でも最低３〜１０人の職人が関与し、工事の手配は多数の職人を期限内に手配する必要があって、案件管理には深い経験が求められた。
しかしながら、図２５のように、現在進捗中及び今後手配しなければならない工事・作業の一覧を見える化することで、手配の支援を容易にし、また手配漏れを防ぐことが可能となる。

データ登録表示モジュール２１０は、それぞれの工事・作業についての情報をトランザクション情報９００から、ヒト・モノ・コト関連マスタＤＢを参照して取得し、図２５のような案件ごとの線表を表示する。

例えば、１０１号室の退去工事案件２５０１は８月９日から１６日の間に実施する必要があるが（２５０２）、この案件を展開して表示すると、１件の調査と３件の工事が記載されている（２５０３）。
調査には２件の作業、エアコン工事には３件の作業、大工工事には１件の作業が必要で、それぞれの作業予定が線表２５０４の様に分解して記載されている。それぞれの作業に必要な日数や、作業の予定日は、すべてトランザクション情報９００または各種マスタＤＢに記載されている情報を取得することで、データ登録表示モジュール２１０が表示をおこなう。

図２６は、案件検索画面２６００の例である。
例えば管理会社端末１０４や施工会社端末１０２に表示される画面の例である。管理会社も施工会社も多数の案件を抱えており、各案件の中で複雑な進捗状況を管理する必要がある。図２６のようにトランザクション情報９００に格納したすべての作業情報を検索する機能を提供することで、各社が担当する案件が、どのような状態で、次にどんなアクションをしなければならないのかを表示することが可能となる。

２６０１は、検索のための条件の記入欄である。案件が原状回復なのか、入居中修繕なのかの選択の受け付けや、フェーズ、工期、ステータス、キーワードなどでの検索が可能である。

その検索結果は一覧表示され、各案件の概要が２６０４に表示される。それぞれの案件をクリックすると、さらに案件の詳細情報を確認することも可能である。
また、それぞれの案件について、フェーズ判定処理手段により判定された現在のフェーズが２６０２に表示され、現在のステータス情報が２６０３に表示されている。

このように、図２６のような検索及び結果の一覧表示を行うことで、各案件の現在の状況が簡単にわかり、かつ各案件の概要や詳細を表示可能であって、管理会社や施工会社は案件の進捗を容易に把握することができるようになる。

以上説明してきたように、本実施例によれば、建物の新規施工時から取り壊しまでの、関連するすべての情報を一元的に記憶、管理する管理システムを実現する。本実施例の管理システムにより、従来は管理会社ごと、施工会社ごと、などでそれぞれ管理されて断絶されていた情報が、１つのメインＤＢ２２０により時系列ですべて一元的に管理され、居住者や、オーナー、管理会社、施工会社、その他関連する企業すべてにとって有益な情報を提供するためのベースとなる情報が蓄積されることとなる。

これまで記載してきた通り、メインＤＢ２２０のトランザクション情報９００には、建物の新規施工時から取り壊しまでの、関連するすべての情報が時系列に一元的に記憶されている。これらの蓄積情報を解析することで様々な有用な情報を引き出し、表示することが可能となる。
本実施例では、実施例１において蓄積されたメインＤＢ２２０の情報に基づいて、データ解析を実施し、有益な情報を抽出・表示する方法について説明する。

図２７は、データ解析処理フロー２７００の例である。
統合管理システム１０１のデータ解析モジュール２１２は、メインＤＢ２２０から検索したい項目の情報を取得する（ステップ２７１０）。
データ解析モジュール２１２は、取得したデータを解析し（ステップ２７２０）、解析結果を統合管理システム１０１の出力装置２０５に表示する、もしくは各端末に送付し、各端末が表示する（ステップ２７３０）。

図２８は、共通因子解析処理フロー２８００の例である。
データ解析モジュール２１２におけるデータ解析処理２７２０のユースケースの１つを説明するフローであり、時系列に蓄積された多数の情報の中から、共通の因子を抽出発見して表示するものである。

例えば、
１．建物単位のソート分析による共通因子の発見
２．区画単位のソート分析による共通因子の発見
３．施設単位のソート分析による共通因子の発見
４．担当管理会社単位のソート分析による共通因子の発見
５．業者単位のソート分析による共通因子の発見
などにより、それぞれの単位で共通に発生している事項、評価、内容などを、特異情報として表示する。

図２８の例ではさらに、これらのトランザクション情報９００が、いくつかの階層構造を持つ複数の項目の情報を含んでいることに着目し、階層的な項目を粒度の小さいものから大きいものに順に共通因子を発見していくことで、どの階層の項目で特異情報が現れるかを順次判定していく。

データ解析モジュール２１２は、まず階層的な項目のうちの特定の項目のデータをすべて取得する（ステップ２８１０）。
当該モジュールは、データを解析し、それらのデータに共通する因子を検出する（ステップ２８２０）。

共通因子が見つかった場合には、その共通因子のあるデータを特異情報として出力・表示する（ステップ２８４０）。
共通因子が見つからなかった場合には、一つ上位の階層の項目に移動し（２８６０）、この一つ上位の階層の情報をまたすべて取得して同様の解析処理を実施する。

階層のすべての項目について解析処理が終わるまで処理を繰り返し（ステップ２８５０）、階層ごとに順次特異情報を発見していく。
例えば、トランザクション情報９００は、建物のトラブルに関する情報を、建物・区画・ブロック・設備などの階層上の項目で記憶している。具体的には、ある建物ＡＡのＢＢ号室の部屋ＣＣの設備ＤＤにトラブルが起きているのかという情報を蓄積している。

このような、階層構造をもつ情報を小さいものから順に共通因子が無いかをたどっていく。例えば、トランザクション情報９００のある建物ＡＡのＢＢ号室の部屋ＣＣの設備ＤＤ（ＤＤはトイレとする）の情報を過去にわたってさかのぼり、すべてのレコードを取得する。
ここで、過去も何度もの同じような不具合が発見されれば、このある建物ＡＡのＢＢ号室の部屋ＣＣのトイレ自体に問題があるのだという特異情報が抽出される。

次に、１階層上位の建物ＡＡのＢＢ号室の部屋ＣＣが同一の過去のすべてのレコードを取得する。これを解析することで、特異情報が抽出されるか確認する。同様に１階層ずつ上位に解析をしていく。

ここで例えば、建物ＡＡが同一であるすべてのレコードについて同様の解析を行い、不具合の生じた同じ建物ＡＡの他の部屋でも、同様にトイレのトラブルが起きていることが共通因子として発見されたとする。この場合、建物ＡＡのＢＢ号室の部屋ＣＣの設備ＤＤが過去にわたってトイレトラブルがある、ということだけではなく、実は建物ＡＡのいくつかの他の部屋のトイレにもトラブルがあるということが発見でき、建物ＡＡ自体の水回りのトラブルの可能性が想定される。

このように、階層状の項目について順次トランザクション情報９００に記憶されている情報の共通因子を見つけ出していくことで、建物全体について総合的に問題点や特徴点などを見つけ出すことが可能となる。

階層的な共通因子解析処理フローは、トラブルなどが発見された場合の調査に有効である。当該トラブルが発見された設備（機器等）についての原因をトランザクション情報９００を検索することで行うが、これを当該設備から階層を上にたどって順次検索して共通因子（トラブルの原因）を発見していくことで、このトラブルが、設備によるものなのか、その上の階層の区画によるものなのか、さらにその上の階層の建物によるものなのか、などを特定することが可能となり、効率よく的確に問題の所存を発見することができる。

その他にも、トランザクション情報９００に格納されている建物の新規施工時から取り壊しまでの時系列情報に基づいて、以下のようなデータ解析のユースケースが考えられる。このデータ解析は図２７のように、データ解析モジュールがデータを解析することにより実現される。トランザクション情報９００の「項番」は図９の項番９０３および図１０の項番９１３の番号を示す。

１．建物全体の品質を監視
項番２４の建物ＩＤごとに、項番５２のトラブル有無をソート、トラブルがあった件について、項番５０のファシリティ症状種別で１年ごとに集計を行う。
これにより、部屋や区画を超えて建物自体の老朽化や施工品質を把握することができる。

２．モノの品質を監視
建物や区画関係なく、項番３９の型番、項番４０のメーカー、項番４１の年式ごとに、項番５２のトラブル有無をソート、時系列で集計することで、型番、メーカー、年式ごとにトラブル頻度を算出。
例えばＸＸ社製の２０００年式ＹＹという型番のエアコンは２年ごとに多くの場合故障しているという情報を得ることができる。
また、故障している地域（項番２６建物住所）を軸にみることで、上記のエアコンが寒冷地では故障頻度が高いなどの分析結果を出力することができる。

これらの情報により故障予測をたてることができるため、製品需要予測をメーカーに提供することが可能となり、問屋に需要予測をたてさせることも可能となる。
また、ある時期にまとめて同型番や同メーカーの商品を発注してリプレースすることで大量購入によるコスト減も可能となる。

３．地域の状態を監視
項番５２のトラブル有無、項番３７のファシリティＩＤ、項番５０のファイシリティ症状種別、項番２６の建物住所の相関を見ることで、一つの区画トラブルを超えた例えば悪臭や害虫被害などの地域インフラのトラブルを検知することが可能となる。
通常地域は所有区画で管理がわかれており、統一的に町内の共通インフラの問題を知ることは極めて難しい。しかしながら、このデータ形式では部屋や建物の単位を超えて地域の抱える問題についても知ることや予見することが可能となる。

４．仕事の品質＝職人を監視
実際に建物を治すのは「職人」と言われる人たちであるが、この「職人」は主に、電気工事、水道工事、内装工事などある程度のジャンルに分かれている。
項番１０２の依頼先担当者名でソートし、項番６０の作業検収判定にＮＧがついている職人を集計すると、依頼した作業を一回で終わらせられないいい加減な仕事をする職人かどうかの評価を出力可能となる。
また、その職人が対応した箇所（項番３７のファシリティＩＤ）に、次に問題が発生するまでの時間が短い（項番５２のトラブル有無及び項番２１のタイムスタンプより算出）場合、見た目が良く工事完了を検収しても、すぐにダメになるいい加減な仕事をする職人であるという評価を出力することが可能となる。

５．適切な対価を監視
類似する工事の金額の平均値と分散を取得。
項番３３のファイシリティ種別ＩＤ、項番５８の作業名、項番１０２の依頼先担当者、項番９０の原価の情報でソートすることにより、特定の職人について工事対象箇所に関する原価を集計することで、各作業ごとの適正価格を出力することが可能となる。
通常、一式で工事見積もりを通していることが多く作業粒度も大きく、個別の作業の価格の分析ができる状況ではなかった。また、職人が他でいくらで仕事をしているか分からなかった。
しかしながら、本実施例のトランザクション情報９００では、すべての作業が細かい粒度で記憶されているため、これらを個別に分析することで、例えば、同じ水道管のパッキン交換であっても、職人Ａは平均３万円、職人Ｂは平均１０万で行っているということを見える化することが可能となる。

６．人間のスコアリング
複数の分析を組み合わせることによってヒトやモノをスコアリングすることが可能になる。
例えば、職人の「作業の価格」「作業品質」「対応スピード」の３つをパラメータ化し、各職人ごとに評価することで、各職人をスコアリングすることが可能となる。
「作業の価格」は、分析５で導出したように、価格の平均値からのハズレ具合をスコア化することができる。例えば工種によって価格差は大きく異なるため偏差値を用いてスコア化する。
「工事品質」は、分析４で記載したような仕事の品質に基づいてスコアリングが可能である。
「対応スピード」は、例えば、「現場」と「職人の事務所が近いかどうか」で近似してスコア化することが可能である。この際、スケジュールの空き状況も考慮しても構わない。
これらに応じて例えば、価格（安いほうが高くなる偏差値）×品質（悪いと低くなるスコア）/対応スピード（遠くなるほどゆっくりあがるスコア）のような組み合わせに対して、各関数のパラメータを最適化することで、その工事にいま適した職人を１つのスコアで出すことが可能となる。

７．人間間の関連性による人間のスコア
上記分析６で「人間のスコア」を算出したが、これを複数の作業の関連性を考慮してスコア化することもできる。
メインＤＢ２２０には、項番９２〜９９の「誰が」、項番１００〜１０３の「誰に」依頼したかという作業の関連性を示す情報が記憶されている。これらの情報及び項番５７〜８３の作業の内容を用いることで、例えば、ＡからＢに「発注」をしたという情報や、ＡからＢが「情報を得た」という情報や、ＡがＢを「評価した」という情報などが取得できる。

このＡとＢの関連性を有向グラフとして持たせ数的処理を行うことで各ノードやエッジの重要性をグラフ分析することが可能である。例えば、Ｇｏｏｇｌｅ（登録商標）のpagerankの考え方により、信頼性の高いヒトからの評価は高く、逆に信頼性の低いヒトからの評価は低いものとして各ヒト間の相関を再帰計算することで、「評判の良い」入居者であるとか、「信頼できる仕事をしてくる」職人であるということを、より高い信頼性をもって知ることが可能となる。
その結果「信頼性の低い」団体の「推薦」でゴリ押しされる職人や大家や入居者や業者でなく、「信頼性の高い、もしくはみんなに信頼された」職人や大家や入居者や業者の評価値を上げる公正な評価システムを構築することが可能となる。

８．予測工期を導出
項番１０の案件ＩＤごとに、項番２２の初回作成時タイムスタンプと項番１５の完了報告ＩＤが記載された項番２１のタイムスタンプとの差分を求めることで、「実際の工期」を算出ことが可能である。
ここで各案件ごとに、項番８６の出し値（請求額）と項番９０の原価とを集計することにより、工事の規模と原価を算出することが可能である。

この実際の工期を、項番９５の作成者ＩＤ（工事を手配する担当者）でソートすることにより、案件ＩＤ、開始時期、実際の工期、担当者、出し値、原価の一覧データを算出することが可能となる。
これらの因子を分析し、担当者とその他の因子との間の相関関係があることが分かれば、例えば、担当者名を入力すると、それに応じた工期や、出し値、原価等の数値の予測値を求めることが可能となる。また、さらに時期の因子も加味して担当者と、その他の因子との間の相関関係を求めれば、担当者名と開始時期を入力することで、季節因子も加味した状態で工期や、出し値、原価等の予測値を求めることが可能となる。

９．工期と費用の傾向を導出
トランザクション情報９００に記憶された膨大な工事件数の類型化を行い、工事のタイプごとの「工期」と「費用」の傾向を導出する。例えばこれらの因子の関係が不明である場合に教師なし学習（クラスタリング）を行うことにより、季節性や他の因子の依存性によって大きく異なる工事の傾向を知ることができ、適切な工期や価格を導出することができる。

１０．異常値検出
以上のような工期と費用などの結果に対して、メインＤＢ２２０の中で結果に大きな影響を与える因子の標準的な閾値を導出し、この閾値を超えていないかを常に監視するような仕組みを作ることが可能である。

例えば「工事の手配がＸ週間以上完了していない場合は、人間が手配を忘れている」というような閾値Ｘを上記のような分析で明らかにし、メインＤＢ２２０のある項目とある項目の差分を監視し続け、これが閾値Ｘを超えた場合に、アラートを表示することができる。この仕組みでは、閾値Ｘ自体をトランザクション情報９００の分析から取得するため、実際の工事や作業で意識しなければならない値に近い閾値を設定することが可能となり、実際の人間の感覚に近いサービスを提供することが可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１０１…統合管理システム、１０２…施工管理会社端末、１０３…メーカー端末、１０４…管理会社端末、１０５…入居者端末、２１０…データ登録表示モジュール、２１１…状態判定モジュール、２１２…データ解析モジュール、２２０…メインＤＢ、２２１…ヒト関連ＤＢ、２２２…モノ関連ＤＢ、２２３…コト関連ＤＢ、５００…ヒト関連マスタ情報、６００…モノ関連マスタ情報、７００…コト関連マスタ情報、８００…フェーズ関連マスタ情報、９００…トランザクション情報、１２００…フェーズ開始終了条件情報、１３００…フェーズ進行可否判定情報

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上述の実施例は少なくとも下記を開示している。
（１）
建築物に関する情報を管理する管理サーバであって、
建築物または建築物が有する設備に関する情報であるモノ関連情報と、
人に関する情報であるヒト関連情報と、
工事内容に関する情報であるコト関連情報と、
を対応付けたトランザクション情報を記憶する記憶手段と、
複数の作業を含む工事案件について生じた事象を前記記憶手段に記憶するデータ登録手段と、
を有し、
前記データ登録手段は、所定の建築物に対する工事案件において生じた複数の事象に関する情報を、当該所定の建築物に関する前記モノ関連情報と当該工事案件に関する前記ヒト関連情報と当該工事案件に関する前記コト関連情報として対応付けて、前記複数の事象が生じた時系列に基づいて前記記憶手段の前記トランザクション情報に記憶する
ことを特徴とする管理サーバ。
（２）
（１）に記載の管理サーバであって、
前記工事案件の進捗度合を特定する状態判定手段を有し、
前記データ登録手段は、前記工事案件の複数の作業それぞれについて、各作業の状況に関する情報を前記モノ関連情報と前記ヒト関連情報と前記コト関連情報と対応付けて前記トランザクション情報に記憶し、
前記状態判定手段は、前記複数の作業の前記状況に関する情報に基づいて、前記複数の作業を含む前記工事案件の進捗度合を特定する
ことを特徴とする管理サーバ。
（３）
（２）に記載の管理サーバであって、
前記進捗度合は複数のフェーズからなり、それぞれのフェーズの開始条件と終了条件とを記憶したフェーズ開始終了条件情報を有し、
前記状態判定手段は、前記複数の作業が、現在のフェーズの終了条件を満たしている場合または次のフェーズの開始条件を満たしている場合のいずれかを満たす場合に、前記進捗度合を次のフェーズに更新する
ことを特徴とする管理サーバ。
（４）
（３）に記載の管理サーバであって、
現在のフェーズから次のフェーズへ進行してよい場合を定めるフェーズ進行可否判定情報を有し、
前記状態判定手段は、前記フェーズ進行可否判定情報に基づいて次のフェーズに進行してよい場合に、前記進捗度合を次のフェーズに更新する
ことを特徴とする管理サーバ。
（５）
（３）または（４）に記載の管理サーバであって、
前記複数のフェーズは、前記工事案件についての、依頼・調査・手配・現場作業・完了報告・請求・完了の少なくともいずれかを含む
ことを特徴とする管理サーバ。
（６）
（１）〜（５）のいずれか１項に記載の管理サーバであって、
記憶手段に記憶された前記トランザクション情報に基づく情報を表示する表示手段を有し、
前記トランザクション情報の前記モノ関連情報は、前記工事案件の対象である前記所定の建築物に対して、前記建築物を特定する情報と前記建築物の中の区画を特定する情報と前記区画の中の設備を特定する情報とを合わせて記憶しており、
前記表示手段は、前記建築物を特定する情報、前記区画を特定する情報または前記設備を特定する情報の少なくとも一つの情報をキーとして、前記トランザクション情報を検索し、同一のキーを持つ工事内容に関する情報を取得し、表示する
ことを特徴とする管理サーバ。
（７）
（６）に記載の管理サーバであって、
前記トランザクション情報の前記コト関連情報は、前記所定の設備に関連する写真データを合わせて記憶しており、
前記表示手段は、前記トランザクション情報を検索し、同一の前記設備を特定する情報を持つ前記写真データを取得し、同一の前記設備に関連する写真データを時系列で複数表示する
ことを特徴とする管理サーバ。
（８）
（７）に記載の管理サーバであって、
前記表示手段は、現場調査と関連付けて記憶された前記所定の設備に関する写真データと、現場調査後に実施された工事と関連付けて記憶された前記所定の設備に関する写真データと、を比較可能な状態で表示する
ことを特徴とする管理サーバ。
（９）
（１）〜（８）のいずれか１項に記載の管理サーバであって、
前記表示手段は、
前記工事案件の前記複数の作業それぞれに要する期間に関する情報を、前記トランザクション情報から取得し、
取得された前記期間に関する情報に基づいて、前記複数の作業を線表の上に表示する
ことを特徴とする管理サーバ。
（１０）
建築物に関する情報を管理する管理サーバにおける情報管理方法であって、
前記管理サーバは、
建築物または建築物が有する設備に関する情報であるモノ関連情報と、
人に関する情報であるヒト関連情報と、
工事内容に関する情報であるコト関連情報と、
を対応付けたトランザクション情報を記憶する記憶手段と、
を有しており、
所定の建築物に対する工事案件において生じた複数の事象に関する情報を、当該所定の建築物に関する前記モノ関連情報と当該工事案件に関する前記ヒト関連情報と当該工事案件に関する前記コト関連情報として対応付けて、前記複数の事象が生じた時系列に基づいて前記記憶手段の前記トランザクション情報に記憶する
ことを特徴とする情報管理方法。
（１１）
（１０）に記載の情報管理方法であって、
前記トランザクション情報は、前記工事案件が有する複数の作業それぞれについて、各作業の状況に関する情報を前記モノ関連情報と前記ヒト関連情報と前記コト関連情報と対応付けて記憶しており、
前記複数の作業の前記状況に関する情報に基づいて、前記複数の作業を含む前記工事案件の進捗度合を特定する
ことを特徴とする情報管理方法。
（１２）
（１１）に記載の情報管理方法であって、
前記進捗度合は複数のフェーズからなり、前記記憶手段はそれぞれのフェーズの開始条件と終了条件とを記憶したフェーズ開始終了条件情報を有しており、
前記複数の作業が、現在のフェーズの終了条件を満たしている場合または次のフェーズの開始条件を満たしている場合のいずれかを満たす場合に、前記進捗度合を次のフェーズに更新する
ことを特徴とする情報管理方法。
（１３）
（１２）に記載の情報管理方法であって、
前記記憶手段は現在のフェーズから次のフェーズへ進行してよい場合を定めるフェーズ進行可否判定情報を有しており、
前記フェーズ進行可否判定情報に基づいて次のフェーズに進行してよい場合に、前記進捗度合を次のフェーズに更新する
ことを特徴とする情報管理方法。
（１４）
（１２）または（１３）に記載の情報管理方法であって、
前記複数のフェーズは、前記工事案件についての、依頼・調査・手配・現場作業・完了報告・請求・完了の少なくともいずれかを含む
ことを特徴とする情報管理方法。
（１５）
（１０）〜（１４）のいずれか１項に記載の情報管理方法であって、
前記トランザクション情報の前記モノ関連情報は、前記工事案件の対象である前記所定の建築物に対して、前記建築物を特定する情報と前記建築物の中の区画を特定する情報と前記区画の中の設備を特定する情報とを合わせて記憶しており、
前記建築物を特定する情報、前記区画を特定する情報または前記設備を特定する情報の少なくとも一つの情報をキーとして、前記トランザクション情報を検索し、同一のキーを持つ工事内容に関する情報を取得し、表示する
ことを特徴とする情報管理方法。
（１６）
（１５）に記載の情報管理方法であって、
前記トランザクション情報の前記コト関連情報は、前記所定の設備に関連する写真データを合わせて記憶しており、
前記トランザクション情報を検索し、同一の前記設備を特定する情報を持つ前記写真データを取得し、同一の前記設備に関連する写真データを時系列で複数表示する
ことを特徴とする情報管理方法。
（１７）
（１６）に記載の情報管理方法であって、
現場調査と関連付けて記憶された前記所定の設備に関する写真データと、現場調査後に実施された工事と関連付けて記憶された前記所定の設備に関する写真データと、を比較可能な状態で表示する
ことを特徴とする情報管理方法。
（１８）
（１０）〜（１７）のいずれか１項に記載の情報管理方法であって、
前記工事案件の前記複数の作業それぞれに要する期間に関する情報を、前記トランザクション情報から取得し、
取得された前記期間に関する情報に基づいて、前記複数の作業を線表の上に表示する
ことを特徴とする情報管理方法。
（１９）
建築物に関する情報を管理する管理サーバを実現させるためのプログラムであって、
前記管理サーバに（１０）〜（１８）のいずれか１項に記載の情報管理方法の各ステップを実行させるためのプログラム。

Claims (19)

1. 建築物に関する情報を管理する管理サーバであって、
   建築物または建築物が有する設備に関する情報であるモノ関連情報と、
   人に関する情報であるヒト関連情報と、
   工事内容に関する情報であるコト関連情報と、
   を対応付けたトランザクション情報を記憶する記憶手段と、
   複数の作業を含む工事案件について生じた事象を前記記憶手段に記憶するデータ登録手段と、
   を有し、
   前記データ登録手段は、所定の建築物に対する工事案件において生じた複数の事象に関する情報を、当該所定の建築物に関する前記モノ関連情報と当該工事案件に関する前記ヒト関連情報と当該工事案件に関する前記コト関連情報として対応付けて、前記複数の事象が生じた時系列に基づいて前記記憶手段の前記トランザクション情報に記憶する
   ことを特徴とする管理サーバ。
2. 請求項１に記載の管理サーバであって、
   前記工事案件の進捗度合を特定する状態判定手段を有し、
   前記データ登録手段は、前記工事案件の複数の作業それぞれについて、各作業の状況に関する情報を前記モノ関連情報と前記ヒト関連情報と前記コト関連情報と対応付けて前記トランザクション情報に記憶し、
   前記状態判定手段は、前記複数の作業の前記状況に関する情報に基づいて、前記複数の作業を含む前記工事案件の進捗度合を特定する
   ことを特徴とする管理サーバ。
3. 請求項２に記載の管理サーバであって、
   前記進捗度合は複数のフェーズからなり、それぞれのフェーズの開始条件と終了条件とを記憶したフェーズ開始終了条件情報を有し、
   前記状態判定手段は、前記複数の作業が、現在のフェーズの終了条件を満たしている場合または次のフェーズの開始条件を満たしている場合のいずれかを満たす場合に、前記進捗度合を次のフェーズに更新する
   ことを特徴とする管理サーバ。
4. 請求項３に記載の管理サーバであって、
   現在のフェーズから次のフェーズへ進行してよい場合を定めるフェーズ進行可否判定情報を有し、
   前記状態判定手段は、前記フェーズ進行可否判定情報に基づいて次のフェーズに進行してよい場合に、前記進捗度合を次のフェーズに更新する
   ことを特徴とする管理サーバ。
5. 請求項３または４に記載の管理サーバであって、
   前記複数のフェーズは、前記工事案件についての、依頼・調査・手配・現場作業・完了報告・請求・完了の少なくともいずれかを含む
   ことを特徴とする管理サーバ。
6. 請求項１〜５のいずれか１項に記載の管理サーバであって、
   記憶手段に記憶された前記トランザクション情報に基づく情報を表示する表示手段を有し、
   前記トランザクション情報の前記モノ関連情報は、前記工事案件の対象である前記所定の建築物に対して、前記建築物を特定する情報と前記建築物の中の区画を特定する情報と前記区画の中の設備を特定する情報とを合わせて記憶しており、
   前記表示手段は、前記建築物を特定する情報、前記区画を特定する情報または前記設備を特定する情報の少なくとも一つの情報をキーとして、前記トランザクション情報を検索し、同一のキーを持つ工事内容に関する情報を取得し、表示する
   ことを特徴とする管理サーバ。
7. 請求項６に記載の管理サーバであって、
   前記トランザクション情報の前記コト関連情報は、前記所定の設備に関連する写真データを合わせて記憶しており、
   前記表示手段は、前記トランザクション情報を検索し、同一の前記設備を特定する情報を持つ前記写真データを取得し、同一の前記設備に関連する写真データを時系列で複数表示する
   ことを特徴とする管理サーバ。
8. 請求項７に記載の管理サーバであって、
   前記表示手段は、現場調査と関連付けて記憶された前記所定の設備に関する写真データと、現場調査後に実施された工事と関連付けて記憶された前記所定の設備に関する写真データと、を比較可能な状態で表示する
   ことを特徴とする管理サーバ。
9. 請求項１〜８のいずれか１項に記載の管理サーバであって、
   前記表示手段は、
   前記工事案件の前記複数の作業それぞれに要する期間に関する情報を、前記トランザクション情報から取得し、
   取得された前記期間に関する情報に基づいて、前記複数の作業を線表の上に表示する
   ことを特徴とする管理サーバ。
10. 建築物に関する情報を管理する管理サーバにおける情報管理方法であって、
    前記管理サーバは、
    建築物または建築物が有する設備に関する情報であるモノ関連情報と、
    人に関する情報であるヒト関連情報と、
    工事内容に関する情報であるコト関連情報と、
    を対応付けたトランザクション情報を記憶する記憶手段と、
    を有しており、
    所定の建築物に対する工事案件において生じた複数の事象に関する情報を、当該所定の建築物に関する前記モノ関連情報と当該工事案件に関する前記ヒト関連情報と当該工事案件に関する前記コト関連情報として対応付けて、前記複数の事象が生じた時系列に基づいて前記記憶手段の前記トランザクション情報に記憶する
    ことを特徴とする情報管理方法。
11. 請求項１０に記載の情報管理方法であって、
    前記トランザクション情報は、前記工事案件が有する複数の作業それぞれについて、各作業の状況に関する情報を前記モノ関連情報と前記ヒト関連情報と前記コト関連情報と対応付けて記憶しており、
    前記複数の作業の前記状況に関する情報に基づいて、前記複数の作業を含む前記工事案件の進捗度合を特定する
    ことを特徴とする情報管理方法。
12. 請求項１１に記載の情報管理方法であって、
    前記進捗度合は複数のフェーズからなり、前記記憶手段はそれぞれのフェーズの開始条件と終了条件とを記憶したフェーズ開始終了条件情報を有しており、
    前記複数の作業が、現在のフェーズの終了条件を満たしている場合または次のフェーズの開始条件を満たしている場合のいずれかを満たす場合に、前記進捗度合を次のフェーズに更新する
    ことを特徴とする情報管理方法。
13. 請求項１２に記載の情報管理方法であって、
    前記記憶手段は現在のフェーズから次のフェーズへ進行してよい場合を定めるフェーズ進行可否判定情報を有しており、
    前記フェーズ進行可否判定情報に基づいて次のフェーズに進行してよい場合に、前記進捗度合を次のフェーズに更新する
    ことを特徴とする情報管理方法。
14. 請求項１２または１３に記載の情報管理方法であって、
    前記複数のフェーズは、前記工事案件についての、依頼・調査・手配・現場作業・完了報告・請求・完了の少なくともいずれかを含む
    ことを特徴とする情報管理方法。
15. 請求項１０〜１４のいずれか１項に記載の情報管理方法であって、
    前記トランザクション情報の前記モノ関連情報は、前記工事案件の対象である前記所定の建築物に対して、前記建築物を特定する情報と前記建築物の中の区画を特定する情報と前記区画の中の設備を特定する情報とを合わせて記憶しており、
    前記建築物を特定する情報、前記区画を特定する情報または前記設備を特定する情報の少なくとも一つの情報をキーとして、前記トランザクション情報を検索し、同一のキーを持つ工事内容に関する情報を取得し、表示する
    ことを特徴とする情報管理方法。
16. 請求項１５に記載の情報管理方法であって、
    前記トランザクション情報の前記コト関連情報は、前記所定の設備に関連する写真データを合わせて記憶しており、
    前記トランザクション情報を検索し、同一の前記設備を特定する情報を持つ前記写真データを取得し、同一の前記設備に関連する写真データを時系列で複数表示する
    ことを特徴とする情報管理方法。
17. 請求項１６に記載の情報管理方法であって、
    現場調査と関連付けて記憶された前記所定の設備に関する写真データと、現場調査後に実施された工事と関連付けて記憶された前記所定の設備に関する写真データと、を比較可能な状態で表示する
    ことを特徴とする情報管理方法。
18. 請求項１０〜１７のいずれか１項に記載の情報管理方法であって、
    前記工事案件の前記複数の作業それぞれに要する期間に関する情報を、前記トランザクション情報から取得し、
    取得された前記期間に関する情報に基づいて、前記複数の作業を線表の上に表示する
    ことを特徴とする情報管理方法。
19. 建築物に関する情報を管理する管理サーバを実現させるためのプログラムであって、
    前記管理サーバに請求項１０〜１８のいずれか１項に記載の情報管理方法の各ステップを実行させるためのプログラム。

Images