JP6201459B2 - プロジェクトのリスケジュール方法及びプログラム - Google Patents

Description

本発明は、プロジェクトのリスケジュールに関する。

従来より、システムを用いて、情報処理に関する開発プロジェクトをスケジュールすることが行われている。開発の依頼者である顧客の都合等による開発要件の追加、作業遅延などにより、初期にスケジュールしたプロジェクトが、予定通りに進捗するとは限らない。

スケジュールの見直しに関して、プロジェクトの納期とプロジェクトの完了予測日の差から遅延量を算出し、遅延が予測される場合は、作業工程の優先度を変更したり、他プロジェクトの納期等を遵守できるように計画を自動的に変更する技術、同一工程について過去実績期間と現在設定期間とを比べ、実績期間が短ければ設定期間を短縮する技術等が提案されている。

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

開発するプロジェクトは、複数の作業で構成され、例えば、標準ＷＢＳ（Work Breakdown structure：作業分割構成）に基づいて各プロジェクトについて複数の作業が設定される。設定された作業は全て実施すべき作業であり、これを省略することは品質の低下につながる。

プロジェクトの納期（システム稼働日）までの期間において、未完了の作業が存在する場合には、各プロジェクトを管理するＰＭ（プロジェクトマネージャ）は、未完了の作業のうち、システム稼働後の作業としてリスケジュール可能な不急の作業を正確に見極めて、納期前後のスケジュールを見直すことが必要な場合がる。

不急の作業とは、本来実施する必要があるが、幾つかの条件によってはシステム稼働後に実施しても問題のない作業である。不急の作業の見極めは難しく、経験の少ないＰＭには負担となっている。

上述した技術では、プロジェクトの納期までの作業工程の調整を行うものであり、不急の作業を見極めることができないため、納期直前のスケジュール調整を行うＰＭの負担を軽減できない。

１つの側面において、本発明の目的は、プロジェクトにおいて未完了の作業をリスケジュールすることである。

本実施例の一態様によれば、コンピュータによって実行される複数の作業を有するプロジェクトのリスケジュール方法であって、前記作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、前記抽出された未完了の作業毎に、過去に該作業をリスケジュールしたプロジェクトマネージャに対して、リスケジュールした割合と該プロジェクトマネージャの熟練度とを積和した値を、プロジェクトマネージャの総数で割ることによって、前記プロジェクトの納期後に作業可能な程度を示す不急度を算出し、前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、前記リスケジュール案を表示装置に表示させる。

また、上記課題を解決するための手段として、上記手順をコンピュータに実行させるリスケジュールプログラム、そのリスケジュールプログラムを記録した記録媒体、及び上記プロジェクトのリスケジュール方法を行うプロジェクト管理装置とすることもできる。

本実施例の一態様によれば、プロジェクトにおいて未完了の作業をリスケジュールすることができる。

プロジェクト管理装置のハードウェア構成を示す図である。 プロジェクト管理装置の機能構成例を示す図である。 不急度とリスケジュールとの関係を示す図である。 ＤＢの理論構造例を示す図である。 ユーザマスタのデータ構成例を示す図である。 役割マップ情報のデータ構成例を示す図である。 プロジェクト基本情報のデータ構成例を示す図である。 プロジェクト実績情報のデータ構成例を示す図である。 担当ユーザリンク情報のデータ構成例を示す図である。 作業基本情報のデータ構成例を示す図である。 作業実績情報のデータ構成例を示す図である。 マスタスケジュールの例を示す図である。 リスケジュール処理を説明するためのフローチャート図（その１）である。 リスケジュール処理を説明するためのフローチャート図（その２）である。 リスケジュール処理を説明するためのフローチャート図（その３）である。 リスケジュール処理を説明するためのフローチャート図（その４）である。 リスケジュール案を示す図である。 現在の不急度一覧表を示す図である。 １年後の不急度一覧表を示す図である。

以下、本発明の実施の形態を図面に基づいて説明する。本実施の形態におけるプロジェクト管理装置は、図１に示すようなハードウェア構成を有する。図１は、プロジェクト管理装置のハードウェア構成を示す図である。図１において、プロジェクト管理装置１００は、コンピュータによって制御される端末であって、ＣＰＵ（Central Processing Unit）１１と、主記憶装置１２と、補助記憶装置１３と、入力装置１４と、表示装置１５と、通信Ｉ／Ｆ（インターフェース）１７と、ドライブ装置１８とを有し、バスＢに接続される。

ＣＰＵ１１は、主記憶装置１２に格納されたプログラムに従ってプロジェクト管理装置１００を制御する。主記憶装置１２には、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１にて実行されるプログラム、ＣＰＵ１１での処理に必要なデータ、ＣＰＵ１１での処理にて得られたデータ等を格納する。また、主記憶装置１２の一部の領域が、ＣＰＵ１１での処理に利用されるワークエリアとして割り付けられている。

補助記憶装置１３には、ハードディスクドライブが用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１３に格納されているプログラムの一部が主記憶装置１２にロードされ、ＣＰＵ１１に実行されることによって、各種処理が実現される。記憶部１３０は、主記憶装置１２及び／又は補助記憶装置１３を有する。

入力装置１４は、マウス、キーボード等を有し、ユーザがプロジェクト管理装置１００による処理に必要な各種情報を入力するために用いられる。表示装置１５は、ＣＰＵ１１の制御のもとに必要な各種情報を表示する。通信Ｉ／Ｆ１７は、例えばインターネット、ＬＡＮ（Local Area Network）等に接続し、外部装置との間の通信制御をするための装置である。通信Ｉ／Ｆ１７による通信は無線又は有線に限定されるものではない。
プロジェクト管理装置１００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９によってプロジェクト管理装置１００に提供される。

ドライブ装置１８は、ドライブ装置１８にセットされた記憶媒体１９（例えば、ＣＤ−ＲＯＭ等）とプロジェクト管理装置１００とのインターフェースを行う。

また、記憶媒体１９に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体１９に格納されたプログラムは、ドライブ装置１８を介してプロジェクト管理装置１００にインストールされる。インストールされたプログラムは、プロジェクト管理装置１００により実行可能となる。

尚、プログラムを格納する媒体としてＣＤ−ＲＯＭに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。

