JP2017037605A - 情報処理装置及び情報処理プログラム - Google Patents

Abstract

【課題】クラウドソーシングシステムのワーカーに対し、そのワーカーの受注可能なタスクの規模に応じて分割されたタスクを提示するようにした情報処理装置を提供する。【解決手段】情報処理装置の算出手段は、クラウドソーシングシステムに登録されたワーカーの受注履歴から該ワーカーの受注可能なタスクの規模を算出し、分割手段は、タスクを前記算出手段によって算出された規模に応じて分割し、提示手段は、前記ワーカーに前記分割されたタスクを提示する。【選択図】図１

Description

本発明は、情報処理装置及び情報処理プログラムに関する。

特許文献１には、複数種類のサービスからのタスクを、特定種類のサービスからのタスクの作業の遅れをなくして配分することを課題とし、タスク配分サーバーは、複数種類のサービスの各々について、ユーザーのサービスからのタスクの実行履歴からユーザーの興味度の推定値と該推定値の不確かさを算出し、ログインしたユーザーに対し、複数種類のサービスの各々について、該サービスからのタスクを配分されている他のユーザーによりタスクが実行されていない確率を考慮して、興味度の推定値と該推定値の不確かさに基づきサービスからのタスクの優先度を算出し、最大の優先度のサービスからのタスクをユーザーに提示することが開示されている。

特許文献２には、タスクの予定管理を有効に行えるスケジュール管理装置、スケジュール管理方法及びプログラムを提供することを課題とし、ユーザーの予定上の空き時間にコンテキスト推定ルールを適用してコンテキストを推定し、タスクテンプレートに基づいて、タスク入力手段により入力されたタスクを複数のサブタスクに分割し、コンテキストとタスクのメタデータとの関係により遂行すべきタスクを推薦するタスク推薦ルールを列挙された該ユーザーの空き時間に適用し、該空き時間のコンテキスト及びサブタスクのメタデータに基づいて該空き時間に遂行すべきタスクを推薦し、推薦されたタスクを予定として管理することが開示されている。

特許文献３には、タスクリストとスケジュール表という個人スケジュールを管理するツールを用いて効率的にスケジュール管理を行うことを支援するスケジューリング支援システムを提供することを課題とし、タスクリストにあるタスクを、スケジュールに展開する手段を提供し、その際、スケジューリングを支援する機能及び、既存の作業割付をシフトして再スケジューリングを手助けする方式を提供し、煩雑になりがちなスケジューリングを軽減することで、スケジュール展開を実施できるようにすることが開示されている。

特開２０１４−１２００３１号公報 特開２００６−１５５３６８号公報 特開２００６−１４６５３０号公報

従来技術においては、タスクを配分するために、ワーカーの興味度をもとにタスクを配分し、ワーカーにタスクを提示することが行われている。また、ワーカーのスケジュール情報をもとに空き時間にタスクを割り当てることが行われている。
しかし、タスクを配分するにあたって、タスクの規模とワーカーの実施可能なタスクの規模とのマッチングが重要であるが、これらの観点が従来技術にはない。そして、ワーカーのスケジュール情報を取得すること自体が困難であり、そもそもスケジュール情報はワーカーの実施可能なタスクの規模を反映していない。
そこで、本発明は、クラウドソーシングシステムのワーカーに対し、そのワーカーの受注可能なタスクの規模に応じて分割されたタスクを提示するようにした情報処理装置及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。

請求項１の発明は、クラウドソーシングシステムに登録されたワーカーの受注履歴から該ワーカーの受注可能なタスクの規模を算出する算出手段と、タスクを前記算出手段によって算出された規模に応じて分割する分割手段と、前記ワーカーに前記分割されたタスクを提示する提示手段を有する情報処理装置である。

請求項２の発明は、前記ワーカーからタスクの分割要求を受け付ける受付手段をさらに有し、前記分割手段は、前記受付手段が分割要求を受け付けた場合に、前記タスクの分割処理を行う、請求項１に記載の情報処理装置である。

請求項３の発明は、前記受付手段が分割要求を受け付けた場合に、前記タスクの発注者に通知する通知手段と、前記発注者による前記タスクの分割の可否の判定結果を受け付ける第２の受付手段をさらに有し、前記分割手段は、前記第２の受付手段が分割可の判定結果を受け付けた場合に、前記タスクの分割処理を行う、請求項２に記載の情報処理装置である。

請求項４の発明は、前記分割手段は、分割されたタスクを受注可能なワーカー数が予め定められた閾値より多い又は以上になるように、分割処理を行う、請求項１から３のいずれか一項に記載の情報処理装置である。

請求項５の発明は、前記分割手段によって分割されたタスクの優先度にしたがって、前記ワーカーが受注するタスクを選定する選定手段をさらに有する請求項１から４のいずれか一項に記載の情報処理装置である。

請求項６の発明は、コンピュータを、クラウドソーシングシステムに登録されたワーカーの受注履歴から該ワーカーの受注可能なタスクの規模を算出する算出手段と、タスクを前記算出手段によって算出された規模に応じて分割する分割手段と、前記ワーカーに前記分割されたタスクを提示する提示手段として機能させるための情報処理プログラムである。

請求項１の情報処理装置によれば、クラウドソーシングシステムのワーカーに対し、そのワーカーの受注可能なタスクの規模に応じて分割されたタスクを提示することができる。

請求項２の情報処理装置によれば、ワーカーからタスクの分割要求を受け付けた場合に、タスクの分割処理を行うようにすることができる。

請求項３の情報処理装置によれば、発注者によって分割可の判定結果を受け付けた場合に、タスクの分割処理を行うようにすることができる。

請求項４の情報処理装置によれば、分割されたタスクを受注可能なワーカー数が予め定められた閾値より多い又は以上になるように、分割処理を行うようにすることができる。

請求項５の情報処理装置によれば、分割されたタスクの優先度にしたがって、ワーカーが受注するタスクを選定することができる。

請求項６の情報処理プログラムによれば、クラウドソーシングシステムのワーカーに対し、そのワーカーの受注可能なタスクの規模に応じて分割されたタスクを提示することができる。

第１の実施の形態の構成例についての概念的なモジュール構成図である。 本実施の形態を利用したシステム構成例を示す説明図である。 一般的なクラウドソーシングシステムによる処理例を示す説明図である。 第１の実施の形態による処理例を示すフローチャートである。 タスク情報テーブルのデータ構造例を示す説明図である。 ワーカー情報テーブルのデータ構造例を示す説明図である。 タスク受注履歴情報テーブルのデータ構造例を示す説明図である。 受注可能タスク情報提示画面の表示例を示す説明図である。 タスク情報テーブルのデータ構造例を示す説明図である。 第２の実施の形態の構成例についての概念的なモジュール構成図である。 第２の実施の形態による処理例を示すフローチャートである。 タスク情報テーブルのデータ構造例を示す説明図である。 受注可能タスク情報提示画面の表示例を示す説明図である。 部分受注タスク候補提示画面の表示例を示す説明図である。 第３の実施の形態の構成例についての概念的なモジュール構成図である。 第３の実施の形態による処理例を示すフローチャートである。 タスク情報テーブルのデータ構造例を示す説明図である。 第４の実施の形態の構成例についての概念的なモジュール構成図である。 第４の実施の形態による処理例を示すフローチャートである。 タスク情報テーブルのデータ構造例を示す説明図である。 算出ロジック例を示す説明図である。 受注候補サブタスク情報テーブルのデータ構造例を示す説明図である。 受注候補サブタスク情報テーブルのデータ構造例を示す説明図である。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

以下、図面に基づき本発明を実現するにあたっての好適な各種の実施の形態の例を説明する。
＜＜第１の実施の形態＞＞
図１は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態に応じて、又はそれまでの状況・状態に応じて定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、すべての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。

第１の実施の形態である情報処理装置１００は、クラウドソーシングシステムの機能を有するものであって、図１の例に示すように、タスク情報登録・更新モジュール１０５、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０を有している。特に、タスクの分割を行い、その分割されたタスク（以下、サブタスクともいう）を、ワーカー（以下、ワーカー候補者ともいう）に提示するものである。

近年、業務委託の形態としてインターネット等を介して不特定多数の人に業務を委託するクラウドソーシングが注目されている。
クラウドソーシングとは、不特定の人（クラウド、群衆等とも言われる）と業務委託（ソーシング）を組み合わせた造語であり、発注者が受注者を公募し、タスク（仕事）を発注することができる働き方の仕組みのことをいう。なお、特定の人々に作業を委託するアウトソーシングと対比される概念である。
そのクラウドソーシングを実現するために、例えば、発注者がインターネット上のウェブサイトでワーカーを公募し、仕事とワーカーとのマッチングを図る。クラウドソーシングシステムは、その処理の全般又はその一部の処理（支援処理を含む）を行うものである。

例えば、クラウドソーシングでは、発注者が仕事（タスク）の発注を行い、不特定多数のワーカーが発注されたタスクに応募し、発注者がタスクを受注するワーカー（受注者）を決定し、受注者が発注者に成果物を納品して報酬を受け取るというプロセスでやりとりが行われることが一般的である。図３に示す例を用いて、一般的なクラウドソーシングシステム（情報処理装置３００）による処理例を説明する。この例では、発注者用情報処理装置１７０とワーカー用情報処理装置１８０との間で、情報処理装置３００を介して、クラウドソーシングが行われている。なお、クラウドソーシングシステムには、特別なスキルを持たない個人から、特別なスキルを持つ専門業者まで幅広いワーカーが登録されている。
ステップＳ３０２では、発注者用情報処理装置１７０は、情報処理装置３００に対して、仕事の発注を行う。具体的には、ワーカー用情報処理装置１８０の画面に、その発注された仕事が提示される。つまり、企業側（発注者用情報処理装置１７０）は、自社では対応が困難な業務や外部発注した方が効率的な業務等をクラウドソーシングサイトである情報処理装置３００に掲載し、仕事の発注を行う。
ステップＳ３０４では、ワーカー用情報処理装置１８０は、情報処理装置３００に対して、提示された仕事への応募を行い、それが発注者用情報処理装置１７０に通知される。通知としては、発注者用情報処理装置１７０の画面への表示、電子メール、チャット、電子掲示板、ソーシャルメディアを用いた通知、プッシュ通知等であってもよい。
ステップＳ３０６では、発注者用情報処理装置１７０とワーカー用情報処理装置１８０の間で、情報処理装置３００を介して、受注者の決定（業務請負契約の締結）を行う。
ステップＳ３０８では、ワーカー用情報処理装置１８０は、情報処理装置３００を介して、発注者用情報処理装置１７０に対して、成果物の納品を行う。
ステップＳ３１０では、発注者用情報処理装置１７０は、情報処理装置３００を介して、ワーカー用情報処理装置１８０に対して、報酬の支払を行う。
このように、クラウドソーシングでは発注者が発注したタスクに対してワーカーに応募してもらうことが前提であり、登録されたワーカーに対して受注可能なタスクを提示しないと、ワーカーにタスクを受注してもらえないこととなる。

