JP2011170573A - 管理サーバ及び建設受発注システム - Google Patents

Abstract

【課題】発注者の希望に応じて、最適な建設方式が容易に選択可能となる管理サーバ及び建設受発注システムを提供すること。
【解決手段】管理項目と、管理項目に対する配点とを提案情報として記憶する記憶手段と、前記発注端末から、管理項目に対応する重み情報を含む提案要求を受信する提案要求受信手段と、前記事業者端末から、管理項目の中から選択項目を受信し、当該選択項目の配点と、前記選択項目に関する重みから評価点数を算出する評価点数算出手段と、前記評価点数算出手段により算出された評価点数を含めた提案リストを生成する提案リスト生成手段と、前記提案リストを、前記発注端末に送信する提案リスト送信手段と、を備える。
【選択図】図１

Description

本発明は、発注者が使用する発注端末と、建設事業者が使用する事業者端末とが接続される管理サーバを含む建設受発注システムにおける管理サーバ等に関する。

日本の建設事業者については、ビル建設を主に担当するゼネコンと、個人住宅建設を主に担当するハウスメーカとに大別することができる。また、建設をマネジメントするＰＭ（プロジェクトマネジメント）・ＣＭ（コンストラクションマネジメント）等の建設事業者が知られている。

これらの建設事業者のうち、建設における企画から完成及び運用管理に至るまでワンストップでサービスを提供出来る建設事業者が存在している。当該建設事業者は、上記サービスを提供できることが可能な人材や組織を保有し、十分な実績に基づいたポテンシャルがある。

したがって、発注者側は、建設事業者に対して工事の一式を発注し、建設事業者もそれを請け負うことが一般的である。建設事業者は、例えば建材メーカ、施工業者等の種々の建設関連の専門工事事業者にそれぞれの業務・工事を発注することとなる。

このように、工事には建設の用途、規模、地域、その他の与条件の違いにより単品生産の性格が強いことから、種々な事業者を含めた発注が行われる。そのため、工事を行う場合、工事に伴う要求のハード・ソフトの決定に至るプロセスが極めて複雑になるといった問題があった。また、発注者側は、どの部分でどのような設計・工事が行われているか解らないため、全体として発注者の要求に見合った見積がいくらになる等が不明瞭となっていた。

そこで、一例として発注者の希望を反映した工事を行うために、発注者の条件を種々の業者に送信し、各業者に見積等を決定して入力してもらうことにより、見積や工期について決める場合に、発注者がプロセスを参照可能となる建設受発注システムが知られている（例えば、特許文献１参照）。

特開２００３−６２８０号公報

ここで、建設事業者は種々の事業者があるため、例えば同じ条件で工事依頼をした場合でも、工事に採用する建設方式や、建材のコストといった選択の幅が多岐にわたるため、建設工事予算（建設費）が異なって来るのが通常である。この場合、どの建設事業者を使うことによりコストと性能のバランスが取れた工事が行えるのか、建設の初期段階で発注者側が判断することは出来なかった。

とくに、企画・設計・工事の内容、すなわちハード（例えば、建築物や建材、内装、外装）とソフト（例えば、テナントの運営サービスといった役務提供）との関係については、専門的であることから、発注者が判断することは極めて難しいという問題があった。すなわち、企画・設計・工事において、どの程度まで作業内容を実行するのか、構造的にどの方式がベストなのかと言ったことが、発注者側では判断することは極めて難しいからである。また、当該コスト、用途、性能及び機能に対応する建設方式が適切であるか否かといったことを初期の段階で判断するコミュニケーションツールがなかった。

これらの解決する仕組みとしては、ＰＭ／ＣＭを利用する方法が考えられるが、ＰＭ／ＣＭを考慮した受発注システムは無く、さらに発注者リスクを担保するＰＭ／ＣＭ方式が困難であるために、結果として発注者が効果的にＰＭ／ＣＭを利用するといったことが出来なかった。

したがって、工事に対するリスクをどのように評価し、当該リスクを誰が負担するのかといった点に関しても明確に決められていない場合が多く、発注者側と建設事業者側とでトラブルとなる場合も少なくなかった。

上述した課題に鑑み、本発明が目的とするところは、発注者の希望に応じて、最適な建設方式が容易に選択可能となる管理サーバ及び建設受発注システムを提供することである。

上述した課題に鑑み、本発明の管理サーバは、
発注者が使用する発注端末と、建設事業者が使用する事業者端末とが接続される管理サーバを含む建設受発注システムにおける管理サーバであって、
管理項目と、管理項目に対する配点とを提案情報として記憶する記憶手段と、
前記発注端末から、管理項目に対応する重み情報を含む提案要求を受信する提案要求受信手段と、
前記事業者端末から、管理項目の中から選択項目を受信し、当該選択項目の配点と、前記選択項目に関する重みから評価点数を算出する評価点数算出手段と、
前記評価点数算出手段により算出された評価点数を含めた提案リストを生成する提案リスト生成手段と、
前記提案リストを、前記発注端末に送信する提案リスト送信手段と、
を備えることを特徴とする。