本実施の形態におけるプロジェクト管理装置１００は、センタ型アウトソーシングサービスとしてプロジェクトを管理するシステムであり、例えば、標準ＷＢＳ（Work Breakdown structure：作業分割構成）の適用により、作業進捗の管理を支援する。

プロジェクト管理装置１００では、プロジェクトが遅延した場合に、不急の作業を特定しリスケジュールすることを可能とする。プロジェクトの不急の作業を、過去の作業実績から判断し、その作業を納期後（例えば、システム稼働後）にリスケジュールすることを可能とする。

不急の作業例として、本来ならばシステム稼働までにシステムバックアップの自動化ツールを作成して動かす必要があるが、どうしてもシステム稼働日までに作成が間に合わない。その際、自動化ツールが完成するまでの間、バックアップは手動で実施するといった対応が考えられる。そしてシステム稼働後、余裕ができた段階で自動化ツールを作成する。

図２は、プロジェクト管理装置の機能構成例を示す図である。図２において、プロジェクト管理装置１００は、データベース（ＤＢ）３１と、スケジュール部４０と、リスケジュール部５０とを有する。

スケジュール部４０は、プロジェクトを構成する複数の作業のスケジュールを行う処理部であり、マスタスケジュール作成部４１と、担当者割り当て部４２と、実績管理部４３と、マスタスケジュール表示部４４等を有する。

マスタスケジュール作成部４１は、プロジェクト基本情報３４に新たなプロジェクトを登録し、作業基本情報３７に、新プロジェクトを構成する各作業を登録する等によってマスタスケジュールを作成する。マスタスケジュールは、プロジェクトの納期までの各作業のスケジュールを示す。

担当者割り当て部４２は、プロジェクト毎、作業毎に担当者を割り当てる。担当者割り当て部４２は、担当ユーザリンク情報３６によって、プロジェクト及び作業と担当者とを関連付ける。また、担当者割り当て部４２は、役割マップ情報２３を用いて、割り当てた担当ユーザと、割り当てられたプロジェクトでの役割とを対応付ける。

実績管理部４３は、各プロジェクト、各作業の実績を管理する。実績管理部４３は、プロジェクト実績情報３５を用いてプロジェクトの実績を管理し、作業実績情報３８を用いて作業の実績を管理する。

マスタスケジュール表示部４４は、ＤＢ３１を用いて、プロジェクトマネージャＰＭ２によって指定されたプロジェクトのマスタスケジュールを表示装置１５に表示する。

リスケジュール部５０は、プロジェクトマネージャＰＭ２のリスケジュール案作成指示に応じて、プロジェクトのリスケジュールを行う処理部であり、不急度判定部５１と、リスケジュール案作成部５２とを有する。

リスケジュール部５０における処理において、対象プロジェクト情報６１、対象作業情報６２、不急度一覧表６３が内部データ６０として記憶部１３０に保持される。内部データ６０は、リスケジュール部５０における処理中に有効なデータであり、処理の終了によって初期化される。

対象プロジェクト情報６１は、リスケジュール対象のプロジェクトに関する情報であり、プロジェクトマネージャＰＭ２によるスケジュールの表示要求等によって指定されたプロジェクトに関する。

対象作業情報６２は、指定されたプロジェクトを構成する１以上の作業に関する情報であり、各作業に対応付けて少なくとも作業の未完了／完了のステータスを管理するテーブルである。

不急度一覧表６３は、対象作業情報６２において未完了の作業に関して、各作業に対応付けて少なくとも不急度を示すテーブルである。不急度は、プロジェクトの納期後に作業可能な程度を示す。不急度がゼロ又はゼロに近い程、プロジェクトの納期後の作業は不可であることを示し、納期後へのリスケジュールできないことを意味する。また、不急度が高い程、プロジェクトの納期後に作業可能であることを示し、納期後へのリスケジュールが可能であることを示す。

不急度判定部５１は、リスケジュール案作成指示で指定される、スケジュール部４０によってスケジュールされたプロジェクトにおいて、各作業の不急度を判定する。不急度判定部５１は、ＤＢ３１の既に完了している過去の作業実績情報３８等を参照して、開発中のプロジェクトの未完了の作業の不急度を判定する。不急度一覧表６３が記憶部１３０に作成される。

不急度判定部５１では、過去の同じＷＢＳを利用したプロジェクトでシステム稼働後にリスケジュールされた作業の統計をとり、全くリスケジュールされていない作業を不急度低、よくリスケジュールされている作業を不急度高と判断する。この際、リスケジュールされたプロジェクトマネージャＰＭ２の熟練度も勘案する。熟練度の算出方法については、後述される。

図３は、不急度とリスケジュールとの関係を示す図である。図３中、縦軸に不急度を示し、横軸に作業を示す。不急度がゼロの場合、リスケジュールできない不可作業３ａを示す。また、不急度が高い程、リスケジュール可能な作業であり、候補作業３ｂとして示している。図３の例では、作業Ｃ及び作業Ｇはリスケジュールできない不可タスク３ａであり、タスク作業Ｅ、作業Ｄ、作業Ｆ、及び作業Ｈは、リスケジュール可能な候補作業３ｂであることを示している。

図２にて、リスケジュール案作成部５２は、不急度の高い作業を対象に、作業のスケジュールを見直して、プロジェクトのリスケジュール案を作成し表示装置１５に表示する。図３の例では、作業Ｃ及び作業Ｇはリスケジュールされることなく現状通りのスケジュールとなる。

ＰＭ２によりリスケジュールが確認され、承認された場合、リスケジュール案作成部５２によって作成されたリスケジュール案に従って、ＤＢ３１内の作業実績情報３８が更新される。ＤＢ３１内の作業実績情報３８の更新によって、不急度の高い作業が、プロジェクトの納期後にスケジュールされる。

ＤＢ３１には、ユーザマスタ３２、役割マップ情報３３、プロジェクト基本情報３４、プロジェクト実績情報３５、担当ユーザリンク情報３６、作業基本情報３７、作業実績情報３８等が格納される。各データ例については後述される。

また、図２を参照して、プロジェクト管理装置１００を利用した全体の流れについて説明する。プロジェクトマネージャＰＭ２が、プロジェクト遅延によるリスケジュール案作成指示を行うと（ｉ）、リスケジュール部５０は、不急度判定部５１によって、ＤＢ３１を利用して、指定されたプロジェクトの各作業の不急度を判定する（ｉｉ）。