タスクを配分する場合、ワーカーの興味や能力だけでなく、タスクの業務量とワーカーの実施可能な業務量のマッチングが重要である。ワーカーの実施可能な業務量にするためにタスクを細分化することが考えられる。しかし、単なる細分化では、その細分化したタスクを複数人で担当する場合、あまり細分化しすぎると成果物のとりまとめや品質の統一などに工数がかかってしまう等の問題も発生するため、タスク全体の作業効率を維持しながら、ワーカーが受注しやすくタスクを分割することは難しい。
また、クラウドソーシングにおけるように不特定多数のワーカーを対象とする場合、企業内のワーカーと異なり、ワーカーの詳細なスケジュール情報を把握することが難しいため、ワーカーのスケジュール情報をもとにしてタスクを細分化しワーカーに提示することは難しい。
クラウドソーシングの場合、ディレクターという役割の人を置いて人手により発注されたタスクの細分化などを行うようにしてもよいが、タスクやワーカーの数が増えてきた場合、すべてのタスクに対してディレクターを配置し、ワーカーが受注しやすいようにタスクを細分化してワーカーに提示することは難しい。
なお、この説明は、ワーカーのスケジュール情報を抽出することができる場合、ディレクターという役割の人を置いた場合等において、情報処理装置１００の適用を排除するものではない。

第１の実施の形態による処理の概要を示す。第１の実施の形態では、登録されたワーカーの中から発注されたタスクを遂行可能な能力を持つ候補ワーカーを抽出し、各候補ワーカーの過去のタスクの受注履歴情報をもとに、各候補ワーカーが受注しやすいタスク規模（業務量）を推計し、複数の候補ワーカーでより効率的にタスクを遂行できるように、タスクを複数のサブタスクに分割して、分割したサブタスクを候補ワーカー毎に異なるタスク情報として提示する。
第１の実施の形態によれば、各候補ワーカーの過去のタスクの受注履歴情報をもとに、候補ワーカーの受注しやすい業務量を推計し、各候補ワーカーにあわせて受注しやすい業務量にタスクを自動分割し、候補ワーカー毎に異なる業務量のタスク情報として提示することにより、候補ワーカーがタスクを受注しやすくなり、結果的に、タスクの受注率が向上することとなる。

タスク情報登録・更新モジュール１０５は、タスク制御モジュール１１０、発注者用情報処理装置１７０、ワーカー用情報処理装置１８０と接続されている。タスク情報登録・更新モジュール１０５は、タスクの納期、報酬、受注に必要なスキルなどのタスク情報を入力・更新する。
タスク制御モジュール１１０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０を有しており、タスク情報登録・更新モジュール１０５、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０と接続されている。タスク制御モジュール１１０は、発注されたタスクをワーカーに配分し、タスクが受注されるように制御を行う。
タスク情報管理モジュール１１５は、タスク情報記憶モジュール１２０を有しており、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０と接続されている。タスク情報管理モジュール１１５は、タスク毎の情報を保持し、タスク制御モジュール１１０、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０からの要求に応じて保持したタスク情報を抽出する。

タスク分割モジュール１２５は、タスク情報管理モジュール１１５、受注タスク規模推計モジュール１３０と接続されている。タスク分割モジュール１２５は、タスクを受注タスク規模推計モジュール１３０によって算出された規模に応じて分割する。例えば、タスク情報、ワーカー情報をもとにタスク情報管理モジュール１１５内に登録されたタスクをワーカーが受注しやすいようにサブタスクに分割し、タスク情報管理モジュール１１５内に登録する。したがって、ワーカーがタスクを受注しやすくなり、タスク受注率の向上につながる。

受注タスク規模推計モジュール１３０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５と接続されている。受注タスク規模推計モジュール１３０は、クラウドソーシングシステムに登録されたワーカーの受注履歴からそのワーカーの受注可能なタスクの規模を算出する。例えば、過去のタスク受注履歴などのワーカー情報をもとにワーカーが受注しやすいタスクの規模を推計する。したがって、ワーカーが希望するタスク業務量を推計できる。「ワーカーの受注可能なタスクの規模」には、以下のものを含む。そのワーカーが受注し得る最大限のタスクの規模、そのワーカーが一般的に受注してきたタスクの規模（受注しやすいタスク規模）、そのワーカーが受注し得る最大限のタスクの規模等がある。具体的には、そのワーカーの過去の受注履歴における統計値（規模の最大値、平均値、最頻値、中央値、最小値等）を用いる。

ワーカー情報管理モジュール１３５は、ワーカー情報記憶モジュール１４０を有しており、タスク制御モジュール１１０、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー情報管理モジュール１３５は、ワーカー毎のスキル情報、過去の業務履歴などのワーカー情報を保持し、要求に応じてワーカー情報の登録・更新・抽出をする。
タスク情報提示モジュール１４５は、タスク制御モジュール１１０、ワーカー用情報処理装置１８０と接続されている。タスク情報提示モジュール１４５は、ワーカーにタスク分割モジュール１２５によって分割されたタスクを提示する。例えば、ワーカー毎に受注可能なタスク情報を提示することとなる。したがって、ワーカーがタスクを受注しやすくなり、タスク受注率の向上につながる。
ワーカー情報登録・更新モジュール１５０は、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、ワーカー用情報処理装置１８０と接続されている。ワーカー情報登録・更新モジュール１５０は、ワーカーのスキル情報、過去の業務履歴などワーカー情報管理モジュール１３５内のワーカー情報を登録・更新する。

発注者用情報処理装置１７０は、情報処理装置１００のタスク情報登録・更新モジュール１０５と接続されている。発注者用情報処理装置１７０は、発注者によって利用される端末である。
ワーカー用情報処理装置１８０は、情報処理装置１００のタスク情報登録・更新モジュール１０５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー用情報処理装置１８０は、ワーカーによって利用される端末である。
発注者用情報処理装置１７０、ワーカー用情報処理装置１８０は、例えば、通信機能を有するパーソナルコンピュータ、携帯端末（スマートフォンを含む携帯電話等）等であって、ブラウザを備えている。

前述のモジュールを有する情報処理装置１００は、発注タスクのシステムによる自動分割、提示処理を行う。
例えば、登録されたワーカーの中から発注されたタスクを遂行可能な能力を持つ候補ワーカーを抽出し、各候補ワーカーの過去の受注履歴情報をもとに候補ワーカーが受注しやすい業務量を推計し、その情報をもとにタスクをサブタスクに自動分割して、候補ワーカー毎に異なる業務量タスク（サブタスク）情報を提示する。
候補ワーカーのスキル情報をもとにそのタスクを候補ワーカーが実施した場合のタスクの実施目安時間の情報もあわせて提示することにより、候補ワーカーがより受注しやすくなる。

図２は、本実施の形態を利用したシステム構成例を示す説明図である。
情報処理装置１００、発注者用情報処理装置１７０Ａ、発注者用情報処理装置１７０Ｂ、ワーカー用情報処理装置１８０Ａ、ワーカー用情報処理装置１８０Ｂ、ワーカー用情報処理装置１８０Ｃ、ワーカー用情報処理装置１８０Ｄ、ワーカー用情報処理装置１８０Ｅは、通信回線２９０を介してそれぞれ接続されている。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。また、情報処理装置１００による機能は、クラウドサービスとして実現してもよい。

図４は、第１の実施の形態による処理例を示すフローチャートである。
ステップＳ４０２では、発注するタスクを登録する。具体的には、発注者が発注するタスクの情報をタスク情報登録・更新モジュール１０５を用いてタスク情報管理モジュール１１５に登録する。
ステップＳ４０４では、発注されたタスクを実施可能なスキルを持つワーカーを抽出する。具体的には、タスク制御モジュール１１０はワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、発注されたタスクを受注可能な候補ワーカーを抽出する。
ステップＳ４０６では、候補ワーカーの過去の受注履歴から受注しやすいタスク規模を推計する。具体的には、受注タスク規模推計モジュール１３０により、候補ワーカーの過去の受注履歴情報と納期までの作業時間などの情報をもとに候補ワーカーが受注しやすいタスク規模（業務量）を推計する。

ステップＳ４０８では、候補ワーカーの受注しやすいタスク規模情報をもとに発注されたタスクをサブタスクに分割し、タスク情報管理モジュール１１５に登録する。具体的には、タスク制御モジュール１１０は候補ワーカーの受注しやすいタスク規模情報をもとにタスク分割モジュール１２５を用いて発注されたタスクをサブタスクに分割し、タスクとしてタスク情報管理モジュール１１５に登録する。
ステップＳ４１０では、他に候補ワーカーがいるか否かを判断し、他に候補ワーカーがいる場合はステップＳ４０６へ戻り、それ以外の場合はステップＳ４１２へ進む。
ステップＳ４１２では、分割したサブタスクのタスク情報を候補ワーカーに提示する。具体的には、候補ワーカー毎に受注しやすいタスク規模の分割されたサブタスクのタスク情報をタスク情報提示モジュール１４５を用いて候補ワーカーに提示する。

次に、発注タスクの情報処理装置１００による自動分割、提示処理について、具体例を用いて説明する。
まず、発注者が発注するタスク内容や納期、報酬などのタスク情報をタスク情報登録・更新モジュール１０５を用いてタスク情報管理モジュール１１５に登録し、タスクの発注依頼を出す。
図５に、タスク情報管理モジュール１１５に登録されたタスク情報の例を示す。図５（ａ）は、タスク情報テーブル５００のデータ構造例を示す説明図である。タスク情報テーブル５００は、発注されたタスクに関する情報を記憶している。このタスク情報テーブル５００内の情報をもとに、翻訳レベルＸ（例えば、４）以上のワーカーの中から、ワーカーの翻訳処理スピードをもとにした業務遂行時間とワーカーの過去の受注履歴をもとに受注しやすい業務量に分割したサブタスクの情報を候補ワーカーに提示する。
タスク情報テーブル５００は、項目欄５０２、タスク情報欄５０４を有している。項目欄５０２は、項目を記憶している。タスク情報欄５０４は、タスク情報を記憶している。具体的には、タスク情報テーブル５００は、タスクＩＤとして「Ｔ０１０７４０」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「２０，０００文字」、タスク発注日として「２０１５／０５／１１」、成果物納期として「２０１５／０５／１５」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「５０，０００円」、親タスクＩＤとして「−」（Ｎｕｌｌ）、サブタスクＩＤとして「Ｔ０１０７４１，Ｔ０１０７４２，Ｔ０１０７４３」を記憶している。つまり、サブタスクＩＤ欄５４０は、タスク情報テーブル５１０へのリンク５４２（Ｔ０１０７４１）、タスク情報テーブル５２０へのリンク５４４（Ｔ０１０７４２）、タスク情報テーブル５３０へのリンク５４６（Ｔ０１０７４３）を記憶している。

タスク情報テーブル５１０、タスク情報テーブル５２０、タスク情報テーブル５３０は、分割されたサブタスク情報を示している。これらは、タスク情報テーブル５００と同等のデータ構造を有している。
図５（ｂ）は、タスク情報テーブル５１０のデータ構造例を示す説明図である。
タスク情報テーブル５１０は、項目欄５１２、タスク情報欄５１４を有している。項目欄５１２は、項目を記憶している。タスク情報欄５１４は、タスク情報を記憶している。タスク情報テーブル５１０は、タスクＩＤとして「Ｔ０１０７４１」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「１０，０００文字」、タスク発注日として「２０１５／０５／１１」、成果物納期として「２０１５／０５／１５」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「２５，０００円」、親タスクＩＤとして「Ｔ０１０７４０」、サブタスクＩＤとして「−」（Ｎｕｌｌ）を記憶している。
図５（ｃ）は、タスク情報テーブル５２０のデータ構造例を示す説明図である。タスク情報テーブル５２０は、項目欄５２２、タスク情報欄５２４を有している。項目欄５２２は、項目を記憶している。タスク情報欄５２４は、タスク情報を記憶している。タスク情報テーブル５２０は、タスクＩＤとして「Ｔ０１０７４２」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／ 一般文書」、タスク量として「５，０００文字」、タスク発注日として「２０１５／０５／１１」、成果物納期として「２０１５／０５／１５」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「１２，５００円」、親タスクＩＤとして「Ｔ０１０７４０」、サブタスクＩＤとして「−」（Ｎｕｌｌ）を記憶している。
図５（ｄ）は、タスク情報テーブル５３０のデータ構造例を示す説明図である。タスク情報テーブル５３０は、項目欄５３２、タスク情報欄５３４を有している。項目欄５３２は、項目を記憶している。タスク情報欄５３４は、タスク情報を記憶している。タスク情報テーブル５３０は、タスクＩＤとして「Ｔ０１０７４３」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「５，０００文字」、タスク発注日として「２０１５／０５／１１」、成果物納期として「２０１５／０５／１５」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「１２，５００円」、親タスクＩＤとして「Ｔ０１０７４０」、サブタスクＩＤとして「−」（Ｎｕｌｌ）を記憶している。

