JP2003288457A - データ管理システムおよびデータ管理システムに利用可能なオブジェクトリポジトリサーバ - Google Patents

Abstract

(57)【要約】 【課題】 工事の一連の作業に関するデータを効率よく
管理する技術が求められていた。 【解決手段】 一連の細分化した作業に関するデータを
管理するオブジェクトリポジトリサーバ１００は、作業
工程における予定成果物を属性情報として持つ工程イン
スタンスを格納する工程データベース１６２と、作業に
関わる業者をそれぞれ業者インスタンスとして格納する
業者データベース１６４と、工程インスタンスと業者イ
ンスタンスとの関連を保持する第２関連保持部１６８と
を備える。出来高受付部１１０は、業者端末から出来高
に関する報告を受け付け、処理部１１２は、出来高に関
する報告を、業者端末、管理サーバまたは機関サーバの
少なくとも一者から確認可能な状態にせしめ、検査結果
受付部１２０は、管理サーバより、出来高が予定成果物
をどの程度満足しているかの検査結果を受け付ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ管理技術に
関する。とくに、本発明は、一連の細分化した作業に関
するデータを管理するデータ管理システム、およびその
データ管理システムに利用可能なオブジェクトリポジト
リサーバに関する。

【０００２】

【従来の技術】工事を実施するにあたり、その工事は施
主から施工業者へ一括発注されることが多い。とくに、
ビルの建築など、比較的規模の大きい建設工事では、施
主側の要求をもとに作成された設計図面を複数の総合建
設業者、いわゆるゼネコン（general contractor）に提
示した上で、最も安い見積もりを出したゼネコンに工事
を一括発注する方式が一般的である。工事を受注したゼ
ネコンは、実際の工事における各工程を請け負う下請け
の専門工事業者を選定し、各工程を専門工事業者に発注
し、工事全体が円滑に進むように、それぞれの工程の工
期などを管理する。

【０００３】

【発明が解決しようとする課題】このような、一括発注
方式について、様々な問題点が指摘されている。たとえ
ば、施主側から見ると、各専門工事業者の選定をゼネコ
ンに任せるのではなく、より低価格でかつ質の高い専門
工事業者を選定して、効率良く工事を進めたいという要
望がある。また、工事費の明細は必ずしも明確ではな
く、透明性の高い発注方式が求められている。施工業者
側から見ると、一括発注方式では工事費は完成時に一括
払いされるか、せいぜい施工前、施工中、完成時の３回
に分割して支払われる程度であるため、施工開始から入
金までに相当の時間差があるという問題がある。このキ
ャッシュフローの問題は、とくに中小規模の施工業者に
とっては死活問題となりかねず、施工に伴う出費に追随
して、できる限り前倒しで入金を受けたいという要望が
ある。

【０００４】そこで、本発明は、上記の課題を解決する
ことのできるデータ管理システム、およびそのデータ管
理システムに利用可能なオブジェクトリポジトリサーバ
を提供することを目的とする。

【０００５】

【課題を解決するための手段】上記目的を達成するため
に、本発明の第１の形態に係るデータ管理システムは、
一連の細分化した作業に関するデータを管理するオブジ
ェクトリポジトリサーバと、作業の出来高を該オブジェ
クトリポジトリサーバに報告する業者端末と、作業の出
来高に関する検査結果を該オブジェクトリポジトリサー
バに報告する管理サーバと、支払業務を行う金融機関な
どにより管理される機関サーバとがネットワークによっ
て接続されているデータ管理システムであって、前記オ
ブジェクトリポジトリサーバは、細分化した作業工程を
順序付けてそれぞれ工程インスタンスとして格納し且つ
各作業工程において予め定められた予定成果物を属性情
報として該工程インスタンスに対応付けて格納する工程
データベース部と、作業に関わる業者をそれぞれ業者イ
ンスタンスとして格納する業者データベース部と、工程
インスタンスと業者インスタンスとの関連を保持する関
連保持部と、業者端末から出来高に関する報告を受け付
ける出来高受付部と、前記出来高に関する報告を、業者
端末、管理サーバまたは機関サーバの少なくとも一者か
ら確認可能な状態にせしめる処理部と、出来高に関する
報告を受け付けたことを管理サーバまたは機関サーバの
少なくとも一者に伝える伝達部と、管理サーバより、該
出来高が予定成果物をどの程度満足しているかの検査結
果を受け付ける検査結果受付部と、この検査結果を機関
サーバに送信する検査結果送信部とを備える。

【０００６】作業を細分化し、それぞれの工程について
施工業者に出来高を報告させ、その報告を関係者が確認
可能とすることで、工事の透明性および作業の質の信頼
性を向上させることができる。このようなきめ細かい工
程管理には、膨大なデータを効率よく処理可能なデータ
管理技術が必須であるが、このデータ管理にはデータ量
の観点からオブジェクトリポジトリ技術が好適である。

【０００７】前記機関サーバは、検査結果送信部より送
信される検査結果を受けて、該出来高に対する支払業務
を遂行可能な状態としてもよい。これにより、支払業務
を行う金融機関等は、工事完了時の一括払いだけではな
く、工事の途中であってもその時点までに完了している
出来高に応じて支払を行うことができ、また、完了して
いない工程についての支払を回避することができる。

【０００８】前記オブジェクトリポジトリサーバは、管
理サーバにより検査された出来高に対応して支払うべき
金額を施工業者ごとに集約する金額集約部と、集約した
金額を管理サーバまたは機関サーバに対して所定のタイ
ミングで送信する金額送信部とを備えてもよい。前記機
関サーバは、オブジェクトリポジトリサーバまたは管理
サーバから、集約した金額を受け付ける金額受付部と、
所定のタイミングで、この金額を施工業者に対して支払
う支払処理部とを備えてもよい。これにより、金融機関
等における施工業者への支払業務を自動化し、同一の施
工業者への支払を一括して行うことができるので、金融
機関等の支払業務の負荷を軽減することができる。

【０００９】本発明の第２の形態に係るオブジェクトリ
ポジトリサーバは、一連の細分化した作業に関するデー
タを管理するオブジェクトリポジトリサーバであって、
細分化した作業工程を順序付けてそれぞれ工程インスタ
ンスとして格納し且つ各作業工程において予め定められ
た予定成果物を属性情報として該工程インスタンスに対
応付けて格納する工程データベース部と、作業に関わる
業者をそれぞれ業者インスタンスとして格納する業者デ
ータベース部と、工程インスタンスと業者インスタンス
との関連を保持する関連保持部と、業者端末から出来高
に関する報告を受け付ける出来高受付部と、前記出来高
に関する報告を、支払業務を行う金融機関などに設けら
れた機関端末から確認可能な状態にせしめる処理部とを
備える。

【００１０】オブジェクトリポジトリサーバは、該出来
高が予定成果物をどの程度満足しているかの検査結果を
外部から受け付ける検査結果受付部と、この検査結果
を、前記機関端末に送信する検査結果送信部とを備えて
もよい。検査された出来高に対応して支払うべき金額を
業者ごとに集約する金額集約部を備えてもよい。

