JP2019032785A - プロジェクト管理装置、プロジェクト管理方法及びプロジェクト管理プログラム - Google Patents

Abstract

【課題】計画策定、タスクに対する要員の割当、及び、タスク実施段階の監視・制御を支援する。【解決手段】本発明のプロジェクト管理装置は、１又は複数のタスクを含むタスクグループが連続的に実行されるべき期間である計画期間と、タスクごとの工数と、タスクごとのレベルとを受け付け、計画期間内に完了され得るタスクグループを特定し、特定したタスクグループが実施されるために必要な工数及びレベルをタスクごとに出力する計画策定部と、タスクごとの工数、タスクごとのレベル、要員のレベル、及び、要員の空工数に基づき、タスクに対して要員を割当てるタスク自動割当部と、所定の期日が経過してもタスクが完了しない場合に、要員に対して警告を出力し、要員から警告に対する回答を受け付けるタスク進捗管理部と、を備えることを特徴とする。【選択図】図２８

Description

本発明は、プロジェクト管理装置、プロジェクト管理方法及びプロジェクト管理プログラムに関する。

多くの要員を動員して期限までに所定の成果を達成する一連の業務は、一般に“プロジェクト”と呼ばれる。プロジェクトを構成する業務のそれぞれは、“タスク”と呼ばれる。そして、プロジェクト実施主体は、プロジェクトを実施する前段階において、個々のタスクの工数、個々のタスクに必要な要員の技術水準等を予め決定し、タスクに対して要員を割当てる。近時、このような要員の割当を自動的に行う技術が普及している。

特許文献１のプロジェクト管理支援システムは、タスクの担当者が当該タスクの工数を自己申告するのを受け付け、当該担当者に係る過去の自己申告に対する信頼度（申告内容と実績との差分等）に基づいて、今回自己申告された工数を補正する。さらに、当該システムは、当該担当者に係る過去の生産性（ミスの多さ、他のサポートを受けた頻度等）に基づいて、今回自己申告された工数を補正する。その後、当該システムは、補正後の工数に基づいて、当該タスクの具体的なスケジュール（日程）を決定する。

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

しかしながら、特許文献１においては、依然として以下の課題が残る。第１に、あるタスクに対して自己申告した要員を当該タスクの担当者とすることが前提になっており、多くの候補のうちから担当者を選択する方法は具体的に開示されていない。第２に、自己申告制が前提であるが故に、タスクの担当者は、難易度の高いタスクには積極的に取り組もうとせず工数を過大申告しがちである。第３に、仮に個々のタスクのスケジュールを決定できたとしても、複数のタスクを含む全体工程が期限までに完了することは担保されず、それを担保するための要員の数及びレベルも明らかにはならない。第４に、タスク実施段階で遅延が発生した場合、遅延の原因及び対策が明らかにならない。
そこで、本発明は、計画策定、タスクに対する要員の割当、及び、タスク実施段階の監視・制御を支援することを目的とする。

本発明のプロジェクト管理装置は、１又は複数のタスクを含むタスクグループが連続的に実行されるべき期間である計画期間と、タスクごとの工数と、タスクごとのレベルとを受け付け、計画期間内に完了され得るタスクグループを特定し、特定したタスクグループが実施されるために必要な工数及びレベルをタスクごとに出力する計画策定部と、タスクごとの工数、タスクごとのレベル、要員のレベル、及び、要員の空工数に基づき、タスクに対して要員を割当てるタスク自動割当部と、所定の期日が経過してもタスクが完了しない場合に、要員に対して警告を出力し、要員から警告に対する回答を受け付けるタスク進捗管理部と、を備えることを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、計画策定、タスクに対する要員の割当、及び、タスク実施段階の監視・制御を支援することができる。

（ａ）、（ｂ）及び（ｃ）は、タスクグループの日数を説明する図である。 プロジェクト管理装置の構成を説明する図である。 タスク情報の一例である。 タスク紐付情報の一例である。 スキル領域情報の一例である。 ユーザ情報の一例である。 ユーザ工数情報の一例である。 ユーザ空工数情報の一例である。 遅延情報の一例である。 タスクグループ情報の一例である。 スケジュール案情報の一例である。 スケジュール案情報（見直し後）の一例である。 フェーズ、タスクグループ及びタスクの関係等を概観する図である。 定義入力処理手順のフローチャートである。 計画策定処理手順のフローチャートである。 タスク自動割当処理手順のフローチャートである。 タスク手動割当処理手順のフローチャートである。 タスク着手処理手順のフローチャートである。 タスク着手取消処理手順のフローチャートである。 タスク完了処理手順のフローチャートである。 タスク完了取消処理手順のフローチャートである。 遅延認識処理手順のフローチャートである。 アラーム表示処理手順のフローチャートである。 （ａ）は、タスク定義画面の、（ｂ）は、タスク紐付画面の一例である。 （ａ）は、スキル定義画面の、（ｂ）は、ユーザ定義画面の、（ｃ）は、計画策定画面の一例である。 （ａ）は、タスクグループのマッピング図の、（ｂ）は、実施不可タスクグループ図の一例である。 （ａ）は、タスク割当画面の、（ｂ）は、割当可能ユーザ一覧画面の、（ｃ）は、全ユーザ一覧画面の一例である。 （ａ）は、タスク進捗画面の、（ｂ）は、管理者警告画面の、（ｃ）は、担当者警告画面の一例である。 （ａ）は、影響範囲調査結果画面の、（ｂ）は、タスクマップ画面の一例である。 割当パタンの一例である。

以降、本発明を実施するための形態（“本実施形態”と呼ぶ）を、図等を参照しながら詳細に説明する。本実施形態は、システム構築プロジェクトに本発明を適用する例であるが、本発明は、一連の業務を複数の要員によって期間までに完了する例に一般的に適用できる。

（用語）
タスクとは、プロジェクト（詳細後記）を構成する業務の最小単位である。２つのタスク間には、あるタスクを完了しなければ他のタスクに着手できないという関係が存在する場合がある。この場合、前者を“前提タスク”と呼び、後者を“後続タスク”と呼び、この関係を“前提後続関係”と呼ぶ。特定のタスクが、あるタスクの“後続タスク”であると同時に、別のあるタスクの“前提タスク”である場合（数珠繋ぎ）もある。１つの前提タスクに対して複数の後続タスクがある場合（枝への分岐）もあり、複数の前提タスクに対して１つの後続タスクがある場合（枝からの合流）もある。

タスクグループとは、前提後続関係によって数珠状又は枝状に結合された一連のタスクの集合である。１つのタスクが１つのタスクグループを形成する場合もある。プロジェクトとは、１又は複数のタスクグループの集合であり、請負契約等の対象となる単位である。フェーズとは、連続して実施される１又は複数のタスクグループの集合である。タスクグループがフェーズとしてまとまる理由としては、例えば、要員が属する組織が同じである、業務内容が類似している、予算が同じである、成果物を納品する時期が同じである等が想定され得る。１つのフェーズに属するタスクグループ間には、前記の前提後続関係のような関係があるわけではない。以上を整理すると、“プロジェクト＞フェーズ＞タスクグループ＞タスク”という包含関係が成立していることになる。“＞”の左側が上位概念であり、右側が下位概念である。なお、前提後続関係は、タスクグループにおけるタスクの並列実施の可否を決定する（図１において詳細後記）。

ユーザとは、タスクを実施する要員であり、本実施形態のプロジェクト管理装置の使用者である。ユーザは、タスクを直接実施する“担当者”、担当者を管理する“管理者”、及び、担当者の成果物をチェックする“レビュアー”に区分され得る。

タスクに対して、工数及びレベルが定義される。工数とは、タスクの業務量（単位：人工）である。例えば、あるタスクを完了するために、１人の担当者が１０日間働かなければならない場合、当該タスクの工数は、１×１０＝１０人工である。２人の担当者を活用できる場合、１０人工のタスクは、１０／２＝５日で完了され得る。レベルとは、タスクの難易度であり、換言すれば、当該タスクの担当者に求められる能力の水準である。タスクの内容に応じて、レベルは、複数の“領域”に細分化される。例えば、財務関係のシステム開発のタスクには、“財務会計”の知識が必要である。生産関係のシステム開発のタスクは、“生産管理”の知識が必要である。ここでの“財務会計”及び“生産管理”が、領域に相当する。１つのタスクが複数の領域について別のレベルを要求する場合もある。

（タスクグループ）
図１に沿って、タスクグループの日数を説明する。図１（ａ）は、７つのタスクを有する１つのタスクグループの例である。タスク間の矢印は、前提後続関係を示す。矢印の始点側のタスクが前提タスクであり、終点側のタスクが後続タスクである。例えば、タスクＢは、タスクＣの前提タスクである。タスクＢは、タスクＡの後続タスクでもある。さらに、タスクＢは、タスクＦの後続タスクでもある。つまり、タスクＡ及びタスクＦの両者を完了した後でなければタスクＢに着手することができない。さらに、タスクＢを完了した後でなければタスクＣに着手することができない。

図１（ａ）を全体的に見ると以下のことがわかる。
・当該タスクグループのタスクのうち最後に実施されることになるタスクは、タスクＣである。なぜならば、タスクＣは、他のタスクの前提タスクにはなっていないからである。
・当該タスクグループのタスクのうち最初に実施されなければならないタスクは、タスクＡ、タスクＤ及びタスクＧである。なぜならば、タスクＡ、タスクＤ及びタスクＧは、他のタスクの後続タスクにはなっていないからである。
図１（ａ）を参照しただけでは、どの程度の日数で当該タスクグループを完了し得るかはわからない。それを知るために、プロジェクト管理装置は、タスクの工数に基づいてタスクグループの日数を算出するシミュレーションを行う。

このシミュレーションにおいて、プロジェクト管理装置は、前提後続関係を遵守する一方、単純化のために、タスクが要求するレベルを捨象し、１つのタスクに対して１日あたり所定の人数の仮想的な担当者を割当てる。タスクグループが完了するまでの日数は、短いほどよい。そこで、プロジェクト管理装置は、前提後続関係の制約がないタスク同士を可能な限り並列化かつ前倒化したうえでスケジュール表を作成する。

