JP6978115B2 - 情報処理システム、情報処理方法、及びプログラム - Google Patents

Description

本発明は、情報処理システム、情報処理方法、及びプログラムに関する。

従来から、建物のリフォームの工事に関する見積を作成するシステムは存在する（例えば特許文献１参照）。

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

しかしながら、建物の工事の候補の場所等現場にて見積りを即座かつ精度よく発行することの要望がなされているが、上述の特許文献１を含む従来の技術ではこのような要望に応えることができない状況である。

本発明は、このような状況に鑑みてなされたものであり、建物の工事の候補の場所等現場にて見積りを即座かつ精度よく発行することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理システムは、
建物の工事の施工内容を決定する施工内容決定手段と、
前記工事に必要な製品を決定する製品決定手段と、
前記工事について決定された前記施工内容及び前記製品についての、当該工事の施工者の候補との間で予め合意された原価情報に基づいて、当該工事に関する見積りを発行する見積発行手段と、
を備える。

また、前記工事の施工の日程を決定する施工日程決定手段と、
前記工事について決定された前記施工内容、前記製品、及び前記施工の日程に基づいて、前記工事の受注に関する処理を実行する受注手段と、
をさらに備えることができる。

前記工事について決定された、前記施工内容、前記製品、及び前記施工の日程に基づいて、当該工事の施工者の候補の段取りに関する情報を、段取情報として取得する段取情報取得手段、
をさらに備え、
前記受注手段は、さらに前記段取情報に基づいて、前記工事の受注に関する前記処理を実行することができる。

前記工事の受注の内容に基づいて、前記候補を前記工事の施工者として決定し、当該施工者に対して前記工事の施工を発注する発注手段、
をさらに備えることができる。

前記情報処理システムにアクセスするためのアカウントを階層的に管理し、所定の単位毎にアクセスの制限要否を各階層で設定して管理する管理手段、
をさらに備えることができる。

本発明の一態様の情報処理方法及びプログラムの夫々は、上述の本発明の一態様の情報処理装置に対応する情報処理方法及びプログラムの夫々である。

本発明によれば、建物の工事の候補の場所等現場にて見積りを即座かつ精度よく発行することが可能になる。

本発明の情報処理システムの一実施形態の構成例を示すブロック図である。 図１に示す情報処理システムのうちリフォーム業者サーバのハードウェア構成の一例を示すブロック図である。 図２のリフォーム業者サーバの機能的構成の一例を示す機能ブロック図である。 図３のリフォーム業者サーバの機能的構成のうち、担当者処理制御部の詳細な機能的構成の一例を示す機能ブロック図である。 図１のリフォーム担当者端末の表示部に表示される各種画面の遷移の一例を示す画面遷移図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、ホーム画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、商品画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、製品吹出しの画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、製品吹出し＿工賃ポップアップの画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、カレンダーの画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、日程カレンダーの画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、「受注済」のタブの画面の一例を示す図である。 図３のリフォーム業者サーバの機能的構成のうち、施工者処理制御部の詳細な機能的構成の一例を示す機能ブロック図である。 図１のリフォーム担当者端末の表示部に表示される各種画面の遷移の一例であって、図５の例とは異なる例を示す画面遷移図である。 段取情報の例であって、施工者の候補の一例としての施工業者の単位での予定を示す情報を示す図である。 段取情報の図１５とは異なる例であって、施工者の候補の一例としての職人等の単位での予定を示す情報を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、受注履歴の画面の一例を示す図である。 図１のリフォーム担当者端末の表示部に表示される各種画面のうち、発注の画面の一例を示す図である。 図１のリフォーム業者サーバの表示部に表示される各種画面のうち、製品情報の入力又は確認用の画面の一例を示す図である。 リフォームサーバ又はリフォーム担当者端末のアカウントの階層の一例を説明する図である。 本発明が適用される情報処理システムの機能的構成の運用例を示す概略図である。 本発明の情報処理システムの第２実施形態の構成例を示すブロック図である。 図２２のリフォーム業者サーバの機能的構成のうち、担当者処理制御部の詳細な機能的構成の一例を示す機能ブロック図である。 電子サインでの注文書の契約処理動作を示すフローチャートである。 見積りから受注に至る画面を示す図である。 サイン画面を示すである。 契約形式選択のダイアログボックスを示す図である。 受注情報生成済みを示すダイアログボックスを示す図である。 署名リクエスト中を示すダイアログボックスを示す図である。 署名リクエストの画面を示す図である。 文書署名の画面を示す図である。 署名選択画面を示す図である。 電子契約の手続完了の画面を示す図である。 印刷、Ｅメール、完了のうち何れの選択を促す選択ダイアログボックスを示す図である。 電子サイン済みの約款付き注文書のＰＤＦファイルの一例を示す図である。 紙ベースでの注文書の処理動作を示すフローチャートである。 電子サインでの工事請負契約書の処理動作を示すフローチャートである。 紙ベースでの工事請負契約書の処理動作を示すフローチャートである。 電子サインでの解約合意書の処理動作を示すフローチャートである。 紙ベースでの解約合意書の処理動作を示すフローチャートである。 電子サインでの工事完了確認書の処理動作を示すフローチャートである。 紙ベースでの工事完了確認書の処理動作を示すフローチャートである。 受注分析画面を示す図である。 売上分析画面を示す図である。 販売分析画面を示す図である。 販売分析詳細画面を示す図である。 目標マスタ画面を示す図である。 発注管理画面を示す図である。 工程管理画面を示す図である。 支払管理画面を示す図である。 入金管理画面を示す図である。 予約管理画面を示す図である。 ＣＡＤ連携機能の画面を示す図である。 カタログ連携機能の画面を示す図である。

以下、本発明の実施形態について、図面を用いて説明する。

図１は、本発明の情報処理システムの一実施形態の構成例を示すブロック図である。
本実施形態の情報処理システムは、建物のリフォームの工事についての見積りから受注や発注までの一連の作業を支援する。この情報処理システムは、図１に示すように、リフォーム業者サーバ１と、リフォーム担当者端末２−１乃至２−ｎ（ｎは任意の整数値）と、施工者端末３−１乃至３−ｍ（ｍはｎとは独立した任意の整数値）とが、インターネット等のネットワークＮに夫々接続されることで構成される。

リフォーム業者サーバ１は、建物のリフォームの工事を請け負う業者（以下、「リフォーム業者」と呼ぶ）に管理され、建物のリフォームの工事についての見積りから受注や発注までの一連の作業を支援する。

ここで、「支援」と記載しているが、見積りから受注や発注までの作業を行う者は、リフォーム業者に属する従業員等であって、リフォームの工事を依頼するユーザの担当者（以下、「リフォーム担当者」と呼ぶ）である。
図１の例では、ｎ人のリフォーム担当者の夫々は、タブレット端末等で構成されるリフォーム担当者端末２−１乃至２−ｎの夫々を１台ずつ保有して、ユーザの自宅等の現場で、見積りや受注等の作業を行う。
なお、以下、ｎ人のリフォーム担当者の夫々を個々に区別する必要がない場合、リフォーム担当者端末２−１乃至２−ｎをまとめて「リフォーム担当者端末２」と呼ぶ。
即ち、リフォーム担当者は、現場でリフォーム担当者端末２を操作しながら、ユーザと打ち合わせ等をすることで、見積りのみならず受注や発注までの作業をその現場で行うことができる。

つまり、リフォーム担当者端末２は、リフォーム業者サーバ１と協働しながら、建物のリフォームの工事についての見積りから受注や発注までの一連の作業を支援する処理として、例えば次のような一連の処理を実行することができる。
ここで、「協働」の手法は、特に限定されない。例えばリフォーム担当者端末２はリフォーム業者サーバ１と適宜通信をしながら主要な処理をリフォーム業者サーバ１に実行してもらう第１手法を、「協働」の手法として採用することができる。また例えば、リフォーム担当者端末２は、リフォーム業者サーバ１又はその管理下の図示せぬ装置から専用のアプリケーションソフトウェア（以下、単に「アプリ」と呼ぶ）を予めダウンロードして、アプリで実行する第２手法を、「協働」の手法として採用することができる。或いはまた第１手法と第２手法とを適宜組み合わせた手法を、「協働」の手法として採用することもできる。
ただし、以下の例では、説明の便宜上、第１手法が「協働」の手法として採用されているものとして説明する。即ち、以下の例で、処理の動作主体が「リフォーム業者サーバ１」となっている個所は例示に過ぎず、実装時には適宜「リフォーム担当者端末２」としてよいことは言うまでもない。

即ち、本例では、リフォーム業者サーバ１は、建物のリフォームの工事についての見積りから受注や発注までの一連の作業を支援する処理を、リフォーム担当者端末２と適宜通信を行いながら実行する。

ここで、本例のリフォーム業者は、リフォームの工事を自身で請け負うのではなく、施工業者や職人（以下、これらをまとめて「施工者」と呼ぶ）に発注して、当該施工者に請け負ってものとする。ただし、本例は例示に過ぎず、リフォーム業者は、リフォームの工事の少なくとも一部を自身で請け負う場合もある。
つまり、リフォームの工事の前の段階で、当該工事を請け負う施工者を確保（発注）しておくための段取りが必要である。
本例では、このような施工者の候補はｍ人存在し、ｍ人の施工者の夫々は、施工者端末３−１乃至３−ｍの夫々を１台ずつ保有して、自身の予定を開示したり、リフォーム業者からの発注等に対する応答を行うものとする。なお、以下、ｍ人の施工者の夫々を個々に区別する必要がない場合、施工者端末３−１乃至３−ｍをまとめて「施工者端末３」と呼ぶ。
本例では、リフォーム業者サーバ１は、施工者端末３と適宜通信をすることで、施工者の候補の段取りを支援する処理を実行する。

以上まとめると、例えば、リフォーム業者サーバ１は、建物のリフォームの工事の施工内容、当該工事に必要な１以上の製品（建材等）、及び当該工事の施工の日程を、リフォーム担当者端末２と適宜通信をすることで決定する。
リフォーム業者サーバ１は、その工事について決定された施工内容及び製品について、当該工事の施工者の候補との間で予め合意された原価情報に基づいて、当該工事に関する見積りを発行する。

これにより、次のような効果を奏することができる。
即ち、リフォーム担当者は、従来のシステムを用いていた際には現場で見積りを発行しようとしても、施工業者の候補に連絡を取ったり、或いは、上司等に連絡を取って金額の承認を得たり等諸々の作業が必要であった。このため、リフォーム担当者が、現場にて、即座に見積りを発行したり、精度良い見積りを発行することは非常に困難であった。
しかしながら、図１の情報処理システムを用いることで、当該工事の施工者の候補との間で予め合意された原価情報が製品や施工内容毎に用意されている。このことは、従来のシステムで見積りの発行に必要であった、施工業者の候補に連絡を取ったり、或いは、上司等に連絡を取って金額の承認を得たり等諸々の作業と等価なことが、事前に済んでいること意味する。したがって、リフォーム担当者は、これらの諸々の作業を行う必要は無くなるため、現場等にて見積りを即座にかつ精度よく発行することが出来るようになる。

さらに、リフォーム業者サーバ１は、工事について決定された施工内容、製品、及び施工の日程に基づいて、工事の受注に関する処理を実行することができる。
これにより、リフォーム担当者は、現場にて見積りのみならず、受注もすることができる。

具体的には、リフォームにおいては、ユーザは家での困りごとがあり、「至急なんとかしたい」という要望が存在する。
しかしながら、従来、リフォーム業者の側には、法律上及びリフォーム業者の手続き上かなりの事務作業が存在し、下記のステップＳＴ１乃至ＳＴ１０の工程が必要であったため、上述の要望に十分に応えることができない状況であった。

即ち、ステップＳＴ１は、「下請けに見積りを取る」、という工程である。ステップＳＴ２は、「見積り作成のため再訪問、下請けによる現場確認（調査等）」、という工程である。ステップＳＴ３は、「下請けからの見積り提出待ち（およそ一週間程度）」、という工程である。ステップＳ４は、「ステップＳＴ１で取った下請けの見積りに利益を乗せた価格でお客様に提出していいのか、上司等に確認してリフォーム業者（会社）としての承認が必要」、という工程である。ステップＳＴ５は、「承認後、ユーザに提示する見積りを作成して、リフォーム業者（会社）としての承認を行う」、という工程である。ステップＳＴ６は、「見積りをユーザに提出（一般的にはここまでで２週間かかる）」、という工程である。ステップＳＴ７は、「ユーザから契約意思を受ける」、という工程である。ステップＳＴ８は、「注文書及び工事約款を作成する」、という工程である。ステップＳＴ９は、「注文書及び工事約款の書類をユーザから受取る」、という工程である。ステップＳＴ１０は、「ユーザへ請け書を発行する」、という工程である。
このステップＳＴ１０の工程が終了すると、ユーザからの受注が完了する。

しかしながら、リフォーム担当者は、図１の情報処理システムを用いることで、これらのステップＳＴ１乃至ＳＴ１０の面倒で手間のかかる事務作業を自身で手動で行わなくても、見積りや受任をユーザの家等の現場で即座に行うことができる。
このようにして、図１の情報処理システムを適用することで、ユーザは家での困りごとがあり、「至急なんとかしたい」というリフォームの要望に、応えることできるようになる。

さらに、リフォーム業者サーバ１は、工事について決定された、施工内容、製品、及び施工の日程に基づいて、当該工事の施工者の候補の段取りに関する情報を、段取情報として取得することができる。
そして、リフォーム業者サーバ１は、さらに段取情報に基づいて、工事の受注に関する処理を実行することができる。
これにより、リフォーム担当者は、施工業者の段取りを確実にしたうえで、ユーザから適切な受注を得ることができる。
なお、段取情報の具体例については、図１５や図１６を参照して後述する。

また、リフォーム業者サーバ１は、工事の受注の内容に基づいて、候補であった者を工事の施工者として決定し、当該施工者に対して工事の施工を発注することができる。
これにより、リフォーム担当者は、見積りや受注のみならず、工事の発注も短期間にかつ簡便な作業ですることができる。

具体的には、上述したように、リフォームにおいては、ユーザは家での困りごとがあり、「至急なんとかしたい」という要望が存在する。
しかしながら、従来、リフォーム業者の側には、法律上及びリフォーム業者の手続き上かなりの事務作業が存在し、上述のステップＳＴ１乃至ＳＴ１０の工程に加えて、工事の発注までするために次のようなステップＳＴ１１乃至ＳＴ１６の工程が必要であったため、上述の要望にさらに十分に応えることができない状況であった。

即ち、ステップＳＴ１１は、「工事台帳を作り、下請け業者（施工業者の候補）からの見積書を参照して転記する」、という工程である。ステップＳＴ１２は、「契約に関する情報（ユーザの顧客情報、施工に関する情報、入金に関する情報）を取得する」、という工程である。ステップＳＴ１３は、「上述のステップＳＴ１１及びＳＴ１２の各工程での内容に基づいて発注書を作る」、という工程である。ステップＳＴ１４は、「この発注書の内容について、リフォーム事業者（会社）が承認する」、という工程である。ステップＳＴ１５は、「下請け業者（施工業者の候補）に発注書を例えばメールやＦＡＸ等で提出する」、という工程である。なお、ステップＳＴ１５の時点で工事の日程が確実に確定する。ステップＳＴ１６は、「下請け業者（施工業者の候補）から発注請け書を受領する」、という工程である。

しかしながら、リフォーム担当者は、図１の情報処理システムを用いることで、ステップＳＴ１１乃至ＳＴ１６の面倒で手間のかかる事務作業を自身で手動で行わなくても、簡便な作業のみで、工事の発注を短期間に行うことができる。
このようにして、図１の情報処理システムを適用することで、ユーザは家での困りごとがあり、「至急なんとかしたい」というリフォームの要望に、応えることができるようになる。

このように、本例ではリフォーム業者サーバ１が主要な処理を実行する（上述の第１手法に従った処理を実行する）ため、図１の情報処理システムのうちリフォーム業者サーバ１に着目して、以下の説明を行う。

図２は、図１に示す情報処理システムのうちリフォーム業者サーバのハードウェア構成の一例を示すブロック図である。

リフォーム業者サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