【００１１】本発明の第３の形態に係るオブジェクトリ
ポジトリサーバは、一連の細分化した作業に関するデー
タを管理するオブジェクトリポジトリサーバであって、
作業計画のバージョンをそれぞれ計画インスタンスとし
て格納する計画データベース部と、細分化した作業工程
を順序付けてそれぞれ工程インスタンスとして格納する
工程データベース部と、作業に関わる業者をそれぞれ業
者インスタンスとして格納する業者データベース部と、
計画インスタンスと工程インスタンスとの関連を保持す
る第１関連保持部と、工程インスタンスと業者インスタ
ンスとの関連を保持する第２関連保持部と、作業工程に
変更があった場合に、新たな計画インスタンスを生成す
る計画インスタンス生成部と、変更された作業工程に対
応する新たな工程インスタンスを生成する工程インスタ
ンス生成部と、新たな計画インスタンスに、新たな工程
インスタンス、および変更された作業工程以降の作業工
程に対応する工程インスタンスを関連付ける関連生成部
とを備え、第１関連保持部は、関連生成部により生成さ
れた関連を保持する。これにより、計画変更が頻繁に行
われても、それに伴うデータ量の増大を最小限に抑えつ
つ、効率的な作業計画のバージョン管理を実現すること
ができる。

【００１２】本発明の第４の形態に係るオブジェクトリ
ポジトリサーバは、一連の細分化した作業に関するデー
タを管理するオブジェクトリポジトリサーバであって、
作業計画のバージョンをそれぞれ計画インスタンスとし
て格納する計画データベース部と、細分化した作業工程
を順序付けてそれぞれ工程インスタンスとして格納する
工程データベース部と、作業に関わる業者をそれぞれ業
者インスタンスとして格納する業者データベース部と、
計画インスタンスと工程インスタンスとの関連を保持す
る第１関連保持部と、工程インスタンスと業者インスタ
ンスとの関連を保持する第２関連保持部と、ある作業工
程に携わる業者に変更があった場合に、新たな計画イン
スタンスを生成する計画インスタンス生成部と、業者が
変更された作業工程に対応する新たな工程インスタンス
を生成する工程インスタンス生成部と、新たな計画イン
スタンスに、新たな工程インスタンス、および変更され
た作業工程以降の作業工程に対応する工程インスタンス
を関連付ける第１関連生成部と、新たな工程インスタン
スに、変更後の業者に対応する業者インスタンスを関連
付ける第２関連生成部とを備え、第１関連保持部は、第
１関連生成部により生成された関連を保持し、第２関連
保持部は、第２関連生成部により生成された関連を保持
する。これにより、業者の変更に伴うデータ量の増大を
最小限に抑えつつ、効率的な作業計画のバージョン管理
を実現することができる。

【００１３】なお、上記の発明の概要は、本発明の必要
な特徴の全てを列挙したものではなく、これらの特徴の
組合わせも又発明となりうる。また、本発明の表現を装
置、方法、システム、コンピュータプログラムの間で変
換したものもまた、本発明の態様として有効である。

【００１４】

【発明の実施の形態】従来の一括発注方式の問題点を踏
まえ、プロジェクト・マネジメント（Project Manageme
nt：以下、「ＰＭ」とも表記する）と呼ばれる方式が提
案されている。この方式では、工事に必要な作業を複数
の工程に細分化し、発注者である施主がそれぞれの工程
ごとに専門工事業者と直接契約し、工事を発注する。こ
のような分割発注方式により、工程ごとに作業内容と価
格が明確になり、中間マージンなどのコストが削減され
るとともに、発注者はより低価格で高品質の施工業者を
選択することができるようになる。

【００１５】通常、施主は様々な専門工事業者を的確に
選定するために必要な情報や知識を持っておらず、各専
門工事業者の作業範囲と責任範囲を予め決定し明示した
り、施工時に全体の進行と現場の作業管理を行ったりと
いった、従来ゼネコンが担っていた管理業務を行うこと
は困難である。そのため、ＰＭ方式では、このような管
理業務を、建設コンサルタントや建築士など、建設工事
の専門家により構成されるコンストラクション・マネー
ジャ（Construction Manager：以下、「ＣＭ」とも表記
する）に有料で委託する。高度な知識とノウハウを持つ
ＣＭが工事全体を管理することで、建設プロジェクトの
コスト低減、品質向上、円滑なスケジューリングを実現
することができる。また、発注者と施工業者の間に第三
者機関としてＣＭが介入することで、工事の透明性およ
び信頼性を向上させることにもつながる。

【００１６】このようなＰＭ方式を採用した建設プロジ
ェクトにおいて、発注者と受注者の双方の信用を補完す
る新たな決済サービスとして、金融機関などによるエス
クローサービスが注目を集めるようになっている。これ
は、金融機関などのエスクローサービス事業者（以下、
単に「エスクロー事業者」ともいう）が発注者と受注者
の間にたち、発注者から予め委託を受け、発注者が発注
した発注内容が受注者により適切に実施されたことを確
認した後、発注者に代わって受注者に代金を支払うサー
ビスである。エスクロー事業者は、工事の各工程が適切
に施工されたことを検証する技術を必ずしも持っていな
いが、前述のＣＭは、高い専門知識を有する第三者機関
であるから、ＣＭの検査結果を取得することで、施工状
況を的確に検証し、把握することができる。このよう
に、ＰＭ方式において、ＣＭが建設プロジェクト全体を
管理することにより、エスクロー事業者はリスクの少な
いエスクローサービスを提供することができる。

【００１７】ＰＭ方式では、建設プロジェクトを複数の
工程に細分化して管理するが、この工程ごとに支払いが
行われれば、とくに受注者である施工業者にとって利点
が大きい。さらに、工程の終了ごとに支払いが行われる
だけでなく、たとえば月ごとに進捗状況を検証し、出来
高に応じて支払いが行われれば、施工業者の経済的負担
が大幅に軽減される。施工業者の経済的負担が減り、中
小規模の施工業者が工事の入札に参加できるようになる
と、品質、価格、納期などに関する競争原理が機能し、
その結果、安価で質の高い工事が実施されるようになる
など、発注者にとっても利点が大きい。

【００１８】従来、このような出来高払いが行われなか
ったのは、ＣＭのような信頼性の高い第三者機関が存在
せず、施工状況を客観的に検証することが困難であった
ためと考えられる。それぞれの立場からすると、まず、
発注者側にとっては、完了した工程までの代金は支払っ
てもよいが、未着手の工程分の代金を過剰に支払うこと
は避けたいところである。たとえば、公共事業の場合は
納税者への説明責任があるし、発注者が株式会社である
場合は株主への説明責任があるから、検証なしに代金を
支払うことはできない。また、エスクロー事業者側にと
っても、同様に、未完成分の代金を支払うことは避けた
いところである。

【００１９】本実施の形態では、工程ごとの支払い、ま
たは期間ごとの支払いの実現に不可欠な、公正かつ定量
的な進捗状況の検証は、ＣＭにより実現される。しかし
ながら、従来、このような支払方法が困難であったもう
一つの理由に、工程ごとの進捗状況および出来高を厳密
に管理するための管理コストおよび人的管理工数の増大
が挙げられる。工程管理の電子化、自動化を図り、管理
コストおよび管理工数を軽減するためには、膨大な作業
データを効率的に管理するためのデータ管理手法が不可
欠である。

【００２０】本実施の形態では、工程ごと、または期間
ごとの決済が可能なエスクローサービスを実現するため
の作業データの管理に、オブジェクトリポジトリデータ
ベースを活用する。以下、本実施の形態のデータ管理シ
ステムによる工事の管理手法について説明した後、オブ
ジェクトリポジトリデータベースを用いたシステムが、
従来のリレーショナルデータベースを用いたシステムよ
りも優れている点について説明する。

