特開 2024-24679 取引情報管理サーバ、取引情報管理システム、取引情報管理方法、取引情報管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024024679

(43)【公開日】2024-02-22

(54)【発明の名称】取引情報管理サーバ、取引情報管理システム、取引情報管理方法、取引情報管理プログラム

(51)【国際特許分類】

   G06Q 50/08 20120101AFI20240215BHJP

   G06Q 50/26 20240101ALI20240215BHJP

【ＦＩ】

G06Q50/08

G06Q50/26

【審査請求】未請求

【請求項の数】19

【出願形態】ＯＬ

(21)【出願番号】P 2023219243

(22)【出願日】2023-12-26

(62)【分割の表示】P 2023537113の分割

【原出願日】2023-02-14

(31)【優先権主張番号】P 2022021990

(32)【優先日】2022-02-16

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】522061833

【氏名又は名称】株式会社ＧＡＣＣＩ

(74)【代理人】

【識別番号】110003937

【氏名又は名称】弁理士法人前川知的財産事務所

(72)【発明者】

【氏名】若本 憲治

(57)【要約】

【課題】公共工事の入札等に関する元請と下請の間の見積書の調整作業の効率を向上させる。
【解決手段】取引情報管理サーバ２は、工事入札のために元請事業者と下請事業者との間の少なくとも見積に関する取引情報を管理するサーバであって、工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶部１０と、元請グループ情報に含まれる下請事業者に対し、元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理部２１と、を備え、見積情報管理部２１は見積費目ごとに見積単価の登録を受け付ける。
【選択図】 図２

【特許請求の範囲】

【請求項1】

工事入札のために元請事業者と下請事業者との間の少なくとも見積に関する取引情報を管理する取引情報管理サーバであって、
工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶部と、
前記元請グループ情報に含まれる下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理部と、
を備え、
前記見積情報管理部は前記見積費目ごとに見積単価の登録を受け付ける、
取引情報管理サーバ。

【請求項2】

前記見積情報管理部は、前記元請グループ情報に含まれるすべての下請事業者に対し、前記元請毎入札情報の前記複数の見積費目のすべてについて見積単価の登録を許可する、
請求項１に記載の取引情報管理サーバ。

【請求項3】

前記見積情報管理部は、前記元請グループ情報に含まれる下請事業者のうち前記元請が選択した下請事業者に対し、前記元請毎入札情報の前記複数の見積費目のうち前記元請事業者が選択した範囲で見積単価の登録を許可する、
請求項１に記載の取引情報管理サーバ。

【請求項4】

前記見積情報管理部は、前記元請事業者に対して、前記元請毎入札情報について見積単価の登録のない見積費目及び見積単価の登録が複数ある見積費目をそれぞれ識別可能に表示する、
請求項１から３のいずれかに記載の取引情報管理サーバ。

【請求項5】

前記元請毎入札情報は設計図面、積算書類、仕様書を含む、
請求項１から４のいずれかに記載の取引情報管理サーバ。

【請求項6】

前記元請毎入札情報について全体の原価を算出する価格算出部をさらに備える、
請求項１から５のいずれかに記載の取引情報管理サーバ。

【請求項7】

前記価格算出部は、さらに、前記元請事業者の過去の前記元請毎入札情報、落札結果、前記元請グループ情報に含まれる下請事業者との取引実績に基づいて学習したモデルを用いて、前記元請事業者に見積単価の推奨額を提示する、
請求項６に記載の取引情報管理サーバ。

【請求項8】

前記価格算出部は、さらに、前記原価の予想額を算出する、
請求項６または７に記載の取引情報管理サーバ。

【請求項9】

前記工事入札の落札状況に応じて、前記見積情報管理部は、前記元請グループ情報に含まれる下請事業者に対し再度見積依頼を実行する、
請求項１から８のいずれかに記載の取引情報管理サーバ。

【請求項10】

チャットをしながら共同編集できる、
請求項１から９のいずれかに記載の取引情報管理サーバ。

【請求項11】

前記公共事業は土木建設工事に関する、
請求項１から１０のいずれかに記載の取引情報管理サーバ。

【請求項12】

工事入札のために元請事業者と下請事業者との間の見積に関する取引情報を管理する取引情報管理システムであって、
工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶部と、
前前記元請グループ情報に含まれる下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理部と、
を備え、
前記見積情報管理部は前記見積費目ごとに見積単価の登録を受け付ける、
取引情報管理システム。

【請求項13】

コンピュータが、工事入札のために元請事業者と下請事業者との間の見積に関する取引情報を管理する取引情報管理方法であって、
工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶工程と、
前記元請グループ情報に含まれる下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理工程と、
を備える取引情報管理方法。

【請求項14】

工事入札のために元請事業者と下請事業者との間の見積に関する取引情報の管理をコンピュータに実行させる取引情報管理プログラムであって、
工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶工程と、
前記元請グループ情報に含まれる下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理工程と、
をコンピュータに実行させる取引情報管理プログラム。

【請求項15】

工事入札のために元請事業者と下請事業者と発注者との間の少なくとも見積に関する取引情報を管理する取引情報管理サーバであって、
前記工事入札と発注者とを紐づけた入札情報と、前記入札情報に含まれ、前記工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請事業者を含む元請グループ情報と、を記憶する記憶部と、
前記元請グループ情報に含まれる前記下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理部と、
を備え、
前記見積情報管理部は前記見積費目ごとに見積単価の登録を受け付ける、
取引情報管理サーバ。

【請求項16】

前記入札情報を出力する出力管理部をさらに備え、
前記見積情報管理部は、前記工事入札の落札結果に基づいて、前記元請毎入札情報から前記元請事業者に紐づく元請受注後情報を生成し、
前記出力管理部は、前記元請受注後情報に基づいて受注工事明細を元請端末に出力する、
請求項１５に記載の取引情報管理サーバ。

【請求項17】

前記見積情報管理部は、前記工事入札の落札結果に基づいて、前記入札情報から前記元請事業者に見積を採用された下請事業者に紐づく下請受注後情報を生成し、
前記出力管理部は、前記下請受注後情報に基づいて受注工事明細を下請端末に出力する、
請求項１６に記載の取引情報管理サーバ。

【請求項18】

前記元請事業者と前記下請事業者と前記発注者との間の少なくとも二者間でのマッチングを支援するマッチング管理部をさらに備える、
請求項１５に記載の取引情報管理サーバ。

【請求項19】

前記出力管理部は、前記元請毎入札情報に基づいて分析グラフを出力する、
請求項１６に記載の取引情報管理サーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、取引情報管理サーバ、取引情報管理システム、取引情報管理方法、取引情報管理プログラムに関する。

【背景技術】

【0002】

官公庁等の行政機関が公共工事を外部に委託発注する場合、まず、工事の仕様等を公告し、いわゆる元請と言われる委託受注希望業者からの入札により委託先を決定する。このような公告情報を収集し元請に提供するサービスが存在する。例えば、特許文献１には、各都道府県、市町村、あるいは国の各省庁や道路公団等の公共機関が発注する公共事業に係わる入札関連情報を集約して元請等に提供し、提供する情報量に応じて課金する公共事業情報提供システムが記載されている。

【0003】

また、元請は、施工を行う下請に対し、公告された公共工事の工事内容を細分化した費目について見積を依頼し、提出された見積価格に基づいて下請の選定を行う。このような下請の選定において、見積を依頼する前に下請を評価し、適切な下請に対して見積を依頼する技術が提案されている（特許文献２参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００４－２１３２４７号公報

【特許文献2】特開２０１５－１０２９９６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、公共工事について公告される情報には、入札に関する情報として、設計情報、仕様情報、及び、費目と費目ごとの見積単価を含む積算情報の３つの情報が含まれる。これら３つの情報はそれぞれ、表計算形式やＰＤＦ形式のファイルで提供される。元請が下請に見積を依頼する場合、これらの３つの情報ファイル一式をそのまま見積を依頼したい全ての下請にメール等で送付することが慣例的に行われている。下請は、図面等の設計情報及び仕様情報を確認し、積算情報ファイルの全ての費目のなかから、自社が施工を希望する（または自社の事業領域で施工可能な）費目についてのみ見積書を作成し、積算ファイルの該当する費目の見積単価に入力して、元請にファイル一式と見積書を返送する。元請は、返送された複数の積算ファイル同士を突き合わせて、費目ごとに採用する見積単価と下請を決定し、統合することで工事原価を集計する積算作業を行う。

【0006】

この慣例的な手順においては、各下請における見積作成作業は、積算ファイルに含まれる膨大な費目から、施工を希望する（見積を提出したい）費目を抽出し、転記して見積書を作成するため非効率となっている。また、元請における積算作業は、各下請に見積の範囲を指定せず、また下請側同士で事業領域が重なる場合もあるため、複数の下請から返送された全積算ファイルを統合しても、費目によって、見積が１社からも提出されていない（抜け）ことや、逆に必要以上に複数の下請から見積の提出がある（被り）ことが頻繁に発生する。このような場合、元請は抜けや被りのあった費目について、見積の再依頼や採用下請及び採用単価の選定などの調整作業を行うことになり、非効率となっている。

【0007】

本開示は、このような問題点を解決するためになされたもので、公共工事の入札等に関する元請と下請の間の見積書の調整作業の効率を向上させることができる取引情報管理サーバ、取引情報管理システム、取引情報管理方法、取引情報管理プログラムを提供することを目的としている。

【課題を解決するための手段】

【0008】

上記した目的を達成するために、本開示に係る取引情報管理サーバは、工事入札のために元請事業者と下請事業者との間の少なくとも見積に関する取引情報を管理する取引情報管理サーバであって、工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶部と、前記元請グループ情報に含まれる下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理部と、を備え、前記見積情報管理部は前記見積費目ごとに見積単価の登録を受け付ける。

【発明の効果】

【0009】

上記手段を用いる本開示によれば、公共工事の入札等に関する元請と下請の間の見積書の調整作業の効率を向上させることができる。

【図面の簡単な説明】

【0010】