出力部１６は、液晶等のディスプレイやスピーカ等により構成され、各種情報を画像や音声として出力する。
入力部１７は、例えばキーボード等により構成され、各種情報を出力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば図１のリフォーム担当者端末２や施工者端末３等）との間で通信を行う。

ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３０が適宜装着される。ドライブ２０によってリムーバブルメディア３０から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。
また、リムーバブルメディア３０は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

なお、図示はしないが、図１のリフォーム担当者端末２や施工者端末３も、図２に示すハードウェア構成と基本的に同様の構成を有することができる。従って、リフォーム担当者端末２と施工者端末３のハードウェア構成の説明については省略する。

このような図２のリフォーム業者サーバ１の各種ハードウェアと各種ソフトウェアとの協働により、建物のリフォームの工事についての見積りから受注や発注までの一連の作業を支援する処理の実行が可能になる。
以下、このような処理を実行するためのリフォーム業者サーバ１の機能的構成の一例について説明する。

図３は、図２のリフォーム業者サーバの機能的構成の一例を示す機能ブロック図である。

図３に示すように、リフォーム業者サーバ１のＣＰＵ１１においては、担当者処理制御部５１と、施工者処理制御部５２と、主制御部５３とが機能する。
担当者処理制御部５１は、通信部１９を介してリフォーム担当者端末２と通信をすることで、リフォーム担当者端末２と協働して、担当者の作業を支援するための処理を制御する。
施工者処理制御部５２は、通信部１９を介して施工者端末３と通信をすることで、施工者の候補の段取り等を支援するための処理を制御する。

担当者処理制御部５１は、建物のリフォームの工事の施工内容、当該工事に必要な１以上の製品（建材等）、及び当該工事の施工の日程を、リフォーム担当者端末２と適宜通信をすることで決定する。
施工者処理制御部５２は、その工事について決定した、施工内容、１以上の製品、及び日程に基づいて、当該工事の施工者の候補の段取りに関する情報を、段取情報として施工者端末３から取得する。
担当者処理制御部５１は、この段取情報に基づいて、当該工事の受注の可否を判断する。

主制御部５３は、このような担当者処理制御部５１と施工者処理制御部５２とを含むリフォーム業者サーバ１について、その全体の処理を制御する。
例えば主制御部５３は、担当者処理制御部５１と施工者処理制御部５２との間で授受される情報を適宜加工等したうえで、一方から他方へ伝送する制御等を実行する。
また例えば、主制御部５３は、情報処理システムにアクセスするためのアカウントを階層的に管理し（例えば後述する図２０に示す階層でアカウントを管理し）、所定の単位毎にアクセスの制限要否を各階層で設定して管理することができる。
また例えば、主制御部５３は、見積りや受注案件の内容の確認をリフォーム担当者等が行うに際し、各種支援をするための制御を実行することができる。ここで、見積りや受注案件の内容の確認には、スケジュール、案件進捗や工程管理含の確認も含まれる。なお、このような制御を実行する機能ブロックを、図示はしないが、「見積・受注案件内容確認手段」と呼ぶことにする。この見積・受注案件内容確認手段には、上述のように、スケジュール、案件進捗、工程管理の確認機能も含まれる。

以下、担当者処理制御部５１と施工者処理制御部５２の夫々について、その順番に個別に説明していく。

先ず、担当者処理制御部５１の詳細な機能的構成例について説明する。
図４は、図３のリフォーム業者サーバの機能的構成のうち、担当者処理制御部の詳細な機能的構成の一例を示す機能ブロック図である。
担当者処理制御部５１には、図４に示すように、施工内容決定部６１と、製品候補提示部６２と、製品決定部６３と、見積発行部６４と、施工日程案提示部６５と、施工日程決定部６６と、施工者段取確認部６７と、受注可否判定部６８と、受注処理部６９とが設けられている。

なお、図４の担当者処理制御部５１の詳細な機能的構成（図４に示す各機能ブロック）について説明をするに際し、図５乃至図１２に示す具体例を適宜用いて説明する。

担当者処理制御部５１は、図５に示す遷移をする各種画面を、リフォーム担当者端末２の図示せぬ表示部（ディスプレイ）に表示させる制御を実行しながら施工内容決定部６１乃至受注処理部６９の夫々を適宜機能させる。

図５は、図１のリフォーム担当者端末の表示部に表示される各種画面の遷移の一例を示す画面遷移図である。
図５の画面遷移図において、長方形は１つの画面を示しており、当該長方形（画面）内において、「Ｐ」を含む記号は画面のＩＤを示しており、その下方の文字列は画面の内容（又は名称）を示している。
また、図５の画面遷移図において、第１の長方形（第１の画面）から、第２の長方形（第２の画面）に向かう矢印は、所定の遷移条件が満たされた場合、リフォーム担当者端末２の表示部に表示される対象が、第１の画面から第２の画面に遷移されることを示している。なお、遷移条件は、特に限定されず、多くの場合、第１の画面に表示される所定のソフトウェアボタンに対する押下操作がなされたこと等の条件が採用されている。

図４に戻り、施工内容決定部６１は、リフォームの工事の施工内容を決定する。
具体的には例えば、施工内容決定部６１は、図６に示す画面（図５のＩＤ：Ｐ−００２のホーム画面）をリフォーム担当者端末２に表示させる。
図６は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、ホーム画面の一例を示す図である。
図６の画面において、「パック商品」、「キッチン」、・・・、「エクステリア」、・・・というメッセージが表示される選択ボックスは、ユーザ又はリフォーム担当者により施工内容が選択される際に押下操作がなされる。即ち、「パック商品」、「キッチン」、・・・、「エクステリア」、・・・というメッセージは、施工内容を示している。
そこで、図４の施工内容決定部６１は、ユーザ又はリフォーム担当者により押下操作がなされた選択ボックスに表示されたメッセージ、例えば「エクステリア」等を、施工内容として決定する。

このようにして、施工内容が決定されると、即ち、その施工内容を示すメッセージが表示された選択ボックスが押下されると、リフォーム担当者端末２の表示部に表示される画面は、図６に示す画面から、図５のＩＤ：Ｐ−００２＿２の絞込検索の画面（図示せず）を経由して、図７に示す画面（図５のＩＤＰ−００２＿３の商品選択の画面）に遷移する。
即ち、図４の製品候補提示部６２は、例えば図７に示す画面をリフォーム担当者端末２に表示させることで、決定された施工内容のリフォームの工事に必要な１以上の製品の候補を提示する。
図７は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、商品画面の一例を示す図である。
図７の画面には、決定された施工内容のリフォームの工事に必要な製品（商品）の複数の候補を示す選択ボックス（図７の例では３つの選択ボックス）が表示される。これらの複数の候補の中から、リフォームの工事に必要な製品（商品）がユーザ又はリフォーム担当者により選択される。即ち、選択された製品（商品）が表示された選択ボックスに対して押下操作がなされる。

この場合、リフォーム担当者端末２の表示部に表示される画面は、例えば図７に示す画面から、図８に示す画面（図５のＩＤＰ−００２＿４＿１の製品吹出しの画面）に遷移する。
図８は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、製品吹出しの画面の一例を示す図である。
図８の画面においては、図７の画面で選択された製品（商品）の各詳細が吹出しで示される。
即ち、１つの製品（商品）は、複数の小製品（部品等）で構成される場合があり、かつ小製品の変更等のカスタマイズが可能な場合がある。このような場合、小製品単位で、カスタマイズに必要な情報や小製品の説明等が吹出しで表示される。ユーザは、カスタマイズの選択をするために吹出しを適宜参考にできるので、非常に便利である。
即ち、図４の製品候補提示部６２は、例えば図７の画面のみならず図８の画面をリフォーム担当者端末２に表示させることで、決定された施工内容のリフォームの工事に必要な１以上の製品の候補を提示することもできる。

ユーザ又はリフォーム担当者のリフォーム担当者端末２に対する操作に基づいて、製品（商品）が選択され、小製品（部品等）のカスタマイズについての操作がなされると、リフォーム担当者端末２の表示部には、例えば図９に示す画面（図５のＩＤＰ−００２＿４＿３の製品吹出し＿工賃ポップアップの画面）が表示される。
図９は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、製品吹出し＿工賃ポップアップの画面の一例を示す図である。
図９の画面には、リフォームの工事に必要な製品（商品）として選択されたものの工賃（工事費）がポップアップ表示される。
即ち、図４の製品候補提示部６２は、例えば図７及び図８の各画面のみならず図９の画面をリフォーム担当者端末２に表示させることで、決定された施工内容のリフォームの工事に必要な１以上の製品の候補を提示することもできる。

ユーザが、上述の各種画面を視認しながら、リフォームの工事の施工内容、及び当該工事に必要な１以上の製品（商品）について選択して、その選択内容で確定する場合、所定の操作（図示せぬ画面に対して）を実行する。
すると、図４の製品決定部６３は、ユーザによる所定の操作により確定された１以上の製品（商品）を、リフォームの工事に必要な１以上の製品（商品）として決定する。

見積発行部６４は、製品決定部６３により決定された１以上の製品について、製品の代金や工賃等を含む見積書をデータとして発行する。リフォーム担当者端末２は、見積書を表示部に表示させたり、紙媒体として印刷したり、見積書のデータを図示せぬユーザの端末に送信することができる。
ここで、見積発行部６４は、その工事について決定された施工内容及び製品について、当該工事の施工者の候補（下請け業者等）との間で予め合意された原価情報に基づいて、当該工事に関する見積りを発行することができる。
これにより、上述したように、リフォーム担当者は、従来必要であった長時間を要し非常に面倒な諸々の作業を行う必要は無くなるため、現場にて見積りを即座かつ精度よく発行することが出来るようになる。
なお、図示はしないが、見積書の発行の前に、ユーザに対して電子サインを入力させる領域や、リフォームの工事に必要な製品（商品）として確定することをユーザに対して確認させるためのボタン（商品確認ボタン）を備えた画面（見積確認画面）が、ユーザに提示されてもよい。
また、見積発行部６４は、施工内容や商品についてその場で（上司の承認を得たり、或いは後述する値引きの権限をリフォーム担当者のアカウントに特別に付与したりする等）見積額を値引きする処理（値引きの処理）を実行できるようにしてもよい。
なお、値引きの処理の形態は特に限定されず、金額の端数を取る形態や、何パーセント引きの形態等を採用することができる。

施工日程案提示部６５は、リフォームの工事について、施工内容決定部６１により決定された施工内容、及び製品決定部６３により決定された製品に基づいて、工事の施工の日程に関する提案をユーザに対して行うことができる。
即ち、上述したように、製品決定部６３により複数の製品（複数の商品の場合もあるし、１つの商品内の複数の部品の場合もある）が決定された場合、同時に施工可能な製品、施工すべき製品、及び施工できない製品等の製品（建材）が存在するときもある。このようなときには、施工日程案提示部６５は、これらの製品の関係性に応じて効率的な施工日程及び支払日（リフォーム業者にとっての入金日）を提案することができる。

リフォームの工事の施工の日程に関する提案は、例えば図１０に示す画面（図５のＩＤ：Ｐ−００３のカレンダーの画面）や図１１に示す画面（図５のＩＤ：Ｐ−００４＿７の日程カレンダーの画面）に含まれて、リフォーム担当者端末２の表示部に表示される。
図１０は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、カレンダーの画面の一例を示す図である。
図１１は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、日程カレンダーの画面の一例を示す図である。
図１０や図１１の各画面には、カレンダーが表示されると共に、リフォームの工事の日程等も適宜表示される。
なお、上述の説明では、施工日程案提示部６５により提案された日程は、あくまでも案であって、ユーザ又はリフォーム担当者によるリフォーム担当者端末２に対する所定の操作により適宜変更可能である。或いは、ユーザ又はリフォーム担当者は、リフォーム担当者端末２に対する所定の操作を行うことで、施工日程案提示部６５による提案を待たずに、所望の日程を設定することもできる。
施工日程決定部６６は、ユーザ又はリフォーム担当者のリフォーム担当者端末２に対する所定操作により最終的に設定された日程を、リフォームの工事の施工の日程として決定する。

施工者段取確認部６７は、主制御部５３の制御のもと、リフォームの工事について決定された、施工内容、１以上の製品、及び日程を、施工者処理制御部５２に通知する。
詳細については後述するが、施工者処理制御部５２は、施工者端末３と適宜通信をすることで、リフォームの工事の施工者の候補の段取りに関する情報を、段取情報として施工者端末３から取得する。段取情報は、主制御部５３の制御のもと、施工者処理制御部５２から担当者処理制御部５１に伝送される。
そこで、担当者処理制御部５１の施工者段取確認部６７は、段取情報に基づいて、施工者の候補の段取（施工者の候補の予約等による確保等）ができたか否かを確認する。

受注可否判定部６８は、施工者段取確認部６７による確認の結果、即ち、施工者の候補の段取（施工者の候補の予約等による確保等）ができたか否か等に基づいて、リフォームの工事についてユーザからの受注が可能か否かを判定する。
なお、受注可否判定部６８は、必須な構成要素ではなく、適宜省略することが可能である。

受注処理部６９は、本例では受注が可能と受注可否判定部６８により判定された場合、その旨をユーザ又はリフォーム担当者に通知して、リフォームの工事についてユーザからの受注に関する各種処理を実行する。
なお、本例は例示に過ぎず、上述のように受注可否判定部６８が存在しない場合には、受注処理部６９は、施工者の段取情報の有無にかかわらず独立して、リフォームの工事についてユーザからの受注に関する各種処理を実行することもできる。

以上のような一連の処理は、ユーザやリフォーム等を単位として、各単位毎に独立して実行が可能である。
このため、ユーザやリフォーム等の管理毎に、その進捗状況、例えば、見積書の発行までは済んではいるが未受注の段階と、受注済の段階との何れかであるかが区別つくと、リフォーム担当者にとって便宜である。
そこで、例えば図１２に示す画面（図５のＩＤ：Ｐ−００７＿４のオーダー検索（「受注済」のタブの画面））がリフォーム担当者端末２の表示画面に適宜表示される。
図１２は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、「受注済」のタブの画面の一例を示す図である。
リフォーム担当者は、リフォーム担当者端末２に対して所定の検索操作を行うことで、図１２の画面が提示されるので、受注済のユーザ等を容易に確認することができる。

以上、図３のリフォーム業者サーバ１の機能的構成のうち、担当者処理制御部５１の機能的構成例について図４乃至図１２を参照して説明した。
次に、図３のリフォーム業者サーバ１の機能的構成のうち、施工者処理制御部５２の機能的構成例について図１３乃至図２０を参照して説明する。

図１３は、図３のリフォーム業者サーバの機能的構成のうち、施工者処理制御部の詳細な機能的構成の一例を示す機能ブロック図である。
施工者処理制御部５２には、図１３に示すように、施工情報取得部８１と、施工者段取部８２と、受注確認部８３と、施工者発注処理部８４とが設けられている。

なお、図１３の施工者処理制御部５２の詳細な機能的構成（図１３に示す各機能ブロック）について説明をするに際し、図１４乃至図１８に示す具体例を適宜用いて説明する。

施工者処理制御部５２は、図１４に示す遷移をする各種画面を、リフォーム担当者端末２の図示せぬ表示部（ディスプレイ）に表示させる制御を実行しながら、施工情報取得部８１乃至施工者発注処理部８４の夫々を適宜機能させる。

図１４は、図１のリフォーム担当者端末の表示部に表示される各種画面の遷移の一例であって、図５の例とは異なる例を示す画面遷移図である。
画面遷移図の記載の規則等については、図５と同様であるので、ここではこれらの説明は省略する。

施工情報取得部８１は、リフォームの工事について担当者処理制御部５１により決定された、施工内容、１以上の製品、及び日程を含む情報を、施工情報として、主制御部５３を介して担当者処理制御部５１から取得する。

施工者段取部８２は、リフォームの工事の施工情報（施工内容、１以上の製品、及び日程）に基づいて、当該工事の施工者の候補の段取りに関する情報を、段取情報として施工者端末３から取得する。

このような施工者段取部８２には、施工者日程調整部９１と、施工者発注予約部９２とが設けられている。

施工者日程調整部９１は、図１５に示す施工業者（施工者の候補の一例）の予定を示す情報や、図１６に示す職人等（施工者の候補の別の一例）の日程を示す情報を、段取情報の一部として施工者端末３から取得する。