また、本発明の管理サーバにおいて、
前記提案リストには、前記事業者端末から受信された選択項目が含まれていることを特徴とする。
また、本発明の管理サーバは、
前記提案リストを送信した後に、前記発注端末から必要となる管理項目が選択された情報を含む契約要求を受信する契約要求受信手段を更に有し、
前記契約要求に含まれる管理項目に対し評価点数を算出し、当該管理項目と評価点数を含む契約リストを生成して送信することを特徴とする。

本発明の建設受発注システムは、発注者が使用する発注端末と、建設事業者が使用する事業者端末とが接続される建設受注管理サーバを含む建設受発注システムであって、
前記管理サーバは、
管理項目と、管理項目に対する配点とを提案情報として記憶する記憶手段と、
前記発注端末から、管理項目に対応する重み情報を含む提案要求を受信する提案要求受信手段と、
前記事業者端末から、管理項目の中から選択項目を受信し、当該選択項目の配点と、前記選択項目に関する重みから評価点数を算出する評価点数算出手段と、
前記評価点数算出手段により算出された評価点数を含めた提案リストを生成する提案リスト生成手段と、
前記提案リストを、前記発注端末に送信する提案リスト送信手段と、
を備えたことを特徴とする。

本発明によれば、発注端末から、管理項目に対応する重み情報を含む提案要求を受信すると、事業者端末から、管理項目の中から選択項目を受信し、当該選択項目の配点と、前記選択項目に関する重みから評価点数を算出する。そして、算出された評価点数を含めた提案リストを生成し、発注端末に送信する。したがって、発注者は提案リストに基づいた算出された評価点数が表示され、当該評価点数により建設事業者や、建設方式を選定することができるため、細かい管理項目の内容を直接把握できない場合であっても、より適切な建設方式を選択可能となる。

第１実施形態における建設受発注システムの全体を示す図である。 第１実施形態における管理サーバの機能構成図である。 第１実施形態における建設方式情報のデータ構成の一例を示す図である。 第１実施形態における建設スキーム基本情報のデータ構成の一例を示す図である。 第１実施形態における建設スキーム特徴情報のデータ構成の一例を示す図である。 第１実施形態における業務リスク情報のデータ構成の一例を示す図である。 第１実施形態における建設事業者情報のデータ構成の一例を示す図である。 第１実施形態における建設情報のデータ構成の一例を示す図である。 第１実施形態における提案管理項目情報のデータ構成の一例を示す図である。 第１実施形態における仕様管理項目情報のデータ構成の一例を示す図である。 第１実施形態における基本管理項目重み情報のデータ構成の一例を示す図である。 第１実施形態における仕様管理項目重み情報のデータ構成の一例を示す図である。 第１実施形態における提案リストのデータ構成の一例を示す図である。 第１実施形態における管理サーバの動作を説明するためのフローチャートである。 第１実施形態における建設受発注システムの全体の処理の流れを説明するための図である。 第１実施形態における建設受発注システムの全体の処理の流れを説明するための図である。 第１実施形態における建設受発注システムの全体の処理の流れを説明するための図である。 第１実施形態における実施例について説明するための図である。 第２実施形態における提案リストのデータ構成の一例を示す図である。 本実施形態におけるロジックプロセスについて説明するための図である。 本実施形態におけるロジックプロセスについて説明するための図である。

以下、図面を参照して本発明を実施するための最良の形態について説明する。ここで、本発明ついては、以下のような考えに基づいているものである。

すなわち、これからの建設は、成熟社会(投資余力の低下)やエコロジー社会（地球環境問題）の到来を受けて、建物もフローのみでなくストック活用時代へとその変化を迫られている。

このような大きな変革の渦に巻き込まれながらも、建設産業の変革は進んでいない。なぜならば、建設の企画、設計、施工、管理・運営のフェーズにおけるソフト・ハード要件に一貫性が必要でありながら、フーズごとの役割、責任があいまいで、さらに、縦割りの組織であることによって阻害されていると考えられている。

一方、プロジェクトの進め方、方針の決定根拠などいまだに不透明な仕組みであることが、原因であるとも言われている。

これからの建設産業は、国内はもちろん国外の工事においてもワンストップでの建設を行う仕掛けが必要である。その仕掛けとして、アットリスクでのＰＭ／ＣＭ方式の採用はもちろんであるが、さらに、論理的でダイレクトなコミュニケーションの機能を考える必要があった。

上述した考えに基づき、本発明の受発注システム等の用い方の一例として、インターネット上に仮想市場を創造して、国内外の建設の発注者と複数の受注予定者が、出会い、取引を行うことがある。また、個別に行っても良く、両者共、従来の営業を効率化し、個別プロジェクトの性格（民間、公共工事）におけるセキュリティの強弱によって、透明性や客観性についても調整する効果がある。