不急度判定部５１によって各作業の不急度の判定後、リスケジュール案作成部５２が、プロジェクトにおいて、不急度に基づいて指定されたプロジェクトの納期後に行える作業を抽出し、システム実施開始後（プロジェクトの納期後）に抽出した作業を行うようにリスケジュール案を作成して表示装置１５に表示する（ｉｉｉ）。

プロジェクトマネージャＰＭ２は、表示されたリスケジュール案を確認して、リスケジュールの確定又はキャンセルを行う（ｉｖ）。確定の場合には、ＤＢ３１にリスケジュール案が反映される。具体的には、後述される作業実績情報３８の構成例において、リスケジュール対象となった作業の予定開始日及び予定終了日が変更される。一方、キャンセルの場合、ＤＢ３１にリスケジュール案の反映は抑止され、リスケジュール対象となった作業の予定開始日及び予定終了日は変更されない。

図４は、ＤＢの理論構造例を示す図である。図４では、ＤＢ３０における情報間の関連を示している。図４において、ユーザマスタ３２は、役割マップ情報３３と関連付けられ、また、役割マップ情報３３は、プロジェクト基本情報３４と関連付けられる。役割マップ情報３３は、プロジェクト毎の担当ユーザと、担当ユーザの役割とを管理する。

プロジェクト基本情報３４とプロジェクト実績情報３５とが関連付けられる。プロジェクト実績情報３５は、関連付けられた各プロジェクトの実績情報を管理する。

また、プロジェクト基本情報３４と作業基本情報３７とが関連付けられる。作業基本情報３７は、プロジェクトを構成する１以上の作業が管理され、また、プロジェクト内の作業間の従属関係を管理する。

プロジェクト基本情報３４と、作業基本情報３７とは、夫々、担当ユーザリンク情報３に関連付けられる。担当ユーザリンク情報３６は、ユーザが属する１以上のプロジェクト又は１以上の作業を管理する。

次に、ＤＢ３１に格納され管理される情報のデータ構成例について図５から図１１で説明する。図５は、ユーザマスタのデータ構成例を示す図である。図５において、ユーザマスタ３２は、各ユーザの情報を管理するテーブルであり、ユーザＩＤ、ユーザタイプ、ユーザ名、パスワード、部署コード、役職、Ｅｍａｉｌアドレス、電話番号等の項目を有する。

ユーザＩＤは、ユーザを一意に識別するＩＤである。ユーザタイプは、ユーザの場合「０」を示し、グループの場合「１」を示し、仮担当の場合「２」を示す。ユーザ名は、ユーザの名前を示す。

パスワードは、ユーザのパスワードを示す。部署コードは、ユーザが所属する部署を特定するコードを示す。役職は、部署でのユーザの役職を示す。

Ｅｍａｉｌアドレスは、ユーザの電子メールアドレスを示す。電話番号は、ユーザの電話番号を示す。

各項目に設定されるデータ例として、ユーザＩＤ「fj******」のユーザタイプは「０」（ユーザ）であり、ユーザ名は「富士 太郎」である。このユーザのパスワードは「abcdefg」であり、部署コード「0a387311a908012c38af41330000****」で特定される部署において、ユーザの役職は「８（担当者）」であることが示されている。また、ユーザのＥｍａｉｌアドレスは「******＠**.**.**」であり、電話番号は「XXXX-XXXX」である。

図６は、役割マップ情報のデータ構成例を示す図である。図６において、役割マップ情報３３は、プロジェクトにおいけるユーザの役割を対応付けたテーブルであり、プロジェクト論理ＩＤ、仮担当（役割）ユーザＩＤ、担当ユーザＩＤ、表示順、登録日等の項目を有する。

プロジェクト論理ＩＤは、プロジェクト基本情報３４に登録されたプロジェクトを特定するＩＤを示す。仮担当（役割）ユーザＩＤは、プロジェクトにおける担当ユーザの役割を識別する情報を示す。担当ユーザＩＤは、プロジェクトの担当となったユーザのＩＤを示す。表示順は、プロジェクト内における担当ユーザの表示順を示す。登録日は、プロジェクトに対して担当ユーザを登録した日付を示す。

各項目に設定されるデータ例として、プロジェクト論理ＩＤ「0a38743977c3011374da3aee0000****」で特定されるプロジェクトにおいて、仮担当（役割）ユーザＩＤが「pjmanager」である担当ユーザのＩＤは「fj******」であり、表示順「9999」で表示され、これら情報の登録日は「2012/9/1」であることが示されている。

図７は、プロジェクト基本情報のデータ構成例を示す図である。図７において、プロジェクト基本情報３４は、登録されたプロジェクト毎の情報を管理するテーブルであり、プロジェクト論理ＩＤ、プロジェクトタイプ、プロジェクト名、作成者のユーザＩＤ、新規作成日、最終更新者のユーザＩＤ、最終更新日、プロジェクト責任者のユーザＩＤ、テンプレートＩＤ、表示順等の項目を有する。

プロジェクト論理ＩＤは、プロジェクト基本情報３４に登録されたプロジェクトを特定する論理ＩＤを示す。プロジェクトタイプは、運用プロジェクトの場合は「０」を示し、標準フローの場合は「１」を示し、逐次プロジェクトの場合は「２」を示し、ひな型の場合は「３」を示す。プロジェクト名は、プロジェクトのプロジェクト名（タイトル）を示す。

作成者のユーザＩＤは、プロジェクトの基本情報を新規作成したユーザのＩＤを示す。新規作成日は、プロジェクトを新規に作成した日付を示す。最終更新者のユーザＩＤは、このプロジェクトの基本情報を最後に更新したユーザのＩＤを示す。最終更新日は、最後に更新した日付を示す。

プロジェクト責任者のユーザＩＤは、プロジェクトマネージャＰＭ２のユーザＩＤを示す。子作業の数は、プロジェクト配下の作業数を示す。テンプレートＩＤは、標準ＷＢＳに従った雛型プロジェクトのＩＤを示す。表示順は、プロジェクトの表示順を示す。

