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

Abstract

【課題】プロジェクトの遅延原因を特定を支援する。
【解決手段】ＣＣＰＭ（Critical Chain Project Management）に基づくプロジェクト管理装置において、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数の時点毎に消費率の変化の程度を示す変化量を算出する変化量算出部と、変化量算出部が算出した変化量が所定の閾値を超える時点を抽出する抽出部と、を備えることを特徴とするプロジェクト管理装置。
【選択図】図１

Description

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

従来、ソフトウェア開発や建設工事などのプロジェクトを管理するため、例えば、アローダイアグラムやガントチャートなどの様々な様式の工程表が考案され、利用されてきた。近年では、ＣＣＰＭ（Critical Chain Project Management）という工程管理方法が新たに提唱されている（例えば、特許文献１）。ＣＣＰＭでは、各工程の工期を短く設定する代わりに全工程の後にまとまったバッファを設け、工程毎に割振られた工期で工程を完了できない場合、バッファを消費させる。ＣＣＰＭでは、プロジェクトの進捗の程度を示す進捗率とバッファの消費の程度を示す消費率との２つのパラメータについてのトレンドグラフにより進捗を管理する。トレンドグラフでは、プロジェクトの進捗状況に応じて、その表示領域が３つに分割されて示される。プロジェクトの管理者は、任意の日時におけるデータが当該トレンドグラフ上のどの領域に属するかということを確認することによりプロジェクトの進捗を視覚的に把握することができる。

特開２０１２―５８８６７号公報

しかしながら、トレンドグラフによって任意の日時におけるプロジェクトの進捗状況を確認することはできるものの、例えばプロジェクトに遅延が発生している場合に、この遅延原因を特定することは困難であった。

本発明は上記の点に鑑みてなされたものであり、プロジェクトの遅延原因の特定を支援するプロジェクト管理装置、プロジェクト管理方法、およびプロジェクト管理プログラムを提供する。

本発明は、上記の課題を解決するためになされたものであり、本発明の一態様は、ＣＣＰＭに基づくプロジェクト管理装置において、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数時点毎に消費率の変化の程度を示す変化量を算出する変化量算出部と、変化量算出部が算出した変化量が所定の閾値を超える時点を抽出する抽出部と、を備えることを特徴とするプロジェクト管理装置である。

また、本発明の一態様は、上記のプロジェクト管理装置は、プロジェクトを構成する各工程を予定工期内に完了する確率として予め定められた値と変化量算出部が算出した変化量とに基づいて所定の閾値を算出する閾値算出部を備えることを特徴とする。

また、本発明の一態様は、上記のプロジェクト管理装置において、閾値算出部は、変化量算出部が算出した変化量の平均値に基づいて所定の閾値を算出することを特徴とする。

また、本発明の一態様は、上記のプロジェクト管理装置において、消費率は、複数時点毎の進捗報告に基づいて算出され、プロジェクト管理装置は、抽出部が抽出した時点に対応する複数の進捗報告のうち、同一の日付、同一の工程、または同一の担当者についての情報が含まれる複数の進捗報告を抽出する類似兆候抽出部を備えることを特徴とする。

また、本発明の一態様は、ＣＣＰＭに基づくプロジェクト管理方法であって、変化量算出部が、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数時点毎に消費率の変化の程度を示す変化量を算出する変化量算出過程と、抽出部が、変化量算出部が算出した変化量が所定の閾値を超える時点を抽出する抽出過程と、を有することを特徴とするプロジェクト管理方法である。

また、本発明の一態様は、ＣＣＰＭに基づくプロジェクト管理プログラムであって、コンピュータに、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数時点毎に消費率の変化の程度を示す変化量を算出する変化量算出手順、変化量算出手順において算出された変化量が所定の閾値を超える時点を抽出する抽出手順、を実行させるためのプロジェクト管理プログラムである。

本発明によれば、プロジェクトの遅延原因の特定を支援することができる。

本発明の第１の実施形態に係るプロジェクト管理装置の機能構成の一例を示す図である。 従来のプロジェクト管理手法に基づいて計画された工程表の一例である。 本実施形態に係るＣＣＰＭに基づいて計画された工程表の一例である。 本実施形態に係るＣＣＰＭに基づくバッファの設定方法を説明するための第１の図である。 本実施形態に係るＣＣＰＭに基づくバッファの設定方法を説明するための第２の図である。 本実施形態に係るＣＣＰＭに基づいてプロットされたトレンドグラフの一例である。 本実施形態に係るプロジェクト管理装置のプロジェクト情報記憶部が格納するデータの一例を示す表である。 本実施形態に係るプロジェクト管理装置のタスク情報記憶部が格納するデータの一例を示す表である。 本実施形態に係るプロジェクト管理装置の進捗情報記憶部が格納するデータの一例を示す表である。 本実施形態に係るプロジェクト管理装置の進捗率記憶部が格納するデータの一例を示す表である。 本実施形態に係るプロジェクト管理装置の消費率記憶部が格納するデータの一例を示す表である。 本実施形態に係るプロジェクト管理装置の変化量記憶部が格納するデータの一例を示す表である。 本実施形態に係るプロジェクト管理装置による処理の流れの一例を示す第１の図である。 本実施形態に係る消費率の変化量の時系列変化を示すグラフの一例である。 本実施形態に係るプロジェクト管理装置による処理の流れの一例を示す第２の図である。 本発明の第２の実施形態に係るプロジェクト管理装置の機能構成の一例を示す図である。 本実施形態に係るプロジェクト管理装置の変化量記憶部が格納するデータの一例を示す表である。

＜第１の実施形態＞
以下、図面を参照しながら、本発明の第１の実施形態に係るプロジェクト管理装置について説明する。図１は、本実施形態に係るプロジェクト管理装置１００の機能構成の一例を示す図である。プロジェクト管理装置１００は、ＣＣＰＭと呼ばれるプロジェクト管理手法に基づいてプロジェクトの管理を行う装置であり、プロジェクトの遅延原因の特定を支援する機能を備える。

ここで、図２〜６を参照し、ＣＣＰＭの特徴について簡単に説明する。図２〜図５において、符号Ｗ１〜符号Ｗ４各々は、プロジェクトを構成する作業工程をそれぞれ示す。これら作業工程は、以下でタスクと称することがある。各タスク間を連結する矢印を、依存線という。例えば、図２〜図５において、Ｂ作業Ｗ２は、Ａ作業Ｗ１に依存しており、Ａ作業Ｗ１が終了しなければ、Ｂ作業を開始することができない。同様に、Ｄ作業Ｗ４は、Ｃ作業Ｗ３に依存しており、Ｃ作業Ｗ３が終了しなければ、Ｄ作業Ｗ４を開始することができない。このような作業間の依存関係を示すものが依存線である。図２〜図５の下部には、時間の経過を示す時間軸が記載されている。図２〜図５において、日付ｔ１、ｔ２、ｔ３、ｔ４は、それぞれＡ作業Ｗ１、Ｂ作業Ｗ２、Ｃ作業Ｗ３、Ｄ作業Ｗ４の開始日を示す。日付ｔ１’、ｔ２’、ｔ３’、ｔ４’は、それぞれＡ作業Ｗ１、Ｂ作業Ｗ２、Ｃ作業Ｗ３、Ｄ作業Ｗ４の終了日を示す。マイルストンＭＳは、プロジェクトの区切りとなる期限を示す。日付ｔＭＳは、マイルストンの期日を示す。

図２は、従来のプロジェクト管理手法に基づいて計画された工程表の一例Ｃ１である。依存関係にある作業のうち、全工程の終了までに最も時間を要すると見積られる作業群がクリティカルパスと呼ばれる。Ａ作業Ｗ１およびＢ作業Ｗ２全体の予定工期に比して、Ｃ作業Ｗ３およびＤ作業Ｗ４全体の予定工期の方が長い時間を要するので、クリティカルパスはＣ作業Ｗ３およびＤ作業Ｗ４である。しかし、従来の方法では、タスク間の依存関係は考慮しているが、作業に割当てられる資源の依存関係は考慮してこなかった。資源とは、例えば、作業を担当する人材や作業を行う上で必要となるコンピュータなどの資材のことを指す。例えば、工程表Ｃ１において、Ａ作業Ｗ１、Ｂ作業Ｗ２、Ｃ作業Ｗ３は、担当Ａが担当することになっており、Ｃ作業Ｗ３は、担当Ｂが担当することになっている。同一の人物が担当するＢ作業Ｗ２とＤ作業Ｗ４とが並行して進められた場合、Ｂ作業Ｗ２とＤ作業Ｗ４とに遅延が発生する可能性が高い。従って、プロジェクトの終了期限日ｔＭＳにプロジェクトを完了することができない場合がある。