また、本発明の受発注システム等の特徴として、アットリスクＰＭ／ＣＭ方式によって、発注者の要求事項に対し、建設事業者の取り組み方やコミットが、建設の初期段階において発注者とコンセンサスが得ることができることである点にある。

以下、このような考えに基づいて発明した受発注システム等につき、具体的な実施形態を図を用いて詳細に説明する。

［１．第１実施形態］
まず、第１実施形態について、説明する。
［１．１ 全体構成］
まず、本実施形態における建設受発注システム１００の全体構成を図１に示す。図１に示すように、建設受発注システム１００は、管理サーバ１に、ユーザが利用する発注端末３と、建設事業者が利用する複数の事業者端末５とが、ネットワークを介して接続されている。

ここで、各端末、サーバが接続されるネットワークは、例えばＩＳＤＮやインターネット等の公衆回線を利用したネットワークでも良いし、専用線で接続されたネットワークであっても良い。

管理サーバ１は、建設（工事）の発注に関するリスク評価等の管理を行うサーバであり、例えばＰＭ（プロジェクトマネジメント）が管理する。また、発注端末３は、顧客、施主等の発注者が操作する端末であり、例えば専用ソフトを利用したり、ＷＥＢブラウザ等によりアクセスしたりすることとしても良い。事業者端末５は、各建設事業者が操作する端末であり、事業者毎に接続されている。

［１．２ 装置構成］
続いて、建設受発注システム１００に接続される各装置の構成について説明する。なお、本実施形態では、特徴的である管理サーバ１を中心に説明する。

［１．２．１ 管理サーバ］
まず管理サーバ１の構成について図２を用いて説明する。図２に示すように、制御部１０に、通信部２０と、入出力部３０と、記憶部４０とがバスを介して接続されている。

制御部１０は、管理サーバ１を制御する機能部であり、例えばＣＰＵ（Central Process Unit）等の演算処理装置により構成されている。制御部１０は、記憶部４０に記憶されている各種プログラムを読み出して実行することにより、各機能を実現している。

通信部２０は、管理サーバ１が外部のネットワークに接続される場合に使われる機能部である。管理サーバ１（制御部１０）は、通信部２０を介して他の端末装置と通信を行うこととなる。なお、ここで通信部２０の一例としては、Ｅｔｈｅｒｎｅｔ（登録商標）に代表されるような有線ＬＡＮのＮＩＣ（Network Interface Card）であったり、ＩＥＥＥ８０２．１１ｂ等の無線ＬＡＮの通信インタフェースであったりと、いずれかの通信回線を利用するものである。

入出力部３０は、管理サーバ１に対して指示を入力したり、状態を表示したりするための機能部である。すなわち、入力装置及び出力装置を備えて構成されており、例えば、入力装置としてキーボードや、出力装置として液晶モニタ等により構成されている。

記憶部４０は、管理サーバ１が処理を実行するのに必要なプログラムや、各種データ等を記憶するための記憶部である。ここで、記憶部４０は、例えば半導体メモリや、ハードディスクドライブ等の何れかの記憶装置により構成されている。

（記憶部の構成）
ここで、記憶部４０の構成について詳細に説明する。記憶部４０には、建設方式情報４１０と、建設事業者情報４２０と、建設情報４３０と、提案情報４４０と、契約情報４５０と、提案リスト４６０と、契約リスト４７０とが記憶されている。

建設方式情報４１０は、発注者が、建設を発注する場合の基本となる建設スキームを選択する場合に利用される情報である。建設方式情報４１０には、建設スキーム基本情報４１２と、建設スキーム特徴情報４１４と、建設スキームリスク情報４１６とを含めて記憶している。

ここで、建設スキームとは、企画、設計、施工等の建設の基本となる流れを定義するものである。例えば、大枠の基本モデルとしては、一般的なビルを建設する「ビルモデル」、個人宅のような住宅を建設する「住宅モデル」、都市全体を開発・建設する「都市開発モデル」とがあげられる。そして、各基本モデルに対して、建設スキームの中核をなすための「ゼネコンタイプ」「設計事務所タイプ」等があげられる。さらに、ＰＭ／ＣＭ等をどの時点で利用するか、第三者機関を利用するかといった細かい選択モデルがあげられる。

そして、上記のモデルを組み合わせることにより、大枠となる建設スキームが構築される。この、建設スキームを決定する場合に利用される建設方式情報４１０の一例を図３に示す。図３に示すように、建設方式情報４１０は、建設スキームの基本モデル（例えば「ビルモデル」）に対応づけて、施工方式の大枠となる共通タイプ（例えば、「ゼネコンタイプ」）とが記憶されている。