【図1】本開示の第１実施形態に係る取引情報管理システムのネットワーク構成を示す図である。

【図2】本開示の第１実施形態に係る取引情報管理サーバの主な構成を示すブロック図である。

【図3】第１実施形態の取引情報管理サーバに記憶される登録ユーザ情報の例をまとめた表である。

【図4】取引情報管理サーバに記憶される入札情報の例をまとめた表である。

【図5】積算処理ルーチンを示すフローチャートである。

【図6】費目ステータス判定ルーチンを示すフローチャートである。

【図7】元請費目別一覧表示ルーチンを示すフローチャートである。

【図8】元請端末に表示される入札情報の表示例である。

【図9】図８において見積単価が複数登録された費目について詳細を展開表示した表示例である。

【図10】図９において複数登録された見積単価のひとつを選択した後の画面の表示例である。

【図11】下請端末に表示される入札情報の表示例である。

【図12】本開示の第２実施形態に係る取引情報管理システムのネットワーク構成を示す図である。

【図13】本開示の第２実施形態に係る取引情報管理サーバの主な構成を示すブロック図である。

【図14】第２実施形態の取引情報管理サーバに記憶される登録ユーザ情報の例をまとめた表である。

【図15】第２実施形態の取引情報管理サーバに記憶される入札情報の例をまとめた表である。

【図16】第２実施形態の端末に表示される受注工事明細の表示例である。

【図17】第２実施形態の端末に表示される実行予算の予実管理情報の表示例である。

【図18】第２実施形態の端末に表示される分析グラフの表示例である。

【図19】本開示の実施形態に係るコンピュータの構成を示す概略ブロック図である。

【発明を実施するための形態】

【0011】

以下、本開示の実施形態を図面に基づき説明する。

【0012】

（第１実施形態）
まず本開示の第１実施形態について説明する。

【0013】

＜構成＞
図１は、本開示の第１実施形態に係る取引情報管理システムのネットワーク構成を示す図である。図２は、本開示の第１実施形態に係る取引情報管理サーバの主な構成を示すブロック図である。

【0014】

取引情報管理システム１は、主として公共事業である土木建設工事の入札に関し、ユーザ間で発生する見積や発注に関する取引情報をクラウド上で取りまとめて管理することができる取引情報管理サービスを提供するシステムである。取引情報管理システム１のユーザは、主に、建設会社等の元請（以下単に元請という）と施工会社等の下請事業者（以下単に下請という）である。取引情報管理サーバ２において、元請は、取引を行う下請をあらかじめグループ登録しておき、入札を行いたい公告がある場合に、当該元請に紐づく入札情報を作成して、グループ登録した下請に一斉に見積依頼を行う。複数の元請が、同じ公告情報について各元請に紐づく入札情報を作成することができる。見積依頼を受け取った下請は、取引情報管理サーバ２の指定された入札情報にアクセスし、費目単位で見積単価を入力して取引情報管理サーバ２に登録できる。取引情報管理サーバ２は、登録された見積単価に基づいた積算価格（工事原価）を算出し、元請に提示する。元請は、提示された積算価格に自社の利益を上乗せして入札提出価格を決定する。このように、取引情報管理システム１は、見積業務の効率化により、主要人材の時間が確保されたり、積算価格の分析や精度を向上する時間を確保したりできることで、元請及び下請の両者が公共工事ごとの利益を安定して獲得するために利用される。

【0015】

図１に示すように、本実施形態に係る取引情報管理システム１は、取引情報管理サーバ２、公告配信サーバ３、元請端末４、及び、下請端末５がネットワークＮＷを介して相互に通信可能に接続されて構成されている。取引情報管理サーバ２は、取引情報管理サービスを提供する事業者が運用するサーバである。公告配信サーバ３は、官公庁や地方自治体等が公告情報を配信するサーバである。元請端末４は、取引情報管理サービスを利用する元請が使用する端末装置である。下請端末５は、同じく取引情報サービスを利用する下請が使用する端末装置である。なお、説明の簡略化のため図１では公告配信サーバ３、元請端末４、下請端末５をそれぞれ1つのみ示しているが、それぞれ複数であってもよい。すなわち、異なる複数の官公庁等の公告配信サーバ３、異なる複数の元請の元請端末４、異なる複数の下請の下請端末５であってもよい。また、取引情報管理サーバ２についても、物理的または仮想的に複数のサーバから構成されていてもよい。ネットワークＮＷは、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等である。

【0016】

図２に示すように、取引情報管理サーバ２は、記憶部１０及び処理部２０を備える。記憶部１０は、登録ユーザデータベース１１、及び入札情報データベース１２を含む。以下、データベースをＤＢと表記し、登録ユーザデータベース１１を登録ユーザＤＢ１１、入札情報データベース１２を入札情報ＤＢ１２と表記する場合がある。処理部２０は、見積情報管理部２１、価格算出部２２、下請実績評価部２３、ユーザ管理部２４、制御部２５を備える。これら各部は、取引情報管理サーバ２の内部で相互に通信可能に接続されている。

【0017】

元請端末４及び下請端末５は、例えばＰＣや、スマートフォン、タブレットＰＣ、及び携帯電話のような端末装置であり、それぞれ文字入力手段やマイク等の入力部と表示画面やスピーカー等の出力部を備える。元請端末４及び下請端末５は、取引情報管理サーバ２が提供する動作環境（ＡＰＩ（アプリケーションプログラミングインタフェース）、プラットフォーム等）を利用して取引情報管理サーバ２にアクセスしてもよい。また、端末にインストールされた専用のアプリケーションソフトウェアによって取引情報管理サーバ２にアクセスしてもよい。

【0018】

＜記憶部＞
図３は、取引情報管理サーバに記憶される登録ユーザ情報の例をまとめた表である。図４は、取引情報管理サーバに記憶される入札情報の例をまとめた表である。これらの図を参照しながら、記憶部１０の登録ユーザＤＢ１１及び入札情報ＤＢ１２に含まれる各情報について以下説明する。

【0019】

登録ユーザＤＢ１１は、取引情報管理サービスを利用するユーザに関するユーザ情報を含んでいる。具体的には、図３に示すように、ユーザ情報は、元請に関する元請情報と下請に関する下請情報の２つに分類されている。元請のユーザ情報には、取引情報管理サービスに登録した元請（図３では例として元請Ｘと元請Ｙが記載されている）ごとに、元請ＩＤ、元請名、元請業種、元請信用度、元請入落札実績、元請グループ情報、備考等が含まれる。下請のユーザ情報には、取引情報管理サービスに登録した下請（図３では例として下請Ｓと下請Ｔが記載されている）ごとに、下請ＩＤ、下請名、下請業種、下請信用度、元請毎下請評価、備考等が含まれる。

【0020】

元請ＩＤ及び下請ＩＤは、取引情報管理サーバ２で自動付与される一意な符号等であり、ユーザ認証やデータ紐づけ等に用いられる。元請名、下請名は、それぞれユーザである事業者の名称である。元請業種及び下請業種は、事業領域や、業種であり、ユーザが複数選択することが可能な情報である。元請信用度及び下請信用度は、ユーザの経営事項審査の評点である。なお、経営事項審査とは、官公庁の建設工事入札に参加する業者に義務付けられている、経営に関する客観的事項について受ける審査である。元請入落札実績は、元請が過去に入札した案件についての入落札実績の履歴情報であり、取引情報管理サーバ２で自動生成され更新される。元請グループ情報は、元請に紐づく下請、すなわち元請が取引を行う可能性のある複数の下請群である。元請は、ユーザ登録済みの下請から複数選択して元請グループ情報として登録できる。なお、ユーザ登録されていない下請に対しては、取引情報管理サービス上で登録依頼メッセージを下請に送ることで登録を促すことができる。元請毎下請評価は、下請の見積単価が採用された等の過去の取引実績について、取引情報管理サーバ２により元請及び入札情報に紐づけられて記憶される情報である。

【0021】

元請名、下請名、元請業種、下請業種、及び、元請グループ情報は、取引情報管理サービスのユーザ登録時や利用時にユーザ自身が入力したり、他のクラウドサービスのアカウントと連携することで取得したりしてもよい。また、下請信用度及び元請信用度は、各事業者の信用度を公開している外部サーバから取得してもよい。

【0022】

次に、図４を参照しながら入札情報について説明する。入札情報ＤＢ１２は、公告情報毎に入札情報が記憶されている。入札情報とは、本実施形態では、主に官公庁等が公共土木工事について公告する入札に関する情報であり、公告情報ごと（図４では例として公告情報１と公告情報２が記載されている）に共通入札情報及び元請毎入札情報が作成される。共通入札情報は、入札ＩＤ、入札種別、入札主催者、入札名称、入札公募価格、入札期日、入札ステータス、入札結果が含まれ、公告情報ごとに１組作成される。一方、元請毎入札情報は、元請毎入札情報ＩＤ、設計情報、仕様情報、積算情報、入札価格情報、入落札結果、等が含まれ、元請ごと（図４では例として元請Ｘと元請Ｙが記載されている）に１組作成される。元請毎入札情報ＩＤには、入札ＩＤおよび元請ＩＤが紐づけられている。

【0023】

共通入札情報のうち、入札種別は、例えば、工事、業務、その他、から選択されて記憶される。また、入札ステータスは、例えば、公告、入札受付中、受付終了、入落札結果判明、等から選択されて記憶される。そして、入札結果は、落札した元請の元請ＩＤ、落札額等が記憶される。共通入札情報は、ネットワークＮＷを介して公告配信サーバから自動または運営会社による手動で、随時取得する。

【0024】

元請毎入札情報のうち、設計情報とは、例えば図面等であり、仕様情報とは、公告された公共工事において、図面だけでは表現できない、材料品質や施工手順などを文章で規定する書類等の情報である。積算情報とは、公告された公共工事において必要な材料等を示す「費目（見積費目）」ごとに単位、数量、単価、規格等について規定しそれらをまとめた情報である。

【0025】