図３は、ＣＣＰＭに基づいて計画された工程表の一例Ｃ２である。工程表Ｃ２は、工程表Ｃ１と同一のプロジェクトに係る工程表である。工程表Ｃ２は、ＣＣＰＭに基づいている。ＣＣＰＭでは、タスクの依存関係に加え、資源の依存関係も考慮する。上述のようにＢ作業Ｗ２とＤ作業Ｗ４とは、担当者が同一であるため、これらの作業を並行して計画するのは不適切である。そこで、ＣＣＰＭでは、資源に依存関係がある場合、その資源を必要とするタスクが重複しないようにプロジェクトが計画される。例えば、工程表Ｃ２の場合、資源に依存関係のあるＢ作業Ｗ２とＤ作業Ｗ４とが重複しないように、Ｄ作業Ｗ４作業の開始日ｔ４をＢ作業Ｗ２の終了日ｔ２’に移動している。このように各タスクの依存関係および資源の依存関係を考慮した予定工期について、プロジェクト終了までの工期が最長となる作業群をクリティカルチェーンという。工程表Ｃ２の例において、クリティカルチェーンは、Ａ作業Ｗ１、Ｂ作業Ｗ２、Ｄ作業Ｗ４である。

図４は、ＣＣＰＭに基づくバッファの設定方法を説明するための第１の図である。ＣＣＰＭでは、プロジェクトバッファという概念を導入し、プロジェクトが計画される。バッファは作業計画に対する作業の遅延を吸収し、最終的なプロジェクトの遅延を防止するために設けられる。バッファを設置しない従来の方法では、各タスクの予定工期は９０％の確率で作業を完了できる期間として見積られていた。ＣＣＰＭでは５０％の確率で作業を完了できる期間を各タスクの予定工期として見積り、従来の方法による見積り期間の差分をバッファとして設置する。図４に示される工程表Ｃ３は、工程表Ｃ２の各タスクＷ１〜Ｗ４各々に対して、バッファＢ１〜Ｂ４がそれぞれ設けられた様子を示す。

図５は、ＣＣＰＭに基づくバッファの設定方法を説明するための第２の図である。ＣＣＰＭでは、工程表Ｃ３のように算出したバッファを分類し、再配置する。図５に示される工程表Ｃ４は、工程表Ｃ３に示すバッファ期間を再配置した様子を示す。ＣＣＰＭにおいて、クリティカルチェーンは、プロジェクト全体の進捗に直結する作業群である。クリティカルチェーンに属するタスクのバッファは、プロジェクト全体のバッファ（プロジェクトバッファ）として共通管理される。クリティカルチェーン以外のタスクのバッファは、合流バッファとしてタスク毎に個別管理する。

工程表Ｃ４において、クリティカルチェーンであるＡ作業Ｗ１、Ｂ作業Ｗ２、Ｄ作業Ｗ４のバッファＢ１、Ｂ２、Ｂ４は、プロジェクトバッファとして統合され、プロジェクトの最終作業であるＤ作業Ｗ４終了日後に配置されている。クリティカルチェーンではないＣ作業Ｗ３のバッファＢ３は、合流バッファとしてＣ作業Ｗ３と一体に配置されている。以上のように、ＣＣＰＭでは各タスクを、その遅延がプロジェクトの工期に即座に影響を及ぼすクリティカルチェーンと、多少の遅れであればプロジェクトの工期に影響を及ぼさないタスクとに分類して管理するため、従来のプロジェクト管理手法に比して、プロジェクトの遅延を正確に検出することができる。

図６は、ＣＣＰＭに基づいてプロットされたトレンドグラフの一例Ｇ１である。トレンドグラフとは、ＣＣＰＭにおける上述のプロジェクトバッファの消費率（バッファ消費率）を縦軸に、プロジェクトの進捗率を横軸にとったグラフである。トレンドグラフにおいて、グラフの表示領域は３つに分割される。当該分割された３つの領域Ａ１〜Ａ３は、それぞれプロジェクトの進捗状況を示す。領域Ａ１は、プロジェクトの遅延が深刻であることを示す危険域である。領域Ａ２は、プロジェクトが遅れ始めていることを示す警告域である。領域Ａ３は、プロジェクトの進捗が順調であることを示す安全域である。このように、ＣＣＰＭではトレンドグラフにおいてデータがどの領域に属するかということを検討することにより、プロジェクトの進捗と遅延とを確認することができる。

トレンドグラフによりプロジェクトの遅延していることが示される場合、遅延を解消し、プロジェクトを進めるために、管理者により遅延原因の解析が行われる。解析作業は、例えば、トレンドグラフ上で変化量の大きなデータポイントを判別し、当該日の作業を確認することにより行われてきた。しかしながら、グラフＧ１に示すようにトレンドグラフは、煩雑な軌道を描くことがあり、このような場合は、視認による遅延原因の解析は困難であった。本実施形態に係るプロジェクト管理装置１００は、所定の閾値に基づいて、トレンドグラフ上における消費率の変化量の大きなデータポイントを抽出することで、遅延原因の特定を容易にする。具体的には、例えばプロジェクト管理装置１００は、後述する図１４に示すように、消費率の変化量の時系列変化を閾値とともにグラフ上に示すことで、変化量の大きなデータポイントを管理者に分かり易く示す。

図１の説明に戻る。プロジェクト管理装置１００は、記憶部１１０と、操作入力部１２０と、表示部１３０と、プロジェクト情報入力制御部１４１と、タスク情報入力制御部１４２と、進捗報告入力制御部１４３と、進捗率算出部１４４と、消費率算出部１４５と、変化量算出部１４６と、閾値算出部１４７と、抽出部１５０と、生成部１６０と、を備える。

記憶部１１０は、例えば、ＨＤＤ（Hard Disc Drive；ハードディスク記憶装置）、ＳＳＤ（Solid State Drive；半導体記憶装置）、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory；書き換え可能不揮発性メモリ）、ＲＯＭ（Read Only Memory）、またはＲＡＭ（Random Access Memory）などを備え、プロジェクト管理装置１００の備えるＣＰＵ（Central Processing Unit；中央演算装置）が実行する各種プログラム（ファームウェアやアプリケーションプログラムなど）やＣＰＵが行った各種の処理結果などを格納する。プロジェクト情報入力制御部１４１、タスク情報入力制御部１４２、進捗報告入力制御部１４３、進捗率算出部１４４、消費率算出部１４５、変化量算出部１４６、閾値算出部１４７、抽出部１５０、生成部１６０は、例えば、記憶部１１０に格納されたプログラムをＣＰＵが実行することにより機能する。

また、記憶部１１０は、プロジェクト情報記憶部１１１と、タスク情報記憶部１１２と、進捗報告記憶部１１３と、進捗率記憶部１１４と、消費率記憶部１１５と、変化量記憶部１１６と、閾値係数記憶部１１７と、閾値記憶部１１８と、特殊原因遅延発生日記憶部１１９と、を備える。

以下では、複数のプロジェクトについて例示する。図７は、プロジェクト情報記憶部１１１が格納するプロジェクト情報の一例を示す表Ｔ１である。プロジェクト情報記憶部１１１は、プロジェクトＩＤ（IDentifier）、プロジェクト名、最終更新日、期間、プロジェクトオーナー、プロジェクトリーダー、最終再計算基準日、残作業率、クリティカルチェーン情報を格納する。表Ｔ１において例示されているデータは、既に終了したプロジェクトについてのものである。プロジェクトＩＤは、プロジェクト各々の識別情報を示す。プロジェクト名は、プロジェクトの名称を示す。

最終更新日は、プロジェクト情報の最終更新日を示す。期間は、プロジェクトの開始日と終了日とを示す。プロジェクトオーナーは、プロジェクトの責任者を示す。プロジェクトリーダーは、プロジェクトの指揮者を示す。最終再計算基準日は、残作業率やクリティカルチェーン情報などの数値の更新が行われた最後の日付を示す。残作業率は、最終再計算基準日における、予定作業量に対する残りの作業量の比率を示す。例えば、残作業率は、プロジェクトの各タスクのうち未着手のタスクの予定工期と進行中のタスクの終了までに係る予定日数の総和とを、プロジェクト全体の各タスクの予定工期の総和で除算することで算出される。

クリティカルチェーン情報は、プロジェクトＩＤが示すプロジェクトについての、実績日数、ＣＣ（クリティカルチェーン）残日数、初期計画日数、進捗率、消費バッファ、総バッファ、消費率を含む。実績日数は、最終再計算基準日における、プロジェクト開始日からの作業日数を示す。ＣＣ残日数は、未着手のクリティカルチェーンのタスクの予定工期および進行中のクリティカルチェーンのタスクの終了までに要する予定日数の総和を示す。初期計画日数は、クリティカルチェーンのタスクの予定工期の総和を示す。進捗率は、プロジェクトの進捗の程度を示す。消費バッファは、プロジェクトバッファのうち、クリティカルチェーンのタスクの遅延によって消費された日数を示す。総バッファは、プロジェクトバッファの総日数を示す。消費率は、プロジェクトバッファの消費の程度を示す。表Ｔ１において、消費バッファは９であり、総バッファは１０である。従って、表Ｔ１に示されるように、消費率は、消費バッファを総バッファで除算することにより求められる９０．０％である。