この、共通タイプを選択した場合の特徴と、リスクについて、特徴コードと、リスクコードとがそれぞれ選択されている。特徴コードは、後述する建設スキーム特徴情報４１４に記憶されているコードであり、リスクコードは、後述する建設スキームリスク情報４１６に記憶されているコードである。

また、更に建設スキームは複数の選択タイプが記憶されており、発注者が選択可能となっている。選択タイプに対応づけて、当該基本モデル、共通タイプ、選択タイプに対応する建設スキームが、建設スキームコードとして記憶されている。また、選択タイプに対応づけて、当該選択タイプを選択した場合の特徴とリスクについてが、特徴コード及びリスクコードとして記憶されている。

ここで、建設スキームコードは、建設スキーム基本情報４１２に記憶されているコードである。建設スキーム基本情報４１２のデータ構造の一例を図４に示す。図４に示すように、建設スキームコードに対応づけて建設スキーム項目が記憶されている。この、建設スキーム項目に基づいて、建設スキームが作成され、発注端末に送信・表示されることになる。

ここで、建設スキームとは、建設の流れ、方式をモデル化したものである。すなわち、建設プロジェクトは、当該建設スキームに従って構築されることとなる。

また、この建設スキーム項目については、項目の入れ替え、削除等が可能となる。これにより、発注者はより適切な建設スキームを作成したり、検討したりすることが可能となる。

また、建設スキーム特徴情報４１４のデータ構造の一例を図５に示す。図５に示すように、建設スキーム特徴情報４１４は、特徴コード（例えば、「ＳＡ−０１」）に対応して、特徴の内容（例えば、「基本設計のコスト…」）が記憶されている。

また、建設スキームリスク情報４１６のデータ構造の一例を図６に示す。図６に示すように、建設スキームリスク情報４１６は、リスクコード（例えば、「ＲＡ−０１」）に対応して、リスクの内容（例えば、「基本設計完了時の見積り価格が…」）が記憶されている。

建設事業者情報４２０は、建設事業者に関する情報を記憶している。この建設事業者情報４２０のデータ構造の一例を図７に示す。図７に示すように、建設事業者情報４２０には、会社名（例えば、「○○建設」）と、当該建設事業者の所在地（例えば、「東京都ＸＸ区ＹＹ１−２」）と、設立時期（例えば、「１９９０年５月」）と、資本金（例えば、「５０００万円」）と、当該建設事業者の法人基本情報とが記憶されている。

ここで、建設事業者情報４２０に記憶されている事項は、建設事業者に関する情報であって、発注者等が建設事業者選定時の参考となる項目の情報が記憶されて入ればよい。また、この建設事業者情報４２０は、建設事業者が更新出来ることとしても良いし、第三者機関が更新したり、通信社等の機関から配信されたり等、いずれの更新方法を用いても良い。

建設情報４３０は、発注者が発注する工事に関する種々の情報を記憶している。本実施形態の場合は、一例として図８に示すように、建設予算（例えば、「１億円」）と、建設規模（例えば、「５〜８階建ビル」）と、建設期間（例えば、「２０１２年夏完成」）と、建設場所（例えば、「ＢＢ県ＣＣ市ＤＤ２−５」）と、建設面積（例えば、「○○○○ｍ^２」）と、ＰＭ等を利用するか否かの情報（例えば、「希望する」）とを記憶している。これらの建設情報４３０は、建設事業者が建設規模を把握したり、予算を算定したりする場合に必要となる情報が含まれているものとする。

提案情報４４０は、提案リストや契約リストを生成するときの基本となる項目が記憶されている情報である。提案情報４４０は、基本管理項目情報４４２と、仕様管理項目情報４４４とを含んで構成されている。

基本管理項目情報４４２は、工事に関する基本となる管理項目が記憶されている。例えば、図９に示すように、仕様管理項目（例えば、「設計予算書の作成」）に対して、建設事業者が保証すべき項目（例えば、「１ 建設工事予算の範囲内にて設計」）と、配点（例えば、「１０」）とが記憶されている。

ここで、配点の詳細については後述するが、それぞれの管理項目に割り当てられている素点であり、当該配点に基づいて、評価点数が算出されることとなる。

仕様管理項目情報４４４は、工事に関する仕様の項目が記憶されている。例えば、図１０に示すように、各仕様（例えば「構造」）について、取るべき仕様（例えば、「耐震構造」「免震構造」「制震構造」）と、各構造のレベル（例えば、耐震構造の「Ｉ」「ＩＩ」「ＩＩＩ」）と項目が分かれており、それぞれに配点が付されている。

また、選択可能な仕様管理項目も併せて記憶されている。例えば、設備（環境設備）に対して、「ＬＥＤ照明」「太陽光発電」「雨水利用」…等が選択可能であり、各仕様を選択することにより、割り当てられた配点が加算されることとなる。