積算情報には、費目（図４では例として費目Ａと費目Ｂが記載されている）ごとに、区分、数量、単位、見積単価、再見積単価、備考等が含まれる。見積単価には、下請により登録される下請毎単価（図４では例として下請Ａと下請Ｂが記載されている）、ステータス、元請推奨単価、下請毎推奨単価、採用単価と採用下請、等が含まれる。再見積単価には、見積単価と同様に、下請により登録される下請毎単価（図４では例として下請ａと下請ｂが記載されている）、ステータス、元請推奨単価、下請毎推奨単価、採用単価と採用下請、等が含まれる。元請が入札情報を新規作成した時点では、下請毎単価には、規定値として「０」円が登録されている。

【0026】

見積単価とは、元請が入札申請を提出する前に、下請に見積依頼を行うことにより下請から取得する価格であり、再見積単価とは、元請が落札できた場合に、工事原価の算出をより精度高く行うために採用下請に対し再度見積を依頼して取得する価格である。一般的に入札申請を提出する前の見積単価は、下請側も受注前のため、概算で決められることが多く、その結果、集計した工事原価も概算額となるため、落札後に受注が確定した段階で採用下請に対し正確な見積単価の提出を求め、落札した元請は最終的な工事原価から利益を算出する。以下、単に「下請毎単価」という場合は「見積単価の下請毎単価」を指し、「再見積単価」の「下請毎単価」を指す場合は「再見積単価の下請毎単価」と表記して区別する。

【0027】

こうした公告情報の大部分は、見積単価及び再見積単価を除き、ネットワークＮＷを介して公告配信サーバから自動または運営会社による手動で、随時取得することができる。

【0028】

積算情報のうち、区分は、工事種別、工事内容、作業内容に関する情報である。

【0029】

見積単価のステータスは、「未登録」（下請から下請毎単価の登録がない）、「１件登録あり」（１社から下請毎単価の登録あり）、「複数登録あり」（複数の下請から下請毎単価の登録あり）、及び「採用単価決定」（複数登録された下請毎単価のいずれかが採用であるとして選択されている）等、の下請毎単価の登録状態を示す情報である。元請が入札情報を新規作成した時点では、ステータスの規定値は「未登録」に設定される。見積単価の元請推奨単価は、下請毎単価が複数の下請から登録された場合に、登録された下請毎単価のうち価格算出部２２により最適と判断され提示される（推奨される）単価である。見積単価の下請毎推奨単価は、価格算出部２２により最適と判断され後述する下請画面５０１において提示される（推奨された）単価である。見積単価の採用単価は、下請毎単価が複数の下請から登録された場合、積算に使用する下請毎単価として元請が採用、選択した単価であり、採用下請は、採用された下請毎単価を登録した下請の下請ＩＤである。再見積単価に含まれるステータス、元請推奨単価、下請毎推奨単価、採用単価と採用下請についても見積単価と同様である。

【0030】

元請毎入札情報のうち、入札価格情報は、原価、粗利、入札額を含む。原価、粗利、入札額は、それぞれ見積時予想額、申請額を含む。見積時予想額とは、入札前に、各費目の元請推奨単価又は採用単価に基づいて価格算出部２２が集計した金額であり、申請額は、実際に入札において元請が提出した金額を入力したものである。

【0031】

これら登録ユーザＤＢ１１及び入札情報ＤＢ１２、に記憶される情報は、主にネットワークＮＷを介して外部端末からの入力を取得したり、外部サーバから取得したりすることで随時登録又は更新される。なお、本実施形態では登録ユーザＤＢ１１と入札情報ＤＢ１２を別体としているが、それぞれの情報を一体とし記憶した物理的又は仮想的に一つのデータベースであってもよい。

【0032】

＜処理部の機能＞
図２に戻り、取引情報管理サーバ２の処理部２０の機能について以下説明する。

【0033】

見積情報管理部２１は、入札情報ＤＢ１２に記憶される公告情報を管理する機能を有する。具体的には、見積情報管理部２１は、新規案件作成処理、見積依頼処理、下請毎単価登録処理、費目ステータス判定処理、入札価格算出処理を実行する。これらの処理をまとめて積算処理という。見積情報管理部２１は、積算処理に再見積処理を含めてもよい。

【0034】

見積情報管理部２１は、新規案件作成処理として、元請の元請端末４から、選択された公告情報に対する新規案件作成要求を受信して、当該選択された公告情報および当該元請に紐づく元請毎入札情報を作成し入札情報ＤＢ１２に記憶する。また、元請または下請から、主に見積単価に関する情報の新規登録、変更、削除等の更新を受信し、入札情報ＤＢ１２を更新する。

【0035】

見積情報管理部２１は、見積依頼処理として、元請端末４から、元請に紐づく元請毎入札情報について見積依頼の要求を受信した場合に、当該元請の元請グループ情報に登録されている全ての下請に対し、当該元請入札情報に紐づく積算情報の全ての費目について、下請毎単価の登録を可能にし、当該元請から見積依頼がある旨の見積依頼メッセージを一斉に送信する。

【0036】

見積情報管理部２１は、下請毎単価登録処理として、見積依頼メッセージを受信した下請が登録した下請毎単価を受信し、入札情報ＤＢ１２に記憶する。見積情報管理部２１は、また、複数の下請から下請毎単価の登録があった費目について、元請に対し、いずれかの下請毎単価を選択可能にし、元請の選択した下請毎単価を採用単価として入札情報ＤＢ１２に記憶する。

【0037】

見積情報管理部２１は、費目ステータス判定処理として、下請毎単価の登録状況に応じて、見積単価の費目ごとのステータスを随時判定するステータス判定を実行し、判定結果を入札情報ＤＢ１２に記憶する。また、見積情報管理部２１は、費目ステータス判定処理に付随する元請費目別一覧表示処理として、見積単価の費目ごとのステータスに応じて、後述する元請画面４０１の元請費目別一覧表４２２の各費目の行の表示設定を変更する。

【0038】

見積情報管理部２１は、工事入札の落札状況に応じて、元請グループ情報に含まれる下請事業者に対し再度見積依頼を実行する。具体的には、見積情報管理部２１は、再見積処理として、落札決定後に、元請端末４から、元請に紐づく元請毎入札情報について再見積依頼の要求を受信した場合に、原価計算で採用した下請毎単価に紐づく下請に対し、原価計算で採用した下請毎単価の費目について、「再見積単価の下請毎単価」の登録を可能にし、当該元請から再見積依頼がある旨の再見積依頼メッセージを一斉に送信する。「再見積単価の下請毎単価」の下請による登録やステータス判定や表示設定の変更は、「見積単価の下請毎単価」の場合と同様であるため説明を省略する。

【0039】

価格算出部２２は、元請毎入札情報について、各種価格を算出する機能を有する。具体的には、原価、実行予算、粗利、入札額、下請毎推奨単価、及び、元請推奨単価、を算出する。原価は、登録された下請毎単価に基づいて、採用単価および元請推奨単価を考慮して集計されることで算出される。実行予算は、工事全体の原価である。工事全体の原価は、元請の場合、自社施工費と下請の見積金額との合計である。

【0040】

また、価格算出部２２は、下請毎に後述する下請画面５０１において下請が「下請毎単価」を入力する際の参考値として参照できる下請毎推奨単価を算出する下請毎推奨単価解析モデルを有する。下請毎推奨単価解析モデルは、例えば、過去に登録された、入札情報ＤＢ１２の共通入札情報のうち、「入札種別」、「入札主催者」「入札公募価格」、「落札者」、「落札額」等を、元請毎入札情報のうち、「設計情報」、「仕様情報」、「費目」、「区分」、当該下請の登録した「下請毎単価」等を、登録ユーザＤＢ１１のユーザ情報のうち、当該下請の「元請毎下請評価」等を、を教師データとしてこれら各情報の相関を機械学習（例えばディープラーニング）させた学習済みモデルである。下請毎推奨単価解析モデルは、教師データとして用いた上記各情報について入力、登録がされることで、費目ごとに当該下請にとって最適な価格（下請毎推奨単価）を算出する。なお、下請毎推奨単価を算出するために入力が必要な情報は、上記教師データに用いた情報の一部でも構わない。

【0041】

さらに、価格算出部２２は、元請毎に見積単価の元請推奨単価を算出する元請推奨単価解析モデルを有する。元請推奨単価解析モデルは、例えば、過去に登録された、入札情報ＤＢ１２の共通入札情報のうち、「入札種別」、「入札主催者」「入札公募価格」、「落札者」、「落札額」等を、元請毎入札情報のうち、「設計情報」、「仕様情報」、「費目」、「区分」、「下請毎単価」、「採用単価」、「採用下請」、「原価」、「粗利」、「入札額」、「入落札結果」等を、登録ユーザＤＢ１１のユーザ情報のうち、元請グループに属する各下請の「元請毎下請評価」等を、を教師データとしてこれら各情報の相関を機械学習（例えばディープラーニング）させた学習済みモデルである。元請推奨単価解析モデルは、教師データとして用いた上記各情報について入力、登録がされることで、下請にとって費目ごとの最適な価格（元請推奨単価）を算出する。なお、元請推奨単価を算出するために必要な情報は、上記教師データに用いた情報の一部でも構わない。

【0042】

下請実績評価部２３は、下請信用度とは別に、取引情報管理サービスで独自に下請を評価する機能を有する。具体的には、下請実績評価部２３は、下請の下請毎単価の採用実績、取引回数や下請信用度等に基づいて評価を行い、登録ユーザＤＢ１１の元請毎下請評価に記憶する。

【0043】

ユーザ管理部２４は、ネットワークＮＷを介して元請端末４から元請情報を取得し登録ユーザＤＢ１１に記憶する機能を有する。同様に、ユーザ管理部２４は、ネットワークＮＷを介して下請端末５から下請情報を取得し登録ユーザＤＢ１１に記憶する機能を有する。

【0044】