各項目に設定されるデータ例として、プロジェクト論理ＩＤ「0a38743977c3011374da3aee0000****」で特定されるプロジェクトにおいて、プロジェクトタイプは「０」（運用プロジェクト）であり、プロジェクト名は「××様／△△プロジェクト」である。作成者のユーザＩＤは「fj******」であり、新規作成日は「2012/12/1」である。最終更新者のユーザＩＤは「fj******」であり、最終更新日は「2012/2/1」である。また、プロジェクト責任者のユーザＩＤは「fj******」である。

子作業の数は「５０」個であり、テンプレートＩＤは「1b49854088d4022384db4veg1213****」であり、表示順は「１０」である。

図８は、プロジェクト実績情報のデータ構成例を示す図である。図８において、プロジェクト実績情報３５は、各プロジェクトの実績を管理するテーブルであり、プロジェクト論理ＩＤ、計画開始日、実績開始日、計画終了日、実績終了日、システム稼働予定日、システム稼働実績日、進捗率、運用ステータス、進捗ステータス等の項目を有する。

プロジェクト論理ＩＤは、プロジェクト基本情報３４に登録されたプロジェクトを特定するＩＤを示す。

計画開始日は、プロジェクトの計画開始日を示し、実績開始日は、プロジェクトの実際の開始日を示す。計画終了日は、プロジェクトの計画終了日を示し、実績終了日は、プロジェクトの実際の終了日を示す。

システム稼働予定日は、顧客での運用開始の予定日を示す。システム稼働実績日は、顧客において実際に運用された日付を示す。進捗率は、プロジェクトの完成度の割合を示す。

運用ステータスは、運用中の場合は「０」を示し、準備中の場合は「１」を示し、完了の場合は「９」を示す。進捗ステータスは、完了の場合は「０」を示し、未着手の場合は「１」を示し、予定通りの場合は「２」を示し、やや遅れの場合は「３」を示し、見直し要の場合は「４」を示す。

各項目に設定されるデータ例として、プロジェクト論理ＩＤ「0a38743977c3011374da3aee0000****」で特定されるプロジェクトに関して、計画開始日は「2012/12/15」であり、実績開始日は「2012/12/20」である。また、計画終了日は「2013/3/1」であり、実績終了日は「2013/3/2」である。そして、このプロジェクトの顧客におけるシステム稼働予定日は「2013/2/25」であり、システム稼働実績日は「2013/2/26」である。

進捗率は「１００」％であり、運用ステータスは「９」（完了）を示し、このプロジェクトは完了していることを示す。また、進捗ステータスにおいても「０」（完了）を示している。

図９は、担当ユーザリンク情報のデータ構成例を示す図である。図９において、担当ユーザリンク情報３６は、担当ユーザ毎にプロジェクト又は作業との関連を管理するテーブルであり、ユーザＩＤ、リンク元の論理ＩＤ、関連オブジェクトのタイプ、プロジェクト論理ＩＤ、役割、表示順等の項目を有する。

ユーザＩＤは、プロジェクト又は作業のいずれかを担当する担当ユーザのＩＤを示す。リンク元の論理ＩＤは、プロジェクト基本情報３４に登録されているプロジェクト論理ＩＤ又は作業基本情報３７に登録されている作業論理ＩＤを示す。

関連オブジェクトのタイプは、関連付けられたオブジェクトがプロジェクト又は作業のいずれかであることを示す。プロジェクト論理ＩＤは、リンク元が作業の場合にプロジェクト論理ＩＤが示される。

役割は、担当するプロジェクト又は作業におけるユーザの役割を示す。オブジェクトタイプがプロジェクトを示す場合において、修正不可は「０」で示され、修正可は「２」で示される。オブジェクトタイプが作業を示す場合において、写し（予約）は「０」で示され、主担当は「１」で示され、レビュアは「２」で示され、依頼者は「３」で示される。表示順は、このユーザの担当ユーザリンク情報の表示順を示す。

各項目に設定されるデータ例として、ユーザＩＤ「fj******」に関連するリンク元の論理ＩＤは「0a387439d9870105e215ed2e0000****」であり、関連オブジェクトのタイプは「２」（作業）であり、プロジェクト論理ＩＤはリンク元が作業の場合に示され、この例では、「0a38743977c3011374da3aee0000****」である。また、役割は「２」であるため、ユーザＩＤ「fj******」で特定されるユーザは、この作業のレビュアであることが示されている。

図１０は、作業基本情報のデータ構成例を示す図である。図１０において、作業基本情報３７は、登録された作業毎の情報を管理するテーブルであり、作業論理ＩＤ、作業名、表示順、プロジェクト論理ＩＤ、親作業論理ＩＤ、階層レベル、子作業の数、作業の一意キー、リードタイム（標準期間（日））、最終更新者、最終更新日等の項目を有する。

作業論理ＩＤは、作業基本情報３７に登録された作業を特定する論理ＩＤを示す。作業名は、作業の名称（タイトル）を示す。表示順は、作業の表示順を示す。プロジェクト論理ＩＤは、作業のプロジェクト論理ＩＤを示し、関連付けられる。親作業論理ＩＤは、作業の親作業論理ＩＤを示し、関連付けられる。

階層レベルは、プロジェクトにおいて、作業が位置する階層レベルを示す。子作業の数は、作業配下にある子作業の数を示す。作業の一意キーは、作業に一意に与えられたキーを示す。異なる作業論理ＩＤであっても作業の一意キーが同一の場合、作業として同じであることを示す。リードタイムは、作業を完成させるために必要な日数を示す。

最終更新者は、この作業の基本情報を更新したユーザのＩＤを示す。最終更新日は、この作業の基本情報を更新した最終日を示す。

図１１は、作業実績情報のデータ構成例を示す図である。図１１において、作業実績情報３８は、作業毎の実績を管理するテーブルであり、作業論理ＩＤ、進捗状況（％）、ステータス、実績期間（日数）、実績工数（時間）、予定開始日、実績開始日、予定終了日、実績終了日、リスケジュール有無等の項目を有する。

作業論理ＩＤは、作業基本情報３７に登録された作業を特定する論理ＩＤを示す。進捗状況（％）は、作業の進捗度を示す。ステータスは、現在の作業の状態を示し、予定の状態では「０」を示し、着手可の状態では「１」を示し、着手中の状態では「２」を示し、承認中の状態では「３」を示し、差戻しの状態では「４」を示し、完了の状態では「９」を示す。