図１（ｂ）は、スケジュール表の一例である。スケジュール表の横軸は、日数である。プロジェクト管理装置は、スケジュール表に、図１（ａ）の７つのタスクを配置している。図１（ａ）では、各タスクの長方形の横幅は意味を有さない一方、図１（ｂ）の各タスクの長方形の横幅は、そのタスクが実施される日数を示している。プロジェクト管理装置は、図１（ｂ）の例ではタスクに対して１日あたり１人の担当者を割当てるので、各タスクの日数（横幅）は、その工数に一致する。タスクグループが完了するまでの日数を短くするための工夫は、２日目〜８日目、１７日目及び１８日目に現れている。

２日目〜８日目において、タスクＧに対して、タスクＤ又はタスクＥが同時並列的に実施されている。１７日目及び１８日目において、タスクＡ及びタスクＦが同時並列的に実施されている。このように、複数のタスクが同一タイミングで実施されるようにスケジュール表に配置すること、及び、実際に実施することを、「タスクを“並列”する」と表現する。並列されるタスクの数は、“２”に限らず、“３”以上である場合もある。並列されるタスク間には、前提後続関係は存在しない。プロジェクト管理装置は、タスクグループが完了するまでの期間を図１（ｂ）の例より短くすることはできない。そこで、図１（ｂ）における、最初のタスクＤの着手日から最後のタスクＣの完了日までの日数を、タスクグループの“最短日数”と呼ぶ。この例では、最短日数は、“２７”である。

図１（ｃ）もまた、スケジュール表の一例である。図１（ｃ）においては、タスクが並列される期間はない。プロジェクト管理装置は、並列され得ないタスクＤ、Ｅ及びＦのまとまりと、並列され得ないタスクＡ、Ｂ及びＣのまとまりとの間に、タスクＣを配置している。そこで、図１（ｃ）における、最初のタスクＤの着手日から最後のタスクＣの完了日までの日数を、タスクグループの“最長日数”と呼ぶ。この例では、最長日数は、“３６”である。本実施形態においては、土曜日、日曜日、祝日等の休日にタスクが実施されることはない。図１（ｂ）及び（ｃ）のスケジュール表は、そのような休日を除外している。なお、本実施形態においては、“ユーザにタスクを割当てる”及び“タスクにユーザを割当てる”は同義であり、両者とも、タスクとユーザを関連付けることを意味する。

（プロジェクト管理装置の構成）
図２に沿って、プロジェクト管理装置１の構成を説明する。プロジェクト管理装置１は、一般的なコンピュータである。プロジェクト管理装置１は、中央制御装置１１、入力装置１２、出力装置１３、主記憶装置１４、補助記憶装置１５及び通信装置１６を備える。補助記憶装置１５は、タスク情報３１、タスク紐付情報３２、スキル領域情報３３、ユーザ情報３４、ユーザ工数情報３５、ユーザ空工数情報３６、遅延情報３７、タスクグループ情報３８及びスケジュール案情報３９を格納する。主記憶装置１４における、計画策定部２１、タスク自動割当部２２、タスク手動割当部２３及びタスク進捗管理部２４は、プログラムである。以降の説明において、“○○部は”と動作主体を記した場合、それは、中央制御装置１１が補助記憶装置１５から○○部を読み出し、主記憶装置１４にロードしたうえで○○部の機能（詳細後記）を実現することを意味する。

プロジェクト管理装置１は、ネットワーク４を介して、１又は複数の管理者端末装置２及び１又は複数の担当者端末装置３に接続可能である。管理者端末装置２及び担当者端末装置３は、一般的な携帯型のコンピュータであり、それぞれ管理者及び担当者によって使用され、中央制御装置、入力装置、出力装置、主記憶装置、補助記憶装置及び通信装置（図示せず）を備える。

（タスク情報）
図３に沿って、タスク情報３１を説明する。タスク情報３１においては、タスクコード欄１０１から領域２レベル欄１１９までのデータが相互に関連付けて記憶されている。
タスクコード欄１０１のタスクコードは、タスクを一意に特定する識別子である。
タスク名欄１０２のタスク名は、タスクの名称である。
期日欄１０３の期日は、タスクを完了しなければならない年月日である。
工数欄１０４の工数は、タスクの工数（単位：人工）である。
完了予定日欄１０５の完了予定日は、タスクを完了する予定の年月日である。完了予定日が未定である場合、当該欄は空欄である（欄１０７及び１０８も同様）。
前提タスク有り欄１０６の前提タスク有りフラグは、当該タスクに対する前提タスクが存在することを示す。本実施形態では、すべてのフラグは“Ｘ”である。そして、フラグが記憶されていないレコード（行）も存在する。

着手可能日欄１０７の着手可能日は、タスクに着手することができる年月日である。
着手日欄１０８の着手日は、タスクに実際に着手した年月日である。
優先度欄１０９の優先度は、その前提タスクが存在しないタスク間での当該タスクの優先度であり、数字が小さいほど優先度が高く、先にユーザが割当てられる。
タスクグループコード欄１１０のタスクグループコードは、タスクグループを一意に特定する識別子である。
完了フラグ欄１１１の完了フラグは、タスクが完了したことを示す。
遅延フラグ欄１１２の遅延フラグは、期日が経過してもなおタスクが完了していないことを示す。
遅延見込フラグ欄１１３の遅延見込フラグは、期日が経過してもなおタスクが完了しないことが予想されることを示す。

担当者ユーザコード欄１１４の担当者ユーザコードは、担当者のユーザコードである。ユーザコードとは、個々のユーザ（担当者、管理者及びレビュアーになり得る）を一意に特定する識別子である。
担当者名欄１１５の担当者名は、担当者の氏名である。
管理者ユーザコード欄１１６の管理者ユーザコードは、管理者のユーザコードである。
管理者名欄１１７の管理者名は、管理者の氏名である。
領域１レベル欄１１８の領域１レベルは、タスクが要求するある領域における能力の水準である。領域２レベル欄１１９は、タスクが要求する他のある領域における能力の水準である。紙面の都合上記載を省略したが、異なる複数の領域ごとに、領域３レベル欄、領域４レベル欄、・・・が存在するものとする（他の図においても同様である）。なお、数字が大きいほど能力は高い。
タスク情報３１のレコード（行）の数は、タスクの数に一致する。

（タスク紐付情報）
図４に沿って、タスク紐付情報３２を説明する。タスク紐付情報３２においては、タスクコード欄１２１から後続タスク２名欄１３２までのデータが相互に関連付けて記憶されている。
タスクコード欄１２１のタスクコードは、図３のタスクコードと同じである。
タスク名欄１２２のタスク名は、図３のタスク名と同じである。
前提タスク１コード欄１２３の前提タスク１コードは、当該タスクに前提タスクがある場合の前提タスクのタスクコードである。前提タスク１名欄１２４の前提タスク１名は、前提タスクの名称である。前提タスク１完了予定日欄１２５の前提タスク１完了予定日は、前提タスクの完了予定日である。あるタスクに複数の前提タスクが存在する場合、前提タスク２コード欄１２６、前提タスク２名欄１２７及び前提タスク２完了予定日欄１２８に、他の前提タスクについてのデータが記憶される。記載を省略したが、前提タスク３コード欄、前提タスク３名欄、前提タスク３完了予定日欄、・・・が存在してもよい。

後続タスク１コード欄１２９の後続タスク１コードは、当該タスクに後続タスクがある場合の後続タスクのタスクコードである。後続タスク１名欄１３０の後続タスク１名は、後続タスクの名称である。あるタスクに複数の後続タスクが存在する場合、後続タスク２コード欄１３１及び後続タスク２名欄１３２に、他の後続タスクについてのデータが記憶される。記載を省略したが、後続タスク３コード欄、後続タスク３名欄、・・・が存在してもよい。
タスク紐付情報３２のレコードの数は、タスクの数に一致する。

（スキル領域情報）
図５に沿って、スキル領域情報３３を説明する。スキル領域情報３３においては、スキル領域欄１４１に記憶されたスキル領域（“領域１”、“領域２”、・・・）に関連付けて、スキル領域名欄１４２にはスキル領域名（スキルの領域の具体的な名称）が記憶されている。スキル領域情報３３のレコードの数は、スキルの領域の数に一致する。

（ユーザ情報）
図６に沿って、ユーザ情報３４を説明する。ユーザ情報３４においては、ユーザコード欄１５１から役割欄１６１までのデータが相互に関連付けて記憶されている。
ユーザコード欄１５１のユーザコードは、前記したユーザコードである。
ユーザ名欄１５２のユーザ名は、ユーザの氏名である。
領域１レベル欄１５３の領域レベル１は、その領域においてユーザが有する能力の水準である。領域２レベル欄１５４から領域７レベル欄１５９までには、他のそれぞれの領域においてユーザが有する能力の水準が記憶されている。なお、数字が大きいほど能力は高い。そして、例えば領域１レベル欄１５３の“５”は、領域１レベル欄１１８（図３）の“５”に対応している。
タスクグループコード欄１６０のタスクグループコードは、ユーザが既に割当てられているタスク又は割当てられる予定であるタスクが属するタスクグループのタスクグループコードである。タスクグループごとに、使用されるプログラム言語が特定されている場合が多い。
役割欄１６１の役割は、“担当者”、“管理者”及び“レビュアー”のうちのいずれかである。
ユーザ情報３４のレコードの数は、ユーザの数に一致する。

（ユーザ工数情報）
図７に沿って、ユーザ工数情報３５を説明する。ユーザ工数情報３５においては、ユーザコード欄１７１から非稼働日フラグ欄１７６までのデータが相互に関連付けて記憶されている。
ユーザコード欄１７１のユーザコードは、図６のユーザコードと同じである。但し、ここでのユーザは、特に“担当者”を想定している。
日付欄１７２の日付は、日繰りのカレンダー（年月日）である。
ユーザ名欄１７３のユーザ名は、図６のユーザ名と同じである。
タスクコード欄１７４のタスクコードは、当該日付において当該ユーザに対して割当てられたタスクのタスクコードである。
タスク名欄１７５のタスク名は、当該日付において当該ユーザに対して割当てられたタスクの名称である。
非稼働日フラグ欄１７６の非稼働日フラグは、当該ユーザが当該日付（休日）においては稼働しないことを示すフラグである。
ユーザ工数情報３５のレコードの数は、ユーザ及び日付の組合せの数に一致する。