図１５は、段取情報の例であって、施工者の候補の一例としての施工業者の単位での予定を示す情報を示す図である。
図１６は、段取情報の図１５とは異なる例であって、施工者の候補の一例としての職人等の単位での予定を示す情報を示す図である。
図１５及び図１６の夫々の段取情報においては、施工業者又は職人等での単位の工程表（予定表）が日単位で含まれており、日単位で他の予定が入っているか否か、即ち、リフォームの工事の日程で調整できるか（予約が取れるか）否かが容易に判断可能なようになっている。

製品、施工内容によって、その工事を請け負うことができる業者が絞り込まれ、絞り込まれた業者予定を閲覧することができる。即ち、図１５に示される段取情報の例には、「施工業者Ｘ」のＡ工事乃至Ｄ工事の工程表（日程表）が、日単位で含まれて表示される。まず、製品や施工内容に基づき、当該製品や当該施工内容を請け負うことができる（受注可能な）施工業者（図１５の例では施工業者Ｘ）が、絞り込まれる。次に、リフォーム担当者端末２は、絞り込まれた施工業者の予定を表示することができる。
受注可否判断について、リフォーム担当者端末２（タブレット）上にて、施工内容と日程を決定した際、その施工内容を請け負うことができる業者予定が空いていない場合、その決定が拒否される。即ち、所定の施工内容及び日程の受注を受注可能な業者が存在しない場合、当該受注は、拒否される。具体的には例えば、リフォーム担当者端末２において所定の施工内容及び日程における受注の決定を受付けた場合、当該施工内容を請け負うことができる施工業者の予定が空いていないとき、当該受注の決定は拒否される。
職人毎の予定が閲覧可能であり、なおかつ職人には書き込みの権限があり、予定を書き込んでもらう。その後、図１５に反映され、業者側は施行者側の予定が確認できるようになる。即ち、職人は、施工者端末３を用いて、当該職人自身の予定を閲覧することができる。また、職人は、施工者端末３を用いて、当該職人自身の予定を書き込むことができる。職人により書き込まれた予定は、段取情報に含まれる。即ち、職人により書き込まれた予定は、リフォーム担当者端末２等において、図１６に示すように職人毎の予定等として表示される。

図１３に戻り、施工者日程調整部９１は、これら図１５や図１６の例等の段取情報に基づいて、各施工者の候補毎に（施工業者単位でも職人単位でも、両者を区別せずにあわせた単位でも構わない）、リフォームの工事の日程で調整できるか（予約が取れるか）否かを判断する。

施工者発注予約部９２は、施工者日程調整部９１によりリフォームの工事の日程で調整できる（予約が取れる）と判断された施工者の候補の施工者端末３に対して、当該施工者の候補の予約を行うための各種処理を実行する。
具体的には例えば、施工者発注予約部９２は、リフォームの工事の施工情報（施工内容、１以上の製品、及び日程）を、施工者端末３（施工者の候補）に通知する。すると、施工者端末３は、当該工事の発注を受ける旨の施工者の候補の意思表示を示す情報を送信する。そこで、施工者発注予約部９２は、当該情報を、上述の段取情報の少なくとも一部として、施工者端末３（施工者の候補）から取得することで、当該施工者の候補の予約をすることができる。

ここで、注目すべき点は、施工者発注予約部９２を設けることで、従来において受注前若しくは受注後に施工業者を押さえることはできるものの発注までできなかったという課題を解決することができる、という点である。
即ち、リフォーム業者（或いはリフォーム担当者）の操作に基づいて機能する施工者発注予約部９２は、施工者の候補（その施工者端末３）に直接コンタクトをして、工事の発注を受ける旨の施工者の候補の意思表示を受けることができる。その結果、上述の従来の課題が解決される。

このようにして、リフォームの工事の日程で施工者の候補の予約が取れると、そのことを示す情報は、段取情報の一部として、図３の主制御部５３を介して担当者処理制御部５１に伝送される。
すると、担当者処理制御部５１は、上述したように、リフォームの工事のユーザに対する受注が可能であると判定し、受注に関する処理を実行する。

受注確認部８３は、施工者の候補の発注を予定しているリフォームの工事について、ユーザに対する受注が済んだか否かを確認する。
例えば、受注確認部８３は、図１７に示す画面（図１４のＩＤ：Ｐ−０２５の「受注履歴」の画面）をリフォーム担当者端末２の表示画面に表示させる。
図１７は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、受注履歴の画面の一例を示す図である。
図１７の画面には、リフォームの工事毎の単位で、見積り（未受注）の段階、受注済の段階、引き取り（工事終了）の段階等のステータス（進捗）が表示される。
そこで、受注確認部８３は、施工者の候補の発注を予定しているリフォームの工事について、そのステータス（進捗）を確認することで、ユーザに対する受注が済んだか否かを確認する。

施工者発注処理部８４は、ユーザに対する受注が済んだことが確認されたリフォームの工事について、予約済みの施工者の候補に対して正式に発注するための各種処理を実行する。
例えば、施工者発注処理部８４は、図１８に示す画面（図１４のＩＤ：Ｐ−０２５＿３の「発注」の画面）をリフォーム担当者端末２の表示画面に表示させる。
図１８は、図１のリフォーム担当者端末の表示部に表示される各種画面のうち、発注の画面の一例を示す図である。
図１８の画面には、リフォームの工事毎の単位で、施工者に対して正式な発注をするために必要な情報（例えば期間等）を入力するための領域が設けられている。そこで、リフォーム担当者等は、リフォーム担当者端末２を操作して、この領域に各種情報を入力し、決定等の所定の操作を実行する。
例えば、施工者発注処理部８４は、当該所定の操作を受け付けると、リフォーム担当者等により入力された各種情報を含む発注書のデータを生成し、施工者端末３に送信することで、施工者に対して正式な発注をする。

ところで、上述したように、ユーザ又はリフォーム担当者のリフォーム担当者端末２に対する操作に基づいて、リフォームの工事の施工内容が決定され、その施工内容のリフォームの工事に必要な製品（商品）が決定されると、見積りの発行が可能になる。
その際、リフォーム担当者が、従来必要であった長時間を要し非常に面倒な諸々の作業を行うことなく、現場にて見積りを即座かつ精度よく発行することが出来るようになるために、次のようにして見積りが発行される。
即ち、上述したように、その工事について決定された施工内容及び製品について、当該工事の施工者の候補（下請け業者等）との間で予め合意された原価情報に基づいて、当該工事に関する見積りが発行される。

このような見積りの発行を可能にすべく、各施工内容又は各製品毎に、当該工事の施工者の候補（下請け業者等）との間で予め合意された原価情報について予め入力され、リフォーム業者サーバ１により予め管理されていると便宜である。
このため、所定製品の原価情報を含む製品情報の入力又は確認用の画面が、図１のリフォーム業者サーバ１に適宜表示され、リフォーム業者の権限付与者により当該所定製品の製品情報が入力（更新含む）されたり、視認される。なお、権限付与者については、図２０を参照して後述する。
なお、製品又は施工内容の一部について、その原価が予め入力されていなくても、原価をその場で入力する機能も備え付けられている。ただし、リフォーム担当者が自在に入力できるようにすることは適切でなく、その上司等後述する図２０のアカウントの上位者のみが入力できるようにすると好適である。もちろん、値引き処理等ができるように、リフォーム担当者に権限等を付与してもよい。

図１９は、図１のリフォーム業者サーバの表示部に表示される各種画面のうち、製品情報の入力又は確認用の画面の一例を示す図である。
図１９の画面には、入力又は確認の対象となる製品（商品）として選択されたものの製品情報の詳細項目がポップアップ表示される。
即ち、リフォーム業者の権限付与者は、図１９の画面をみながら、所定製品の製品情報を入力（更新含む）したり、確認を行うことができる。

具体的には例えば、図１９の画面のうち、「製品名」と表示された項目において、見積り時にユーザ（顧客）に提示される所定製品の名称や品番が入力（更新含む）され、その入力内容が表示される。

また例えば、図１９の画面のうち「原価」と表示された項目において、予め協力業者（施工業者の候補）と同意された所定製品の価格が入力（更新含む）され、その入力内容が表示される。
つまり、所定製品について、原価が予め設定されているので、リフォーム担当者が、見積り発行時に従来のように施工業者の候補（協力業者）に電話する等して原価を決定する必要が無くなる。その結果、その分だけ、現場で即座かつ容易に見積り発行が可能になる。
なお、リフォーム担当者端末２の画面において、所定製品に関する情報がユーザ（顧客）に提示される際には、この原価はユーザ（顧客）には見えないように制限が課される。

また例えば、図１９の画面のうち「販売価格」と「定価」と表示された各項目において、見積り時にユーザ（顧客）に提示される所定製品の販売価格と定価が夫々入力（更新含む）され、その入力内容が表示される。

また例えば、図１９の画面のうち「利益額」と「利益率」と表示された各項目において、予めリフォーム業者にて決定された（所定製品をユーザ（顧客）に販売する際における）利益額と利益率が夫々入力（更新含む）され、その入力内容が表示される。
つまり、所定製品について、原価のみならず、リフォーム業者の利益額や利益率が予め設定されているので、リフォーム担当者が、見積り発行時に従来のように利益額や利益率を上司に電話する等して承認を得る必要が無くなる。その結果、その分だけ、現場で即座かつ容易に見積り発行が可能になる。

また例えば、図１９の画面のうち「発注先」と表示された項目において、予め所定商品（この商材）について単価契約を結んでいる取引業者（協力業者、即ち施工業者の候補）が入力（更新含む）され、その入力内容が表示される。なお、予め所定商品（この商材）について単価契約を結んでいる取引業者は、複数存在する場合もある。

また例えば、図１９の画面のうち「詳細」と表示された項目において、ユーザ（顧客）に提示される所定商品（この商材）の注意点等の詳細情報が入力（更新含む）され、その入力内容が表示される。

また例えば、図１９の画面のうち「ポップアップ画像」と表示された項目において、商品選択の際にユーザ（顧客）が閲覧できる所定商品（その商材）についてのイメージ画像が入力（更新含む）され、その入力内容が表示される。

このように、図１９の画面を用いることで、所定製品についての原価や利益率等の事前の登録やその更新が可能になる。しかしながら、所定製品についての原価や利益は、リフォーム業者が会社として設定又は更新されるものであり、リフォーム業者に属しているからといって例えばリフォーム担当者が勝手に設定又は更新できるようであってはならない。つまり、リフォーム業者内で管理の立場にある者（例えばリフォーム担当者の上司等）等の限られた者のみが、所定製品についての原価や利益を設定又は更新できるようにしておくと好適である。
そこで、リフォームサーバ１（又はそこにアクセスする可能性のあるリフォーム担当者端末２）は、アカウントが付与された者のみが使用可能となっている。さらに、このアカウントは、図２０に示すように階層に区分されて管理され、リフォームサーバ１（又はそこにアクセスする可能性のあるリフォーム担当者端末２）で管理される情報は、所定単位（例えば画面や機能といった単位）毎に、どの階層の者までアクセスできるのかといったアクセス制限が自在に設定できるようになっている。
即ち、アカウントの階層によって、アクセスできる情報に差異がでるようにすることができる。例えば図１９の画面の各項目への入力（更新を含む）というアクセスは、上位階層のアカウントを有する者のみに許されるような設定が可能である。即ち、この上位階層のアカウントを有する者が、図１９の説明で上述した「権限付与者」である。

図２０は、リフォームサーバ又はリフォーム担当者端末のアカウントの階層の一例を説明する図である。
図２０において、本部管理システムがリフォームサーバ１に相当する。
リフォーム担当者（社員又は支店社員）のアカウントである。
図２０において、担当者甲、乙、・・・ｎの夫々が、アカウントを付与される者の一例であって、同図中上位に示すリフォーム業者（利用会社）及び本社又は支店に属する者である。
担当者甲、乙、・・・ｎの夫々は、個々のアカウントを有しており、自身が属しているリフォーム業者（利用会社）及び本部又は支店（同図において担当者と上方の実線で結ばれているところ）の管理下にある画面や機能についてどの範囲まで閲覧できるのかを設定するのかが、アカウントの権限として付与されている。即ち、どの範囲まで閲覧できるのかがアカウントの階層によって決まっており、その設定された階層で許可された範囲までの画面や機能等にアクセスすることができる。
また、図２０の下方に示される家は、ユーザ（顧客）を示している。即ち、担当者甲、乙、・・・ｎの夫々は、担当者甲、乙、・・・ｎの夫々は、自身が担当するユーザ（同図において担当者と実線で結ばれている顧客）についての情報を閲覧することができるが、他の担当者のユーザ（同図において担当者と実線で結ばれていない顧客）についての情報を閲覧することはできない。
なお、アカウントを付与される者は、図２０に図示されているリフォーム担当者は例示であり、社員又は支店社員に属する者、例えば管理者（リフォーム担当者の上司等）も含まれることは言うまでもない。
また例えば、アカウントの権限管理は、閲覧のみならず、各種操作に対しても行うことができる。例えば値引き処理に対して、リフォーム担当者（例えば担当者乙のみ）にその枠を持たせて操作させることも可能だし、それを超える場合やその権限を持たない場合には、図２０に図示せぬ上位権限者（例えばリフォーム担当者甲の上司等）に操作させることも可能である。

また例えば、図示はしないが、リフォーム担当者端末２等に備えられている機能を、ユーザ（顧客）の端末に移譲することもできる。これにより、ダウンロードして利用するアプリの形態に限らず、直接（ＷＥＢ上でダウンロードするタイプのアプリケーション（いわゆるネイティブアプリ）ではなく、ＷＥＢアプリ）でユーザ（顧客）がリフォームの依頼や注文もできるようになる。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述の実施形態では、情報処理システムは、建物のリフォームの工事についての見積りから受注や発注までの一連の作業を支援する処理を実行したが、特にリフォームに限定されない。

また例えば、図１に示すシステム構成や、図２に示すリフォーム業者サーバ１のハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、上述の図３、図４、及び図１３の夫々に示す各機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に上述の例に限定されない。

また、機能ブロックの存在場所も、図３、図４、及び図１３の上述の各例に限定されず、任意でよい。
例えば、上述の各例において、リフォーム業者サーバ１に全ての機能ブロックが設けられる構成となっているが、これは例示に過ぎない。例えば上述したように、リフォーム担当者端末２にインストールされたアプリが実行する機能ブロックとして、上述の例ではリフォーム業者サーバ１側に配置された機能ブロックの少なくとも一部を、リフォーム担当者端末２側が備える構成としてもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

例えば情報処理システムは、図２１のような機能的構成で運用することもできる。
図２１は、本発明が適用される情報処理システムの機能的構成の運用例を示す概略図である。図２１のブロックは、１つの機能ブロック、情報、又は情報処理装置を示している。例えば、本部システムは、図２０における本部管理システムに相当する機能を示している。

以下、本発明が適用される情報処理システムの第２実施形態を説明する。第２実施形態は、図１乃至図４に示した構成を享受する。
図２２は、情報処理システムの第２実施形態の構成例を示すブロック図である。なお、図１に示した構成例と同じ構成には同一の符号を付しその説明は省略する。
図２２に示すように、情報処理システムの第２実施形態は、リフォーム担当者端末２と、リフォーム業者サーバ１と、電子サインシステム４とを含む。

リフォーム担当者端末２は、工事を依頼するユーザ及び当該工事を請け負うリフォーム業者の担当者のうち少なくとも一方の操作を受け付けるタブレット等である。
電子サインシステム４は、ネットワークＮを介してリフォーム業者サーバ１と通信する。電子サインシステム４は、リフォーム業者サーバ１からの要求に応じて電子認証を行う所定認証機関（電子認証を公正に行う機関）である。
電子サインシステム４は、ユーザ及びリフォーム業者の夫々の署名を認証する。電子サインシステム４に予め署名を登録しておくことで、他者との取引の際に自動認証される。少なくともリフォーム業者は、署名を電子サインシステム４に事前に登録しておくものとする。

リフォーム業者サーバ１は、工事についての見積りから請負の契約に至るリフォーム業者の一連の作業を支援するものであり、以下において詳細に説明する。

次に、図２３を参照してリフォーム業者管理サーバ及びリフォーム担当者端末の機能的構成を説明する。なお、第２実施形態のリフォーム業者管理サーバは、図３及び図４にて説明した機能的構成と同じ符号の構成を含むものであり、同じ構成には同一の符号を付しその説明は省略する。
図２３は、図２２のリフォーム担当者端末の機能的構成と、図３のリフォーム業者サーバの機能的構成のうち、担当者処理制御部の詳細な機能的構成の一例を示す機能ブロック図である。