実績期間（日数）は、実際の作業日数を示す。実績工数（時間）は、実際の工数を時間で示す。予定開始日は、作業の予定開始日を示す。実績開始日は、実際に作業を開始した日付を示す。予定終了日は、作業の予定終了日を示す。実績終了日は、実際に作業を終了した日付を示す。リスケジュール有無は、リスケジュールされたか否かを示すフラグであり、リスケジュール無しの場合は「０」を示し、リスケジュール有りの場合は「１」を示す。

各項目に設定されるデータ例として、作業論理ＩＤ「0a387439d9870105e215ed2e0000****」で特定される作業の進捗状況は「１００」％であり、ステータスは「９」（完了）を示す。実績期間（日数）は「１」日であり、実績工数（時間）は「２」時間である。

予定開始日「2013/1/21」に対して、実績開始日は「2013/1/22」であったことを示し、予定終了日「2013/1/21」に対して、実績終了日は「2013/1/22」であったことを示す。

リスケジュール前の、ＤＢ３１に基づくプロジェクトのマスタスケジュールの例を図１２で説明する。図１２は、マスタスケジュールの例を示す図である。図１２に例示されるマスタスケジュールでは、作業Ａから作業Ｈまでの作業がシステム稼働予定日までにスケジュールされた状態が示されている。図１２中、作業Ａから作業Ｈの作業名の下の（ ）内に完了又は未完了を示しているが、各作業Ａ〜Ｈの完了又は未完了の区別は、文字色等により視認し易い表示で示してもよい。また、各作業名の「−＞」印は、作業の予定開始日又は実績開始日から予定終了日又は実績終了日までの長さを表し、「−＞」印の下にリードタイムを示す日数を示している。

マスタスケジュールを表示装置１５に表示した時点（本日（2012/12/21））、即ち、システム稼働予定日（2012/12/30）の１０日前の時点において、作業Ａ及び作業Ｂは完了しているが、作業Ｃから作業Ｈまでは未完了である。未完了の作業のうち、本日（2012/12/21）の時点までに作業Ｃ、作業Ｄ及び作業Ｅは完了を予定していた作業である。

本実施の形態に係るプロジェクト管理装置１００は、リスケジュール部５０によって、未完了の作業Ｃから作業Ｈのうち、不急度に基づいて１以上の作業をシステム稼働予定日（2012/12/30）にリスケジュールする。以下、作業Ａから作業Ｈを有するプロジェクトをプロジェクト名「プロジェクトα」で特定するものとする。

不急度を判定してリスケジュールするリスケジュール部５０によるリスケジュール処理を図１３から図１６で説明する。

図１３から図１６は、リスケジュール処理を説明するためのフローチャート図である。図１３において、スケジュール部４０は、マスタスケジュール表示部４４によって、プロジェクトマネージャＰＭ２によるマスタスケジュールの表示要求に応じて、要求で指定されるプロジェクトのマスタスケジュールを表示装置１５に表示させる（ステップＳ１１）。

マスタスケジュール表示部４４は、マスタスケジュールの表示要求で指定されるプロジェクト名とシステム稼働予定日と示す対象プロジェクト情報６１を記憶部１３０に記憶する。システム稼働予定日は、マスタスケジュールの表示要求で指定されるプロジェクト名のプロジェクト基本情報３４のプロジェクト論理ＩＤで関連付けられるプロジェクト実績情報３５から取得することができる。

また、マスタスケジュール表示部４４は、プロジェクト論理ＩＤで関連付けられる作業基本情報３７から作業名、リードタイムを取得し、また、作業実績情報３８から各作業の予定開始日、予定終了日、ステータスを取得して、対象作業情報６２を記憶部１３０に記憶する。対象プロジェクト情報６１と対象作業情報６２とに基づいて、図１２に示すマスタスケジュールが表示装置１５に表示される。

そして、マスタスケジュールの表示後、プロジェクトマネージャＰＭ２が、プロジェクトの遅延を確認すると、プロジェクト遅延によりリスケジュール案作成指示を行う。リスケジュール案作成指示は、表示されたマスタスケジュールの画面に構成されるリスケジュールボタンを押下することによって行われる。

マスタスケジュール表示部４４は、表示されたマスタスケジュールの画面に構成されるリスケジュールボタンの押下を検出したか否かを判断する（ステップＳ１２）。リスケジュールボタンの押下ではない場合（ステップＳ１２がＮｏ）、このリスケジュールに係る処理を終了する。リスケジュールボタンの押下を検出した場合（ステップＳ１２がＹｅｓ）、リスケジュール部５０が起動する（ステップＳ１３）。

図１４において、リスケジュール部５０は、対象作業情報６２によって示される全ての作業を対象とし（ステップＳ１４）、対象作業情報６２から順にレコードを処理対象として、対象作業のステータスが未完了を示すか否かを判断する（ステップＳ１５）。対象作業のステータスが未完了を示す場合（ステップＳ１５がＹｅｓ）、未完了の作業について、不急度判定部５１による不急度判定処理を行う（ステップＳ１６）。

各作業の不急度判定は、下記の式によって計算される。作業Ｃを例として示すが、他の各作業について同様に不急度を計算する。

作業Ｃの不急度
＝（
（ＰＭ（１）の作業Ｃのリスケ率（％））×（ＰＭ（１）の熟練度）
＋ ・・・
＋ （ＰＭ（ｎ）の作業Ｃのリスケ率（％））×（ＰＭ（ｎ）の熟練度）
）÷ｎ 式（１）
ここで、ＰＭ（１）からＰＭ（ｎ）は異なるプロジェクトマネージャＰＭ２を示し、ｎは過去に作業Ｃをシステム稼動後にリスケジュールしたことのあるプロジェクトマネージャの総人数を示す。

上記式（１）において、各プロジェクトマネージャＰＭ（ｉ）（ｉ＝１、２、・・・、ｎ）の作業Ｃのリスケ率（リスケジュール率）（％）は、
作業Ｃのリスケ率（％）
＝ （ＰＭ（ｉ）が作業Ｃをリスケジュールしたプロジェクト数）
÷ （ＰＭ（ｉ）がリスケジュールを実施したプロジェクト数）
× １００ 式（２）
によって計算される。