（ユーザ空工数情報）
図８に沿って、ユーザ空工数情報３６を説明する。ユーザ空工数情報３６においては、ユーザコード欄１８１から合計空工数欄１８４までのデータが相互に関連付けて記憶されている。
ユーザコード欄１８１のユーザコードは、図６のユーザコードと同じである。
ユーザ名欄１８２のユーザ名は、図６のユーザ名と同じである。
検索日数欄１８３の検索日数は、ユーザの合計空工数（直ちに後記）を検索する対象期間の日数である。検索日数は、休日を除き、検索を行う日の翌日からカウントされる。
合計空工数欄１８４の合計空工数は、検索日数のうち、タスクが未だ割当てられていない日を合計した数である。
ユーザ空工数情報３６のレコードの数は、ユーザの数に一致する。

（遅延情報）
図９に沿って、遅延情報３７を説明する。遅延情報３７においては、タスクコード欄１９１から完了フラグ欄２０１までのデータが相互に関連付けて記憶されている。
タスクコード欄１９１から期日欄１９７までに記憶されているデータは、図３におけるそれぞれ同名の欄に記憶されているデータと同じである。
リカバリ期日欄１９８のリカバリ期日は、タスクが遅延している（期日が経過してもなお完了していない）場合に、担当者が回答した新たな期日の年月日である。つまり、担当者は、そのリカバリ期日までには、遅延したタスクを完了できると回答している。
原因欄１９９の原因は、タスクが遅延した原因である。
対策欄２００の対策は、タスクをリカバリ期日までに完了するための施策である。
完了フラグ欄２０１の完了フラグは、図３の完了フラグと同じである。
遅延情報３７のレコードの数は、遅延しているタスクの数に一致する。

（タスクグループ情報）
図１０に沿って、タスクグループ情報３８を説明する。タスクグループ情報３８においては、タスクグループコード欄２１１からフェーズ内並列タスク数欄２１７までのデータが相互に関連付けて記憶されている。
タスクグループコード欄２１１のタスクグループコードは、図３のタスクグループコードと同じである。
最短日数欄２１２の最短日数は、前記した最短日数である。
最長日数欄２１３の最長日数は、前記した最長日数である。
割当日数欄２１４の割当日数は、プロジェクト管理装置１がタスクに対し担当者を実際に割当てた場合のタスクグループの日数である。“最短日数≦割当日数≦最長日数”が成立する。

グループ内最大並列タスク数欄２１５のグループ内最大並列タスク数は、最短日数でタスクグループを完了する場合の、並列されるタスクの最大数である。タスク間に数珠繋ぎの前提後続関係のみが存在する場合、グループ内最大並列タスク数は、“１”である。枝への分岐又は枝からの合流が多くなるほど、グループ内最大並列タスク数が大きくなる場合が多い。なお、例えば、タスクグループ内において、２つのタイミングでそれぞれタスクが“２”個並列している場合、グループ内最大並列タスク数は、“４”ではなく“２”である。
フェーズコード欄２１６のフェーズコードは、タスクグループが属するフェーズを一意に特定する識別子である。
フェーズ内並列タスク数欄２１７のフェーズ内並列タスク数は、同じフェーズに属する１又は複数のタスクグループのグループ内最大並列タスク数の最大値である。
タスクグループ情報３８のレコードの数は、タスクグループの数に一致する。

（スケジュール案情報）
図１１及び図１２に沿って、スケジュール案情報３９を説明する。スケジュール案情報３９は、全体として、横軸（列）にカレンダーを有し、縦軸（行）に割当ユーザを有するマトリクスである。マトリクスの交点のセルに、その日付にその割当ユーザに割当てられたタスクのタスクコードが記憶されている。紙面の都合上、図１１及び図１２のスケジュール案情報３９は、６段に分かれているが、本来１つのものである。割当ユーザとは、スキルを捨象した仮想的な担当者である。図１１の縦軸の“１”、“２”、・・・“７”は、割当ユーザを一意に特定する識別子である。タスクの数が１８（Ａ〜Ｒ）であるのに対し、割当ユーザの数は７であるから、少なくとも１人の割当ユーザが、日付をずらして複数のタスクを掛け持ちすることが前提になっている。

図１１の割当ユーザの数が７人であるのに比して、図１２の割当ユーザの数は５人である。プロジェクト管理装置１は、図１１においては、２０１７年１月１９日から２７日にタスクＧを割当ユーザ“７”に割当てていたが、図１２においては、割当ユーザ“１”に割当てている（強調表示箇所）。同様に、プロジェクト管理装置１は、図１１においては、２０１７年２月９日及び１０日にタスクＡを割当ユーザ“６”に割当てていたが、図１２においては、割当ユーザ“３”に割当てている（強調表示箇所）。その結果、図１２においては、割当ユーザ“１”及び“３”の負担は大きくなっている。

図１３に沿って、フェーズ、タスクグループ及びタスクの関係、並びに、タスクに対してユーザを割当てる処理を概観する。二重線（工数欄の右）の左側を見ると、以下のことがわかる。
・工数は、タスクに対して定義される一方、最短日数、最長日数及びグループ内最大並列タスク数は、タスクグループに対して定義される。フェーズ内並列タスク数は、フェーズに対して定義される。
・フェーズ、タスクグループ及びタスクの包含関係は、“フェーズ＞タスクグループ＞タスク”である。

図１３の二重線の右側は、図１１のスケジュール案情報３９を、同じ内容で表現し直したものである。図１１に比して、図１３においては、横軸はカレンダーのままであるが、縦軸がタスクになっている。そして交点のセルに割当ユーザ“１”、“２”、・・・、“７”が記憶されている。二重線の右側を見ると、例えば、以下のことがわかる。

・グループ内最大並列タスク数は、タスクグループＴ４については“２”（２月１４日、１５日）であり、タスクグループＴ５については“３”（１月２５日〜３１日）である。
・フェーズＦ２のフェーズ内並列タスク数は、“３”（２と３のうち大きい方）である。
・タスクグループＴ４の最短日数“１２”は、２月８日〜２３日までの１２日間（休日除く）である。タスクグループＴ４の最長日数“１４”は、タスクＫを２月６日及び７日に配置した場合における、２月６日〜２３日までの１４日間である。
・１つのタスクグループが、１つのフェーズを構成することもある（Ｔ１及びＦ３）。

以降、処理手順（図１４〜図２３）を説明する。その過程で、表示画面例（図２４〜図２９）を参照する。

（定義入力処理手順）
図１４は、定義入力処理手順のフローチャートである。いま、ある管理者が、プロジェクト管理装置１を操作しているとする。
ステップＳ３０１において、プロジェクト管理装置１の計画策定部２１は、タスクの定義を受け付ける。具体的には、第１に、計画策定部２１は、出力装置１３にタスク定義画面４１（図２４（ａ））を表示する。
第２に、計画策定部２１は、管理者が入力欄４２に、タスクコード、タスク名、・・・を行ごとに入力し、登録／変更ボタン４３ｅを押下するのを受け付ける。

ステップＳ３０２において、計画策定部２１は、タスク情報３１（図３）を更新する。具体的には、計画策定部２１は、タスク情報３１の新たなレコードを作成し、新たなレコードの対応する欄にステップＳ３０１の“第２”において受け付けたデータを記憶する。

前記したステップＳ３０１及びＳ３０２の他にも、計画策定部２１は、管理者がタスク情報３１の既存レコードのタスクコードを入力したうえで削除ボタン４３ｆを押下するのを受け付けると、タスク情報３１から当該タスクのレコードを削除する。管理者が、タスク情報３１の既存レコードのタスクコードを入力した後、例えば変更後の工数を入力したうえで、登録／変更ボタン４３ｅを押下すると、計画策定部２１は、当該レコードの工数を上書き更新する。管理者が入力欄４２に、タスクコード、タスク名、・・・を行ごとに入力した後、仮登録／仮変更ボタン４３ａを押下しながら影響範囲表示ボタン４３ｃを押下すると、計画策定部２１は、出力装置１３に影響範囲調査結果画面８３（図２９（ａ））を表示する。計画策定部２１は、プロジェクト管理装置１に対してタスク間の前提後続関係が入力されていることを前提に、当該タスクが仮に登録（変更）された場合の当該タスクの下流にあるすべての後続タスクを強調表示する。

管理者が、タスク情報３１の既存レコードのタスクコードを入力した後、仮削除ボタン４３ｂを押下すると、計画策定部２１は、当該タスクが仮に削除された場合の当該タスクの下流にあるすべての後続タスクを強調表示する。管理者は、影響範囲調査結果画面８３を参照した後、登録、変更及び削除のいずれも行わない場合は、仮取消ボタン４３ｄを押下する。

ステップＳ３０３において、計画策定部２１は、タスクの紐付を受け付ける。具体的には、第１に、計画策定部２１は、出力装置１３にタスク紐付画面４４（図２４（ｂ））を表示する。
第２に、計画策定部２１は、管理者が入力欄４５に、複数のタスクを示す図形（例えば長方形）をタスクコードとともに描画するのを受け付ける。その後、計画策定部２１は、管理者が紐付ボタン４６ａを押下しながら、例えば、まずタスクＡの図形を選択し、続いて タスクＢの図形を選択し、最後に登録／変更ボタン４６ｅを押下するのを受け付ける。すると、計画策定部２１は、入力欄４５に描画されているタスクＡ（前提タスク）を起点としタスクＢ（後続タスク）を終点とする矢印を描画する。