図８は、タスク情報記憶部１１２が格納するタスク情報の一例を示す表Ｔ２である。タスク情報記憶部１１２は、タスクＩＤ、タスク名、先行タスク、担当者、クリティカルチェーンフラグ、予定工期、開始日、終了日、作業期間、残日数をプロジェクト毎に対応付けて格納する。表Ｔ２は、「２０１３／６／１２」時点における例を示している。タスクＩＤは、タスク各々の識別情報を示す。タスク名は、タスクＩＤが示すタスクの作業内容を示す。タスク名とタスクＩＤとは、１対１で対応付けられており、相互に参照可能である。表Ｔ２においてタスク名は省略されている。

先行タスクは、タスクの依存関係を示す。先行タスクには、別のタスクＩＤが記録される。先行タスクが無い場合には、当該項目は「ＮＵＬＬ」とする。例えば、表Ｔ２において、タスクＩＤ「Ｋ１」の先行タスクは「ＮＵＬＬ」である。「Ｋ１」のタスクが依存するタスクはなく、当該タスクの開始には制約がない。例えば、表Ｔ２において、タスクＩＤ「Ｋ４」の先行タスクは、「Ｋ２」である。「Ｋ４」のタスクは「Ｋ２」のタスクに依存し、「Ｋ２」のタスク完了後でなければ、「Ｋ４」のタスクを開始できない。担当者は、タスクＩＤに示されるタスクの作業を実行する担当者を示す。

クリティカルチェーンフラグは、タスクＩＤに示されるタスクがクリティカルチェーンであるか否かを示す。クリティカルチェーンフラグには、ＴＲＵＥまたはＦＡＬＳＥが記録される。例えば、表Ｔ２において、タスクＩＤ「Ｋ１」のクリティカルチェーンフラグは「ＴＲＵＥ」であり、当該タスクはクリティカルチェーンである。例えば、表Ｔ２において、タスクＩＤ「Ｋ２」のクリティカルチェーンフラグは「ＦＡＬＳＥ」であり、当該タスクはクリティカルチェーンではない。

予定工期は、プロジェクト計画時に、タスクＩＤに示されるタスクを完了するまでに要すると見積られた日数を示す。開始日は、タスクＩＤに示されるタスクを開始した日付を示す。タスクが開始されていない場合には、当該項目は「ＮＵＬＬ」とする。例えば、表Ｔ２において、タスク名「Ｋ１」の開始日は、「２０１３／６／６」である。例えば、表Ｔ２において、タスク名「Ｋ８」のタスクは、「２０１３／６／１２」時点において開始されていないため、「ＮＵＬＬ」である。終了日は、タスクＩＤに示されるタスクを完了した日付を示す。例えば、表Ｔ２において、タスク名「Ｋ１」の終了日は、「２０１３／６／６」である。例えば、表Ｔ２において、タスク名「Ｋ６」のタスクは、「２０１３／６／１２」時点において完了していないため、「ＮＵＬＬ」である。作業期間は、タスクＩＤに示されるタスクの開始から終了までに要した日数を示す。或いは、作業期間は、現在進行中のタスクを開始してから経過した日数を示す。残日数は、タスクＩＤに示されるタスクのタスク情報が更新された日において見積られた、タスク完了までに要する日数を示す。

図９は、プロジェクト管理装置１００の進捗報告記憶部１１３が格納する進捗報告情報の一例を示す表Ｔ３である。進捗報告記憶部１１３は、報告ＩＤ、タスク名、タスク着手日、報告日、残日数、遅延理由、担当者を格納する。表Ｔ３において、報告ＩＤは、進捗報告各々の識別番号を示す。表Ｔ３において、タスク名は、進捗報告に係るタスクの作業内容を示す。タスク着手日は、タスク名に示される作業を開始した日付を示す。表Ｔ３において、報告日は、進捗報告情報が記憶された日付を示す。表Ｔ３において、残日数は、タスク名に示されるタスクの終了までに要する残りの作業日数を示す。表Ｔ３において、遅延理由は、タスク名に示されるタスクが遅延している理由について、担当者からの報告内容を示す。担当者は、タスク名に示される作業の担当者を示す。

図１０は、プロジェクト管理装置１００の進捗率記憶部１１４が格納する進捗率の一例を示す表Ｔ４である。進捗率記憶部１１４は、進捗率を時系列に記憶する。表Ｔ４において、日付は、進捗報告が行われた日付を示す。表Ｔ４において、進捗率は、対応する日付における進捗率を示す。

図１１は、プロジェクト管理装置１００の消費率記憶部１１５が格納するデータの一例を示す表Ｔ５である。消費率記憶部１１５は、消費率を時系列に記憶する。表Ｔ５において、日付は、進捗報告が行われた日付を示す。表Ｔ５において、消費率は、対応する日付における消費率を示す。すなわち、この一例において、記憶部１１０の消費率記憶部１１５には、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている。ここで、時点とは、例えば、日付や時刻、月などを指す。

図１２は、プロジェクト管理装置１００の変化量記憶部１１６が格納する変化量の一例を示す表Ｔ６である。表Ｔ５と表Ｔ６とに例示した消費率と変化量とは同一のプロジェクトについてのものである。変化量記憶部１１６は、消費率の変化の程度を示す変化量を時系列に記憶する。表Ｔ６において、日付は、進捗報告が行われた日付を示す。表Ｔ６において、変化量は、対応する日付におけるバッファ消費率の前日からの変化量を示す。具体的には、例えば、表Ｔ５に示される「２０１３／６／６」の消費率は５％である。当該日はプロジェクトの開始日であり、その前日には、プロジェクトが開始されておらず、プロジェクトバッファは全く消費されていない。そのため、表Ｔ６に示される「２０１３／６／６」の変化量は、消費率と同じ５％である。例えば、表Ｔ５に示される「２０１３／６／７」の消費率は２５％である。その前日である「２０１３／６／６」の消費率は、５％であるので、表Ｔ６に示される「２０１３／６／７」の変化量は、「２０１３／６／７」の消費率２５％と「２０１３／６／６」の消費率５％との差の２０％である。

図１の説明に戻る。閾値係数記憶部１１７は、変化量が大きい時点を抽出するための閾値の算出に使用する閾値係数を格納する。本実施形態では、閾値係数として「２」が閾値係数記憶部１１７に格納されている。当該「２」の閾値係数は、ＣＣＰＭにおいて、各タスクの予定工期の見積りを行う際の作業を完了できる確率５０％（１／２）に基づいて設定されている。例えば、作業を完了できる確率が８０％（４／５）であるとして、予定工期の見積りを行うとき、閾値係数は、「１．２５（５／４）」に設定される。

閾値記憶部１１８は、変化量が大きい時点を抽出するための閾値を格納する。
特殊原因遅延発生日記憶部１１９は、閾値に基づいて抽出された変化量が示す日数を示す情報を格納する。

操作入力部１２０は、例えば、マウスやキーボードなどを備え、プロジェクト管理装置１００の操作者からの入力を受け付ける。操作入力部１２０は受け付けた操作内容に応じた処理を行う。操作入力部１２０が受け付ける操作内容は、プロジェクトの概要を示すプロジェクト情報、プロジェクトのタスク各々についての内容を示すタスク情報、タスクの進捗報告の内容を示す進捗報告情報、グラフの表示命令、遅延原因に係る進捗報告の表示命令などである。操作入力部１２０は、プロジェクト情報を受け付けると、プロジェクト情報入力制御部１４１にプロジェクト情報を出力する。操作入力部１２０は、タスク情報を受け付けると、タスク情報入力制御部１４２にタスク情報を出力する。操作入力部１２０は、進捗報告情報を受け付けると、進捗報告入力制御部１４３に進捗報告情報を出力する。操作入力部１２０は、グラフの表示命令を受け付けると、グラフの生成命令を生成部１６０に出力する。操作入力部１２０は、遅延原因に係る進捗報告の表示命令を受け付けると、変化量の算出命令を変化量算出部１４６に出力する。

表示部１３０は、例えば、液晶ディスプレイや有機ＥＬ（Electro-Luminescence）ディスプレイなどの表示装置を備える。表示部１３０は、生成部１６０から入力されたグラフの画像データや表の画像データに基づく画像を表示装置に表示する。

プロジェクト情報入力制御部１４１は、操作入力部１２０から入力されたプロジェクト情報をプロジェクト情報記憶部１１１に記憶させる。プロジェクト情報入力制御部１４１は、例えば、表Ｔ１に示す、プロジェクト名、プロジェクトの期間、プロジェクトオーナー、プロジェクトリーダー、初期計画日数、総バッファの情報をプロジェクトＩＤ毎に対応付けてプロジェクト情報記憶部１１１に記憶させる。プロジェクト情報入力制御部１４１は、プロジェクト情報の更新を行った日付を、最終更新日（表Ｔ１）としてプロジェクト情報記憶部１１１に記憶させる。