制御部２５は、取引情報管理サーバ２を統括的に制御する機能を有する。具体的には、制御部２５は、取引情報管理サーバ２内の各部の動作、エラー処理、やサーバ内の各部の通信を制御する機能を有する。制御部２５は、また、ネットワークＮＷを介して、公告配信サーバ３、元請端末４や下請端末５から情報を取得したり、元請端末４や下請端末５からの要求に応じて、元請端末４や下請端末５の出力部に各種表示や音声等を出力することを管理する機能を有する。例えば、後述する元請画面４０１や下請画面５０１におけるチャット機能を制御する。

【0045】

図５は、積算処理ルーチンを示すフローチャートである。図６は、費目ステータス判定ルーチンを示すフローチャートである。図７は、元請費目別一覧表示ルーチンを示すフローチャートである。これらの図を参照しながら、取引情報管理サーバ２の処理部２０が実行する「積算処理」「費目ステータス判定処理」「元請費目別一覧表示処理」について以下説明する。

【0046】

＜積算処理の流れ＞
まず、図５の、積算処理ルーチンを示すフローチャートを参照しながら積算処理について説明する。当該ルーチンは、取引情報管理サーバ２において元請毎入札情報が作成されており、元請端末４や下請端末５から取引情報管理サーバ２へのログイン（ユーザ認証）がそれぞれ完了している状態でスタートする。図５では、説明を簡単にするために、元請Ｘの元請端末４（区別のために元請端末４（Ｘ）と表記する）、下請Ｓの下請端末５（同様に下請端末５（Ｓ）と表記する）、及び、下請Ｔの下請端末５（同様に下請端末５（Ｔ）と表記する）、と取引情報管理サーバ２との間における積算処理ルーチンを示している。また、図５では、例として、元請毎入札情報には、積算情報として、費目Ａ、費目Ｂ、及び費目Ｃの３つの費目を含み、元請Ｘの元請グループ情報には、下請Ｓと下請Ｔが登録されているものとする。

【0047】

ステップＳ１０１において、元請Ｘは、元請端末４（Ｘ）において、公告情報一覧から、例えば公告情報１を選択して新規案件の作成要求を取引情報管理サーバ２に送信する。

【0048】

次のステップＳ１０２において、取引情報管理サーバ２の見積情報管理部２１は、公告情報１について元請Ｘに紐づけた元請毎入札情報一式を作成し、入札情報ＤＢ１２に記憶する。

【0049】

続くステップＳ１０３において、元請Ｘは、元請端末４（Ｘ）において、公告情報１について作成した元請毎入札情報元請Ｘについての見積依頼の要求を取引情報管理サーバ２に送信する。

【0050】

続くステップＳ１０４において、取引情報管理サーバ２は、下請端末５（Ｓ）の下請Ｓ及び下請端末５（Ｔ）の下請Ｔに対し、見積依頼を実行する。具体的には、取引情報管理サーバ２は、元請Ｘに紐づいた元請毎入札情報のすべての費目、即ち費目Ａ、費目Ｂ及び費目Ｃの下請毎単価について下請毎単価を登録可能とするとともに、下請Ｓ及び下請Ｔに対し下請毎単価の入力を依頼する見積依頼メッセージを送信する。見積依頼メッセージには、下請毎単価の入力期限などの情報を含めることができる。

【0051】

ステップＳ１０５において、取引情報管理サーバ２は、下請端末５（Ｓ）及び下請端末５（Ｔ）に見積依頼メッセージを表示する。なお、取引情報管理サーバ２は、併せて、登録ユーザＤＢ１１に登録されている下請Ｓ及び下請ＴのメールアドレスやＳＮＳ等に下請毎単価を登録できるＵＲＬリンク等を含む見積依頼メッセージを送信してもよい。

【0052】

ステップＳ１０６において、取引情報管理サーバ２は、元請端末４（Ｘ）に、公告情報１の元請Ｘに紐づく積算情報のすべての費目を一覧として表示することができる。この時点では、上記見積依頼に対し、下請Ｓ及び下請Ｔから下請毎単価が登録されていないため、すべての費目のステータスは新規案件作成時規定の「未登録」であり、費目ごとの表示はそれぞれ、背景が赤色となる。ステップＳ１０６は、ステップＳ１０４の見積依頼の実行から、最初にいずれかの費目の下請毎単価が登録されるまでの間に、元請端末４（Ｘ）からの一覧表示要求により実行されるもので、省略されてもかまわない。

【0053】

ステップＳ１０７において、取引情報管理サーバ２は、下請端末５から下請毎単価を受信し、入札情報ＤＢ１２に記憶する。具体的には、図５に示すように、下請端末５（Ｓ）において、下請Ｓは、すべての費目Ａ、費目Ｂ、及び費目Ｃのうち、費目Ａの下請毎単価と費目Ｂの下請毎単価の金額を入力して取引情報管理サーバ２に送信する（登録する）。取引情報管理サーバ２は、下請Ｓと紐づけて、公告情報１の元請Ｘに紐づく元請毎入札情報について、費目Ａの下請毎単価と費目Ｂの下請毎単価を入札情報ＤＢ１２に記憶する。

【0054】

ステップＳ１０８において、取引情報管理サーバ２は、ステップＳ１０６と同様に、元請端末４（Ｘ）に、公告情報１の元請Ｘに紐づく積算情報のすべての費目を一覧として表示することができる。この時点では、ステップＳ１０４での見積依頼に対し、下請Ｓから費目Ａと費目Ｂのみ下請毎単価が登録され、それぞれの費目のステータスは「１件登録あり」となっている。一方、費目Ｃのステータスは「未登録」のままである。このため、費目ごとの表示は、ステータスが「未登録」の費目Ｃについては背景が赤色、ステータスが「１件登録あり」の費目Ａと費目Ｂについては背景の設定変更はなく、規定の例えば白色のままで維持される。ステップＳ１０８も元請端末４（Ｘ）からの一覧表示要求により実行されるもので、省略されてもかまわない。

【0055】

ステップＳ１０９において、取引情報管理サーバ２は、下請端末５から、下請に紐づけて費目に紐づく下請毎単価を受信し、入札情報ＤＢ１２に記憶する。具体的には、図５に示すように、下請端末５（Ｔ）において、下請Ｔは、すべての費目Ａ、費目Ｂ、及び費目Ｃのうち、費目Ｂの下請毎単価の金額を入力して取引情報管理サーバ２に送信する（登録する）。取引情報管理サーバ２は、下請Ｔと紐づけて、公告情報１の元請Ｘに紐づく元請毎入札情報について、費目Ｂの下請毎単価を記憶する。この時点で、費目Ｂに対しては、下請Ｓが登録した下請毎単価と、下請Ｔが登録した下請毎単価の２つの見積単価が登録されていることになる。

【0056】

ステップＳ１１０において、取引情報管理サーバ２は、ステップＳ１０６と同様に、元請端末４（Ｘ）に、公告情報１の元請Ｘに紐づく積算情報のすべての費目を一覧として表示することができる。この時点では、ステップＳ１０４での見積依頼に対し、下請Ｓから費目Ａと費目Ｂの下請毎単価が、下請Ｔから費目Ｂの下請毎単価が、それぞれ登録されている。この時点で、費目Ｂには２つの下請毎単価が登録されているため費目Ｂのステータスは「複数登録あり」となり、費目Ｃは下請毎単価が未だ登録されていないため費目Ｃのステータスは「未登録」のままである。この場合、費目ごとの表示は、ステータスが「未登録」である費目Ｃについては背景が赤色、ステータスが「１件登録あり」の費目Ａについては背景が規定の白色、ステータスが「複数登録あり」の費目Ｂについては背景が緑色に設定される。ステップＳ１１０も元請端末４（Ｘ）からの一覧表示要求により実行されるもので、省略されてもかまわない。

【0057】

ステップＳ１１１において、取引情報管理サーバ２は、元請端末４（Ｘ）から、ステータスが「複数登録あり」の費目について、原価等の入札価格情報の算出に用いる下請毎単価として採用したことを示す選択を受信する。具体的には、まず、元請端末４（Ｘ）には、ステータスが「複数登録あり」の費目Ｂについて、登録された下請Ｓの下請毎単価と下請Ｔの下請毎単価が選択肢として表示される。元請Ｘは、元請端末４（Ｘ）において、費目Ｂについて、下請Ｓの下請毎単価または下請Ｔの下請毎単価のいずれかを選択することができる。選択結果は取引情報管理サーバ２に送信され、入札情報ＤＢ１２に記憶される。

【0058】

続くステップＳ１１２において、取引情報管理サーバ２は、登録された下請毎単価に基づいて、原価等の入札価格情報を算出し、入札情報ＤＢに記憶する。

【0059】

ステップＳ１１３において、取引情報管理サーバ２は、元請端末４（Ｘ）からの要求により、原価等の入札価格情報の算出結果を元請端末４（Ｘ）に表示させて当該ルーチンをリターンする。

【0060】

＜費目ステータス判定処理＞
次に、図６の、費目ステータス判定ルーチンを示すフローチャートを参照しながら費目ステータス判定処理について説明する。当該ルーチンは、元請端末４または下請端末５において積算情報の登録、更新が行われた場合に実行される。当該ルーチンを実行することにより、各費目の見積単価のステータス、及び／又は、再見積単価のステータスが、「未登録」、「１件登録あり」、「複数登録あり」、または「採用単価決定」のいずれかに設定される。なお、新規案件作成時のステータスの規定値は「未登録」である。

【0061】

ステップＳ２０１において、見積情報管理部２１は、元請端末４または下請端末５から積算情報の登録を受信して、ステップＳ２０２に進む。当該ルーチンにおいて、元請端末４または下請端末５から積算情報の登録を受信した場合とは、具体的には、下請端末５からある費目について下請毎単価（又は再見積単価の下請毎単価）の新規登録、変更、または削除（金額を０円にすること）を受け付けた場合、又は、元請端末４からある費目について見積単価（又は再見積単価の下請毎単価）の採用選択の新規登録または変更を受け付けた場合である。

【0062】