次に、タスク制御モジュール１１０は、ワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、発注されたタスクを受注可能な候補ワーカーを抽出する。図６（ａ）にワーカー情報の例を示す。ワーカー情報テーブル６００は、ワーカー情報記憶モジュール１４０に登録された「ワーカー情報」である。発注されたタスクの内容とワーカーのスキルレベルや希望報酬レベルをマッチングし、ワーカーを受注候補ワーカーにするかどうかを判定するために用いる。
図６（ａ）は、ワーカー情報テーブル６００のデータ構造例を示す説明図である。ワーカー情報テーブル６００は、項目欄６０２、ワーカー情報欄６０４を有している。項目欄６０２は、項目を記憶している。ワーカー情報欄６０４は、ワーカー情報を記憶している。ワーカー情報テーブル６００は、ワーカーＩＤとして「Ｂ００２８」、名前として「富士 太郎」、スキル情報として「翻訳」、業務可能時間帯として「１０：００〜１７：００」、希望報酬レベルとして「２，０００円／時間 以上」を記憶している。スキル情報（翻訳）欄６３０は、ワーカースキル情報テーブル６１０へのリンク６３２を記憶している。受注中のタスク情報欄６４０は、受注中タスク情報テーブル６２０へのリンク６４２を記憶している。受注タスク履歴情報欄６５０は、タスク受注履歴情報テーブル７００へのリンク６５２を記憶している。

図５の例に示すタスクでは、タスク種別が「日英翻訳／一般文書」で、受注者スキルが「日英翻訳品質レベル４以上」であるので、ワーカー情報内のワーカースキル情報からこの条件を満たすワーカーを候補ワーカーとして抽出する。図６（ｂ）にワーカースキル情報の例を示す。
図６（ｂ）は、ワーカースキル情報テーブル６１０のデータ構造例を示す説明図である。ワーカースキル情報テーブル６１０は、翻訳スキル項目欄６１２、分野欄６１４、翻訳品質レベル欄６１６、翻訳速度欄６１８を有している。翻訳スキル項目欄６１２は、翻訳スキル項目を記憶している。分野欄６１４は、分野を記憶している。翻訳品質レベル欄６１６は、翻訳品質レベルを記憶している。翻訳速度欄６１８は、翻訳速度を記憶している。
ワーカーは複数の業務スキルを保有しているので、ワーカースキル情報テーブル６１０に、業務毎にスキル情報を登録する。
この翻訳スキルの例では、図５の例で発注されたタスクが日英翻訳／一般文書で［翻訳レベル＝４以上］なので、行６６０から分かるように、このワーカーは受注候補ワーカーとなり、翻訳速度＝１０００文字／時間から発注タスクの遂行時間が推計でき、過去の発注履歴によりこのワーカーが受注しやすい業務量を算出し、サブタスクとして分割し、ワーカーに提示する。

例えば、図６（ａ）に示すワーカー情報の例では、ワーカースキル情報で「日英翻訳／一般文書」の翻訳品質レベル＝レベル４なので、このワーカー（ワーカーＩＤ＝Ｂ００２８）はこの条件にあてはまるため、候補ワーカーの一人となる。
タスク情報とワーカー情報管理モジュール１３５内に保持された候補ワーカーの過去の受注タスク履歴情報から受注タスク規模推計モジュール１３０により、ワーカーが受注しやすいタスクの規模（業務量）を推計し、そのタスク規模推計情報をもとにタスク分割を行う。図７にタスク受注履歴情報の例を示す。

図７（ａ）は、タスク受注履歴情報テーブル７００のデータ構造例を示す説明図である。タスク受注履歴情報テーブル７００は、項目欄７０２、値欄７０４を有している。項目欄７０２は、項目を記憶している。値欄７０４は、値を記憶している。タスク受注履歴情報テーブル７００は、タスクＩＤとして「Ｔ０１００４３」、発注者ＩＤとして「Ｈ００３６」、受注ワーカーＩＤとして「Ｂ００２８」、タスク種別として「日英翻訳」、発注日として「２０１４／０１／１５」、納期として「２０１４／０１／２５」、受注日として「２０１４／０１／２１」、納品日として「２０１４／０１／２５」、作業時間として「１０時間」、タスク報酬として「２０，００００円」、タスク状態として「終了」、発注者評価として「４」、タスクＩＤとして「Ｔ０１００４４」、発注者ＩＤとして「Ｈ０１４２」等を記憶している。タスク詳細欄７２０は、タスク詳細情報テーブル７１０へのリンク７２２を記憶している。
そして、図７（ｂ）は、タスク詳細情報テーブル７１０のデータ構造例を示す説明図である。タスク詳細情報テーブル７１０は、タスク詳細項目７１２、値欄７１４を有している。タスク詳細項目７１２は、タスク詳細項目を記憶している。値欄７１４は、値を記憶している。タスク詳細情報テーブル７１０は、翻訳分野として「一般文書」、タスク量として「１０，０００文字」、成果物品質として「翻訳品質レベル４」を記憶している。
タスク受注履歴情報テーブル７００は、ワーカーの過去の受注したタスク情報をワーカー情報として保持する。タスク受注履歴情報テーブル７００内から候補ワーカーの過去に受注したタスクの規模情報（タスク量、タスク処理時間）をもとに候補ワーカーが受注しやすいタスク規模を推計し、その情報をもとに元タスクを分割して、候補ワーカーに提示する。

例えば、タスク規模をワーカーの１日あたりの作業量とした場合、図７の例に示す候補ワーカー（ＩＤ＝Ｂ００２８）の過去の受注履歴情報内のタスク（タスクＩＤ＝Ｔ０１００４３）を例にとって考えると、受注日＝２０１４／１／２１と納品日＝２０１４／１／２５から作業日数は５日間であり作業時間は１０時間であることから、１日あたりの平均作業時間は２時間となる。同様の処理を候補ワーカー（ＩＤ＝Ｂ００２８）の過去の受注タスク履歴情報内の同様のタスク種別（この例では「日英翻訳」）のタスクに対して行い、候補ワーカー（ＩＤ＝Ｂ００２８）の平均の１日あたりの平均作業時間を算出する。例えば、過去の同じタスク種別の受注タスクの１日あたりの平均作業時間が２時間であった場合、この候補ワーカーの受注しやすい業務量は２時間／日の業務量と判定し、その情報をもとにタスク分割モジュール１２５によりタスクを分割する。

次に図５のタスク情報を例にとり、タスクの分割処理について説明する。
このタスク（タスクＩＤ＝Ｔ０１０７４０）のタスク作業期間は２０１５／５／１１〜２０１５／０５／１５の５日間であり、図６（ｂ）の例に示す候補ワーカー（ワーカーＩＤ＝Ｂ００２８）のワーカースキル情報の翻訳速度（１０００文字／時間）で、過去の受注タスク履歴情報から算出した受注しやすい作業時間＝２時間／日であることから、作業日数＝５日間で受注しやすい業務量は１０，０００文字の翻訳であることが推計される。
なお、候補ワーカーが他のタスクを受注中である場合には、受注できる業務量が限られるため、受注タスク規模推計モジュール１３０では、図６（ｃ）の例に示すような受注中のタスク情報をもとに現在受注中の業務量を考慮して候補ワーカーが受注しやすい業務量の推計を行う。

図６（ｃ）は、受注中タスク情報テーブル６２０のデータ構造例を示す説明図である。受注中タスク情報テーブル６２０は、項目欄６２２、受注中タスク情報欄６２４を有している。項目欄６２２は、項目を記憶している。受注中タスク情報欄６２４は、受注中タスク情報を記憶している。受注中タスク情報テーブル６２０は、受注中タスクＩＤとして「Ｔ０２１４８０」、タスク受注日として「２０１５／１／２０」、タスク納期として「２０１５／２／１０」、タスク遂行推計時間として「１０時間」を記憶している。
受注中タスク情報テーブル６２０は、ワーカーが現在受注中のタスク情報をワーカー情報として保持する。
すでに受注中のタスクがあれば、他のタスクに割ける時間が限られるため、この情報をもとにワーカーの業務可能時間を算出し、受注可能かどうかの判定に活用する。

次に、図５のタスク情報を例にとり、タスクの分割処理について説明する。
このタスク（タスクＩＤ＝Ｔ０１０７４０）のタスク作業期間は２０１５／５／１１〜２０１５／０５／１５の５日間であり、図６（ｂ）の例に示す候補ワーカー（ワーカーＩＤ＝Ｂ００２８）のワーカースキル情報の翻訳速度（１０００文字／時間）で、過去の受注タスク履歴情報から算出した受注しやすい作業時間＝２時間／日であることから、作業日数＝５日間で受注しやすい業務量は１０，０００文字の翻訳であることが推計される。
なお、候補ワーカーが他のタスクを受注中である場合には、受注できる業務量が限られるため、受注タスク規模推計モジュール１３０では、図６（ｃ）の例に示すような受注中のタスク情報をもとに現在受注中の業務量を考慮して候補ワーカーが受注しやすい業務量の推計を行う。
他の候補ワーカーに対しても同様に受注しやすい業務量の推計処理を行う。ここでは、候補ワーカーの受注しやすい業務量が翻訳文量＝１０，０００文字、５，０００文字と算出された場合を例にとり、タスクの分割処理について説明する。
タスク分割モジュール１２５は、発注されたタスク（Ｔ０１０７４０）を候補ワーカーの受注しやすい業務量の推計値をもとに、Ｔ０１０７４１（１０，０００文字）、Ｔ０１０７４２（５，０００文字）、Ｔ０１０７４３（５，０００文字）の３つのサブタスクに分割し、タスク情報管理モジュール１１５に登録する。

タスク制御モジュール１１０はタスク情報管理モジュール１１５に登録された候補ワーカーの受注しやすい業務量のサブタスクのタスク情報を各候補ワーカーに提示する。図８に候補ワーカー（ワーカーＩＤ＝Ｂ０２９５）へのタスクの提示例を示す。この例のように、タスクの業務量だけでなく、候補ワーカーのスキル情報をもとに候補ワーカーが実施した場合のタスクの実施目安時間の情報もあわせて提示することにより、候補ワーカーがより受注しやすくなる。
このようにワーカーの過去の受注タスク履歴情報からワーカーが受注しやすい業務量を推計し、推計した業務量にあわせてタスクを自動分割し、ワーカー毎に受注しやすい業務量のタスクとしてワーカーに提示することにより、結果的には、タスクの受注率が向上することとなる。