図２３に示すように、担当者処理制御部５１は、施工内容決定部１０１と、製品候補提示部６２と、製品決定部６３と、見積発行部６４と、受注処理部１０２と、契約制御部１０３と、を備える。契約制御部１０３は、認証制御部１１１を有する。
なお、見積発行部６４乃至受注処理部１０２の間（破線の部分）には、図４の施工日程案提示部６５と、施工日程決定部６６と、施工者段取確認部６７と、受注可否判定部６８とが含まれる。
記憶部１８には、製品及び施工内容ＤＢ１２１が記憶されている。製品及び施工内容ＤＢ１２１には、製品のカタログ、製品の仕様、製品の価格等と、ユーザとの商談により作成された見積り、受発注の内容、リフォーム業者や施工業者のスケジュール、施工内容等が記憶されている。

施工内容決定部１０１は、リフォーム担当者端末２に表示した画面（図５４参照）のタッチ操作により製品が選択されることで当該製品のカタログを表示してユーザに確認した後、施工内容を決定する。
なお、これ以外の方法として、ユーザとリフォーム担当者が異なる場所に存在するような遠隔契約がある。この場合、例えばリフォーム担当者が電話にてユーザの要望を聞きながら、担当者だけのリフォーム担当者端末２の操作により商品選択しつつ工事内容を作成し、見積りを作成する。
その後、ユーザが見積りの内容に納得された場合はそのまま遠隔での契約が可能である。
遠隔契約では、リフォーム業界での通例である現地（お客様宅）契約・見積をしなくてもよく、リフォーム担当者とは異なる場所に居るユーザからリフォーム工事を受注することができる。これは、業務短縮や時勢的に求められているテレワークにも資する。

見積発行部６４は、工事に関する見積りをリフォーム担当者端末２へ発行する。具体的には、見積発行部６４は、商品及び施工内容ＤＢ１２１を参照して、確定した商品にて施工するリフォーム工事に関する見積りを作成し、ＰＤＦ形式の見積書に変換した上で、リフォーム担当者端末２へ発行する。
受注処理部１０２は、受注処理部６９の機能を有しており、見積りの提示を受けたユーザからの工事の依頼に基づいて、工事の請け負う受注処理を行う。
契約制御部１０３は、見積りの提示を受けたユーザからの工事の依頼に基づいて、工事の請け負いの電子的な契約を、当該ユーザとリフォーム担当者との間で行わせる制御を実行する。制御は、電子サインシステム４を介する制御である。
具体的には、契約制御部１０３は、見積発行部６４又は受注処理部１０２からの指示により工事の請け負いに関する電子的な契約処理を、電子サインシステム４を介して行う。
契約制御部１０３は、紙媒体による契約（紙ベースで契約）と、電子的な契約（電子署名による契約）とのうち、何れかで行うのかをユーザに選択させる操作を受付け（例えば図２６の紙ベースで契約するのチェックボックス２２３）、電子的な契約が選択された場合、工事の請負の電子的な契約を、当該ユーザと請負者との間で行わせる制御を実行する。
認証制御部１１１は、ユーザ及びリフォーム業者の夫々の署名を例えば図２３の電子サインシステム４に認証させる制御を実行する。

リフォーム担当者端末２のＣＰＵ６１においては、提示部１３１と、依頼操作受付部１３２と、締結操作受付部１３３と、表示制御部１３４が機能する。
提示部１３１は、見積発行部６４により発行された見積りをユーザに提示する。
依頼操作受付部１３２は、見積りの提示を受けたユーザによる工事の依頼を示す操作を受け付ける。操作は、ユーザ又は請負者により行われる操作であり、例えば図２４のＳ１０２やＳ１０３における、内容確認ボタン、約款確認ボタン、受注ボタン等の押下操作である。
締結操作受付部１３３は、契約制御部１０３の制御に基づいて、少なくともユーザ側の契約の締結に関する操作を受け付ける。操作は、例えば図３２の署名ボタン２５６の押下操作等である。

表示制御部１３４は、依頼操作受付部１３２及び締結操作受付部１３３の夫々により受け付けられる操作がなされる操作子（ソフトウェアボタン等）を、同一画面内に順次表示させる制御を実行する（例えば図２５乃至図２９の画面参照）。
具体的には、表示制御部１３４は、例えば締結操作受付部１３３により受け付けられる操作がなされる操作子（ボタン等）を図２５の画面２１１に表示し、画面内のお客様署名欄２１２が操作されることで、図２６のサイン画面２２０をポップアップ表示する。

以下、図２４乃至図３５を参照して第２実施形態の情報処理システムの動作を説明する。図２４は、電子サインでの注文書の処理動作を示すフローチャートである。図２５は、見積りから受注に至る画面を示す図である。図２６は、サイン画面を示すである。図２７は、契約形式選択のダイアログボックスを示す図である。図２８は、受注情報生成済みを示すダイアログボックスを示す図である。図２９は、署名リクエスト中を示すダイアログボックスを示す図である。図３０は、署名リクエストの画面を示す図である。図３１は、文書署名の画面を示す図である。図３２は、署名選択画面を示す図である。図３３は、電子契約の手続完了の画面を示す図である。図３４は、印刷、Ｅメール、完了のうち何れの選択を促す選択ダイアログボックスを示す図である。図３５は、電子サイン済みの約款付き注文書のＰＤＦファイルの一例を示す図である。

なお、本実施形態の情報システムでは、現地での見積りや契約と遠隔での見積りや契約が可能であるが、システム構成、ユーザ端末を設けない例（図２２、図２３参照）で説明しているため、説明をわかり易くするために、現地での見積りや契約について説明するが、システムにユーザ端末を加えてユーザとリフォーム担当者とが遠隔で手続きを行うようにしてもよい。

図２４のステップＳ１０１において、リフォーム工事の現場にてユーザと商談をしたリフォーム担当者は、リフォーム担当者端末２を操作すると、提示部１３１は、リフォーム担当者端末２に図２５に示す画面２１１を表示する。

この画面２１１にリフォーム担当者が、受注製品や金額、お客様情報等の顧客情報、施工日程等を入力して、契約情報及び顧客情報を含む見積りデータを作成し、画面２１１上でユーザに見積りを提示する。
ここで、リフォーム担当者は、ユーザと見積りの内容（製品や施工内容等）を確認し合った後、約款を説明する。なお、約款説明は、法律上の必須要件ではない場合が多いため、電子署名の際に約款付き注文書に同意さえすれば、約款にも同意したとみなすことができる。

約款を説明した後、ステップＳ１０２において、リフォーム担当者端末２の画面の内容確認ボタンをユーザに押下してもらい、内容確認の欄にチェックを入れた後、図示しない約款確認ボタンをユーザに押下してもらう。内容確認ボタンを押下とは、「商品を確認しました」のメッセージ横のチェックボックスにチェックを入れてもらうことを言う。

最後に、ユーザに電子サインをしてもらう。
この場合、画面２１１のお客様署名欄２１２を押下することで、図２６に示すサイン画面２２０が画面２１１の上面にポップアップ表示される。

このサイン画面２２０には、サイン欄２２１、この手順をスキップするチェックボックス２２２、紙ベースで契約するチェックボックス２２３、キャンセルボタン２２４、ＯＫボタン２２５等が設けられている。
キャンセルボタン２２４は、サイン画面２２０を消すボタンである。ＯＫボタン２２５は、ここで選択した内容を確定するためのボタンである。
このサイン画面２２０では、ユーザがサイン欄２２１に自筆でサインできる他、この手順をスキップするか、紙ベースで契約するか等を選ぶことができる。

例えばチェックボックス２２２をチェックすることで、サインをスキップすることができる。例えばユーザがリフォーム担当者とは異なる場所（遠隔地等）に居るときは、本人確認ができないため、サインをせずに次の操作に進むことができる。

また、チェックボックス２２３をチェックすることで、電子サインをスキップし、印刷した書面（紙）による契約をすることができる。書面（紙）による契約では、書面（紙）の署名欄に押印することでもよくサインしてもよい。

サイン画面２２０において、ユーザがサイン欄２２１に自筆でサインして、ＯＫボタン２２５を押下することで、サイン画面２２０が消され、図２５の画面２１１に戻る。このような自筆のサインによりユーザは、リフォーム工事を依頼したことを実感することができる。

（電子契約手続き）
ユーザにより電子的な契約が選択された場合、契約制御部１０３は、工事の請け負いの電子的な契約を、当該ユーザとリフォーム業者との間で行わせる制御を実行する。
具体的には、ユーザによりサインされた後、リフォーム工事の契約をユーザと正式に交わすため、ステップＳ１０３において、リフォーム担当者により、画面２１１の受注ボタン２１３が押下されると、受注処理のための情報がリフォーム業者サーバ１の製品及び施工内容ＤＢ１２１に保存されると共に、図２７に示すように、画面２１１の上面にダイアログボックス２１４がポップアップ表示される。なお、画面２１１のお客様署名欄にはサインが挿入されている。

ダイアログボックス２１４は、契約形式の選択を促す画面であり、注文書・注文請書及び工事請負書契約書のうち何れかを選択するチェックボックスが設けられている。例えば注文書であれば、注文書・注文請書のチェックボックスをチェックする。
注文請書と注文書、又は工事請負契約書等に分類する意義として、リフォーム業界の通例上、簡易な工事については、注文書でやり取りし、大規模工事については工事請負契約書でやり取りする傾向がある。これら２つの契約形態を用意することで、業界上、使い分けの需要を満たす効果がある。
ユーザは、ダイアログボックス２１４の注文書・注文請書のチェックボックスにチェックを入れて、画面２１１の受注ボタン２１３を押下することで、受注処理部１０２により見積りデータを基に受注情報が生成される。受注情報は、注文書の元の情報である。なお、注文情報を生成する際には、事前にメールアドレスの登録が必要である。
このように画面上のボタン操作を順に行ってゆくことで受注処理が完了する。なお、依頼操作受付部１３２により受け付けられる操作についても、図６乃至図９への画面遷移に示す通りである。

受注情報が正常に生成されると、図２８に示すように、受注情報生成済みを示すダイアログボックス２１５が表示される。ダイアログボックス２１５には、チェックマークが設けられている。

続いて、ステップＳ１０４において、受注処理部１０２は、注文情報に基づいて約款付き注文書（ＰＤＦファイル）を作成し、メールアドレスと共に電子サインシステム４へ電子サインを依頼するよう契約制御部１０３に指示する。
契約制御部１０３は、約款付き注文書（ＰＤＦファイル）とメールアドレスを含む電子サイン依頼を電子サインシステム４へ送信する。
電子サイン依頼を電子サインシステム４へ送信すると、契約制御部１０３は、図２９に示すように、画面２１１の上面に、署名リクエスト中（電子サイン処理待ち）を示すダイアログボックス２１６をポップアップ表示する。
なお、遠隔契約の際には、電子契約を待っている間、他の受注に関する処理ができなくなるため、上記ダイアログボックス２１６を表示させることなく、図１２の画面や図２５の画面２１１に遷移するようにしてもよく、これら以外の画面に遷移してもよい。

図１９に示した画面では、商品名や品番の他に、製品コードが表示される。
製品コードは、いわゆる品番のことであり、施工業者側はこの品番と商品名を参照して依頼された商品を判別する。製品名に品番が入力されることもあるが、製品コードは、商品の特定に欠かせない要素の一つである。
また、図１９の画面には、コンテント画像のアイコンとポップアップ画像のアイコンが示されている。コンテント画像のアイコンを押下することで、イメージ画像が表示される。また、ポップアップ画像のアイコンを押下することで、図８の画面にある虫眼鏡のマークをタップした際に出てくる商品についての詳細説明画像が表示される。
この他、例えば数量の項目には、デフォルトの数量が設定される。単位の項目には製品に適した単位が設定される。「式」以外に例えば長さの単位「ｍ」等の場合は、その商品を選択した際にポップアップ画面が表示されて数値の入力が可能になる。製品タイプでは、工賃と商品との区分けをしている。有効のチェックボックスは、当製品を表示するか否かを指定するためのボタンである。Ｄｅｆａｕｌｔ Ｐｒｏｄｕｃｔのチェックボックスは、チェックを入れることで、吹き出しの中の商品群の中でデフォルトで選択される商品になる。

ステップＳ１０５において、リフォーム業者サーバ１から依頼を受けた電子サインシステム４は、ユーザ（顧客）に対する署名リクエストをユーザにより指定されるアドレスへ送信する。
ユーザの指定アドレスが例えばユーザの端末であれば、ユーザの端末に署名リクエストが届けられ、ユーザの指定アドレスがリフォーム担当者端末２であればリフォーム担当者端末２に署名リクエストが届けられる。
この実施形態では、ユーザの指定アドレスがリフォーム担当者端末２として説明する。

署名リクエストがリフォーム担当者端末２に届けられると、届いた署名リクエストの画面２３１（図３０参照）がリフォーム担当者端末２に表示される。
画面２３１には、電子署名ＵＲＬ２３２のリンクが記載されている。
ユーザは、リフォーム担当者端末２に表示された画面２３１の中の電子署名ＵＲＬ２３２の部分をクリック操作することで、当該ＵＲＬにリンクされた図３１の文書署名の画面２４１が表示される。
文書署名の画面２４１には、受注されたリフォーム工事に関する契約内容が記載されており、文末には署名欄２４２が設けられている。また、画面２４１の下部には、署名ボタン２４３が設けられている。
ユーザは、文書署名の画面２４１を閲覧することで、契約内容や署名欄２４２の位置を確認した後、署名ボタン２４３を押下すると、図３２に示すように、画面２４１の上面に、署名選択画面２５１がポップアップ表示される。

署名選択画面２５１には、ボタン２５２乃至ボタン２５６が設けられている。ボタン２５２は、印影を電子署名とするボタンである。ボタン２５３は、署名画像をアップロードするボタンであり、予め用意されたサイン等の署名画像を電子署名とするためのものである。ボタン２５４は、今回のみの署名画像を作成するためのボタンであり、図２６と同様のサイン画面が表示され、手書きでサインすることになる。ボタン２５５は、署名をキャンセルするためのキャンセルボタンである。ボタン２５６は、選択した署名を確定するボタンである。
ユーザは、これらのボタンの中から所望のボタンを選択して次の手続きを行うことができる。
なお、署名選択画面２５１では、手書きのサインの他に、例えばゴシック体等のＰＣ文字での署名、又は簡易な自分の名前のハンコ等を署名選択画面２５１で作成してそのハンコを署名画像にすることができる。

なお、本実施形態の電子署名は、電子署名ＵＲＬ２３２をユーザに送り、ユーザからの電子署名ＵＲＬ２３２へのアクセスにより電子署名を行う仕組みを導入している。一般的な電子契約システムは、契約書ＰＤＦを作成し、それを顧客情報と共に電子契約システムへアップする必要があるが、本実施形態でその必要がない。

ユーザは、例えばボタン２５２を選択して署名確定のボタン２５６を押下すると、電子サインシステム４は、契約内容が承認されたものと判定して、選択された電子サインを約款付き注文書に行い、電子サインシステム４の保管用記憶装置に保管すると共に、図３３に示すように、電子契約の手続完了の画面２６１を当該リフォーム担当者端末２に表示する。なお、リフォーム担当者には、別途電子サインシステム４側から電子サインが終了した旨の通知メールが届けられる。
また、電子契約の手続完了をもってユーザにより注文内容が承認されると、電子サインシステム４は、電子サイン済みの約款付き注文書の保管場所を示すＵＲＬをリフォーム業者サーバ１へ送信する。

ステップＳ１０６において、ユーザの電子サイン後、リフォーム業者サーバ１では、受注処理部１０２が、電子サインシステム４から受信されたＵＲＬにアクセスし、電子サインされた注文書からＰＤＦ形式の注文請書を生成する。この際、リフォーム業者の電子サインが注文請書に自動入力されるように処理される。

製品＆工事内容ＤＢ１２１に登録されている商品は、施工価格・製品価格について、予め会社側から合意を得ているため、通常必要な会社側からの電子サインが自動で施されるのも第２実施形態の情報処理システムの特徴の一つである。これにより、リフォーム担当者から会社側への電子サインの依頼を省略することができる。電子サインの省略は、リフォーム工事ではありがちな解約や契約差替等の際にも同様に行える。