タスク情報入力制御部１４２は、操作入力部１２０から入力されたタスク情報をタスク情報記憶部１１２に記憶させる。タスク情報入力制御部１４２は、例えば、表Ｔ２に示す、タスクＩＤ、タスク名、先行タスク、担当者、クリティカルチェーンフラグ、予定工期、開始日の情報をタスク情報記憶部１１２に記憶させる。

進捗報告入力制御部１４３は、操作入力部１２０から入力された進捗報告情報を進捗報告記憶部１１３に記憶させる。進捗報告入力制御部１４３は、例えば、操作入力部１２０から入力されたタスク名、報告日、残日数、遅延理由、担当者の情報に対して、報告ＩＤを割当て、対応付けて進捗報告記憶部１１３に記憶させる。進捗報告入力制御部１４３は、操作入力部１２０から入力されたタスクの残日数に基づいて、タスク情報記憶部１１２の残日数（表Ｔ２）を更新する。

残日数が「０」の場合、進捗報告入力制御部１４３は、現在の日付（進捗報告の行われた日付）を終了日としてタスク情報記憶部１１２に記憶させる。進捗報告入力制御部１４３は、タスクの開始日から現在の日付までの日数を作業期間として、タスク情報記憶部１１２に記憶させる。進捗報告入力制御部１４３は、タスク情報記憶部１１２を参照し、クリティカルチェーンフラグが「ＴＲＵＥ」であり、開始日が「ＮＵＬＬ」ではないタスク情報を抽出する。進捗報告入力制御部１４３は、抽出したタスク情報について、作業期間と残日数との総和から予定工期の総和を減算することにより消費バッファを算出する。進捗報告入力制御部１４３は、算出した消費バッファをプロジェクト情報記憶部１１１に記憶させる。進捗報告入力制御部１４３は、プロジェクト情報記憶部１１１のクリティカルチェーン情報を更新すると、プロジェクト情報記憶部１１１の最終再計算基準日と最終更新日とを現在の日付に更新する。

進捗報告入力制御部１４３は、タスク情報記憶部１１２を参照し、クリティカルチェーンフラグが「ＴＲＵＥ」であるタスク情報を抽出する。タスク情報記憶部１１２は、抽出したタスク情報のうち開始日が「ＮＵＬＬ」である未着手のタスクの予定工期の総和を算出する。進捗報告入力制御部１４３は、算出した予定工期の総和に、抽出したタスク情報のうち開始日は記録されているが終了日が「ＮＵＬＬ」である作業中のタスクの残日数を加算する。進捗報告入力制御部１４３は、算出された日数をプロジェクト情報記憶部１１１に、ＣＣ残日数として記憶させる。進捗報告入力制御部１４３は、進捗率算出部１４４に、進捗率の算出命令を出力する。進捗報告入力制御部１４３は、消費率算出部１４５に、消費率の算出命令を出力する。

進捗率算出部１４４は、進捗報告入力制御部１４３から進捗率の算出命令を入力されると、進捗率を算出する。具体的には、進捗率算出部１４４は、プロジェクト情報記憶部１１１を参照し、初期計画日数とＣＣ残日数とを取得する。進捗率算出部１４４は、取得した初期計画日数とＣＣ残日数とに基づいて、以下の式（１）から進捗率を算出する。
（進捗率）＝（１−（ＣＣ残日数）／（初期計画日数））×１００ ・・・（１）
進捗率算出部１４４は、算出した進捗率をプロジェクト情報記憶部１１１に記憶させる。進捗率算出部１４４は、算出した進捗率を現在の日付（進捗報告の行われた日付）に対応付けて、進捗率記憶部１１４に記憶させる。進捗率算出部１４４は、進捗率記憶部１１４に日付が同一の進捗率が記憶されている場合は、当該新たに算出した進捗率で該当日の進捗率を上書きする。

消費率算出部１４５は、進捗報告入力制御部１４３から消費率の算出命令を入力されると、消費率を算出する。具体的には、消費率算出部１４５は、プロジェクト情報記憶部１１１を参照し、進捗報告に基づいて更新された消費バッファと総バッファとを取得する。消費率算出部１４５は、取得した消費バッファと総バッファとに基づいて、以下の式（２）により消費率を算出する。
（消費率）＝（消費バッファ）／（総バッファ）×１００ ・・・（２）
消費率算出部１４５は、算出した消費率をプロジェクト情報記憶部１１１に記憶させる。消費率算出部１４５は、算出した消費率を現在の日付（進捗報告の行われた日付）に対応付けて、消費率記憶部１１５に記憶させる。消費率記憶部１１５に日付が同一の消費率が記憶されている場合は、当該新たに算出した消費率で該当日の消費率を上書きする。

変化量算出部１４６は、操作入力部１２０から遅延原因に係る進捗報告の表示命令を入力されると、消費率の変化量を算出する。具体的には、変化量算出部１４６は、プロジェクト情報記憶部１１１からプロジェクトの開始日を取得する。変化量算出部１４６は、プロジェクト開始からの経過日数を示す変数Ｄ_１を０とする。変化量算出部１４６は、変数Ｄ_１が０の場合、消費率記憶部１１５を参照し、プロジェクトの開始日の消費率を取得する。変化量算出部１４６は、取得した消費率をプロジェクトの開始日の変化量として変化量記憶部１１６に記憶させ、変数Ｄ_１に１を加算する。変数Ｄ_１が１以上の場合、変化量算出部１４６は、消費率記憶部１１５を参照し、プロジェクトの開始日からＤ_１日後の消費率Ｂ［Ｄ_１］と（Ｄ_１−１）日後の消費率Ｂ［Ｄ_１−１］との２つの時点における消費率を読み出す。変化量算出部１４６は、Ｄ_１日後の消費率Ｂ［Ｄ_１］から（Ｄ_１−１）日後の消費率Ｂ［Ｄ_１−１］を減算し、消費率の変化の程度を示す変化量Ｃ［Ｄ_１］を算出する。変化量算出部１４６は、算出した変化量Ｃ［Ｄ_１］を、プロジェクトの開始日からＤ_１日後の日付に対応付けて変化量記憶部１１６に記憶させ、変数Ｄ_１に１を加算する。変数Ｄ_１が示す日数が、消費率記憶部１１５に記憶されている最後の日付の、プロジェクト開始からの経過日数よりも大きい場合、変化量算出部１４６は、閾値算出部１４７に閾値の算出命令を出力する。

閾値算出部１４７は、変化量算出部１４６から閾値の算出命令を入力されると、変化量が大きい時点を抽出するための閾値を算出する。具体的には、閾値算出部１４７は、変化量記憶部１１６を参照し、日付毎の変化量を取得する。閾値算出部１４７は、取得した変化量各々の絶対値について、その平均値を算出する。閾値算出部１４７は、閾値係数記憶部１１７を参照し、閾値係数を取得する。閾値算出部１４７は、算出した平均値と閾値係数との積を算出し、当該積を閾値として算出する。閾値算出部１４７は、算出した閾値を、閾値記憶部１１８に記憶させる。すなわち、この一例において、閾値算出部１４７は、閾値係数と変化量算出部１４６が算出した変化量とに基づいて、所定の閾値を算出する。また、閾値算出部１４７は、変化量算出部１４６が算出した変化量の平均値に基づいて所定の閾値を算出する。閾値算出部１４７は、遅延に関係する日付の抽出命令を抽出部１５０に出力する。閾値算出部１４７は、変化量の時系列変化を示すグラフの生成命令を生成部１６０に出力する。

抽出部１５０は、変化量算出部１４６が算出した変化量が所定の閾値を超える時点を抽出し、類似する遅延の兆候に基づいて進捗報告を抽出する。抽出部１５０は、特殊原因遅延発生日抽出部１５１と、類似兆候抽出部１５２と、を備える。抽出部１５０の特殊原因遅延発生日抽出部１５１は、閾値算出部１４７から遅延に関係する日付の抽出命令を入力されると、閾値記憶部１１８を参照し、閾値を取得する。特殊原因遅延発生日抽出部１５１は、プロジェクト情報記憶部１１１を参照し、プロジェクトの開始日を取得する。特殊原因遅延発生日抽出部１５１は、プロジェクトの開始日からの経過日数を示す変数Ｄ_２を０とする。特殊原因遅延発生日抽出部１５１は、変化量記憶部１１６を参照し、プロジェクトの開始日からＤ_２日後の変化量Ｃ［Ｄ_２］を取得する。特殊原因遅延発生日抽出部１５１は、取得した変化量Ｃ［Ｄ_２］の絶対値｜Ｃ［Ｄ_２］｜と閾値Ｔとを比較する。変化量Ｃ［Ｄ_２］の絶対値｜Ｃ［Ｄ_２］｜が閾値Ｔよりも大きい場合、特殊原因遅延発生日抽出部１５１は、抽出した変化量Ｃ［Ｄ_２］に対応付けられている日付を特殊原因遅延発生日記憶部１１９に記憶させ、変数Ｄ_２に１を加算する。変化量Ｃ［Ｄ_２］の絶対値｜Ｃ［Ｄ_２］｜が閾値Ｔ以下の場合、特殊原因遅延発生日抽出部１５１は、変数Ｄ_２に１を加算する。変数Ｄ_２が示す日数が、変化量記憶部１１６に記憶されている最後の日付の、プロジェクト開始からの経過日数よりも大きい場合、特殊原因遅延発生日抽出部１５１は、類似兆候抽出部１５２に進捗報告の抽出命令を出力する。