続くステップＳ２０２において、見積情報管理部２１は、登録のあった費目について、「下請毎単価」の登録がないか否かを判定する。なお、下請毎単価が「０円」で登録された場合は、その費目について見積の提出がないものとして、カウントしない。当該判定結果が真（Ｙｅｓ）、すなわち「下請毎単価」の登録がないと判定された場合、ステップＳ２０８に進む。一方、偽（Ｎｏ）の場合、すなわち「下請毎単価」の登録があると判定された場合はステップＳ２０３に進む。

【0063】

ステップＳ２０３において、見積情報管理部２１は、登録のあった費目について、「下請毎単価」の登録が複数あるか否かを判定する。当該判定結果が真（Ｙｅｓ）、すなわち「下請毎単価」の登録が複数あると判定された場合、ステップＳ２０４に進む。一方、偽（Ｎｏ）の場合、すなわち「下請毎単価」の登録が複数ない（すなわち、「下請毎単価」の登録が１件のみ）と判定された場合はステップＳ２０７に進む。

【0064】

続くステップＳ２０４において、見積情報管理部２１は、登録のあった費目について、複数登録されている「下請毎単価」のうちいずれかが採用選択されているか否かを判定する。当該判定結果が真（Ｙｅｓ）、すなわち複数登録されている「下請毎単価」のうちいずれかが採用選択されていると判定された場合、ステップＳ２０５に進む。一方、偽（Ｎｏ）の場合、すなわち複数登録されている「下請毎単価」のうちいずれも採用選択されていないと判定された場合はステップＳ２０６に進む。

【0065】

ステップＳ２０５では、すなわち、ステップＳ２０４で複数登録されている「下請毎単価」のうちいずれかが採用選択されていると判定された場合、見積情報管理部２１は、登録のあった費目について、ステータスを「採用単価決定」に設定し、当該ルーチンをリターンする。

【0066】

ステップＳ２０６では、すなわち、ステップＳ２０４で複数登録されている「下請毎単価」のうちいずれも採用選択されていないと判定された場合、見積情報管理部２１は、登録のあった費目について、ステータスを「複数登録あり」に設定し、当該ルーチンをリターンする。

【0067】

ステップＳ２０７では、すなわち、ステップＳ２０３で「下請毎単価」の登録が複数でないと判定された場合、見積情報管理部２１は、登録のあった費目について、ステータスを「１件登録あり」に設定し、当該ルーチンをリターンする。

【0068】

ステップＳ２０８では、すなわち、ステップＳ２０２で「下請毎単価」の登録がないと判定された場合、見積情報管理部２１は、登録のあった費目について、ステータスを「未登録」に設定して、当該ルーチンをリターンする。

【0069】

＜色分け表示処理＞
次に、図７の、元請費目別一覧表示ルーチンを示すフローチャートを参照しながら元請費目別一覧表示処理について説明する。当該ルーチンは、元請端末４において後述する元請費目別一覧表４２２を表示する場合に実行される。

【0070】

ステップＳ３０１において、見積情報管理部２１は、元請端末４から元請費目別一覧表４２２の表示要求を受信して、ステップＳ３０２に進む。

【0071】

続くステップＳ３０２において、見積情報管理部２１は、元請費目別一覧表４２２に表示する費目のステータスが「未登録」か否かを判定する。当該判定結果が真（Ｙｅｓ）、すなわち費目のステータスが「未登録」であると判定された場合、ステップＳ３０７に進む。一方、偽（Ｎｏ）の場合、すなわち費目のステータスが「未登録」でないと判定された場合はステップＳ３０３に進む。

【0072】

ステップＳ３０３において、見積情報管理部２１は、元請費目別一覧表４２２に表示する費目のステータスが「複数登録あり」か否かを判定する。当該判定結果が真（Ｙｅｓ）、すなわちステータスが「複数登録あり」であると判定された場合、ステップＳ３０４に進む。一方、偽（Ｎｏ）の場合、すなわちステータスが「複数登録あり」でない（すなわち、「下請毎単価」の登録が１件のみ）と判定された場合はステップＳ３０８に進む。

【0073】

ステップＳ３０４において、見積情報管理部２１は、元請費目別一覧表４２２に表示する費目のステータスが「採用単価決定」か否かを判定する。当該判定結果が真（Ｙｅｓ）、すなわちステータスが「採用単価決定」であると判定された場合、ステップＳ３０５に進む。一方、偽（Ｎｏ）の場合、すなわちステータスが「採用単価決定」でないと判定された場合はステップＳ３０６に進む。

【0074】

ステップＳ３０５では、すなわち、ステップＳ３０４でステータスが「採用単価決定」であると判定された場合、見積情報管理部２１は、その費目の行の表示設定について、背景を緑色、かつ、展開用矢印の追加、に設定して、ステップＳ３０８に進む。

【0075】

ステップＳ３０６では、すなわち、ステップＳ３０４でステータスが「採用単価決定」でないと判定された場合、見積情報管理部２１は、その費目の行の表示設定について、背景を橙色、かつ、展開用矢印の追加、に設定して、ステップＳ３０８に進む。

【0076】

ステップＳ３０７では、すなわち、ステップＳ３０２でステータスが「未登録」であると判定された場合、見積情報管理部２１は、その費目の行の表示設定について、背景を赤色に設定して、ステップＳ３０８に進む。

【0077】

ステップＳ３０８では、見積情報管理部２１は、費目の行の表示設定に従って、元請端末４に元請費目別一覧表４２２を表示し、当該ルーチンをリターンする。

【0078】

元請費目別一覧表４２２に表示する費目が複数ある場合は、各費目について上記元請費目別一覧表示ルーチンを実行し、見積情報管理部２１は、各費目の表示設定に応じた表示を行う。

【0079】

＜端末装置表示画面＞
図８は、元請端末に表示される入札情報の表示例である。図９は、図８において見積単価が複数登録された費目について詳細を展開表示した表示例である。図１０は、図９において複数登録された見積単価のひとつを選択した後の画面の表示例である。図１１は、下請端末に表示される入札情報の表示例である。以下これらの図に基づき、本実施形態の端末装置における主な表示画面を説明する。

【0080】

まず、元請端末４の主な表示画面について説明する。取引情報管理サーバ２は、ユーザ認証後、図８に示す元請画面４０１を元請端末４に表示させる。

【0081】

元請画面４０１には、表示領域上部において、入札情報のうち主に共通入札情報を表示する元請共通入札情報表示領域４１０が配置され、元請共通入札情報表示領域４１０の下側に元請毎入札情報、特に積算情報を表示する元請積算情報表示領域４２０が配置されている。

【0082】

元請共通入札情報表示領域４１０には、案件名（入札名称）４１１、入札期日４１２、当該案件全体の入札価格情報を一覧表示する全体価格表４１３、取引情報管理サーバ２に
見積依頼の実行を要求する「見積り」ボタン４１４、下請とのチャット機能を実行するチャットボタン４１５が配置されている。チャット機能は、例えば、通話を開始したい下請毎単価が表示された行を選択した状態で、チャットボタン４１５を選択することにより、その下請毎単価に紐づく下請との間でチャット機能が実行される。

【0083】

元請積算情報表示領域４２０は、元請共通入札情報表示領域４１０とはタブ４２１で区切られており、一費目が一行に対応する元請費目別一覧表４２２、元請費目別一覧表４２２に行を追加するための「項目追加」ボタン４２３、表示されている元請費目別一覧表４２２に関しての価格を表示する元請小計欄４２４が配置されている。タブ４２１は、費目の区分に対応して、複数表示されており、選択されたタブに応じて、元請費目別一覧表４２２の表示が区分でフィルタされて切り替わり、元請小計欄４２４の記載（数値）の表示も切り替わる。図８では、タブ４２１として「ＡＬＬ」、「道路改良」及び「橋梁下部」が表示されており、「ＡＬＬ」が選択された状態であるため、元請費目別一覧表４２２には、すべての区分を含む積算情報が表示されている。元請費目別一覧表４２２の最上列は、表示項目のタイトルを示し、２行目以下に費目ごとに、費目に紐づく区分、数量、単位、単価、金額、編集アイコン（図８では鉛筆の図柄）、削除アイコン（図８ではバツ印）、等が表示される。なお、単価には、費目のステータスに応じて、下請毎単価、元請推奨単価、採用単価のいずれかが表示される。

【0084】

元請費目別一覧表４２２において、ステータスが「複数登録あり」の費目の行は、左端にその行の詳細情報について展開表示できることを示す矢印（展開表示矢印）４２５が配置され、橙色の背景で表示される（図８－１０では、背景色橙色については図示できないため、中濃の網掛けで表示）。また、元請費目別一覧表４２２において、ステータスが「未登録」の費目の行は、赤色の背景で表示される（図８－１０では、背景色赤色については図示できないため、濃い網掛けで表示）。一方、元請費目別一覧表４２２において、ステータスが「１件登録あり」の費目は、元請画面４０１の規定の背景色（例えば白色）で表示される。このように、ステータスが「未登録」の費目の行、「複数登録あり」の費目の行の背景色をそれぞれ元請画面４０１の規定の背景色と異なるものにすることで、調整の必要な費目を容易に把握することができる。

【0085】

次に、図９及び図１０を用いて、ステータスが「複数登録あり」の費目における採用単価の選択表示について説明する。図８に示す元請費目別一覧表４２２において、ステータスが「複数登録あり」の費目の行（以下展開元行という）の展開表示矢印４２５を選択することで、図９に示すように、展開先行の下に、その費目に紐づいた「下請毎単価」を含む詳細情報が表示される展開表示４２６が現れる。図９は、図８の元請費目別一覧表４２２の２行目４２２ｂ（展開元行４２２ｂともいう）を展開した様子を示している。

【0086】

展開表示４２６には、展開元行４２２ｂの費目について「下請毎単価」を登録した下請の下請会社名とともに、登録された下請毎単価、登録された下請毎単価に基づいて計算された金額（下請毎単価に数量を掛けた金額）、採用の有無を選択できる「採用」ラジオボタンが表示されている。

【0087】