【００２１】図１は、本実施の形態に係るデータ管理シ
ステムの全体構成を示す図である。データ管理システム
１０において、工事の発注者の端末３０、工事の受注者
である施工業者の端末５０、発注者および施工業者に対
してエスクローサービスを提供するエスクロー事業者の
機関サーバ４０、工事を統括的に管理するコンストラク
ション・マネージャ（ＣＭ）の管理サーバ６０、および
一連の細分化した作業に関するデータを管理するオブジ
ェクトリポジトリサーバ１００が、インターネット２０
に接続されている。オブジェクトリポジトリサーバ１０
０は、ＣＭにより直接管理されてもよいし、ＣＭから委
託を受けたデータ管理会社により運営されてもよい。発
注者端末３０、機関サーバ４０、業者端末５０、管理サ
ーバ６０は、それぞれ、インターネット２０を介してオ
ブジェクトリポジトリサーバ１００にアクセスし、ＷＷ
Ｗ（World Wide Web）などの技術を利用して工事の管理
に必要なデータを登録し、また、登録されたデータを閲
覧する。以下、発注者というとき、発注者自身と発注者
の端末をとくに区別しない。同様に、エスクロー事業者
とそのサーバを、施工業者とその端末を、ＣＭとその管
理サーバを、それぞれ区別せずに用い、端末またはサー
バと、その所有主体に対して、同一の符号を付すことが
ある。

【００２２】図２は、発注者が工事を企画してから工事
が開始されるまでの手順を概略的に示す。まず、発注者
３０が工事を企画し（１）、その工事の管理業務をＣＭ
６０に委託する（２）。ＣＭ６０は、発注者３０ととも
に工事の内容を検討し、工事に必要な作業を複数の工程
に細分化して、それぞれの工程について、予算、施工業
者、工程完了時に得られると予定される成果物などを決
定する（３）。この詳細については後述する。つづい
て、ＣＭ６０は、決定した施工業者５０に対して、工事
を工程ごとに発注し（４）、各工程に関するデータをオ
ブジェクトリポジトリサーバ１００内のデータベースに
登録する（５）。発注者３０および施工業者５０ｘ、５
０ｙ、および５０ｚは、それぞれ、エスクロー事業者４
０とエスクローサービスに関する契約を締結する（６、
７）。このとき、エスクロー事業者４０は、発注者３０
から資金の寄託を受けてもよい。必要であれば、エスク
ロー事業者４０は発注者３０に対して融資を行う。

【００２３】図３は、工事の一連の作業が細分化される
様子を説明するための図である。まず、作業内容の観点
から作業を階層的に区分して、作業ワークブレークダウ
ンストラクチャ（Work Breakdown Structure：以下、
「ＷＢＳ」とも表記する）を定義する。つづいて、構築
物の部位の観点から作業を階層的に区分して、部位ＷＢ
Ｓを定義する。作業ＷＢＳおよび部位ＷＢＳでは、それ
ぞれ、管理単位として適切なレベルまで作業が細分化さ
れる。そして、作業ＷＢＳを横軸に、部位ＷＢＳを縦軸
にとったマトリクスを構成し、それらの交点をワークパ
ッケージ（Work Package：以下、「ＷＰ」とも表記す
る）と定義する。たとえば、ＷＰ１は、部位が「下水処
理場／共通施設／管理施設」で、作業内容が「建設工事
／新設工事／土木工事／基礎工」の工程にあたる。以
下、このＷＰごとに工程が管理される。このように、作
業を細分化して管理することで、きめ細かい工程管理が
可能となる。各ＷＰは、後述するように、工程インスタ
ンスとしてオブジェクトリポジトリサーバ１００に登録
される。

【００２４】作業がＷＰに細分化されると、それぞれの
ＷＰごとに予定成果物と予算が定義される。予定成果物
は、その工程の終了時に得られると予定される成果物で
あり、たとえば、設計工程では設計図などであってもよ
いし、配管工程では管が正しく配管された状態であって
もよい。また、進捗状況を定量的に表現するために、た
とえば、配管工程の予定成果物を配管した管の長さなど
で表現してもよい。予算は、その工程について発注者か
ら受注者へ支払われる予定対価である。これは、後述す
る出来高払いの際に、支払額を算出するためにも用いら
れる。このように、ＷＰごとに予定成果物および予算を
定義しておくことで、工事費の内訳が明確になるととも
に、工程が終了するごとに、または所定のタイミングご
とに出来高に応じた対価を評価して、施工業者への支払
を実行することができる。予定成果物および予算は、そ
のＷＰの情報が格納された工程インスタンスの属性情報
として、オブジェクトリポジトリサーバ１００に登録さ
れる。

【００２５】図４は、ＣＭ６０が工事計画に関するデー
タをオブジェクトリポジトリサーバ１００に登録するた
めの登録画面の例を示す。本実施の形態のオブジェクト
リポジトリサーバ１００は、ウェブサーバとしての機能
も有しており、登録画面をウェブページとして管理サー
バ６０に提示し、ＣＧＩ（Common Gateway Interface）
などの機能を利用して管理サーバ６０からＷＰの情報を
受け付ける。オブジェクトリポジトリサーバ１００は、
後述するように、作業計画のバージョンを計画インスタ
ンスとして、ＷＰを工程インスタンスとして、施工業者
の情報を業者インスタンスとして、それぞれ格納する。

【００２６】図５は、工事が開始されてから工事が完了
するまでの手順を概略的に示す図である。施工業者５０
は、担当するＷＰの施工を実施し（８）、所定のタイミ
ングごとに、またはその工程の終了時に、出来高に関す
る報告をオブジェクトリポジトリサーバ１００に登録す
る（９）。出来高に関する報告は、工程の進捗状況また
は工程終了時に納品された納品物の状況を示す情報であ
り、たとえば、現場の写真、作業日報、使用した原料の
量、構築された建造物の状態、などの情報であってもよ
い。この出来高に関する報告は、施工業者５０への出来
高払いの根拠となる情報であるから、工程ごとにその進
捗状況を立証するにふさわしい情報が選定されて登録さ
れるのが好ましい。オブジェクトリポジトリサーバ１０
０は、施工業者５０から出来高に関する報告の登録を受
け付けると、その旨を自動的にＣＭ６０に通知する（１
０）。

【００２７】ＣＭ６０は、オブジェクトリポジトリサー
バ１００に登録された出来高に関する報告をチェック
し、必要であれば現場で検査を実施し、現在の出来高が
予定成果物をどの程度満足しているかを査定し（１
１）、その検査結果を発注者３０に報告する（１２）。
発注者３０が、ＣＭ６０から受けた検査結果を承認する
と（１３）、ＣＭ６０は検査結果をオブジェクトリポジ
トリサーバ１００に登録する（１４）。オブジェクトリ
ポジトリサーバ１００は、ＣＭ６０から検査結果が登録
されると、その旨を自動的に施工業者５０およびエスク
ロー事業者４０に通知する（１５）。