抽出部１５０の類似兆候抽出部１５２は、特殊原因遅延発生日抽出部１５１から進捗報告の抽出命令を入力されると、特殊原因遅延発生日記憶部１１９を参照し、特殊原因遅延発生日抽出部１５１により抽出された日付を取得する。類似兆候抽出部１５２は、進捗報告記憶部１１３を参照し、取得した日付各々に該当する進捗報告を取得する。類似兆候抽出部１５２は、取得した進捗報告各々の内容を比較し、進捗報告を抽出する。すなわち、この一例において、類似兆候抽出部１５２は、特殊原因遅延発生日抽出部１５１が抽出した時点に対応する複数の進捗報告から進捗報告を抽出する。

本実施形態において、類似兆候抽出部１５２は、進捗報告のうちの担当者と、タスク名と、報告日と、に基づいて進捗報告をそれぞれ抽出する。類似兆候抽出部１５２は、取得した進捗報告のうち、同一の担当者が含まれる進捗報告を抽出する。類似兆候抽出部１５２は、取得した進捗報告のうち、同一のタスク名が含まれる進捗報告を抽出する。類似兆候抽出部１５２は、取得した進捗報告のうち、同一の報告日が含まれる進捗報告を抽出する。すなわち、この一例において、類似兆候抽出部１５２は、同一の日付、同一の工程（タスク）、または同一の担当者についての情報が複数の進捗報告に含まれる進捗報告を抽出する。類似兆候抽出部１５２は、担当者と、タスク名と、報告日とに基づいてそれぞれ抽出した進捗報告の報告ＩＤを示す報告ＩＤ情報を生成部１６０に出力する。

生成部１６０は、表示用の画像データを生成する。生成部１６０は、グラフ生成部１６１と、遅延原因リスト生成部１６２と、を備える。グラフ生成部１６１は、操作入力部１２０からトレンドグラフの生成命令を入力されると、進捗率記憶部１１４から進捗率を取得する。同様に、グラフ生成部１６１は、消費率記憶部１１５から消費率を取得する。グラフ生成部１６１は、日付毎の進捗率と消費率とに基づいて、進捗率と消費率とを軸として有するトレンドグラフ（例えば、グラフＧ１）上にデータをプロットした画像データを生成する。グラフ生成部１６１は、生成した画像データを表示部１３０に出力する。

グラフ生成部１６１は、変化量の時系列変化を示すグラフの生成命令を入力されると、変化量記憶部１１６から日付毎の変化量を取得する。グラフ生成部１６１は、取得した日付毎の変化量に基づいて、例えば、変化量を縦軸とし、日付を横軸とするグラフデータを生成する。グラフ生成部１６１は、閾値記憶部１１８から閾値を取得する。グラフ生成部１６１は、変化量について閾値が示す値を、横軸に平行な線分として、生成したグラフ上に重ね合わせたグラフの画像データを生成する。グラフ生成部１６１は、生成した画像データを表示部１３０に出力する。

遅延原因リスト生成部１６２は、特殊原因遅延発生日記憶部１１９を参照し、日付を取得する。遅延原因リスト生成部１６２は、進捗報告記憶部１１３を参照し、取得した日付に基づいて進捗報告を抽出する。遅延原因リスト生成部１６２は、抽出した進捗報告を示す表のデータを生成する。遅延原因リスト生成部１６２は、類似兆候抽出部１５２から担当者と、タスク名と、報告日と、に基づいてそれぞれ抽出された報告ＩＤを入力されると、生成した表のデータ上で当該報告ＩＤの進捗報告を判別できるように、例えば、当該進捗報告について表示する色を変更する。遅延原因リスト生成部１６２は、生成した表を表示するための画像データを生成する。遅延原因リスト生成部１６２は、生成した画像データを表示部１３０に出力する。

図１３は、プロジェクト管理装置１００による処理の流れの一例を示す第１の図である。まず、変化量算出部１４６は、プロジェクト情報記憶部１１１からプロジェクトの開始日を取得する。次に、変化量算出部１４６は、プロジェクト開始からの経過日数を示す変数Ｄ_１を０とする（ステップＳ１０１）。次に、変化量算出部１４６は、変数Ｄ_１が０か否かを判定する（ステップＳ１０２）。変数Ｄ_１が０の場合（ステップＳ１０２；ＹＥＳ）、消費率記憶部１１５を参照し、プロジェクトの開始日の消費率を取得する。次に、変化量算出部１４６は、取得した消費率をプロジェクトの開始日の変化量として変化量記憶部１１６に記憶させる（ステップＳ１０３）。

変数Ｄ_１が１以上の場合（ステップＳ１０３；ＮＯ）、変化量算出部１４６は、消費率記憶部１１５を参照し、プロジェクトの開始日からＤ_１日後の消費率Ｂ［Ｄ_１］と（Ｄ_１−１）日目の消費率Ｂ［Ｄ_１−１］とを取得する（ステップＳ１０４）。次に、変化量算出部１４６は、Ｄ_１日後の消費率Ｂ［Ｄ_１］から（Ｄ_１−１）日後の消費率Ｂ［Ｄ_１−１］を減算し、変化量Ｃ［Ｄ_１］を算出する（ステップＳ１０５）。次に、変化量算出部１４６は、算出した変化量を、プロジェクトの開始日からＤ_１日後の日付に対応付けて、変化量記憶部１１６に記憶させる。次に、変化量算出部１４６は、変数Ｄ_１に１を加算する（ステップＳ１０６）。

次に、変化量算出部１４６は、変数Ｄ_１が示す日数が、消費率記憶部１１５に記憶されている最後の日付の、プロジェクト開始からの経過日数よりも大きいか否かを判定する（ステップＳ１０７）。変数Ｄ_１が、消費率記憶部１１５に記憶されている最後の日付の、プロジェクトの開始日からの経過日数以下の場合（ステップＳ１０７；ＮＯ）、ステップＳ１０２に戻る。変数Ｄ_１が、消費率記憶部１１５に記憶されている最後の日付の、プロジェクトの開始日からの経過日数より大きい場合（ステップＳ１０７；ＹＥＳ）、変化量算出部１４６は、閾値算出部１４７に閾値の算出命令を出力する。次に、閾値算出部１４７は、変化量記憶部１１６を参照し、日付毎の変化量を取得する。閾値算出部１４７は、取得した変化量各々の絶対値について、その平均値を算出する。閾値算出部１４７は、閾値係数記憶部１１７を参照し、閾値係数αを取得する。次に、閾値算出部１４７は、算出した変化量の絶対値の平均値と閾値係数との積を閾値Ｔとして算出する（ステップＳ１０８）。次に、閾値算出部１４７は、特殊原因遅延発生日抽出部１５１に変化量の抽出命令を出力する。

次に、閾値算出部１４７は、変化量の時系列変化を示すグラフの生成命令を生成部１６０に出力する。次に、生成部１６０のグラフ生成部１６１は、閾値算出部１４７から変化量の時系列変化を示すグラフの生成命令を入力されると、変化量記憶部１１６から日付毎の変化量を取得する。次に、グラフ生成部１６１は、取得した日付毎の変化量に基づいて、変化量を縦軸とし、日付を横軸とするグラフデータを生成する。次に、グラフ生成部１６１は、閾値記憶部１１８から閾値を取得する。グラフ生成部１６１は、変化量について閾値が示す値を、横軸に平行な線分として、生成したグラフ上に重ね合わせたグラフの画像データを生成する。（ステップＳ１０９）。次に、グラフ生成部１６１は、生成したグラフの画像データを表示部１３０に出力する。そして、表示部１３０は、生成部１６０から入力されたグラフの画像データ基づく画像を表示装置に表示する（ステップＳ１１０）。すなわち、この一例において、表示部１３０は、変化量の時系列変化を示すグラフを表示する。その後、図１５に示すステップＳ２０１に遷移する。

図１４は、上述のステップＳ１１０において表示部１３０が表示する消費率の変化量の時系列変化を示すグラフの一例Ｇ２である。グラフＧ２において、縦軸は変化量を示す。グラフＧ２において、横軸は日付を示す。グラフＧ２には、変化量記憶部１１６が記憶する変化量が日付毎にプロットされている。また、グラフＧ２には、閾値Ｔが示す値が横軸に平行な線分として示されている。また、当該閾値を超える変化量が円Ｓにより示されている。閾値を超える変化量は、後述の図１５に示す処理によって抽出される。このようにすることでプロジェクト管理装置１００は、消費率の変化が大きく、プロジェクトの遅延原因が発生した日付を分かり易く表示することができる。