ステップＳ３０４において、計画策定部２１は、タスク情報３１（図３）及びタスク紐付情報３２（図４）を更新する。具体的には、第１に、計画策定部２１は、タスク紐付情報３２の新たなレコードを作成し、新たなレコードの対応する欄に、ステップＳ３０３の“第２”において受け付けたデータに基づいて、タスク間の前提後続関係を定義するデータを記憶する。
第２に、計画策定部２１は、タスク情報３１のレコードのうち、ステップＳ３０３の“第２”で選択された後続タスクのレコードに、前提タスク有りフラグ“Ｘ”を記憶する。

前記したステップＳ３０３及びＳ３０４の他にも、計画策定部２１は、管理者が表示済の矢印を選択しながら紐付削除ボタン４６ｂを押下するのを受け付けると、タスク情報３１及びタスク紐付情報３２から、その前提後続関係を定義するデータを削除する。管理者が影響範囲表示ボタン４６ｄを押下すると、計画策定部２１は、仮に紐付又は紐付解除がなされた場合の影響範囲調査結果画面８３（図２９（ａ））を表示する。管理者が仮取消ボタン４６ｃを押下すると、計画策定部２１は、初期画面、又は、前回登録／変更ボタン４６ｅが押下された直後における入力欄４５を表示する。

ステップＳ３０５において、計画策定部２１は、後続タスクの着手可能日を更新する。具体的には、第１に、計画策定部２１は、タスク情報３１のレコードのうち、ステップＳ３０３の“第２”で選択された後続タスクを以下の３つに場合分けする。
〈第１の場合〉後続タスクの上流にあるすべての前提タスクの前提タスク有り欄１０６（図３）に“Ｘ”が記憶されている。
〈第２の場合〉後続タスクの上流にある前提タスクのうちに、前提タスク有り欄１０６が空欄であるものが存在し、かつ、後続タスクの上流にある前提タスクのうちに、完了予定日欄１０５が空欄であるものが存在する。
〈第３の場合〉後続タスクの上流にある前提タスクのうちに、前提タスク有り欄１０６が空欄であるものが存在し、かつ、後続タスクの上流にあるすべての前提タスクの完了予定日欄１０５に日付が記憶されている。

第２に、計画策定部２１は、後続タスクのレコードの着手可能日欄１０７を以下のように更新する。
〈前記第１の場合〉着手可能日欄１０７に、“最も遅い前提タスクの完了予定日＋１”を記憶する。
〈前記第２の場合〉着手可能日欄１０７を空欄とする。
〈前記第３の場合〉着手可能日欄１０７に、“最も遅い前提タスクの完了予定日＋１”及び“現在日＋１”のうちのいずれか遅い日付を記憶する。

ステップＳ３０６において、計画策定部２１は、スキル領域の定義を受け付ける。具体的には、第１に、計画策定部２１は、出力装置１３にスキル定義画面４７（図２５（ａ））を表示する。
第２に、計画策定部２１は、管理者が入力欄４８に、領域１のスキル領域名、領域２のスキル領域名、・・・を入力し、登録／変更ボタン４９を押下するのを受け付ける。
ステップＳ３０７において、計画策定部２１は、スキル領域情報３３（図５）を更新する。具体的には、計画策定部２１は、ステップＳ３０６の“第２”において受け付けたデータを使用して、スキル領域情報３３を作成・更新する。

ステップＳ３０８において、計画策定部２１は、ユーザの定義を受け付ける。具体的には、第１に、計画策定部２１は、出力装置１３にユーザ定義画面５０（図２５（ｂ））を表示する。
第２に、計画策定部２１は、管理者が入力欄５１に、ユーザコード、ユーザ名、領域１のレベル、・・・、役割を入力し、登録／変更ボタン５２を押下するのを受け付ける。
ステップＳ３０９において、計画策定部２１は、ユーザ情報３４（図６）を更新する。具体的には、計画策定部２１は、ステップＳ３０８の“第２”において受け付けたデータを使用して、ユーザ情報３４を作成・更新する。その後、定義入力処理手順を終了する。

（計画策定処理手順）
図１５は、計画策定処理手順のフローチャートである。引き続き管理者がプロジェクト管理装置１を操作しているとする。
ステップＳ３２１において、プロジェクト管理装置１の計画策定部２１は、計画期間を受け付ける。具体的には、第１に、計画策定部２１は、出力装置１３に計画策定画面５３（図２５（ｃ））を表示する。
第２に、計画策定部２１は、管理者が入力欄５４に、計画期間を入力し、計画策定ボタン５５を押下するのを受け付ける。計画期間とは、前記したシミュレーションの期間である。個別具体的な担当者の採用・研修に先立ち、管理者は、必要な担当者の数、レベル等を知ろうとする。計画期間はそのための期間であり、フェーズの期間を含む。

ステップＳ３２２において、計画策定部２１は、タスクグループを抽出する。具体的には、計画策定部２１は、タスク情報３１（図３）及びタスク紐付情報３２（図４）を参照して、タスクグループを抽出する。例えば、計画策定部２１は、後続タスクを有しないタスクを抽出し、当該タスクの前提タスクを上流側に順次遡って行く。途中で前提タスクを複数有するタスクに到達した場合は枝分かれし、それぞれの枝について前提タスクを上流側に順次遡る。計画策定部２１は、すべての枝について、前提タスクを有さないタスクに到達するまでこの処理を続け、前提後続関係で繋がったひとまとまりのタスクの集合をタスクグループとする。計画策定部２１は、複数のタスクグループを抽出することになる。

ステップＳ３２３において、計画策定部２１は、タスクグループの最短日数等を算出する。具体的には、第１に、計画策定部２１は、ステップＳ３２２において抽出したすべてのタスクグループの最短日数を図１（ｂ）の例に従って算出する。最短日数は、前提後続関係に矛盾しない範囲で可能な限りタスクが並列された場合の日数である。
第２に、計画策定部２１は、ステップＳ３２２において抽出したすべてのタスクグループの最長日数を図１（ｃ）の例に従って算出する。このとき計画策定部２１は、タスクの並列をなくす。

ステップＳ３２４において、計画策定部２１は、すべてのタスクグループの最短日数が計画期間以内であるか否かを判断する。具体的には、計画策定部２１は、ステップＳ３２２において抽出したすべてのタスクグループの最短日数を、ステップＳ３２１の“第２”において受け付けた計画期間と比較する。計画策定部２１は、すべてのタスクグループの最短日数が計画期間以内である場合（ステップＳ３２４“Ｙｅｓ”）、ステップＳ３２５に進み、それ以外の場合（ステップＳ３２４“Ｎｏ”）、ステップＳ３２９に進む。

ステップＳ３２５において、計画策定部２１は、タスクグループをフェーズにまとめる。いま、計画期間が“２８日”であり、最短日数が、“（タスクグループコード，最短日数）＝（Ｔ１，２７），（Ｔ２，５），（Ｔ３，１２），（Ｔ４，１２），（Ｔ５，１２）”であったとする。第１に、計画策定部２１は、最短日数が少ない順にタスクグループを並び替える。すると、タスクグループは、“（タスクグループコード，最短日数）＝（Ｔ２，５），（Ｔ３，１２），（Ｔ４，１２），（Ｔ５，１２），（Ｔ１，２７）”のように並び替えられる。

第２に、計画策定部２１は、先頭のタスクグループから順に最短日数を加算し、加算結果が計画期間を超える直前で境界線を入れる。そして、計画策定部２１は、加算結果を“０”にリセットしたうえで、境界線より後のタスクグループについて、同様の処理を繰り返す。計画策定部２１は、この処理を前記の例の最短日数に対して適用すると、以下の結果を得る。ここで、“｜”は、境界線である。
（タスクグループコード，最短日数）＝（Ｔ２，５），（Ｔ３，１２）｜（Ｔ４，１２），（Ｔ５，１２）｜（Ｔ１，２７）

第３に、計画策定部２１は、境界線で区切られた１又は複数のタスクグループをフェーズとし、フェーズに対してフェーズコードを付す。前記の例では、タスクグループＴ２及びＴ３に対してフェーズコードＦ１が付され、タスクグループＴ４及びＴ５に対してフェーズコードＦ２が付され、タスクグループＴ１に対してフェーズコードＦ３が付される。

ステップＳ３２６において、計画策定部２１は、タスクグループ情報３８（図１０）を更新する。具体的には、第１に、計画策定部２１は、タスクグループ情報３８の新たなレコードを、タスクグループの数だけ作成する。
第２に、計画策定部２１は、新たなレコードに、タスクグループコード、最短日数、最長日数及びフェーズコードを記憶する。
第３に、計画策定部２１は、それぞれのタスクグループのグループ内最大並列タスク数を算出したうえで、新たなレコードに、グループ内最大並列タスク数及びフェーズ内並列タスク数を記憶する。割当日数欄２１４は、ここでは空欄のままとしておく。

ステップＳ３２７において、計画策定部２１は、スケジュール案情報３９（図１１）を作成する。具体的には、第１に、計画策定部２１は、各タスクに対し、１日あたり所定の数の割当ユーザを割当て、スケジュール案情報３９（図１１）を作成する。
第２に、計画策定部２１は、割当ユーザの数を任意の数だけ減少させたうえで、ステップＳ３２７の“第１”の処理を繰り返す。そして、計画策定部２１は、見直し後のスケジュール案情報３９（図１２）を作成する。

ステップＳ３２８において、計画策定部２１は、タスクグループのマッピング図５６（図２６（ａ））を表示する。具体的には、第１に、計画策定部２１は、タスクグループのマッピング図５６を出力装置１３に表示する。タスクグループのマッピング図５６は、計画期間内に実施できるフェーズごとに、フェーズ欄５７ａ、５７ｂ及び５７ｃを有する。
第２に、計画策定部２１は、各フェーズ欄５７ａ、５７ｂ及び５７ｃに、そのフェーズに属するすべてのタスクグループごとに、各タスクを示す図形、各タスクの工数、及び、前提後続関係を示す矢印を表示する。計画策定部２１は、タスク情報３１（図３）及びタスク紐付情報３２（図４）を参照して当該表示をするためのデータを取得する。

