JP5749561B2 - スケジューリング装置及びプログラム - Google Patents

Description

本発明は、スケジューリング装置及びプログラムに係り、より詳しくは、少なくとも一部の期間で並列して進行する複数のプロジェクトを構成する各タスクに対して、サービスを提供するリソースを割り当てるスケジューリング装置及びプログラムに関する。

従来、生産工程等の複数の工程を含む作業工程の工程計画を作成するスケジューリング方法が提案されている（例えば特許文献１〜５、非特許文献１〜５等参照）。

これまでの工程計画手法は、実際には優先順位を比較できない並列タスク相互の関係を、順列化可能な形に置き換えてスケジューリングを行うものが主流である。置き換える方法には、複数の並列進行する工区を均質なものとみなして１つにまとめる（例えば集合住宅がフロア単位で進行するとする考え方が該当する）“タクト化”や、サービスを提供するリソースの競合を回避するためのバッファを置く“クリティカルチェーン法”等がある。

しかしながら、これらの方法による置き換えは、実態と差異が生じるため、プロジェクトバッファ等、ある種のムダを許容せざるを得ないという本質的な問題を抱えている。また、並列タスク相互の関係を考慮しない工程計画手法では、ある職能のリソース配分の変動がクリティカルパスや直接後続しない職能の能率が変動するといった現象を事前に発見できないという問題があった。このような問題に対して、製造業の分野では、各種のシミュレーションを応用したスケジュール方法が提案されているが、これらの既知の手法は、流れ作業を前提としたスケジューリング手法となっており、結局は全順序型のスケジューリング問題が対象となる。

また、労働者の視点からスケジュールの問題を認識することで分散的なタスクに対するスケジュールを支援する手法として、マルチエージェントシステムを利用した技術が提案されている。

しかしながら、マルチエージェントシステムでは、労働者であるエージェントが行動ルールに基づいて自身に課されたタスクを自律的に実行するなど、エージェント個体の意思決定をモデル化しているため、労働者数や判断条件が増えるほどプログラム処理の負荷や時間が増大するという問題があった。

例えば、４０階建てのマンションを想定した場合、随時６００人近い労働者が同時に意思決定を行っていることになり、シミュレーションが完了するまでに数日を要することもあった。実務の効率化を図るためには、汎用的なパソコンで会議中に結果が表示されるような処理速度が必要である。あるいは、マルチエージェントシステムを利用し、シミュレーションのログから得られた労働者の手待ちを解消するアルゴリズムを構築し、指定工期での完了を達成するための最小必要労働者数を職能ごとに導出する手法を考えることもできる。しかしながら、この場合、必要となる労働者数はシミュレーションが完了した後でなければ把握できない。現実的な問題として、保有しているリソースを効率的に活用して工期を満足させる結果を見出す必要がある。例えば、多能工の労働者を育成し、そのような労働者を意図的に温存することにより、ピーク時のワークバランスを平準化する方策が考えられる。また、余剰の保有リソースに公平な労働機会を提供することも、現実的な課題になりつつある。

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

"Critical Chain", Eliyahu M. Goldratt,North River Pr ,1997 "エージェントベースモデリングによる集合住宅内装工事計画の可視化に関する研究"、建築学会 第７回「建築生産の自動化における可視化技術の応用」ワークショップ 梗概集、2011 "集合住宅内装工程計画に対する エージェントベースモデリングの適用"、東京工業大学平成21年度知能システム科学専攻修士論文、2011 "集合住宅内装工事計画における非定型要因のエージェントベースモデリングによる影響分析"、JAWS2010梗概集、2010 "Analyzing Construction Plannning of Interior Finish Work of Apartment Building"、ABSEL2011、2011

しかしながら、上記従来技術では、複数のタスクが実行可能な資源（多能工的職能・能力を持つ人や設備）が同時並行あるいは逐次的に行う作業を多数のプロジェクトに割当てる問題を、効率的、短時間で計算、可視化することはできない、という問題があった。

本発明は、上記事実に鑑みて成されたものであり、少なくとも一部の期間で重複して進行する複数のプロジェクトを構成する複数のタスクに対して、タスクを実行するリソースを効率よく短時間で割り当てることができるスケジューリング装置及びプログラムを提供することを目的とする。

上記目的を達成するために、請求項１記載の発明のスケジューリング装置は、少なくとも一部の期間で重複して進行する複数のプロジェクトの各々について前記プロジェクトを構成する複数のタスクの半順序関係を定義した実行順序データと、前記複数のタスクの遂行時間を定義したタスク遂行時間データと、前記複数のタスクと前記複数のタスクの各々を実行可能な職能タイプとの対応関係を定義した第１の対応関係データと、前記職能タイプと前記タスクを実行する複数のリソースとの対応関係を定義した第２の対応関係データと、に基づいて、前記複数のプロジェクトを構成するタスクのうち未終了のタスクから、着手可能な着手可能タスクを抽出する抽出手段と、前記複数のリソースのうち前記着手可能タスクを実行可能で且つ他のタスクに未割り当てのリソースを割り当てる割当手段と、前記複数のプロジェクトの全タスクが終了するまで、予め定めた時間毎に前記割当手段による前記リソースの割り当てが実行されるように制御する制御手段と、を含み、前記第１の対応関係データにより定義された前記対応関係は、タスク職能関数によって定義され、前記タスク職能関数は、１つの前記職能タイプに対して複数のタスクを割り当て可能であることを特徴とする。

この発明によれば、少なくとも一部の期間で重複して進行する複数のプロジェクトの各々について前記プロジェクトを構成する複数のタスクの半順序関係を定義した実行順序データと、前記複数のタスクの遂行時間を定義したタスク遂行時間データと、前記複数のタスクと前記複数のタスクの各々を実行可能な職能タイプとの対応関係を定義した第１の対応関係データと、前記職能タイプと前記タスクを実行する複数のリソースとの対応関係を定義した第２の対応関係データと、に基づいて、前記複数のプロジェクトを構成するタスクのうち未終了のタスクから、着手可能な着手可能タスクを抽出する抽出手段と、前記複数のリソースのうち前記着手可能タスクを実行可能で且つ他のタスクに未割り当てのリソースを割り当て、前記複数のプロジェクトの全タスクが終了するまで、予め定めた時間毎に前記割り当てステップよる前記リソースの割り当てが実行されるように制御する。このため、少なくとも一部の期間で重複して進行する複数のプロジェクトを構成する複数のタスクに対して、タスクを実行するリソースを効率よく短時間で割り当てることができる。

なお、請求項２に記載したように、前記遂行時間は、タスク推定遂行時間割当関数によって定義されると共に、前記タスク推定遂行時間割当関数を変更することによって変更可能であり、前記抽出手段は、前記遂行時間が変更された場合に、前記着手可能タスクを再抽出するようにしてもよい。
また、請求項３に記載したように、前記実行順序データは、前記複数のプロジェクトの各々について、異なるタスクを定義可能である構成としてもよい。
また、請求項４に記載したように、前記複数のプロジェクトは、離散時間で管理される構成としてもよい。
また、請求項５に記載したように、前記複数のプロジェクトの各タスクに対する前記予め定めた時間毎の前記リソースの割り当て結果を示すスケジュール表を生成し、生成したスケジュール表を出力するスケジュール表出力手段を備えた構成としてもよい。

これにより、各プロジェクトの各タスクに対して、リソースがどのような日程で割り当てられたのかを容易に把握することができる。

また、請求項６に記載したように、前記スケジュール表を、前記複数のリソースの各々に対する前記予め定めた時間毎の前記タスクの割り当て結果を示すスケジュール表に並び替える並替手段を備えた構成としてもよい。

これにより、各リソースが担当するタスクがどのような日程で割り当てられたのかを容易に把握することができる。

請求項７記載の発明のスケジューリングプログラムは、コンピュータを、請求項１〜請求項６の何れか１項に記載のスケジューリング装置を構成する各手段として機能させるためのスケジューリングプログラムである。