注文請書を生成した後、受注処理部１０２は、契約制御部１０３に自社（リフォーム業者）の電子サインを注文請書に付与する依頼を指示する。この指示を受けた契約制御部１０３は、電子サインシステム４にＰＤＦ形式の注文請書を送信し電子サインを依頼する。

ステップＳ１０７において、リフォーム業者サーバ１から依頼を受けた電子サインシステム４は、注文請書にリフォーム業者の電子サイン処理を行った上でシステム内に保管し、電子サイン済みの注文請書の保管場所を示すＵＲＬを依頼元へ送信する。なお、電子サインシステム４は、ユーザ及びリフォーム業者双方の電子署名がなされた時点でユーザへ契約完了の電子メールを送信する。

リフォーム業者サーバ１では、受注処理部１０２が、電子サインシステム４から受信されたＵＲＬにアクセスし、電子サインされた注文請書を受け取る。
このようにして、ステップＳ１０８において、リフォーム業者サーバ１は、電子サイン済み注文請書のＰＤＦファイルと電子サイン済みの約款付き注文書のＰＤＦファイルを電子サインシステム４から受け取る。

ステップＳ１０９において、上記２つのファイルを受け取ったリフォーム業者サーバ１は、図３４に示す選択ダイアログボックス２１７を、画面２１１の上面に重ねて表示する。
選択ダイアログボックス２１７には、印刷、Ｅメール、完了等のうち何れかの選択を促すボタンが設けられており、何れかのボタンの押下に従う処理が受注処理部１０２により行われる。

Ｅメールのボタンが押下されると、受注処理部１０２は、受け取った電子サイン済み注文請書のＰＤＦファイルと電子サイン済みの約款付き注文書のＰＤＦファイルを登録された宛先（リフォーム担当者端末２）へ電子メールで送信しその画面に表示する。
印刷のボタンが押下されると、受注処理部１０２は、デフォルトで設定されているプリンタにより紙の書類として印刷することができる。
完了のボタンが押下されると、受注処理部１０２は、受注処理処理を終了する。

図３５に、電子サイン済みの約款付き注文書のＰＤＦファイルの一例を示す。図３５に示すように、電子サイン済みの約款付き注文書のＰＤＦファイルは、注文書２７１と約款２７２乃至２７４が１つのＰＤＦファイルとしてまとめられており、１回の電子署名手続きで複数の書類が同時に電子署名されるため、ユーザは何度も同じ操作をせずに済む。
注文書２７１の電子サイン欄には、図３１の文書署名の画面２４１にて確認した署名欄２４２の位置にユーザにより手書きされたサインが挿入される。
なお、電子サイン済み注文請書のＰＤＦファイルについては、リフォーム業者の電子署名のみがなされる。

次に、図３６を参照して紙ベースでの注文書の処理動作を説明する。図３６は、紙ベースでの注文書の処理動作を示すフローチャートである。なお、以下の各書類の処理動作を説明するにあたり図２４に示した電子サインでの注文書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。
ステップＳ１０１乃至Ｓ１０５までの動作は、図２４に示した電子サインでの注文書の処理動作と同じである。
ステップＳ１０６において、表示されたサイン画面２２０（図２６参照）で、紙ベースで契約するチェックボックス２２３にチェックが入れられると、リフォーム業者サーバ１の受注処理部１０２は、注文書を紙ベースで処理するよう動作する。
この場合、ステップＳ２０１において、リフォーム担当者は、約款付き注文書をユーザに渡し、ユーザに対して約款付き注文書の署名欄にサイン（署名）を記載してもらい、その約款付き注文書を受け取る。
約款付き注文書を受け取ったリフォーム担当者は、自社に戻り、スキャナ等を利用して注文書をＰＤＦ形式のファイルにした上で、リフォーム業者サーバ１にアップロードし製品＆施工内容ＤＢ１２１に記憶する。
具体的には、図１７に示した受注履歴画面の詳細の項目を押下して表示される受注詳細画面に設けられている図示しないインポートボタンから工事請負契約書のインポートを行うことで、ＰＤＦ形式の工事請負契約書が製品＆施工内容ＤＢ１２１に記憶される。なお、紙ベースでの契約が選択された場合にのみこの処理が発生する。

このように紙ベースでの注文書の処理動作によれば、紙ベースの契約要望である場合でも約款付き注文書等の契約書ＰＤＦをシステム上にアップすることで、その後の発注書作成等のプロセスをシステム上で行えるようになり、契約プロセスを紙ベースでも電子契約書類と同様に一貫して管理することができる。また、これにより電子や紙全ての契約書を当システムに集約する誘導が可能になる。

次に、図３７を参照して電子サインでの工事請負契約書の処理動作を説明する。図３７は、電子サインでの工事請負契約書の処理動作を示すフローチャートである。なお、電子サインでの工事請負契約書の処理動作を説明するにあたり図２４に示した電子サインでの注文書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。

図２７に示したダイアログボックス２１４において、工事請負契約書のチェックボックスがチェックされた場合、リフォーム業者サーバ１の受注処理部１０２は、工事請負契約書を処理するよう動作する。
この場合、工事請負契約書のチェックボックスがチェックされた場合、ステップＳ１０４において、受注処理部１０２は、注文情報に基づいて約款付き工事請負契約書（ＰＤＦファイル）を作成する。

その後、図２４と同様にステップＳ１０５、Ｓ１０６のユーザ側の電子サインの処理を行った後、ステップＳ１０７、Ｓ１０８のリフォーム業者側の電子署名は行わずに、ステップＳ１０６からステップＳ１０９に進む。

ステップＳ１０９において、電子サイン付きの約款付き工事請負契約書（ＰＤＦファイル）をリフォーム担当者端末２に表示する。
そして、電子サイン付きの約款付き工事請負契約書（ＰＤＦファイル）をリフォーム業者サーバ１の製品＆施工内容ＤＢ１２１に登録（記憶）する。
その後、必要に応じて（ユーザからの要求などがあれば）、電子サイン付きの約款付き工事請負契約書（ＰＤＦファイル）をユーザの指定アドレス（端末等）へ送信する。
このように電子サインでの工事請負契約書の処理動作によれば、工事請負契約書についても双方の電子署名を施した正式な契約書類として管理することができる。

次に、図３８を参照して紙ベースでの工事請負契約書の処理動作を説明する。図３８は、紙ベースでの工事請負契約書の処理動作を示すフローチャートである。なお、以下の工事請負契約書の処理動作を説明するにあたり図３６に示した紙ベースでの工事請負契約書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。
ステップＳ１０１乃至Ｓ１０３までの動作は、図３８に示した紙ベースでの注文書の処理動作と同じである。
ステップＳ１０４において、表示されたサイン画面２２０（図２６参照）で、紙ベースで契約するチェックボックス２２３にチェックが入れられると、リフォーム業者サーバ１の受注処理部１０２は、工事請負契約書を紙ベースで処理するよう動作する。具体的には、受注処理部１０２は、書面の工事請負契約書がリフォーム業者サーバ１にアップロードされるまで待機する。
この場合、ステップＳ２０１において、リフォーム担当者は、書面の約款付き工事請負契約書をユーザに渡し、ユーザに対して約款付き工事請負契約書の署名欄にサイン（署名）を記載してもらい、その約款付き工事請負契約書を受け取る。
約款付き工事請負契約書を受け取ったリフォーム担当者は、自社に戻り、スキャナ等を利用して工事請負契約書をＰＤＦ形式のファイルにした上で、リフォーム業者サーバ１にアップロードし製品＆施工内容ＤＢ１２１に記憶（登録）する。
このように紙ベースでの工事請負契約書の処理動作によれば、紙ベースの工事請負契約書についてもユーザとリフォーム担当者との間で書面のやり取りをした後、ＰＤＦ形式のファイルにした上で、リフォーム業者サーバ１にアップロードするので、電子サイン付きのものと同様にサイン（署名）を施した正式な契約書類として管理することができる。

次に、図３９を参照して電子サインでの解約合意書の処理動作を説明する。図３９は、電子サインでの解約合意書の処理動作を示すフローチャートである。なお、電子サインでの解約合意書の処理動作を説明するにあたり図３７に示した電子サインでの工事請負契約書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。

電子サインでの解約合意書を処理する場合、図２５の画面２１１に受注契約の内容を表示した状態で、ユーザの解約の内容を確認した後、ユーザに承認をもらうため、図２６のサイン画面２２０を表示させる。
そして、表示したサイン画面２２０にユーザに手書き等でサインをしてもらい、図示しない解約ボタンを押下してもらう。なお、遠隔契約では、手書きサインは行わない。
図３９のステップＳ３０１において、解約ボタンが押下されることにより、ステップＳ１０３において、解約処理のための情報がリフォーム業者サーバ１に送信される。その後のステップＳ１０４以降の動作は、処理対象の書類が解約合意書に変わる以外は、電子サインでの工事請負契約書の処理動作と同じである。
このように電子サインでの解約合意書の処理動作によれば、解約合意書についても工事請負契約書と同様に電子サイン及び電子署名を施した正式な書類として管理することができる。

次に、図４０を参照して紙ベースでの解約合意書の処理動作を説明する。図４０は、紙ベースでの解約合意書の処理動作を示すフローチャートである。なお、紙ベースでの解約合意書の処理動作を説明するにあたり図３８に示した紙ベースでの工事請負契約書の処理動作及び図３９に示した電子サインでの解約合意書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。

紙ベースでの解約合意書を処理する場合、図３９に示した電子サインでの解約合意書の処理動作と同様に、図４０のステップＳ３０１において、解約ボタンが押下される。
これにより、リフォーム業者サーバ１では、受注処理部１０２は、解約合意書を作成し、ＰＤＦ形式の解約合意書をユーザの登録アドレスに送信する。
ユーザは、受け取ったＰＤＦ形式の解約合意書を書面に印刷し、書面の解約合意書の署名欄にサイン（署名）を記載して、その解約合意書をリフォーム担当者に渡す。
その後のステップＳ２０１、Ｓ２０２等の処理は、処理対象の書類が解約合意書に変わる以外は、図３８の紙ベースでの工事請負契約書の処理動作と同じである。
このように紙ベースでの解約合意書の処理動作によれば、紙ベースの解約合意書についてもユーザとリフォーム担当者との間で書面のやり取りをした後、ＰＤＦ形式のファイルにした上で、リフォーム業者サーバ１にアップロードするので、電子サイン付きのものと同様にサイン（署名）を施した正式な書類として管理することができる。

次に、図４１を参照して電子サインでの工事完了確認書の処理動作を説明する。図４１は、電子サインでの工事完了確認書の処理動作を示すフローチャートである。なお、電子サインでの工事完了確認書の処理動作を説明するにあたり図３９に示した電子サインでの解約合意書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。

電子サインでの工事完了確認書を処理する場合、図２５の画面２１１に受注契約の内容を表示した状態で、ユーザの工事の内容を確認した後、ユーザに承認をもらうため、図２６のサイン画面２２０を表示させる。
そして、表示したサイン画面２２０にユーザに手書き等でサインをしてもらい、図示しない工事完了確認ボタンを押下してもらう。
図４１のステップＳ４０１において、工事完了確認ボタンが押下されることにより、ステップＳ１０３において、工事完了処理のための情報がリフォーム業者サーバ１に送信される。その後のステップＳ１０４以降の動作は、処理対象の書類が工事完了確認書に変わる以外は、図３９の電子サインでの解約合意書の処理動作と同じである。
このように電子サインでの工事完了確認書の処理動作によれば、工事完了確認書についても解約合意書と同様に電子サイン及び電子署名を施した正式な書類として管理することができる。

次に、図４２を参照して紙ベースでの工事完了確認書の処理動作を説明する。図４２は、紙ベースでの工事完了確認書の処理動作を示すフローチャートである。なお、紙ベースでの工事完了確認書の処理動作を説明するにあたり図４０に示した紙ベースでの解約合意書の処理動作及び図４１に示した電子サインでの工事完了確認書の処理動作と同じ処理には同一のステップ番号を付しその説明は省略する。

紙ベースでの工事完了確認書の処理動作は、図４１に示した電子サインでの工事完了確認書の処理動作と同様に、図４２のステップＳ４０１において、工事完了確認ボタンが押下されることで、ステップＳ１０４において、工事完了確認書が作成されて、ユーザの登録アドレスへ送信される。
その後のステップＳ２０１、Ｓ２０２等の処理は、処理対象の書類が工事完了確認書に変わるだけで、図４０の紙ベースでの解約合意書の処理動作と同じである。

なお、工事完了確認書については、必須フローに入らないため、ステータスにも影響を及ぼさない。そのため、電子サインでない場合は、電子サイン付き工事完了報告書が入る予定のリフォーム業者サーバ１の記憶領域にリフォーム担当者が工事完了確認書のＰＤＦファイルを入れておけばよい。

このように紙ベースでの工事完了確認書の処理動作によれば、紙ベースの工事完了確認書についてもユーザとリフォーム担当者との間で書面のやり取りをした後、ＰＤＦ形式のファイルにした上で、リフォーム業者サーバ１に記憶することで、電子サイン付きのものと同様にサイン（署名）を施した書類として管理することができる。

次に、図４３乃至４６を参照して第２実施形態の情報処理システムの分析機能について説明する。図４３は、受注分析画面を示す図である。図４４は、売上分析画面を示す図である。図４５は、販売分析画面を示す図である。図４６は、販売分析詳細画面を示す図である。

図４３に示す受注分析画面３０１には、入力欄３０２乃至３０６と分析結果の表示欄３０７が設けられている。受注分析画面３０１は、受注分析を行うための画面である。

入力欄３０２は、チェックボックス式であり、支店を選択できる。会社の範囲内で支店を選択しない場合は会社の範囲内の全支店が選択される。リフォーム業者サーバ１にログインした利用者の権限によって見れる範囲が変わる。
つまり、アカウントの権限によって検索できる範囲が異なる。例えば社長のアカウントであれば、全てのエリアやショップを検索できるが、チームリーダーのアカウントであれば自分のショップ内のみが検索できる。
入力欄３０３は、チェックボックス式であり、前の入力欄３０２の範囲（支店のエリア内）で選んだ範囲のショップの選択肢が出る。例：ショップには南大阪チーム・兵庫チーム・東京チーム等の選択肢が選択できる。選択しない場合は支店のエリア内の全ショップが選択される。
入力欄３０４は、期内のチェックボックスと月内のチェックボックスで構成されている。期内のチェックボックスをチェックすると、前回の会計年度更新日〜本日までのデータが分析の対象となる。月内のチェックボックスをチェックすると、当月１日〜本日までのデータが分析の対象となる。
入力欄３０５は、チェックボックス式であり、担当者を選択できる。入力欄３０５では、前の入力欄３０３のショップの範囲内で選んだ範囲の担当者名の選択肢が表示される。選択肢を選択しない場合は全担当者名が選択される。
入力欄３０６は、プルダウンメニューであり、分析結果を、例えば見積数が多い順、見積金額が高い順、受注額が高い順、受注粗利が高い順、受注達成率が高い順、粗利達成率が高い順等に並べ替えることができる。

表示欄３０７には、例えば見積欄、受注欄、粗利欄、利益率欄等の欄に区分して、受注に関する分析結果が表示される。
表示欄３０７の各チームのデータは、下位下層がある場合はチーム名３０８をクリックすることで下位下層が表示される。クリックした先にさらに下位下層がある場合はさらにクリックすることで表示される。並び替えがある場合は下層もその並び替えのルールに従い並び替えられる。

見積欄には、例えば、見積数、見積金額、粗利が各チーム毎に表示される。
見積数は、選択した期間内・エリア内・ショップ内・担当者内のトータルの見積作成数である。見積金額は、選択した期間内・エリア内・ショップ内・担当者内のトータルの見積金額である。見積金額は、全て税抜で表示される。
粗利（粗利益）は、選択した期間内・エリア内・ショップ内・担当者内のトータルの見積粗利である。

受注欄には、受注数、受注金額、受注目標、達成率等が表示される。
受注数は、選択した期間内・エリア内・ショップ内・担当者内のトータルの受注数である。
受注金額は、選択した期間内・エリア内・ショップ内・担当者内のトータルの受注金額である。
受注目標は、目標マスタのデータを参照する。
達成率は、選択した期間内・エリア内・ショップ内・担当者内のトータル受注金額／選択した期間内・エリア内・ショップ内・担当者内のトータル受注目標（パーセンテージ表示）である。達成率は下桁なしで表示される。