第３に、計画策定部２１は、各フェーズ欄５７ａ、５７ｂ及び５７ｃに、それぞれ要員欄５８ａ、５８ｂ及び５８ｃを表示する。各要員欄５８ａ、５８ｂ及び５８ｃには、そのフェーズを計画期間内に完了させるために必要な担当者の延べ人数、並びに、タスクごとに必要とされる担当者のレベル及び担当者の延べ人数が表示されている。計画策定部２１は、タスク情報３１（図３）及びタスクグループ情報３８（図１０）を参照して当該表示をするためのデータを取得する。
第４に、計画策定部２１は、管理者がスケジュール案参照ボタン５７ｄを押下するのを受け付けると、スケジュール案情報３９（図１１）及び見直し後のスケジュール案情報３９（図１２）を、出力装置１３に表示する。

ステップＳ３２９において、計画策定部２１は、計画期間に収まらないタスクグループを表示する。いま、計画期間が“２４日”であり、最短日数が、“（タスクグループコード，最短日数）＝（Ｔ１，２７），（Ｔ２，５），（Ｔ３，１２），（Ｔ４，１２），（Ｔ５，１２）”であったとする。タスクグループＴ１の最短日数“２７”は、計画期間“２４”を超過している。このとき、計画策定部２１は、実施不可タスクグループ図５９（図２６（ｂ））を出力装置１３に表示する。実施不可タスクグループ図５９においては、タスクグループＴ１の各タスクを示す図形、各タスクの工数、及び、前提後続関係を示す矢印が表示されている。計画策定部２１は、タスク情報３１（図３）及びタスク紐付情報３２（図４）を参照して当該表示をするためのデータを取得する。ステップＳ３２８又はＳ３２９の後、計画策定処理手順を終了する。

（タスク自動割当処理手順）
図１６は、タスク自動割当処理手順のフローチャートである。引き続き管理者がプロジェクト管理装置１を操作しているとする。
ステップＳ３４１において、プロジェクト管理装置１のタスク自動割当部２２は、ユーザを割当てるべきタスクを抽出する。具体的には、タスク自動割当部２２は、タスク情報３１（図３）から、担当者ユーザコード欄１１４、遅延フラグ欄１１２及び遅延見込フラグ欄１１３のいずれもが空欄であるタスクを抽出する。そのようなタスクが抽出できない場合は、タスク自動割当部２２は、タスク自動割当処理手順を終了する。

ステップＳ３４２において、タスク自動割当部２２は、タスクを並び替える。具体的には、タスク自動割当部２２は、ステップＳ３４１において抽出したタスクを以下の優先順位で並び替える。
〈優先順位１〉遅延フラグ欄１１２が空欄であるタスク→完了フラグ欄１１１が空欄であるタスク→完了予定日欄１０５が空欄であるタスク、の順
〈優先順位２〉優先順位１で差がつかない場合、前提タスク有り欄１０６が空欄であるタスク→前提タスク有り欄１０６が空欄ではなく着手可能日欄１０７も空欄ではないタスク、の順
〈優先順位３〉優先順位２で差がつかない場合、期日が現在日に近い順
〈優先順位４〉優先順位３で差がつかない場合、優先度が高い順

ステップＳ３４３において、タスク自動割当部２２は、ユーザを割当てるべきタスクを特定する。具体的には、タスク自動割当部２２は、ステップＳ３４２において並び替えたタスクのうち、未処理の先頭のタスクを取得する。ここで取得されたタスクを“割当対象タスク”と呼ぶ。

ステップＳ３４４において、タスク自動割当部２２は、レベルを満たすユーザ候補を抽出する。具体的には、第１に、タスク自動割当部２２は、タスク情報３１（図３）を参照し、割当対象タスクの各領域のレベルを取得する。
第２に、タスク自動割当部２２は、ユーザ情報３４（図６）を参照し、ステップＳ３４４の“第１”において取得したレベルを満たしかつ役割が“担当者”であるユーザを抽出する。ここで抽出されたユーザを、“ユーザ候補”と呼ぶ。

ステップＳ３４５において、タスク自動割当部２２は、少なくとも１人のユーザ候補が抽出できたか否かを判断する。具体的には、タスク自動割当部２２は、ステップＳ３４４の“第２”において少なくとも１人のユーザ候補が抽出できた場合（ステップＳ３４５“Ｙｅｓ”）、ステップＳ３４６に進み、できなかった場合（ステップＳ３４５“Ｎｏ”）、ステップＳ３５２に進む。

ステップＳ３４６において、タスク自動割当部２２は、ユーザ候補を並び替える。具体的には、タスク自動割当部２２は、ステップＳ３４４の“第２”において抽出したユーザ候補を以下の優先順位で並び替える。
〈優先順位１１〉割当対象タスクが属するタスクグループに属する他のタスクに対して既に割当てられているユーザ候補→割当対象タスクが属するタスクグループに属する他のタスクに対して未だ割当てられていないユーザ候補、の順
〈優先順位１２〉優先順位１１で差がつかない場合、ユーザ空工数情報３６（図８）における、所定の検索日数に対応する合計空工数が多い順

ステップＳ３４７において、タスク自動割当部２２は、ユーザをタスクに割当てる。具体的には、第１に、タスク自動割当部２２は、割当対象タスクに対して１日ごとに所定の数のユーザ候補を割当てる。例えば、現在日が１月３０日（月）であり、割当対象タスクの期日が２月９日（木）であり、その工数が５日であるとする。一方、並び替えた後先頭にいるユーザ候補に対しては、２月１日（水）から２月８日（水）までタスクが割当てられておらず、２月４日（土）及び２月５日（日）には非稼働日フラグが立っているとする。この場合、タスク自動割当部２２は、２月１日（水）、２月２日（木）、２月３日（金）、２月６日（月）及び２月７日（火）に、先頭にいるユーザ候補に対して割当対象タスクを割当てる（１日ごとに１人を前倒しで割当てる例）。
第２に、タスク自動割当部２２は、タスク情報３１のレコードのうち、ステップＳ３４７の“第１”においてユーザに割当てたタスクのレコードの担当者ユーザコード欄１１４及び担当者名欄１１５に、それぞれ、担当者ユーザコード及び担当者名を記憶する。

ステップＳ３４８において、タスク自動割当部２２は、ユーザ工数情報３５（図７）を更新する。具体的には、タスク自動割当部２２は、ユーザ工数情報３５のレコードのうち、ステップＳ３４７の“第１”において割当てたユーザの割当てた日付のレコードのタスクコード欄１７４及びタスク名欄１７５に、それぞれ、割当てたタスクのタスクコード及びタスク名を記憶する。

ステップＳ３４９において、タスク自動割当部２２は、ユーザ空工数情報３６（図８）を更新する。具体的には、第１に、タスク自動割当部２２は、ユーザ空工数情報３６のレコードのうち、ステップＳ３４７の“第１”において割当てたユーザのレコードの検索日数を取得する。
第２に、タスク自動割当部２２は、ユーザ工数情報３５（図７）のレコードのうち、ステップＳ３４７の“第１”において割当てたユーザのレコードであって、その日付が現在日の翌日以降“現在日＋検索日数”までの期間であるレコードを特定する。
第３に、タスク自動割当部２２は、ステップＳ３４９の“第２”において特定したレコードの数を、ステップＳ３４９の“第１”において取得したレコードの合計空工数欄１８４に記憶する。

ステップＳ３５０において、タスク自動割当部２２は、タスクのすべての工数についてユーザを割当てたか否かを判断する。具体的には、タスク自動割当部２２は、ステップＳ３４７の“第１”においてユーザを割当てた結果、割当対象タスクの工数が完全に満たされた場合（ステップＳ３５０“Ｙｅｓ”）、ステップＳ３５３に進み、それ以外の場合（ステップＳ３５０“Ｎｏ”）、ステップＳ３５１に進む。
ステップＳ３５１において、タスク自動割当部２２は、ユーザ候補が残っているか否かを判断する。具体的には、割当対象タスクに対して割当可能なユーザ候補が残っている場合（ステップＳ３５１“Ｙｅｓ”）、ステップＳ３４７に戻り、残っていない場合（ステップＳ３５１“Ｎｏ”）、ステップＳ３５２に進む。

ステップＳ３５２において、タスク自動割当部２２は、遅延見込フラグを立てる。具体的には、タスク自動割当部２２は、タスク情報３１（図３）において、割当対象タスクのレコードの遅延見込フラグ欄１１３に“Ｘ”を記憶する。
ステップＳ３５３において、タスク自動割当部２２は、すべてのタスクに対してユーザを割当てたか否かを判断する。具体的には、タスク自動割当部２２は、未処理の割当対象タスクが存在しない場合（ステップＳ３５３“Ｙｅｓ”）、タスク自動割当処理を終了し、未処理の割当対象タスクが存在する場合（ステップＳ３５１“Ｎｏ”）、ステップＳ３４３に戻る。

（タスク手動割当処理手順）
図１７は、タスク手動割当処理手順のフローチャートである。引き続き管理者がプロジェクト管理装置１を操作しているとする。
ステップＳ３６１において、プロジェクト管理装置１のタスク手動割当部２３は、ユーザを割当てるべきタスクを抽出する。具体的には、タスク手動割当部２３は、タスク情報３１（図３）から、担当者ユーザコード欄１１４が空欄であるレコードを抽出する。そのようなレコードが抽出できない場合は、タスク自動割当部２２は、タスク手動割当処理手順を終了する。

ステップＳ３６２において、タスク手動割当部２３は、タスク割当画面６０（図２７（ａ））を表示する。具体的には、タスク手動割当部２３は、タスク割当画面６０を出力装置１３に表示し、その未割当タスク欄６１に、ステップＳ３６１において抽出したレコードのタスクコード、タスク名、期日、工数、タスクグループコード、領域１レベル、・・・、優先度を表示する。以降では、未割当タスク欄６１の１行目に表示されている“タスクＶ”に対して、管理者が手動で担当者を割当てる例を説明する。