【００２８】施工業者５０は、オブジェクトリポジトリ
サーバ１００に登録された検査結果を取得し、その検査
結果に基づいて算出された対価をＣＭ６０に請求する
（１６）。ＣＭ６０は、発注者３０に代わって、エスク
ロー事業者４０に施工の対価の支払を依頼する（１
７）。エスクロー事業者４０は、ＣＭ６０からの支払依
頼を受けて、オブジェクトリポジトリサーバ１００に登
録された検査結果を参照し、支払額が妥当であると判断
した場合は、発注者３０に代わって施工の対価を施工業
者５０に支払う（１８）。エスクロー事業者４０は、発
注者３０から資金の寄託を受けている場合は、その資金
から施工の対価を支払ってもよい。資金の寄託を受けて
いない場合は、施工の対価を立て替えて施工業者５０に
支払い、所定のタイミングで発注者３０から回収しても
よい。また、エスクロー事業者４０は、単に発注者３０
に代わって金融機関などに支払指示を出すだけであって
もよく、エスクローサービスには様々な契約形態が採用
され得る。以上の手順がＷＰごとに繰り返されて工事が
進む。

【００２９】上記ステップ１８における支払のタイミン
グは、ＷＰの工程が完了した時点であってもよいし、所
定の期間ごと、たとえば、月ごと、半期ごとなどであっ
てもよい。工程完了時に支払を行う場合は、施工業者５
０は、出来高に関する報告として、完成した納品物に関
する情報を登録し、ＣＭ６０は、その納品物が予定成果
物を満足しているか、または満足していなくても同等と
認められるかを検査する。所定の期間ごとに支払を行う
場合は、施工業者５０は、出来高に関する報告として、
その期間に行った工事の進捗状況に関する情報を登録
し、ＣＭ６０は、その進捗状況が予定成果物をどの程度
満足しているか、たとえば何％進捗したかを検査する。
支払額は、この検査結果に基づいて算出されてもよい。
たとえば、工程完了時に支払を行う場合、計画通りに施
工が進んだときは支払額を予算と同額としてもよいし、
納品物の質が予定よりも悪ければ支払額を予算よりも低
くしてもよいし、工期の延長または原料の追加などがあ
ったときは支払額を予算よりも高くしてもよい。所定の
期間ごとに支払を行う場合は、進捗状況に応じて支払額
を算出してもよい。たとえば予定の５０％の施工が終了
しているという検査結果が出たときは、支払額を予算の
５０％としてもよい。これにより、施工の進捗に応じて
適切な支払額を設定することができるので、発注者３０
およびエスクロー事業者４０が未施工分の対価を支払う
リスクを軽減することが可能となる。

【００３０】施工業者５０が同一の工事における複数の
ＷＰを担当していた場合、または同一のオブジェクトリ
ポジトリサーバ１００によって管理される複数の工事の
ＷＰを担当していた場合は、オブジェクトリポジトリサ
ーバ１００は、その施工業者５０に支払うべき金額を集
約してもよい。集約した金額をエスクロー事業者４０に
送信することで、エスクロー事業者４０は一括して施工
業者５０に支払を行うことができるので、エスクロー事
業者４０の人的工数およびコストを軽減することができ
る。

【００３１】上記の例では、主に、発注者が施主自身で
ある場合、すなわち施主が複数の施工業者と直接契約を
締結し、それぞれの施工業者に対してエスクローサービ
スにより支払を行う場合について説明した。しかし、現
実には、大規模な工事を実施するにあたり、施主はゼネ
コンなどの大手建設業者と契約を結び、大手建設業者が
必要に応じて下請けの施工業者に工程の一部または全部
を発注し、ゼネコンから受注した下請け業者が必要に応
じてさらに孫請けの施工業者に工程の一部または全部を
発注するといった、階層的な請負関係により工事が実施
されることがある。このような場合であっても、本実施
の形態のデータ管理システム１０によりエスクローサー
ビスを提供することができる。

【００３２】図６は、施工業者間に階層的な請負関係が
ある場合のエスクローサービスの形態の例を示す。図６
に示した例では、施主７０はゼネコン８０に工事を発注
し、ゼネコン８０は施工業者５０ａに工事の一部または
全部の工程を発注し、施工業者５０ａは受注した工程の
一部または全部を施工業者５０ｂに発注する。ＣＭ６０
は、これらの階層的な請負関係を把握し、工事全体を統
括的に管理する。施主７０およびゼネコン８０は、エス
クロー事業者４０ｘとエスクロー契約を締結する。エス
クロー事業者４０ｘは、施主７０から予め委託を受け、
ＣＭ６０から支払依頼があると、ゼネコン８０にそれま
での工程に対する費用を支払う。同様に、ゼネコン８０
および施工業者５０ａはエスクロー事業者４０ｙと、施
工業者５０ａおよび施工業者５０ｂはエスクロー事業者
４０ｚと、それぞれエスクロー契約を締結し、エスクロ
ーサービスを受ける。つまり、この例では、階層的な請
負関係のそれぞれの当事者間で、本実施の形態のシステ
ムによるエスクローサービスが提供される。このとき、
施主７０とゼネコン８０の関係においては、施主７０が
発注者、ゼネコン８０が受注者となり、ゼネコン８０と
施工業者５０ａの関係においては、ゼネコン８０が発注
者、施工業者５０ａが受注者となり、施工業者５０ａと
施工業者５０ｂの関係においては、施工業者５０ａが発
注者、施工業者５０ｂが受注者となる。すなわち、施主
以外にも、ゼネコン８０、施工業者５０などが本システ
ムにおける発注者となりうる。

【００３３】図６の例では、それぞれの当事者間で、異
なるエスクロー事業者４０ｘ、４０ｙ、４０ｚがエスク
ローサービスを提供したが、同一のエスクロー事業者４
０がエスクローサービスを提供してもよい。このとき、
エスクロー事業者４０は、それぞれの当事者間における
支払処理を独立に行ってもよいし、それぞれの当事者間
の契約内容を予め把握しておき、ＣＭ６０から支払依頼
を受けたときに、施主７０の資金から、ゼネコン８０、
施工業者５０ａ、および施工業者５０ｂに、それぞれの
取り分を分配してもよい。工事に参加する全ての施工業
者５０がエスクローサービスの提供を受ける必要はな
く、当事者間の契約に任されることはいうまでもない。

【００３４】図７は、施工業者５０がオブジェクトリポ
ジトリサーバ１００に出来高に関する報告を登録するた
めの出来高情報登録画面の例を示す。業者Ａがオブジェ
クトリポジトリサーバ１００にログインして出来高情報
表示画面を表示すると、業者Ａが携わるＷＰの中から、
出来高情報を登録するＷＰを選択するための選択ボック
スが提示される。ここで１つのＷＰを選択すると、その
ＷＰの出来高情報として登録すべき情報が提示される。
施工業者５０は、登録ボタンをクリックすることによ
り、指定された出来高情報をオブジェクトリポジトリサ
ーバ１００にアップロードして登録する。この例では、
ＷＰとして「主ポンプ／電気設備」が選択され、出来高
に関する報告として現場写真３枚と作業日報１部を登録
すべき旨が表示されている。

【００３５】図８は、オブジェクトリポジトリサーバ１
００が登録された出来高に関する報告を提示する出来高
情報表示画面の例を示す。出来高情報表示画面には、プ
ロジェクトに含まれるＷＰの中から、出来高情報を表示
したいＷＰを選択するための選択ボックスが提示され
る。ここで１つのＷＰを選択すると、そのＷＰの施工業
者、工期、出来高情報の登録日、および登録された出来
高情報が提示される。この例では、ＷＰとして「主ポン
プ／電気設備」が選択され、そのＷＰの施工業者「Ａ
社」、工期「２００２年３月１日から２００２年３月３
０日まで」、出来高情報登録日「２００２年３月１０
日」などの情報が表示されるとともに、出来高情報とし
て現場写真３枚と作業日報１部が登録されている旨が表
示されている。出来高情報は関係者の全てに提示されな
くてもよく、必要に応じてアクセス制限が設けられても
よい。