図８は、受注可能タスク情報提示画面８００の表示例を示す説明図である。受注可能タスク情報提示画面８００には、タスク提示領域８１０、「受注する」ボタン８３０、「キャンセル」ボタン８４０、ワーカーＩＤ表示領域８５０を表示する。タスク提示領域８１０は、受注チェック欄８１２、タスクＩＤ欄８１４、タスク名欄８１６、タスク種別欄８１８、納期欄８２０、目安時間欄８２２、報酬欄８２４、タスク詳細欄８２６を有している。受注チェック欄８１２は、受注チェックボックスを表示している。タスクＩＤ欄８１４は、タスクＩＤを表示している。タスク名欄８１６は、タスク名を表示している。タスク種別欄８１８は、タスク種別を表示している。納期欄８２０は、納期を表示している。目安時間欄８２２は、目安時間を表示している。報酬欄８２４は、報酬を表示している。タスク詳細欄８２６は、タスク詳細を表示するための「詳細情報」ボタンを表示している。
受注可能タスク情報提示画面８００内には、例えば、「現在、あなたが受注可能なタスクは以下（受注チェック欄８１２）の通りです。受注したいタスクがある場合には、［受注チェック］（受注チェック欄８１２）のチェックボックスにチェックを入れて「受注する」ボタン８３０を押してください。」と表示する。
ワーカーは複数の業務スキルを保有している業務毎にスキル情報を登録している。この翻訳スキルの例では、図５の例で発注されたタスクが日英翻訳／一般文書で［翻訳レベル＝４以上］なので、このワーカーは受注候補ワーカーとなり、ワーカーの過去の受注履歴からワーカーが受注しやすい業務量を算出してサブタスクとして分割し、タスク提示領域８１０のように、ワーカーに提示する。

また、タスクの分割により業務量の量的な変化だけでなく、質的に変化（要求スキルが変化）させるようにしてもよい。図９に、サブタスクによってスキルレベルが異なる分割例を示す。この例では、タスク全体を実施するには「日英翻訳品質レベル＝４」が必要であるが、分割されたサブタスク＝Ｔ０１０９６３を実施するには「日英翻訳品質レベル＝３」で十分であることを示している。このようにタスク全体の質（必要なスキル）が均一でない場合には、タスクの分割は量的な分割に限らず、質的に分割するようにしてもよく、サブタスクに分割することによる要求スキルレベルの変化（質の変化）により受注可能な候補ワーカー数が増加し、タスクの受注率の向上につながる。

図９は、タスク情報テーブル９００のデータ構造例を示す説明図である。図９は、分割時にタスク遂行に必要なスキルが変化する例を示している。つまり、タスクによっては実施に必要な受注者スキルが均一でない場合がある。例えば、この例ではタスクの一部は「日英翻訳品質レベル＝３」で十分である場合であり、サブタスクに分割することによって受注者に要求されるスキルレベルが変化することもあり、受注候補ワーカーを増加させることができる。
図９（ａ）は、タスク情報テーブル９００のデータ構造例を示す説明図である。タスク情報テーブル９００は、項目欄９０２、タスク情報欄９０４を有している。項目欄９０２は、項目を記憶している。タスク情報欄９０４は、タスク情報を記憶している。タスク情報テーブル９００は、タスクＩＤとして「Ｔ０１０９６０」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「１０，０００文字」、タスク発注日として「２０１５／０７／２０」、成果物納期として「２０１５／０７／３０」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「２３，０００円」、親タスクＩＤとして「−」（Ｎｕｌｌ）、サブタスクＩＤとして「Ｔ０１０９６１，Ｔ０１０９６２，Ｔ０１０９６３」を記憶している。サブタスクＩＤ欄９４０は、タスク情報テーブル９１０へのリンク９４２（Ｔ０１０９６１）、タスク情報テーブル９２０へのリンク９４４（Ｔ０１０９６２）、タスク情報テーブル９３０へのリンク９４６（Ｔ０１０９６３）を記憶している。
図９（ｂ）は、タスク情報テーブル９１０のデータ構造例を示す説明図である。タスク情報テーブル９１０は、項目欄９１２、タスク情報欄９１４を有している。項目欄９１２は、項目を記憶している。タスク情報欄９１４は、タスク情報を記憶している。タスク情報テーブル９１０は、タスクＩＤとして「Ｔ０１０９６１」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「５，０００文字」、タスク発注日として「２０１５／０７／２０」、成果物納期として「２０１５／０７／３０」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「１２，０００円」、親タスクＩＤとして「Ｔ０１０９６０」、サブタスクＩＤとして「−」（Ｎｕｌｌ）を記憶している。
図９（ｃ）は、タスク情報テーブル９２０のデータ構造例を示す説明図である。タスク情報テーブル９２０は、項目欄９２２、タスク情報欄９２４を有している。項目欄９２２は、項目を記憶している。タスク情報欄９２４は、タスク情報を記憶している。タスク情報テーブル９２０は、タスクＩＤとして「Ｔ０１０９６２」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「２，５００文字」、タスク発注日として「２０１５／０７／２０」、成果物納期として「２０１５／０７／３０」、受注者スキルとして「日英翻訳品質レベル４以上」、報酬として「６，０００円」、親タスクＩＤとして「Ｔ０１０９６０」、サブタスクＩＤとして「−」（Ｎｕｌｌ）を記憶している。
図９（ｄ）は、タスク情報テーブル９３０のデータ構造例を示す説明図である。タスク情報テーブル９３０は、項目欄９３２、タスク情報欄９３４を有している。項目欄９３２は、項目を記憶している。タスク情報欄９３４は、タスク情報を記憶している。タスク情報テーブル９３０は、タスクＩＤとして「Ｔ０１０９６３」、タスク状態として「発注情報公開中」、タスク種別として「日英翻訳／一般文書」、タスク量として「２，５００文字」、タスク発注日として「２０１５／０７／２０」、成果物納期として「２０１５／０７／３０」、受注者スキルとして「日英翻訳品質レベル３以上」、報酬として「５，０００円」、親タスクＩＤとして「Ｔ０１０９６０」、サブタスクＩＤとして「−」（Ｎｕｌｌ）を記憶している。
タスク情報テーブル９３０の受注者スキルとしての「日英翻訳品質レベル３以上」は、このサブタスクを実施するために必要なスキルは、親タスク（タスク情報テーブル９００の受注者スキルとしての「日英翻訳品質レベル４以上」）よりも低いスキルで実施可能であることを示している。

＜＜第２の実施の形態＞＞
図１０は、第２の実施の形態の構成例についての概念的なモジュール構成図である。
サブタスクの分割は発注時に候補ワーカーの情報をもとに、情報処理装置１００が自動的にサブタスクに分割するケース（第１の実施の形態）だけでなく、ワーカーに対して受注対象のタスク情報の提示後にワーカー側からの要求によりタスクを分割するようにしてもよい。
情報処理装置１０００は、タスク分割要求通知モジュール１０２０、タスク情報登録・更新モジュール１０５、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、タスク分割要求入力モジュール１０１０、ワーカー情報登録・更新モジュール１５０を有している。なお、前述の実施の形態と同種の部位は、同等の機能を有している。

タスク分割要求通知モジュール１０２０は、タスク制御モジュール１１０、発注者用情報処理装置１７０と接続されている。タスク分割要求通知モジュール１０２０は、タスク分割要求入力モジュール１０１０が分割要求を受け付けた場合に、その分割要求を受けたタスクの発注者に通知する。そして、発注者によるそのタスクの分割の可否の判定結果を受け付ける。具体的には、タスク分割要求通知モジュール１０２０は、発注者に対してワーカーからのタスク分割要求があったことを通知する。

タスク情報登録・更新モジュール１０５は、タスク制御モジュール１１０、発注者用情報処理装置１７０、ワーカー用情報処理装置１８０と接続されている。タスク情報登録・更新モジュール１０５は、タスクの納期、報酬、受注に必要なスキルなどのタスク情報を入力・更新する。
タスク制御モジュール１１０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０、タスク分割要求処理モジュール１０３０を有しており、タスク分割要求通知モジュール１０２０、タスク情報登録・更新モジュール１０５、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、タスク分割要求入力モジュール１０１０、ワーカー情報登録・更新モジュール１５０と接続されている。タスク制御モジュール１１０は、発注されたタスクをワーカーに配分し、タスクが受注されるように制御を行う。
タスク情報管理モジュール１１５は、タスク情報記憶モジュール１２０を有しており、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０、タスク分割要求処理モジュール１０３０と接続されている。タスク情報管理モジュール１１５は、タスク毎の情報を保持し、要求に応じて保持したタスク情報を抽出する。
タスク分割モジュール１２５は、タスク情報管理モジュール１１５、受注タスク規模推計モジュール１３０と接続されている。タスク分割モジュール１２５は、タスク分割要求通知モジュール１０２０が分割可の判定結果を受け付けた場合に、タスクの分割処理を行う。具体的には、タスク分割モジュール１２５は、タスク情報管理モジュール１１５内のタスクをサブタスクに分割し、タスク情報管理モジュール１１５内に登録する。

受注タスク規模推計モジュール１３０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５と接続されている。受注タスク規模推計モジュール１３０は、タスク分割要求入力モジュール１０１０が分割要求を受け付けた場合に、タスクの分割処理を行う。具体的には、受注タスク規模推計モジュール１３０は、ワーカーのタスク受注履歴情報をもとにワーカーが受注しやすいタスクの規模を推計する。
タスク分割要求処理モジュール１０３０は、タスク情報管理モジュール１１５と接続されている。タスク分割要求処理モジュール１０３０は、ワーカーからのタスク分割要求に対して、残りのサブタスクの候補ワーカー数情報に基づいた分割可否の自動判定やワーカーの要求に基づいてタスク分割処理を行う。

ワーカー情報管理モジュール１３５は、ワーカー情報記憶モジュール１４０を有しており、タスク制御モジュール１１０、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー情報管理モジュール１３５は、ワーカー毎のスキル情報、過去の業務履歴などのワーカー情報を保持し、要求に応じてワーカー情報の登録・更新・抽出をする。
タスク情報提示モジュール１４５は、タスク制御モジュール１１０、ワーカー用情報処理装置１８０と接続されている。タスク情報提示モジュール１４５は、ワーカー毎に受注可能なタスク情報を提示する。
タスク分割要求入力モジュール１０１０は、タスク制御モジュール１１０、ワーカー用情報処理装置１８０と接続されている。タスク分割要求入力モジュール１０１０は、ワーカー用情報処理装置１８０を使用しているワーカーからタスクの分割要求を受け付ける。具体的には、提示されたタスクに対してワーカーが分割要求を出し、その分割要求を受け付ける。

ワーカー情報登録・更新モジュール１５０は、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、ワーカー用情報処理装置１８０と接続されている。ワーカー情報登録・更新モジュール１５０は、ワーカー情報管理モジュール１３５内のワーカー情報を登録・更新する。
発注者用情報処理装置１７０は、情報処理装置１０００のタスク分割要求通知モジュール１０２０、タスク情報登録・更新モジュール１０５と接続されている。発注者用情報処理装置１７０は、発注者によって利用される端末である。
ワーカー用情報処理装置１８０は、情報処理装置１０００のタスク情報登録・更新モジュール１０５、タスク情報提示モジュール１４５、タスク分割要求入力モジュール１０１０、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー用情報処理装置１８０は、ワーカーによって利用される端末である。
発注者用情報処理装置１７０、ワーカー用情報処理装置１８０は、例えば、通信機能を有するパーソナルコンピュータ、携帯端末（スマートフォンを含む携帯電話等）等であって、ブラウザを備えている。