ステップＳ３６３において、タスク手動割当部２３は、タスクの選択を受け付ける。具体的には、タスク手動割当部２３は、管理者が、タスクＶを示すラジオボタン６２を選択した状態で割当提案ボタン６３ｂを押下するのを受け付ける。因みに、管理者がラジオボタン６２を選択した状態で影響範囲表示ボタン６３ａを押下すると、タスク手動割当部２３は、出力装置１３に影響範囲調査結果画面８３（図２９（ａ））を表示する。また、管理者が割当取消ボタン６３ｃを押下すると、タスク手動割当部２３は、割当提案ボタン６３ｂの押下を取消す。

ステップＳ３６４において、タスク手動割当部２３は、レベルを満たすユーザ候補を抽出する。具体的には、タスク手動割当部２３は、割当対象タスクを“タスクＶ”としたうえで、タスク自動割当処理手順（図１６）のステップＳ３４４の処理を実行することによって、タスクＶに割当可能なユーザ候補を抽出する。このときタスク手動割当部２３は、タスクＶの工数よりも、現在日の翌日以降タスクＶの期日までの期間の合計空工数が小さくなるようなユーザ候補を抽出することはない。

ステップＳ３６５において、タスク手動割当部２３は、少なくとも１人のユーザ候補を抽出できたか否かを判断する。具体的には、タスク手動割当部２３は、ステップＳ３６４において少なくとも１人のユーザ候補が抽出できた場合（ステップＳ３６５“Ｙｅｓ”）、ステップＳ３６７に進み、できなかった場合（ステップＳ３６５“Ｎｏ”）、ステップＳ３６６に進む。
ステップＳ３６６において、タスク手動割当部２３は、割当不可メッセージを表示する。具体的には、タスク手動割当部２３は、“そのタスクに対して割当可能な担当者が見つかりません”というメッセージを出力装置１３に表示する。このとき、タスク手動割当部２３は、メッセージを音声で出力してもよい。

ステップＳ３６７において、タスク手動割当部２３は、割当可能ユーザ一覧画面６４（図２７（ｂ））を表示する。具体的には、第１に、タスク手動割当部２３は、ユーザ一覧欄６５の担当者ユーザコード欄及び担当者名欄に、ユーザ候補のそれぞれユーザコード及び担当者名を表示し、期日欄に、タスクＶの期日を表示する。さらに、タスク手動割当部２３は、タスクグループ欄に“一致”又は“不一致”のいずれかを表示する。“一致”は、タスクＶが属するタスクグループの他のタスクに対し、その担当者が既に割当てられていることを示す。“不一致”は、タスクＶが属するタスクグループの他のタスクに対し、その担当者が未だ割当てられていないことを示す。

第２に、タスク手動割当部２３は、工数欄に分数を表示する。分子は、現在日の翌日以降タスクＶの期日までのその担当者の空工数である。分母は、タスクＶの工数である。タスク手動割当部２３は、領域１レベル欄にも分数を表示する。分子は、その担当者の領域１のレベルである。分母は、タスクＶに要求される領域１のレベルである。他の領域についても同様である。その後、管理者は、ユーザ一覧欄６５にタスクＶに対して割当てたいユーザ候補がいる場合、そのユーザを示すラジオボタン６６を選択した状態で割当実行ボタン６７ｂを押下する。管理者は、ユーザ一覧欄６５の内にタスクＶに対して割当てたいユーザ候補がいない場合、全ユーザ表示ボタン６７ａを押下する。
第３に、タスク手動割当部２３は、管理者がこれらのボタンのいずれかを押下するのを受け付ける。

ステップＳ３６８において、タスク手動割当部２３は、割当てたいユーザ候補が存在するか否かを判断する。具体的には、タスク手動割当部２３は、割当てたいユーザ候補が存在せず、全ユーザ表示ボタン６７ａの押下を受け付けた場合（ステップＳ３６８“Ｎｏ”）、ステップＳ３６９に進む。タスク手動割当部２３は、割当てたいユーザ候補が存在し、割当実行ボタン６７ｂの押下を受け付けた場合（ステップＳ３６８“Ｙｅｓ”）、ステップＳ３７１に進む。

ステップＳ３６９において、タスク手動割当部２３は、ユーザ候補を再度抽出する。具体的には、タスク手動割当部２３は、ユーザ情報３４（図６）を参照し、以下の２つの緩和条件を満たすユーザを抽出する。
〈緩和条件１〉タスクＶが要求するレベルを所定の程度緩和したレベルを有すること。所定の程度とは、例えば「タスクＶが要求するレベルを一律的に“１”とする」である。
〈緩和条件２〉現在日の翌日以降タスクＶの期日までの期間を所定の程度緩和した合計空工数を有すること。所定の程度とは、例えば「合計空工数が“１”以上である」である。

ステップＳ３７０において、タスク手動割当部２３は、全ユーザ一覧画面６８（図２７（ｃ））を表示する。具体的には、第１に、タスク手動割当部２３は、全ユーザ一覧画面６８を出力装置１３に表示する。全ユーザ一覧画面６８の構成は、割当可能ユーザ一覧画面６４（図２７（ｂ））と同じである。ステップＳ３６５“Ｙｅｓ”を経由した場合、タスク手動割当部２３は、全ユーザ一覧画面６８のレコード６９ａ〜６９ｆを表示する一方、ステップＳ３６５“Ｎｏ”を経由した場合、全ユーザ一覧画面６８は、レコード６９ｄ〜６９ｆのみを表示することになる。そして、タスク手動割当部２３は、レコード６９ｄ〜６９ｆに表示される分数のうち、分子が分母未満であるものの分子に“＃”を付す。
第２に、タスク手動割当部２３は、管理者が、任意のユーザを示すラジオボタン７０を選択した状態で、割当実行ボタン７１ｂを押下するのを受け付ける。因みに、管理者が絞込ユーザ表示ボタン７１ａを押下するのを受け付けると、タスク手動割当部２３は、割当可能ユーザ一覧画面６４（図２７（ｂ））を表示する。

ステップＳ３７１において、タスク手動割当部２３は、ユーザをタスクに割当てる。具体的には、タスク手動割当部２３は、タスク情報３１（図３）からタスクＶのレコードを取得する。そして、タスク手動割当部２３は、取得したレコードの担当者ユーザコード欄１１４及び担当者名欄１１５に、ステップＳ３６７の“第２”又はステップＳ３７０の“第２”において選択された担当者のユーザコード及び担当者名をそれぞれ記憶する。
ステップＳ３７２において、タスク手動割当部２３は、ユーザ工数情報３５（図７）を更新する。当該ステップの処理は、タスク自動割当処理手順のステップＳ３４８と同様である。
ステップＳ３７３において、タスク手動割当部２３は、ユーザ空工数情報３６（図８）を更新する。当該ステップの処理は、タスク自動割当処理手順のステップＳ３４９と同様である。その後、タスク手動割当処理手順を終了する。

（タスク着手処理手順）
図１８は、タスク着手処理手順のフローチャートである。担当者に対するタスクの割当が完了し、いま、担当者端末装置３を携帯している担当者“日立一郎”がタスク“テストＡ”に着手したとする。
ステップＳ３８１において、プロジェクト管理装置１のタスク進捗管理部２４は、タスク進捗画面７２（図２８（ａ））を表示する。具体的には、第１に、タスク進捗管理部２４は、日立一郎が操作する担当者端末装置３から、“タスク進捗画面表示要求”及び日立一郎のユーザコードを受信する。
第２に、タスク進捗管理部２４は、ユーザコードを検索キーとしてタスク情報３１（図３）を検索し、該当するすべてのレコードを取得し、取得したレコードのタスク名、担当者名、管理者名、期日、優先度、工数、着手日及び完了フラグを取得する。
第３に、タスク進捗管理部２４は、担当者端末装置３の出力装置に、タスク進捗画面７２を表示し、タスクリスト欄７３に、ステップＳ３８１の“第２”において取得したデータをタスクごとに表示する。

ステップＳ３８２において、タスク進捗管理部２４は、着手ボタンの押下を受け付ける。具体的には、タスク進捗管理部２４は、担当者が“テストＡ”を示すラジオボタン７４ａを選択した状態で着手ボタン７５ａを押下するのを受け付ける。
ステップＳ３８３において、タスク進捗管理部２４は、前提タスクが存在するか否かを判断する。具体的には、タスク進捗管理部２４は、タスク情報３１を参照した結果、“テストＡ”の前提タスクが存在する場合（ステップＳ３８３“Ｙｅｓ”）、ステップＳ３８４に進み、存在しない場合（ステップＳ３８３“Ｎｏ”）、ステップＳ３８７に進む。

ステップＳ３８４において、タスク進捗管理部２４は、前提タスクが完了しているか否かを判断する。具体的には、タスク進捗管理部２４は、タスク情報３１を参照した結果、前提タスクの完了フラグが記憶されている場合（ステップＳ３８４“Ｙｅｓ”）、ステップＳ３８７に進み、記憶されていない場合（ステップＳ３８４“Ｎｏ”）、ステップＳ３８５に進む。
ステップＳ３８５において、タスク進捗管理部２４は、メッセージを表示し、ボタンの押下を促す。具体的には、タスク進捗管理部２４は、“前提タスクが完了していません。着手する場合は、着手ボタン７５ａを再度押下して下さい。着手しない場合は、着手取消ボタン７５ｂを押下して下さい。”というメッセージを担当者端末装置３の出力装置に、表示する。

ステップＳ３８６において、タスク進捗管理部２４は、再度着手ボタンの押下を受け付けたか否かを判断する。具体的には、タスク進捗管理部２４は、着手ボタン７５ａの押下を再度受け付けた場合（ステップＳ３８６“Ｙｅｓ”）、ステップＳ３８７に進み、受け付けなかった場合（ステップＳ３８６“Ｎｏ”）、タスク着手処理手順を終了する。
ステップＳ３８７において、タスク進捗管理部２４は、タスク情報３１（図３）を更新する。具体的には、第１に、タスク進捗管理部２４は、タスク情報３１の“テストＡ”の着手日として現在日を記憶する。
第２に、タスク進捗管理部２４は、タスク進捗画面７２のタスクリスト欄７３の“テストＡ”の着手日の欄に現在日を表示する。その後、タスク着手処理手順終了する。

