以下、本発明の実施の形態を図面に基づいて説明する。本実施の形態におけるプロジェクト管理装置は、図1に示すようなハードウェア構成を有する。図1は、プロジェクト管理装置のハードウェア構成を示す図である。図1において、プロジェクト管理装置100は、コンピュータによって制御される端末であって、CPU(Central Processing Unit)11と、主記憶装置12と、補助記憶装置13と、入力装置14と、表示装置15と、通信I/F(インターフェース)17と、ドライブ装置18とを有し、バスBに接続される。
CPU11は、主記憶装置12に格納されたプログラムに従ってプロジェクト管理装置100を制御する。主記憶装置12には、RAM(Random Access Memory)、ROM(Read Only Memory)等が用いられ、CPU11にて実行されるプログラム、CPU11での処理に必要なデータ、CPU11での処理にて得られたデータ等を格納する。また、主記憶装置12の一部の領域が、CPU11での処理に利用されるワークエリアとして割り付けられている。
補助記憶装置13には、ハードディスクドライブが用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置13に格納されているプログラムの一部が主記憶装置12にロードされ、CPU11に実行されることによって、各種処理が実現される。記憶部130は、主記憶装置12及び/又は補助記憶装置13を有する。
入力装置14は、マウス、キーボード等を有し、ユーザがプロジェクト管理装置100による処理に必要な各種情報を入力するために用いられる。表示装置15は、CPU11の制御のもとに必要な各種情報を表示する。通信I/F17は、例えばインターネット、LAN(Local Area Network)等に接続し、外部装置との間の通信制御をするための装置である。通信I/F17による通信は無線又は有線に限定されるものではない。
プロジェクト管理装置100によって行われる処理を実現するプログラムは、例えば、CD−ROM(Compact Disc Read-Only Memory)等の記憶媒体19によってプロジェクト管理装置100に提供される。
ドライブ装置18は、ドライブ装置18にセットされた記憶媒体19(例えば、CD−ROM等)とプロジェクト管理装置100とのインターフェースを行う。
また、記憶媒体19に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体19に格納されたプログラムは、ドライブ装置18を介してプロジェクト管理装置100にインストールされる。インストールされたプログラムは、プロジェクト管理装置100により実行可能となる。
尚、プログラムを格納する媒体としてCD−ROMに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。コンピュータ読取可能な記憶媒体として、CD−ROMの他に、DVDディスク、USBメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。
本実施の形態におけるプロジェクト管理装置100は、センタ型アウトソーシングサービスとしてプロジェクトを管理するシステムであり、例えば、標準WBS(Work Breakdown structure:作業分割構成)の適用により、作業進捗の管理を支援する。
プロジェクト管理装置100では、プロジェクトが遅延した場合に、不急の作業を特定しリスケジュールすることを可能とする。プロジェクトの不急の作業を、過去の作業実績から判断し、その作業を納期後(例えば、システム稼働後)にリスケジュールすることを可能とする。
不急の作業例として、本来ならばシステム稼働までにシステムバックアップの自動化ツールを作成して動かす必要があるが、どうしてもシステム稼働日までに作成が間に合わない。その際、自動化ツールが完成するまでの間、バックアップは手動で実施するといった対応が考えられる。そしてシステム稼働後、余裕ができた段階で自動化ツールを作成する。
図2は、プロジェクト管理装置の機能構成例を示す図である。図2において、プロジェクト管理装置100は、データベース(DB)31と、スケジュール部40と、リスケジュール部50とを有する。
スケジュール部40は、プロジェクトを構成する複数の作業のスケジュールを行う処理部であり、マスタスケジュール作成部41と、担当者割り当て部42と、実績管理部43と、マスタスケジュール表示部44等を有する。
マスタスケジュール作成部41は、プロジェクト基本情報34に新たなプロジェクトを登録し、作業基本情報37に、新プロジェクトを構成する各作業を登録する等によってマスタスケジュールを作成する。マスタスケジュールは、プロジェクトの納期までの各作業のスケジュールを示す。
担当者割り当て部42は、プロジェクト毎、作業毎に担当者を割り当てる。担当者割り当て部42は、担当ユーザリンク情報36によって、プロジェクト及び作業と担当者とを関連付ける。また、担当者割り当て部42は、役割マップ情報23を用いて、割り当てた担当ユーザと、割り当てられたプロジェクトでの役割とを対応付ける。
実績管理部43は、各プロジェクト、各作業の実績を管理する。実績管理部43は、プロジェクト実績情報35を用いてプロジェクトの実績を管理し、作業実績情報38を用いて作業の実績を管理する。
マスタスケジュール表示部44は、DB31を用いて、プロジェクトマネージャPM2によって指定されたプロジェクトのマスタスケジュールを表示装置15に表示する。
リスケジュール部50は、プロジェクトマネージャPM2のリスケジュール案作成指示に応じて、プロジェクトのリスケジュールを行う処理部であり、不急度判定部51と、リスケジュール案作成部52とを有する。
リスケジュール部50における処理において、対象プロジェクト情報61、対象作業情報62、不急度一覧表63が内部データ60として記憶部130に保持される。内部データ60は、リスケジュール部50における処理中に有効なデータであり、処理の終了によって初期化される。
対象プロジェクト情報61は、リスケジュール対象のプロジェクトに関する情報であり、プロジェクトマネージャPM2によるスケジュールの表示要求等によって指定されたプロジェクトに関する。
対象作業情報62は、指定されたプロジェクトを構成する1以上の作業に関する情報であり、各作業に対応付けて少なくとも作業の未完了/完了のステータスを管理するテーブルである。
不急度一覧表63は、対象作業情報62において未完了の作業に関して、各作業に対応付けて少なくとも不急度を示すテーブルである。不急度は、プロジェクトの納期後に作業可能な程度を示す。不急度がゼロ又はゼロに近い程、プロジェクトの納期後の作業は不可であることを示し、納期後へのリスケジュールできないことを意味する。また、不急度が高い程、プロジェクトの納期後に作業可能であることを示し、納期後へのリスケジュールが可能であることを示す。
不急度判定部51は、リスケジュール案作成指示で指定される、スケジュール部40によってスケジュールされたプロジェクトにおいて、各作業の不急度を判定する。不急度判定部51は、DB31の既に完了している過去の作業実績情報38等を参照して、開発中のプロジェクトの未完了の作業の不急度を判定する。不急度一覧表63が記憶部130に作成される。
不急度判定部51では、過去の同じWBSを利用したプロジェクトでシステム稼働後にリスケジュールされた作業の統計をとり、全くリスケジュールされていない作業を不急度低、よくリスケジュールされている作業を不急度高と判断する。この際、リスケジュールされたプロジェクトマネージャPM2の熟練度も勘案する。熟練度の算出方法については、後述される。
図3は、不急度とリスケジュールとの関係を示す図である。図3中、縦軸に不急度を示し、横軸に作業を示す。不急度がゼロの場合、リスケジュールできない不可作業3aを示す。また、不急度が高い程、リスケジュール可能な作業であり、候補作業3bとして示している。図3の例では、作業C及び作業Gはリスケジュールできない不可タスク3aであり、タスク作業E、作業D、作業F、及び作業Hは、リスケジュール可能な候補作業3bであることを示している。
図2にて、リスケジュール案作成部52は、不急度の高い作業を対象に、作業のスケジュールを見直して、プロジェクトのリスケジュール案を作成し表示装置15に表示する。図3の例では、作業C及び作業Gはリスケジュールされることなく現状通りのスケジュールとなる。
PM2によりリスケジュールが確認され、承認された場合、リスケジュール案作成部52によって作成されたリスケジュール案に従って、DB31内の作業実績情報38が更新される。DB31内の作業実績情報38の更新によって、不急度の高い作業が、プロジェクトの納期後にスケジュールされる。
DB31には、ユーザマスタ32、役割マップ情報33、プロジェクト基本情報34、プロジェクト実績情報35、担当ユーザリンク情報36、作業基本情報37、作業実績情報38等が格納される。各データ例については後述される。
また、図2を参照して、プロジェクト管理装置100を利用した全体の流れについて説明する。プロジェクトマネージャPM2が、プロジェクト遅延によるリスケジュール案作成指示を行うと(i)、リスケジュール部50は、不急度判定部51によって、DB31を利用して、指定されたプロジェクトの各作業の不急度を判定する(ii)。
不急度判定部51によって各作業の不急度の判定後、リスケジュール案作成部52が、プロジェクトにおいて、不急度に基づいて指定されたプロジェクトの納期後に行える作業を抽出し、システム実施開始後(プロジェクトの納期後)に抽出した作業を行うようにリスケジュール案を作成して表示装置15に表示する(iii)。
プロジェクトマネージャPM2は、表示されたリスケジュール案を確認して、リスケジュールの確定又はキャンセルを行う(iv)。確定の場合には、DB31にリスケジュール案が反映される。具体的には、後述される作業実績情報38の構成例において、リスケジュール対象となった作業の予定開始日及び予定終了日が変更される。一方、キャンセルの場合、DB31にリスケジュール案の反映は抑止され、リスケジュール対象となった作業の予定開始日及び予定終了日は変更されない。
図4は、DBの理論構造例を示す図である。図4では、DB30における情報間の関連を示している。図4において、ユーザマスタ32は、役割マップ情報33と関連付けられ、また、役割マップ情報33は、プロジェクト基本情報34と関連付けられる。役割マップ情報33は、プロジェクト毎の担当ユーザと、担当ユーザの役割とを管理する。
プロジェクト基本情報34とプロジェクト実績情報35とが関連付けられる。プロジェクト実績情報35は、関連付けられた各プロジェクトの実績情報を管理する。
また、プロジェクト基本情報34と作業基本情報37とが関連付けられる。作業基本情報37は、プロジェクトを構成する1以上の作業が管理され、また、プロジェクト内の作業間の従属関係を管理する。
プロジェクト基本情報34と、作業基本情報37とは、夫々、担当ユーザリンク情報3に関連付けられる。担当ユーザリンク情報36は、ユーザが属する1以上のプロジェクト又は1以上の作業を管理する。
次に、DB31に格納され管理される情報のデータ構成例について図5から図11で説明する。図5は、ユーザマスタのデータ構成例を示す図である。図5において、ユーザマスタ32は、各ユーザの情報を管理するテーブルであり、ユーザID、ユーザタイプ、ユーザ名、パスワード、部署コード、役職、Emailアドレス、電話番号等の項目を有する。
ユーザIDは、ユーザを一意に識別するIDである。ユーザタイプは、ユーザの場合「0」を示し、グループの場合「1」を示し、仮担当の場合「2」を示す。ユーザ名は、ユーザの名前を示す。
パスワードは、ユーザのパスワードを示す。部署コードは、ユーザが所属する部署を特定するコードを示す。役職は、部署でのユーザの役職を示す。
Emailアドレスは、ユーザの電子メールアドレスを示す。電話番号は、ユーザの電話番号を示す。
各項目に設定されるデータ例として、ユーザID「fj******」のユーザタイプは「0」(ユーザ)であり、ユーザ名は「富士 太郎」である。このユーザのパスワードは「abcdefg」であり、部署コード「0a387311a908012c38af41330000****」で特定される部署において、ユーザの役職は「8(担当者)」であることが示されている。また、ユーザのEmailアドレスは「******@**.**.**」であり、電話番号は「XXXX-XXXX」である。
図6は、役割マップ情報のデータ構成例を示す図である。図6において、役割マップ情報33は、プロジェクトにおいけるユーザの役割を対応付けたテーブルであり、プロジェクト論理ID、仮担当(役割)ユーザID、担当ユーザID、表示順、登録日等の項目を有する。
プロジェクト論理IDは、プロジェクト基本情報34に登録されたプロジェクトを特定するIDを示す。仮担当(役割)ユーザIDは、プロジェクトにおける担当ユーザの役割を識別する情報を示す。担当ユーザIDは、プロジェクトの担当となったユーザのIDを示す。表示順は、プロジェクト内における担当ユーザの表示順を示す。登録日は、プロジェクトに対して担当ユーザを登録した日付を示す。
各項目に設定されるデータ例として、プロジェクト論理ID「0a38743977c3011374da3aee0000****」で特定されるプロジェクトにおいて、仮担当(役割)ユーザIDが「pjmanager」である担当ユーザのIDは「fj******」であり、表示順「9999」で表示され、これら情報の登録日は「2012/9/1」であることが示されている。
図7は、プロジェクト基本情報のデータ構成例を示す図である。図7において、プロジェクト基本情報34は、登録されたプロジェクト毎の情報を管理するテーブルであり、プロジェクト論理ID、プロジェクトタイプ、プロジェクト名、作成者のユーザID、新規作成日、最終更新者のユーザID、最終更新日、プロジェクト責任者のユーザID、テンプレートID、表示順等の項目を有する。
プロジェクト論理IDは、プロジェクト基本情報34に登録されたプロジェクトを特定する論理IDを示す。プロジェクトタイプは、運用プロジェクトの場合は「0」を示し、標準フローの場合は「1」を示し、逐次プロジェクトの場合は「2」を示し、ひな型の場合は「3」を示す。プロジェクト名は、プロジェクトのプロジェクト名(タイトル)を示す。
作成者のユーザIDは、プロジェクトの基本情報を新規作成したユーザのIDを示す。新規作成日は、プロジェクトを新規に作成した日付を示す。最終更新者のユーザIDは、このプロジェクトの基本情報を最後に更新したユーザのIDを示す。最終更新日は、最後に更新した日付を示す。
プロジェクト責任者のユーザIDは、プロジェクトマネージャPM2のユーザIDを示す。子作業の数は、プロジェクト配下の作業数を示す。テンプレートIDは、標準WBSに従った雛型プロジェクトのIDを示す。表示順は、プロジェクトの表示順を示す。
各項目に設定されるデータ例として、プロジェクト論理ID「0a38743977c3011374da3aee0000****」で特定されるプロジェクトにおいて、プロジェクトタイプは「0」(運用プロジェクト)であり、プロジェクト名は「××様/△△プロジェクト」である。作成者のユーザIDは「fj******」であり、新規作成日は「2012/12/1」である。最終更新者のユーザIDは「fj******」であり、最終更新日は「2012/2/1」である。また、プロジェクト責任者のユーザIDは「fj******」である。
子作業の数は「50」個であり、テンプレートIDは「1b49854088d4022384db4veg1213****」であり、表示順は「10」である。
図8は、プロジェクト実績情報のデータ構成例を示す図である。図8において、プロジェクト実績情報35は、各プロジェクトの実績を管理するテーブルであり、プロジェクト論理ID、計画開始日、実績開始日、計画終了日、実績終了日、システム稼働予定日、システム稼働実績日、進捗率、運用ステータス、進捗ステータス等の項目を有する。
プロジェクト論理IDは、プロジェクト基本情報34に登録されたプロジェクトを特定するIDを示す。
計画開始日は、プロジェクトの計画開始日を示し、実績開始日は、プロジェクトの実際の開始日を示す。計画終了日は、プロジェクトの計画終了日を示し、実績終了日は、プロジェクトの実際の終了日を示す。
システム稼働予定日は、顧客での運用開始の予定日を示す。システム稼働実績日は、顧客において実際に運用された日付を示す。進捗率は、プロジェクトの完成度の割合を示す。
運用ステータスは、運用中の場合は「0」を示し、準備中の場合は「1」を示し、完了の場合は「9」を示す。進捗ステータスは、完了の場合は「0」を示し、未着手の場合は「1」を示し、予定通りの場合は「2」を示し、やや遅れの場合は「3」を示し、見直し要の場合は「4」を示す。
各項目に設定されるデータ例として、プロジェクト論理ID「0a38743977c3011374da3aee0000****」で特定されるプロジェクトに関して、計画開始日は「2012/12/15」であり、実績開始日は「2012/12/20」である。また、計画終了日は「2013/3/1」であり、実績終了日は「2013/3/2」である。そして、このプロジェクトの顧客におけるシステム稼働予定日は「2013/2/25」であり、システム稼働実績日は「2013/2/26」である。
進捗率は「100」%であり、運用ステータスは「9」(完了)を示し、このプロジェクトは完了していることを示す。また、進捗ステータスにおいても「0」(完了)を示している。
図9は、担当ユーザリンク情報のデータ構成例を示す図である。図9において、担当ユーザリンク情報36は、担当ユーザ毎にプロジェクト又は作業との関連を管理するテーブルであり、ユーザID、リンク元の論理ID、関連オブジェクトのタイプ、プロジェクト論理ID、役割、表示順等の項目を有する。
ユーザIDは、プロジェクト又は作業のいずれかを担当する担当ユーザのIDを示す。リンク元の論理IDは、プロジェクト基本情報34に登録されているプロジェクト論理ID又は作業基本情報37に登録されている作業論理IDを示す。
関連オブジェクトのタイプは、関連付けられたオブジェクトがプロジェクト又は作業のいずれかであることを示す。プロジェクト論理IDは、リンク元が作業の場合にプロジェクト論理IDが示される。
役割は、担当するプロジェクト又は作業におけるユーザの役割を示す。オブジェクトタイプがプロジェクトを示す場合において、修正不可は「0」で示され、修正可は「2」で示される。オブジェクトタイプが作業を示す場合において、写し(予約)は「0」で示され、主担当は「1」で示され、レビュアは「2」で示され、依頼者は「3」で示される。表示順は、このユーザの担当ユーザリンク情報の表示順を示す。
各項目に設定されるデータ例として、ユーザID「fj******」に関連するリンク元の論理IDは「0a387439d9870105e215ed2e0000****」であり、関連オブジェクトのタイプは「2」(作業)であり、プロジェクト論理IDはリンク元が作業の場合に示され、この例では、「0a38743977c3011374da3aee0000****」である。また、役割は「2」であるため、ユーザID「fj******」で特定されるユーザは、この作業のレビュアであることが示されている。
図10は、作業基本情報のデータ構成例を示す図である。図10において、作業基本情報37は、登録された作業毎の情報を管理するテーブルであり、作業論理ID、作業名、表示順、プロジェクト論理ID、親作業論理ID、階層レベル、子作業の数、作業の一意キー、リードタイム(標準期間(日))、最終更新者、最終更新日等の項目を有する。
作業論理IDは、作業基本情報37に登録された作業を特定する論理IDを示す。作業名は、作業の名称(タイトル)を示す。表示順は、作業の表示順を示す。プロジェクト論理IDは、作業のプロジェクト論理IDを示し、関連付けられる。親作業論理IDは、作業の親作業論理IDを示し、関連付けられる。
階層レベルは、プロジェクトにおいて、作業が位置する階層レベルを示す。子作業の数は、作業配下にある子作業の数を示す。作業の一意キーは、作業に一意に与えられたキーを示す。異なる作業論理IDであっても作業の一意キーが同一の場合、作業として同じであることを示す。リードタイムは、作業を完成させるために必要な日数を示す。
最終更新者は、この作業の基本情報を更新したユーザのIDを示す。最終更新日は、この作業の基本情報を更新した最終日を示す。
図11は、作業実績情報のデータ構成例を示す図である。図11において、作業実績情報38は、作業毎の実績を管理するテーブルであり、作業論理ID、進捗状況(%)、ステータス、実績期間(日数)、実績工数(時間)、予定開始日、実績開始日、予定終了日、実績終了日、リスケジュール有無等の項目を有する。
作業論理IDは、作業基本情報37に登録された作業を特定する論理IDを示す。進捗状況(%)は、作業の進捗度を示す。ステータスは、現在の作業の状態を示し、予定の状態では「0」を示し、着手可の状態では「1」を示し、着手中の状態では「2」を示し、承認中の状態では「3」を示し、差戻しの状態では「4」を示し、完了の状態では「9」を示す。
実績期間(日数)は、実際の作業日数を示す。実績工数(時間)は、実際の工数を時間で示す。予定開始日は、作業の予定開始日を示す。実績開始日は、実際に作業を開始した日付を示す。予定終了日は、作業の予定終了日を示す。実績終了日は、実際に作業を終了した日付を示す。リスケジュール有無は、リスケジュールされたか否かを示すフラグであり、リスケジュール無しの場合は「0」を示し、リスケジュール有りの場合は「1」を示す。
各項目に設定されるデータ例として、作業論理ID「0a387439d9870105e215ed2e0000****」で特定される作業の進捗状況は「100」%であり、ステータスは「9」(完了)を示す。実績期間(日数)は「1」日であり、実績工数(時間)は「2」時間である。
予定開始日「2013/1/21」に対して、実績開始日は「2013/1/22」であったことを示し、予定終了日「2013/1/21」に対して、実績終了日は「2013/1/22」であったことを示す。
リスケジュール前の、DB31に基づくプロジェクトのマスタスケジュールの例を図12で説明する。図12は、マスタスケジュールの例を示す図である。図12に例示されるマスタスケジュールでは、作業Aから作業Hまでの作業がシステム稼働予定日までにスケジュールされた状態が示されている。図12中、作業Aから作業Hの作業名の下の( )内に完了又は未完了を示しているが、各作業A〜Hの完了又は未完了の区別は、文字色等により視認し易い表示で示してもよい。また、各作業名の「−>」印は、作業の予定開始日又は実績開始日から予定終了日又は実績終了日までの長さを表し、「−>」印の下にリードタイムを示す日数を示している。
マスタスケジュールを表示装置15に表示した時点(本日(2012/12/21))、即ち、システム稼働予定日(2012/12/30)の10日前の時点において、作業A及び作業Bは完了しているが、作業Cから作業Hまでは未完了である。未完了の作業のうち、本日(2012/12/21)の時点までに作業C、作業D及び作業Eは完了を予定していた作業である。
本実施の形態に係るプロジェクト管理装置100は、リスケジュール部50によって、未完了の作業Cから作業Hのうち、不急度に基づいて1以上の作業をシステム稼働予定日(2012/12/30)にリスケジュールする。以下、作業Aから作業Hを有するプロジェクトをプロジェクト名「プロジェクトα」で特定するものとする。
不急度を判定してリスケジュールするリスケジュール部50によるリスケジュール処理を図13から図16で説明する。
図13から図16は、リスケジュール処理を説明するためのフローチャート図である。図13において、スケジュール部40は、マスタスケジュール表示部44によって、プロジェクトマネージャPM2によるマスタスケジュールの表示要求に応じて、要求で指定されるプロジェクトのマスタスケジュールを表示装置15に表示させる(ステップS11)。
マスタスケジュール表示部44は、マスタスケジュールの表示要求で指定されるプロジェクト名とシステム稼働予定日と示す対象プロジェクト情報61を記憶部130に記憶する。システム稼働予定日は、マスタスケジュールの表示要求で指定されるプロジェクト名のプロジェクト基本情報34のプロジェクト論理IDで関連付けられるプロジェクト実績情報35から取得することができる。
また、マスタスケジュール表示部44は、プロジェクト論理IDで関連付けられる作業基本情報37から作業名、リードタイムを取得し、また、作業実績情報38から各作業の予定開始日、予定終了日、ステータスを取得して、対象作業情報62を記憶部130に記憶する。対象プロジェクト情報61と対象作業情報62とに基づいて、図12に示すマスタスケジュールが表示装置15に表示される。
そして、マスタスケジュールの表示後、プロジェクトマネージャPM2が、プロジェクトの遅延を確認すると、プロジェクト遅延によりリスケジュール案作成指示を行う。リスケジュール案作成指示は、表示されたマスタスケジュールの画面に構成されるリスケジュールボタンを押下することによって行われる。
マスタスケジュール表示部44は、表示されたマスタスケジュールの画面に構成されるリスケジュールボタンの押下を検出したか否かを判断する(ステップS12)。リスケジュールボタンの押下ではない場合(ステップS12がNo)、このリスケジュールに係る処理を終了する。リスケジュールボタンの押下を検出した場合(ステップS12がYes)、リスケジュール部50が起動する(ステップS13)。
図14において、リスケジュール部50は、対象作業情報62によって示される全ての作業を対象とし(ステップS14)、対象作業情報62から順にレコードを処理対象として、対象作業のステータスが未完了を示すか否かを判断する(ステップS15)。対象作業のステータスが未完了を示す場合(ステップS15がYes)、未完了の作業について、不急度判定部51による不急度判定処理を行う(ステップS16)。
各作業の不急度判定は、下記の式によって計算される。作業Cを例として示すが、他の各作業について同様に不急度を計算する。
作業Cの不急度
=(
(PM(1)の作業Cのリスケ率(%))×(PM(1)の熟練度)
+ ・・・
+ (PM(n)の作業Cのリスケ率(%))×(PM(n)の熟練度)
)÷n 式(1)
ここで、PM(1)からPM(n)は異なるプロジェクトマネージャPM2を示し、nは過去に作業Cをシステム稼動後にリスケジュールしたことのあるプロジェクトマネージャの総人数を示す。
上記式(1)において、各プロジェクトマネージャPM(i)(i=1、2、・・・、n)の作業Cのリスケ率(リスケジュール率)(%)は、
作業Cのリスケ率(%)
= (PM(i)が作業Cをリスケジュールしたプロジェクト数)
÷ (PM(i)がリスケジュールを実施したプロジェクト数)
× 100 式(2)
によって計算される。
PM(i)のユーザIDを含むプロジェクト基本情報34からプロジェクト論理IDで関連付けられるプロジェクト実績情報35の数が、各PM(i)が担当したプロジェクト数に相当する。プロジェクト実績情報35毎に、プロジェクト論理IDで関連付けられる作業基本情報37の作業論理IDを示す作業実績情報38を取得し、取得した作業実績情報38でリスケジュール有無の値が「1」(リスケジュール有)を示す場合に、そのプロジェクトにおいてリスケジュールが実施されたと判断する。リスケジュールを実施したと判断したプロジェクト数をカウントする。PM(i)がリスケジュールを実施したプロジェクト数を得ることができる。
上述したようにPM(i)のユーザID及びプロジェクト論理IDに基づいて得られたプロジェクト実績情報35の、プロジェクト論理IDで関連付けられる作業基本情報37のうち、作業名が所定の作業(例えば、作業C)と一致する作業基本情報37に関して、更に、作業論理IDで関連付けられる作業実績情報38のリスケジュール有無の値「1」である場合に、そのプロジェクトにおいて所定の作業(作業C)をリスケジュールしたと判断する。よって、所定の作業(例えば、作業C)をリスケジュールしたプロジェクト数を取得することができる。
リスケ率は、PM(i)がリスケジュールを実施したプロジェクト数に対する所定の作業(作業C)をリスケジュールしたプロジェクト数の割合で示される。
また、上記式(1)において、各プロジェクトマネージャPM(i)の熟練度は、
PM(i)の熟練度
= (PM(i)の過去の成功プロジェクト数)
÷ (PM(i)の過去の担当プロジェクト数) 式(3)
によって計算される。ここで、成功プロジェクト数とは、稼働日に遅延がなかったプロジェクト数を示す。
上述したようにPM(i)のユーザID及びプロジェクト論理IDに基づいて得られたプロジェクト実績情報35のうち、進捗ステータスの値が「0」(完了)を示すプロジェクト実績情報35の数が、PM(i)の過去の担当プロジェクト数に相当する。
上述の進捗ステータスの値が「0」(完了)を示すプロジェクト実績情報35のうち、システム稼働実績日がシステム稼働予定日と一致又はシステム稼働予定日より前の日付を示すプロジェクト実績情報35の数が、PM(i)の過去の成功プロジェクト数に相当する。
PM(i)の熟練度は、PM(i)の過去の担当プロジェクト数に対するPM(i)の過去の成功プロジェクト数の割合で示される。
対象作業のステータスが完了を示す場合(ステップS15がNo)、プロジェクトの全ての作業のチェックを完了したか否かを判断する(ステップS17)。全ての作業のチェックを完了していない場合(ステップS17がNo)、リスケジュール部50は、対象作業情報62の次のレコードを処理対象として、ステップS15へ戻り上述同様の処理を繰り返す。全ての作業のチェックを完了している場合(ステップS17がYes)、未完了を示す作業の不急度一覧表63がリスケジュール処理における内部データ60として記憶部130に保存される(ステップS18)。
不急度一覧表63は、レコードNo、作業名、リードタイム(日)、予定開始日、予定終了日、不急度、リスケフラグ等の項目を有する。
レコードNoは、不急度一覧表63の各レコードを識別する番号である。作業名は、作業基本情報37に登録された作業名を示す。リードタイムは、作業に必要な日数を示す。予定開始日は、作業の予定開始日を示す。予定終了日は、作業の予定終了日を示す。
不急度は、不急度判定部51によって計算された作業の不急度を示す。リスケフラグは、リスケジュール処理においてリスケジュールされない場合に未リスケジュールを示す「0」が設定され、リスケジュール処理においてリスケジュールされた場合にリスケジュール済みを示す「9」が設定される。不急度一覧表63の作成時には、リスケフラグは、全ての作業で「0」を示す。
図15にて、リスケジュール部50のリスケジュール案作成部52は、システム稼働日までの残日数を求める(ステップS19)。リスケジュール案作成部52は、プロジェクト実績情報35を参照して、リスケジュール対象のプロジェクトのシステム稼働予定日を取得する。また、リスケジュール案作成部52は、現在の日付を取得して、システム稼働予定日と現在の日付との差分を計算する。
そして、リスケジュール案作成部52は、システム稼働前の作業のリードタイム総和を求める(ステップS20)。リスケジュール案作成部52は、不急度一覧表63のリスケフラグが「0」のレコードのリードタイムを全て足して、リードタイム総和を計算する。
リスケジュール案作成部52は、ステップS19で算出した「システム稼働予定日までの残日数」がステップS20で算出した「システム稼働前の作業のリードタイム総和」以上であるか否かを判断する(ステップS21)。
「システム稼働予定日までの残日数」が「システム稼働前の作業のリードタイム総和」より少ない場合(ステップS21のNo)、リスケジュール案作成部52は、不急度一覧表63の中でリスケフラグが「0」かつ不急度が最も高い値のレコードのリスケフラグを「9」に変更する(ステップS21−2)。
そして、リスケジュール案作成部52は、ステップS20へ戻り、上述した同様の処理を繰り返す。ステップS21の判断条件が満たされた状態を、不急度一覧表63−2で示す。図14に示す不急度一覧表63は、図15の不急度一覧表63−2に更新される。
不急度一覧表63−2では、ステップS20、S21、及びS21−2の処理の繰り返しによって、作業Fと作業Hのレコードのリスケフラグが「9」に設定されたことを示している。
「システム稼働予定日までの残日数」が「システム稼働前の作業のリードタイム総和」以上である場合(ステップS21のYes)、リスケジュール案作成部52は、リスケジュール案を作成する(ステップS22)。リスケジュール案作成部52は、リスケフラグが更新された不急度一覧表63−2において、リスケフラグが「9」のレコードについて、システム稼働予定日「2012/12/30」の後に予定開始日及び予定終了日を順に設定する。
図14に示す不急度一覧表63−2のうち、リスケジュール案作成部52は、作業Fの予定開始日「2012/12/21」及び予定終了日「2012/12/24」が、「2012/12/31」及び「2012/1/3」に変更する。また、作業Fの予定開始日「2012/12/28」及び予定終了日「2012/12/30」が、「2013/1/4」及び「2013/1/6」に変更する。図15の不急度一覧表63−2が、図15の不急度一覧表63−4に更新される。
リスケジュール案作成部52は、不急度一覧表63−4に基づいてリスケジュール案を表示装置15に表示する(ステップS23)。後述される図17に示すようなリスケジュール案が表示装置15に表示される。
このように、残された作業期間に対応して、不急度の高い作業から自動的にシステム稼働後の工程にスケジュールし直す。納期までの作業期間と残り作業のリードタイムの総和とを比較して、納期までの作業期間が短い場合、不急度の高い作業から順番にシステム稼働後の工程にリスケジュールする。
プロジェクトマネージャPM2は、表示されたリスケジュール案を確認して、問題ないと判断した場合、リスケジュール案をDB31に反映させるために、画面に用意されている「OK」ボタンを押下する。一方、プロジェクトマネージャPM2は、リスケジュール案を承認できない場合は、画面に用意されている「キャンセル」ボタンを押下する。
図16にて、リスケジュール案作成部52は、リスケジュール案を表示した画面において、「OK」ボタンの押下を検出したか否かを判断する(ステップS24)。「キャンセル」ボタンの押下を検出した場合(ステップS24のNo)、リスケジュール案作成部52は、リスケジュール案を破棄して(ステップS25)、このリスケジュール処理を終了する。リスケジュール案作成部52は、DB31に反映されずに不急度一覧表63−4が破棄される。DB31から得られる不急度は、不急度一覧表63の状態を維持する。
一方、「OK」ボタンの押下を検出した場合(ステップS24のYes)、リスケジュール案作成部52は、リスケジュール案をDB31に反映して(ステップS26)このリスケジュール処理を終了する。リスケジュール案作成部52は、不急度一覧表63−4を用いて、DB31を反映する。具体的には、不急度一覧表63−4のリスケフラグが「9」を示す作業F及び作業Hの予定開始日及び予定終了日で、作業実績情報38の予定開始日及び予定終了日を更新する。
不急度一覧表63−4に基づいて作成されたリスケジュール案を図17に示す。図17は、リスケジュール案を示す図である。図17に示すリスケジュール案において、未完了の作業Cから作業Hのうち、作業Fと作業Hとがシステム稼働予定日「2012/12/30」の後にスケジュールされる案が示されている。
プロジェクトマネージャPM2は、表示装置15に表示されたリスケジュール案を確認して、リスケジュール案を適用するか否かを判断することができる。
上述したように、リスケジュール案は、作業の不急度に基づいて自動的に行われる。また、不急度の計算では、過去のプロジェクトマネージャのリスケジュール率及び熟練度が考慮されることにより精度よく不急度を算出することができる。従って、リスケジュール案では、現在のプロジェクトマネージャPM2のプロジェクトの経験に寄らず、精度よくシステム稼働予定日後にリスケジュール可能な作業を抽出でき、また、適切にリスケジュールすることができる。
また、不急度の計算では、累積された過去のプロジェクトマネージャのリスケジュール率及び熟練度が考慮されるため、同じ作業であっても、累積された情報に応じてリスケジュールの仕方が変動する。例えば、リスケジュールする時期が異なると提示されるリスケジュール案が異なる。
過去のプロジェクトマネージャのリスケジュール率及び熟練度の累積された情報に応じてリスケジュール案が変動する例について、図18及び図19で説明する。図18及び図19では、同じプロジェクトαを現在(「2012/12/21」)と一年後(「2013/12/21」)とでリスケジュールを行った場合の例を示す。
図18は、現在の不急度一覧表を示す図である。図18に示す不急度一覧表63−2において、作業Cの不急度は「0」であり、作業Dの不急度は「60」であり、作業Eの不急度は「30」であり、作業Fの不急度は「70」であり、作業Gの不急度は「30」であり、作業Hの不急度は「90」である。
不急度一覧表63−2のリスケフラグが「9」を示す作業F及び作業Hがリスケジュールされる。
作業Fの予定開始日「2012/12/21」及び予定終了日「2012/12/24」がリスケジュールされて、不急度一覧表63−4に示すように、予定開始日「2012/12/21」及び予定終了日「2012/12/28」となる。
作業Hの予定開始日「2012/12/28」及び予定終了日「2012/12/30」がリスケジュールされて、不急度一覧表63−4に示すように、予定開始日「2012/12/31」及び予定終了日「2013/1/3」となる。
プロジェクトにおいては、標準の運用契約の内容が変更されることで作業Gがシステム稼働日以降に実施しても大きな問題にならなくなる場合、一年後には作業Gが多くのプロジェクトでリスケジュールされた実績が積みあがり、不急度が高くなる可能性ある。一方で、作業Gがリスケジュールされる分、他の作業がリスケジュールされないようになり、相対的に他の作業の不急度が低くなる可能性がある。
図19は、1年後の不急度一覧表を示す図である。図19に示す不急度一覧表63−6において、作業Cの不急度は「0」であり、作業Dの不急度は「40」であり、作業Eの不急度は「15」であり、作業Fの不急度は「70」であり、作業Gの不急度は「75」であり、作業Hの不急度は「65」である。
図19に示す不急度一覧表63−6では、図18の不急度一覧表63−2と比べて、作業D、作業E、及び作業Hの不急度が低下している。1年後では、作業Gの不急度が「30」であったのが「75」と高く変化している。
一方で、作業Dの不急度は「60」から「40」と低く変化し、作業Eの不急度は「30」から「15」と低く変化し、作業Hの不急度は「90」から「65」と低く変化している。
この場合、不急度一覧表63−6のリスケフラグが「9」を示す作業F及び作業Gがリスケジュールされる。
作業Fの予定開始日「2013/12/21」及び予定終了日「2013/12/24」がリスケジュールされて、不急度一覧表63−8に示すように、予定開始日「2013/12/31」及び予定終了日「2014/1/3」となる。
作業Gの予定開始日「2013/12/25」及び予定終了日「2013/12/27」がリスケジュールされて、不急度一覧表63−4に示すように、予定開始日「2014/1/4」及び予定終了日「2014/1/6」となる。
このように、不急度が過去の実績に基づいて計算されることにより、精度良く判断されるため、より安全なリスケジュール案を作成することができる。
上述したように、本実施の形態では、経験の少ないPMでも最適なスケジュール修正が可能となる。プロジェクトの遅延や失敗を防ぎ、確実なシステム稼働を支援することに加えて、PMの作業負荷軽減に寄与する。
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
(付記1)
コンピュータによって実行される複数の作業を有するプロジェクトのリスケジュール方法であって、
前記作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、
前記抽出された未完了の作業毎に、前記プロジェクトの納期後に作業可能な程度を示す不急度を算出し、
前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、
前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、
前記リスケジュール案を表示装置に表示させる
ことを特徴とするリスケジュール方法。
(付記2)
前記不急度は、過去に前記作業をリスケジュールしたプロジェクトマネージャに対して、リスケジュールした割合と該プロジェクトマネージャの熟練度とを積和した値を、プロジェクトマネージャの総数で割った値であることを特徴とする付記1記載のリスケジュール方法。
(付記3)
前記未完了の作業毎のリスケジュールした割合は、前記プロジェクトマネージャがリスケジュールを実施したプロジェクト数に対する該プロジェクトマネージャが該作業をリスケジュールしたプロジェクト数の割合であることを特徴とする付記2記載のリスケジュール方法。
(付記4)
前記プロジェクトマネージャの熟練度は、該プロジェクトマネージャの過去の担当プロジェクト数に対する該プロジェクトマネージャの稼働日に遅延がなかった成功プロジェクトの割合であることを特徴とする付記2又は3記載のリスケジュール方法。
(付記5)
前記未完了の作業の前記不急度の値が高い程、リスケジュールの候補作業であることを示し、値がゼロの場合は、リスケジュールができない不可作業であることを示すことを特徴とする付記2乃至4のいずれか一項記載のリスケジュール方法。
(付記6)
プロジェクトの作業毎の実績を示す作業実績情報を記憶した記憶部を参照して、指定されたプロジェクトに係る該作業実績情報に基づいて未完了の作業を抽出し、
前記抽出された未完了の作業毎に、前記プロジェクトの納期後にリスケジュール可能な程度を示す不急度を算出し、
前記未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶し、
前記不急度一覧表に基づいて、前記未完了の作業を前記納期後にリスケジュールしたリスケジュール案を作成し、
前記リスケジュール案を表示装置に表示させる
処理をコンピュータに実行させるプロジェクトのリスケジュールプログラム。
(付記7)
プロジェクトの作業毎の実績を示す作業実績情報を記憶した記憶部と、
前記記憶部に記憶された前記作業実績情報をから未完了の作業を抽出し、該抽出された未完了の作業毎に、前記プロジェクトの納期後にリスケジュール可能な程度を示す不急度を算出して、該未完了の作業毎に前記不急度を対応付けた不急度一覧表を作成して記憶部に記憶する不急度判定部と、
前記記憶部に記憶された前記不急度一覧表に基づいて、リスケジュール可能な未完了の作業を、前記納期後にリスケジュールしたリスケジュール案を作成して、該リスケジュール案を表示装置に表示させるリスケジュール案作成部と
を有するプロジェクトのリスケジュール装置。