前述のモジュールを有する情報処理装置１０００は、ワーカーからの要求によるタスクの分割処理を行う。例えば、以下のような処理を行う。
ワーカーに提示されたタスクに対して、ワーカーが自分で実施可能な業務量をもとにタスクの分割要求を出し、（発注者の承諾が得られれば、）情報処理装置１０００は要求に基づいて発注されたタスクを分割し、残りのサブタスクとして再登録し、別の候補ワーカーに提示する。
タスクの属性として分割可否フラグのような情報を保持しておき、発注者が［分割可］と指定したタスクについてはタスク登録時にシステムが最小単位にタスクを自動分割しておき、ワーカーからの分割要求時にサブタスクを提示し、希望タスク量（サブタスク数）を指定するようにしてもよい。
ワーカーの要求に応じてタスクを分割した場合には必ず残りのサブタスクができてしまうので、その残りのタスクを受注するワーカーが必要となるが、発注者がタスクの分割の可否を判断する際に、残りのタスクの候補ワーカーの有無や候補ワーカー数の情報等をもとに発注者がタスクの分割を判定できるようにする。また、候補ワーカーがいない場合には発注者の判断を仰ぐことなく、システムが分割の可否を判定して自動的にタスクの分割を拒否するようにしてもよい。

図１１は、第２の実施の形態による処理例（ワーカー要求によるタスクの分割処理例）を示すフローチャートである。
ステップＳ１１０２では、発注されたタスクを実施可能なスキルを持つワーカーを抽出し、抽出された候補ワーカーにタスクを提示する。具体的には、タスク制御モジュール１１０はワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、発注されたタスクを実施可能な候補ワーカーを抽出し、候補ワーカーに受注可能なタスクを提示する。
ステップＳ１１０４では、ワーカーからタスクの分割要求があるか否かを判断し、ある場合はステップＳ１１０６へ進み、それ以外の場合は処理を終了する（ステップＳ１１９９）。具体的には、候補ワーカーよりタスク分割要求があるかどうかを確認し、分割要求がない場合（ステップＳ１１０４でＮｏ）には通常のタスク提示処理を行う。

ステップＳ１１０６では、分割後の残りのサブタスクの候補ワーカー情報を抽出する。具体的には、ステップＳ１１０４でタスク分割要求があった場合には、分割した際の残りのサブタスクの候補ワーカー情報を抽出する。
ステップＳ１１０８では、残りのタスクの候補ワーカーはいるか否かを判断し、いる場合はステップＳ１１１０へ進み、それ以外の場合はステップＳ１１１４へ進む。
ステップＳ１１１０では、ワーカーからのタスク分割要求を分割タスクの情報とともに発注者に通知する。
具体的には、ステップＳ１１０８、ステップＳ１１１０では、残りのタスクの候補ワーカーがいない場合（ステップＳ１１０８でＮｏ）にはタスク分割要求が許諾されなかったことをワーカーに通知し（ステップＳ１１１４）、候補ワーカーがいる場合（ステップＳ１１０８でＹｅｓ）には分割した際の残りのタスクの候補ワーカー等の情報と含めてタスク分割要求があったことを発注者に通知する（ステップＳ１１１０）。

ステップＳ１１１２では、発注者によりタスクが許諾されたか否かを判断し、許諾された場合はステップＳ１１１６へ進み、それ以外の場合はステップＳ１１１４へ進む。
ステップＳ１１１４では、タスク分割要求が許諾されなかったことをワーカーに通知する。
具体的には、ステップＳ１１１２、ステップＳ１１１４では、発注者がタスクの分割を許諾しなかった場合（ステップＳ１１１２でＮｏ）には、その旨をワーカーに通知し（ステップＳ１１１４）、通常のタスク提示処理を行う。

ステップＳ１１１６では、ワーカーの要求にしたがってタスクを分割しサブタスクとして登録し、ワーカーに分割されたサブタスクを提示する。
具体的には、ステップＳ１１１２、ステップＳ１１１６では、発注者がタスクの分割を許諾した場合（ステップＳ１１１２でＹｅｓ）には、タスク制御モジュール１１０はワーカーの要求にしたがってサブタスクに分割し、タスク情報記憶モジュール１２０にサブタスクとして登録し、タスク分割要求を出した候補ワーカーへの受注可能タスク内容を変更して提示するとともに、残りのサブタスクについて候補ワーカーを抽出し、抽出された候補ワーカーに対して受注可能タスクとして提示する。

次に、ワーカー要求によるタスクの分割処理について、具体例を用いて説明する。
タスク制御モジュール１１０はワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、発注されたタスクを実施可能な候補ワーカーを抽出する。
次にタスク制御モジュール１１０はタスク情報提示モジュール１４５を通して、候補ワーカー毎に実施可能なタスクを提示する。候補ワーカーがタスクを受注したいが業務量が多すぎる場合に、発注者がタスク情報内の分割可否情報として「分割可能」と指定したタスクについては、提示されたタスクに対して候補ワーカーが分割要求を出すことができる。図１２（ａ）にタスク分割可否の情報付きのタスク情報の例、図１３に候補ワーカーへのタスク情報提示ユーザーインターフェースの例を示す。

図１２（ａ）は、タスク情報テーブル１２００のデータ構造例を示す説明図である。タスク情報テーブル１２００は、項目欄１２０２、タスク情報欄１２０４を有している。項目欄１２０２は、項目を記憶している。タスク情報欄１２０４は、タスク情報を記憶している。タスク情報テーブル１２００は、タスクＩＤとして「Ｔ０１０５８０」、タスク名として「レター翻訳」、タスク種別として「日英翻訳」、タスク量として「１２，０００文字」、成果物納期として「２０１４／１２／２０」、受注者スキルとして「日英翻訳レベル４以上」、報酬として「２４，０００円」、タスク分割可否として「分割可能」、親タスクＩＤとして「−」（Ｎｕｌｌ）、ステータスとして「公募中」、受注ワーカーＩＤとして「−」（Ｎｕｌｌ）、候補ワーカー数として「４」、候補ワーカーＩＤとして「Ｂ０１２４，Ｂ０２９５，Ｂ０４１０，Ｂ０４８３」を記憶している。

図１３は、受注可能タスク情報提示画面１３００の表示例を示す説明図である。
受注可能タスク情報提示画面１３００に、タスク提示領域１３１０、「受注する」ボタン１３３０、「キャンセル」ボタン１３４０、ワーカーＩＤ表示領域１３５０を表示する。タスク提示領域１３１０は、受注チェック欄１３１２、タスクＩＤ欄１３１４、タスク名欄１３１６、タスク種別欄１３１８、納期欄１３２０、目安時間欄１３２２、タスク量欄１３２４、報酬欄１３２６、部分受注欄１３２８を有している。
受注チェック欄１３１２は、受注チェックをボックスを有している。タスクＩＤ欄１３１４は、タスクＩＤを表示している。タスク名欄１３１６は、タスク名を表示している。タスク種別欄１３１８は、タスク種別を表示している。納期欄１３２０は、納期を表示している。目安時間欄１３２２は、目安時間を表示している。タスク量欄１３２４は、タスク量を表示している。報酬欄１３２６は、報酬を表示している。部分受注欄１３２８は、部分受注の可能性がある場合は、「部分受注要求」ボタンを表示している。
そして、受注可能タスク情報提示画面１３００内には、例えば、「現在、あなたが受注可能なタスクは以下の通りです。受注したいタスクがある場合には、［受注チェック］（受注チェック欄１３１２）のチェックボックスを選択し、「受注する」ボタン１３３０を押下してください。」と表示し、そして、「部分受注欄１３２８に「部分受注要求」のボタンが表示されているタスクはタスクの一部のみを受注できる可能性があるタスクです。部分受注を希望する場合には「部分受注要求」ボタンを押下し、表示されたタスクリストから受注希望のタスクを選択してください。」と表示する。この例では、部分受注欄１３２８内の「部分受注要求」ボタンの押下により、候補ワーカーに対して部分受注のタスク候補リストを表示する。

図１２（ａ）の例に示すタスクに対して、ある候補ワーカー（ワーカーＩＤ＝Ｂ０２９５）が分割要求を出した場合を例にとり、タスク分割要求処理のフローについて説明する。図１３のユーザーインターフェース例で「部分受注要求」ボタンを押下すると、タスク分割要求処理モジュール１０３０はタスクを部分受注の候補タスクに分割し、分割したタスク情報を分割要求のあった候補ワーカーに提示する（図１４に部分受注の候補タスク提示例を示す）。この例で候補ワーカーがサブタスクＩＤ＝０１（タスク量＝６，０００文字）のタスクを選択し部分受注要求を出したとすると、タスク分割要求処理モジュール１０３０は、選択されたタスク量（６，０００文字）でタスクを分割し、分割した場合の残りのタスクのタスク情報をもとに候補ワーカー情報を抽出する。（タスク分割要求に基づいて図１２（ａ）のタスクを分割したタスク情報の例を図１２（ｂ）に示し、その場合の残りのタスク情報の例を図１２（ｃ）に示す。）もし、残りのタスクの候補ワーカー数がゼロの場合には、タスク分割要求に対して自動的に分割拒否の判定を行い、タスク分割要求を出した候補ワーカーにその旨を通知する。

図１２（ｂ）は、タスク情報テーブル１２１０のデータ構造例を示す説明図である。タスク情報テーブル１２１０は、項目欄１２１２、タスク情報欄１２１４を有している。項目欄１２１２は、項目を記憶している。タスク情報欄１２１４は、タスク情報を記憶している。タスク情報テーブル１２００は、タスクＩＤとして「Ｔ０１０５８１」、タスク名として「レター翻訳」、タスク種別として「日英翻訳」、タスク量として「６，０００文字」、成果物納期として「２０１４／１２／２０」、受注者スキルとして「日英翻訳レベル４以上」、報酬として「１２，０００円」、タスク分割可否として「−」（Ｎｕｌｌ）、親タスクＩＤとして「Ｔ０１０６４０」、ステータスとして「受注契約完了」、受注ワーカーＩＤとして「Ｂ０２９５」、候補ワーカー数として「−」（Ｎｕｌｌ）、候補ワーカーＩＤとして「−」（Ｎｕｌｌ）を記憶している。
図１２（ｃ）は、タスク情報テーブル１２２０のデータ構造例を示す説明図である。タスク情報テーブル１２２０は、項目欄１２２２、タスク情報欄１２２４を有している。項目欄１２２２は、項目を記憶している。タスク情報欄１２２４は、タスク情報を記憶している。タスク情報テーブル１２２０は、タスクＩＤとして「Ｔ０１０５８２」、タスク名として「レター翻訳」、タスク種別として「日英翻訳」、タスク量として「６，０００文字」、成果物納期として「２０１４／１２／２０」、受注者スキルとして「日英翻訳レベル４以上」、報酬として「１２，０００円」、タスク分割可否として「分割可能」、親タスクＩＤとして「Ｔ０１０６４０」、ステータスとして「公募中」、受注ワーカーＩＤとして「−」（Ｎｕｌｌ）、候補ワーカー数として「５」、候補ワーカーＩＤとして「Ｂ０１２４，Ｂ０４１０，Ｂ０４８３，Ｂ０５４２，Ｂ０８３０」を記憶している。