以上説明したように、本発明によれば、少なくとも一部の期間で重複して進行する複数のプロジェクトを構成する複数のタスクに対して、タスクを実行するリソースを効率よく短時間で割り当てることができる、という優れた効果を有する。

スケジューリング装置のブロック図である。 タスク集合の概念を示す図である。 スケジューリング装置のＣＰＵで実行される処理のフローチャートである。 タスクと職能とワーカーとの関係を示す概念図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトの進行を示すイメージ図である。 プロジェクトのスケジュール表の一例を示す図である。 ワーカーのスケジュール表の一例を示す図である。 プロジェクトのスケジュール表の一例を示す図である。 プロジェクトのスケジュール表の一例を示す図である。

以下、図面を参照して本発明の実施の形態の一例について詳細に説明する。

図１には、本実施形態に係るスケジューリング装置１０の概略ブロック図を示した。同図に示すように、スケジューリング装置１０は、コンピュータ２０を含んで構成されていり、例えば一般的なパーソナルコンピュータの構成とすることができる。

コンピュータ２０は、ＣＰＵ２０Ａ、ＲＯＭ２０Ｂ、ＲＡＭ２０Ｃ、不揮発性メモリ２０Ｄ、及び入出力インターフェース（Ｉ／Ｏ）２０Ｅがバス２０Ｆを介して各々接続された構成となっている。

Ｉ／Ｏ２０Ｅには、キーボードやマウス等を含んで構成された操作部２２、液晶ディスプレイ等で構成された表示部２４、及び後述する処理の制御プログラム等を記憶するためのハードディスク２６等が接続されている。

なお、後述する処理の制御プログラムは、本実施形態では一例としてハードディスク２６に予め記憶され、ＣＰＵ２０Ａがこの予め記憶された制御プログラムを読み込むことにより実行される。また、ＣＤ−ＲＯＭ等の記録媒体に制御プログラムを記録し、これをＣＤ−ＲＯＭドライブ等で読み込むことにより実行するようにしてもよい。

本実施形態に係るスケジューリング装置１０は、少なくとも一部の期間で重複して進行する複数のプロジェクトを構成する複数のタスクに対して、タスクを実行するリソースを割り当てるものである。

ここで、プロジェクトは、様々な事業分野において実行される各種の計画が含まれる。例えば建築分野であれば、プロジェクトは、集合住宅の建築における各住戸の建築計画に該当する。この場合、プロジェクトの数は住戸の数に相当し、住戸の数に相当する複数のプロジェクトは並列進行可能である。そして、各プロジェクトには、内装工事、電気工事、ダクト工事、給排水工事等、複数のタスクが含まれる。これらのタスクの実行には、特定の職能を備えたリソース、例えばワーカー（職人、労働者等）が必要となる。例えば内装工や電気工、ダクト工、給排水工等である。本実施形態に係るスケジューリング装置１０では、いわゆる集合論を用いて、一例として、上記の職能を有する職人（リソース）を、並列して進行する各住戸の建築（プロジェクト）における各種工事（タスク）に対して効率よく短時間で割り当てる。なお、リソースにはワーカーが含まれ、ワーカーには職人や労働者等が含まれる。

また、プロジェクト、タスク、リソースは上記の例に限られない。例えば、医療分野であれば、プロジェクトは、患者の治療計画に該当し、タスクは、内科治療、外科治療等に該当し、リソースは内科医、外科医等に該当する。

本実施形態では、プロジェクトの表現を、タスクをノード、タスク間順序を集合論に基づく半順序集合（POS:Partially Ordered Set）で表し、タスク集合を終了タスク集合と未終了タスク集合に分割する。また、未終了集合の極小元集合を着手可能タスク集合とし、それを更に仕掛タスク集合と開始可能タスク集合に分割する。そして、これらのタスク集合の動的変化と、職能とタスクとの関係と、に基づいて、特定の職能を有するワーカーをタスクに動的に割り当てる。

＜タスクと職能集合＞

本実施形態では、集合論に基づいて、（１）タスク集合、（２）職能集合、（３）タスク職能関係、（４）労働者集合と職能割当関数、（５）ワーカーに対する実行可能タスク集合、（６）タイムカウンター集合とタイムインターバル集合、（７）タスクの推定遂行時間とタスク推定遂行時間割当関数を以下のように定義する。

（１）タスク集合：Task Set
各プロジェクトに含まれるタスクの集合であるタスク集合TASKSを一例として以下のように定義する。
TASKS={101, 102, 103,….,Start, End}

また、特殊タスクの開始と終了を表すタスク集合StartEndSetを一例として以下のように定義する。
StartEndSet={Start, End }

なお、全てのタスク集合は、StartEndSetに含まれる開始のシンボルである最小元Startと終了のシンボルである最大元Endを含む。

（２）職能集合：PROFS:Profession Set
ワーカーが有する職能の集合である職能集合PROFSを一例として以下のように定義する。
PROFS={電気工、ダクト工、給排水工、・・・}

（３）タスク職能関係：Task Profession Relation:TPR
どのタスクがどの職能によって遂行可能かの割当を表すタスク職能関係TPRを以下のように定義する。
TPR⊆TASKS×PROFS

なお、特殊な条件では、１つのタスクは特定の職能でしか実行できないという制限がつく。これをタスク職能関数と呼ぶ（Task Profession Function:TPF)。

いずれにせよ特定の職能は一般に複数のタスクを遂行できる。タスク職能関数TPFが１：１関数のときは、１職種に対して１タスクの以下の限定された関係が成り立つ。
TRF:TASKS→PROFS

（４）労働者集合と職能割当関数：Profession Assignment Function:ProfAssignF
労働者集合(Worker Set) をΩとする。ワーカー（労働者）はそれぞれ職能を割り当てられるものとし、職能割当関数ProfAssignFを以下のように定義する。
ProfAssignF:Ω→PROFS

（５）ワーカーωに対する実行可能タスク集合：POS_TASKS[ω]:Posible Task Set for ω
タスク職能関係の下での、実行可能タスク集合POS_TASKS[ω]を以下のように定義する。
POS_TASKS[ω]={ x | <x,y>∈TPR, y=ProfAssignF(ω)}

また、タスク職能関数の下での、実行可能タスク集合POS_TASKS[ω]を以下のように定義する。
POS_TASKS[ω]={ x | x∈TRF-1(y), y=ProfAssignF(ω)}

（６）タイムカウンター集合：TimeCounter={0,1,2,…}とタイムインターバル集合TimeInterval
本実施形態では、０を含む自然数でタイムカウンター集合とタイムインターバル集合を定義する。

（７）タスクの推定遂行時間：EstTimeAcomp:Estimated Time for Accomplishmentと、タスクへの推定遂行時間割当て関数：EstTimeAcompF:Estimated Time for Task Accomplishment Function

本実施形態では、タスク毎に標準の推定遂行時間EstTimeAcompがタイムインターバル集合TimeIntervalへのタスク推定遂行時間割当て関数EstTimeAcompFとして定義される。
EstTimeAcompF:TASKS→TimeInterval

なお、本実施形態では、タイムインターバル集合TimeIntervalは０を含む自然数とする。

＜プロジェクトの定義と極小元集合＞
本実施形態では、（１）プロジェクト、（２）終了タスク集合、未終了タスク集合、着手可能集合を以下のように定義する。

（１）プロジェクト：タスク集合
タスク集合TASKSに半順序関係を定義したプロジェクトPを以下のように定義する。
P=（TASKS,<）
ただし、プロジェクトPは最小元Startと最大元Endを持つ。

例えば、以下のようなタスク集合TASKSを定義する。なお、数字の本来の大小はここでは関係ない。
TASKS={Start,1,2,3,4,5,6,7,End}