ＰＭ（ｉ）のユーザＩＤを含むプロジェクト基本情報３４からプロジェクト論理ＩＤで関連付けられるプロジェクト実績情報３５の数が、各ＰＭ（ｉ）が担当したプロジェクト数に相当する。プロジェクト実績情報３５毎に、プロジェクト論理ＩＤで関連付けられる作業基本情報３７の作業論理ＩＤを示す作業実績情報３８を取得し、取得した作業実績情報３８でリスケジュール有無の値が「１」（リスケジュール有）を示す場合に、そのプロジェクトにおいてリスケジュールが実施されたと判断する。リスケジュールを実施したと判断したプロジェクト数をカウントする。ＰＭ（ｉ）がリスケジュールを実施したプロジェクト数を得ることができる。

上述したようにＰＭ（ｉ）のユーザＩＤ及びプロジェクト論理ＩＤに基づいて得られたプロジェクト実績情報３５の、プロジェクト論理ＩＤで関連付けられる作業基本情報３７のうち、作業名が所定の作業（例えば、作業Ｃ）と一致する作業基本情報３７に関して、更に、作業論理ＩＤで関連付けられる作業実績情報３８のリスケジュール有無の値「１」である場合に、そのプロジェクトにおいて所定の作業（作業Ｃ）をリスケジュールしたと判断する。よって、所定の作業（例えば、作業Ｃ）をリスケジュールしたプロジェクト数を取得することができる。

リスケ率は、ＰＭ（ｉ）がリスケジュールを実施したプロジェクト数に対する所定の作業（作業Ｃ）をリスケジュールしたプロジェクト数の割合で示される。

また、上記式（１）において、各プロジェクトマネージャＰＭ（ｉ）の熟練度は、
ＰＭ（ｉ）の熟練度
＝ （ＰＭ（ｉ）の過去の成功プロジェクト数）
÷ （ＰＭ（ｉ）の過去の担当プロジェクト数） 式（３）
によって計算される。ここで、成功プロジェクト数とは、稼働日に遅延がなかったプロジェクト数を示す。

上述したようにＰＭ（ｉ）のユーザＩＤ及びプロジェクト論理ＩＤに基づいて得られたプロジェクト実績情報３５のうち、進捗ステータスの値が「０」（完了）を示すプロジェクト実績情報３５の数が、ＰＭ（ｉ）の過去の担当プロジェクト数に相当する。

上述の進捗ステータスの値が「０」（完了）を示すプロジェクト実績情報３５のうち、システム稼働実績日がシステム稼働予定日と一致又はシステム稼働予定日より前の日付を示すプロジェクト実績情報３５の数が、ＰＭ（ｉ）の過去の成功プロジェクト数に相当する。

ＰＭ（ｉ）の熟練度は、ＰＭ（ｉ）の過去の担当プロジェクト数に対するＰＭ（ｉ）の過去の成功プロジェクト数の割合で示される。

対象作業のステータスが完了を示す場合（ステップＳ１５がＮｏ）、プロジェクトの全ての作業のチェックを完了したか否かを判断する（ステップＳ１７）。全ての作業のチェックを完了していない場合（ステップＳ１７がＮｏ）、リスケジュール部５０は、対象作業情報６２の次のレコードを処理対象として、ステップＳ１５へ戻り上述同様の処理を繰り返す。全ての作業のチェックを完了している場合（ステップＳ１７がＹｅｓ）、未完了を示す作業の不急度一覧表６３がリスケジュール処理における内部データ６０として記憶部１３０に保存される（ステップＳ１８）。

不急度一覧表６３は、レコードＮｏ、作業名、リードタイム（日）、予定開始日、予定終了日、不急度、リスケフラグ等の項目を有する。

レコードＮｏは、不急度一覧表６３の各レコードを識別する番号である。作業名は、作業基本情報３７に登録された作業名を示す。リードタイムは、作業に必要な日数を示す。予定開始日は、作業の予定開始日を示す。予定終了日は、作業の予定終了日を示す。

不急度は、不急度判定部５１によって計算された作業の不急度を示す。リスケフラグは、リスケジュール処理においてリスケジュールされない場合に未リスケジュールを示す「０」が設定され、リスケジュール処理においてリスケジュールされた場合にリスケジュール済みを示す「９」が設定される。不急度一覧表６３の作成時には、リスケフラグは、全ての作業で「０」を示す。

図１５にて、リスケジュール部５０のリスケジュール案作成部５２は、システム稼働日までの残日数を求める（ステップＳ１９）。リスケジュール案作成部５２は、プロジェクト実績情報３５を参照して、リスケジュール対象のプロジェクトのシステム稼働予定日を取得する。また、リスケジュール案作成部５２は、現在の日付を取得して、システム稼働予定日と現在の日付との差分を計算する。

そして、リスケジュール案作成部５２は、システム稼働前の作業のリードタイム総和を求める（ステップＳ２０）。リスケジュール案作成部５２は、不急度一覧表６３のリスケフラグが「０」のレコードのリードタイムを全て足して、リードタイム総和を計算する。

リスケジュール案作成部５２は、ステップＳ１９で算出した「システム稼働予定日までの残日数」がステップＳ２０で算出した「システム稼働前の作業のリードタイム総和」以上であるか否かを判断する（ステップＳ２１）。

「システム稼働予定日までの残日数」が「システム稼働前の作業のリードタイム総和」より少ない場合（ステップＳ２１のＮｏ）、リスケジュール案作成部５２は、不急度一覧表６３の中でリスケフラグが「０」かつ不急度が最も高い値のレコードのリスケフラグを「９」に変更する（ステップＳ２１−２）。

そして、リスケジュール案作成部５２は、ステップＳ２０へ戻り、上述した同様の処理を繰り返す。ステップＳ２１の判断条件が満たされた状態を、不急度一覧表６３−２で示す。図１４に示す不急度一覧表６３は、図１５の不急度一覧表６３−２に更新される。

不急度一覧表６３−２では、ステップＳ２０、Ｓ２１、及びＳ２１−２の処理の繰り返しによって、作業Ｆと作業Ｈのレコードのリスケフラグが「９」に設定されたことを示している。