図１５は、プロジェクト管理装置１００による処理の流れの一例を示す第２の図である。まず、特殊原因遅延発生日抽出部１５１は、閾値算出部１４７から変化量の抽出命令を入力されると、特殊原因遅延発生日抽出部１５１は、閾値記憶部１１８を参照し、閾値を取得する。次に、特殊原因遅延発生日抽出部１５１は、プロジェクト開始からの経過日数を示す変数Ｄ_２を０とする（ステップＳ２０１）。次に、特殊原因遅延発生日抽出部１５１は、変化量記憶部１１６を参照し、プロジェクト開始からＤ_２日目の変化量Ｃ［Ｄ_２］を取得する。

次に、特殊原因遅延発生日抽出部１５１は、取得した変化量Ｃ［Ｄ_２］の絶対値｜Ｃ［Ｄ_２］｜が閾値Ｔより大きいか否かを判定する。変化量Ｃ［Ｄ_２］の絶対値｜Ｃ［Ｄ_２］｜が閾値Ｔよりも大きい場合（ステップＳ２０２；ＹＥＳ）、特殊原因遅延発生日抽出部１５１は、抽出した変化量｜Ｃ［Ｄ_２］｜に対応付けられている日付を特殊原因遅延発生日記憶部１１９に記憶させる（ステップＳ２０３）。次に、特殊原因遅延発生日抽出部１５１は、変数Ｄ_２に１を加算する（ステップＳ２０４）。変化量Ｃ［Ｄ_２］の絶対値｜Ｃ［Ｄ_２］｜が閾値Ｔ以下の場合（ステップＳ２０２；ＮＯ）、ステップＳ２０４に遷移する。

次に、特殊原因遅延発生日抽出部１５１は、変数Ｄ_２が示す日数が、変化量記憶部１１６に記憶されている最後の日付の、プロジェクトの開始日からの経過日数よりも大きいか否かを判定する（ステップＳ２０５）。変数Ｄ_２が示す日数が、変化量記憶部１１６に記憶されている最後の日付の、プロジェクトの開始日からの経過日数以下の場合（ステップＳ２０５；ＮＯ）、ステップＳ２０２に戻る。変数Ｄ_２が示す日数が、変化量記憶部１１６に記憶されている最後の日付の、プロジェクトの開始日からの経過日数よりも大きい場合（ステップＳ２０５；ＹＥＳ）、特殊原因遅延発生日抽出部１５１は、類似兆候抽出部１５２に進捗報告の抽出命令を出力する。

類似兆候抽出部１５２は、特殊原因遅延発生日抽出部１５１から進捗報告の抽出命令を入力されると、特殊原因遅延発生日記憶部１１９を参照し、特殊原因遅延発生日抽出部１５１により抽出された日付を取得する。次に、類似兆候抽出部１５２は、進捗報告記憶部１１３を参照し、取得した日付各々に該当する進捗報告を抽出する（ステップＳ２０６）。

次に、類似兆候抽出部１５２は、取得した進捗報告のうち、同一の担当者が含まれる進捗報告を抽出する（ステップＳ２０７）。また、類似兆候抽出部１５２は、取得した進捗報告のうち、同一のタスク名が含まれる進捗報告を抽出する（ステップＳ２０８）。また、類似兆候抽出部１５２は、取得した進捗報告のうち、同一の報告日が含まれる進捗報告を抽出する（ステップＳ２０９）。次に、類似兆候抽出部１５２は、担当者と、タスク名と、報告日と、に基づいてそれぞれ抽出した進捗報告の報告ＩＤを示す報告ＩＤ情報を遅延原因リスト生成部１６２に出力する。

次に、遅延原因リスト生成部１６２は、特殊原因遅延発生日記憶部１１９を参照し、日付を取得する。次に、遅延原因リスト生成部１６２は、進捗報告記憶部１１３を参照し、取得した日付に基づいて進捗報告を抽出する。次に、遅延原因リスト生成部１６２は、抽出した進捗報告を示す表の画像データを生成する（ステップＳ２１０）。次に、遅延原因リスト生成部１６２は、抽出部１５０の類似兆候抽出部１５２から担当者と、タスク名と、報告日とに基づいてそれぞれ抽出された報告ＩＤを入力されると、生成した表のデータ上で当該報告ＩＤの進捗報告を判別できるように、例えば、当該進捗報告について表示する色を変更する。遅延原因リスト生成部１６２は、生成した画像データを表示部１３０に出力する。表示部１３０は、遅延原因リスト生成部１６２から入力された表の画像データに基づいて、抽出された進捗報告の表を表示する（ステップＳ２１１）。これにより、プロジェクトの管理者は、例えば、表示された進捗報告の遅延理由を確認し、遅延原因を特定することができる。

以下、類似兆候抽出部１５２により抽出された進捗報告からの、遅延原因の特定方法の例について説明する。同一の担当者から遅延報告が行われている場合、遅延原因として、例えば以下の４つが想定される。第１の遅延原因は、他の作業に追われるなどして、担当者の作業量が不足していることである。第２の遅延原因は、突発的に発生したタスクなどにより、担当者の作業量が不足していることである。第３の遅延原因は、健康状態の悪化などにより、担当者の作業効率が低下していることである。第４の遅延原因は、担当者のプロジェクトやタスクへの理解度が低く、作業効率が悪いことである。これらの原因を裏付けるためには、例えば、当該担当者について、作業量、他のプロジェクトへの割当状況、タスクの消化実績、超過勤務、有給休暇の取得状況などを確認する。

同一のタスク名のタスクについて遅延報告が行われている場合、遅延原因として、例えば以下の２つが想定される。第１の遅延原因は、当該タスクに関する作業時間や手順の見積りが正しくないことである。第２の遅延原因は、当該タスクの実施に必要なコンピュータなどの資材が故障したり、他のタスクに使用されていたりして不足していることである。これらの原因を裏付けるためには、例えば、過去の類似したタスクの計画や作業実績と当該タスクの進捗状況とを対比したり、資材の使用状況や故障状況を確認したりする。同一の報告日に遅延報告が多く行われている場合、遅延原因として、例えばプロジェクト全体に影響を及ぼす問題が発生したことが想定される。

従来、ＣＣＰＭに基づくプロジェクト管理方法ではトレンドグラフを確認することにより、プロジェクトの遅延を視覚的に把握することができた。遅延を把握した場合、遅延を解消するための手がかりとして遅延の原因を特定することが行われる。例えば、従来、トレンドグラフから遅延の原因に関係するデータを得ようとする場合、視覚的にバッファ消費率の変化が大きいデータを管理者が各々抽出し、抽出したデータを解析することにより遅延原因を特定していた。このような方法は、効率的或いは定量的とは言えず、原因の特定に至るまでのプロセスは、プロジェクトの管理者の経験に依存する部分が多かった。特に大規模なプロジェクトになるとデータ量は膨大になり、例えば、グラフＧ１に示すように、トレンドグラフの軌跡は非常に煩雑になる。従って、遅延原因の特定は、さらに困難であった。このようにＣＣＰＭの問題点は、プロジェクトの遅延という結果に関する情報は提供するが、なぜ遅れたかという原因に関する情報は十分には提供しないという点であった。遅延原因を特定できなくては、プロジェクトの管理者は効果的な対策を打つことはできない。その結果、計画通りにプロジェクトを完了することが難しくなる場合があった。

それに対して、以上のように、ＣＣＰＭに基づくプロジェクト管理装置１００は、記憶部１１０と、変化量算出部１４６と、抽出部１５０と、を備える。変化量算出部１４６は、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が時系列に記憶されている記憶部１１０の消費率記憶部１１５から、消費率を読み出し、複数時点毎に消費率の変化の程度を示す変化量を算出する。抽出部１５０の特殊原因遅延発生日抽出部１５１は、変化量算出部１４６が算出した変化量が所定の閾値を超える時点を抽出する。

これにより、プロジェクト管理装置１００は、バッファの消費率の変化を数値として算出し、消費率の変化が大きい時点を抽出することができる。従って、プロジェクト管理装置１００は、遅延原因に関係する進捗報告などのデータを、プロジェクト管理者の経験に依らずに、定量的に抽出することができる。その結果、例えば、プロジェクトに関係する資料が膨大であったとしても、プロジェクトの管理者は、資料のどの部分に着目するべきかという手がかりを得ることができ、遅延原因の特定に要する作業時間を短縮することができる。また、プロジェクト管理装置１００は、ＣＣＰＭに通常用いられるバッファの消費率を使用し、新たな測定値の入力を必要としない。従って、ＣＣＰＭに基づいて管理されるプロジェクトに対して、新たな負荷をかけることなくプロジェクト管理装置１００を適用することができる。