そして、各タスクに以下のような関係があるものとする。Start<1,Start<2,1<3,2<3,3<4,3<5,4<6,5<7,6<7,7<End

この場合、各タスクの関係は以下のように表せる。

5 → → → 7 → E
↑ ↑
S → １ → 3 → 4 → 6
↓→ ２→ ↑

これは、ノードをタスク集合の元、アークを半順序関係と見なせばグラフ表現となるが、しばしば用いられるタスクをアークとした表現ではない。

（２）終了タスク集合、未終了タスク集合、着手可能タスク集合
プロジェクトP=(TASKS,<)に対して、終了タスク集合Finished Task Set:Fin_TASKS[P]、未終了タスク集合Unfinished Task Set:UFin_TASKS[P]を以下のように定義する。
Fin_TASKS[P]⊆TASKS-{Start}
UFin_TASKS[P]⊆TASKS-{Start}

ただし、終了タスク集合Fin_TASKS[P]、未終了タスク集合UFin_TASKS[P]には最小元Startは入らないものとする。また、終了タスク集合Fin_TASKS[P]、未終了タスク集合UFin_TASKS[P]に対して以下が成り立つ。
Fin_TASKS[P] ∩ UFin_TASKS[P]＝φ
Fin_TASKS[P] ∪ UFin_TASKS[P]＝TASKS-{Start}

また、着手可能タスク集合Able to Begin Task Set:ABegin_TASKS[P]を以下のように定義する。
ABegin_TASKS[P]⊆UFin_TASKS[P]
ABegin_TASKS[P]={x | ∀y∈UFin_TASKS[P] y<x→y=x, x∈UFin_TASKS[P]}

すなわち、着手可能タスク集合は、未終了タスク集合の極小元の集合となる。

また、仕掛タスク集合Task In Process Set:TaskInProgS[P]をプロジェクトPの着手可能タスク集合ABegin_TASKS[P]の部分集合と捉え、これにより着手中の仕掛タスク集合を定義する。すなわち、仕掛タスク集合TaskInProgS[P]は以下のように定義される。
TaskInProgS[P]⊆ABegin_TASKS[P]

これらの定義から、タスクは以下のように進行する。すなわち、未終了タスク集合から、その極小元集合が着手可能タスク集合として求められ、その着手可能タスク集合のうち、リソースの割当てが行われたタスクについては、仕掛タスク集合と認識される。ただしもとの着手可能タスク集合は未終了タスク集合の極小元の集合なので、一部が仕掛タスクと認識されても、それ自体はタスクが終了しない限り変化しない。その意味では、実際に作業中でない開始可能タスク集合を開始可能タスク集合として把握しておく必要がある。

また、開始可能タスク集合Startable Task Set:StartTaskS[P]を以下のように定義する。
StartTaskS[P]=ABegin_TASKS[P]-TaskInProgS[P]

ここで、一つのプロジェクトの中である時点で開始可能なタスクは開始可能タスク集合StartTaskS[P]に含まれ、開始中であるが未終了の仕掛タスクは 仕掛タスク集合TaskInProgS[P]に含まれる。

また、終了したタスクは、終了タスク集合Fin_TASKS[P]へと移り、次の未終了タスク集合UFin_TASKS[P]とそれに応じた着手可能タスク集合ABegin_TASKS[P]が計算される。これらは何れもタスク集合が有限集合であることから容易に求められる。

図２には、集合論により表現された各タスク集合及びリソース（労働者）の割当の概念図を示した。

（３）サブプロジェクト（Y,<）
P=(X,<)をプロジェクト、Xはそのタスク集合とする。この場合、任意のタスク集合の部分集合Y⊆Xに対して、そこに制限されたプロジェクト（Y,<）が定義される。これをP=(X,<)のサブプロジェクトと呼ぶ。

（４）プロジェクト進行：Project Progress at Time t:ProjProg[P](t)
プロジェクトP=(X,<)に対する時間tでのプロジェクト進行ProjProg[P](t)は次の集合時間関数の組みで示される。
ProjProg[P](t)=(X,Fin_TASKS[P](t),UFin_TASKS[P](t),ABegin_TASKS[P](t),TaskInProgS[P](t),StartTaskS[P](t))
ただし、
ProjProg[P](0)=(X,φ,X-{Start},ABegin_TASKS[P](0),φ,StartTaskS[P](0))
となる。また、上記の定義から、
StartTaskS[P](0)=ABegin_TASKS[P](0)、かつ
ABegin_TASKS[P](0)={x | ∀y∈X-{Start} y<x→y=x, x∈X-{Start}}
となる。

＜プロジェクト集合とプロジェクト集合に対するタスク割当て＞
ここでは、単一のプロジェクトではなく、プロジェクトの集合に対して、終了タスク集合、未終了タスク集合、着手可能タスク集合、仕掛タスク集合、開始可能タスク集合を定義する。なお、ワーカω∈Ωの実行可能タスク集合：POS_TASKS[ω]は既に定義した。

（１）プロジェクト集合：ProS
プロジェクトを有限個集めた集合をプロジェクト集合Prosとして以下のように定義する。
ProS={P1,P2,…,Pn}

（２）プロジェクト集合に対する終了タスク集合、未終了タスク集合、着手可能タスク集合
プロジェクト集合ProSに対して、単一のプロジェクトに対して定義した、終了タスク集合、未終了タスク集合、着手可能タスク集合を、プロジェクト集合からタスク集合への集合関数として以下のように定義する。