【００３６】図９は、オブジェクトリポジトリサーバ１
００が登録された検査結果を提示する検査結果表示画面
の例を示す。検査結果表示画面には、プロジェクトに含
まれるＷＰの中から、検査結果を表示したいＷＰを選択
するための選択ボックスが提示される。ここで１つのＷ
Ｐを選択すると、そのＷＰの施工業者、工期、出来高情
報の登録日、検査日、検査結果、進捗度、予算、支払
額、および支払日が提示される。この例では、ＷＰとし
て「主ポンプ／電気設備」が選択され、そのＷＰの施工
業者「Ａ社」、工期「２００２年３月１日から２００２
年３月３０日まで」、出来高情報登録日「２００２年３
月１０日」、検査日「２００２年３月１１日」、検査結
果「良」、進捗度「６０％」、予算「１，５００，００
０円」、支払額「９００，０００円」、支払日「２００
２年３月３１日」などの情報が表示される。ここで、支
払額は、予算と進捗度の積により算出されている。これ
らの情報の全てが関係者に提示されなくてもよく、必要
な情報のみを選択して提示してもよいし、必要に応じて
アクセス制限が設けられてもよい。このように、工事の
工程管理に必要な情報がオブジェクトリポジトリサーバ
１００に登録され、必要に応じて関係者に提示されるの
で、工程管理の透明性および信頼性が格段に向上する。

【００３７】以上説明したように、本実施の形態のデー
タ管理システム１０は、工事をＷＰに細分化して管理す
るＰＭ方式の利便性と、ＣＭの存在による高い信頼性と
により、リスクが少なく利便性が高いエスクローサービ
スを提供することができる。本データ管理システム１０
は、ＷＰごと、または期間ごとの支払を実現すること
で、とくに受注者側に大きな利点を与えるが、エスクロ
ー事業者にとってもリスクの少ないエスクローサービス
が提供できるという利点があり、多くの受注者およびエ
スクロー事業者が本システムに参加することが期待され
るから、発注者側にとっても魅力的なシステムとして構
築される。本システムにおけるデータ管理には、以下に
説明するように、オブジェクトリポジトリ技術が好適で
ある。オブジェクトリポジトリデータベースの採用によ
り、工事の進捗に伴って目まぐるしく変化する状況に的
確に対応し、利便性の高い管理環境を提供することがで
きる。

【００３８】以下、本実施の形態のデータ管理システム
１０におけるデータ管理手法について説明する。従来の
リレーショナルデータベースを用いた例と対比しつつ、
本実施の形態のオブジェクトリポジトリデータベースを
用いたデータ管理技術の利点を明らかにする。

【００３９】図１０は、ある建築物を建設するときの工
程の流れを示す。初期計画では、一連の作業が、床堀、
埋戻、鋼矢板杭、法面整形、基礎コンクリート、コンク
リートブロック積、屑止コンクリート、端止コンクリー
トのＷＰに細分化されている。初期計画に沿って業者Ａ
が埋戻工程を作業している途中に、何らかの要因で手戻
りが発生し、再度、埋戻工程を実施する必要が生じたと
する。このとき、初期計画を修正して、新たに２次計画
が作成される。

【００４０】２次計画では、初期計画に沿って実施した
埋戻工程の後に、再び埋戻工程が実施され、それ以降は
初期計画と同じ工程が実施される。２次計画に沿って業
者Ａが鋼矢板杭工程を作業している途中に、浸水が発生
して止水作業を実施する必要が生じたとする。このと
き、新たに３次計画が作成される。

【００４１】３次計画では、新たに発生した止水工程が
業者Ｘにより実施され、その後、鋼矢板杭工程以降の工
程が実施される。３次計画に沿って業者Ａが法面整形工
程を作業している途中に、法面が崩落して最初の工程か
らやり直す必要が生じたとする。このとき、新たに４次
計画が作成される。

【００４２】４次計画では、初期計画における初工程で
ある床堀工程から順に、初期計画と同じ工程が実施され
る。図１０の例のように、実際の施工の現場では、日々
の進捗状況や作業状態に応じて、計画が変更されること
が珍しくない。このような計画の変更（バージョンアッ
プ）が頻繁に繰り返される場合であっても、適切に工程
管理を行う必要がある。

【００４３】図１１は、一般的なリレーショナルデータ
ベースを用いて工程を管理するときのデータ構造の例を
示す。リレーショナルデータベース３００には、工程名
欄３０２、予定成果物欄３０４、業者欄３０６、および
計画バージョン欄３０８が設けられている。初期計画時
には、上から８レコードのみが記録されていたが、計画
変更が行われるごとに、変更された工程とそれ以降の工
程を新たなレコードとして追加していくので、４次計画
時には３０レコードを費やしている。このように、図１
１に示したデータ構造では、計画変更が頻繁に行われる
と、データベースのレコード数が膨大になり効率的でな
い。

【００４４】図１２は、一般的なリレーショナルデータ
ベースを用いて工程を管理するときのデータ構造の他の
例を示す。リレーショナルデータベース３１０には、工
程名欄３１２、初期計画欄３１４、２次計画欄３１６、
３次計画欄３１８、４次計画欄３２０、・・・、１０次
計画欄３２２が設けられており、それぞれのｎ次計画欄
には、予定成果物欄および業者欄が設けられている。図
１２に示したデータ構造では、新たに工程が追加された
とき、たとえば図１０の例では３次計画において止水工
程が追加されたときにのみ、レコードが追加される。し
かしながら、計画変更を見越して予め十分な数のｎ次計
画欄を設けておく必要があり、計画変更が予定より少な
かった場合は確保したフィールドに無駄が生じ、計画変
更が予定より多かった場合はデータを記録することがで
きなくなる。

【００４５】図１３および図１４は、本実施の形態のデ
ータ管理システム１０におけるオブジェクトリポジトリ
データベースのデータ構造を模式的に示す。オブジェク
トリポジトリデータベースでは、作業計画のバージョン
を格納する計画クラス、細分化した作業工程を格納する
工程クラス、および作業に関わる業者を格納する業者ク
ラスが設計されており、新たな情報を追加するときに、
新たなインスタンスが実体として生成される。各計画イ
ンスタンスは、その計画に含まれる工程インスタンスへ
のリレーションを保持する。各工程インスタンスは、そ
の工程に携わる業者インスタンスへのリレーションを保
持する。このとき、データの信頼性や検索および処理の
効率などを考慮して、逆リレーションすなわち工程イン
スタンスから計画インスタンスへのリレーション、およ
び業者インスタンスから工程インスタンスへのリレーシ
ョンを保持してもよい。各工程インスタンスは、属性情
報として、予定成果物の情報を保持する。もちろん、各
インスタンスは各種属性情報を保持してよいが、ここで
は説明の簡便のため省略する。

【００４６】図１３を参照して、初期計画から２次計画
への計画変更に伴うデータの変化について説明する。初
期計画インスタンスは、床堀、埋戻、鋼矢板杭、法面整
形、基礎コンクリート、コンクリートブロック積、屑止
コンクリート、端止コンクリート、の各工程インスタン
スへのリレーションを保持する。床堀、埋戻、鋼矢板
杭、法面整形の各工程インスタンスは、Ａ業者インスタ
ンスへのリレーションを保持し、基礎コンクリート、コ
ンクリートブロック積、屑止コンクリート、端止コンク
リートの各工程インスタンスは、Ｂ業者インスタンスへ
のリレーションを保持する。これにより、図１０に示し
た初期計画の情報が全て表現される。