契約情報４５０は、発注者が提案リスト等の提案項目に対して重みが記憶されている。すなわち、発注者の希望する重要度に応じて重みを記憶することにより、適切な計算を行うことが可能となる。

ここで、基本管理項目情報４４２に対応する重みが基本管理項目重み情報４５２（図１１）と、仕様管理項目情報４４４に対応する重みが仕様管理項目重み情報４５４（図１２）とが記憶されている。

なお、本実施形態においては、当該重みは発注者が設定することとするが、例えばＰＭ／ＣＭ等を含めた発注者、建設事業者以外の第三者機関が設定することとしても良い。また、本実施形態については、重みを「０」と設定することにより、当該基本管理項目／仕様管理項目は非選択の項目として処理されることとなる。

続いて、提案リスト４６０は、各建設事業者が作成した事業者別提案リストに基づいて生成されるリストであり、契約リスト４７０は、各建設事業者が作成した事業者別契約リストに基づいて生成されるリストである。

一例として、提案リスト４６０について説明する。まず、提案情報４４０から生成される提案テンプレートに基づいて、各建設事業者は事業者別提案リストを作成する。そして、管理サーバ１は、事業者別提案リストから算出される評価点数（本実施形態においては基本管理項目から算出される「基本点数」、仕様管理項目から算出される「仕様点数」）を含めて提案リスト４６０を生成する。

図１３に提案リスト４６０の一例を示す。図１３に示すように、建設事業者毎に、各管理項目（基本管理項目及び仕様管理項目）に対して、それぞれ建設事業者が選択した属性が記憶されている。

さらに、当該選択した属性に基づいて算出された評価点数が、併せて記憶されている。基本管理項目の選択された管理項目の属性に基づいて算出された点数を「基本点数」、仕様管理項目の選択された管理項目の属性に基づいて算出された点数を「仕様点数」として、それぞれ記憶している。

さらに、契約リスト４７０は、提案リストに基づいて、発注者が必要と判断した管理項目を選択し、当該選択された管理項目に基づいて生成されるリストである。

［１．２．２ 発注端末及び事業者端末］
続いて、発注端末３及び事業者端末５について説明する。ここで、発注端末３及び事業者端末５は、従来からの通信端末（例えば、パーソナルコンピュータ等）であればよい。すなわち、制御部に、入出力装置や、記憶装置、通信装置等が接続されている端末となる。

必要なリストや情報については、出力装置（例えば、液晶ディスプレイ）に表示され、発注者や建設事業者からは必要な情報が入力装置（例えば、キーボード等）から入力されれば良い。

また、管理サーバ１とは、通信装置（例えば、ＮＩＣ等）を介して接続されるネットワークと通信路が確立されれば良い。ここで、データの送受信としては、専用のソフトをインストールして実行することとしても良いし、ＷＥＢブラウザ上で操作できることとしても良い。

また、発注端末３及び事業者端末５では、動作に必要なプログラムやデータを記憶装置に記憶しており、随時読み出したり、記憶したりすることができる。なお、本実施形態においては、事業者端末５においては、一建設事業者分の提案リストである事業者別提案リスト、一建設事業者分の契約リストである事業者別契約リストが記憶される。

また、発注端末３においても、管理サーバから送信される提案リスト４６０や、契約リスト４７０が記憶装置に記憶されることとなる。

これら一連の動作処理については、従来の端末装置（例えば、コンピュータ等）と変わらないため、その詳細な説明を省略する。

［１．３ 処理の流れ］
続いて本実施形態における建設受発注システム１００の処理の流れについて説明する。

［１．３．１ 提案リストの生成処理］
まず、管理サーバ１が提案リストを生成する場合の処理について、図１４を用いて説明する。まず、管理サーバ１は、発注端末３から提案要求を受信する（ステップＳ１０）。ここで、提案要求には、発注者が選択した建設事業者を示す選択建設事業者情報と、管理項目に対する重み情報とが含まれているものとする。

なお、説明の都合上、重み情報について併せて説明するが、選択建設事業者情報と異なるタイミングで管理サーバ１に送信されることとしても良いことは勿論である。

続いて、ステップＳ１０において受信された提案要求及び提案情報４４０に基づいて提案テンプレートを生成する（ステップＳ１２）。そして、生成された提案テンプレートを、選択された建設事業者の事業者端末５にそれぞれ送信する（ステップＳ１４）。

ここで、管理サーバ１は、事業者端末５により作成された事業者別提案リストを受信する（ステップＳ１６）。そして、ステップＳ１４において送信した総ての建設事業者の事業者端末５から、事業者別提案リストを受信した場合には（ステップＳ１８；Ｙｅｓ）、受信された事業者別提案リストと、契約情報４５０（基本管理項目重み情報４５２及び仕様管理項目重み情報４５４）とに基づいて、評価点数（基本点数、仕様点数）を算出する（ステップＳ２０）。