まず、プロジェクト集合に対する終了タスク集合：Finished Task Set for Project Set:Fin_TASKS[ProS]を以下のように定義する。
Fin_TASKS[ProS]={ h | h:ProS→{ Fin_TASKS[P] | P∈ProS}
ここで、h(P)=Fin_TASKS[P]である。

同様に、未終了タスク集合、着手可能タスク集合も以下のように定義される。

プロジェクト集合に対する未終了タスク集合：Unfinished Task Set for Project Set:UFin_TASKS[ProS]を以下のように定義する。
UFin_TASKS[ProS]={ h | h:ProS→{ UFin_TASKS[P] | P∈ProS}

ここで、h(P)=UFin_TASKS[P]が上記と同様に集合関数として定義される。なお、終了タスク集合、未終了タスク集合には最小元Startは入らないものとする。

また、それぞれのプロジェクトのタスク名は、
Fin_TASKS[P] ∩ UFin_TASKS[P]＝φ for any P∈ProS
Fin_TASKS[P] ∪ UFin_TASKS[P]＝TASKS[P]-{Start} for any P∈ProS
となる。ただし、(TASKS[P],<)=Pとする。

なお、複数のプロジェクトでタスクを区別して割り当てるために、プロジェクトからの集合関数という形で例えば以下のように割り当てることとする。
h(P1)={基本墨出し}
h(P2)={基本墨出し, 排水配管, SP配管, UB組立}
h(P3)={基本墨出し, 排水配管}

また、プロジェクト集合に対する着手可能タスク集合：Able to Begin Task Set:ABegin_TASKS[ProS]を以下のように定義する。
ABegin_TASKS[ProS]⊆UFin_TASKS[ProS]
ABegin_TASKS[ProS]={ h | h:ProS→{ ABegin_TASKS[P] | P∈ProS}
ここで、h(P)=ABegin_TASKS[P]である。
ただし、
ABegin_TASKS[P]={x | ∀y∈UFin_TASKS[P] y<x→y=x, x∈UFin_TASKS[P]}
である。すなわち、プロジェクト集合Prosに対する着手可能タスク集合ABegin_TASKS[ProS]は、未終了タスク集合UFin_TASKS[ProS]の極小元の集合をプロジェクト毎に割り当てる集合関数として与えられる。

また、プロジェクト集合に対する仕掛タスク集合：Task In Process Set for Project Set:TaskInProgS[ProS]をプロジェクトPから仕掛タスク集合に対する集合関数として以下のように定義する。
TaskInProgS[ProS]={ h | h:ProS→{ TaskInProgS[P] | P∈ProS}
ここで、h(P)=TaskInProgS[P]である。
また、∀P∈ProS、TaskInProgS[P]⊆ABegin_TASKS[P]が成り立つ。

また、プロジェクト集合に対する開始可能タスク集合：Startable Task Set for Project Set:StartTaskS[ProS]をプロジェクトPから開始可能タスク集合に対する集合関数として以下のように定義する。
StartTaskS[ProS]={ h | h:ProS→{ StartTaskS[P] | P∈ProS}

これは離散時間システムではそれぞれの集合の計算の順序によって異なるが、それぞれのプロジェクトPについて、開始可能タスク集合StartTaskS[P]は、その時点で着手可能タスク集合にワーカーを割り当てて、仕掛タスク集合を計算し、これを差し引いた集合となる。

＜プロジェクトとプロジェクト集合への資源の割付け＞

ここでは、タスク職能関係と、ワーカー（例えば人）への職能割当関数POS_TASKS[ω]を用いて、個々のワーカーに対してタスクを割り当てることにより、プロジェクトへの人の割付を行うための枠組みを定式化する。ある時点t∈TimeCounter={0,1,2,…}の各々において、未終了タスク集合を計算し、そこから着手可能タスク集合を求め、それに対して仕事が割り当てられていないワーカーを割り当てる。これによって、仕掛タスク集合が計算され、その時点での残りの開始可能タスク集合も求まる。

そして、次の時点では、終了タスクや仕掛タスクを除いた新たな未終了タスク集合を計算する。

（１）プロジェクトとプロジェクト集合へのタスク割当て
プロジェクト進行：Project Progress at Time t:ProjProg[P](t)を以下のように定義する。

プロジェクトP=(X,<)に対する時間tでのプロジェクト進行Project Progress at Time t：ProjProg[P](t)は、（タスク集合X、終了タスク集合、未終了タスク集合、着手可能タスク集合、仕掛タスク集合、）からなる集合時間関数の組みとして以下のように定義される。
ProjProg[P](t)=(X,Fin_TASKS[P](t),UFin_TASKS[P](t),ABegin_TASKS[P](t),TaskInProgS[P](t),StartTaskS[P](t))
ただし、ｔ＝０、すなわち初期時点においては、
ProjProg[P](0)=(X,φ,X-{Start},ABegin_TASKS[P](0),φ,StartTaskS[P](0))
となる。また、上記の定義より、
StartTaskS[P](0)=ABegin_TASKS[P](0)、かつ
ABegin_TASKS[P](0)={x | ∀y∈X-{Start} y<x→y=x, x∈X-{Start}}
である。

（２）未割当労働者集合Ω[u]と割当済み労働者集合Ω[a]
未割当労働者集合Ω[u]と割当済み労働者集合Ω[a]については以下のような関係が成り立つ。
Ω(t)＝Ω[u](t) ∪ Ω[a](t)
Ω[u] ∩ Ω[a]=φ
Ω[u](0)＝Ω
Ω[a](0)=φ

（３）ある時点tでのプロジェクトPのタスクへの実行可能労働者集合割当関数：AssinableWorkers[P](a)
プロジェクトPのタスクへの実行可能労働者集合割当関数AssinableWorkers[P]は、以下のように定義される。
AssinableWorkers[P]:ABegin_TASKS[P]→Power(Ω[u](t))
ただし、P∈ProS、a∈ABegin_TASKS[P]のとき、
AssinableWorkers：ABegin_TASKS[P]→Power(Ω)
である。これは、ワーカーの集合をタスクに割り当てる集合関数であり、着手可能タスク集合に含まれるタスクに対して、そのタスクを実行可能な職能を持つワーカーを割当可能労働者集合から集めた集合を割り当てる集合関数である。また、
AssinableWorkers[P](a)={ω| a∈POS_TASKS[ω] | ω∈Ω[u] }、a∈ABegin_TASKS[P]
である。この割当集合が空であれば、タスク割当はできない。そのときはワーカーの集合としてφ（空集合）を割り当てるものとする。一般にタスクに必ずワーカーの集合が割り当てられる保証はなく、AssinableWorkers[a]=φ、つまりそのタスクを実行するワーカーの集合を割当できないタスクが存在する可能性がある。ここで、実行可能労働者集合割当関数AssinableWorkers[P](a)は、ワーカーにタスクを割り当てるのではなく、タスクにそれを遂行できる未割当のワーカーの集合を割り当てる集合関数となっている。

（４）担当労働者割当関数(Worker in Charge):WinCh
着手可能タスクABegin_TASKS[P]の各々に対して、割当可能労働者集合が割り当てられているとして、そこから実際に担当労働者（ワーカー）を割り当てる担当労働者割当関数(Worker in Charge):WinChを以下のように定義する。
WinCh[P]:ABegin_TASKS[P]→Ω[u]、P∈ProS
ここで担当労働者割当関数WinChは、次の条件を満たすものとする。
∀P,Q∈ProS ∀a∈ABegin_TASKS[P] ∀b∈ABegin_TASKS[Q] ∃ω∈Ω[u] WinCh[P](a)=WinCh[Q](b)=ω then P=Q & a=b

すなわち、担当労働者割当関数WinChでは、異なるプロジェクトあるいは異なるタスクに対して同一のワーカーが割り当てられることはないという条件を満たすものとする。

このような条件を満たす担当労働者割当関数WinCh[P]を定めることが、具体的に各時点でのワーカー（担当労働者）の担当タスクの割当を行う事に相当する。なお、この担当労働者割当関数WinCh[P]は、唯一に決まるものではなく、様々な割当法があり、割当法によってプロジェクトの進行速度や効率に大きな差がでる。

（５）最小人数最長工程単能工優先割当法
次に、プロジェクトの担当労働者を割り当てる担当労働者割当関数WinCh[P]の具体例について説明する。

まず、有限個のプロジェクトP∈ProSがあるとする。そして、
AssinableWorkers[P]：ABegin_TASKS[P]→Power(Ω)
によって求められた、AssinableWorkers[P](a)、a∈ABegin_TASKS[P]に含まれるワーカーの人数を、|AssinableWorkers[P](a)|で表す。

このとき、プロジェクトPi毎に、タスクa∈ABegin_TASKS[P]は割当可能労働者集合のサイズ、|AssinableWorkers[P](a)|が１のものから順に整列することができる。サイズがゼロ、すなわち担当労働者のいない割当可能労働者集合を持つタスクは、その時点での割当計算からは除外する。更に、割当可能労働者集合はP∈ProSについても併せて整列することができる。例えば、以下のようにサイズが１のものから順に整列することができる。
サイズ１：AssinableWorkers[P2](a3)、a3∈ABegin_TASKS[P2]、かつ、|AssinableWorkers[P2](a3)|=1
サイズ１：AssinableWorkers[P1](a2)、かつ、|AssinableWorkers[P1](a2)|=1
サイズ２：、、、、
このとき、割当可能労働者集合のサイズの小さい順で、かつ同じサイズの割当可能労働者集合については、そのタスクの遂行時間の長いタスクから、タスクにワーカーを割り当てるタスクへの担当労働者の割付方法を、本実施形態では最小人数最長工程優先割当法と呼ぶ。この最少人数最長工程優先割当法のアルゴリズムは以下のようになる。

（ｉ）まず、サイズが１の割当可能労働者集合を持つタスクから最長のタスクの実行時間のプロジェクトPとタスクaを選んで、これに割当可能労働者集合AssinableWorkers[P](a)の中から（長さ１の場合は一人しかワーカーは含まれない）、ワーカーを割り当てる。

（ｉｉ）（ｉ）でサイズが１のタスクがないときは、サイズが２の割当可能労働者集合について割当を行う。このとき、２人以上のワーカーがいるときには、１つの職能を有する単能工のワーカーを優先して割り当てる。条件が同じ場合には、確率的に一人のワーカーを選択する。

（ｉｉｉ）一人のワーカーの割当が終了すると、割当可能労働者集合が変化するので、それを再計算して、改めて、（ｉ）のワーカーの割当を行う。

（ｉｖ）ワーカーを割り付けるべきタスクがなくなるか、あるいはタスクに割り当てるワーカーがなくなるまで上記の割り当てを行う。

＜タスクとプロジェクトの小さな抽象事例＞

以下では、７つのタスクと４つの職能、１０人のワーカーのケースにおけるワーカーの割当の具体例について説明する。

（１）タスク集合、職能集合、タスク職能関数、労働者集合と職能割当て関数、ワーカーに対する実行可能タスク集合、タスクの推定遂行時間割当

（ｉ）タスク集合:Task Setとプロジェクト
７つのタスクを有するタスク集合TASKSは以下のように定義される。
TASKS={Start,1,2,3,4,5,6,7,End}

そして、各タスクには、実行順序に関して以下のような関係があるものとする。Start<1,Start<2,1<3,2<3,3<4,3<5,4<6,5<7,6<7,7<End

この場合、各タスクの関係（実行順序）は以下のように表せる。

5 → → → 7 → E
↑ ↑
S → １ → 3 → 4 → 6
↓→ ２→ ↑

（ｉｉ）職能集合Profession Set:PROFS
４つの職能を有する職能集合PROFSは、以下のように定義される。
PROFS={α,β,γ,δ}

（ｉｉｉ）タスク職能関数:TRF:TASKS→PROFS
タスク職能関数TRFは、タスク１〜７に対して、以下のように職能を割り当てる。
TRF(1)=α,TRF(2)=β,TRF(3)=α,TRF(4)=γ,TRF(5)=δ,TRF(6)=δ,TRF(7)=γ

（ｉｖ）労働者集合と職能割当関数：Profession Assignment Function:ProfAssignF
労働者集合Ωが１０人のワーカーで構成される場合、以下のように定義される。
Ω={w1,w2,w3,w4,w5,w6,w7,w8,w9,w10}

そして、職能割当関数ProfAssignFは、労働者集合Ωの各ワーカーに対して、以下のように職能を割り当てる。なお、各ワーカーには予め職能が割り当てられる。
ProfAssignF:Ω→PROFS
ProfAssignF(w1)=ProfAssignF(w2)=α
ProfAssignF(w3)=ProfAssignF(w4)=ProfAssignF(w5)=β
ProfAssignF(w6)=γ
ProfAssignF(w7)=ProfAssignF(w8)=ProfAssignF(w9)=ProfAssignF(w10)=δ

（ｖ）ワーカーωに対する実行可能タスク集合：POS_TASKS[ω]:Posible Task Set for ω
上記のように各ワーカーに対して職能が割り当てられると、各ワーカーに対する実行可能タスク集合POS_TASKS[ω]は、以下のようになる。
POS_TASKS[w1]=POS_TASKS[w2]={1,3},
POS_TASKS[w3]=POS_TASKS[w4]=POS_TASKS[w5]={2},
POS_TASKS[w6]={4,7},
POS_TASKS[w7]=POS_TASKS[w8]=POS_TASKS[w9]=POS_TASKS[w10]={5,6}

（ｖｉ)タイムカウンター集合とタイムインターバル集合
タイムカウンター集合はTimeCounter={0,1,2,…}、タイムインターバル集合はTimeIntervalと定義する。

（ｖｉｉ）タスクの推定遂行時間割当て関数：EstTimeAcompF:TASKS→TimeInterval
推定遂行時間割当関数EstTimeAcompFは、各タスクに対して、推定遂行時間を以下のように与える。
EstTimeAcompF(1)=3,
EstTimeAcompF(2)=5,
EstTimeAcompF(3)=1,
EstTimeAcompF(4)=7,
EstTimeAcompF(5)=2,
EstTimeAcompF(6)=10,
EstTimeAcompF(7)=5

（２）終了タスク集合、未終了タスク集合、着手可能タスク集合、ワーカー割当計算
（ｉ）終了タスク集合、未終了タスク集合、着手可能タスク集合、仕掛タスク集合、開始可能タスク集合
ある時点ｔにおける終了タスク集合、未終了タスク集合、着手可能タスク集合、仕掛タスク集合、開始可能タスク集合は以下のように定義される。
終了タスク集合：Finished Task Set:Fin_TASKS[P](t)
未終了タスク集合：Unfinished Task Set:UFin_TASKS[P](t)
着手可能タスク集合：ABegin_TASKS[P](t)
仕掛タスク集合：TaskInProgS[P](t)
開始可能タスク集合：StartTaskS[P](t)

プロジェクトP=(X,<)に対する時間tでのプロジェクト進行ProjProg[P](t)は以下のように表される。

プロジェクト進行：ProjProg[P](t)=(X,Fin_TASKS[P](t),UFin_TASKS[P](t),ABegin_TASKS[P](t),TaskInProgS[P](t),StartTaskS[P](t))

（ｉｉ）初期（t=0）での計算
t=0の初期時点では、終了タスク集合Fin_TASKS[P](0)、未終了タスク集合UFin_TASKS[P](0)、着手可能タスク集合ABegin_TASKS[P](0)、仕掛タスク集合TaskInProgS[P](0)、開始可能タスク集合StartTaskS[P](0)、プロジェクト進行ProjProg[P](t)は以下のようになる。
Fin_TASKS[P](0)=空集合
UFin_TASKS[P](0)={1,2,3,4,5,6,7,End}
ABegin_TASKS[P](0)={1,2}
TaskInProgS[P](0)=空集合
StartTaskS[P](0)={1,2,3,4,5,6,7,End}
ProjProg[P](t)=({Start,1,2,3,4,5,6,7,End},φ,{1,2,3,4,5,6,7,End},{1,2},φ,{1,2,3,4,5,6,7,End}}

（ｉｉｉ）第１期（t=1）での計算
第１期の最初（のステージ）でタスクが開始される。このため、t=1の初期時点では、終了タスク集合Fin_TASKS[P](1)、未終了タスク集合UFin_TASKS[P](1)、着手可能タスク集合ABegin_TASKS[P](1)、仕掛タスク集合TaskInProgS[P](1)、開始可能タスク集合StartTaskS[P](1)、プロジェクト進行ProjProg[P](t)はt=0の場合と同様となる。

（ｉｖ）第k期（t=k）での計算
第k期の最初（のステージ）で、終了タスクが計算され、終了したタスクは、終了タスク集合へと移り、次の未終了タスク集合とそれに応じた着手可能タスク集合が計算される。そして、新たに計算された着手可能タスク集合のタスクに対してワーカーが割り当てられる。

以下、スケジューリング装置１０のＣＰＵ２０Ａで実行される処理について、図３に示すフローチャートを参照して説明する。

ステップ１００では、プロジェク集合Pros、各プロジェクトのタスク集合TASKSを前述のように定義すると共に、定義された各タスクの実行順序を定義する。これは、例えばユーザーが操作部２２を操作して入力することにより定義することができる。なお、以下の各種集合や関数の定義についても同様である。

ステップ１０２では、職能集合PROFS、タスク職能関係TPR又はタスク職能関数TPFを前述のように定義する。

ステップ１０４では、労働者集合Ωと職能割当関数ProfAssignFを前述のように定義する。

ステップ１０６では、実行可能タスク集合POS_TASKS[ω]を例えばタスク職能関係TPR、労働者集合Ω、及び職能割当関数ProfAssignFに基づいて求める。

ステップ１０８では、タイムカウンター集合TimeCounterとタイムインターバル集合TimeIntervalを前述のように定義する。

ステップ１１０では、タスク推定遂行時間割当関数EstTimeAcompFを前述のように定義する。

ステップ１１２では、未割当労働者集合Ω[u]と割当済み労働者集合Ω[a]を前述のように定義する。

ステップ１１４では、時間変数ｔを０に初期化する。

ステップ１１６では、タスク集合X、終了タスク集合Fin_TASKS[P](t)、未終了タスク集合UFin_TASKS[P](t)、着手可能タスク集合ABegin_TASKS[P](t)、仕掛タスク集合TaskInProgS[P](t)、開始可能タスク集合StartTaskS[P](t)を含むプロジェクト進行ProjProg[P](t)を前述のように定義する。

ステップ１１８では、プロジェクト進行ProjProg[P](t)のうち着手可能タスク集合ABegin_TASKS[P](t)に属する着手可能タスクに対して、実行可能労働者集合割当関数AssinableWorkers[P]、担当労働者割当関数WinChにより、未割当労働者集合Ω[u] (t)からワーカーを割り当てる。この割当は、例えば前述したように最小人数最長工程単能工優先割当法により割り当てる。

ステップ１２０では、未割当労働者集合Ω[u]と割当済み労働者集合Ω[a]を更新する。

ステップ１２２では、着手可能タスクに対するワーカーの割り当てが終了したか否かを判断する。ここで、着手可能タスクに対するワーカーの割り当てが終了する場合とは、全ての着手可能タスクに対してワーカーが割り当てられた場合や、着手可能タスクに対して割り当てるべきワーカーが存在しない場合である。そして、着手可能タスクに対するワーカーの割り当てが終了した場合には、ステップ１２４へ移行する。一方、割り当てが終了していない場合には、ステップ１１８へ移行し、上記と同様にワーカーが割り当てられていない着手可能タスクに対してワーカーを割り当てる。

ステップ１２４では、時間変数ｔを１インクリメントする。例えば単位が日であれば、ｔを１インクリメントさせるとタスクの実行が１日進行したことになる。

ステップ１２６では、終了タスク集合Fin_TASKS[P](t)、未終了タスク集合UFin_TASKS[P](t)、着手可能タスク集合ABegin_TASKS[P](t)、仕掛タスク集合TaskInProgS[P](t)、開始可能タスク集合StartTaskS[P](t)を更新する。例えば、タスク推定遂行時間割当関数EstTimeAcompFにより算出された各タスクの推定遂行時間に基づき、時点ｔにおいて終了したタスクは終了タスク集合に移動する。また、未終了タスク集合のうち着手可能となったタスクは、着手可能タスク集合に移動する。

ステップ１２８では、全タスクの実行が終了したか否か、すなわち、終了タスク集合に全てのタスクが移動したか否かを判断する。そして、全タスクが終了した場合にはステップ１３０へ移行し、実行されていないタスクが存在する場合には、ステップ１１８へ戻って全タスクの実行が終了するまで上記と同様の処理を繰り返す。

ステップ１３０では、各プロジェクトの各タスクに対して、各時点においてどのようにワーカーが割り当てられたかを示すスケジュール表のデータを出力先に出力する。出力先としては、例えば表示部２４やハードディスク２６等がある。

なお、スケジュール表としては、例えば後述する図１９〜２２に示すようなスケジュール表を生成して出力することができる。図１９に示すように、複数のプロジェクトの各タスクに対する日毎のワーカーの割り当て結果を示すスケジュール表を生成し、生成したスケジュール表を表示部２４等に出力してもよいが、図２０に示すように、図１９に示すスケジュール表を、複数のワーカーの各々に対する日毎のタスクの割り当て結果を示すスケジュール表に並び替えて出力するようにしてもよい。

本実施形態では、上記のようにして並列して進行する複数のプロジェクトを構成する複数のタスクに対してワーカーを割り当てるので、例えば製造ラインや建築工事で用いられる一般的なマスター工程やタクト工程に代表される、全順序的な単一プロジェクトを支援するスケジューリング手法では対処できない半順序構造のプロジェクトが並列して進行する工程のリソースの割当に関するスケジューリングの問題を解決することができる。

例えば、行為者の行動の蓄積というボトムアップ型と称されるスケジューリング手法である、マルチエージェントシステム等を用いた分散型プロセスのスケジューリング支援手法と比較して、割当アルゴリズムを用いて開始可能タスク集合に対して未割当労働者集合を一義的に割り当てるため、プログラム処理数が少なくなり、より早く結果を導出できる。また、各時点で着手可能なタスクの集合が計算でき、その中の開始可能なタスクの集合を計算し、それに対する割当可能なワーカーを計算により求め、割当アルゴリズムを用いてタスクにワーカーを割り当てることで、半順序構造を持つプロジェクトの各タスクに対するリソースの割り当ての自動演算をより早く行なうことができる。

＜プロジェクト進行の具体例＞

以下では、プロジェクト進行の具体例について説明する。ここでは、３つのプロジェクトP1、P2、P3、４つのタスクa、b、c、d、３つの職種TypeA、TypeB、TypeC、３人のワーカーW1、W2、W3である場合におけるプロジェクト進行の具体例について説明する。

本実施形態では、ワーカー等の資源の側が、プロジェクトを構成するタスクに動的に寄付く形で割り付けられるスケジューリングを扱う。これを、本実施形態では資源寄り付き型動的スケジューリング(Resource Approaching Dynamical Scheduling)と呼ぶ。

（１）タスク集合:Task Set
プロジェクト集合PS、タスク集合TASKS等は以下のように定義される。
PS＝{P1,P2,P3}
TASKS[P1]=TASKS[P2]=TASKS[P3]={a,b,c,d}
StartEndSet={Start, End }

上記のように、各プロジェクトP1、P2、P3は全て同一のタスクを有する。このように全て同一のタスクを有するプロジェクトの例としては、例えば集合住宅の各住戸の建設等があるが、プロジェクトの種類はこれに限られるものではない。

（２）職能集合：PROFS:Profession Set
職能集合PROFSは以下のように定義される。
PROFS={TypeA, TypeB, TypeC}

（３）タスク職能関係 Task Profession Relation:TPR)
タスク職能関係TPRは以下のように定義される。
TPR⊆TASKS×PROFS

図４には、タスク、職能、及びワーカー（労働者）との関係の概念を示した。同図に示すように、タスクと職能との関係、職能とワーカーとの関係は、何れも多対多の関係にある。

（４）労働者集合と職能割当関数： Profession Assignment Function:ProfAssignF
Ωを労働者集合(Worker Set)として、職能割当関数ProfAssignFは以下のように各ワーカーに対して職能を定義する。なお、各ワーカーには、予め職能が割り当てられている。
ProfAssignF:Ω→PROFS
ProfAssignF(W1)=TypeA
ProfAssignF(W2)=TypeB
ProfAssignF(W3)=TypeC

（５）ワーカーWに対する実行可能タスク集合：POS_TASKS[W]:Posible Task Set for W
各ワーカーに対する実行可能タスク集合POS_TASKSは以下のようになる。
POS_TASKS[W1]={a}
POS_TASKS[W2]={b,c}
POS_TASKS[W3]={c,d}

（６）タスクの推定遂行時間割当て関数： EstTimeAcompF:Estimated Time for Task
タスクの推定遂行時間割当関数EstTimeAcompFは、各タスクに対して推定遂行時間を以下のように割り当てる。なお、ここでは、単位は日である。すなわち、タスクａの推定遂行時間は１日、タスクｂの推定遂行時間は２日、タスクｃの推定遂行時間は４日、タスクｄの推定遂行時間は１日である。
EstTimeAcompF(a)=1
EstTimeAcompF(b)=2
EstTimeAcompF(c)=4
EstTimeAcompF(d)=1

（７）プロジェクト進行のグラフ表現
図５には、各プロジェクトの進行をグラフ表現した。同図の“ｓ”はStartを示している。また、各ノードはタスクを示し、例えば“a[P1]/1日”は、プロジェクトP1のタスクaは推定遂行時間が１日であることを示している。

本実施形態では、各プロジェクトP1、P2、P3は同一のタスク集合であり、図５に示すような進行で実行される。すなわち、タスクa、b、c、dには、ａ＜ｂ、ａ＜ｃ、ｂ＜ｄ、ｃ＜ｄの順序関係がある。このように各プロジェクトが同一のタスク集合となるものとしては、集合住宅の建築等がある。

図５に示すように、各プロジェクトのクリティカルパスはタスクｃを経由する下側のルートであり、６日が最短工程となる。

以下では、着手可能タスク集合をプロジェクト毎に、その半順序集合の極小元の集合として求める。図６に示すように、t=0（ゼロ日目）の初期時点では、最初の着手可能タスク集合を求める。

同図において、点線内のタスクa[P1]、a[P2]、a[P3]が着手可能タスク集合となる。すなわち、着手可能タスクABegin_TASKS[P1]、ABegin_TASKS[P2]、ABegin_TASKS[P3]は以下のようになる。
ABegin_TASKS[P1]={a[P1]}
ABegin_TASKS[P2]={a[P2]}
ABegin_TASKS[P3]={a[P3]}

ここで、労働者集合をΩ[u](0)＝Ω＝{W1,W2,W3}とすると、実行可能労働者集合割当関数AssinableWorkersは、各着手可能タスクに対して以下のようにワーカーを割り当てる。
AssinableWorkers[P1](a[P1])={W1}
AssinableWorkers[P2](a[P2])={W1}
AssinableWorkers[P3](a[P3])={W1}

このように、タスクａはワーカーW1しか実行できないので、各プロジェクトの着手可能タスクの実行可能労働者集合はワーカーW1のみとなる。そして、ワーカーはW1,W2,W3の３人しかいないので、前述した最小人数最長工程単能工優先割当法で担当者を割り付ける。この場合、各プロジェクトの着手可能タスクに割り当てられた実行可能労働者集合のサイズは以下のようになる。
|AssinableWorkers[P1](a[P1])|=1
|AssinableWorkers[P2](a[P2])|=1
|AssinableWorkers[P3](a[P3])|=1

このように、各プロジェクトの着手可能タスクに割り当てられた実行可能労働者集合のサイズは全て１となるので、ここでｊは確率的にプロジェクトP1のタスクa[P1]に対してワーカーW1を割り付ける。

次に、図７に示すように、１日目にタスクa[P1]がワーカーW1により実行され、１日目が終了すると、ワーカーW1は解放される。これにより、図８に示すように、２日目にはタスクa[P1]は終了タスク（図中‘F'で示す）となる。

また、１日目の終了後、次にワーカーを割当可能となる着手可能タスクは、図７において点線で示したタスクタスクa[P2]、a[P3]、b[P1]、c[P1]となる。

これらの着手可能タスクに対して上記と同様にワーカーの割当を行う。すなわち、実行可能労働者集合割当関数AssinableWorkersは、各着手可能タスクに対して以下のようにワーカーを割り当てる。
AssinableWorkers[P2](a[P2])={W1}
AssinableWorkers[P3](a[P3])={W1}
AssinableWorkers[P1](b[P1])={W2}
AssinableWorkers[P1](c[P1])={W2,W3}

ここでも、前述した最小人数最長工程単能工優先割当法により、タスクa[P2]にW1が割り当てられ、次に工期が４日のタスクc[P1]に単能工のワーカーW3が割り当てられ、最後にタスクb[P1]にワーカーW2が割り当てられる。

これにより、図８に示すように、２日目には、タスクb[P1]、c[P1]、a[P2]が実行され、２日目が終了すると、タスクa[P2]は終了し、工期が２日のタスクb[P1]、c[P1]は仕掛タスクとなり、図９に示すように３日目も実行される。

図８〜１８に示すように、２日目以降も同様にして、着手可能タスクを求め、これにワーカーを割り当てることを、全てのプロジェクトの全てのタスクが終了するまで繰り返す。これにより、図１８に示すように、１２日目が終了すると、全プロジェクトの全タスクの実行が終了する。

図１９には、プロジェクト毎に、各タスクの１〜１２日目にどのようにワーカーが割り当てられたかを示すスケジュールを表形式にまとめたものを示した。なお、図１９において、網点のハッチング（以下、ハッチングＡと称する）で示したタスクは、着手可能タスクを示している。また、左上から右下に向かう斜線によるハッチング（以下、ハッチングＢと称する）で示したタスクは、着手可能タスクのうち、実際にワーカーが割り当てられたタスクを表している。また、右上から左下に向かう斜線によるハッチング（以下、ハッチングＣと称する）で示したタスクは、仕掛かり状態のタスクを表している。

図１９に示したスケジュールでは、ワーカーW1を３日雇用し、ワーカーW2を１０日雇用し、ワーカーW3を１１日雇用することが必要となるが、ワーカーの割り当ては、なるべくハッチングＡで示した着手可能タスクに対してワーカーを割り当て、かつワーカーに余りがでないように、工期が左側にシフトするように、すなわち工期を短縮できるように割り当てることが好ましい。

ワーカーをタスクに割り当てるディスパッチルールは、本実施形態では、最小人数最長工程単能工優先割当法を用いたが、ディスパッチルールはこれに限られるものではない。ディスパッチルールは適宜、様々な制約に基づいて適宜変更することができる。

本実施形態では、図１９に示すようなスケジュールを求めたとしても、例えばワーカーの手配がつかなかった場合や、予想外のトラブルで工数が伸びた場合等の事態が発生した場合には、その時点でワーカーの変更に応じて労働者集合を変更したり、工数の変更に応じてタスク推定遂行時間割当関数を変更したりして、その時点から再度着手可能タスク集合を計算し直せばよい。このように、プロジェクトの進行途中において予想外のトラブルが発生した場合でも、その時点から着手可能タスク集合やワーカーの割当の再計算を容易に行うことができるので、予想外のトラブル等にも柔軟に対応できる。

図２０には、図１９に示した各プロジェクトの各タスクへ資源（ワーカー）を割り当てた表を、逆に各資源に対して各プロジェクトの各タスクが割り当てられた表として表現したものを示した。この表は、ジョブショップスケジューリングのマシン（この場合はワーカー）へのジョブ（この場合はプロジェクトとそれを構成するタスク）の割当を、ジョブを構成するタスクの半順序的加工条件、つまり一つのジョブを同時に二つの機械（ワーカー）によって加工することも可能という形で一般化したものである。ちなみに、マンション施工などでは、この並列作業は一部屋の内装（ジョブ＝プロジェクト）で二人のワーカーが同時にその部屋で施工できる状況を示す。

上記で説明したプロジェクトに対する資源の割当では、全体工期は１２日である。また、プロジェクト毎に並列に作業が行えるだけの十分な人数がいれば、最短工期は、この場合のクリティカルパスになる６日になる筈である。そこで、ワーカーの雇用形態を変えることにより、この工期がどのように変化するかを考察する。

図２０では、ワーカーW１が延べ３日（一人で３日）雇用、ワーカーW２が延べ１０日（一人で１０日）雇用、ワーカーW３が延べ１１日（一人で１１日）雇用されている。すなわち、一つの職種に対して一人を雇用してプロジェクトを実行している。これに対して、延べ人数は同じで複数人の同時雇用を許すように雇用形態を変えることができた場合に、プロジェクトの工期はどのように変化するのかについて計算した結果について説明する。

図２１には、ワーカーの雇用形態を以下のように変えることにより、どの程度工期が縮まるかについて計算した結果を示した。
ワーカーW1を１日雇用
ワーカーW1と同じ職能を有するワーカーW1'を１日雇用
ワーカーW1と同じ職能を有するワーカーW1"を１日雇用
ワーカーW2を４日雇用
ワーカーW2と同じ職能を有するワーカーW2'を６日雇用
ワーカーW3を７日雇用
ワーカーW3と同じ職能を有するワーカーW3'を４日雇用

以上より、ワーカーW1、W1'、W1"は延べ３日雇用、ワーカーW2、W2'は延べ１０日雇用、ワーカーW3、W3'は延べ１１日雇用である。

ここでは、雇用の延べ人数は図１９の場合と同じであるが、ワーカーを増員することにより、着手可能タスクに対してワーカーを集中して割り当てている。

これにより、図２１に示すように、初日にワーカーW1の職能を有するワーカー３人で各プロジェクトのタスクaを１日で終了させている。ワーカーW2,W2'は、それぞれ２日目から連続４日雇用と連続６日雇用で延べ１０日雇用。ワーカーW3、W3'は、それぞれ２日目から８日目まで連続７日雇用、２日目から５日目までの連続４日雇用で述べ１１日雇用である。これにより、職能別の延べ雇用人数としては変化はないが、全体工期を８日に短縮することができる。

このように、図１９でハッチングＡで示された着手可能タスクをなるべく早めに遂行するように、延べ雇用人数を一定としつつ、雇用パターン（ワーカーの割付パターン）を変更可能な条件下では、かなりの最適化が可能であることが判る。上記のような簡単なディスパッチルールによるワーカーの割り当てにより、延べ雇用人数が同じで全体工期を１２日から８日と２／３に短縮できる。
ただし、このような雇用条件の変化は、プロジェクトの種類によって異なる。例えば、医療等の分野では、雇用条件を簡単に変更することがはきない。また、高度検査機械などの限定リソースの割り当てもある。例えば緊急患者でその検査の割付や治療の割付が動的に変わっても、本実施形態に係る資源寄り付き型動的スケジューリングによれば、その都度、再割付が容易に可能となる。

図２２には、ワーカーの雇用形態をさらに以下のように変えることにより、さらにどの程度工期が縮まるかについて計算した結果を示した。
ワーカーW1を１日雇用
ワーカーW1と同じ職能を有するワーカーW1'を１日雇用
ワーカーW1と同じ職能を有するワーカーW1"を１日雇用
ワーカーW2を４日雇用
ワーカーW2と同じ職能を有するワーカーW2'を４日雇用
ワーカーW2と同じ職能を有するワーカーW2"を２日雇用
ワーカーW3を５日雇用
ワーカーW3と同じ職能を有するワーカーW3'を５日雇用
ワーカーW3と同じ職能を有するワーカーW3"を１日雇用

以上より、ワーカーW1、W1'、W1"は延べ３日雇用、ワーカーW2、W2'、W2"は延べ１０日雇用、ワーカーW3、W3'、W3"は延べ１１日雇用である。

このように、ワーカーW2"、W3"を追加することにより、全体工期は６日となり、プロジェクト単独のクリティカルパスの範囲内にまで全体工期を短縮することができることが判った。

以上のように、本実施形態に係るスケジューリング装置１０は、複数の並列して行われるプロジェクトの各タスクに対して、限られた人数の異なる技能を持つワーカーを、時系列で高速に割り当てることができる。このスケジューリング装置１０で実行される処理は、職制のリーダーやワーカーが現場で行っている「その場・その時点で自らのチームにとって最適なワーカーを割り当てる」意思決定をアルゴリズム化したものと言える。このため、現実の作業進捗に近い工程表や勤務スケジュールを算出することができる。このアルゴリズムでは、開始、終了、着手可能なタスクやワーカーを時系列で集合論的に計算しながら作業とワーカーを割り当てるため、計算回数の少ない高速なスケジューリングが可能である。前述した例では、日毎の状態から着手可能なタスクやワーカーの集合を求め、これらの集合同士をマッチングさせるアルゴリズムとしている。

これにより、本発明は、従来技術であるマルチエージェントシステムの技術を用いた場合と比較して、およそ数百分の１のスピードでスケジューリング結果を得ることができる。スケジューリングの結果は図１９に示したような各プロジェクトの日割りの工程表や、図２０に示したようなワーカー毎の勤務スケジュール表の様式で瞬時に表現できる。これらの管理表から、ワーカー不足で作業が進まない状況（図１９の網点のハッチングＡで示した部分）やワーカーの空き状況（図２０の網点のハッチングＡで示した部分）を一目で把握でき、計画している工程やワーカー編成の妥当性や問題を瞬時に判断できる。

また、本実施形態では、前述してように、タイムカウンター集合TimeCounter及びタイムインターバル集合TimeIntervalを定義し、タスク毎に標準の推定遂行時間EstTimeAcompがタイムインターバル集合TimeIntervalへのタスク推定遂行時間割当て関数EstTimeAcompFとして定義される。このため、スケジューリングの任意の時点から条件を変更してスケジュールを容易に再計算することができ、プロジェクトの状況変化に対して柔軟に対応することができる。スケジューリングは前述のように高速で完了するため、短時間で何回でも条件設定を変更しながら最適化を目指したスケジュールの検討が可能となる。

なお、本実施形態では、プロジェクトが集合住宅の各住戸の建築である場合について説明したが、プロジェクトはこれに限られるものではない。例えば、医療分野においては、患者がプロジェクトの対象となり、その標準治療手続きがプロジェクトとなる。タスクはそれぞれの治療やその準備行為や事務処理等の病院の諸手続き等で、それぞれの職能がタスクを遂行する。

１０ スケジューリング装置
２０ コンピュータ
２２ 操作部
２４ 表示部
２６ ハードディスク

Claims (7)

1. 少なくとも一部の期間で重複して進行する複数のプロジェクトの各々について前記プロジェクトを構成する複数のタスクの半順序関係を定義した実行順序データと、前記複数のタスクの遂行時間を定義したタスク遂行時間データと、前記複数のタスクと前記複数のタスクの各々を実行可能な職能タイプとの対応関係を定義した第１の対応関係データと、前記職能タイプと前記タスクを実行する複数のリソースとの対応関係を定義した第２の対応関係データと、に基づいて、前記複数のプロジェクトを構成するタスクのうち未終了のタスクから、着手可能な着手可能タスクを抽出する抽出手段と、
   前記複数のリソースのうち前記着手可能タスクを実行可能で且つ他のタスクに未割り当てのリソースを割り当てる割当手段と、
   前記複数のプロジェクトの全タスクが終了するまで、予め定めた時間毎に前記割当手段による前記リソースの割り当てが実行されるように制御する制御手段と、
   を含み、
   前記第１の対応関係データにより定義された前記対応関係は、タスク職能関数によって定義され、前記タスク職能関数は、１つの前記職能タイプに対して複数のタスクを割り当て可能である
   スケジューリング装置。
2. 前記遂行時間は、タスク推定遂行時間割当関数によって定義されると共に、前記タスク推定遂行時間割当関数を変更することによって変更可能であり、前記抽出手段は、前記遂行時間が変更された場合に、前記着手可能タスクを再抽出する
   請求項１記載のスケジューリング装置。
3. 前記実行順序データは、前記複数のプロジェクトの各々について、異なるタスクを定義可能である
   請求項１又は請求項２記載のスケジューリング装置。
4. 前記複数のプロジェクトは、離散時間で管理される
   請求項１〜請求項３の何れか１項に記載のスケジューリング装置。
5. 前記複数のプロジェクトの各タスクに対する前記予め定めた時間毎の前記リソースの割り当て結果を示すスケジュール表を生成し、生成したスケジュール表を出力するスケジュール表出力手段
   を備えた請求項１〜請求項４の何れか１項に記載のスケジューリング装置。
6. 前記スケジュール表を、前記複数のリソースの各々に対する前記予め定めた時間毎の前記タスクの割り当て結果を示すスケジュール表に並び替える並替手段
   を備えた請求項５記載のスケジューリング装置。
7. コンピュータを、請求項１〜請求項６の何れか１項に記載のスケジューリング装置を構成する各手段として機能させるためのスケジューリングプログラム。

Images