図９では、展開元行４２２ｂの費目Ｂについての展開表示４２６において、下請Ｓと下請Ｔから登録された「下請毎単価」が表示されている。元請は、展開表示４２６において、採用する方の下請の「採用」ラジオボタンを選択することができる。

【0088】

費目Ｂの展開元行４２２ｂには、元請推奨単価の金額が表示されている。すなわち、登録された複数の「下請毎単価」のうち、取引情報管理サーバ２の価格算出部２２が推奨する方の下請毎単価の金額が表示されている。元請は、提示されている元請推奨単価を参考に、どの下請毎単価を採用するのかを決めることができる。

【0089】

展開表示４２６において、いずれかの「採用」ラジオボタンが選択されると、図１０に示すように、展開元行４２２ｂの背景色が緑色に変更される（図１０では、背景色緑色については図示できないため、薄い網掛けで表示）。このように、元請費目別一覧表４２２に下請毎単価が複数登録された費目がある場合について、採用単価を決定した費目の行について、決定していない費目の行と区別して表示することで、調整済みであることが容易に把握できる。

【0090】

このように、見積単価に抜けや重複がある費目を容易に認識できる。また、重複する場合には、推奨する単価を提示する。推奨単価を仮採用して工事原価を算出できるので、重複について調整を行う前であっても、リアルタイムで工事原価を把握できる。

【0091】

図１１は、下請端末に表示される入札情報の表示例である。次に、下請端末５において下請が下請毎単価を入力（登録）する画面について説明する。取引情報管理サーバ２は、下請のユーザ認証後、下請端末５に、図１１に示すような下請画面５０１を表示する。

【0092】

下請画面５０１には、図１１に示すように、表示領域上部において、共通入札情報を表示する下請共通入札情報表示領域５１０が配置され、下請共通入札情報表示領域５１０の下側に、見積依頼された積算情報を表示する下請積算情報表示領域５２０が配置されている。

【0093】

下請共通入札情報表示領域５１０には、案件名（入札名称）５１１、入札の期日５１２、見積依頼主５１３、コメント５１４、見積依頼の送信主の元請へ見積を提出する「見積り提出」ボタン５１５、「推奨額一括入力」ボタン５１６、見積依頼を送信した元請とのチャット機能を実行するチャットボタン５１７が配置されている。チャットボタン４１５を選択することにより、見積依頼を送信した元請との間でチャット機能が実行される。

【0094】

下請積算情報表示領域５２０は、下請共通入札情報表示領域５１０とはタブ５２１で区切られており、積算情報の費目ごとにリストで並べた下請費目別一覧表５２２、表示されている下請費目別一覧表５２２に関しての価格を表示する小計欄５２３が配置されている。タブ５２１は、費目の区分に対応して、複数表示される。図１１では、タブ５２１として「ＡＬＬ」、「道路改良」及び「橋梁下部」が表示されている。選択したタブに応じて、下請費目別一覧表５２２の表示が区分でフィルタされて切り替わり、小計欄５２３の記載（数値）の表示も切り替わる。図１１では、タブ５２１の「ＡＬＬ」が選択されて、下請費目別一覧表５２２には、すべての区分を含む積算情報が表示されている。下請費目別一覧表５２２の最上列は、表示項目のタイトルを示し、２行目以下に費目ごとに、費目に紐づく区分、数量、単位、単価、金額が表示されている。

【0095】

下請費目別一覧表５２２において、各費目の単価の欄は、上下２段表示になっている。下段には、金額として数値を入力可能なボックス５２４（図１１では、５行目５２２ｅにのみ代表で符号５２４を表示）が配置されている。図１１では、１行目５２２ａから３行目５２２ｃまでのボックス５２４について金額の入力があり、入力がない４行目５２２ｄと５行目５２２ｅのボックス５２４には規定値として「０」が表示されている。

【0096】

上段の右側には単価の推奨額５２５として下請毎推奨単価が表示され（図１１では、５行目５２２ｅにのみ代表で符号５２５を表示）、上段の左側には右側に表示された下請毎推奨単価をボックス５２４に反映させるための「反映」印５２６（図１１では▼で表示、５行目５２２ｅにのみ代表で符号５２６を表示）が表示されている。下請は、見積を提出したい費目について、各ボックス５２４に金額として「０」以外の正の数値を入力し、「見積り提出」ボタン５１５を選択することで、見積を提出、すなわち取引情報管理サーバ２の入札情報ＤＢに登録することができる。また、ボックス５２４に入力した数値に応じて、小計欄５２３の金額も再計算されて表示される。下請は、「推奨額一括入力」ボタン５１６を選択することで、下請毎推奨単価が表示されている費目について、一括でそれぞれのボックス５２４に下請毎推奨単価を反映させることもできる。

【0097】

以上のように、本実施形態における取引情報管理システム１では、公共工事の入札等に関する元請と下請の間の見積書の調整作業の効率を向上させることができる。すなわち、元請と下請がクラウド上に公告ごとにまとめられた設計図面、仕様書、積算書類一式にアクセスすることで、見積作成及び積算に係る作業時間が短縮できる。また、あらかじめ元請グループ情報に登録された全ての下請に対し、全費目について一括で見積依頼を送信することで、公共土木工事の入札に係る見積り作業や発注作業について元請と下請の間の慣例的な手順を維持しながらも、両者にとって作業を効率化することができる。

【0098】

また、取引情報管理システム１は、元請が元請端末４に表示する元請画面４０１において、費目ごとに下請毎単価の登録状況に応じた表示をすることができる。これにより、元請は、調整の必要な費目、具体的には、下請毎単価の登録の「抜け」や「重複」のある費目を容易に認識することができるため、入札に係る作業をさらに効率化することができる。

【0099】

また、取引情報管理システム１は、原価等の入札価格情報について、下請毎単価が複数登録されているが元請が採用単価を選択していない場合でも、価格算出部２２の算出した元請推奨単価に基づいて入札価格情報の算出を行う。これにより、元請はリアルタイムで原価等の入札価格情報を確認でき、作業や意思決定の時間が短縮することができる。

【0100】

また、取引情報管理システム１において、落札確定した元請は、原価計算で採用した下請毎単価に紐づく下請に対し、原価計算で採用した下請毎単価の費目について、再見積りボタン一つで再見積依頼を一斉に送信し、再見積単価の下請毎単価を取得することができる。これにより、再見積依頼の作業や時間を短縮しながら、原価や利益の算出精度を向上することができる。

【0101】

また、取引情報管理システム１は、元請は、元請端末４に表示する元請画面４０１において、指定した下請とのチャットを行うことができる。また、下請は、下請端末５に表示する下請画面５０１において、見積依頼を送信した元請とのチャットを行うことができる。このように元請と下請がチャット機能を用いてリアルタイムで相談しながらそれぞれ採用単価、下請毎単価の決定等の調整ができることで、さらに価格決定の作業効率が向上する。チャットは、ＷＥＢ会議等の他のコミュニケーションツールや共同編集で代替しても構わない。

【0102】

（第２実施形態）
次に本開示の第２実施形態について説明する。なお、第１実施形態と同じ構成要素については同じ符号を付して、詳しい説明を省略する。

【0103】

図１２は、本開示の第２実施形態に係る取引情報管理システムのネットワーク構成を示す図である。図１３は、本開示の第２実施形態に係る取引情報管理サーバの主な構成を示すブロック図である。

【0104】

図１２に示すように、本実施形態に係る取引情報管理システム２０１は、取引情報管理サーバ６、元請端末４、下請端末５、及び、発注者端末７がネットワークＮＷを介して相互に通信可能に接続されて構成されている。取引情報管理サーバ６は、取引情報管理サービスを提供する事業者が運用するサーバである。発注者端末７は、取引情報管理サービスを利用する発注者が使用する端末装置である。なお、説明の簡略化のため図１では発注者端末７を1つのみ示しているが、複数であってもよい。また、取引情報管理サーバ６についても、物理的または仮想的に複数のサーバから構成されていてもよい。発注者は、建設工事の施主、すなわち入札主催者であり、例えば、官公庁、地方自治体、民間の施主やディベロッパー、等である。第１実施形態では、取引情報管理サービスは元請と下請の二者間の情報プラットフォームであったが、第２実施形態では、建設工事の発注者もユーザとして取引情報管理サービスに加わり、元請、下請け、発注者の三者間での情報プラットフォームとなっている点が異なっている。

【0105】

図１３に示すように、取引情報管理サーバ６は、記憶部２１０及び処理部２２０を備える。記憶部２１０は、登録ユーザデータベース２１１、及び入札情報データベース２１２を含む。以下、登録ユーザデータベース２１１を登録ユーザＤＢ２１１、入札情報データベース２１２を入札情報ＤＢ２１２と表記する場合がある。処理部２２０は、見積情報管理部２２１、価格算出部２２２、下請実績評価部２３、ユーザ管理部２２４、制御部２２５、出力管理部２２６、マッチング管理部２２７、を備える。これら各部は、取引情報管理サーバ６の内部で相互に通信可能に接続されている。

【0106】

発注者端末７は、元請端末４及び下請端末５と同様の、例えばＰＣや、スマートフォン、タブレットＰＣ、及び携帯電話のような端末装置である。

【0107】

図１４は、第２実施形態の取引情報管理サーバ６に記憶される登録ユーザ情報の例をまとめた表である。図１５は、第２実施形態の取引情報管理サーバ６に記憶される入札情報の例をまとめた表である。これらの図を参照しながら、記憶部２１０の登録ユーザＤＢ２１１及び入札情報ＤＢ２１２に含まれる各情報について以下説明する。

【0108】

登録ユーザＤＢ２１１に記憶されるユーザ情報は、第１実施形態の登録ユーザＤＢ１１に記憶されるユーザ情報と比較して、発注者のユーザ情報が追加されている点、及び、後述するマッチング機能に関する情報が追加されている点、が異なる。図１４に示すように、ユーザ情報は、元請に関する元請情報と、下請に関する下請情報と、発注者に関する発注者情報と、の３つに分類されている。元請及び下請のユーザ情報には、第１実施形態に対してマッチング希望条件が追加されている。発注者のユーザ情報には、取引情報管理サービスに登録した発注者（図１４では例として発注者Ｖと発注者Ｗが記載されている）ごとに、発注者ＩＤ、発注者名、発注者グループ情報、マッチング希望条件、備考等が含まれる。