また、図２を用いて説明したように、従来のクリティカルパスに基づくプロジェクト管理手法では、資源の競合による作業効率の低下が考慮されていないため、遅れがプロジェクトの工期に影響を及ぼすタスクであるか否かを判定できない。図３〜図５を用いて説明したように、ＣＣＰＭは、クリティカルチェーンに基づいてプロジェクトを管理するため、より正確にプロジェクトの遅延を判定することができる。上述のように、プロジェクト管理装置１００は、ＣＣＰＭに基づいて遅延原因の特定を支援するため、従来の管理手法に基づいて遅延要因の特定を支援する装置よりも、遅延原因の特定において、より優れた効果を発揮することができる。

プロジェクト管理装置１００は、変化量に基づいて所定の閾値を算出する閾値算出部１４７を備える。統計学者のＷｉｌｌｉａｍ Ｅｄｗａｒｄｓ Ｄｅｍｉｎｇ氏によると、遅延の原因は、特殊原因と共通原因とに分類される。特殊原因とは、プロジェクトの一部にのみ影響を与えるものであり、非周期的に発生するとされる。特殊原因は、例えば、担当者の業務の理解不足、人員や機械などの資源の不足などであり、原因を特定することで遅延への対応が可能である。共通原因とは、プロジェクトの全体に影響を与えるものであり、周期的に発生するとされる。共通原因は、例えば、工期の見積りの誤差などであり、進行中のプロジェクトにおいて遅延を是正することは難しい。上述のように閾値算出部１４７は、変化量の絶対値の平均値など、変化量に基づいて所定の閾値を算出するため、周期的に発生するとされる共通原因に基づく変化量の変動の影響を除外する閾値を算出することができる。これにより、プロジェクト管理装置１００は、遅延原因のうちの特殊原因に分類される遅延原因に関与するデータを抽出することができる。

閾値算出部１４７は、プロジェクトを構成する各工程を予定工期内に完了する確率として予め定められた値に基づいて、閾値を算出する。上述のように本実施形態において、閾値係数は、各タスクの予定工期の見積りにおける作業を完了できる確率５０％（１／２）に基づき、「２」に設定されている。予定工期の見積りにおける作業を完了できる確率５０％は、遅延が発生する確率が５０％であることを意味する。閾値算出部１４７は、タスク（工程）を予定工期内に完了する確率、すなわち、遅延が発生する確率に基づいて閾値を算出するため、プロジェクト管理装置１００は、遅延に関係するデータをより正確に抽出することができる。

プロジェクト管理装置１００は、特殊原因遅延発生日抽出部１５１が抽出した時点に対応する複数の進捗報告のうち、同一の日付、同一の工程、または同一の担当者についての情報が含まれる複数の進捗報告を抽出する類似兆候抽出部１５２を備える。これにより、プロジェクト管理装置１００は、変化量の大きさとは別の観点から、遅延に関係する進捗報告を抽出する。従って、プロジェクト管理者は、より正確にプロジェクトの遅延原因を特定することができる。

プロジェクト管理装置１００は、変化量の時系列変化を示すグラフ（例えば、グラフＧ２）を表示する表示部１３０を備える。従って、プロジェクト管理装置１００は、閾値を超える変化量とその日付を分かり易く表示することができる。

＜第２の実施形態＞
以下、図面を参照しながら、本発明の第２の実施形態に係るプロジェクト管理装置について説明する。第２の実施形態に係るプロジェクト管理装置は、第１の実施形態に係るプロジェクト管理装置１００同様、ＣＣＰＭに基づいてプロジェクトの管理を行う装置であり、プロジェクトの遅延原因の特定を支援する機能を備える。第２の実施形態に係るプロジェクト管理装置は、複数時点毎の進捗率の変化量を算出し、変化量が閾値を超える時点を抽出する。

図１６は、本実施形態に係るプロジェクト管理装置１００ａの機能構成の一例を示す図である。プロジェクト管理装置１００ａは、記憶部１１０ａと、操作入力部１２０ａと、表示部１３０ａと、プロジェクト情報入力制御部１４１ａと、タスク情報入力制御部１４２ａと、進捗報告入力制御部１４３ａと、進捗率算出部１４４ａと、消費率算出部１４５ａと、変化量算出部１４６ａと、閾値算出部１４７ａと、抽出部１５０ａと、生成部１６０ａと、を備える。記憶部１１０ａは、プロジェクト情報記憶部１１１ａと、タスク情報記憶部１１２ａと、進捗報告記憶部１１３ａと、進捗率記憶部１１４ａと、消費率記憶部１１５ａと、変化量記憶部１１６ａと、閾値係数記憶部１１７ａと、閾値記憶部１１８ａと、特殊原因遅延発生日記憶部１１９ａと、を備える。抽出部１５０ａは、特殊原因遅延発生日抽出部１５１ａと、類似兆候抽出部１５２ａと、を備える。生成部１６０ａは、グラフ生成部１６１ａと、遅延原因リスト生成部１６２ａと、を備える。

上述の本実施形態に係るプロジェクト管理装置１００ａの構成のうち、プロジェクト情報記憶部１１１ａ、タスク情報記憶部１１２ａ、進捗報告記憶部１１３ａ、進捗率記憶部１１４ａ、消費率記憶部１１５ａ、閾値係数記憶部１１７ａ、閾値記憶部１１８ａ、特殊原因遅延発生日記憶部１１９ａ、操作入力部１２０ａ、表示部１３０ａ、プロジェクト情報入力制御部１４１ａ、タスク情報入力制御部１４２ａ、進捗報告入力制御部１４３ａ、進捗率算出部１４４ａ、消費率算出部１４５ａ、閾値算出部１４７ａ、抽出部１５０ａ、生成部１６０ａ各々は、第１の実施形態に係るプロジェクト管理装置１００の構成のうち、プロジェクト情報記憶部１１１、タスク情報記憶部１１２、進捗報告記憶部１１３、進捗率記憶部１１４、消費率記憶部１１５、閾値係数記憶部１１７、閾値記憶部１１８、特殊原因遅延発生日記憶部１１９、操作入力部１２０、表示部１３０、プロジェクト情報入力制御部１４１、タスク情報入力制御部１４２、進捗報告入力制御部１４３、進捗率算出部１４４、消費率算出部１４５、閾値算出部１４７、抽出部１５０、生成部１６０各々と同一の機能構成を備えるため説明を省略し、本実施形態に係る特徴的な構成である変化量記憶部１１６ａと変化量算出部１４６ａとについて説明する。

図１７は、本実施形態に係る記憶部１１０ａの変化量記憶部１１６ａが格納する変化量の一例を示す表Ｔ７である。ここでは、図１０の表Ｔ４と表Ｔ７とに例示した進捗率と変化量とは同一のプロジェクトについてのものであるとする。変化量記憶部１１６ａは、消費率の変化の程度を示す変化量を時系列に記憶する。表Ｔ７において、日付は、進捗報告が行われた日付を示す。表Ｔ７において、変化量は、対応する日付における進捗率の前日からの変化量を示す。具体的には、例えば、表Ｔ４に示される「２０１３／６／６」の進捗率は５％である。当該日はプロジェクトの開始日であり、その前日には、プロジェクトが開始されていない。そのため、表Ｔ７に示される「２０１３／６／６」の変化量は、消費率と同じ５％である。例えば、表Ｔ４に示される「２０１３／６／７」の消費率は２０％である。その前日である「２０１３／６／６」の消費率は、５％であるので、表Ｔ６に示される「２０１３／６／７」の変化量は、「２０１３／６／７」の消費率２０％と「２０１３／６／６」の消費率５％との差の１５％である。

図１６の説明に戻る。変化量算出部１４６ａは、操作入力部１２０ａから遅延原因に係る進捗報告の表示命令を入力されると、進捗率の変化量を算出する。具体的には、変化量算出部１４６ａは、プロジェクト情報記憶部１１１ａからプロジェクトの開始日を取得する。変化量算出部１４６ａは、プロジェクト開始からの経過日数を示す変数Ｄ_１’を０とする。変化量算出部１４６ａは、変数Ｄ_１’が０の場合、進捗率記憶部１１４ａを参照し、プロジェクトの開始日の進捗率を取得する。変化量算出部１４６ａは、取得した進捗率をプロジェクトの開始日の変化量として変化量記憶部１１６ａに記憶させ、変数Ｄ_１’に１を加算する。変数Ｄ_１’が１以上の場合、変化量算出部１４６ａは、進捗率記憶部１１４を参照し、プロジェクト開始からＤ_１’日目の進捗率Ｂ’［Ｄ_１’］と（Ｄ_１’−１）日目の進捗率Ｂ’［Ｄ_１’−１］とを取得する。変化量算出部１４６ａは、Ｄ_１’日目の進捗率Ｂ’［Ｄ_１’］から（Ｄ_１’−１）日目の消費率Ｂ’［Ｄ_１’−１］を減算し、変化量Ｃ’［Ｄ_１’］を算出する。変化量算出部１４６ａは、算出した変化量Ｃ’［Ｄ_１’］を日付に対応付けて変化量記憶部１１６ａに記憶させ、変数Ｄ_１’に１を加算する。変数Ｄ_１’が示す日数が、進捗率記憶部１１４ａに記憶されている最後の日付の、プロジェクトの開始日からの経過日数よりも大きい場合、変化量算出部１４６ａは、閾値算出部１４７ａに閾値の算出命令を出力する。