【００４７】埋戻工程の手戻りにより計画が変更される
と、２次計画インスタンスが新たに生成される。さら
に、変更された埋戻工程に対応する工程インスタンスが
新たに生成され、生成された埋戻（再作業）工程インス
タンスに、その工程に携わるＡ業者インスタンスへのリ
レーションが登録される。２次計画インスタンスは、埋
戻（再作業）工程インスタンスへのリレーションと、そ
れ以降の工程へのリレーションを保持する。計画変更に
伴うデータの増大は、２次計画インスタンスおよび埋戻
（再作業）工程インスタンスの追加のみである。

【００４８】つづいて、図１４を参照して、３次計画お
よび４次計画への計画変更に伴うデータの変化について
説明する。３次計画では、業者Ｘが担当する止水工程が
新たに追加された。これに伴い、３次計画インスタンス
を新たに生成するとともに、止水工程に対応する工程イ
ンスタンスおよび業者Ｘに対応する業者インスタンスを
新たに生成する。止水工程インスタンスに、Ｘ業者イン
スタンスへのリレーションを張り、３次計画インスタン
スに、止水工程インスタンスおよびそれ以降の工程イン
スタンスへのリレーションを張る。４次計画では、初工
程よりやり直すため、４次計画インスタンスを生成し、
初期計画と同じ工程インスタンスへのリレーションを張
ればよい。このように、図１３および図１４に示したデ
ータ構造によれば、頻繁に計画変更が行われても、最小
限のデータの増大で対応することができる。本実施の形
態のデータ管理システム１０では、作業を細分化したＷ
Ｐを単位として工事を管理するにあたり、資源の再利用
を可能とするオブジェクト指向技術を利用したオブジェ
クトリポジトリデータベースを用いることにより、頻繁
に変更されるデータを効率的に処理する。

【００４９】図１５は、本実施の形態に係るオブジェク
トリポジトリサーバ１００の内部構成を示す。オブジェ
クトリポジトリサーバ１００は、ハードウエアコンポー
ネントでいえば、任意のコンピュータのＣＰＵ、メモ
リ、メモリにロードされたプログラムなどによって実現
されるが、ここではそれらの連携によって実現される機
能ブロックを描いている。したがって、これらの機能ブ
ロックがハードウエアのみ、ソフトウエアのみ、または
それらの組合せによっていろいろな形で実現できること
は、当業者には理解されるところである。

【００５０】オブジェクトリポジトリサーバ１００は、
主に、通信部１０２、主制御部１０４、および記憶部１
０６を備える。通信部１０２は、インターネット２０を
介して他装置と通信するために必要なモデムなどのハー
ドウェアと、そのハードウェアを制御するためのドライ
バなどを含む。主制御部１０４は、出来高受付部１１
０、処理部１１２、伝達部１１４、検査結果受付部１２
０、検査結果送信部１２２、登録受付部１３０、計画イ
ンスタンス生成部１３２、工程インスタンス生成部１３
４、業者インスタンス生成部１３６、第１関連生成部１
３８、第２関連生成部１４０、金額集約部１５０、およ
び金額送信部１５２を含む。記憶部１０６は、計画デー
タベース１６０、工程データベース１６２、業者データ
ベース１６４、第１関連保持部１６６、および第２関連
保持部１６８を含む。

【００５１】計画データベース１６０は、作業計画のバ
ージョンをそれぞれ計画インスタンスとして格納する。
工程データベース１６２は、細分化した作業工程を順序
付けてそれぞれ工程インスタンスとして格納する。業者
データベース１６４は、作業に関わる業者をそれぞれ業
者インスタンスとして格納する。第１関連保持部１６６
は、計画インスタンスと工程インスタンスとの関連を保
持する。第２関連保持部１６８は、工程インスタンスと
業者インスタンスとの関連を保持する。第１関連保持部
１６６および第２関連保持部１６８に保持される関連情
報は、各インスタンスの属性情報として保持されてもよ
い。各インスタンスは、各種属性情報を保持してもよ
い。たとえば、計画インスタンスは、計画の名称、計画
のバージョン番号、変更日時、発注者、計画責任者など
の属性情報を保持してもよい。工程インスタンスは、予
定成果物、予算、工期などの属性情報を保持してもよ
い。業者インスタンスは、業者の名称、所在地、連絡先
などの属性情報を保持してもよい。このようなクラス設
計に自由度が高いことは、当業者には理解されるところ
である。

【００５２】出来高受付部１１０は、業者端末５０から
出来高に関する報告を受け付け、記憶部１０６に格納す
る。このとき、出来高に関する報告は、図示しない出来
高情報保持部に格納されてもよいし、工程インスタンス
の属性情報として格納されてもよい。処理部１１２は、
出来高に関する報告を、業者端末５０、管理サーバ６
０、または機関サーバ４０の少なくとも一者から確認可
能な状態にせしめる。本実施の形態では、ウェブページ
として出来高に関する報告を提示する。伝達部１１４
は、出来高に関する報告を受け付けたことを管理サーバ
６０または機関サーバ４０の少なくとも一者に通知す
る。伝達部１１４は、たとえば電子メールなどを利用し
て通知してもよい。

【００５３】検査結果受付部１２０は、管理サーバ６０
から、出来高が予定成果物をどの程度満足しているかの
検査結果を受け付ける。このとき、検査結果は、図示し
ない検査結果保持部に格納されてもよいし、工程インス
タンスの属性情報として格納されてもよい。検査結果送
信部１２２は、検査結果を機関サーバ４０に送信する。
検査結果送信部１２２は、検査結果を受け付けたとき
に、機関サーバ４０に電子メールなどにより自動的に検
査結果を送信してもよいし、機関サーバ４０からアクセ
スがあったときにウェブページなどにより提示してもよ
い。

【００５４】登録受付部１３０は、作業に関するデータ
の登録または変更を受け付ける。登録受付部１３０が計
画の変更要求を受け付けると、計画インスタンス生成部
１３２は、新たな計画インスタンスを生成する。登録を
要求したユーザは、新たな計画インスタンスの生成処理
を意識することなく、単に変更されたデータを入力する
だけで、計画インスタンス生成部１３２が自動的に計画
インスタンスの生成処理を行う。このとき、計画のバー
ジョン番号をユーザから受け付けてもよいし、現在の計
画のバージョン番号を参照して自動的に新たなバージョ
ン番号を生成してもよい。このバージョン番号は、計画
インスタンスの属性情報として保持されてもよい。新た
な計画インスタンスが生成されると、第１関連生成部１
３８は、計画インスタンスと、その計画に含まれる工程
に対応する工程インスタンスとを関連づける。生成され
た関連情報は第１関連保持部１６６に格納される。

【００５５】登録受付部１３０が工程の変更または追加
を受け付けると、工程インスタンス生成部１３４は、新
たな工程インスタンスを生成する。このインスタンス生
成処理も、ユーザに意識させることなく、データの入力
を受け付けると自動的に行われる。新たな工程インスタ
ンスが生成されると、第２関連生成部１４０は、工程イ
ンスタンスと、その工程に携わる業者に対応する業者イ
ンスタンスとを関連づける。生成された関連情報は第２
関連保持部１６８に格納される。登録受付部１３０が業
者の追加を受け付けると、業者インスタンス生成部１３
６は、新たな業者インスタンスを生成する。