図１４は、部分受注タスク候補提示画面１４００の表示例を示す説明図である。受注可能タスク情報提示画面１３００内の「部分受注要求」ボタンが押下された場合に、部分受注タスク候補提示画面１４００を表示する。
部分受注タスク候補提示画面１４００に、タスク提示領域１４１０、「部分受注要求を出す」ボタン１４３０、「キャンセル」ボタン１４４０を表示する。タスク提示領域１４１０は、受注チェック欄１４１２、サブタスクＩＤ欄１４１４、タスク名欄１４１６、タスク種別欄１４１８、納期欄１４２０、目安時間欄１４２２、タスク量欄１４２４、報酬欄１４２６を有している。受注チェック欄１４１２は、受注チェックボックスを有している。サブタスクＩＤ欄１４１４は、サブタスクＩＤを表示している。タスク名欄１４１６は、タスク名を表示している。タスク種別欄１４１８は、タスク種別を表示している。納期欄１４２０は、納期を表示している。目安時間欄１４２２は、目安時間を表示している。タスク量欄１４２４は、タスク量を表示している。報酬欄１４２６は、報酬を表示している。
部分受注タスク候補提示画面１４００内には、例えば、「タスクを部分的に受注したい場合には、［受注チェック］（受注チェック欄１４１２）のチェックボックスにチェックを入れて「部分受注要求を出す」ボタン１４３０を押してください。」と表示する。
部分受注タスク候補提示画面１４００は、分割したタスクの提示を行っている。つまり、候補ワーカーに対して、部分受注対象の候補タスクを提示している。

上記の事例では、残りのタスクの候補ワーカー数がゼロの場合に分割拒否の自動判定を行う実施例を示したが、発注者がタスクを発注する際に、「分割後の残りのタスクの候補ワーカー数がある一定数以下の場合は分割要求を許諾しない」と指定した場合には、残りのタスクの候補ワーカー数がゼロ以外の場合でも自動的に分割拒否の判定を行うようにしてもよい。
次に、タスク分割要求処理モジュール１０３０は、残りのタスク情報（残りのタスクの候補ワーカー情報を含む）とともに、候補ワーカーからタスク分割要求があったことを通知する。発注者は残りのタスク情報や候補ワーカー数の情報などをもとに、タスクの分割を許可するかどうかの判定を行い、判定結果をタスク情報登録・更新モジュール１０５を用いてインプットする。

発注者がタスクの分割を許可しなかった場合には、タスク分割要求処理モジュール１０３０はその旨をワーカーに通知し、通常のタスク提示処理を行う。
発注者がタスクの分割を許可した場合には、ワーカーの要求にしたがってタスク分割モジュール１２５によりタスクを分割し、タスク情報記憶モジュール１２０にサブタスクとして登録し、タスク分割要求を出した候補ワーカーへの受注可能タスク内容を変更して提示するとともに、残りのタスクの候補ワーカーに対して残りのタスク情報を受注可能タスクとして提示する。
これにより、提示されたタスクを候補ワーカーの希望に合わせた業務量に近いタスクにすることができるため、タスクの受注率があがる。また発注者はタスク分割要求の可否の判断の際に、候補ワーカーの要求にしたがってタスクを分割した場合の残りのタスクの候補ワーカー数などの情報を参照することができることにより、タスク全体の受注者数を確保できるようにタスク分割要求の可否を判断することができるようになる。

＜＜第３の実施の形態＞＞
図１５は、第３の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置１５００は、タスク分割要求通知モジュール１０２０、タスク情報登録・更新モジュール１０５、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、タスク分割要求入力モジュール１０１０、ワーカー情報登録・更新モジュール１５０を有している。
タスク分割要求通知モジュール１０２０は、タスク制御モジュール１１０、発注者用情報処理装置１７０と接続されている。タスク分割要求通知モジュール１０２０は、発注者にワーカーからタスク分割要求があったことを通知する。
タスク情報登録・更新モジュール１０５は、タスク制御モジュール１１０、発注者用情報処理装置１７０、ワーカー用情報処理装置１８０と接続されている。タスク情報登録・更新モジュール１０５は、タスクの納期、報酬、受注に必要なスキルなどのタスク情報を入力・更新する。
タスク制御モジュール１１０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５を有しており、タスク分割要求通知モジュール１０２０、タスク情報登録・更新モジュール１０５、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、タスク分割要求入力モジュール１０１０、ワーカー情報登録・更新モジュール１５０と接続されている。タスク制御モジュール１１０は、発注されたタスクをワーカーに配分し、タスクが受注されるように制御を行う。
タスク情報管理モジュール１１５は、タスク情報記憶モジュール１２０を有しており、タスク分割モジュール１２５と接続されている。タスク情報管理モジュール１１５は、タスク毎の情報を保持し、要求に応じて保持したタスク情報を抽出する。

タスク分割モジュール１２５は、タスク分割数判定モジュール１５１０を有しており、タスク情報管理モジュール１１５と接続されている。タスク分割モジュール１２５は、タスク分割数判定モジュール１５１０によって算出された分割数に、タスクの分割処理を行う。例えば、タスクをサブタスクに分割し、タスク情報管理モジュール１１５内に登録する。
タスク分割数判定モジュール１５１０は、分割されたタスクを受注可能なワーカー数が予め定められた閾値より多い又は以上になるように分割数を算出する。例えば、候補ワーカーの情報をもとにタスクの分割数を判定する。

ワーカー情報管理モジュール１３５は、ワーカー情報記憶モジュール１４０を有しており、タスク制御モジュール１１０、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー情報管理モジュール１３５は、ワーカー情報を保持し、要求に応じてワーカー情報の登録・更新・抽出をする。
タスク情報提示モジュール１４５は、タスク制御モジュール１１０、ワーカー用情報処理装置１８０と接続されている。タスク情報提示モジュール１４５は、ワーカー毎に受注可能なタスク情報を提示する。
タスク分割要求入力モジュール１０１０は、タスク制御モジュール１１０、ワーカー用情報処理装置１８０と接続されている。タスク分割要求入力モジュール１０１０は、ワーカーが提示されたタスクに対して分割要求を出す。
ワーカー情報登録・更新モジュール１５０は、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、ワーカー用情報処理装置１８０と接続されている。ワーカー情報登録・更新モジュール１５０は、ワーカー情報管理モジュール１３５内のワーカー情報を登録・更新する。

発注者用情報処理装置１７０は、情報処理装置１５００のタスク分割要求通知モジュール１０２０、タスク情報登録・更新モジュール１０５と接続されている。発注者用情報処理装置１７０は、発注者によって利用される端末である。
ワーカー用情報処理装置１８０は、情報処理装置１５００のタスク情報登録・更新モジュール１０５、タスク情報提示モジュール１４５、タスク分割要求入力モジュール１０１０、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー用情報処理装置１８０は、ワーカーによって利用される端末である。
発注者用情報処理装置１７０、ワーカー用情報処理装置１８０は、例えば、通信機能を有するパーソナルコンピュータ、携帯端末（スマートフォンを含む携帯電話等）等であって、ブラウザを備えている。

前述のモジュールを有する情報処理装置１５００は、候補ワーカー数に基づいたタスク分割処理を行う。
例えば、タスクを分割する際に、分割したサブタスクを受注可能な候補ワーカーがある一定人数を越えるように分割する。
タスクを細分化しないと受注されないが、細分化しすぎるとタスクを統合する際に手間がかかるため、受注が見込める範囲でサブタスク化するのが難しくなってしまうが、これを解決することになる。例えば、翻訳文量１０，０００文字では一人しか候補ワーカーがいないが、５，０００文字にすれば３人、２，５００文字にすれば８人と増えていく場合に、候補ワーカー数がある閾値に達するまでタスクを分割して候補ワーカーに提示する。

図１６は、第３の実施の形態による処理例（候補ワーカー数によるタスク分割処理例）を示すフローチャートである。
ステップＳ１６０２では、発注タスクを受注可能なスキルを持つ候補ワーカーを抽出する。具体的には、タスク制御モジュール１１０はワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、発注されたタスクを受注可能な候補ワーカーを抽出する。
ステップＳ１６０４では、タスク分割数の初期設定値を設定する。具体的には、タスク制御モジュール１１０はタスク分割数の初期設定値を設定する。

ステップＳ１６０６では、候補ワーカー数は閾値より多いか否かを判断し、多い場合はステップＳ１６１４へ進み、それ以外の場合はステップＳ１６０８へ進む。具体的には、タスク分割数判定モジュール１５１０は、ステップＳ１６０２で抽出した候補ワーカー数が予め決められた閾値より多いかどうかを判定する。なお、この閾値は、登録者側が設定してもよいし、後述するタスク分割数毎の候補ワーカー情報テーブル１７１０内のワーカー倍率を用いて設定してもよい。
ステップＳ１６０８では、タスクをタスク分割数で指定された数のタスクに分割する。具体的には、閾値より少ない場合（ステップＳ１６０６でＮｏ）には、タスク分割数で設定された値にタスクを分割する。

ステップＳ１６１０では、分割したタスクを受注可能なスキルを持つ候補ワーカーを抽出する。
ステップＳ１６１２では、タスク分割数を増加させ、ステップＳ１６０６へ戻る。
具体的には、ステップＳ１６１０、ステップＳ１６１２では、タスク制御モジュール１１０はワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、ステップＳ１６０８で分割したタスクを受注可能な候補ワーカーを抽出し、タスク分割数の設定値を増加させる。
ステップＳ１６１４では、分割したサブタスクの情報をタスク情報管理モジュール１１５に登録する。具体的には、候補ワーカー数が閾値を超える（ステップＳ１６０６でＹｅｓ）までステップＳ１６０８〜ステップＳ１６１２の処理を繰り返し、閾値を超えたら分割したサブタスク情報をタスク管理モジュール１１５に登録し、タスク分割処理を終了する。

次に、候補ワーカー数によるタスク分割処理について、具体例を用いて説明する。
図１７（ａ）に示すタスク情報を例にとり、分割処理フローについて説明する。
タスク制御モジュール１１０はワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報をもとに、発注されたタスクを受注可能な候補ワーカーを抽出する（ステップＳ１６０２）。図１７（ｂ）、図１７（ｃ）に図１７（ａ）のタスクを分割した場合の分割数毎のタスク量、候補ワーカー情報の概念図を示す。
図１７（ａ）は、タスク情報テーブル１７００のデータ構造例を示す説明図である。タスク情報テーブル１７００は、発注されたタスクの情報を記憶しており、項目欄１７０２、タスク情報欄１７０４を有している。項目欄１７０２は、項目を記憶している。タスク情報欄１７０４は、タスク情報を記憶している。
図１７（ｂ）は、タスク分割数毎の候補ワーカー情報テーブル１７１０のデータ構造例を示す説明図である。タスク分割数毎の候補ワーカー情報テーブル１７１０は、分割数欄１７１２、タスク量欄１７１４、候補ワーカー数欄１７１６、ワーカー倍率欄１７１８、候補ワーカー情報欄１７２０を有している。分割数欄１７１２は、分割数を記憶している。タスク量欄１７１４は、タスク量を記憶している。候補ワーカー数欄１７１６は、候補ワーカー数を記憶している。ワーカー倍率欄１７１８は、ワーカー倍率を記憶している。候補ワーカー情報欄１７２０は、候補ワーカー情報を記憶している。
タスク分割数毎の候補ワーカー情報テーブル１７１０のタスク量欄１７１４の例は、１２，０００文字の日英翻訳業務タスクの分割数毎の候補ワーカー情報抽出リストの例である。
「分割数＝１」は分割しない状態（オリジナル）の発注タスクのことを指し、この例の場合、分割しない状態でタスクを受注できる候補ワーカーは１名で、タスクを２分割した場合には、候補ワーカー数が３名に、３分割した場合には候補ワーカー数が８名になることを表している。
タスク分割数毎の候補ワーカー情報テーブル１７１０のワーカー倍率欄１７１８の例に示すワーカー倍率とは、タスクを受注できる候補ワーカーの倍率のことで、例えば、分割数＝３の場合、分割した３つのタスクに対して候補ワーカー数＝８なので、ワーカー倍率＝８／３（２．７）となる。ワーカー倍率が高いほど、タスク全体として受注できるワーカーが多いことになる。
図１７（ｃ）は、ワーカー情報テーブル１７３０のデータ構造例を示す説明図である。ワーカー情報テーブル１７３０は、項目欄１７３２、ワーカー情報欄１７３４を有している。項目欄１７３２は、項目を記憶している。ワーカー情報欄１７３４は、ワーカー情報を記憶している。