粗利欄には、粗利益の分析結果として、受注粗利、粗利目標、達成率が表示される。
受注粗利は、選択した期間内・エリア内・ショップ内・担当者内のトータルの受注粗利（予定ではなく、実行粗利額）である。
粗利目標は、目標マスタで設定されるデータであり、目標マスタを参照して得られる。
達成率は、選択した期間内・エリア内・ショップ内・担当者内のトータル粗利金額／選択した期間内・エリア内・ショップ内・担当者内のトータル受注目標（パーセンテージ表示）である。
受注粗利は、目標マスタを作成する元のデータとなる。ベースの設定を行うことで、毎月各担当の目標額の編集できる。特定の権限者のみ編集可能である。（図４７の目標マスタ画面３４１参照）

利益率欄には、見積利益率、受注利益率が表示される。利益率は下２桁まで表示される。
見積利益率は、選択した期間内・エリア内・ショップ内・担当者内のトータルの見積粗利／選択した期間内・エリア内・ショップ内・担当者内のトータル見積金額（予定ではなく、実行粗利額）である。
受注利益率は、選択した期間内・エリア内・ショップ内・担当者内のトータルの受注粗利／選択した期間内・エリア内・ショップ内・担当者内のトータル受注金額（予定ではなく、実行粗利額）である。

このように受注分析画面３０１では、期間内・エリア内・ショップ内・担当者等に絞って、見積、受注、粗利、利益率等、様々な方向から受注分析の結果を得ることができる。

図４４に示す売上分析画面３１１には、入力欄３１２乃至３１６と分析結果の表示欄３１７が設けられている。売上分析画面３１１は、売上分析を行うための画面である。

入力欄３１２乃至３１６は、図４３に示した受注分析画面３０１の入力欄３０２乃至３０６と同じ機能でありその説明は省略する。
表示欄３１７には、例えば売上欄、粗利欄、利益率欄等の欄に区分して、売り上げに関する分析結果が表示される。
表示欄３１７の各チームのデータは、下位下層がある場合はチーム名３１８をクリックすることで下位下層が表示される。

売上欄には、例えば、売上数、売上額、売上目標、達成率、売上予定額、達成予定等が各チーム毎に表示される。
売上数は、選択した期間内・エリア内・ショップ内・担当者内の入金完了フラグが立った受注分のトータル受注数である。
売上額は、選択した期間内・エリア内・ショップ内・担当者内の入金完了フラグが立った受注分のトータル受注額である。
売上目標は、目標マスタのデータを参照する。
達成率は、選択した期間内・エリア内・ショップ内・担当者内のトータル受注金額／選択した期間内・エリア内・ショップ内・担当者内のトータル受注目標（パーセンテージ表示）である。
売上予定額は、選択した期間内・エリア内・ショップ内・担当者内の入金完了フラグが立っていない受注分、かつ、選択期間の最終日≧入金予定日のうちの最終日になっている受注分のトータルの受注額である。
達成予定率は（売上額+売上予定額）／売上目標である。

粗利欄は、例えば、売上粗利、粗利目標、達成率、粗利予定額、達成予定率等が各チーム毎に表示される。
売上粗利は、選択した期間内・エリア内・ショップ内・担当者内の入金完了フラグが立った受注分のトータル粗利額（予定ではなく、実行粗利額）である。
粗利目標は、目標マスタのデータを参照する。
達成率は、選択した期間内・エリア内・ショップ内・担当者内のトータル受注粗利／選択した期間内・エリア内・ショップ内・担当者内のトータル粗利目標（パーセンテージ表示）である。１００％以上（例えば３００％等）もありえる。
粗利予定額は、選択した期間内・エリア内・ショップ内・担当者内の入金完了フラグが立っていない受注分、かつ、選択期間の最終日≧入金予定日のうちの最終日になっている受注分のトータルの粗利額である。
達成予定率は、（売上粗利+売上予定粗利）／粗利目標である。

利益率欄は、例えば、利益率と予定利益率が各チーム毎に表示される。
利益率は、選択した期間内・エリア内・ショップ内・担当者内のトータルの売上粗利／選択した期間内・エリア内・ショップ内・担当者内のトータル売上金額（予定ではなく、実行粗利額）である・
予定利益率は、（売上粗利+売上予定粗利）／（売上額+売上予定額）である。

このように売上分析画面３１１では、期間内・エリア内・ショップ内・担当者等に絞って、売上、粗利、利益率等、様々な方向から売上分析の結果を得ることができる。

図４５に示す販売分析画面３２１には、入力欄３２２乃至３２６と分析結果の表示欄３２７が設けられている。販売分析画面３２１は、販売分析を行うための画面である。

入力欄３２２乃至３２６は、図４３に示した受注分析画面３０１の入力欄３０２乃至３０６と同じ機能でありその説明は省略する。
表示欄３２７には、例えば見積欄、成約欄、成約率欄、商品シェア欄等の欄に区分して、分析結果が表示される。

見積欄には、見積数、見積額、利益率が商品毎や合計毎に表示される。
見積数は、選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの見積作成数である。なお、カウントは、使用した第一階層の分を使用。第二階層以降はカウントしない。例えば、トイレのアメージュＺ、ＯＰに手洗いなし・便座・紙巻とガス給湯器２４号、ＯＰに循環カバーを付けた場合は、カウントはトイレ１、給湯器１等になる。
見積額は、選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの見積額である。
利益率は、選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの見積粗利／選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの見積額（パーセンテージ表示）である。

成約欄には、受注数、受注額、利益率等が表示される。
受注数は、選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの受注数である。
受注額は、選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの受注額である。
利益率は、選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの受注粗利／選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの受注額（パーセンテージ表示）である。

成約率欄には、成約率（数）、成約率（金額）が表示される。
成約率（数）は、受注数／見積数（パーセンテージ表示）である。
成約率（金額）は、受注金額／見積金額（パーセンテージ表示）である。

商品シェア欄には、受注数、受注額が表示される。
受注数は、選択した期間内・エリア内・ショップ内・担当者内の全商品の受注した合計数量／選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの受注数（パーセンテージ表示）である。
受注額は、選択した期間内・エリア内・ショップ内・担当者内の全商品の受注した合計金額／選択した期間内・エリア内・ショップ内・担当者内の該当階層のトータルの受注金額（パーセンテージ表示）である。

このように販売分析画面３２１では、期間内・エリア内・ショップ内・担当者等に絞って、商品毎及び合計毎に、見積、成約、成約率、商品シェア等、様々な方向から販売分析の結果を得ることができる。

図４６に示す販売分析詳細画面３３１には、エリア入力欄３３２、購入商品欄３３３、表示欄３３４が設けられてる。販売分析詳細画面３３１は、販売される商品を詳細に分析するための画面である。
エリア入力欄３３２には、エリアが入力される。エリア入力欄３３２は、図４５の販売分析画面３２１から商品を選択して販売分析詳細画面３３１にジャンプしてきた場合は、販売分析画面３２１で選択されていたエリアが自動で選択されて入力される。
購入商品欄３３３では、チェックボックスにて商品の絞り込みが行える。商品の名称の横にチェックボックスがある場合はチェックボックスをチェックすることで、商品を絞り込むことが可能である。チェックボックスがない商品名のものは、第二階層が表示される。
表示欄３３４には、商品毎の見積欄、受注欄が設けられている。
見積欄には、総数、採用数、シェア等が表示される。
総数は、項目に表示されている対象商品の見積総数を表示する。例えば、カーポートの見積りを出した総数などである。
採用数は、項目に表示されている対象商品の採用された見積総数を表示する。例えば、カーポートのうちネスカが見積りされた数である。
シェアは、採用数／総数であり、パーセンテージ表示であり下桁はない。例えば、カーポートのうちネスカが採用された割合である。

受注欄には、総数、採用数、シェア、利益率等が表示される。
総数は、項目に表示されている対象商品の受注総数を表示する。
採用数は、項目に表示されている対象商品の採用された受注総数を表示する。
シェアは、採用数／総数であり、パーセンテージ表示であり下桁はない。
利益率は、左記対象商品受注粗利合計／左記対象商品受注額合計である。

このように販売分析詳細画面３３１では、期間内、エリア内、ショップ内、等に絞って、商品毎に見積り、受注等の面から分析した商品の詳細な販売分析結果を得ることができる。

図４７に示す目標マスタ画面３４１には、図４３に示した受注分析画面３０１と同じ絞り込み窓３４２（エリア、ショップ、担当者、期間、月内）の他に、入力月の範囲指定欄、受注額目標ベース、受注粗利目標ベース、売上額目標ベース、売上粗利目標ベース等の数値を設定する欄が設けられている。
目標マスタは、製品＆工事内容ＤＢ１２１内に設けられており、目標マスタ画面３４１にてデータの検索や更新が可能である。
目標マスタは、担当者毎に受注目標、受注粗利目標、売上目標、売上粗利目標を定めるためのものである。運用方法としては、期間売上・受注計画に基づいて期初に各人の目標数値を設定しておき、もし期の途中で目標に変更があった場合は、該当するデータを変更する、といった運用になる。
目標マスタ画面３４１には、年度タブ３４３が設けられており、タブを切り替えることで、年度変更が可能であり、過去の目標設定が必要、また過去の集計がしたい等の要望をかなえることができる。
目標マスタ画面３４１では、エリア、ショップ、担当者毎に設定された月毎の受注額目標、受注粗利目標、売上額目標、売上粗利目標を表示することができる。受注額目標、受注粗利目標、売上額目標、売上粗利目標の数値３４４は、９９，９９９，９９９まで横位置に表示が可能であり、個々の値の編集も可能である。月の欄３４５については、横に並べて配置される。
反映ボタン３４６は、押下することで、絞り込み窓３４２で検索した範囲で入力した目標ベースを全て目標マスタに反映する、つまり入力した目標ベースで目標マスタを更新することができる。
このように目標マスタ画面３４１では、目標マスタのデータを様々な方向から検索し表示することができる。

次に、図４８乃至５２を参照して第２実施形態の情報処理システムのデータ管理機能について説明する。図４８は、発注管理画面を示す図である。図４９は、工程管理画面を示す図である。図５０は、支払管理画面を示す図である。図５１は、入金管理画面を示す図である。図５２は、予約管理画面を示す図である。

図４８に示す発注管理画面３５１は、リフォーム業者サーバ１の製品＆施工内容ＤＢ１２１に記憶されているデータのうち発注データを管理するための画面である。
発注管理画面３５１には、図４３に示した受注分析画面３０１と同じ絞り込み窓３５２（エリア、ショップ、担当者、期間、月内）の他に、発注状況のチェックボックス３５３や請書確認のチェックボックス、発注先や顧客名の入力欄、表示欄３５４に表示件数を設定するためのプルダウンメニュー等が設けられている。

発注状況のチェックボックス３５３は、図示しない顧客詳細情報画面にて発注書作成済みがＯＫならば「済」、未だの場合、「未」、発注が無いものは除外する。チェックボックス３５３にチェックを入れない場合は両方検索される。請書確認のチェックボックスも同じである。

表示欄３５４には、担当者、見積Ｎｏ、顧客名、工事名、発注先、工事原価（税込）、発注状況、請書確認、発注日、着工予定日、完工予定日等の項目が設けられている。工事原価（税込）「０」は、この表に含まれない。完工予定日は、契約時に決定する予定日である。
上記絞り込み窓３５２により絞り込み、製品＆施工内容ＤＢ１２１が検索された結果のデータが夫々の項目に表示される。
このように発注管理画面３５１では、製品＆施工内容ＤＢ１２１のデータを発注の面から検索し表示することができる。例えば発注予定や発注済分を一覧で検索できることで発注忘れの防止、過去の発注検索が容易になる。

図４９に示す工事管理画面３６１は、リフォーム業者サーバ１の製品＆施工内容ＤＢ１２１に記憶されている工事データを管理するための画面である。
工事管理画面３６１には、図４３に示した受注分析画面３０１と同様の絞り込み窓３６２（エリア、ショップ、担当者）の他に、着工予定日、完工予定日、着工日、完工日等の期間を入力する入力欄３６３と、顧客名を入力する入力欄３６４と、表示欄３６５とが設けられている。
表示欄３６５には、受注Ｎｏ、顧客名、着工予定日、完工予定日、着工日、完工日、工程表ＰＤＦ等の項目毎に、絞り込み窓３６２で絞り込んで検索されたデータが表示される。
このように工事管理画面３６１では、製品＆施工内容ＤＢ１２１のデータを工事の面から検索し表示することができる。例えば担当任せになりがちな工期進捗の管理が一覧で可能になる。また、工事忘れを防ぐといった効果も期待できる。

図５０に示す支払管理画面３７１は、リフォーム業者サーバ１の製品＆施工内容ＤＢ１２１に記憶されているデータのうち支払データを管理するための画面である。
支払管理画面３７１には、図４３に示した受注分析画面３０１と同様の絞り込み窓３７２（エリア、ショップ、担当者）の他に、顧客名、顧客入金状況、業者名等を入力する入力欄と、着工日、完工日、支払日等の期間を指定する欄と、表示欄３７３とが設けられている。顧客入金状況は、「ＯＫ」、「ＮＧ」の何れかが表示される。
表示欄３７３には、現場住所、業者名、契約日、発注書、着工日、完工日、顧客入金状況、支払金額、支払日等の項目毎に、絞り込み窓３７２で絞り込んで検索されたデータが表示される。
発注書の項目は、発注日が表示される。着工日の項目には、業者毎の着工日が表示される。
このように支払管理画面３７１では、製品＆施工内容ＤＢ１２１のデータを支払いの面から検索し表示することができる。
各業者への発注を行った分が業者に対して支払済なのか未払なのかが一覧で表示できるため、業者からの二重請求、その結果の二重支払を防ぐことができる。
また、発注した工事が終了しているかどうかも確認できるので、発注済未払い分に対して、業者から請求が来た際にその請求内容を支払ってもよいものなのかどうかを確認することができる。

図５１に示す入金管理画面３８１は、リフォーム業者サーバ１の製品＆施工内容ＤＢ１２１に記憶されているデータのうち入金データを管理するための画面である。
入金管理画面３８１には、図４３に示した受注分析画面３０１と同様の絞り込み窓３８２（エリア、ショップ、担当者）の他に、入金予定日、入金日等の期間を指定する欄と、顧客名を入力する入力欄と、入金状況のチェックボックスと、表示欄３７３とが設けられている。顧客入金状況は、「ＯＫ」、「ＮＧ」、「なし」の何れかにチェックすることで検索対象のデータを絞り込むことができる。
表示欄３８３には、受注額、契約金、着手金、完工金、請求書発行日、入金状況の欄が設けられている。
契約金の欄には、予定日、予定額、入金日、入金額が表示される。
着手金の欄には、予定日、予定額、入金日、入金額が表示される。
完工金の欄には、予定日、予定額、入金日、入金額が表示される。
請求書発行日の欄には、契約日、着工日、完工日が表示される。
入金状況の欄には、契約金、着工金、完工金の状況が表示される。契約金、着工金、完工金の状況は、「ＯＫ」又は「ＮＧ」が表示される。「ＮＧ」の条件は、入金予定日が過ぎても入金がない場合又は入金金額が予定額と異なる場合（多い又は少ない）に、「ＮＧ」が表示される。「ＯＫ」は、デフォルトで表示しない。「ＯＫ」は入金予定毎に検索できる。
このように入金管理画面３８１では、製品＆施工内容ＤＢ１２１のデータを入金の面から検索し表示することができる。
リフォーム業界の通例として、多くの工事を請けるため、業者が集金を忘れて未収入金となるケースが多く、それを防ぐ効果がある。
例えば着工予定日に報告もないのに着工していないケースがあるが、このようなケースでは、上位の管理者が支払管理画面３７１を確認することで、何かお客様ともめているのではないかと推測できる。
また、入金予定日なのに入金がされていないケースがあるが、このようなケースでは、工事が遅れている、又は顧客からクレームを受けていて入金がされていない可能性がある、等と推測することができる。
また、上述したように発注管理、工事管理、支払管理、入金管理を行うことで、担当が隠している潜在的な顧客クレームを顕在化する働きもある。