【0109】

発注者ＩＤは、取引情報管理サーバ６で自動付与される一意な符号等であり、ユーザ認証やデータ紐づけ等に用いられる。発注者名は、それぞれユーザである事業者等の名称である。発注者グループ情報は、発注者に紐づく元請及び下請、すなわち発注者が取引を行う可能性のある複数の元請及び複数の下請の群である。発注者は、ユーザ登録済みの元請及び下請から複数選択して発注者グループ情報として登録できる。なお、ユーザ登録されていない元請及び下請に対しては、取引情報管理サービス上で登録依頼メッセージを元請や下請に送ることで登録を促すことができる。発注者情報は、取引情報管理サービスのユーザ登録時や利用時にユーザである発注者自身が入力したり、他のクラウドサービスのアカウントと連携することで取得したりしてもよい。

【0110】

元請情報、下請け情報、発注者情報、それぞれのマッチング希望条件は、新規取引先となりうる事業者からの引合、見積、発注等を受け付ける（以下、単に新規受付という）か否かの希望と、新規受付可が選択された場合には、情報公開先や新規受付の条件等の情報が記憶される。情報公開先の条件の例は、「すべてのユーザにユーザ登録情報を公開」や、「元請のみにユーザ登録情報を公開」、「同業者には公開しない」、「関東地方の事業者に公開」、「特定の種別の入札情報は、特定の規模の元請に公開」、「特定の費目の積算情報は特定の地域の下請に公開」、などである。新規受付の条件の例は、「公共工事に限定」、「関東に限定」などである。なお、新規取引先とは、元請の場合は、例えば元請グループ情報に登録されていない事業者であってもよく、発注者の場合は、例えば発注者グループ情報に登録されていない事業者であってもよい。また、新規取引先に限らず、過去に取引のある事業者であってもマッチングを受け付けてもよい。例えば、元請グループ情報に登録されているが、見積送付先として選択されていないために、しばらく取引がなかった下請からのマッチングを受け付けてもよい。

【0111】

次に、図１５を参照しながら第２実施形態の入札情報ＤＢ２１２に記憶される入札情報について説明する。第１実施形態の入札情報ＤＢ１２に記憶される入札情報と異なる点は、費目に勘定科目の情報が含まれること、及び、元請及び下請のそれぞれに受注後情報が含まれることである。勘定科目は、一般的な分類や仕分けの情報に加え、工事や建築に適した独自の分類タグを含めることができる。独自の分類タグの一例としては、売上高に対して付与する「民間建築」、「民間土木」、「公共建築」、「公共土木」のタグである。勘定科目は、元請が元請端末４から登録したり、取引情報管理サーバ６が、記憶している費目と勘定科目のと対応テーブルを参照して自動登録してもよい。受注後情報は、入落札の結果又は見積採用の採否結果に応じて、入札情報から必要な情報を参照して自動登録してもよく、また、元請、下請けが、それぞれ、元請端末４、下請端末５から手動で登録してもよい。また、図示しないが、入札情報ＤＢ２１２は、後述する実行予算の予実管理情報として、費目に紐づく支払に関する情報、例えば支払の金額、実行予定日、支払実行日等を含む。支払に関する情報は、請求書等を登録することにより自動で取得してもよく、ユーザが手動で登録してもよい。

【0112】

具体的には、公告情報ごとに共通入札情報、元請毎入札情報、及び、下請毎入札情報が作成される。下請毎入札情報は、下請けごと（図１５では例として下請けＳと下請Ｔが記載されている）に作成される。元請毎入札情報及び下請毎入札情報は、それぞれ、受注後情報を含むことができる。受注後情報は、請負額、着工日、完工日、出来高（割合）、出来高（金額）、入金済額、出来高未収金額、を含む。受注後情報は、その公告情報に対して、入札結果が落札である元請と、その元請から最終的な発注を受けた下請に対して自動的に作成される情報である。元請の受注後情報の請負額は、落札した元請に紐づく入札申請額が自動入力される。下請の受注後情報の請負額は、落札した元請に提出した下請毎単価に基づいて算出される請負額が自動入力される。着工日、完工日、出来高（割合）、入金済額は、元請または下請が登録可能な情報である。出来高（金額）は請負額と出来高（割合）に基づいて算出され自動入力される情報である。出来高未収金額は、請負額と出来高（金額）に基づいて算出され自動入力される情報である。

【0113】

図１３に戻り、取引情報管理サーバ６の処理部２２０の機能について以下説明する。第２実施形態の処理部２２０は、第１実施形態の処理部２０に、出力管理部２２６、マッチング管理部２２７を追加し、さらに、第１実施形態の見積情報管理部２１に代わり見積情報管理部２２１を、第１実施形態の価格算出部２２に代わり価格算出部２２２を、第１実施形態のユーザ管理部２４に代わりユーザ管理部２２４を、第１実施形態の制御部２５に代わり制御部２２５を、備えた構成である。

【0114】

見積情報管理部２２１は、第１実施形態の見積情報管理部２１に次の機能が追加されている。見積情報管理部２２１は、工事入札ごとに、工事入札の落札結果に基づいて、工事入札を落札した元請事業者に紐づく元請受注後情報を生成し、また、当該落札した元請事業者に見積を採用された下請事業者に紐づく下請受注後情報を生成して、それぞれ記憶部１０１の入札情報ＤＢ２１２に記憶する。

【0115】

価格算出部２２２は、第１実施形態の価格算出部２２に次の機能が追加されている。価格算出部２２２は、受注後情報の「請負額」と「出来高（割合）」とに基づいて「出来高（金額）」を算出し記憶する。価格算出部２２２は、「出来高（金額）」と「入金済額」とに基づいて、「出来高未収金額」を算出し記憶する。価格算出部２２２は、

【0116】

ユーザ管理部２２４は、第１実施形態のユーザ管理部２４に次の機能が追加されている。ユーザ管理部２２４は、ネットワークＮＷを介して発注者端末７から発注者情報を取得し登録ユーザＤＢ１１に記憶する機能を有する。

【0117】

制御部２２５は、第１実施形態の制御部２５に次の機能が追加されている。制御部２２５は、ネットワークＮＷを介して、発注者端末７から情報を取得したり、発注者端末７からの要求に応じて、発注者端末７の出力部に各種表示や音声等を出力することを管理する機能を有する。

【0118】

出力管理部２２６は、ユーザである元請又は下請からの要求に基づいて、入札情報から「受注工事明細」を生成し出力する。受注工事明細は、元請又は下請に紐づく１または複数の元請受注後情報の一覧情報であり、元請受注後情報又は下請受注後情報に紐づく入札情報の基本情報の一部（例えば、共通入札情報に含まれる入札名称等）を含めることができる。「受注工事明細」を出力した画面表示例については後述する。また、出力管理部２２６は、ユーザである元請からの要求に基づいて、入札情報から「実行予算の予実管理情報」を生成し出力する。予実とは、予算と実績の略である。「実行予算の予実管理情報」を出力した画面表示例については後述する。さらに、出力管理部２２６は、ユーザである元請、下請け、又は発注者からの要求に基づいて、入札情報から「分析グラフ」を生成し出力する。「分析グラフ」を出力した画面表示例については後述する。

【0119】

マッチング管理部２７は、元請事業者と下請事業者と発注者との間の少なくとも二者間でのマッチングを支援する機能を提供する。具体的には、マッチング管理部２７は、登録ユーザおよび入札情報の検索機能を提供する。例えば、元請が元請グループ情報に下請を登録する場合に、マッチング管理部２７は、元請から検索条件の入力を受け付け、登録ユーザＤＢ２１１の下請情報のマッチング希望条件を参照し、検索条件に合致する下請の情報を推奨順に並べたリストとして表示する。同様に、発注者が発注者グループ情報に元請を登録する場合に、マッチング管理部２７は、登録ユーザＤＢ２１１の元請情報のマッチング希望条件を参照し、検索条件に合致する元請の情報を推奨順に並べたリストを表示する。また、元請が費目ごとの見積依頼先の下請を選択する場合に、マッチング管理部２７は、同様にリストを表示してもよい。さらに、マッチング管理部２７は、下請に対して、新規取引可として公開されている元請毎入札情報の検索と、検索した元請入札情報への見積の提案を受け付ける。これにより、ユーザは、マッチング希望条件において新規取引可を選択している業者から、新たな取引先を探すことができる。

【0120】

図１６は、第２実施形態の端末に表示される受注工事明細の表示例である。受注工事明細とは、元請にとっては落札した工事の明細であり、下請けにとっては提出した見積に対して元請が採用を決定した工事（費目）の明細である。受注工事明細は、入札情報に基づいて生成される。本図に基づき、受注工事明細の表示例を説明する。受注工事明細は、元請および下請が端末画面やファイルとして出力可能な情報であるが、出力する項目は似ているため、元請端末４での表示例を説明する。

【0121】

元請画面２４０１には、表示領域の最上部に、現在閲覧している階層を示すナビゲーションバー２４１１、ナビゲーションバー２４１１の下に、メニューバー２４１２が配置されている。メニューバー２４１２には、「受注工事明細」のタイトルと、「新規案件を作成」ボタンと「案件一覧を表示」ボタンとが配置されている。メニューバー２４１２の下には、案件を表形式で表示する案件一覧表２４１３が配置されている。

【0122】