「システム稼働予定日までの残日数」が「システム稼働前の作業のリードタイム総和」以上である場合（ステップＳ２１のＹｅｓ）、リスケジュール案作成部５２は、リスケジュール案を作成する（ステップＳ２２）。リスケジュール案作成部５２は、リスケフラグが更新された不急度一覧表６３−２において、リスケフラグが「９」のレコードについて、システム稼働予定日「2012/12/30」の後に予定開始日及び予定終了日を順に設定する。

図１４に示す不急度一覧表６３−２のうち、リスケジュール案作成部５２は、作業Ｆの予定開始日「2012/12/21」及び予定終了日「2012/12/24」が、「2012/12/31」及び「2012/1/3」に変更する。また、作業Ｆの予定開始日「2012/12/28」及び予定終了日「2012/12/30」が、「2013/1/4」及び「2013/1/6」に変更する。図１５の不急度一覧表６３−２が、図１５の不急度一覧表６３−４に更新される。

リスケジュール案作成部５２は、不急度一覧表６３−４に基づいてリスケジュール案を表示装置１５に表示する（ステップＳ２３）。後述される図１７に示すようなリスケジュール案が表示装置１５に表示される。

このように、残された作業期間に対応して、不急度の高い作業から自動的にシステム稼働後の工程にスケジュールし直す。納期までの作業期間と残り作業のリードタイムの総和とを比較して、納期までの作業期間が短い場合、不急度の高い作業から順番にシステム稼働後の工程にリスケジュールする。

プロジェクトマネージャＰＭ２は、表示されたリスケジュール案を確認して、問題ないと判断した場合、リスケジュール案をＤＢ３１に反映させるために、画面に用意されている「ＯＫ」ボタンを押下する。一方、プロジェクトマネージャＰＭ２は、リスケジュール案を承認できない場合は、画面に用意されている「キャンセル」ボタンを押下する。

図１６にて、リスケジュール案作成部５２は、リスケジュール案を表示した画面において、「ＯＫ」ボタンの押下を検出したか否かを判断する（ステップＳ２４）。「キャンセル」ボタンの押下を検出した場合（ステップＳ２４のＮｏ）、リスケジュール案作成部５２は、リスケジュール案を破棄して（ステップＳ２５）、このリスケジュール処理を終了する。リスケジュール案作成部５２は、ＤＢ３１に反映されずに不急度一覧表６３−４が破棄される。ＤＢ３１から得られる不急度は、不急度一覧表６３の状態を維持する。

一方、「ＯＫ」ボタンの押下を検出した場合（ステップＳ２４のＹｅｓ）、リスケジュール案作成部５２は、リスケジュール案をＤＢ３１に反映して（ステップＳ２６）このリスケジュール処理を終了する。リスケジュール案作成部５２は、不急度一覧表６３−４を用いて、ＤＢ３１を反映する。具体的には、不急度一覧表６３−４のリスケフラグが「９」を示す作業Ｆ及び作業Ｈの予定開始日及び予定終了日で、作業実績情報３８の予定開始日及び予定終了日を更新する。

不急度一覧表６３−４に基づいて作成されたリスケジュール案を図１７に示す。図１７は、リスケジュール案を示す図である。図１７に示すリスケジュール案において、未完了の作業Ｃから作業Ｈのうち、作業Ｆと作業Ｈとがシステム稼働予定日「2012/12/30」の後にスケジュールされる案が示されている。

プロジェクトマネージャＰＭ２は、表示装置１５に表示されたリスケジュール案を確認して、リスケジュール案を適用するか否かを判断することができる。

上述したように、リスケジュール案は、作業の不急度に基づいて自動的に行われる。また、不急度の計算では、過去のプロジェクトマネージャのリスケジュール率及び熟練度が考慮されることにより精度よく不急度を算出することができる。従って、リスケジュール案では、現在のプロジェクトマネージャＰＭ２のプロジェクトの経験に寄らず、精度よくシステム稼働予定日後にリスケジュール可能な作業を抽出でき、また、適切にリスケジュールすることができる。

また、不急度の計算では、累積された過去のプロジェクトマネージャのリスケジュール率及び熟練度が考慮されるため、同じ作業であっても、累積された情報に応じてリスケジュールの仕方が変動する。例えば、リスケジュールする時期が異なると提示されるリスケジュール案が異なる。

過去のプロジェクトマネージャのリスケジュール率及び熟練度の累積された情報に応じてリスケジュール案が変動する例について、図１８及び図１９で説明する。図１８及び図１９では、同じプロジェクトαを現在（「2012/12/21」）と一年後（「2013/12/21」）とでリスケジュールを行った場合の例を示す。

図１８は、現在の不急度一覧表を示す図である。図１８に示す不急度一覧表６３−２において、作業Ｃの不急度は「０」であり、作業Ｄの不急度は「６０」であり、作業Ｅの不急度は「３０」であり、作業Ｆの不急度は「７０」であり、作業Ｇの不急度は「３０」であり、作業Ｈの不急度は「９０」である。

不急度一覧表６３−２のリスケフラグが「９」を示す作業Ｆ及び作業Ｈがリスケジュールされる。

作業Ｆの予定開始日「2012/12/21」及び予定終了日「2012/12/24」がリスケジュールされて、不急度一覧表６３−４に示すように、予定開始日「2012/12/21」及び予定終了日「2012/12/28」となる。

作業Ｈの予定開始日「2012/12/28」及び予定終了日「2012/12/30」がリスケジュールされて、不急度一覧表６３−４に示すように、予定開始日「2012/12/31」及び予定終了日「2013/1/3」となる。

プロジェクトにおいては、標準の運用契約の内容が変更されることで作業Ｇがシステム稼働日以降に実施しても大きな問題にならなくなる場合、一年後には作業Ｇが多くのプロジェクトでリスケジュールされた実績が積みあがり、不急度が高くなる可能性ある。一方で、作業Ｇがリスケジュールされる分、他の作業がリスケジュールされないようになり、相対的に他の作業の不急度が低くなる可能性がある。

図１９は、１年後の不急度一覧表を示す図である。図１９に示す不急度一覧表６３−６において、作業Ｃの不急度は「０」であり、作業Ｄの不急度は「４０」であり、作業Ｅの不急度は「１５」であり、作業Ｆの不急度は「７０」であり、作業Ｇの不急度は「７５」であり、作業Ｈの不急度は「６５」である。