ここで、評価点数の算出方法について種々の方法が考えられるが、本実施形態においては、一例として各管理項目のうち、選択された管理項目に割り当てられている点数（配点）に、契約情報４５０に記憶されている重みを乗算し、それらの総和にて評価点数を算出することとする。また、管理項目によっては、選択された管理項目の属性にしたがって、点数（配点）を用いることとなる。

例えば、図９に示す「基本計画案の確定」については、図１１を参照すると重みが「１．５」と設定されている。これは、発注者が「基本計画案の確定」については、標準（１．０）より、重要であることを表している。

したがって、基本管理項目における「基本計画案の確定」の属性として「１」が選択された場合は１５点（１０×１．５）が加算され、「２」が選択された場合は１２点（８×１．５）が加算されることとなる。このように総ての管理項目に対しての点数を計算し、総和を求めることで評価点数である「基本点数」「仕様点数」を算出する。

なお、ここで説明した算出方法は一例であり、例えば標準偏差を用いる方法であったり、過去の蓄積データから点数を回帰分析にて求める方法であったり、ＡＨＰ法等による階層分析を用いる方法であったりしても良い。

また、事業者別提案リストに基づいて、全体の提案リスト４６０を生成する（ステップＳ２２）。そして、提案リスト４６０に、上述した方法で算出された基本点数及び仕様点数を併せて記憶する（ステップＳ２４）。

そして、このようにして生成された提案リスト４６０を、発注端末３に送信する（ステップＳ２６）。これにより発注端末３において、提案リストが表示されることとなる。この提案リストは、建設事業者毎に、選択した管理項目の内容が表示されることとなり、発注者は当該管理項目に基づいて、建設事業者を選定することができる。

さらに、基本点数及び仕様点数が評価点数として表示されることにより、例えば発注者が建設関係者ではない一般人であっても、どの建設事業者が希望する施工条件に対してより適切であるかを容易に判定することが出来る。

［１．３．２ システムの流れ］
次に、管理サーバ１、発注端末３及び事業者端末５を含む建設受発注システム全体の流れについて、シーケンス図を用いて説明する。なお、本来、事業者端末５は、建設事業者数分システムに存在しているが、説明の都合上、一つのみ記載している。

まず、事業者端末５と管理サーバ１とは、通信を行うことにより建設事業者は建設事業者情報４２０を更新出来る（図１５のＳ１００）。

ここで、発注端末３から建設情報が入力され（Ｓ１１０）、発注端末３から管理サーバ１に建設情報４３０が送信される（Ｓ１１２）。管理サーバ１は、建設情報４３０を受信すると、建設方式情報４１０を発注端末３に送信する（Ｓ１１４）。ここで、管理サーバ１は受信された建設情報４３０に対応して建設方式情報４１０を抽出して送信することとしてもよい。

発注端末３は、受信された建設方式情報に基づいて、発注者に建設スキーム（建設方式）を選択させる（Ｓ１１６）。そして、選択された建設方式が、建設方式選択情報として管理サーバ１に送信される（Ｓ１１８）。

ここで、発注端末３には、建設方式情報に基づいて建設スキームが表示され、併せて選択可能な建設タイプが表示されている。さらに、受信された特徴コードに基づく特徴の内容及び当該建設タイプを選択した場合のリスクコードに基づくリスクの内容が表示されている。これにより、発注者は建設方式を選択する場合に、特徴点やリスクを容易に判定することが可能となる。

なお、建設方式については、送信されてきた建設方式を選択するだけでなく、例えば建設スキームを発注者が変更（カスタマイズ）出来ることとしてもよい。これにより、発注者が希望する建設方式が適切に選択されることとなる。

管理サーバ１は、受信された建設情報及び建設方式選択情報に基づいて、各建設事業者の事業者端末５に建設参加要求を送信する（Ｓ１２０）。事業者端末５では、建設情報及び選択された建設方式が表示され、当該工事（建設）に参加するか否かを選択する。そして、建設に参加するか否かを選択した情報を、建設参加応答として送信する（Ｓ１２４）。

管理サーバ１は、受信された建設参加応答に基づいて、建設事業者リストを生成する（図１６のＳ２００）。生成された建設事業者リストは、建設事業者リストとして発注端末３に送信される（Ｓ２０２）。

発注端末３は、受信された建設事業者リストから、建設事業者リストを表示し、発注者に提案リストを要求する建設事業者を選択させる（Ｓ２０４）。また、併せて当該建設方式において表示される基本管理項目及び仕様管理項目の重みの情報（重み情報）を入力する（Ｓ２０６）。この基本管理項目及び仕様管理項目の重みを発注者が設定することにより、発注者が意図を反映した提案リストを要求することが可能となる。

