(57)【要約】【課題】受注者の人的資源を効率的に活用できる業務仲介装置、業務仲介方法および業務仲介プログラムを提供する。【解決手段】業務仲介装置は、発注された複数のタスクを順に、当該タスクの受注を希望する複数の受注者の各端末から成果物を納入可能な状態に公開する。業務仲介装置は、成果物を納入可能な状態とされたタスクに対する成果物の納入を受注者の各端末から受け付ける。業務仲介装置は、受け付けた成果物から報酬を支払う対象の成果物を決定する。【選択図】図１
2014153756.tif 000002
【特許請求の範囲】
【請求項１】
発注された複数の業務を順に、当該業務の受注を希望する複数の受注者の各端末から成果物を納入可能な状態に公開する公開手段と、
前記公開手段により成果物を納入可能な状態とされた業務に対する成果物の納入を前記複数の受注者の各端末から受け付ける受付手段と、
前記受付手段により受け付けた成果物から報酬を支払う対象の成果物を決定する決定手段と、
を有することを特徴とする業務仲介装置。
【請求項２】
前記決定手段は、前記成果物が納入されるまでの時間に基づいて報酬を支払う対象の成果物を決定する
ことを特徴とする請求項１に記載の業務仲介装置。
【請求項３】
前記決定手段は、最初に納品された成果物を報酬を支払う対象の成果物と決定する
ことを特徴とする請求項２に記載の業務仲介装置。
【請求項４】
前記公開手段は、前記複数の業務を所定個ずつ順に成果物を納入可能な状態に公開する
ことを特徴とする請求項１〜３の何れか１つに記載の業務仲介装置。
【請求項５】
前記受付手段により受け付けた成果物が所定の基準を満たしているか否かをチェックするチェック手段をさらに有し、
前記決定手段は、前記チェック手段によって所定の基準が満たされていると判定された成果物から報酬を支払う対象の成果物を決定する
ことを特徴とする請求項１〜４の何れか１つに記載の業務仲介装置。
【請求項６】
前記チェック手段は、前記受注者の端末に対し、予め正答が定まっているダミー問題を送信し、前記受注者の端末から返信された回答が前記正答に一致している場合に、前記所定の基準が満たされていると判定する
ことを特徴とする請求項５に記載の業務仲介装置。
【請求項７】
前記チェック手段は、前記業務に対する成果物が複数の受注者の端末から受付けた際に、前記各成果物を比較し、成果物同士の一致数または一致率が所定値以上の場合に、前記所定の基準が満たされていると判定する
ことを特徴とする請求項５に記載の業務仲介装置。
【請求項８】
コンピュータが実行する業務仲介方法であって、
発注された複数の業務を順に、当該業務の受注を希望する複数の受注者の各端末から成果物を納入可能な状態に公開する公開工程と、
成果物を納入可能な状態とされた業務に対する成果物の納入を前記複数の受注者の各端末から受け付ける受付工程と、
受け付けた成果物から報酬を支払う対象の成果物を決定する決定工程と、
を有することを特徴とする業務仲介方法。
【請求項９】
発注された複数の業務を順に、当該業務の受注を希望する複数の受注者の各端末から成果物を納入可能な状態に公開する公開手順と、
成果物を納入可能な状態とされた業務に対する成果物の納入を前記複数の受注者の各端末から受け付ける受付手順と、
受け付けた成果物から報酬を支払う対象の成果物を決定する決定手順と、
をコンピュータに実行させることを特徴とする業務仲介プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務仲介装置、業務仲介方法および業務仲介プログラムに関する。
【背景技術】
【０００２】
近年、業務委託形態の１つとして、不特定多数の人に業務を委託するクラウドソーシングが知られている。例えば、インターネットを介して発注者から発注された業務を、不特定多数の受注者に委託するクラウドソーシングのＷｅｂサービスが提供されている。
【０００３】
クラウドソーシングのように発注者から発注された業務を受注者に委託する場合に適用可能な技術として次のような従来技術が提案されている。例えば、事務局側は、特定の物件に必要とされる能力を有する会員を会員情報データベースから検索し、さらに検索された会員の中から評価点に基づいて優秀な者を上位数名、数十名選び出し、これらの会員に対して依頼を送る。連絡を受けた会員は、気に入った内容、条件であれば受諾の意志、もしくは入札参加の意志を知らせる電子メールを事務局に返送する。事務局側は、受託意志のある会員の内から最も高い評価点を有する会員を選択して、この者に正式依頼を発送する（例えば、特許文献１）。この従来技術によれば、発注者から発注された業務を評価点が上位数名、数十名の受託者に委託するため、仕事結果に高い質が期待できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−２１６７４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の従来技術は、評価点が上位数名、数十名の受託者にしか発注者から発注された業務が依頼されず、業務を受託可能な受注者が多数いる場合でも人的資源を効率的に活用できていなかった。
【０００６】
本願は、上記に鑑みてなされたものであって、受注者の人的資源を効率的に活用できる業務仲介装置、業務仲介方法および業務仲介プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願に係る業務仲介装置は、発注された複数の業務を順に、当該業務の受注を希望する複数の受注者の各端末から成果物を納入可能な状態に公開する公開手段と、前記公開手段により成果物を納入可能な状態とされた業務に対する成果物の納入を前記複数の受注者の各端末から受け付ける受付手段と、前記受付手段により受け付けた成果物から報酬を支払う対象の成果物を決定する決定手段と、を有することを特徴とする。
【発明の効果】
【０００８】
本願に係る業務仲介装置によれば、受注者の人的資源を効率的に活用できるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、発注者から発注された業務を不特定多数の人に委託する流れを模式的に示した図である。
【図２】図２は、実施形態に係るシステムの全体の概略構成の一例を示す図である。
【図３】図３は、実施形態に係るサーバの機能的な構成の一例を示す図である。
【図４】図４は、実施形態に係る発注者情報のデータ構成の一例を示す図である。
【図５】図５は、実施形態に係る受注者情報のデータ構成の一例を示す図である。
【図６】図６は、実施形態に係るタスク情報のデータ構成の一例を示す図である。
【図７】図７は、実施形態に係る成果物情報のデータ構成の一例を示す図である。
【図８】図８は、公開されるＷｅｂページの一例を示す図である。
【図９】図９は、タスクに関する情報を表示したＷｅｂページの一例を示す図である。
【図１０】図１０は、成果物のチェックを要求するタスクを表示したＷｅｂページの一例を示す図である。
【図１１】図１１は、実施形態に係る業務仲介処理の手順の一例を示すフローチャートである。
【図１２】図１２は、発注者から発注された業務を並列に不特定多数の人に委託する流れを模式的に示した図である。
【発明を実施するための形態】
【００１０】
以下に、本願に係る業務仲介装置、業務仲介方法および業務仲介プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る業務仲介装置、業務仲介方法および業務仲介プログラムが限定されるものではない。
【００１１】
［１．業務の仲介］
まず、図１を用いて、業務の仲介の一例について説明する。なお、図１は、発注者から発注された業務を不特定多数の人に委託する流れを模式的に示した図である。なお、以下では、仲介する業務のことを「タスク」とも称する。
【００１２】
業務仲介装置は、発注者から業務の発注を受け付けており、発注された複数の業務を順に、当該業務の受注を希望する複数の受注者の各端末から成果物を納入可能な状態に公開する。例えば、業務仲介装置は、発注された複数の業務を１ずつ順に成果物を納入可能な状態に公開する。そして、業務仲介装置は、公開された業務に対する成果物の納入を受け付ける。図１の上側の例では、タスクＡ、Ｂ、Ｃ、Ｄ・・・と複数の業務が発注されており、タスクＡが成果物を納入可能な状態とされている。
【００１３】
業務の受注を希望する複数の受注者は、公開された業務を参照して当該業務に応じた作業を行い、それぞれ成果物を納品する。図１の上側の例では、受注者Ａ、Ｂ、Ｃ・・・がタスクＡに応じた作業を行い、それぞれ成果物を納品している。
【００１４】
業務仲介装置は、受け付けた成果物から報酬を支払う対象の成果物を決定する。例えば、業務仲介装置は、成果物が納入されるまでの時間に基づいて報酬を支払う対象の成果物を決定する。一例として、業務仲介装置は、最初に納品された成果物を、報酬を支払う支払対象の成果物と決定する。業務仲介装置は、支払対象の成果物が決定すると、支払対象が決定した業務に対する成果物の受け付けを終了する。業務仲介装置は、支払対象の成果物を納品した受注者へ報酬を支払う。また、業務仲介装置は、次の業務を成果物を納入可能な状態に公開し、公開された業務に対する成果物の納入を受け付ける。図１の下側の例では、タスクＡの支払対象の成果物が決定して成果物の受け付けを終了し、次のタスクＢが公開されており、タスクＢに対して受注者Ａ、Ｂ、Ｃ・・・が成果物を納品している。
【００１５】
このように、実施形態に係る業務仲介装置は、発注された複数の業務を公開して複数の受注者の各端末から成果物の納入を受け付ける。そして、業務仲介装置は、受け付けた成果物から報酬を支払う対象の成果物を決定する。これにより、業務を受託可能な受注者が多数いる場合に、各受注者が、それぞれ都合や能力に応じて業務を行えるため、受注者の人的資源を効率的に活用できる。以下、このように受注者の人的資源を効率的に活用できる業務仲介装置を含んだクラウドソーシングサービスシステム１０について詳細に説明する。
【００１６】
［２．システムの構成］
実施形態に係るシステムについて説明する。図２は、実施形態に係るシステムの全体の概略構成の一例を示す図である。図２に示すように、クラウドソーシングサービスシステム（以下、ＣＳＳシステムと略す場合がある）１０は、サーバ１１と、発注者端末１２と、受注者端末１３とを有する。サーバ１１と発注者端末１２と受注者端末１３は、各種の情報を交換することが可能とされている。例えば、サーバ１１と発注者端末１２と受注者端末１３は、ネットワーク１４を介して通信可能に接続され、各種の情報を交換することが可能とされている。かかるネットワーク１４の一態様としては、有線または無線を問わず、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）、移動体通信網などの任意の通信網が挙げられる。なお、図２の例では、ＣＳＳシステム１０は、発注者端末１２および受注者端末１３をそれぞれ１つ有する場合を例示したが、開示のシステムはこれに限定されず、発注者端末１２および受注者端末１３は任意の数とすることができる。なお、本実施形態では、サーバ１１が本発明の業務仲介装置に対応する。
【００１７】
サーバ１１は、発注された業務を仲介する装置である。サーバ１１は、例えば、サーバコンピュータなどのコンピュータである。サーバ１１は、１台のコンピュータとして実装してもよく、また、複数台のコンピュータによるクラウドとして実装することもできる。なお、本実施形態では、サーバ１１を１台のコンピュータとした場合を例として説明する。サーバ１１は、発注された業務を仲介するサービスを提供する。例えば、サーバ１１は、発注された複数の業務を、不特定多数の受注者に委託するクラウドソーシングのＷｅｂサービスを提供する。サーバ１１は、業務の発注を発注者端末１２から受け付ける。サーバ１１は、発注された複数の業務を、他の端末から参照可能に公開し、公開された業務に対する成果物の納入を受け付ける。例えば、サーバ１１は、発注された複数の業務をＷｅｂページに公開し、受注者端末１３からＷｅｂページにより公開された業務に対する成果物の納入を受け付ける。
【００１８】
発注者端末１２は、業務を発注する発注者が保持する端末装置であり、一例として、デスクトップ型ＰＣ（パーソナル・コンピュータ）、タブレット型ＰＣ、ノート型ＰＣなどの情報処理装置等である。なお、発注者端末１２は、スマートフォン、ＰＤＡ（Personal  Digital  Assistant）、携帯電話機であってもよい。発注者は、発注者端末１２を操作して、サーバ１１に対してタスクの登録を行う。タスクとは、ネットワーク１４を介して成果物を送受信できる仕事（業務）である。発注者は、サーバ１１に対して順次実行される関連する複数のタスクを登録する。この関連する複数のタスクとは、順番に実行される作業、あるいは、順番に実行されることが好ましい作業であり、例えば、複数の段階に分けられ、前の作業の結果を用いて次の作業が実行される各段階の作業である。一例として、英文を段落毎や一文毎など所定の単位に分けた文章毎に順に翻訳する文章毎の翻訳の作業や、ホームページなどからの情報の抽出、抽出した情報を用いて次の作業を行う場合などが挙げられる。タスクの登録は、サーバ１１により提供されるＷｅｂページに対する入力操作によって実施することができる。例えば、発注者は、サーバ１１にログインした後に、当該Ｗｅｂページ上で、タスクの作業内容や、タスクの種別、作業時間の目安、依頼するタスクの内容を示すタスクデータなど、タスクについての情報を入力することで、タスクをサーバ１１に登録する。このタスク登録の際に、発注者は、タスクの処理費用を支払うための支払情報をサーバ１１に登録する。この処理費用には、タスクの成果物に対する対価（報酬）と、サーバ１１における仲介業務の手数料とが含まれる。
【００１９】
受注者端末１３は、業務の受注を希望する受注者が保持する端末装置であり、一例として、デスクトップ型ＰＣ、タブレット型ＰＣ、ノート型ＰＣなどの情報処理装置等である。なお、受注者端末１３は、スマートフォン、ＰＤＡ、携帯電話機であってもよい。受注者は、受注者端末１３を操作して、サーバ１１により提供されるＷｅｂページ等を参照し、発注者により登録されたタスクを受注できる。なお、受注者は、タスクを受注する前に、予め、サーバ１１に受注者として登録する必要がある。この際、受注者は、当該受注者を示す識別情報や、報酬を受けるための支払情報をサーバ１１に登録する。支払情報は、受注者が現金振込を希望する場合には、振込先の情報（銀行の口座番号など）であり、ネットショッピングなどで利用可能なネットポイントを希望する場合には、受注者のユーザＩＤ等である。
【００２０】
このようなＣＳＳシステム１０では、発注者は、発注者端末１２を操作して、サーバ１１にタスクを発注（登録）できる。サーバ１１は、発注者端末１２から送信されるタスク（業務の発注情報）を取得して管理する。
【００２１】
サーバ１１に予め登録された受注者は、受注者端末１３を操作して、サーバ１１に登録されたタスクから任意のタスクの受注を要求できる。ここで、受注者は、順に公開される複数のタスクを必ずしも全て行う必要はなく、自身の都合や能力に応じて一部のタスクのみや、途中のタスクのみを行うことができる。これにより、各受注者が、それぞれ都合や能力に応じてタスクの作業を行えるため、受注者の人的資源を効率的に活用できる。サーバ１１は、受注者端末１３から受注を要求されたタスクの情報を受注者の受注者端末１３に送信する。そして、サーバ１１は、当該タスクを受注した受注者端末１３から成果物を受信し、当該成果物を発注者端末１２に納品するとともに、必要に応じて受注者に対価を支払う決済処理を実行する。
【００２２】
［３．サーバの構成］
次に、実施形態に係るサーバ１１について詳細に説明する。図３は、実施形態に係るサーバの機能的な構成の一例を示す図である。図３に示すように、サーバ１１は、通信Ｉ／Ｆ（インタフェース）部２０と、記憶部２１と、制御部２２とを有する。
【００２３】
通信Ｉ／Ｆ部２０は、ＮＩＣ（Network  Interface  Card）等のインタフェースである。通信Ｉ／Ｆ部２０は、ネットワーク１４を介して他の装置との間で各種のデータを送受信する。例えば、通信Ｉ／Ｆ部２０は、発注するタスクに関する情報などの各種のデータを発注者端末１２から受信する。また、通信Ｉ／Ｆ部２０は、発注されたタスクに対する成果物のデータなどの各種のデータを発注者端末１２へ送信する。また、通信Ｉ／Ｆ部２０は、受注者端末１３からの要求に応じて、クラウドソーシングのＷｅｂページのデータを要求元の受注者端末１３へ送信する。また、通信Ｉ／Ｆ部２０は、タスクに対する成果物のデータを受注者端末１３から受信する。
【００２４】
記憶部２１は、各種情報を記憶するデバイスである。例えば、記憶部２１としては、ＲＡＭ（Random  Access  Memory）、フラッシュメモリなどの半導体メモリ素子や、ハードディスク、光ディスクなどの記憶装置が挙げられる。
【００２５】
記憶部２１は、制御部２２で実行されるＯＳ（Operating  System）や、後述する業務仲介処理を実行するプログラムを含む各種プログラムを記憶する。さらに、記憶部２１は、各種情報を記憶する。例えば、記憶部２１は、発注者情報３０と、受注者情報３１と、タスク情報３２と、成果物情報３３とを記憶する。
【００２６】
発注者情報３０は、発注者に関する情報がテーブル形式で記憶されたデータである。発注者情報３０には、発注者端末１２から登録された発注者についての情報が格納され、管理される。図４は、実施形態に係る発注者情報のデータ構成の一例を示す図である。図４に示すように、発注者情報３０は、「発注者ＩＤ」、「発注者名」、「発注者端末識別情報」、「支払情報」の各項目を有する。
【００２７】
発注者ＩＤの項目は、発注者を識別する識別情報を記憶する領域である。発注者や受注者などＣＳＳシステム１０を利用するユーザには、それぞれを識別する識別情報としてユーザＩＤが付与される。発注者ＩＤの項目には、発注者のユーザＩＤが格納される。発注者名の項目は、発注者の名称を記憶する領域であり、例えば、個人名、団体名、企業名などの発注者名が格納される。発注者端末識別情報の項目は、発注者の発注者端末１２を識別する識別情報を格納する領域であり、例えば、識別情報として、発注者端末１２のＩＰアドレスが格納される。支払情報の項目は、報酬や手数料を支払うための各種の情報を格納する領域であり、例えば、銀行の口座番号等の対価の支払元の情報が格納される。本実施形態では、後述するように、タスクを登録する場合に、その処理費用も前払いで支払うため、支払情報として予め口座番号などを登録しておき、サーバ１１側が口座引き落としなどで支払いを受けることができるように設定されている。
【００２８】
受注者情報３１は、受注者に関する情報がテーブル形式で記憶されたデータである。受注者情報３１には、受注者端末１３から登録された受注者についての情報が格納され、管理される。図５は、実施形態に係る受注者情報のデータ構成の一例を示す図である。図５に示すように、受注者情報３１は、「受注者ＩＤ」、「受注者名」、「受注者端末識別情報」、「支払情報」の各項目を有する。
【００２９】
受注者ＩＤの項目は、受注者を識別する識別情報を記憶する領域であり、例えば、識別情報として、受注者のユーザＩＤが格納される。受注者名の項目は、受注者の名称を記憶する領域であり、例えば、個人名、団体名、企業名などの受注者名が格納される。受注者端末識別情報の項目は、受注者の受注者端末１３を識別する識別情報を格納する領域であり、例えば、ＩＰアドレス等の受注者端末１３を識別する識別情報が格納される。支払情報の項目は、支払われた報酬等を受け取るための各種の情報を格納する領域であり、例えば、銀行の口座番号等の対価の振込先の情報が格納される。
【００３０】
タスク情報３２は、発注者端末１２から登録されたタスクに関する情報がテーブル形式で記憶されたデータである。タスク情報３２には、発注者端末１２から登録されたタスクについての情報が格納され、管理される。図６は、実施形態に係るタスク情報のデータ構成の一例を示す図である。図６に示すように、タスク情報３２は、「タスク番号」、「発注者ＩＤ」、「業務分野」、「業務内容」、「作業時間」、「タスクデータ」、「報酬」、「状況」、「納品情報」、「成果物ＩＤ」、「関連タスク」の各項目を有する。
【００３１】
タスク番号の項目は、タスクを識別する識別情報を記憶する領域である。タスクには、それぞれを識別する識別情報としてタスク番号が付与される。タスク番号の項目には、登録されたタスクに付与されたタスク番号が格納される。発注者ＩＤの項目は、タスクを依頼した発注者の識別情報を記憶する領域であり、例えば、発注者のユーザＩＤが格納される。業務分野の項目は、発注されたタスクの種別（業務分野）を記憶する領域であり、例えば、発注されたタスクがどのような作業であるかを示す種別が格納される。作業時間の項目は、目安の作業時間を記憶する領域であり、例えば、発注されたタスクの作業にかかる目安の作業時間が格納される。タスクデータの項目は、タスクの内容を記憶する領域であり、例えば、発注されたタスクの内容を示すタスクデータが格納される。報酬の項目は、タスクに対する報酬を記憶する領域であり、例えば、タスクの仕事を実行した受注者に対して支払う報酬が格納される。状況の項目は、タスクの状況を示す情報を記憶する領域であり、例えば、タスクの状況として、タスクが公開された状況であるか、成果物を受け付ける受付中の状況であるか、成果物の受け付けを終了した受付終了であるかが格納される。納品情報の項目は、発注者に対して成果物が納品済みであるか否かの情報を記憶する領域であり、例えば、納品済みである場合、納品済みであることを示す情報が格納される。成果物ＩＤは、発注者に納品した成果物の識別情報を格納する領域である。受注者から納品された成果物には、成果物を識別するための識別情報として成果物ＩＤが付与される。成果物ＩＤの項目には、発注者に納品した成果物の成果物ＩＤが格納される。関連タスクの項目は、タスクに関連するタスクの識別情報を記憶する領域であり、例えば、タスクに関連付けて実施するタスクのタスク番号が格納される。
【００３２】
成果物情報３３は、タスクに対する成果物に関する情報がテーブル形式で記憶されたデータである。タスク情報３２には、受注者端末１３から受け付けたタスクに対する成果物についての情報が格納され、管理される。図７は、実施形態に係る成果物情報のデータ構成の一例を示す図である。図７に示すように、成果物情報３３は、「成果物ＩＤ」、「納品日時」、「タスク番号」、「受注者ＩＤ」、「成果物」、「チェック結果」の各項目を有する。
【００３３】
成果物ＩＤの項目は、受注者から納品された成果物の識別情報を格納する領域であり、例えば、納品された成果物に付与された成果物ＩＤが格納される。納品日時の項目は、成果物の納品日時を記憶する領域であり、例えば、受注者端末１３から成果物を受け付けた日付および時刻が格納される。タスク番号の項目は、タスクを識別する識別情報を記憶する領域であり、例えば、受注者から納品された成果物のタスクのタスク番号が格納される。成果物の項目は、受注者から納品された成果物のデータを格納する領域であり、例えば、成果物のデータそのものや、成果物のデータの格納先など成果物のデータへのリンク先の情報が格納される。チェック結果の項目は、成果物に対するチェック結果のデータを格納する領域であり、例えば、チェック結果が合格の場合、チェック結果が合格であることを示す情報が格納される。
【００３４】
図３に戻り、制御部２２は、サーバ１１を制御するデバイスである。例えば、制御部２２としては、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等の電子回路や、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路を採用できる。
【００３５】
制御部２２は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部２２は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部２２は、管理部４０と、公開部４１と、受付部４２と、決定部４３と、チェック部４４と、送信部４５と、決済部４６とを有する。
【００３６】
管理部４０は、発注者端末１２および受注者端末１３から各種の情報の登録を受付け、登録された情報を管理する。例えば、管理部４０は、発注者についての情報の登録を発注者端末１２から受け付け、発注者についての情報を発注者情報３０を用いて管理する。具体的に、管理部４０は、発注者のユーザＩＤ、発注者の発注者名、発注者端末１２のＩＰアドレス、および、手数料を支払うための支払情報等の各種情報を発注者情報３０に登録する。本実施形態では、後述するように、タスクを登録する場合に、その処理費用も前払いで支払うため、支払情報として予め口座番号などを登録しておき、サーバ１１側が口座引き落としなどで支払いを受けることができるように設定されている。
【００３７】
また、管理部４０は、受注者についての情報を受注者端末１３から受け付け、受注者についての情報を受注者情報３１を用いて管理する。具体的に、管理部４０は、受注者のユーザＩＤ、受注者の受注者名、受注者端末１３のＩＰアドレス、および、対価を受けるための支払情報等の各種情報を受注者情報３１に登録する。
【００３８】
また、管理部４０は、発注するタスクについての情報を発注者端末１２から受け付け、発注するタスクについての情報をタスク情報３２を用いて管理する。具体的に、管理部４０は、発注されたタスクのタスク番号、当該タスクを発注した発注者のユーザＩＤ（発注者ＩＤ）、タスクがどのような作業であるかを示す種別、依頼するタスクの情報、タスクの作業内容、作業時間の目安、タスクデータ、および、タスクの対価（報酬）等の各種情報を、タスク情報３２に登録する。
【００３９】
公開部４１は、発注された複数のタスクを受注者端末１３から参照可能にＷｅｂページに公開する。例えば、公開部４１は、発注された関連する複数のタスクを１つずつ順に、成果物を納入可能な状態としてＷｅｂページに公開する。
【００４０】
図８は、公開されるＷｅｂページの一例を示す図である。図８は、関連する複数のタスクを１つずつ順に成果物を納入可能な状態として公開するタスク公開画面の一例を示している。タスク公開画面５０には、発注されたタスクを表示する表示領域５１が設けられている。表示領域５１は、発注されたタスクに関する情報を一覧表示する領域である。
【００４１】
表示領域５１は、発注されたタスクに関する情報を表示する領域として、「タスク」、「１タスクのめやす」、「報酬」、「状況」の各項目を有する。タスクの項目は、タスクの作業内容を表示する領域であり、タスク情報３２の業務内容の項目の情報が表示される。１タスクのめやすの項目は、タスクの作業にかかる時間の目安を表示する領域であり、タスク情報３２の作業時間の項目の情報が表示される。報酬の項目は、タスクの作業により得られる報酬を表示する領域であり、タスク情報３２の報酬の項目の情報が表示される。状況の項目は、タスクの状況を表示する領域であり、タスク情報３２の状況の項目の情報が表示される。
【００４２】
図８の上側の例では、「ＸＸＸ翻訳（その１）」、「ＸＸＸ翻訳（その２）」、「ＸＸＸ翻訳（その３）」・・・と複数のタスクが表示されている。「ＸＸＸ翻訳（その１）」は、状況が受付中とされ、タスクの作業内容の表示およびタスクに対する成果物の納入可能な状態とされている。「ＸＸＸ翻訳（その２）」および「ＸＸＸ翻訳（その３）」は、状況が公開とされ、タスクの作業内容の表示が可能な状態とされている。図８の下側は、次のタスクが納入可能な状態としてＷｅｂページに公開された状態を示している。「ＸＸＸ翻訳（その１）」は、受付けが終了している。「ＸＸＸ翻訳（その２）」は、状況が受付中とされ、タスクの作業内容の表示およびタスクに対する成果物の納入可能な状態とされている。
【００４３】
受注者は、受注者端末１３を操作して、サーバ１１にアクセスし、タスク公開画面５０を表示させる。そして、受注者は、状況が受付中のタスクの作業を希望する場合、受注者端末１３を操作して、表示領域５１から状況が受付中のタスクを選択する。
【００４４】
公開部４１は、タスク公開画面５０でタスクが選択されると、選択されたタスクに関する情報を表示したＷｅｂページを生成して受注者端末１３へ送信し、選択されたタスクに関する情報を表示したＷｅｂページを受注者端末１３に表示させる。
【００４５】
図９は、タスクに関する情報を表示したＷｅｂページの一例を示す図である。図９は、翻訳を依頼するタスクを表示させタスク画面６０の一例を示している。タスク画面６０は、翻訳対象の英文を表示する表示領域６１と、成果物とする翻訳文を入力する入力領域６２と、翻訳文の納品を指示する納品ボタン６３が設けられている。
【００４６】
受注者は、受注者端末１３を操作して、タスクの作業を行って成果物を納品する。例えば、タスクが図９の示す作業の場合、受注者は、受注者端末１３を操作して、表示領域６１に表示された英文の翻訳文を入力領域６２に入力し、納品ボタン６３を選択する。
【００４７】
受付部４２は、公開されたタスクに対する成果物の納入を受注者端末１３から受け付ける。受付部４２は、受付けた成果物に関する情報を成果物情報３３に登録する。
【００４８】
決定部４３は、受付部４２で受け付けた成果物から報酬を支払う対象の成果物を決定する。決定部４３は、成果物が納入されるまでの時間に基づいて報酬を支払う対象の成果物を決定しており、最初に納品された成果物を報酬を支払う支払対象の成果物と決定する。すなわち、タスクの作業に対して最初に納品された成果物が発注者による報酬の支払い対象となる。
【００４９】
ところで、単純に、最初に納品された成果物が発注者による報酬の支払い対象とした場合、作業スピードを優先するあまり、品質の低い成果物が納品される場合がある。
【００５０】
そこで、チェック部４４は、受付部４２により受け付けた成果物が所定の基準を満たしているか否かをチェックする。決定部４３は、チェック部４４によるチェックの結果、所定の基準が満たされていると判定された成果物から報酬を支払う対象の成果物を決定する。例えば、決定部４３は、所定の基準が満たされていると判定された成果物のうち、最初に納品された成果物を支払対象の成果物と決定する。
【００５１】
例えば、タスクが、複数の選択肢から回答を選択する作業や、問題に対して回答を入力する作業である場合、タスクに予め正答が定まっているダミー問題を含める。チェック部４４は、受付部４２により受け付けた成果物に含まれるダミー問題の回答が正答に一致している場合に、所定の基準が満たされていると判定する。
【００５２】
また、チェック部４４は、タスクに対する成果物が複数の受注者から納品された場合、各成果物を比較し、成果物同士の一致数または一致率が所定値以上の場合に、所定の基準が満たされていると判定してもよい。例えば、タスクが、商品についての商品名および型番等の文字列を調べて入力するものである場合、チェック部４４は、複数の受注者による成果物の一致数（一致率）に基づいて、成果物が所定の基準を満たしているか、つまり成果物を納品可能か否かを判定する。そして、チェック部４４は、当該一致数（一致率）が所定値を超えている成果物を、所定の基準を満たして発注者に納品可能な成果物とする。例えば、チェック部４４は、一致数として「３」が設定されている場合、３人以上の受注者からの成果物が一致すると、所定の基準を満たしている（納品可能）と判定する。また、チェック部４４は、一致率として７５％と設定されている場合、例えば４人の受注者からの成果物のうち、３つ以上が一致している場合には、３／４＝７５％となるため、所定の基準を満たしている（納品可能）と判定する。
【００５３】
なお、例えば、文章を入力する場合等、タスクの内容によっては、回答（成果物）が一致しにくい場合も考えられる。この場合は、繰り返し回数（成果物の一致に必要な試行錯誤の回数）を変化させて、チェックの合格のし易さ、つまり納品のし易さをコントロールしても良い。例えば、「James」の日本語表記を入力する作業を依頼した場合、回答として、「ジェームズ、ジェイムズ、ジェームス、ジェイムス」のように複数の答えがありえる。この場合、受注者に１つの回答しか認めないと、他の受注者の回答と表記が異なる場合も回答が一致しないと判定することになる。
【００５４】
そこで、受注者に複数回の回答を認めたり、あるいは一度に複数の回答入力を許可し、複数の回答のうちのどれかが他の受注者の回答と一致すればよいルールとすれば、一致の難易度が下がり、所定の基準を満たしていると判定しやすくなり、納品もしやすくなる。
【００５５】
また、チェック部４４は、タスクの内容つまり業務分野に応じて、成果物のチェックをタスクとして依頼してもよい。例えば、図９に示したタスクのように、翻訳のなどの業務分野では、受注者が翻訳文等の文字列を入力する必要があり、複数の解答が得られてしまう。このように複数の解答が得られるタスク（一次タスク）については、チェックを依頼する新規のタスク（二次タスク）を生成して、チェックを行うようにしてもよい。例えば、チェック部４４は、納品された成果物のタスクの関連タスクとして、成果物のチェックを要求するタスクをタスク情報３２に登録する。図１０は、成果物のチェックを要求するタスクを表示したＷｅｂページの一例を示す図である。図１０の例は、図９のタスク画面６０で納品された成果物のチェックを要求するタスク画面７０の一例を示している。タスク画面７０は、翻訳対象の英文および納品された翻訳文を表示する表示領域７１と、チェック結果を選択するラジオボタン７２、７３と、チェック結果の納品を指示する納品ボタン７４が設けられている。
【００５６】
受注者は、受注者端末１３を操作して、タスクの作業を行ってチェック結果を納品する。例えば、タスクが図１０の示す作業の場合、受注者は、受注者端末１３を操作して、翻訳文のチェック結果に応じてラジオボタン７２、７３の何れかを選択して、納品ボタン７４を選択する。
【００５７】
チェック部４４は、品質をチェックする二次タスクの成果物に基づいて、一次タスクの成果物が所定の基準を満たしている（納品可能）か否かを判定する。この二次タスクは、不特定多数の受注者により受注可能であるが、二次タスクを、先のタスク（一次タスク）の受注者は受注することはできないようにする。
【００５８】
そして、チェック部４４は、二次タスクの成果物として「きちんと翻訳されている」旨の解答（つまり合格判定）が設定された成果物が所定値を超える一致率（一致数）で取得された場合には、評価対象となった成果物を所定の基準を満たしている、つまり発注者に納品可能な成果物と判定する。
【００５９】
送信部４５は、支払対象の成果物を、当該成果物のタスクを発注した発注者端末１２に送信する。例えば、送信部４５は、タスク情報３２から、該当するタスクに関連付けられた発注者のユーザＩＤを取得し、当該ユーザＩＤに基づいて発注者情報３０を参照して、当該タスクを発注した発注者端末１２の発注者端末識別情報を特定する。そして、当該発注者端末識別情報に基づいて、該当するタスクの成果物を発注者端末１２に送信する。なお、成果物情報３３に登録される成果物に、前述のダミー問題が含まれている場合には、当該ダミー問題に対する解答は削除された成果物を送信する。
【００６０】
また、送信部４５は、成果物を発注者端末１２に送信すると、該当するタスクの成果物を納品した旨の情報、および、当該成果物の成果物ＩＤを、タスク情報３２に登録する。
【００６１】
決済部４６は、タスクの発注および受注に伴う決済処理を実施する。例えば、決済部４６は、タスクの発注が行われた際に、当該タスクの処理費用（報酬＋手数料）を発注者から事前に受け取る処理を実行する。また、決済部４６は、タスクが受注されなかった場合には、発注者に対して処理費用の返還処理を実行する。一方、決済部４６は、タスクが受注され、受注者端末１３から送信された成果物をチェックし、チェックに合格して発注者端末１２に納品した場合には、当該成果物を送信した受注者に対して報酬の支払処理を実行する。
【００６２】
［４．業務仲介処理］
次に、本実施形態に係るＣＳＳシステム１０によりタスクを仲介する業務仲介処理の流れを説明する。図１１は、実施形態に係る業務仲介処理の手順の一例を示すフローチャートである。
【００６３】
図１１に示すように、サーバ１１では、公開部４１が、発注された関連する複数のタスクを順に１つ成果物を納入可能な状態としてＷｅｂページに公開する（Ｓ１０）。
【００６４】
受注者は、受注者端末１３を操作して、サーバ１１にアクセスして公開中のタスクを参照する（Ｓ１１）。そして、受注者は、状況が受付中のタスクの作業を希望する場合、受注者端末１３を操作して、タスクの作業を行って成果物を納品する（Ｓ１２）。
【００６５】
サーバ１１では、チェック部４４が、納品された成果物が所定の基準を満たしているか否かをチェックする（Ｓ１３）。決定部４３は、所定の基準が満たされていると判定された成果物のうち、最初に納品された成果物を支払対象の成果物と決定する（Ｓ１４）。
【００６６】
公開部４１が、支払対象が決定したタスクの公開を終了する（Ｓ１５）。決済部４６は、支払対象とされた成果物を送信した受注者に対して報酬の支払処理を実行する（Ｓ１６）。
【００６７】
公開部４１は、成果物を受け付け可能にする次のタスクがあるか否か判定する（Ｓ１７）。次のタスクがある場合（Ｓ１７肯定）、上述のＳ１０の処理へ移行して次のタスクを公開する。一方、次のタスクがない場合（Ｓ１７否定）、処理を終了する。以上により、業務仲介処理が終了する。なお、Ｓ１５、Ｓ１６の順序は、入れ替えてもよい。例えば、報酬の支払処理を実行した後に、支払対象が決定したタスクの公開を終了してもよい。
【００６８】
［５．その他］
上記実施形態において、サーバ１１は、発注された複数のタスクのうち、並列に実行可能な２以上のタスクを並列して成果物を納入可能な状態に公開し、公開したタスクに対する成果物の納入を並列に受け付けてもよい。図１２は、発注者から発注された業務を並列に不特定多数の人に委託する流れを模式的に示した図である。業務仲介装置は、発注者から業務の発注を受け付けており、発注された複数の業務を、複数個ずつ並列に当該業務の受注を希望する複数の受注者の各端末から参照可能に公開する。そして、業務仲介装置は、公開された業務に対する成果物の納入を受け付ける。図１２の上側の例では、タスクＡ１、Ａ２、Ａ３、Ａ４・・・と複数の業務が並列に成果物を納入可能な状態とされている。業務仲介装置は、成果物を納入可能な状態の各タスクについて成果物の納品を受け付ける。
【００６９】
業務の受注を希望する複数の受注者は、公開された業務を参照して当該業務に応じた作業を行い、それぞれ成果物を納品する。図１２の上側の例では、受注者Ａ、Ｂ、Ｃ・・・がタスクＡ１に応じた作業を行い、それぞれ成果物を納品している。
【００７０】
業務仲介装置は、各タスクについてそれぞれ受け付けた成果物から報酬を支払う対象の成果物を決定する。例えば、業務仲介装置は、タスク毎に、成果物が納入されるまでの時間に基づいて報酬を支払う対象の成果物を決定する。一例として、業務仲介装置は、タスク毎に、最初に納品された成果物を、報酬を支払う支払対象の成果物と決定する。
【００７１】
業務仲介装置は、支払対象の成果物が決定すると、支払対象が決定した業務に対する成果物の受け付けを終了する。業務仲介装置は、支払対象の成果物を納品した受注者へ報酬を支払う。また、業務仲介装置は、次に並列に実行可能な業務を公開し、公開された業務に対する成果物の納入を受け付ける。図１２の下側の例では、タスクＡ１、Ａ２、Ａ３、Ａ４・・・の支払対象の成果物が決定して成果物の受け付けを終了し、次のタスクＢ１、Ｂ２、Ｂ３、Ｂ４・・・が公開されており、タスクＢ１に対して受注者Ａ、Ｂ、Ｃ・・・が成果物を納品している。
【００７２】
このように、実施形態に係る業務仲介装置は、発注された複数の業務を所定個ずつ順に成果物を納入可能な状態に公開する場合でも、各受注者が、それぞれ都合や能力に応じて業務を行えるため、受注者の人的資源を効率的に活用できる。
【００７３】
ここで、実施形態に係る業務仲介装置は、ＯＳなどで用いられる複数のＣＰＵに対してタスクを割り当てるタスク制御の考えを用いて複数の業務を受注者に効率的に配分している。なお、実施形態に係る業務仲介装置は、単純にタスク制御を適用したものではない。一般的なタスク制御では、処理待ちのＣＰＵに対して早い順に各データ（タスク）を割り当てている。この考え方を単純に適用した場合、タスクを実行する受注者がＣＰＵとなり、データがタスクとなる。しかし、実施形態に係る業務仲介装置は、このようなモデルとは異なり、例えば、図１に示すようにタスクＡ〜Ｄ・・・をＣＰＵと見なし、受注者をデータと見なしており、タスクに対して複数の受注者が作業を行い、納品物を納品している。すなわち、実施形態に係る業務仲介装置は、従来のタスク制御とは逆の考え方を適用して人的資源の効率化を図ったものである。また、図１２についても、例えば、Ｈａｄｏｏｐなどの分散処理の考え方を適用しているが、従来の分散処理とは逆にタスクをＣＰＵと見なし、受注者をデータと見なして分散処理の考え方を適用して人的資源の効率化を図ったものである。すなわち、実施形態に係る業務仲介装置は、タスク制御や分散処理を単純に適用したものではない。
【００７４】
また、上記実施形態において、サーバ１１は、発注された複数のタスクを公開し、順に成果物を納入可能な状態にしているが、成果物を納入可能な状態とするタスクを順に公開するようにしてもよい。
【００７５】
また、上記実施形態において、順に成果物を納入可能な状態とする複数のタスクがそれぞれ、前のタスクの結果を用いた方がよいものである場合、サーバ１１は、２段目以降のタスクを公開する際にそれぞれ前のタスクの成果物を共に表示させてもよい。例えば、複数のタスクが英文を所定の単位に分けて順に翻訳するものである場合、前のタスクでの翻訳結果を表示させてもよい。これにより、受注者は、前のタスクの翻訳結果を参照して用語などを一致させて翻訳を行えるため、各タスクで翻訳された翻訳文での用語等のブレを抑制でき、翻訳の質を高めることができる。
【００７６】
また、上記実施形態において、複数のタスクにより翻訳を行う場合に、チェック部４４は、２段目以降のタスクについて、前のタスクでの翻訳結果を用いて成果物が所定の基準を満たしているか否かをチェックしてもよい。例えば、チェック部４４は、前のタスクでの翻訳結果から名詞などの特定の単語に対して用いられた用語を抽出し、成果物に同一の用語が用いられていることにより成果物が所定の基準を満たしているか否かをチェックしてもよい。
【００７７】
また、あまりに早く納品された成果物は、作業スピードを優先するあまり、品質の低い場合がある。そこで、上記実施形態において、成果物を納入可能な状態とされてから所定の期間内で最初に納品された成果物を支払対象の成果物と決定してもよい。この所定の期間は、発注者が設定してもよい。また、所定の期間は、例えば、タスクの作業にかかる目安の時間を基準として定めてもよい。例えば、所定の期間を目安の時間の前後所定の割合（例えば、５割）の範囲とする。これにより、品質の低い納品物が支払対象となることを抑制できる。
【００７８】
上記実施形態において、タスクを受注した受注者は、受信されたタスクの成果物をサーバ１１に送信するものとしたが、この際、サーバ１１において、タスクを送信してから成果物が受信されるまでの間に制限時間を設けてもよい。この場合、サーバ１１は、制限時間内に成果物が受信されなかった場合には、受注者による該当するタスクの受注を取り消してもよい。このようにすれば、特に、複数の受注者の成果物の一致数（一致率）で判定する場合に、受注者同士で連絡を取り合って、回答が正しくない成果物を複数送信することで一致数を確保しようとする不正行為が発生するリスクを軽減できる。
【００７９】
上記実施形態において、ダミー問題を用いた正解チェック、複数の成果物による一致チェック、および、二次タスクによる品質チェックの一部または全部を組み合わせて多重にチェックを行ってもよい。これにより、成果物の品質をより一層向上させることができる。
【００８０】
［６．効果］
このように、サーバ１１は、発注された複数の業務を順に、複数の受注者の各受注者端末１３から成果物を納入可能な状態に公開する。サーバ１１は、成果物を納入可能な状態とされた業務に対する成果物の納入を各受注者端末１３から受け付ける。そして、サーバ１１は、受け付けた成果物から報酬を支払う対象の成果物を決定する。これにより、サーバ１１は、受注者の人的資源を効率的に活用できる。
【００８１】
また、サーバ１１は、成果物が納入されるまでの時間に基づいて報酬を支払う対象の成果物を決定する。これにより、サーバ１１は、品質の低下を抑制しつつ、複数の業務の成果物を早く得ることができる。
【００８２】
また、サーバ１１は、最初に納品された成果物を報酬を支払う対象の成果物と決定する。これにより、サーバ１１は、複数の業務の成果物を早く得ることができる。
【００８３】
また、サーバ１１は、複数の業務を所定個ずつ順に成果物を納入可能な状態に公開する。これにより、サーバ１１は、複数の業務を複数の受注者により分散して行えるため、受注者の人的資源を効率的に活用できる。
【００８４】
また、サーバ１１は、受け付けた成果物が所定の基準を満たしているか否かをチェックする。サーバ１１は、所定の基準が満たされていると判定された成果物から報酬を支払う対象の成果物を決定する。これにより、発注者は、一定以上の品質の成果物を得ることができる。この際、発注者自身が成果物の品質チェックを行って納品の可否を判断する必要がないため、発注者の負担も軽減できる。また、受注者は、チェックに合格すれば、成果物を納品できるので、発注者の恣意的な判断で納品が拒絶されることを防止できる。
【００８５】
また、サーバ１１は、受注者の受注者端末１３に対し、予め正答が定まっているダミー問題を送信し、受注者端末１３から返信された回答が正答に一致している場合に、所定の基準が満たされていると判定する。これにより、サーバ１１は、ダミー問題を混在させてその結果で品質チェックを行えば、ダミー問題の回答が正答であるか否かのみをチェックすればよいため、チェック処理を容易に実行できる。さらに、ダミー問題の難易度や内容を設定することで、受注者のレベル等も判定でき、発注者の望むレベルの受注者から成果物を得ることができる。
【００８６】
また、サーバ１１は、業務に対する成果物が複数の受注者の端末から受付けた際に、前記各成果物を比較し、成果物同士の一致数または一致率が所定値以上の場合に、前記所定の基準が満たされていると判定する。これにより、サーバ１１は、ダミー問題を混在させなくても、複数の受注者の成果物の一致数や一致率から成果物の品質を判定できる。従って、従来、チェック担当者が品質チェックを行っていたテキスト入力形式のタスクを、サーバ１１が自動的に品質チェックすることができる。
【００８７】
また、上述したサーバ１１は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application  Programming  Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
【００８８】
また、特許請求の範囲に記載した「手段」は、「部（section、module、unit）」や「回路」などに読み替えることができる。例えば、決定手段は、決定部や決定回路に読み替えることができる。
【符号の説明】
【００８９】
１０  クラウドソーシングサービスシステム
１１  サーバ
１２  発注者端末
１３  受注者端末
２１  記憶部
２２  制御部
３０  発注者情報
３１  受注者情報
３２  タスク情報
３３  成果物情報
４０  管理部
４１  公開部
４２  受付部
４３  決定部
４４  チェック部
４５  送信部
４６  決済部
【図１】
2014153756.tif 000003
【図２】
2014153756.tif 000004
【図３】
2014153756.tif 000005
【図４】
2014153756.tif 000006
【図５】
2014153756.tif 000007
【図６】
2014153756.tif 000008
【図７】
2014153756.tif 000009
【図８】
2014153756.tif 000010
【図９】
2014153756.tif 000011
【図１０】
2014153756.tif 000012
【図１１】
2014153756.tif 000013
【図１２】
2014153756.tif 000014