図１９に示す不急度一覧表６３−６では、図１８の不急度一覧表６３−２と比べて、作業Ｄ、作業Ｅ、及び作業Ｈの不急度が低下している。１年後では、作業Ｇの不急度が「３０」であったのが「７５」と高く変化している。

一方で、作業Ｄの不急度は「６０」から「４０」と低く変化し、作業Ｅの不急度は「３０」から「１５」と低く変化し、作業Ｈの不急度は「９０」から「６５」と低く変化している。

この場合、不急度一覧表６３−６のリスケフラグが「９」を示す作業Ｆ及び作業Ｇがリスケジュールされる。

作業Ｆの予定開始日「2013/12/21」及び予定終了日「2013/12/24」がリスケジュールされて、不急度一覧表６３−８に示すように、予定開始日「2013/12/31」及び予定終了日「2014/1/3」となる。

作業Ｇの予定開始日「2013/12/25」及び予定終了日「2013/12/27」がリスケジュールされて、不急度一覧表６３−４に示すように、予定開始日「2014/1/4」及び予定終了日「2014/1/6」となる。

このように、不急度が過去の実績に基づいて計算されることにより、精度良く判断されるため、より安全なリスケジュール案を作成することができる。

上述したように、本実施の形態では、経験の少ないＰＭでも最適なスケジュール修正が可能となる。プロジェクトの遅延や失敗を防ぎ、確実なシステム稼働を支援することに加えて、ＰＭの作業負荷軽減に寄与する。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータによって実行される複数の作業を有するプロジェクトのリスケジュール方法であって、
前記作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、
前記抽出された未完了の作業毎に、前記プロジェクトの納期後に作業可能な程度を示す不急度を算出し、
前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、
前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、
前記リスケジュール案を表示装置に表示させる
ことを特徴とするリスケジュール方法。
（付記２）
前記不急度は、過去に前記作業をリスケジュールしたプロジェクトマネージャに対して、リスケジュールした割合と該プロジェクトマネージャの熟練度とを積和した値を、プロジェクトマネージャの総数で割った値であることを特徴とする付記１記載のリスケジュール方法。
（付記３）
前記未完了の作業毎のリスケジュールした割合は、前記プロジェクトマネージャがリスケジュールを実施したプロジェクト数に対する該プロジェクトマネージャが該作業をリスケジュールしたプロジェクト数の割合であることを特徴とする付記２記載のリスケジュール方法。
（付記４）
前記プロジェクトマネージャの熟練度は、該プロジェクトマネージャの過去の担当プロジェクト数に対する該プロジェクトマネージャの稼働日に遅延がなかった成功プロジェクトの割合であることを特徴とする付記２又は３記載のリスケジュール方法。
（付記５）
前記未完了の作業の前記不急度の値が高い程、リスケジュールの候補作業であることを示し、値がゼロの場合は、リスケジュールができない不可作業であることを示すことを特徴とする付記２乃至４のいずれか一項記載のリスケジュール方法。
（付記６）
プロジェクトの作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、
前記抽出された未完了の作業毎に、前記プロジェクトの納期後にリスケジュール可能な程度を示す不急度を算出し、
前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、
前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、
前記リスケジュール案を表示装置に表示させる
処理をコンピュータに実行させるプロジェクトのリスケジュールプログラム。
（付記７）
プロジェクトの作業毎の実績を示す作業実績情報を記憶した記憶部と、
前記記憶部に記憶された前記作業実績情報をから未完了の作業を抽出し、該抽出された未完了の作業毎に、前記プロジェクトの納期後にリスケジュール可能な程度を示す不急度を算出して、該未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶する不急度判定部と、
前記記憶部に記憶された前記不急度一覧表に基づいて、リスケジュール可能な未完了の作業を、前記納期後にリスケジュールしたリスケジュール案を作成して、該リスケジュール案を表示装置に表示させるリスケジュール案作成部と
を有するプロジェクトのリスケジュール装置。

１１ ＣＰＵ
１２ 主記憶装置
１３ 補助記憶装置
１４ 入力装置
１５ 表示装置
１７ 通信Ｉ／Ｆ
１８ ドライブ
１９ 記憶媒体
３１ ＤＢ
３２ ユーザマスタ
３３ 役割マップ情報
３４ プロジェクト基本情報
３５ プロジェクト実績情報
３６ 担当ユーザリンク情報
３７ 作業基本情報
３８ 作業実績情報
４０ スケジュール部
４１ マスタスケジュール作成部
４２ 担当者割り当て部
４３ 実績管理部
４４ マスタスケジュール表示部
５０ リスケジュール部
５１ 不急度判定部
５２ リスケジュール案作成部
１００ プロジェクト管理装置
ＰＭ２ プロジェクトマネージャ

Claims (4)

1. コンピュータによって実行される複数の作業を有するプロジェクトのリスケジュール方法であって、
   前記作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、
   前記抽出された未完了の作業毎に、過去に該作業をリスケジュールしたプロジェクトマネージャに対して、リスケジュールした割合と該プロジェクトマネージャの熟練度とを積和した値を、プロジェクトマネージャの総数で割ることによって、前記プロジェクトの納期後に作業可能な程度を示す不急度を算出し、
   前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、
   前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、
   前記リスケジュール案を表示装置に表示させる
   ことを特徴とするリスケジュール方法。
2. 前記未完了の作業毎のリスケジュールした割合は、前記プロジェクトマネージャがリスケジュールを実施したプロジェクト数に対する該プロジェクトマネージャが該作業をリスケジュールしたプロジェクト数の割合であることを特徴とする請求項１記載のリスケジュール方法。
3. 前記プロジェクトマネージャの熟練度は、該プロジェクトマネージャの過去の担当プロジェクト数に対する該プロジェクトマネージャの稼働日に遅延がなかった成功プロジェクトの割合であることを特徴とする請求項１又は２記載のリスケジュール方法。
4. プロジェクトの作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、
   前記抽出された未完了の作業毎に、過去に該作業をリスケジュールしたプロジェクトマネージャに対して、リスケジュールした割合と該プロジェクトマネージャの熟練度とを積和した値を、プロジェクトマネージャの総数で割ることによって、前記プロジェクトの納期後に作業可能な程度を示す不急度を算出し、
   前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、
   前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、
   前記リスケジュール案を表示装置に表示させる
   処理をコンピュータに実行させるプロジェクトのリスケジュールプログラム。

Images