タスク分割数判定モジュール１５１０は、ステップＳ１６０２で抽出した候補ワーカー数が予め決められた閾値より多いかどうかを判定する。ここでは「候補ワーカー数の閾値＝９」の場合を例にとり、処理フローについて説明する。
発注されたタスク（分割数＝１）では候補ワーカー数＝１であり（図１７（ｂ）、図１７（ｃ）参照）、閾値＝９より小さいので、タスク分割数にしたがい発注タスクを２分割し（ステップＳ１６０８）、分割したサブタスクを受注可能な候補ワーカー情報を抽出する（ステップＳ１６１０）。この例では、分割数＝２では候補ワーカー数＝３であり、閾値＝９より小さいので、タスク分割数を増加させてタスクの分割処理を繰り返す。分割数＝４の場合、では候補ワーカー数＝１０となり、閾値＝９と超えるため、タスク分割数＝４が選定され、４分割されたタスク情報をタスク情報管理モジュール１１５に登録し（ステップＳ１６１４）、分割処理を終了する。
ここでは「候補ワーカー数」をキーとしたタスク分割数の選定の例を示したが、図１７（ｂ）に示すようにタスク毎の候補ワーカーの倍率（ワーカー倍率）という概念を取り入れ、ワーカー倍率をキーとしてタスク分割数を選定するようにしてもよい。例えば、ワーカー倍率がある倍率以上となるようにタスクを分割する等がある。
このように、タスクを分割して細分化しないと受注率があがらないが、タスクを細分化しすぎるとタスクを統合する際に手間がかかるという課題に対して、この手法を用いることにより、受注が見込める範囲でタスクを分割することができるため、より効率的にタスクの成果物を生成することができる。

＜＜第４の実施の形態＞＞
図１８は、第４の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置１８００は、タスク情報登録・更新モジュール１０５、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０を有している。

タスク情報登録・更新モジュール１０５は、タスク制御モジュール１１０、発注者用情報処理装置１７０、ワーカー用情報処理装置１８０と接続されている。タスク情報登録・更新モジュール１０５は、タスクの納期、報酬、受注に必要なスキルなどのタスク情報を入力・更新する。
タスク制御モジュール１１０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０、受注タスク選定モジュール１８１０を有しており、タスク情報登録・更新モジュール１０５、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０と接続されている。タスク制御モジュール１１０は、発注されたタスクをワーカーに配分し、タスクが受注されるように制御を行う。
タスク情報管理モジュール１１５は、タスク情報記憶モジュール１２０を有しており、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０、受注タスク選定モジュール１８１０と接続されている。タスク情報管理モジュール１１５は、タスク毎の情報を保持し、要求に応じて保持したタスク情報を抽出する。
タスク分割モジュール１２５は、タスク情報管理モジュール１１５、受注タスク規模推計モジュール１３０と接続されている。タスク分割モジュール１２５は、タスク情報、ワーカー情報をもとにタスク情報管理手段モジュール１１５に登録されたタスクをワーカーが受注しやすいようにサブタスクに分割し、タスク情報管理モジュール１１５内に登録する。
受注タスク規模推計モジュール１３０は、タスク情報管理モジュール１１５、タスク分割モジュール１２５と接続されている。受注タスク規模推計モジュール１３０は、ワーカー情報をもとにワーカーが受注しやすいタスクの規模を推計する。

受注タスク選定モジュール１８１０は、タスク情報管理モジュール１１５と接続されている。受注タスク選定モジュール１８１０は、タスク分割モジュール１２５によって分割されたタスクの優先度にしたがって、ワーカーが受注するタスクを選定する。具体的には、サブタスクの優先度を算出し、受注するタスクを選定する。
ワーカー情報管理モジュール１３５は、ワーカー情報記憶モジュール１４０を有しており、タスク制御モジュール１１０、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー情報管理モジュール１３５は、ワーカー毎のスキル情報、過去の業務履歴などのワーカー情報を保持し、要求に応じてワーカー情報の登録・更新・抽出をする。
タスク情報提示モジュール１４５は、タスク制御モジュール１１０、ワーカー用情報処理装置１８０と接続されている。タスク情報提示モジュール１４５は、ワーカー毎に受注可能なタスク情報を提示する。
ワーカー情報登録・更新モジュール１５０は、タスク制御モジュール１１０、ワーカー情報管理モジュール１３５、ワーカー用情報処理装置１８０と接続されている。ワーカー情報登録・更新モジュール１５０は、ワーカーのスキル情報、過去の業務履歴などワーカー情報管理モジュール１３５内のワーカー情報を登録・更新する。

発注者用情報処理装置１７０は、情報処理装置１８００のタスク情報登録・更新モジュール１０５と接続されている。発注者用情報処理装置１７０は、発注者によって利用される端末である。
ワーカー用情報処理装置１８０は、情報処理装置１８００のタスク情報登録・更新モジュール１０５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０と接続されている。ワーカー用情報処理装置１８０は、ワーカーによって利用される端末である。
発注者用情報処理装置１７０、ワーカー用情報処理装置１８０は、例えば、通信機能を有するパーソナルコンピュータ、携帯端末（スマートフォンを含む携帯電話等）等であって、ブラウザを備えている。

前述のモジュールを有する情報処理装置１８００は、受注サブタスクの選定処理を行う。
例えば、発注されたタスクをできるだけ受注してもらいやすいように、多くのパターンで細分化してタスクの業務量以上のサブタスクを作成して候補ワーカーに対して提示した場合、受注希望のサブタスクの中からどのサブタスクを受注するかという選定が難しくなる。
情報処理装置１８００では、受注希望のサブタスク毎にタスク選定のための優先度（受注タスク優先度）を算出し、その優先度をもとに受注先を自動選定し、統合した受注タスクを生成する。具体的には、能力の高いワーカーには、それに応じた業務量となるようにしたものである。
受注タスク優先度は、タスク分割優先度とワーカー優先度から算出される。タスク分割優先度とは、タスクの分割数が少ないなど、サブタスクから効率的に納品物を生成することを考慮した優先度で、例えば、サブタスクの業務量などがこれにあたる。ワーカー優先度とは、受注希望ワーカーの情報に基づいた優先度で、例えば、過去の業務評価や受注業務に対するスキルレベルなどがこれにあたる。

図１９は、第４の実施の形態による処理例（受注サブタスクの選定処理例）を示すフローチャートである。
ステップＳ１９０２では、［配分タスク業務量］の初期値を発注タスクの業務量に設定する。
ステップＳ１９０４では、受注希望ワーカーが存在する受注候補タスク情報を抽出し、受注タスク優先度を算出する。
ステップＳ１９０６では、受注選定処理を未実施のサブタスクはあるか否かを判断し、ある場合はステップＳ１９０８へ進み、それ以外の場合は処理を終了する（ステップＳ１９９９）。

ステップＳ１９０８では、受注選定処理を未実施のサブタスク内で受注タスク優先度の最も高いサブタスクのサブタスク業務量を抽出する。
ステップＳ１９１０では、配分タスク業務量≧サブタスク業務量であるか否かを判断し、配分タスク業務量≧サブタスク業務量である場合はステップＳ１９１２へ進み、それ以外の場合はステップＳ１９０６へ戻る。
ステップＳ１９１２では、サブタスクのステータスを「受注確定」とする。
ステップＳ１９１４では、配分タスク業務量＝配分タスク業務量−サブタスク業務量と設定する。
ステップＳ１９１６では、配分タスク業務量＝０であるか否かを判断し、配分タスク業務量＝０である場合は処理を終了し（ステップＳ１９９９）、それ以外の場合はステップＳ１９０６へ戻る。

発注されたタスクの受注率をあげるために、候補ワーカーの受注しやすい業務量にあわせて多くのパターンで細分化したサブタスクを作成して候補ワーカーに対して提示することが考えられるが、その場合、受注希望のサブタスクの中から発注タスクを構成する受注タスクをどう選定するかということが課題となる。その課題を解決するために、タスク分割優先度とワーカー優先度をもとに受注するサブタスクを選定する情報処理装置１８００について説明する。
タスク制御モジュール１１０は、ワーカー情報管理モジュール１３５内のワーカーの保有スキルの情報等をもとに、発注されたタスクを受注可能な候補ワーカーを抽出する。タスク情報とワーカー情報管理モジュール１３５内に保持された候補ワーカーの過去の受注タスク履歴情報から受注タスク規模推計モジュール１３０により、ワーカーが受注しやすいタスクの規模（業務量）を推計し、そのタスク規模推計情報をもとにタスク分割を行い、各候補ワーカーにタスク情報を提示する。タスク情報の提示処理は、第１の実施の形態と同等である。

図２０に示すタスク情報を例にとり、受注するサブタスクの選定処理フローについて説明する。図２０の例では１４人の候補ワーカーに対して、候補ワーカーの受注しやすいタスク規模に合わせて翻訳文量＝６０００文字、３０００文字、１５００文字の３つの業務量のサブタスク情報を提示している。

図２０（ａ）は、タスク情報テーブル２０００のデータ構造例を示す説明図である。タスク情報テーブル２０００は、発注されたタスクに関する情報を記憶しており、項目欄２００２、タスク情報欄２００４を有している。項目欄２００２は、項目を記憶している。タスク情報欄２００４は、タスク情報を記憶している。サブタスク情報欄２０２０は、サブタスク情報テーブル２０１０へのリンク２０２２を記憶している。
図２０（ｂ）は、サブタスク情報テーブル２０１０のデータ構造例を示す説明図である。サブタスク情報テーブル２０１０は、候補ワーカーに提示されたサブタスクに関する情報を記憶しており、サブタスクＩＤ欄２０１２、サブタスク業務量欄２０１４、受注ステータス欄２０１６、候補ワーカーＩＤ欄２０１８を有している。サブタスクＩＤ欄２０１２は、サブタスクＩＤを記憶している。サブタスク業務量欄２０１４は、サブタスク業務量を記憶している。受注ステータス欄２０１６は、受注ステータスを記憶している。候補ワーカーＩＤ欄２０１８は、候補ワーカーＩＤを記憶している。

受注タスク選定モジュール１８１０は、配分タスク業務量の初期値を設定する（ステップＳ１９０２）。配分タスク業務量とは、候補ワーカーに配分すべき業務量のことで、初期値は発注タスクの業務量（図２０の例では１２，０００文字）に設定される。例えば、業務量＝１，５００文字のサブタスクの受注が確定すると、配分すべき業務量は受注確定分だけ減少するので、配分タスク業務量＝１０，５００文字となる。
次に提示したサブタスクの中から受注希望ワーカーが存在する受注候補タスクの関連情報を抽出し、その情報をもとに受注タスク優先度を算出する（ステップＳ１９０４）。図２０に示す例では、受注ステータスが「受注希望あり」となっている７つのサブタスクが受注候補タスクとして抽出される。