案件一覧表２４１３は、ひとつの建設工事（案件）が一行に対応する表である。案件一覧表２４１３の最上列２４１３ａには、表示項目のタイトルとして、「工事名称」、「受注先」、「着工日」、「完工日」、「請負金額」、「出来高（割合）」、「出来高（金額）」、「入金済額」、「出来高未収金額」が示されている。２行目以下は、建設工事ごとに、タイトルに対応する名称や、数値、記号等が表示されている。図１６では、例として２行目２４１３ｂ、３行目２４１３ｃ、４行目２４１３ｄ、５行目２４１３ｅ、６行目２４１３ｆが表示されている。「出来高（金額）」は、工事の途中まで出来上がった部分（すなわち出来形）に相応する請負代金のことであり、「請負金額」に「出来高（割合）」を掛けることで算出される。「出来高（割合）」が工事の進捗状況に応じて適宜更新される。「出来高（割合）」は、ユーザの手入力によって取得してもよい。また、請求書と紐づけることで自動で「出来高（割合）を算出してもよい。

【0123】

図１７は、第２実施形態の端末に表示される実行予算の予実管理情報の表示例である。本図に基づき、実行予算の予実管理情報の表示例を説明する。実行予算の予実管理情報は、元請が端末画面やファイルとして出力可能な情報である。以下では、元請端末４での表示例を説明する。

【0124】

元請画面２４０１には、表示領域の最上部に、現在閲覧している階層を示すナビゲーションバー２４２１、ナビゲーションバー２４２１の下に、メニューバー２４２２が配置されている。メニューバー２４２２には、「実行予算の予実管理」のタイトルと、実行予算の予実管理情報の表示対象期間を示す表示対象期間ボタン（図１７では「２０２２年８月」と表示）と、「案件を選択」ボタンと、が配置されている。メニューバー２４２２の下には、表示対象の案件の概要が表示される案件概要欄２４２３と、実行予算の予実管理情報を表形式で表示する予実管理表２４２４が配置されている。表示対象期間ボタン内には、左向きと右向きの三角印が表示されており、この三角印を選択（クリック）することで、表示期間を変更することができる。「案件を選択」ボタンを選択すると、案件一覧がポップアップやプルダウンで表示され、案件を選択できる。

【0125】

案件概要欄２４２３には、表示対象として選択されている選択案件についての、案件名、発注者名、請負金額、工期、実行予算額、実行利益額、実行利益率、が表示されている。案件概要欄２４２３の実行予算額、実行利益額、はその案件についての合計金額が表示される。予実管理表２４２４は、選択案件について、ひとつの勘定科目分類が一行に対応する表である。予実管理表２４２４の最上列２４２５ａには、表示項目のタイトルとして、「勘定科目分類」、「実行予算金額」、「出来高」、「当月支払」、「今後支払予定」、「支払累計」、「予想完成工事原価」、「現予算残」、「予想完成工事予算残」が示されている。２行目以下は、勘定科目分類ごとに、タイトルに対応する金額（数値）が表示されている。図１７では、例として２行目２４２５ｂ、３行目２４２５ｃ、４行目２４２５ｄ、５行目２４２５ｅ、最終行目２４２５ｆが表示されている。最終行目２４２５ｆは、２行目２４２５ｂから最終行目２４２５ｆの手前の行までの合計を示している。なお、完成工事原価は、一般会計でいう売上原価のことであり、建設収入を得るために直接要した材料費や労務費などが含まれる。

【0126】

図１８は、第２実施形態の端末に表示される分析グラフの表示例である。本図に基づき、分析グラフの表示例を説明する。分析グラフは、元請、下請、発注者、がそれぞれの端末画面やファイルとして出力可能な情報である。以下では、元請端末４での表示例であるダッシュボードを説明する。

【0127】

元請画面２４０１には、表示領域の最上部に、現在閲覧している階層を示すナビゲーションバー２４３１、ナビゲーションバー２４３１の下に、メニューバー２４３２が配置されている。メニューバー２４３２には、「ダッシュボード」のタイトルと、「表示グラフを選択」ボタンと、「絞込条件を選択」ボタンと、が配置されている。メニューバー２４３２の下には、例として４つのグラフ２４３３ａ、２４３３ｂ、２４３３ｃ、２４３３ｄが表示されている。図１８では、グラフ２４３３ａとして「売上高予実推移」のタイトルで、横軸に年月、縦軸に金額をとり、売上高の予算と実績の金額が棒グラフで示されている。また、グラフ２４３３ｂとして「売上高予実達成率」のタイトルで、元請の２０２２年度の売上高予実達成率が１０７％であることが、０％から２００％の間の帯グラフ及びテキストで示されている。また、グラフ２４３３ｃとして、「売上高営業利益率推移」のタイトルで、横軸に年月、縦軸に金額を取り、売上原価及び販管費（販売費及び一般管理費）の２項目については積み上げ棒グラフで、売上高が折れ線グラフで示されている。さらに、グラフ２４３３ｄとして「年間売上高比較」のタイトルで、横軸に金額、縦軸に実績と予算の２項目をとり、売上の分類タグとしての「民間建築」、「民間土木」、「公共建築」、「公共土木」の４項目が積み上げ棒グラフで示されている。これらのグラフは、メニューバー２４３２の「表示グラフを選択」ボタン等で他の内容を示すグラフを選択したり、表示場所を入れ替えたり、グラフの種類・表示形態・表示項目を変更したりすることができる。

【0128】

以上のように、第２実施形態における取引情報管理システム２０１では、元請、下請、発注者の三者間において、建設工事の入札等に関する建設工事の仕様情報（公告情報）を共有できる。これにより、情報が一元化され、見積および発注の作業が効率化する。また、元請及び下請は、受注している工事とその出来高に関する情報を受注工事明細として容易に出力できることで、自社が現在扱っている案件数や、それぞれ進捗状況を確認でき、受注管理や案件管理の効率を向上できる。また、金融機関の融資の担保に関する情報の作成を効率化できる。

【0129】

また、分析グラフにより、工事の売上や利益率、及びその推移等が視覚的に表示されるため、元請、下請け、発注者は、経営判断や分析を経営者と現場で共有できる。また、銀行等に融資の判断資料として提出することができる。

【0130】

＜プログラム＞
ここで、各実施形態に係る取引情報管理サーバ２、６を構成する各機能を実現するためのプログラムの詳細について説明する。図１９は、本開示の実施形態に係るコンピュータの構成を示す概略ブロック図である。

【0131】

取引情報管理サーバ２、６は、図１９で示すコンピュータ８０１に実装される。そして、取引情報管理サーバ２、６の各構成要素の動作は、プログラムの形式で補助記憶装置８０４に記憶されている。ＣＰＵ８０２は、プログラムを補助記憶装置８０４から読み出して主記憶装置８０３に展開し、当該プログラムに従って上記処理を実行する。また、ＣＰＵ８０２は、プログラムに従って、上記の記憶部１０に対応する記憶領域を主記憶装置８０３に確保する。

【0132】

当該プログラムは、具体的には、工事入札のために元請事業者と下請事業者との間の見積に関する取引情報の管理をコンピュータ８０１に実行させる取引情報管理プログラムであって、工事入札毎に当該工事入札に必要な複数の見積費目を含み元請事業者に紐づけられた元請毎入札情報と、前記元請事業者が予め指定した複数の下請を含む元請グループ情報と、を記憶する記憶工程と、前記元請グループ情報に含まれる下請事業者に対し、前記元請毎入札情報の各見積費目について見積単価の登録を許可する見積情報管理工程と、をコンピュータに実行させるものである。

【0133】

なお、補助記憶装置８０４は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、インタフェースを介して接続される磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムがネットワークＮＷを介してコンピュータ８０１に配信される場合、配信を受けたコンピュータ８０１が当該プログラムを主記憶装置８０３に展開し、上記処理を実行しても構わない。

【0134】

また、当該プログラムは、前述した機能の一部を実現するためのものであっても構わない。さらに、当該プログラムは、前述した機能を補助記憶装置８０４に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル（差分プログラム）であっても構わない。

【0135】

これまで説明してきた実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、請求の範囲に記載された発明とその均等の範囲に含まれるものとする。

【0136】

以上で本開示の実施形態の説明を終えるが、本開示の態様はこの実施形態に限定されるものではない。

【0137】

上記各実施形態において、見積情報管理部２１、２２１は、全費目について元請グループ情報に一括送信する「見積依頼」とは別に、あらかじめ下請の業種や実績等に応じて下請毎に見積もりを依頼する範囲（費目ごとまたは区分ごと）を指定しておき、または手動で指定し、特定の下請に特定の費目または区分の範囲で見積もりを依頼する「指定見積依頼」を実行する機能を備えていても良い。例えば、「見積依頼」後、ステータスが「未登録」のままの費目について、「指定見積依頼」により調整を行うことで、原価等の入札価格情報の算出精度が向上する

【0138】

上記各実施形態において、見積情報管理部２１、２２１は、再見積単価の下請毎単価について、１回目に提出された見積単価を反映する機能を有していてもよい。これにより、入力の時間が短縮される。

【0139】

上記第２実施形態において、入札情報ＤＢ２１２に記憶される入札情報は、各公告情報に、発注者入札情報を含み、発注者である入札主催者に紐づく情報を含んでもよい。発注者入札情報は、その公告情報の共通入札情報と、発注者に対して公開が許可されている元請毎入札情報および下請毎入札情報とから自動的に作成される情報である。そして、ユーザ管理部２２４は、ユーザである発注者からの要求に基づいて、「発注工事明細」を出力してもよい。発注工事明細は、発注者に紐づく１または複数の公告情報の一覧情報である。

【0140】

上記第２実施形態において、出力管理部２２６は、ユーザである下請や発注者からの要求に基づいて、「実行予算の予実管理情報」を出力してもよい。

【符号の説明】

【0141】

１、２０１ ：取引情報管理システム
２、６ ：取引情報管理サーバ
３ ：公告配信サーバ
４ ：元請端末
５ ：下請端末
７ ：発注者端末
１０、２１０ ：記憶部
１１、２１１ ：登録ユーザデータベース
１２、２１２ ：入札情報データベース
２０、２２０ ：処理部
２１、２２１ ：見積情報管理部
２２、２２２ ：価格算出部
２３ ：下請実績評価部
２４ ：ユーザ管理部
２５ ：制御部
２２６ ：出力管理部
２２７ ：マッチング管理部
ＮＷ ：ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】