発注端末３より入力された情報を、提案要求に含めて管理サーバ１に送信する（Ｓ２０８）。管理サーバ１は、提案要求に基づいて提案テンプレートを生成し（Ｓ２１０）、当該提案テンプレートを各建設事業者の事業者端末５に送信する（Ｓ２１２）。

事業者端末５は、受信された提案テンプレートに基づいて事業者別提案リストを作成する（Ｓ２１４）。具体的には、提案テンプレートに記憶されている管理項目に対して、建設事業者が実施可能な項目、内容である属性それぞれ登録していくことになる。

各建設事業者の事業者端末５により、事業者別提案リストが管理サーバ１に送信され（Ｓ２１６）、管理サーバ１は提案リストを生成する（Ｓ２１８）。そして、生成した提案リストを発注端末３に送信する（Ｓ２２０）。ここで、生成される提案リストには、事業者別提案リストに基づいて算出された各建設事業者の基本点数と、仕様点数とが併せて記憶されている。

発注端末３は、提案リストを表示し発注者に契約テンプレートに使用する項目を選択させる（Ｓ２２２）。すなわち、提案リストは、多くの管理項目が表示されているため、不必要な管理項目を削ったり、重要度を調整したりすることが出来る。そして、契約テンプレートに使用する項目が選択されると、契約要求として管理サーバ１に送信される（Ｓ２２４）。

管理サーバ１は、受信された契約要求から契約テンプレートを生成し（図１７のＳ３００）、契約テンプレートを各建設事業者の事業者端末５に送信する（Ｓ３０２）。事業者端末５は、事業者別契約リストを作成し（Ｓ３０４）、作成された事業者別契約リストを管理サーバ１に送信する（Ｓ３０６）。

ここで、Ｓ３０４において作成される事業者別契約リストは、入力可能な管理項目が、契約要求に基づいたものである点を除いては図１６のＳ２１４において作成される事業者別提案リストと同じものである。

管理サーバ１は、受信された事業者別契約リストから、契約リストを生成し（Ｓ３０８）、契約リストを発注端末３に送信する（Ｓ３１０）。ここで、契約リストには、事業者別契約リストで入力された管理項目の属性に基づいて算出された基本点数と仕様点数とが併せて記憶されている。

発注端末３は、受信された契約リストを表示し、発注者に建設事業者を決定させる。そして、建設事業者が決定すると（Ｓ３１２）、決定された建設事業者を決定建設事業者として管理サーバ１に送信する（Ｓ３１４）。管理サーバ１は、各建設事業者の事業者端末５に対して、決定建設事業者を送信する（Ｓ３１６）。ここで、決定建設事業者に選択された建設事業者は、契約処理を開始することとなる（Ｓ３１８）。

建設事業者が決定した後のシステムのモデルについて図１８に示す。図１８には、発注者と、建設事業者（例えば、本図ではゼネコン）と、専門工事事業者とが記載されている。このようなモデルを適用することで、ゼネコンが決定した後も適切な建設（工事）を進めることができる。

［２．第２実施形態］
続いて、第２実施形態について説明する。第２実施形態は建設事業者を決定する場合に更に金額の情報を用いる実施形態（いわゆる逆オークション方式）について説明する。

すなわち、図１９に示すように、提案リストの各項目に工事金額が含まれている。各建設事業者が、管理項目において提案した内容を、どの程度の金額で受注可能かを示している。

これは、例えば、図１６のＳ２１４の段階において、各建設事業者は、事業者別提案リストを作成するときに、管理項目の属性を選択したときに、当該属性を受注可能な金額を入力する。そして、事業者別提案リストに含め、Ｓ２１６により管理サーバ１に送信される。

管理サーバ１は、各建設事業者により入力された管理項目毎の工事金額と、工事金額の合計を提案リストに含めて発注端末３に送信する。これにより、発注者は各建設事業者の工事金額を参照することができ、すなわち逆オークションのような方式を採用することが出来る。

さらに、Ｓ２２２において、契約テンプレートに工事金額を含めることにより、他の建設事業者に対して、工事金額を提示することが出来る。建設事業者は、工事金額と管理項目の属性（工事内容）とを比較し、再度工事金額を決定するといったことが可能になる。

このように、本実施形態によれば、建設の内容と合わせて金額が明確になるため、透明性の高い建設の発注を行うことができる。これにより、発注者側の期待と、建設事業者側の意識とが擦り合わされることになるため、意識のズレが生じにくく、金額面も含めて、適切な建設の発注を行うことが可能となる。

［３．変形例］
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。

なお、上述の実施形態において、図１６のＳ２１８にて生成される提案リストを各事業者端末５に送信しても良い。これにより、各建設事業者は、他の建設事業者がどのような提案リストを作成しているかを把握することができ、他の内容に変更することができる。すなわち、他の建設事業者との競争原理が働くことにより、発注者にとってより良い提案リストが生成されることが期待出来る。