受注タスク選定モジュール１８１０では、タスク分割優先度とワーカー優先度から算出される受注タスク優先度をもとに受注するサブタスクを選定する。図２１に受注タスク選定のための優先度の算出ロジック例を示す。この例では、タスク分割優先度として受注するタスクの業務量、ワーカー優先度として受注希望ワーカーの受注業務のスキルレベル、過去の業務評価を用いて優先度を算出している。
図２１は、算出ロジック例を示す説明図である。受注タスク選定優先度算出ロジック２１００は、タスク分割優先度欄２１１０の受注タスク割合欄２１１２について優先度欄２１３０が５段階あり、ワーカー優先度欄２１２０の過去の業務評価欄２１２２、ワーカー優先度欄２１２０のスキルレベル欄２１２４についてそれぞれ優先度欄２１３０が５段階あることを示している。なお、受注タスク割合とは、親タスクに対するサブタスクの割合を示す。優先度の値が高いほど、優先したいという要求が強いことを示している。

次に、受注候補タスクの中から優先度の高いサブタスクを抽出する（ステップＳ１９０８）。図２２に抽出された受注候補サブタスクの関連情報の例を示す。この例では、最も優先度が高いサブタスクとして、優先度＝１３のサブタスクＩＤ＝Ｔ０１０６８１Ａのサブタスクが抽出される。
図２２は、受注候補サブタスク情報テーブル２２００のデータ構造例を示す説明図である。受注候補サブタスク情報テーブル２２００は、サブタスクＩＤ欄２２０２、サブタスク業務量欄２２０４、タスク分割優先度欄２２０６、受注希望ワーカーＩＤ欄２２０８、ワーカー業務評価欄２２１０、受注業務スキルレベル欄２２１２、ワーカー優先度欄２２１４、受注タスク優先度欄２２１６、受注ステータス欄２２１８を有している。サブタスクＩＤ欄２２０２は、サブタスクＩＤを記憶している。サブタスク業務量欄２２０４は、サブタスク業務量を記憶している。タスク分割優先度欄２２０６は、タスク分割優先度を記憶している。なお、サブタスク業務量欄２２０４内の右側の欄は、親タスクに対するサブタスクの割合を記憶している。受注希望ワーカーＩＤ欄２２０８は、受注希望ワーカーＩＤを記憶している。ワーカー業務評価欄２２１０は、ワーカー業務評価を記憶している。受注業務スキルレベル欄２２１２は、受注業務スキルレベルを記憶している。ワーカー優先度欄２２１４は、ワーカー優先度を記憶している。受注タスク優先度欄２２１６は、受注タスク優先度を記憶している。この例では受注タスク優先度を「タスク分割優先度（タスク分割優先度欄２２０６内の値）＋ワーカー優先度（ワーカー優先度欄２２１４内の値）」で算出している。受注ステータス欄２２１８は、受注ステータスを記憶している。

次に、配分タスク業務量とサブタスク業務量を比較する（ステップＳ１９１０）。この例では、配分タスク業務量（１２，０００文字）とサブタスク業務量（６，０００文字）を比較し、配分タスク業務量の方が大きい（ステップＳ１９１０でＹｅｓ）ので、サブタスクＩＤ＝Ｔ０１０６８１Ａの受注を確定し、受注ステータスを「受注確定」に変更する（ステップＳ１９１２）。サブタスクＩＤ＝Ｔ０１０６８１Ａの受注が確定したことから、受注対象の業務量（配分タスク業務量）は減少し、配分タスク業務量として（１２，０００文字−６，０００文字＝）６，０００文字が設定される（ステップＳ１９１４）。
受注タスク選定モジュール１８１０は、受注候補サブタスクに対して受注タスク優先度順に上記の処理を配分タスク業務量＝０となるまで繰り返し、受注タスクを選定する。この例では、図２３の受注候補サブタスク情報例（２）に示す通り、サブタスクＩＤ＝Ｔ０１０６８１Ａ、Ｔ０１０６８２Ａ、Ｔ０１０６８３Ａ、Ｔ０１０６８３Ｃの４つのサブタスクが受注タスクとして選定され、受注希望ワーカーに受注成立情報が通知される。なお、配分タスク業務量＝０とならず、配分すべきタスクが残ってしまった場合には、受注候補ワーカーに対して条件を変更して再提示するなどの処理を行うようにしてもよい。

図２３は、受注候補サブタスク情報テーブル２３００のデータ構造例を示す説明図である。受注候補サブタスク情報テーブル２３００は、サブタスクＩＤ欄２３０２、サブタスク業務量欄２３０４、タスク分割優先度欄２３０６、受注希望ワーカーＩＤ欄２３０８、ワーカー業務評価欄２３１０、受注業務スキルレベル欄２３１２、ワーカー優先度欄２３１４、受注タスク優先度欄２３１６、受注ステータス欄２３１８を有している。サブタスクＩＤ欄２３０２は、サブタスクＩＤを記憶している。サブタスク業務量欄２３０４は、サブタスク業務量を記憶している。タスク分割優先度欄２３０６は、タスク分割優先度を記憶している。受注希望ワーカーＩＤ欄２３０８は、受注希望ワーカーＩＤを記憶している。ワーカー業務評価欄２３１０は、ワーカー業務評価を記憶している。受注業務スキルレベル欄２３１２は、受注業務スキルレベルを記憶している。ワーカー優先度欄２３１４は、ワーカー優先度を記憶している。受注タスク優先度欄２３１６は、受注タスク優先度を記憶している。受注ステータス欄２３１８は、受注ステータスを記憶している。
図２３の例では、受注ステータス欄２３１８に示すように、受注タスク優先度をもとに４つのサブタスクが受注対象タスクとして選定された状態（サブタスクＴ０１０６８１Ａ、Ｔ０１０６８２Ａ、Ｔ０１０６８３Ａ、Ｔ０１０６８３Ｃ）を示している。
このように第４の実施の形態によれば、タスクの受注率をあげるために、候補ワーカーの受注しやすい業務量にあわせて多くのパターンで細分化したサブタスクを作成し、候補ワーカーに提示した場合でも、自動的に受注するサブタスクを選定することが可能となり、発注者の受注タスク選定の負担を軽減することができる。

なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図２４に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ２４０１を用い、記憶装置としてＲＡＭ２４０２、ＲＯＭ２４０３、ＨＤ２４０４を用いている。ＨＤ２４０４として、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）を用いてもよい。タスク情報登録・更新モジュール１０５、タスク制御モジュール１１０、タスク情報管理モジュール１１５、タスク分割モジュール１２５、受注タスク規模推計モジュール１３０、ワーカー情報管理モジュール１３５、タスク情報提示モジュール１４５、ワーカー情報登録・更新モジュール１５０、タスク分割要求入力モジュール１０１０、タスク分割要求通知モジュール１０２０、タスク分割要求処理モジュール１０３０、タスク分割数判定モジュール１５１０、受注タスク選定モジュール１８１０等のプログラムを実行するＣＰＵ２４０１と、そのプログラムやデータを記憶するＲＡＭ２４０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ２４０３と、タスク情報記憶モジュール１２０、ワーカー情報記憶モジュール１４０としての機能を有する補助記憶装置（フラッシュメモリ等であってもよい）であるＨＤ２４０４と、キーボード、マウス、タッチパネル、マイク等に対する利用者の操作に基づいてデータを受け付ける受付装置２４０６と、ＣＲＴ、液晶ディスプレイ、スピーカー等の出力装置２４０５と、ネットワークインターフェースカード等の通信ネットワークと接続するための通信回線インターフェース２４０７、そして、それらをつないでデータのやりとりをするためのバス２４０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。

前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図２４に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図２４に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続しているような形態でもよく、さらに図２４に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器（携帯電話、スマートフォン、モバイル機器、ウェアラブルコンピュータ等を含む）、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）などに組み込まれていてもよい。

なお、前述の各種の実施の形態を組み合わせてもよく（例えば、ある実施の形態内のモジュールを他の実施の形態内に追加する、入れ替えをする等も含む）、また、各モジュールの処理内容として背景技術で説明した技術を採用してもよい。
また、前述の実施の形態の説明において、予め定められた値との比較において、「以上」、「以下」、「より大きい」、「より小さい（未満）」としたものは、その組み合わせに矛盾が生じない限り、それぞれ「より大きい」、「より小さい（未満）」、「以上」、「以下」としてもよい。
なお、前述の実施の形態において、「提示」としたものは、ディスプレイ等の表示装置への表示の他に、プリンター等の印刷装置への印刷、スピーカー等の音声出力装置への音声の出力、振動等があり、それらの組み合わせであってもよい。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラム又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。

１００…情報処理装置
１０５…タスク情報登録・更新モジュール
１１０…タスク制御モジュール
１１５…タスク情報管理モジュール
１２０…タスク情報記憶モジュール
１２５…タスク分割モジュール
１３０…受注タスク規模推計モジュール
１３５…ワーカー情報管理モジュール
１４０…ワーカー情報記憶モジュール
１４５…タスク情報提示モジュール
１５０…ワーカー情報登録・更新モジュール
１７０…発注者用情報処理装置
１８０…ワーカー用情報処理装置
１０００…情報処理装置
１０１０…タスク分割要求入力モジュール
１０２０…タスク分割要求通知モジュール
１０３０…タスク分割要求処理モジュール
１５００…情報処理装置
１５１０…タスク分割数判定モジュール
１８００…情報処理装置
１８１０…受注タスク選定モジュール

Claims (6)

1. クラウドソーシングシステムに登録されたワーカーの受注履歴から該ワーカーの受注可能なタスクの規模を算出する算出手段と、
   タスクを前記算出手段によって算出された規模に応じて分割する分割手段と、
   前記ワーカーに前記分割されたタスクを提示する提示手段
   を有する情報処理装置。
2. 前記ワーカーからタスクの分割要求を受け付ける受付手段
   をさらに有し、
   前記分割手段は、前記受付手段が分割要求を受け付けた場合に、前記タスクの分割処理を行う、
   請求項１に記載の情報処理装置。
3. 前記受付手段が分割要求を受け付けた場合に、前記タスクの発注者に通知する通知手段と、
   前記発注者による前記タスクの分割の可否の判定結果を受け付ける第２の受付手段
   をさらに有し、
   前記分割手段は、前記第２の受付手段が分割可の判定結果を受け付けた場合に、前記タスクの分割処理を行う、
   請求項２に記載の情報処理装置。
4. 前記分割手段は、分割されたタスクを受注可能なワーカー数が予め定められた閾値より多い又は以上になるように、分割処理を行う、
   請求項１から３のいずれか一項に記載の情報処理装置。
5. 前記分割手段によって分割されたタスクの優先度にしたがって、前記ワーカーが受注するタスクを選定する選定手段
   をさらに有する請求項１から４のいずれか一項に記載の情報処理装置。
6. コンピュータを、
   クラウドソーシングシステムに登録されたワーカーの受注履歴から該ワーカーの受注可能なタスクの規模を算出する算出手段と、
   タスクを前記算出手段によって算出された規模に応じて分割する分割手段と、
   前記ワーカーに前記分割されたタスクを提示する提示手段
   として機能させるための情報処理プログラム。

Images