図５２に示す予定管理画面４００は、リフォーム業者サーバ１の製品＆施工内容ＤＢ１２１に記憶されているデータのうち予定データを管理するための画面であり、横軸に曜日、縦軸に日付けがとられた四角のマス目構造のカレンダーで表示される。各マスでは、その日の内容が、ユーザ毎、ショップ毎、エリア毎、会社毎に管理できる。
予定管理画面４００には、時間編集ボタン４０１、メモ編集兼確認ボタン４０２、メモ作成ボタン４０３が設けられている。
時間編集ボタン４０１では、時間を選ぶことができる。
メモ編集兼確認ボタン４０２は、メモ欄のメモの編集とメモ欄に入りきらないメモを見るためのボタンである。
メモ作成ボタン４０３では、お客様名、件名、現場住所、メモ等が入力可能であり、１回のボタン操作で、１つのメモ欄を作成できる。
このように予定管理画面４００では、製品＆施工内容ＤＢ１２１のデータを予定の面から検索し表示することができる。例えば管理者が、関係する各担当の予定を確認できるため、予定管理ツールとしての側面を持つことができる。

次に、図５３、図５４を参照して、第２実施形態の情報処理システムの各種連携機能について説明する。図５３は、ＣＡＤ連携機能の画面を示す図である。図５４は、カタログ連携機能の画面を示す図である。
図８に示した製品吹き出し画面では、画面で選択された製品の詳細内容（仕様等）が吹き出しの形態で表示されたり、サイドメニューに製品の色が表示される。

この第２実施形態では、図５３に示す画面４１０で製品のポインタ４１１が選択されると、図２３の製品候補提示部６２は、連携されているＣＡＤプログラム（ＣＡＤソフト等）を起動して当該製品が配置されているＣＡＤデータ４１２をポップアップ表示する。

ＣＡＤデータ４１２は、具体的な製品の配置図であり、当該製品がどの位置にどのように配置されているかがわかる。この図では、ＣＡＤデータ４１２の一例として平面図を例示したが、３Ｄ等の立体図であってもよい。
このようにＣＡＤソフトと連携して図面を描いたり、タップした商品を実際に配置した感覚を３Ｄ（立体）等で確かめることができる。

また、図５４に示す画面４１０で製品のポインタ４１１が選択されると、図２３の製品候補提示部６２は、そのポインタ４１１の製品に対応するカタログの該当ページ４２０にジャンプし、該当ページ４２０をポップアップ表示する。
このようにウェブ上のカタログページと連携することで、当該製品の詳細な仕様やカラーバリエーション、コーディネイトの例等を確認することができる。

現場にて行ったリフォーム工事の見積りに対して、合意がとれた場合にはスピード感をもって（工事種別によっては即座に）契約を行うことになる。
本実施形態の情報処理システムでは、見積りから受注、契約、夫々の時点の書類作成、その後の工事の進捗管理、工事完了後のユーザからの工事代金の入金までの一連の処理を一貫して管理できるので、ユーザにリフォーム工事のトータルサービスを提供することができる。
特に、リフォーム工事では、リフォーム工事を請け負うリフォーム工事業者が見積りを行う場合、法律の関係で小さな工事や商品でもその部分を工事する下請け業者に依頼して見積りを作成してもらう必要があったり、その見積りを元に利益を乗せて見積りをユーザに提出しなければならない。
また、見積りから契約に移行する際は、見積書と異なる形式の契約用の書類を用意したり、業者間で施工日をすり合わせた上で工事日程を決定する必要がある。
このように作業では、書類作成に時間を費やしたり業者間の連絡が滞り、工期が遅れがちになるが、本実施形態の情報処理システムを導入することで、これらの手数を省略でき、リフォーム工事業者側の業務を効率化することができる。

図１２の画面の例では、受注済の状態の画面を例示したが、この他、例えば受注一覧の画面を表示できる。この受注一覧の画面では、「受注の差替」「解約合意書作成」、工事完了後には、「工事完了確認書」を作成することができる。
また、同画面では、契約破棄・差替・契約書印刷・メールが可能である。これにより、リフォーム担当者は、受注一覧の画面で受注した内容を確認し、契約の差替処理や解約処理を容易に行うことができる。
さらに、受注一覧の画面では、「受注詳細」ボタンを押下することで、Ｗｅｂ上の「受注詳細画面」にジャンプできる。これによりリフォーム担当者は、当該受注情報を簡易に編集することができる。

本実施形態の情報処理システムは、リフォーム業者サーバ１にアクセスするためのアカウントを階層的に管理し、所定の単位毎にアクセスの制限要否を各階層で設定して管理する管理機能と、発注情報を作成する発注情報作成機能と、発注書を作成する発注書作成機能と、帳簿や書類を作成する書類作成機能とをさらに備える。

管理機能は、発注情報の作成権限や発注書の作成権限等の権限が事前に設定されており、権限によって夫々の作成範囲を制限する。
リフォーム業者サーバ１は、工事について決定された施工内容及び製品について、当該工事の施工者の候補との間で予め合意された原価情報に基づいて、当該工事に関する見積りを発行する見積発行部６４（図２３参照）を備える。
原価情報は、予め合意しているものの、現地調査にて予定されていた原価情報より価格が増減することがある。又は合意した原価情報に注意書きで現場状況によって変動する可能性があると記されていることがある。このような場合、予定されていた発注情報のみでは発注することができない。
このため、製品＆施工内容ＤＢ１２１には、編集不可である予定原価と編集可能な実行原価が存在し、実行原価の価格情報にて発注が可能である。但し実行原価が誰でも編集できると、原価の合意が崩れ、担当による余分な金額での発注等の悪用が可能になり、システムの脆弱性に繋がる。

そこで、本実施形態では、リフォーム業者サーバ１に発注情報作成機能と管理機能とを設け、発注情報作成機能が発注情報を作成する際に、実行原価の編集をできるかどうかを管理機能が各担当毎に決定する。権限によっては別担当の発注情報の作成も可能である。
一方、予め合意されているとはいえ、営業単位で勝手に発注をさせず、営業事務など管理部門にて発注管理をしている会社が多く存在する。
この状況を鑑みて、発注情報作機能とは別に実際のＰＤＦ形式の書類を印刷及び送信できる発注書作成機能と管理機能を設け、発注書作成機能が営業単位で発注書を作成する際に、管理機能が発注書を作成できる人又は範囲を制限する。権限によっては、複数の担当分の発注書を作成できる。
なお、予定していた利益と実際の利益を受注単位ごとに可視化するため、また編集者が予定原価と実行原価との違いを明確に意識できるようにするため予定原価の情報を保持しておくものとする。
なお、実行原価を変更可能ケースとしては、上司等に連絡を取って金額の承認を得たり等、諸々の作業と等価なことが事前に確認されていることが前提である。

書類作成機能は、見積りから支払いまでの各種必要書類が一貫して自動で出力することが可能である。
リフォーム工事では、工事の見積りから受注した後、契約後も工事台帳の作成、各施工業者への発注書作成、請求書作成、領収書の作成、工事完了確認書の作成、といった書類を作る必要がある。
このように見積りから支払いまでに非常に多くの書類を作成する際に書類上の作成ミスもよく起きる。
このことが顧客側の視点では、発注ミスや契約書の仕様ミス等で誤った工事をされる原因になり、業者の手を取られることによる顧客からのリクエストの反応が遅くなる原因になる。
リフォーム業者サーバ１に書類作成機能を備えることは、リフォーム業者のリフォーム担当者においても、致命的な書類の作成忘れを防ぐことができるので大変有効である。
例えば台帳を忘れると監査が入ったときに問題になったりする。台帳がないと予算の把握も困難になる。また請求書を忘れると、お客様から入金がなされない場合がある。未収入金はリフォーム業界ではよく発生する。
このように各種書類が多くあり作成が大変であるのにも関わらず、各種書類にミスを許されず、しかも他書類と重複している内容を何度も作成しないとならない。それゆえ書類のチェック等に時間がかかる企業も多いのが実情である。また、リフォーム業は数をこなす必要がある。どんな小さな工事でも上記の書類を作成する必要がある。
リフォーム業者サーバ１に書類作成機能を備えることで、これらの各種書類を自動で出力することは、リフォーム業の運営にとって非常に価値があることである。

また例えば、上述の図３、図４及び図１３に示す機能ブロックは例示にしかすぎず、さらに図示せぬ別の機能ブロックが、情報処理システムに設けられていてもよい。
例えば、上述したように、情報処理システムは、見積・受注案件内容確認部（スケジュール・案件進捗・工程管理の確認をする機能を含む手段）を有するようにしてもよい。
また例えば、情報処理システムは、施工内容を決定するのみならず、その価格（施工価格）を決定する機能を発揮する部（以下、「施工内容・施工価格決定部」と呼ぶ）を有するようにしてもよい。これにより、施工内容の値引き処理が可能になる。
また例えば、情報処理システムは、製品を決定するのみならず、その価格（製品価格）を決定する機能を発揮する部（以下、「製品・製品価格決定部」と呼ぶ）を有するようにしてもよい。これにより、製品の値引き処理が可能になる。
また例えば、情報処理システムは、その他項目で商品や工事についてのメニューを作成する機能を発揮する部を有するようにしてもよい。
また例えば、情報処理システムは、案件のいわゆるＢＩ機能を発揮する部を有するようにしてもよい。

情報処理システムは、権限設定機能、分析機能、予定管理機能を備えてもよい。
・権限設定機能について
会社によって、営業は営業部、工事の施工管理は工事部といった形態をしている会社もある。また、営業単位で発注しているが、発注権限は上長にあるという形態の会社も想定できる。
このような場合に担当営業が発注システムを自由に触れることに不都合がある可能性がある。そのニーズに対応するために、発注書の作成をするためには一定の権限がないとできないといった設定が可能である。なお、権限が大きくなれば他人の発注書も作成可能である。
また、１人の営業担当者が別の営業担当者の見積・受注履歴が見えることが不都合な会社の形態も想定できる。このようなニーズに対応するために、権限の大きさによってどの範囲まで閲覧が可能かを設定することができる。

・分析機能について
売れ筋商品を確認したいというニーズにこたえるために、すべての商品がシステムに反映されている特性を活かして、どの商品群がどれくらいの受注があり、全商品中シェアは何％か等という表示ができる。また、商品群毎にどの商品が売れ筋なのかも確認することができる。

・予定管理機能について、
見積提出日・見積期限日・契約日・着工予定日・完工予定日・着工日・完工日・入金予定日・入金日等、各顧客に対する予定日と実績を入力する欄を活かしてカレンダー上で各人が予定管理できる機能がある。権限によってどの担当分を閲覧するのかを設定することができる

上記実施形態では、ＣＡＤ連携機能やカタログ連携機能を例示したが、この他、例えば他社の見積ソフト、顧客データシステム、会計ソフト等の各部署のソフトウェアからエンタープライズシステムやＥＲＰパッケージのような会社規模のシステムにもＡＰＩ連携を行うことができる。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。

また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものである。

以上まとめると、本発明が適用される情報処理システムは、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理システムは、
建物の工事の施工内容を決定する施工内容決定手段（例えば図４の施工内容決定部６１）と、
前記工事に必要な製品を決定する製品決定手段（例えば図４の製品決定部６３）と、
前記工事について決定された前記施工内容及び前記製品についての、当該工事の施工者の候補との間で予め合意された原価情報に基づいて、当該工事に関する見積りを発行する見積発行手段（例えば図４の見積発行部６４）と、
を備える。

また、情報処理システムは、
前記工事の施工の日程を決定する施工日程決定手段（例えば図４の施工日程決定部６６）と、
前記工事について決定された前記施工内容、前記製品、及び前記施工の日程に基づいて、前記工事の受注に関する処理を実行する受注手段（例えば図４の受注処理部６９）と、
をさらに備えることができる。

前記工事について決定された、前記施工内容、前記製品、及び前記施工の日程に基づいて、当該工事の施工者の候補の段取りに関する情報を、段取情報として取得する段取情報取得手段（例えば図４の施工者段取部８２）、
をさらに備え、
前記受注手段は、さらに前記段取情報に基づいて、前記工事の受注に関する前記処理を実行することができる。

前記工事の受注の内容に基づいて、前記候補を前記工事の施工者として決定し、当該施工者に対して前記工事の施工を発注する発注手段（例えば図１３の施工者発注処理部８４）、
をさらに備えることができる。

前記情報処理システムにアクセスするためのアカウントを階層的に管理し（例えば図２０に示す階層でアカウントを管理し）、所定の単位毎にアクセスの制限要否を各階層で設定して管理する管理手段（例えば図３の主制御部５３）、
をさらに備えることができる。