【００５６】登録受付部１３０が作業工程の変更を受け
付けた場合は、新たな計画インスタンスが生成されると
ともに、変更された作業工程に対応する新たな工程イン
スタンスが生成される。このとき、第１関連生成部１３
８は、新たな計画インスタンスに、新たな工程インスタ
ンス、および変更された作業工程以降の作業工程に対応
する工程インスタンスを関連づける。

【００５７】登録受付部１３０がある作業工程に携わる
業者の変更を受け付けた場合は、新たな計画インスタン
スが生成されるとともに、業者が変更された作業工程に
対応する新たな工程インスタンスが生成される。このと
き、第１関連生成部１３８は、新たな計画インスタンス
に、新たな工程インスタンス、および変更された作業工
程以降の作業工程に対応する工程インスタンスを関連づ
け、第２関連生成部１４０は、新たな工程インスタンス
に、変更後の業者に対応する業者インスタンスを関連づ
ける。

【００５８】金額集約部１５０は、管理サーバ６０によ
り検査された出来高に対応して支払うべき金額を業者ご
とに集約する。金額集約部１５０は、ある業者が携わっ
ている工程を、第２関連保持部１６８に保持された関連
情報を参照して抽出し、その工程についての検査結果を
参照して支払うべき金額を算出する。業者インスタンス
が、属性情報として、その業者が携わっている工程に対
応する工程インスタンスへのリレーションを保持してい
ると、検索に便利である。金額送信部１５２は、集約し
た金額を管理サーバ６０または機関サーバ４０に対して
所定のタイミングで送信する。金額を送信するタイミン
グは、施工業者５０が請求書を発行するタイミングであ
ってもよいし、工程の終了時であってもよいし、月ご
と、半期ごとなどであってもよい。

【００５９】図１６は、本実施の形態に係る機関サーバ
４０の内部構成を示す。機関サーバ４０も、ハードウエ
アのみ、ソフトウエアのみ、またはそれらの組合せによ
っていろいろな形で実現できる。機関サーバ４０は、通
信部４２、金額受付部４４、支払処理部４６を備える。
通信部４２は、インターネット２０を介した他装置との
通信に必要な構成を含む。

【００６０】金額受付部４４は、オブジェクトリポジト
リサーバ１００または管理サーバ６０から、集約した金
額を受け付ける。支払処理部４６は、所定のタイミング
で、この金額を業者に対して支払う。支払のタイミング
は、施工業者５０が請求書を発行するタイミングであっ
てもよいし、工程の終了時であってもよいし、月ごと、
半期ごとなどであってもよい。支払処理部４６は、オブ
ジェクトリポジトリサーバ１００の検査結果送信部１２
２から送信される検査結果を受けて、支払業務を遂行可
能な状態とする。支払処理部４６は、検査結果を受け付
けると、たとえば、施工業者に対する支払金額を保持す
るデータベースの支払可能フラグをたてることにより、
支払業務を遂行可能な状態としてもよい。

【００６１】図１７は、オブジェクトリポジトリサーバ
１００および機関サーバ４０のハードウェアコンポーネ
ントを示す。オブジェクトリポジトリサーバ１００およ
び機関サーバ４０は、ＣＰＵ２２０、入力装置２２２、
表示装置２２４、ＲＡＭ（ランダムアクセスメモリ）２
３０、ハードディスク２３２、およびドライブ装置２２
８を備える。これらの構成は、バス２２６などの信号伝
送路により電気的に接続されている。

【００６２】ハードディスク２３２は、大容量の磁気記
憶装置であり、各種データベースなどを記憶する。記録
媒体２４０は、実施の形態に関連して説明したオブジェ
クトリポジトリサーバ１００および機関サーバ４０の機
能を、ＣＰＵ２２０に実現させるためのプログラムを記
録する。記録媒体２４０がドライブ装置２２８に挿入さ
れると、そのプログラムは、ＲＡＭ２３０またはハード
ディスク２３２に読み出され、ＣＰＵ２２０は、読み出
されたプログラムにより処理を行う。この記録媒体２４
０は、ＣＤ−ＲＯＭ、ＤＶＤ、ＦＤなどのコンピュータ
読み取り可能な媒体である。

【００６３】ここでは、データ管理用のプログラムが記
録媒体２４０に記録されている例について説明したが、
別の例においては、このプログラムは、無線、有線を問
わず、外部のサーバから送信されてもよい。図１７に示
したハードウェア構成において、プログラムは、コンピ
ュータにデータ管理機能を実現させればよいのであっ
て、外部から供給される場合だけでなく、予めハードデ
ィスク２３２に格納されていてよいことも当業者には理
解されるところである。

【００６４】以上、本発明を実施の形態をもとに説明し
たが、本発明の技術的範囲は上記実施の形態に記載の範
囲には限定されない。上記実施の形態は例示であり、そ
れらの各構成要素や各処理プロセスの組合せに、さらに
いろいろな変形例が可能なこと、またそうした変形例も
本発明の範囲にあることは当業者に理解されるところで
ある。

【００６５】本実施の形態では、発注者および受注者と
独立して専門的に管理業務を行う第三者機関がＣＭの業
務を担当することを想定していたが、工事に関する専門
知識とノウハウを有するゼネコンなどが第三者機関とし
てＣＭの業務を担当してもよい。

【００６６】

【発明の効果】本発明によれば、効率的かつ利便性の高
いデータ管理技術を提供することができる。

【図面の簡単な説明】

【図１】実施の形態に係るデータ管理システムの全体構
成を示す図である。

【図２】 発注者が工事を企画してから工事が開始され
るまでの手順を概略的に示す図である。

【図３】 工事の一連の作業が細分化される様子を説明
するための図である。

【図４】 コンストラクション・マネージャが工事計画
に関するデータをオブジェクトリポジトリサーバに登録
するための登録画面の例を示す図である。

【図５】 工事が開始されてから工事が完了するまでの
手順を概略的に示す図である。

【図６】 施工業者間に階層的な請負関係がある場合の
エスクローサービスの形態の例を示す図である。

【図７】 施工業者がオブジェクトリポジトリサーバに
出来高に関する報告を登録するための出来高情報登録画
面の例を示す図である。

【図８】 オブジェクトリポジトリサーバが登録された
出来高に関する報告を提示する出来高情報表示画面の例
を示す図である。

【図９】 オブジェクトリポジトリサーバが登録された
検査結果を提示する検査結果表示画面の例を示す図であ
る。

【図１０】ある建築物を建設するときの工程の流れを示
す図である。

【図１１】 一般的なリレーショナルデータベースを用
いて工程を管理するときのデータ構造の例を示す図であ
る。

【図１２】 一般的なリレーショナルデータベースを用
いて工程を管理するときのデータ構造の他の例を示す図
である。

【図１３】 本実施の形態のデータ管理システムにおけ
るオブジェクトリポジトリデータベースのデータ構造を
模式的に示す図である。

【図１４】 本実施の形態のデータ管理システムにおけ
るオブジェクトリポジトリデータベースのデータ構造を
模式的に示す図である。

【図１５】 本実施の形態に係るオブジェクトリポジト
リサーバの内部構成を示す図である。