（タスク着手取消処理手順）
図１９は、タスク着手取消処理手順のフローチャートである。いま、担当者端末装置３を携帯している担当者“日立一郎”がタスク“カスタマイズＡ”に着手した後、その着手を取消すとする。
ステップＳ４０１において、プロジェクト管理装置１のタスク進捗管理部２４は、タスク進捗画面７２（図２８（ａ））を表示する。当該ステップの処理は、タスク着手処理手順のステップＳ３８１と同様である。

ステップＳ４０２において、タスク進捗管理部２４は、着手取消ボタンの押下を受け付ける。具体的には、タスク進捗管理部２４は、担当者が“カスタマイズＡ”を示すラジオボタン７４ｂを選択した状態で着手取消ボタン７５ｂを押下するのを受け付ける。
ステップＳ４０３において、タスク進捗管理部２４は、タスク情報３１（図３）を更新する。具体的には、第１に、タスク進捗管理部２４は、タスク情報３１の“カスタマイズＡ”の着手日を空欄とする。
第２に、タスク進捗管理部２４は、タスク進捗画面７２のタスクリスト欄７３の“カスタマイズＡ”の着手日の欄を空欄にする。その後、タスク着手取消処理手順終了する。

（タスク完了処理手順）
図２０は、タスク完了処理手順のフローチャートである。いま、担当者端末装置３を携帯している担当者“日立一郎”がタスク“カスタマイズＡ”完了したとする。
ステップＳ４２１において、プロジェクト管理装置１のタスク進捗管理部２４は、タスク進捗画面７２（図２８（ａ））を表示する。当該ステップの処理は、タスク着手処理手順のステップＳ３８１と同様である。

ステップＳ４２２において、タスク進捗管理部２４は、完了ボタンの押下を受け付ける。具体的には、タスク進捗管理部２４は、担当者が“カスタマイズＡ”を示すラジオボタン７４ｂを選択した状態で完了ボタン７５ｃを押下するのを受け付ける。
ステップＳ４２３において、タスク進捗管理部２４は、タスク情報３１（図３）を更新する。具体的には、タスク進捗管理部２４は、タスク情報３１の“カスタマイズＡ”のレコードの完了フラグ欄１１１に“Ｘ”を記憶する。

ステップＳ４２４において、タスク進捗管理部２４は、遅延情報３７（図９）に当該タスクのレコードが存在するか否かを判断する。具体的には、タスク進捗管理部２４は、遅延情報３７にタスク“カスタマイズＡ”のレコードが存在する場合（ステップＳ４２４“Ｙｅｓ”）、ステップＳ４２５に進み、存在しない場合（ステップＳ４２４“Ｎｏ”）、ステップＳ４２６に進む。
ステップＳ４２５において、タスク進捗管理部２４は、遅延情報３７を更新する。具体的には、タスク進捗管理部２４は、遅延情報３７の“カスタマイズＡ”のレコードの完了フラグ欄２０１に“Ｘ”を記憶する。

ステップＳ４２６において、タスク進捗管理部２４は、タスク紐付情報３２（図４）に当該タスクの後続タスクのレコードが存在するか否かを判断する。具体的には、タスク進捗管理部２４は、タスク紐付情報３２に“カスタマイズＡ”の後続タスクのレコードが存在する場合（ステップＳ４２６“Ｙｅｓ”）、ステップＳ４２７に進み、存在しない場合（ステップＳ４２６“Ｎｏ”）、タスク完了処理手順を終了する。

ステップＳ４２７において、タスク進捗管理部２４は、後続タスクの着手可能日を更新する。具体的には、第１に、タスク進捗管理部２４は、定義入力処理手順（図１４）のステップＳ３０５と同じ処理を実行する。
第２に、タスク進捗管理部２４は、タスク進捗画面７２のタスクリスト欄７３のカスタマイズＡの完了フラグ欄に“Ｘ”を表示する。その後、タスク完了処理手順終了する。

（タスク完了取消処理手順）
図２１は、タスク完了取消処理手順のフローチャートである。いま、担当者端末装置３を携帯している担当者“日立一郎”がタスク“カスタマイズＢ”を完了した後、その完了を取消すとする。
ステップＳ４４１において、プロジェクト管理装置１のタスク進捗管理部２４は、タスク進捗画面７２（図２８（ａ））を表示する。当該ステップの処理は、タスク着手処理手順のステップＳ３８１と同様である。

ステップＳ４４２において、タスク進捗管理部２４は、完了取消ボタンの押下を受け付ける。具体的には、タスク進捗管理部２４は、担当者が“カスタマイズＢ”を示すラジオボタン７４ｃを選択した状態で完了取消ボタン７５ｄを押下するのを受け付ける。
ステップＳ４４３において、タスク進捗管理部２４は、タスク情報３１（図３）を更新する。具体的には、タスク進捗管理部２４は、タスク情報３１のタスク名“カスタマイズＢ”のレコードの完了フラグ欄１１１を空欄にする。

ステップＳ４４４において、タスク進捗管理部２４は、遅延情報３７（図９）に当該タスクのレコードが存在するか否かを判断する。具体的には、タスク進捗管理部２４は、遅延情報３７にタスク“カスタマイズＢ”のレコードが存在する場合（ステップＳ４４４“Ｙｅｓ”）、ステップＳ４４５に進み、存在しない場合（ステップＳ４４４“Ｎｏ”）、ステップＳ４４６に進む。
ステップＳ４４５において、タスク進捗管理部２４は、遅延情報３７を更新する。具体的には、タスク進捗管理部２４は、遅延情報３７の“カスタマイズＢ”のレコードの完了フラグ欄２０１を空欄にする。

ステップＳ４４６において、タスク進捗管理部２４は、期日が経過しているか否かを判断する。具体的には、タスク進捗管理部２４は、タスク情報３１を参照し、カスタマイズＢの期日を取得する。そして、タスク進捗管理部２４は、取得した期日を現在日が経過（期日＜現在日）している場合（ステップＳ４４６“Ｙｅｓ”）、ステップＳ４４７に進み、経過していない場合（ステップＳ４４６“Ｎｏ”）、ステップＳ４４８に進む。

ステップＳ４４７において、タスク進捗管理部２４は、遅延情報３７（図９）を更新する。具体的には、タスク進捗管理部２４は、遅延情報３７の新たなレコードを作成し、新たなレコードのタスクコード欄１９１〜期日欄１９７を埋める。タスク進捗管理部２４は、タスク名“カスタマイズＢ”を検索キーとしてタスク情報３１を参照して、これらの欄を埋めるのに必要なデータを取得する。他の欄は空欄としておく。

ステップＳ４４８において、タスク進捗管理部２４は、タスク紐付情報３２（図４）に当該タスクの後続タスクのレコードが存在するか否かを判断する。具体的には、タスク進捗管理部２４は、タスク紐付情報３２に“カスタマイズＢ”の後続タスクのレコードが存在する場合（ステップＳ４４８“Ｙｅｓ”）、ステップＳ４４９に進み、存在しない場合（ステップＳ４４８“Ｎｏ”）、タスク完了取消処理手順を終了する。

ステップＳ４４９において、タスク進捗管理部２４は、後続タスクの着手可能日を更新する。具体的には、第１に、タスク進捗管理部２４は、定義入力処理手順（図１４）のステップＳ３０５の処理を実行する。
第２に、タスク進捗管理部２４は、タスク進捗画面７２のタスクリスト欄７３のカスタマイズＢの完了フラグ欄を空欄にする。ステップＳ４４７及びＳ４４９の後、タスク完了取消処理手順を終了する。

（遅延認識処理手順）
図２２は、遅延認識処理手順のフローチャートである。遅延認識処理手順は、所定の周期で自動的に繰り返し実行される（例えば、夜間のバッチ処理）。
ステップＳ４６１において、プロジェクト管理装置１のタスク進捗管理部２４は、タスク情報３１（図３）から遅延しているタスクを抽出する。具体的には、タスク進捗管理部２４は、タスク情報３１から、期日が現在日の前日以前であり、かつ、完了フラグ欄１１１が空欄であるレコードを取得する。

ステップＳ４６２において、タスク進捗管理部２４は、遅延情報３７（図９）を更新する。具体的には、タスク進捗管理部２４は、遅延情報３７の新たなレコードを作成し、新たなレコードのタスクコード欄１９１〜期日欄１９７を埋める。タスク進捗管理部２４は、ステップＳ４６１において取得したレコードから、これらの欄を埋めるのに必要なデータを取得する。他の欄は空欄としておく。その後、遅延認識処理手順を終了する。

（アラーム表示処理手順）
図２３は、アラーム表示処理手順のフローチャートである。タスクの割当が終了し、担当者はタスクを実施している。いま、担当者“日立一郎”が担当者端末装置３を起動し、管理者“日立三郎”が管理者端末装置２を起動したとする。この起動を契機として以下の処理が開始される。
ステップＳ４８１において、プロジェクト管理装置１のタスク進捗管理部２４は、遅延情報３７（図９）から未完了のタスクを抽出する。具体的には、第１に、タスク進捗管理部２４は、遅延情報３７から、担当者名欄１９４に“日立一郎”が記憶されており、かつ、完了フラグ欄２０１が空欄であるレコード（担当者遅延レコード）を取得する。
第２に、タスク進捗管理部２４は、遅延情報３７から、管理者名欄１９６に“日立三郎”が記憶されており、かつ、完了フラグ欄２０１が空欄であるレコード（管理者遅延レコード）を取得する。