また、本発明が適用される情報処理システムは、工事を依頼するユーザ及び当該工事を請け負う請負者（例えばリフォーム業者サーバ１を管理するリフォーム業者の担当者）のうち少なくとも一方の操作を受け付ける第１情報処理装置（例えば図２３のアプリがインストールされたタブレット等のリフォーム担当者端末２）と、前記工事についての見積りから請負の契約に至る前記請負者の一連の作業を支援する第２情報処理装置（例えば図２３のリフォーム業者サーバ１等）とを含む情報処理システムにおいて、
前記第２情報処理装置（例えば図２３のリフォーム業者サーバ１等）は、
前記工事に関する見積りを前記第１情報処理装置へ発行する見積り発行手段（例えば図２３の見積発行部６４等）と、
前記見積りの提示を受けた前記ユーザからの前記工事の依頼に基づいて、前記工事の請け負いの電子的な前記契約を、当該ユーザと前記請負者との間で行わせる制御（例えば電子サインシステム４を介する制御）を実行する契約制御手段（例えば図２３の契約制御部１０３等）と、
を備え、
前記第１情報処理装置（例えば図２３のリフォーム担当者端末２）は、
前記見積りを前記ユーザに提示する提示手段（例えば図２３の提示部１３１等）と、
前記見積りの提示を受けた前記ユーザによる前記工事の依頼を示す操作（ユーザ又は請負者により行われる操作：例えば、図２４のＳ１０２やＳ１０３における、内容確認ボタン、約款確認ボタン、受注確認ボタン等の押下操作）を受け付ける第１操作受付手段（例えば図２３の依頼操作受付部１３２等）と、
前記契約制御手段の制御に基づいて、少なくとも前記ユーザ側の契約の締結に関する操作（例え図３２の署名確定のボタン２５６の押下操作）を受け付ける第２操作受付手段（例えば図２３の締結操作受付部１３３等）と、
を備える、
ことにより、請負者は、工事についての見積りを発行してから請負の契約の締結までの一連の操作を、タブレット等のリフォーム担当者端末２を工事の現場等に持ち込みその場でユーザと対面しながらリアルタイムに行ったり、遠隔地にいるユーザと非対面で行ったりすることができる。
ユーザにとっては、見積りを受け取ったり、契約をしたりという請負者とのやり取りを何回かにわけて行う煩わしさが軽減される。
また、請負者（リフォーム担当者）としては、その場で契約が成立するので、会社に戻って書類を作成する等の作業が不要になり、業務効率の向上を図ることができる。
さらに、単なる紙契約ではなく電子的な契約を導入することで、紙契約の場合に生じる印紙代、郵送代、用紙代等を節約することができる。
また、電子的な契約では、契約内容をデータでシステムに保存しており、必要な情報をシステム上で容易に検索できる。また紙のように保管する物理的なスペースが不要であり、紛失することもない。
前記工事がリフォーム工事を含む、
ことにより、リフォーム工事では、施工者の営業担当者等は、ユーザの自宅を訪ねて、どの部分を増改築するかといった細かな商談と見積りが必要であり、その際に商談の内容から作成した見積書や契約書をリフォーム担当者端末２等に表示させてユーザに提示し、その場でユーザが納得の下で商談を成立させることができるので、業務効率を向上することができる。
前記第２操作受付手段（例えば図２３の締結操作受付部１３３等）は、さらに、前記ユーザの筆記の操作によるサイン（例えば図２６のサイン画面２２０）を受け付ける、
ことにより、ユーザは、契約というシーンにおいて、例えば手書きでサインを入力するという明示的な操作を行うことで（手書きでサインするという演出を受けることで）、契約をしたという実感が得られる。
前記第２操作受付手段（例えば図２３の締結操作受付部１３３等）は、
さらに、前記契約を行う方式として、対面式と非対面式とのうち何れかを前記ユーザに選択させる操作を受け付け、
前記対面式が選択された場合、前記ユーザの筆記の操作による前記サインを受け付けることを許可し、
前記非対面式が選択された場合（例えば図２６のスキップのチェックボタンが押下された場合）、前記ユーザの筆記の操作による前記サインを受け付けることを禁止する、
ことにより、契約の方式を対面形式か非対面式かをユーザに選択させることができる。
ユーザが対面形式を選択した場合は、（上述の効果と同様に）手書きのサインという演出効果が得られ、契約をしたという実感を得られる。
一方、現場から離れている場所にいる等の理由でユーザが非対面式を選択した場合は、演出効果を不要として、電子的な契約を迅速に締結させることができる。
前記契約制御手段（例えば図２３の契約制御部１０３等）は、
前記ユーザ及び前記請負者の夫々の署名を所定認証機関（例えば図２３の電子サインシステム４）に認証させる制御を実行する認証制御手段（例えば図２３の認証制御部１１１等）を含む、
ことにより、ユーザと請負者の夫々の署名を外部の認証機関（例えば図２３の電子サインシステム４等の所定認証機関）に認証させることで、信頼性のある契約を成立させることができる。
前記契約制御手段（例えば図２３の契約制御部１０３等）は、
紙媒体による前記契約（紙ベースで契約）と、電子的な前記契約（電子署名による契約）とのうち、何れかで行うのかを前記ユーザに選択させる操作を受付け（例えば図２６の紙ベースで契約するのチェックボックス２２３）、
電子的な前記契約が選択された場合、前記工事の請負の電子的な前記契約を、当該ユーザと前記請負者との間で行わせる制御（例えば図２３の電子サインシステム４を介する制御）を実行する、
ことにより、ユーザの中には、紙の契約書のサイン欄にペンでサインして、契約の重みや実感を味わいたいと要望する者も存在する。このような要望に応えることができる。
前記第１情報処理装置（例えば図２３のリフォーム担当者端末２）は、
前記第１操作受付手段及び前記第２操作受付手段の夫々により受け付けられる操作がなされる操作子（ソフトウェアボタン等）を、同一画面内に順次表示させる制御を実行する表示制御手段（例えば図２３の表示制御部１３４）、
をさらに備える、
ことにより、ユーザは、画面内に操作子（ソフトウェアボタン等）が表示される順にクリック操作を進めてゆくことで、工事の見積りから工事の請け負い契約に至る一連の作業を行えるので、タブレット等の操作に不得手なユーザでも請負者との手続きを進めることができる。
加えて、請負契約後の業者発注書・工事台帳・請求書等の書式も自動作成される。特に発注書に関しては、本システムに予め登録されている業者担当者名・メールアドレスを読み取り、発注書を即座に発送できる。
また、着工日・完工日情報や業者毎の工事完了日や支払情報やお客様からの入金情報といったリフォーム工事での必要項目が全て入力する箇所があるため、リフォーム工事の見積りから入金に至るまでの一連の手続きを本システム上で完結することができる。
この特性を活かして、業者未払いの管理や顧客からの未入金管理といった管理機能も備える。
本発明が適用される情報処理方法は、
工事を依頼するユーザ及び当該工事を請け負う請負者（例えば例えばリフォーム業者サーバ１を管理するリフォーム業者の担当者）のうち少なくとも一方の操作を受け付ける第１情報処理装置（例えばアプリが入っているタブレット等のリフォーム担当者端末２）と、前記工事についての見積りから請負の契約に至る前記請負者一連の作業を支援する第２情報処理装置（例えば図２３のリフォーム業者サーバ１）とを含む情報処理システムが実行する情報処理方法において、
前記第２情報処理装置が実行するステップとして、
前記工事に関する見積りを前記第１情報処理装置へ発行する見積り発行ステップ（例えば図２４のＳ１０１）と、
前記見積りの提示を受けた前記ユーザからの前記工事の依頼に基づいて、前記工事の請負の電子的な前記契約を、当該ユーザと前記請負者との間で行わせる制御（例えば図２３の電子サインシステム４を介する制御）を実行する契約制御ステップ（例えば図２４のＳ１０４~Ｓ１０６）と、
を含み、
前記第１情報処理装置が実行するステップとして、
前記見積りを前記ユーザに提示する提示ステップと、
前記見積りの提示を受けた前記ユーザによる前記工事の依頼を示す操作（ユーザ又は請負者により行われる操作：例えば、図２４のＳ１０２やＳ１０３における、内容確認ボタン、約款確認ボタン、受注確認ボタン等の押下操作）を受け付ける第１操作受付ステップと、
前記契約制御ステップにおける制御に基づいて、少なくとも前記ユーザ側の契約の締結に関する操作（例え図３２の署名確定のボタン２５６の押下操作）を受け付ける第２操作受付ステップと、
を含む。
本発明が適用されるプログラムは、
工事を依頼するユーザ及び当該工事を請け負う請負者（例えば例えばリフォーム業者サーバ１を管理するリフォーム業者の担当者）のうち少なくとも一方の操作を受け付ける第１情報処理装置（例えばアプリが入っているタブレット等のリフォーム担当者端末２）と、前記工事についての見積りから請負の契約に至る前記請負者一連の作業を支援する第２情報処理装置（例えば図２３のリフォーム業者サーバ１）とを含む情報処理システムにおいて用いられるプログラムであって、
前記第２情報処理装置を制御するコンピュータ（図２３のＣＰＵ１１）に、
前記工事に関する見積りを前記第１情報処理装置へ発行する見積り発行ステップ（例えば図２４のＳ１０１）と、
前記見積りの提示を受けた前記ユーザからの前記工事の依頼に基づいて、前記工事の請負の電子的な前記契約を、当該ユーザと前記請負者との間で行わせる制御（例えば電子サインシステムを介する制御）を実行する契約制御ステップ（例えば図２４のＳ１０４~Ｓ１０６）と、
を含む制御処理を実行させ、
前記第１情報処理装置を制御するコンピュータ（図２３のＣＰＵ６１）に、
前記見積りを前記ユーザに提示する提示ステップと、
前記見積りの提示を受けた前記ユーザによる前記工事の依頼を示す操作（ユーザ又は請負者により行われる操作：例えば、図２４のＳ１０２やＳ１０３における、内容確認ボタン、約款確認ボタン、受注確認ボタン等の押下操作）を受け付ける第１操作受付ステップと、
前記契約制御ステップにおける制御に基づいて、少なくとも前記ユーザ側の契約の締結に関する操作（例え図３２の署名確定のボタン２５６の押下操作）を受け付ける第２操作受付ステップと、
を含む制御処理を実行させる。

１・・・リフォーム業者サーバ、２,２−１乃至２−ｎ・・・リフォーム担当者端末、３，３−１乃至３−ｍ・・・施工者端末、１１・・・ＣＰＵ、５１・・・担当者処理制御部、５２・・・施工者処理制御部、５３・・・主制御部、６１・・・施工内容決定部、６２・・・製品候補提示部、６３・・・製品決定部、６４・・・見積発行部、６５・・・施工日程案提示部、６６・・・施工日程決定部、６７・・・施工者段取確認部、６８・・・受注可否判定部、６９・・・受注処理部、８１・・・施工情報取得部、８２・・・施工者段取部、８３・・・受注確認部、８４・・・施工者発注処理部、９１・・・施工者日程調整部、９２・・・施工者発注予約部

Claims (9)

1. 工事を依頼するユーザ及び当該工事を請け負う請負者の担当者のうち少なくとも一方の操作を受け付ける第１情報処理装置と、前記工事についての見積りから請負の契約に至る前記請負者の一連の作業を支援する第２情報処理装置とを含む情報処理システムにおいて、
   前記第２情報処理装置は、
   前記工事に関する見積りを前記第１情報処理装置へ発行する見積り発行手段と、
   前記見積りの提示を受けた前記ユーザからの前記工事の依頼に基づいて、前記工事の請け負いの電子的な前記契約を当該ユーザと前記請負者との間で行わせる制御の少なくとも一部として、前記契約に関する契約書の署名の認証を所定の認証機関へ依頼する制御を実行する契約制御手段と、
   を備え、
   前記第１情報処理装置は、
   前記見積りを前記ユーザに提示する提示手段と、
   前記見積りの提示を受けた前記ユーザによる前記工事の依頼を示す操作を受け付ける第１操作受付手段と、
   前記契約を締結させるための指示操作を受け付ける第２操作受付手段と、
   を備え、
   前記契約制御手段は、
   前記第２操作受付手段により前記指示操作が受け付けられた場合、
   前記契約書についての第１認証依頼を前記所定の認証機関に送信することで、
   当該第１認証依頼を受信した前記所定の認証機関から前記契約書への署名要求を前記ユーザの操作対象のデバイスに送信させ、
   当該署名要求がなされた当該ユーザにより当該デバイスに対する署名の操作がなされた場合には、前記契約書に対する前記ユーザの署名を前記所定の認証機関に認証させる、
   制御を実行するユーザ認証制御手段と、
   前記請負者の署名が前記所定の認証機関に予め登録されている場合には、前記第１認証依頼を受信した前記所定の認証機関に、前記ユーザの署名の前記認証と共に、前記請負者の署名を認証させ、
   それ以外の場合には、前記第１認証依頼に対して前記所定の認証機関において行われた前記ユーザの署名の前記認証の後、前記契約書に前記請負者の署名を付与する処理を実行したうえで、前記契約書についての第２認証依頼を前記所定の認証機関に送信することで、当該第２認証依頼を受信した前記所定の認証機関に、前記請負者の署名を認証させる、
   制御を実行する請負者認証制御手段と、
   を含む情報処理システム。
2. 前記契約制御手段は、
   前記契約書を、改竄防止機能を有する所定形式のファイルの形態で前記所定の認証機関へ送信することで、前記第１認証依頼を送信する、
   請求項１に記載の情報処理システム。
3. 前記ユーザ認証制御手段は、
   前記第１認証依頼を前記所定の認証機関に送信することで、
   前記所定の認証機関から送信される、前記契約書への前記署名要求と、当該契約書の保管場所とを含む情報を前記デバイスに送信させ、
   前記ユーザによる前記デバイスに対する操作により、前記情報に含まれる前記保管場所へアクセスして、前記契約書に対して前記署名の前記操作がなされた場合には、前記契約書に対する前記ユーザの署名を前記所定の認証機関に認証させる、
   制御を実行する、
   請求項１に記載の情報処理システム。
4. 前記第１操作受付手段により受け付けられる、工事の依頼を示す前記操作の１つに、手書きサインを受け付ける操作が含まれる、
   請求項１に記載の情報処理システム。
5. 前記契約制御手段は、
   前記手書きサインを、前記ユーザの前記契約書に付与する署名として選択可能とする、
   請求項４に記載の情報処理システム。
6. 前記第２操作受付手段は、前記契約書の形態として紙と電子のうち何れかの選択を受け付け、
   前記第２操作受付手段により前記紙の選択が受け付けられた場合、前記ユーザにより押印又は手書きサインがなされた前記紙の形態の前記契約書を、改竄防止機能を有する所定形式のファイルにして前記第２情報処理装置に送信する制御を実行する送信制御手段、
   をさらに備える請求項１乃至５のうち何れか１項に記載の情報処理システム。
7. 前記第１操作受付手段及び前記第２操作受付手段の夫々により受け付けられる操作がなされる操作子を、前記第１情報処理装置の制御対象の画面内に順次表示させる制御を実行する表示制御手段、
   をさらに備える請求項１乃至６のうち何れか１項に記載の情報処理システム。
8. 工事を依頼するユーザ及び当該工事を請け負う請負者の担当者のうち少なくとも一方の操作を受け付ける第１情報処理装置と、前記工事についての見積りから請負の契約に至る前記請負者の一連の作業を支援する第２情報処理装置とを含む情報処理システムが実行する情報処理方法において、
   前記第２情報処理装置が実行するステップとして、
   前記工事に関する見積りを前記第１情報処理装置へ発行する見積り発行ステップと、
   前記見積りの提示を受けた前記ユーザからの前記工事の依頼に基づいて、前記工事の請け負いの電子的な前記契約を当該ユーザと前記請負者との間で行わせる制御の少なくとも一部として、前記契約に関する契約書の署名の認証を所定の認証機関へ依頼する制御を実行する契約制御ステップと、
   を含み、
   前記第１情報処理装置が実行するステップとして、
   前記見積りを前記ユーザに提示する提示ステップと、
   前記見積りの提示を受けた前記ユーザによる前記工事の依頼を示す操作を受け付ける第１操作受付ステップと、
   前記契約を締結させるための指示操作を受け付ける第２操作受付ステップと、
   を含み、
   前記契約制御ステップは、
   前記第２操作受付ステップの処理により前記指示操作が受け付けられた場合、
   前記契約書についての第１認証依頼を前記所定の認証機関に送信することで、
   当該第１認証依頼を受信した前記所定の認証機関から前記契約書への署名要求を前記ユーザの操作対象のデバイスに送信させ、
   当該署名要求がなされた当該ユーザにより当該デバイスに対する署名の操作がなされた場合には、前記契約書に対する前記ユーザの署名を前記所定の認証機関に認証させる、
   制御を実行するユーザ認証制御ステップと、
   前記請負者の署名が前記所定の認証機関に予め登録されている場合には、前記第１認証依頼を受信した前記所定の認証機関に、前記ユーザの署名の前記認証と共に、前記請負者の署名を認証させ、
   それ以外の場合には、前記第１認証依頼に対して前記所定の認証機関において行われた前記ユーザの署名の前記認証の後、前記契約書に前記請負者の署名を付与する処理を実行したうえで、前記契約書についての第２認証依頼を前記所定の認証機関に送信することで、当該第２認証依頼を受信した前記所定の認証機関に、前記請負者の署名を認証させる、
   制御を実行する請負者認証制御ステップと、
   を含む、
   情報処理方法。
9. 工事を依頼するユーザ及び当該工事を請け負う請負者の担当者のうち少なくとも一方の操作を受け付ける第１情報処理装置と、前記工事についての見積りから請負の契約に至る前記請負者の一連の作業を支援する第２情報処理装置とを含む情報処理システムにおいて用いられるプログラムであって、
   前記第２情報処理装置を制御するコンピュータに、
   前記工事に関する見積りを前記第１情報処理装置へ発行する見積り発行ステップと、
   前記見積りの提示を受けた前記ユーザからの前記工事の依頼に基づいて、前記工事の請け負いの電子的な前記契約を当該ユーザと前記請負者との間で行わせる制御の少なくとも一部として、前記契約に関する契約書の署名の認証を所定の認証機関へ依頼する制御を実行する契約制御ステップと、
   を含む制御処理を実行させ、
   前記第１情報処理装置を制御するコンピュータに、
   前記見積りを前記ユーザに提示する提示ステップと、
   前記見積りの提示を受けた前記ユーザによる前記工事の依頼を示す操作を受け付ける第１操作受付ステップと、
   前記契約を締結させるための指示操作を受け付ける第２操作受付ステップと、
   を含む制御処理を実行させ、
   前記第２情報処理装置を制御するコンピュータに、
   前記契約制御ステップにおいて、
   前記第２操作受付ステップの処理により前記指示操作が受け付けられた場合、
   前記契約書についての第１認証依頼を前記所定の認証機関に送信することで、
   当該第１認証依頼を受信した前記所定の認証機関から前記契約書への署名要求を前記ユーザの操作対象のデバイスに送信させ、
   当該署名要求がなされた当該ユーザにより当該デバイスに対する署名の操作がなされた場合には、前記契約書に対する前記ユーザの署名を前記所定の認証機関に認証させる、
   制御を実行するユーザ認証制御ステップと、
   前記請負者の署名が前記所定の認証機関に予め登録されている場合には、前記第１認証依頼を受信した前記所定の認証機関に、前記ユーザの署名の前記認証と共に、前記請負者の署名を認証させ、
   それ以外の場合には、前記第１認証依頼に対して前記所定の認証機関において行われた前記ユーザの署名の前記認証の後、前記契約書に前記請負者の署名を付与する処理を実行したうえで、前記契約書についての第２認証依頼を前記所定の認証機関に送信することで、当該第２認証依頼を受信した前記所定の認証機関に、前記請負者の署名を認証させる、
   制御を実行する請負者認証制御ステップと、
   を含む制御処理を実行させる、
   プログラム。

Images