【図１６】 本実施の形態に係る機関サーバの内部構成
を示す図である。

【図１７】 本実施の形態に係るオブジェクトリポジト
リサーバおよび機関サーバのハードウェアコンポーネン
トを示す図である。

【符号の説明】

１０・・・データ管理システム、３０・・・発注者端
末、４０・・・機関サーバ、４４・・・金額受付部、４
６・・・支払処理部、５０・・・業者端末、６０・・・
管理サーバ、１００・・・オブジェクトリポジトリサー
バ、１１０・・・出来高受付部、１１２・・・処理部、
１１４・・・伝達部、１２０・・・検査結果受付部、１
２２・・・検査結果送信部、１３０・・・登録受付部、
１３２・・・計画インスタンス生成部、１３４・・・工
程インスタンス生成部、１３６・・・業者インスタンス
生成部、１３８・・・第１関連生成部、１４０・・・第
２関連生成部、１５０・・・金額集約部、１５２・・・
金額送信部、１６０・・・計画データベース、１６２・
・・工程データベース、１６４・・・業者データベー
ス、１６６・・・第１関連保持部、１６８・・・第２関
連保持部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 尾崎 博昭 東京都港区赤坂七丁目５番47号 株式会社 ウェッブアイ内

Claims (9)

【特許請求の範囲】
1. 【請求項１】 一連の細分化した作業に関するデータを
   管理するオブジェクトリポジトリサーバと、作業の出来
   高を該オブジェクトリポジトリサーバに報告する業者端
   末と、作業の出来高に関する検査結果を該オブジェクト
   リポジトリサーバに報告する管理サーバと、支払業務を
   行う金融機関などにより管理される機関サーバとがネッ
   トワークによって接続されているデータ管理システムで
   あって、 前記オブジェクトリポジトリサーバは、 細分化した作業工程を順序付けてそれぞれ工程インスタ
   ンスとして格納し且つ各作業工程において予め定められ
   た予定成果物を属性情報として該工程インスタンスに対
   応付けて格納する工程データベース部と、 作業に関わる業者をそれぞれ業者インスタンスとして格
   納する業者データベース部と、 工程インスタンスと業者インスタンスとの関連を保持す
   る関連保持部と、 業者端末から出来高に関する報告を受け付ける出来高受
   付部と、 前記出来高に関する報告を、業者端末、管理サーバまた
   は機関サーバの少なくとも一者から確認可能な状態にせ
   しめる処理部と、 出来高に関する報告を受け付けたことを管理サーバまた
   は機関サーバの少なくとも一者に伝える伝達部と、 管理サーバより、該出来高が予定成果物をどの程度満足
   しているかの検査結果を受け付ける検査結果受付部と、 この検査結果を機関サーバに送信する検査結果送信部と
   を備えることを特徴とするデータ管理システム。
2. 【請求項２】 前記機関サーバは、検査結果送信部より
   送信される検査結果を受けて、該出来高に対する支払業
   務を遂行可能な状態とすることを特徴とする請求項１に
   記載のデータ管理システム。
3. 【請求項３】 前記オブジェクトリポジトリサーバは、 管理サーバにより検査された出来高に対応して支払うべ
   き金額を業者ごとに集約する金額集約部と、 集約した金額を管理サーバまたは機関サーバに対して所
   定のタイミングで送信する金額送信部とを備えることを
   特徴とする請求項１または２に記載のデータ管理システ
   ム。
4. 【請求項４】 前記機関サーバは、 オブジェクトリポジトリサーバまたは管理サーバから、
   集約した金額を受け付ける金額受付部と、 所定のタイミングで、この金額を業者に対して支払う支
   払処理部とを備えることを特徴とする請求項３に記載の
   データ管理システム。
5. 【請求項５】 一連の細分化した作業に関するデータを
   管理するオブジェクトリポジトリサーバであって、 細分化した作業工程を順序付けてそれぞれ工程インスタ
   ンスとして格納し且つ各作業工程において予め定められ
   た予定成果物を属性情報として該工程インスタンスに対
   応付けて格納する工程データベース部と、 作業に関わる業者をそれぞれ業者インスタンスとして格
   納する業者データベース部と、 工程インスタンスと業者インスタンスとの関連を保持す
   る関連保持部と、 業者端末から出来高に関する報告を受け付ける出来高受
   付部と、 前記出来高に関する報告を、支払業務を行う金融機関な
   どに設けられた機関端末から確認可能な状態にせしめる
   処理部とを備えることを特徴とするオブジェクトリポジ
   トリサーバ。
6. 【請求項６】 該出来高が予定成果物をどの程度満足し
   ているかの検査結果を外部から受け付ける検査結果受付
   部と、 この検査結果を、前記機関端末に送信する検査結果送信
   部とを備えることを特徴とする請求項５に記載のオブジ
   ェクトリポジトリサーバ。
7. 【請求項７】 検査された出来高に対応して支払うべき
   金額を業者ごとに集約する金額集約部を備えることを特
   徴とする請求項６に記載のオブジェクトリポジトリサー
   バ。
8. 【請求項８】 一連の細分化した作業に関するデータを
   管理するオブジェクトリポジトリサーバであって、 作業計画のバージョンをそれぞれ計画インスタンスとし
   て格納する計画データベース部と、 細分化した作業工程を順序付けてそれぞれ工程インスタ
   ンスとして格納する工程データベース部と、 作業に関わる業者をそれぞれ業者インスタンスとして格
   納する業者データベース部と、 計画インスタンスと工程インスタンスとの関連を保持す
   る第１関連保持部と、 工程インスタンスと業者インスタンスとの関連を保持す
   る第２関連保持部と、 作業工程に変更があった場合に、新たな計画インスタン
   スを生成する計画インスタンス生成部と、 変更された作業工程に対応する新たな工程インスタンス
   を生成する工程インスタンス生成部と、 新たな計画インスタンスに、新たな工程インスタンス、
   および変更された作業工程以降の作業工程に対応する工
   程インスタンスを関連付ける関連生成部とを備え、 第１関連保持部は、関連生成部により生成された関連を
   保持することを特徴とするオブジェクトリポジトリサー
   バ。
9. 【請求項９】 一連の細分化した作業に関するデータを
   管理するオブジェクトリポジトリサーバであって、 作業計画のバージョンをそれぞれ計画インスタンスとし
   て格納する計画データベース部と、 細分化した作業工程を順序付けてそれぞれ工程インスタ
   ンスとして格納する工程データベース部と、 作業に関わる業者をそれぞれ業者インスタンスとして格
   納する業者データベース部と、 計画インスタンスと工程インスタンスとの関連を保持す
   る第１関連保持部と、 工程インスタンスと業者インスタンスとの関連を保持す
   る第２関連保持部と、 ある作業工程に携わる業者に変更があった場合に、新た
   な計画インスタンスを生成する計画インスタンス生成部
   と、 業者が変更された作業工程に対応する新たな工程インス
   タンスを生成する工程インスタンス生成部と、 新たな計画インスタンスに、新たな工程インスタンス、
   および変更された作業工程以降の作業工程に対応する工
   程インスタンスを関連付ける第１関連生成部と、 新たな工程インスタンスに、変更後の業者に対応する業
   者インスタンスを関連付ける第２関連生成部とを備え、 第１関連保持部は、第１関連生成部により生成された関
   連を保持し、第２関連保持部は、第２関連生成部により
   生成された関連を保持することを特徴とするオブジェク
   トリポジトリサーバ。