ステップＳ４８２において、タスク進捗管理部２４は、管理者に管理者警告画面７６（図２８（ｂ））を表示する。具体的には、タスク進捗管理部２４は、管理者端末装置２の出力装置に管理者警告画面７６を表示する。このとき、タスク進捗管理部２４は、出力装置（スピーカ）を介して、管理者に注意を促すメッセージを音声出力してもよい。タスク進捗管理部２４は、遅延タスク欄７７の遅延タスク名欄、担当者名欄、期日欄及び遅延日数欄に、管理者遅延レコードの、タスク名、担当者名、期日、遅延日数（現在日と期日との差）を表示する。原因欄、対策欄及びリカバリ期日欄は空欄にしておく。なお、遅延タスク欄７７に、日立一郎以外の担当者についてのレコード（行）が表示される場合もある。管理者が遅延タスク欄７７の遅延タスク名を選択した状態で影響範囲表示ボタン７８を押下すると、タスク進捗管理部２４は、出力装置に影響範囲調査結果画面８３（図２９（ａ））を表示する。

ステップＳ４８３において、タスク進捗管理部２４は、担当者に担当者警告画面７９（図２８（ｃ））を表示し、原因等の入力を促す。具体的には、第１に、タスク進捗管理部２４は、担当者端末装置３の出力装置に担当者警告画面７９を表示する。このとき、タスク進捗管理部２４は、担当者名欄８０ａ、タスク名欄８０ｂ、本来の期限欄８０ｃ及び遅延日数欄８０ｄに、担当者遅延レコードの、担当者名、タスク名、期日、遅延日数を表示する。タスク進捗管理部２４は、出力装置（スピーカ）を介して、担当者に注意を促すメッセージ、並びに、遅延の原因、対策及びリカバリ期日の入力を促すメッセージを音声出力してもよい。
第２に、タスク進捗管理部２４は、担当者が、遅延の原因欄８１ａ、遅延の対策欄８１ｂ及びリカバリ期日８１ｃのうちの少なくとも１箇所にデータを入力し、更新ボタン８２を押下するのを受け付ける。

ステップＳ４８４において、タスク進捗管理部２４は、原因等の入力を受け付けたか否かを判断する。具体的には、タスク進捗管理部２４は、ステップＳ４８３の“第２”において入力を受け付けた場合（ステップＳ４８４“Ｙｅｓ”）、ステップＳ４８５に進み、それ以外の場合（ステップＳ４８４“Ｎｏ”）、アラーム表示処理手順を終了する。
ステップＳ４８５において、タスク進捗管理部２４は、遅延情報３７（図９）を更新する。具体的には、タスク進捗管理部２４は、遅延情報３７の担当者名が日立一郎であるレコードの原因欄１９９、対策欄２００及びリカバリ期日欄１９８に、ステップＳ４８３の“第２”において受け付けたデータを記憶する。

ステップＳ４８６において、タスク進捗管理部２４は、管理者に管理者警告画面７６を再度表示する。具体的には、タスク進捗管理部２４は、管理者端末装置２の出力装置に管理者警告画面７６を再度表示する。このとき、タスク進捗管理部２４は、遅延タスク欄７７の原因欄、対策欄及びリカバリ期日欄に、ステップＳ４８３の“第２”において受け付けたデータを表示する。その後、アラーム表示処理手順を終了する。

（タスクマップ）
タスク進捗管理部２４は、管理者が任意の時点で“タスクマップ表示要求”を入力するのを受け付けると、タスクマップ画面８４（図２９（ｂ））を管理者端末装置２の出力装置に表示する。このとき、タスク進捗管理部２４は、タスク情報３１（図３）を参照し、すべてのタスクを任意の区分に分ける。任意の区分とは、例えば“未着手”、“着手中”、“未着手かつ担当者未割当”、“完了済”、“遅延見込”及び“遅延”である。そして、タスク進捗管理部２４は、前提後続関係の矢印を付し、かつ、区分ごとにタスクの表示態様（例えば色）を変化させたうえですべてのタスクグループを表示する。タスク進捗管理部２４は、タスクに関連付けて、タスクの名称及び工数を表示してもよい。

（割当パタン）
図３０に沿って、割当パタン８５を説明する。いま、工数が“６”であるタスクに対して担当者を割当てることを考える。割当パタン“１”のように、１日に１人の担当者を割当てることを前提にすれば、タスクを完了するのに必要な日数は“６”である。１日に割当てる担当者の数が増えるにつれ、割当パタン“２”、“３”及び“４”のようにタスクを完了するのに必要な日数は減少する。さらに、１日に割当てる担当者の数が最大“３”であっても、割当パタン“３”、“５”及び“６”のバリエーションが存在する。
ステップＳ３２３（図１５）の“第１”において、計画策定部２１は、管理者が任意の割当パタンを選択するのを受け付け、受け付けた割当パタンに基づいてタスクグループの最短日数を算出してもよい。ステップＳ３４７（図１６）の“第１”において、タスク自動割当部２２は、管理者が任意の割当パタンを選択するのを受け付け、受け付けた割当パタンに基づいてユーザをタスクに割当ててもよい。

（本実施形態の効果）
本実施形態のプロジェクト管理装置の効果は以下の通りである。
（１）計画策定、要員の割当及びタスクの進捗管理を総合的に支援することができる。
（２）計画期間内に完了され得る（得ない）タスクグループを知ることができる。
（３）要員からタスク遅延の原因等を受け付けることができる。
（４）要員が端末装置を起動する都度、タスクの遅延を知ることができる。
（５）要員は、どのタスクがどの程度遅延しているかを具体的に知ることができる。
（６）要員を割当てるべきタスクを手動で受け付けることができる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

１ プロジェクト管理装置
２ 管理者端末装置
３ 担当者端末装置
４ ネットワーク
１１ 中央制御装置
１２ 入力装置
１３ 出力装置
１４ 主記憶装置
１５ 補助記憶装置
１６ 通信装置
２１ 計画策定部
２２ タスク自動割当部
２３ タスク手動割当部
２４ タスク進捗管理部
３１ タスク情報
３２ タスク紐付情報
３３ スキル領域情報
３４ ユーザ情報
３５ ユーザ工数情報
３６ ユーザ空工数情報
３７ 遅延情報
３８ タスクグループ情報
３９ スケジュール案情報

Claims (8)

1. １又は複数のタスクを含むタスクグループが連続的に実行されるべき期間である計画期間と、前記タスクごとの工数と、前記タスクごとのレベルとを受け付け、
   前記計画期間内に完了され得る前記タスクグループを特定し、
   前記特定したタスクグループが実施されるために必要な前記工数及び前記レベルを前記タスクごとに出力する計画策定部と、
   前記タスクごとの工数、前記タスクごとのレベル、要員のレベル、及び、前記要員の空工数に基づき、前記タスクに対して前記要員を割当てるタスク自動割当部と、
   所定の期日が経過しても前記タスクが完了しない場合に、前記要員に対して警告を出力し、
   前記要員から前記警告に対する回答を受け付けるタスク進捗管理部と、
   を備えることを特徴とするプロジェクト管理装置。
2. 前記計画策定部は、
   前記計画期間内に完了され得る前記タスクグループを出力し、
   前記計画期間内に完了され得ない前記タスクグループを出力すること、
   を特徴とする請求項１に記載のプロジェクト管理装置。
3. 前記回答は、
   前記タスクが完了しない原因、前記タスクを完了するための対策、及び、前記対策を講じた後に前記タスクが完了する予定の期日のうちの少なくとも１つを含むこと、
   を特徴とする請求項２に記載のプロジェクト管理装置。
4. 前記タスク進捗管理部は、
   前記要員が自身の端末装置を起動することを契機として、前記警告を前記端末装置に出力すること、
   を特徴とする請求項３に記載のプロジェクト管理装置。
5. 前記タスク進捗管理部は、
   前記警告とともに、前記タスクの名称、前記要員の氏名、前記所定の期日、及び、前記所定の期日から現在日までの経過日数のうち少なくとも１つを出力すること、
   を特徴とする請求項４に記載のプロジェクト管理装置。
6. 前記要員が未だ割当てられていないタスクを抽出し、
   前記抽出したタスクから、前記要員を割当てるべきタスクの選択を受け付け、
   前記選択を受け付けたタスクに対して割当られ得る前記要員の候補を抽出するタスク手動割当部を備えること、
   を特徴とする請求項１乃至請求項５のいずれか１項に記載のプロジェクト管理装置。
7. プロジェクト管理装置の計画策定部は、
   １又は複数のタスクを含むタスクグループが連続的に実行されるべき期間である計画期間と、前記タスクごとの工数と、前記タスクごとのレベルとを受け付け、
   前記計画期間内に完了され得る前記タスクグループを特定し、
   前記特定したタスクグループが実施されるために必要な前記工数及び前記レベルを前記タスクごとに出力し、
   前記プロジェクト管理装置のタスク自動割当部は、
   前記タスクごとの工数、前記タスクごとのレベル、要員のレベル、及び、前記要員の空工数に基づき、前記タスクに対して前記要員を割当て、
   前記プロジェクト管理装置のタスク進捗管理部は、
   所定の期日が経過しても前記タスクが完了しない場合に、前記要員に対して警告を出力し、
   前記要員から前記警告に対する回答を受け付けること、
   を特徴とするプロジェクト管理装置のプロジェクト管理方法。
8. プロジェクト管理装置の計画策定部に対し、
   １又は複数のタスクを含むタスクグループが連続的に実行されるべき期間である計画期間と、前記タスクごとの工数と、前記タスクごとのレベルとを受け付け、
   前記計画期間内に完了され得る前記タスクグループを特定し、
   前記特定したタスクグループが実施されるために必要な前記工数及び前記レベルを前記タスクごとに出力する処理を実行させ、
   前記プロジェクト管理装置のタスク自動割当部に対し、
   前記タスクごとの工数、前記タスクごとのレベル、要員のレベル、及び、前記要員の空工数に基づき、前記タスクに対して前記要員を割当てる処理を実行させ、
   前記プロジェクト管理装置のタスク進捗管理部に対し、
   所定の期日が経過しても前記タスクが完了しない場合に、前記要員に対して警告を出力し、
   前記要員から前記警告に対する回答を受け付ける処理を実行させること、
   を特徴とするプロジェクト管理装置を機能させるためのプロジェクト管理プログラム。

Images