また、上述の実施形態においては、管理項目を選択することにより評価点数を算出し、当該算出された点数に基づいて発注者はリスク評価が出来ることとして説明したが、例えば各管理項目に対して、具体的な方針を提供することとしても良い。

具体的には、図２０及び図２１にロジックプロセスとして示す。図に示すように、管理項目に対して各建設事業者のセクションにおいて発注者とＰＭ・ＣＭ方式を用いて、ハード及びソフトに関わる建設事業者（関係者）とコミュニケーションをとりながら透明性及び客観性を保ちつつ実現の可否をテキストで入力させる。そして、当該データを建設事業者から管理サーバ１を介して発注端末３に送信する。ここで、図２０はハードに関する管理項目を、図２１はソフトに関する管理項目を記載したものである。

発注者は、発注端末３に表示されるリスク内容により、リスク評価を行い、これに基づいて各建設事業者に対して要望など行うことが可能となる。

また、発注端末３が建設事業者を選択した段階で、管理サーバ１に選択した建設事業者を送信しても良い。具体的には、図１６のＳ２０４で建設事業者を選択後、管理サーバ１に選択された建設事業者を送信する。管理サーバ１は、受信した建設事業者に関する情報を事業者端末５に送信することとなる。

ここで建設事業者は、発注者が当該建設事業者を選択したか否かの情報であったり、他の選択された建設事業者に関する情報について入手することができる。

また、第三者により管理サーバ１にアクセスし、提案リスト等を参照出来ることとしても良い。すなわち、提案リストによる情報を、管理サーバ１がＷＥＢ上に公開することにより、第三者が参照出来ることとしても良い。また、この場合に、管理サーバ１は認証を行うこととしても良い。この場合、提案リストを参照できる者は認証された者に限られることとなる。

また、発注リスト等により入力されたデータについては、公開範囲を設定することが可能である。すなわち、建設方式までを公開するといった場合や、工事の金額に関する情報については、他の事業者に非公開とするといった、種々の場合が考えられることは勿論である。

また、上述した実施形態においては、建設の一例として新築を例にして説明したが、例えば改修や解体工事、土木工事といった他の建設・工事であっても適用可能であることは勿論である。

１ 管理サーバ
１０ 制御部
２０ 通信部
３０ 入出力部
４０ 記憶部
４１０ 建設方式情報
４１２ 建設スキーム基本情報
４１４ 建設スキーム特徴情報
４１６ 建設スキームリスク情報
４２０ 建設事業者情報
４３０ 建設情報
４４０ 提案情報
４４２ 基本管理項目情報
４４４ 仕様管理項目情報
４５０ 契約情報
４５２ 基本管理項目重み情報
４５４ 仕様管理項目重み情報
４６０ 提案リスト
４７０ 契約リスト
３ 発注端末
５ 事業者端末

Claims (4)

1. 発注者が使用する発注端末と、建設事業者が使用する事業者端末とが接続される管理サーバを含む建設受発注システムにおける管理サーバであって、
   管理項目と、管理項目に対する配点とを提案情報として記憶する記憶手段と、
   前記発注端末から、管理項目に対応する重み情報を含む提案要求を受信する提案要求受信手段と、
   前記事業者端末から、管理項目の中から選択項目を受信し、当該選択項目の配点と、前記選択項目に関する重みから評価点数を算出する評価点数算出手段と、
   前記評価点数算出手段により算出された評価点数を含めた提案リストを生成する提案リスト生成手段と、
   前記提案リストを、前記発注端末に送信する提案リスト送信手段と、
   を備えることを特徴とする管理サーバ。
2. 前記提案リストには、前記事業者端末から受信された選択項目が含まれていることを特徴とする請求項１に記載の管理サーバ。
3. 前記提案リストを送信した後に、前記発注端末から必要となる管理項目が選択された情報を含む契約要求を受信する契約要求受信手段を更に有し、
   前記契約要求に含まれる管理項目に対し評価点数を算出し、当該管理項目と評価点数を含む契約リストを生成して送信することを特徴とする請求項１又は２に記載の管理サーバ。
4. 発注者が使用する発注端末と、建設事業者が使用する事業者端末とが接続される建設受注管理サーバを含む建設受発注システムにおいて、
   前記管理サーバは、
   管理項目と、管理項目に対する配点とを提案情報として記憶する記憶手段と、
   前記発注端末から、管理項目に対応する重み情報を含む提案要求を受信する提案要求受信手段と、
   前記事業者端末から、管理項目の中から選択項目を受信し、当該選択項目の配点と、前記選択項目に関する重みから評価点数を算出する評価点数算出手段と、
   前記評価点数算出手段により算出された評価点数を含めた提案リストを生成する提案リスト生成手段と、
   前記提案リストを、前記発注端末に送信する提案リスト送信手段と、
   を備えたことを特徴とする建設受発注システム。

Images