以上のように、本実施形態に係るプロジェクト管理装置１００ａの変化量算出部１４６ａは、プロジェクトの進捗の程度を示す進捗率が時系列に記憶されている記憶部１１０ａの変化量記憶部１１６から、２つの時点における進捗率を読み出して、当該読み出した２つの進捗率に基づいて進捗率の変化の程度を示す変化量を算出する。これにより、プロジェクト管理装置１００ａは、変化量を抽出し、当該変化量の日付に基づいてプロジェクトの遅延に関係する進捗報告などを表示し、遅延原因の特定を支援することができる。

なお、変化量の算出には、進捗率、消費率のいずれを利用してもよいが、遅延原因の特定においては、進捗率よりも消費率の利用が適している。それぞれのパラメータの変化が示す内容について説明する。例えば、消費率が前日に比して減少した場合、クリティカルチェーンのタスクが予定より前倒しで進んだことが想定される。例えば、消費率が前日から変化していない場合、クリティカルチェーンのタスクが予定通りに進んだことが想定される。例えば、消費率が前日に比して増加した場合、クリティカルチェーンのタスクが予定より遅れたことが想定される。このように消費率の変化からは、プロジェクトの進捗状況が一意に想定される。

例えば、進捗率が前日に比して減少した場合、クリティカルチェーンのタスクが予定より遅れたことが想定される。例えば、進捗率が前日から変化していない場合、クリティカルチェーンのタスクが予定通りに進んだことが想定される。しかしながら、例えば、進捗率が前日に比して増加した場合は、クリティカルチェーンのタスクが予定より遅れたか、予定通りに進んだか、予定より前倒しで進んだかを判断することができない。このように、進捗率の変化からは、プロジェクトの進捗状況を部分的にしか想定することができない。従って、遅延原因の特定には、消費率の利用が適している。

なお、上述した実施形態におけるプロジェクト管理装置１００、１００ａの一部、例えば、進捗率算出部１４４、消費率算出部１４５、変化量算出部１４６、１４６ａ、抽出部１５０の特殊原因遅延発生日抽出部１５１、類似兆候抽出部１５２をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、プロジェクト管理装置１００、１００ａに内蔵されたコンピュータシステムであって、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

また、上述した実施形態におけるプロジェクト管理装置１００、１００ａの一部、または全部を、ＬＳＩ（Large Scale Integration）等の集積回路として実現してもよい。プロジェクト管理装置１００、１００ａの各機能ブロックは個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。

なお、プロジェクト管理装置１００、１００ａは、プロジェクトの進行中に、それまで蓄積したデータに基づいて、変化量を抽出してもよい。また、プロジェクト管理装置１００、１００ａは、プロジェクトの終了後に、当該プロジェクトの経過の分析のために、変化量を抽出してしてもよい。また、プロジェクト管理装置１００、１００ａは、既に終了した類似プロジェクトの消費率や進捗率の変化量に基づいて閾値を算出し、当該算出された閾値を進行中のプロジェクトに適用することで、変化量を抽出してもよい。

なお、プロジェクト管理装置１００、１００ａの各構成要素は別々の装置に備えられていてもよい。例えば、プロジェクト管理装置１００の各構成要素のうち、操作入力部１２０と表示部１３０とが端末装置に備えられ、他の構成要素がサーバ装置に備えられてもよい。そして、端末装置とサーバ装置とが通信により情報を送受信し、プロジェクト管理装置１００の機能を実現してもよい。また、例えば、プロジェクト管理装置１００の記憶部１１０が別の装置に備えられ、当該装置と通信を行うことにより、プロジェクト管理装置１００の機能を実現してもよい。

なお、進捗率算出部１４４、１４４ａや消費率算出部１４５、１４５ａ、変化量算出部１４６、１４６ａは、日数単位ではなく、例えば、数時間毎、半日毎、２日毎の消費率、進捗率、変化量を算出し、記憶部１１０、１１０ａに記憶させてもよい。また、変化量算出部１４６、１４６ａは、変化量の算出に使用する２つの消費率または進捗率として、例えば、２日置きのものなど、周期的なデータを選択する機能を有していてもよい。また、、工期や作業期間、バッファなどは日数単位でなく、時間単位で管理されてもよい。

なお、閾値および閾値係数は、経験則などに基づき任意に設定されてもよい。また、閾値はプロジェクトの各工程を予定工期内に完了する確率に基づいて算出されるが、所定の範囲内で変更されてもよい。例えば、予定工期の見積りには誤差が想定されるため、「５０％」の確率で見積ったとしても、必ずしも正しく見積れるとは限らない。従って、「５０％」の確立に基づいて設定された閾値係数「２」の場合は、例えば、その０．８倍の「１．６」から１．２倍の「２．４」程度の範囲内で閾値係数を変動させてもよい。また、閾値算出部１４７は、例えば、変化量または変化量の絶対値の中央値、最大値、最小値などの統計量を算出することにより、閾値を算出してよい。

なお、抽出部１５０は、特殊原因遅延発生日抽出部１５１による抽出処理、または類似兆候抽出部１５２による抽出処理のいずれかに基づいて、進捗報告を抽出してもよい。例えば、類似兆候抽出部１５２は、進捗報告記憶部１１３を参照し、同一の担当者、同一のタスク名、同一の報告日が記録された進捗報告が複数ある場合に、その進捗報告を抽出するようにしてよい。また、類似兆候抽出部１５２は、抽出時の条件として、同一の担当者、同一のタスク名、同一の報告日が記録された進捗報告が、例えば、３つ、４つ、…など任意の複数ある場合に、その進捗報告を抽出するようにしてもよい。

１００…プロジェクト管理装置、１１０…記憶部、１１１…プロジェクト情報記憶部、１１２…タスク情報記憶部、１１３…進捗報告記憶部、１１４…進捗率記憶部、１１５…消費率記憶部、１１６…変化量記憶部、１１７…閾値係数記憶部、１１８…閾値記憶部、１１９…特殊原因遅延発生日記憶部、１２０…操作入力部、１３０…表示部、１４１…プロジェクト情報入力制御部、１４２…タスク情報入力制御部、１４３…進捗報告入力制御部、１４４…進捗率算出部、１４５…消費率算出部、１４６…変化量算出部、１４７…閾値算出部、１５０…抽出部、１５１…特殊原因遅延発生日抽出部、１５２…類似兆候抽出部、１６０…生成部、１６１…グラフ生成部、１６２…遅延原因リスト生成部

Claims (6)

1. ＣＣＰＭに基づくプロジェクト管理装置において、
   プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数時点毎に前記消費率の変化の程度を示す変化量を算出する変化量算出部と、
   前記変化量算出部が算出した変化量が所定の閾値を超える時点を抽出する抽出部と、
   を備えることを特徴とするプロジェクト管理装置。
2. 前記プロジェクト管理装置は、
   前記プロジェクトを構成する各工程を予定工期内に完了する確率として予め定められた値と前記変化量算出部が算出した変化量とに基づいて前記所定の閾値を算出する閾値算出部
   を備えることを特徴とする請求項１に記載のプロジェクト管理装置。
3. 前記閾値算出部は、
   前記変化量算出部が算出した変化量の平均値に基づいて前記所定の閾値を算出する
   ことを特徴とする請求項２に記載のプロジェクト管理装置。
4. 前記消費率は、前記複数時点毎の進捗報告に基づいて算出され、
   前記プロジェクト管理装置は、
   前記抽出部が抽出した時点に対応する複数の進捗報告のうち、同一の日付、同一の工程、または同一の担当者についての情報が含まれる複数の進捗報告を抽出する類似兆候抽出部
   を備えることを特徴とする請求項１から３のいずれか一項に記載のプロジェクト管理装置。
5. ＣＣＰＭに基づくプロジェクト管理方法であって、
   変化量算出部が、プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数時点毎に前記消費率の変化の程度を示す変化量を算出する変化量算出過程と、
   抽出部が、前記変化量算出部が算出した変化量が所定の閾値を超える時点を抽出する抽出過程と、
   を有することを特徴とするプロジェクト管理方法。
6. ＣＣＰＭに基づくプロジェクト管理プログラムであって、
   コンピュータに、
   プロジェクトの遅延を吸収するためのバッファの消費の程度を示す消費率が複数時点毎に時系列に記憶されている記憶部から、消費率を読み出し、複数時点毎に前記消費率の変化の程度を示す変化量を算出する変化量算出手順、
   前記変化量算出手順において算出された変化量が所定の閾値を超える時点を抽出する抽出手順、
   を実行させるためのプロジェクト管理プログラム。

Images