JP2012058867A - 工程管理方法、および情報処理装置 - Google Patents

Abstract

【課題】マイルストーンの遅延リスクを把握することが可能な工程管理方法、および情報処理装置を提供する。
【解決手段】互いに依存関係にある複数の作業工程によって定義されるプロジェクトの工程を管理する工程管理方法であって、作業工程の工期と作業工程の進捗情報との入力を受け付ける入力受付ステップと、受け付けられた工期と進捗情報とに基づいて、工期の遅れを吸収するためのマイルストーンバッファの消費期間および工期の進捗率を算出し、算出した消費期間のマイルストーンバッファに対する消費率と進捗率とを出力する算出ステップと、を含む。
【選択図】図５

Description

本発明は、マイルストーンの進捗状況を可視化した工程管理方法および情報処理装置に関するものである。

プロジェクト等の作業の工程を管理する方法には様々な方法がある。例えば、特許文献１及び特許文献２には、アローダイアグラムやガントチャート等の工程表によって工程を管理する技術が開示されている。

近年、イスラエルのゴールドラット博士により、ＣＣＰＭ(Critical Chain Project Management)と呼ばれる新しい工程管理方法が提唱されている。このＣＣＰＭは、プロジェクト管理のグローバールスタンダートであるＰＭＢＯＫにも取り上げられている（例えば、非特許文献１及び非特許文献２）。

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

Critical Chain, 1997, Eliyahu M. Goldratt、ISBN: 978-0884271536（URL http://en.wikipedia.org/wiki/Eliyahu_M._Goldratt） ＰＭＢＯＫガイド 第４版、Project Management Institute,Inc（URL http://www.pmi.org）

上述した各種の方法では、プロジェクト進行途中に遅延が許されないマイルストーンを有するプロジェクトの納期遅延を防止することは可能であるが、マイルストーンの遅延を防止することができないという問題があった。

例えば、ＣＣＰＭの工程管理手法を用いることにより、プロジェクトの最終的な納期に対する進捗状況は、プロジェクトバッファの消費状況をグラフ化することによって可視化することができる。しかし、プロジェクトの途中のマイルストーンに対する遅れは、プロジェクトバッファが消費されない場合があり、プロジェクトバッファの監視だけではマイルストーンの遅延リスクを把握することができないという問題があった。

図９は、マイルストーンを有するプロジェクトについて、従来のＣＣＰＭ工程管理手法に基づいて計画した工程表の例を示す図である。図９に示すように、ｗ１〜ｗ６はプロジェクトを構成する作業(タスク)であり、ＰＢはＣＣＰＭのプロジェクトバッファであり、ＦＢはＣＣＰＭの合流バッファであり、ｔ０はプロジェクトの納期であり、ｔ１はマイルストーンの期日を示している。また、各タスクの依存関係を矢印で表すとともに、このプロジェクトの例では、ｗ１→ｗ２→ｗ３→ｗ４がクリティカルチェーンであり、ｗ１→ｗ５→ｗ６がマイルストーンの期日t1までに完了させる必要があるタスクであることを示している。

図１０は、図９に示したプロジェクトの進行途中におけるＣＣＰＭ工程表を示す図である。図１０に示す例では、進捗管理日t2の日付においてタスクｗ１、ｗ２、ｗ５は完了しているが、タスクｗ３とｗ６は仕掛中であることを示している。

ＣＣＰＭでは、タスクの進捗に伴う、プロジェクトバッファの消費量の推移をグラフ化することによってプロジェクトの納期遅延リスクを捉えることができる。しかし、この例ではタスクｗ５、ｗ６の遅れはプロジェクトバッファに何ら影響を与えていないため、マイルストーンの期日t1に遅れる予兆を見過ごしてしまう懸念がある。

一般に、プロジェクトバッファの終了日は、プロジェクトの納期と一致する。計画立案時のプロジェクトバッファの位置は、プロジェクトの納期を変更しない限り不変であるため、タスクの遅れが生じた場合には、プロジェクトバッファを消費する形でその遅れを吸収する。

例えば、合流バッファは、非クリティカルチェーンのタスクがクリティカルチェーンに合流する位置に置かれ、非クリティカルチェーンのタスクの遅れに伴って位置が移動する性質がある。合流バッファの移動によって、クリティカルチェーンに遅れの影響が出る場合は、合流バッファを消費する形で遅れを吸収する。合流バッファがすべて消費しつくされた場合は、合流するクリティカルチェーンのタスクに遅延を引き起こし、以下後続するタスクも連鎖的に遅延が生じ、クリティカルチェーンの遅延はプロジェクトバッファを消費する形で吸収する。

図１０に示した例では、タスクｗ５、ｗ６の遅れに伴って、合流バッファは右にシフトしたものの、プロジェクトバッファを侵食するほどには至っていない。つまり、ＣＣＰＭのプロジェクトバッファは、プロジェクト進行途中のマイルストーンの遅れをとらえることができないという問題があった。

本発明は、上記に鑑みてなされたものであって、マイルストーンの遅延リスクを把握することが可能な工程管理方法、および情報処理装置を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明にかかる工程管理方法は、互いに依存関係にある複数の作業工程によって定義されるプロジェクトの工程を管理する工程管理方法であって、前記作業工程の工期と前記作業工程の進捗情報との入力を受け付ける入力受付ステップと、受け付けられた前記工期と前記進捗情報とに基づいて、前記工期の遅れを吸収するためのマイルストーンバッファの消費期間および前記工期の進捗率を算出し、算出した前記消費期間の前記マイルストーンバッファに対する消費率と前記進捗率とを出力する算出ステップと、を含むことを特徴とする。

また、本発明は、上記工程管理方法を実行する情報処理装置である。

本発明によれば、マイルストーンの遅延リスクを把握することが可能な工程管理方法、および情報処理装置を提供することができる。

本発明の実施の形態にかかるコンピュータの構成を示すブロック図である。 図１Ａに示したコンピュータの入出力構成を示す図である。 入力受付部が受け付け、記憶部が記憶するタスク定義情報（タスク定義テーブル）の例を示す図である。 入力受付部が受け付け、記憶部が記憶する進捗情報（進捗テーブル）の例を示す図である。 本実施の形態におけるＣＣＰＭ工程管理手法に基づいて計画したＣＣＰＭ工程表の例を示す図である。 マイルストーンバッファを有するプロジェクトの進行途中のＣＣＰＭ工程表の例を示す図である。 マイルストーンバッファの消費状況の推移を示すグラフである。 コンピュータにおいて行われるマイルストーンバッファを有するＣＣＰＭ工程表を作成する処理の処理手順を示すフローチャートである。 マイルストーンバッファを有するＣＣＰＭ工程表による進捗管理の処理手順を示すフローチャートである。 マイルストーンを有するプロジェクトについて、従来のＣＣＰＭ工程管理手法に基づいて計画した工程表の例を示す図である。 図９に示したプロジェクトの進行途中におけるＣＣＰＭ工程表を示す図である。

以下に添付図面を参照して、本発明にかかる工程管理方法、および情報処理装置の実施の形態を詳細に説明する。

図１Ａは、本発明の実施の形態にかかるコンピュータ１０００の構成を示すブロック図である。図１Ａに示すように、コンピュータ１０００は、入力受付部１１０と、表示部１２０と、記憶部１３０と、算出部１４０とを含んで構成されている。

図１Ｂは、上述したコンピュータ１０００の入出力構成を示す図である。図１Ｂに示すように、入力受付部１１０が、表示部１２０に表示されたプロジェクトの日程計画を定義するためのタスク定義画面からタスクの定義の入力を受け付け、各タスクの見通しを報告する進捗入力画面から各タスクの進捗状況の入力を受け付けると、受け付けられたこれらのデータ（工程表ファイル）を、算出部１４０が記憶部１３０に記憶する。そして、算出部１４０は、工程表ファイルに格納されているデータを用いて、ＣＣＰＭ工程表を出力し、あるいはバッファの消費状況の推移を示した進捗グラフを出力する機能を有し、プロジェクトバッファ以外にマイルストーンバッファの進捗グラフを出力することが可能となっている。これらの各機能の具体的な処理についてはフローチャートを用いて後述する。続いて、上述したコンピュータ１０００を構成する各部について説明する。

入力受付部１１０は、例えば、キーボードやマウス等の入力装置である。入力受付部１１０は、ユーザからプロジェクトを構成する作業（タスク）の定義、タスクまたはプロジェクトの進捗状況の入力を受け付ける。

表示部１２０は、例えば、ＬＣＤ（Liquid Crystal Display）等の表示装置である。表示部１２０は、入力受付部１１０が入力を受け付けたタスクの定義、タスクまたはプロジェクトの進捗状況を入力するための画面、あるいは後述する算出部１４０によってタスクまたはプロジェクトの進捗状況を示すグラフ（進捗グラフ）やＣＣＰＭ工程表を表示する。

記憶部１３０は、例えば、ＨＤＤ（Hard Disk Drive）等の記憶装置である。記憶部１３０は、入力受付部１１０が受け付けたタスクの定義やタスクまたはプロジェクトの進捗状況、あるいは進捗グラフに表示するための領域（後述）の境界を記憶する。

図２は、入力受付部１１０が受け付け、記憶部１３０が記憶するタスク定義情報（タスク定義テーブル）の例を示す図である。図２に示すように、タスク定義テーブルは、タスクを識別するためのタスク識別ＮＯと、タスク名と、日数と、先行タスクＮＯとが対応付けて記憶されている。

図２に示す例では、１つのプロジェクトにタスクＮＯ１〜６までのタスクが存在し、タスク名がｗ１〜ｗ６までの各タスクの予定工期は、それぞれ１５日、１８日、１２日、１３日、８日、６日であり、タスクｗ２およびｗ５は先行タスクとしてｗ１が存在し、タスクｗ３は先行タスクとしてｗ２が存在し、タスクｗ４は先行タスクとしてｗ３が存在し、タスクｗ６は先行タスクとしてｗ５が存在することを示している。このように、タスク定義テーブルでは、各タスク間の依存関係が定義されている。

図３は、入力受付部１１０が受け付け、記憶部１３０が記憶する進捗情報（進捗テーブル）の例を示す図である。図３に示すように、進捗テーブルは、上述したタスク識別ＮＯと、タスク名と、残日数とが対応付けて記憶されている。

図３に示す例では、仕掛中のタスクとしてタスクｗ３およびｗ６があり、各タスクが終了する見通しを示す残日数は、それぞれ１３日、１１日であることを示している。後述するように、算出部１４０は、進捗テーブルのデータを参照して、未着手のタスクの実施予定日や終了日、プロジェクトバッファの消費、マイルストーンバッファの消費日数の計算を行う。

図４は、本実施の形態におけるＣＣＰＭ工程管理手法に基づいて計画したＣＣＰＭ工程表の例を示す図である。図４に示すように、ＣＣＰＭ工程表には、従来の工程表にはないマイルストーンバッファ（ＭＢ）が追加されている。

図４に示すＣＣＰＭ工程表では、マイルストーンバッファの終了日はマイルストーンの期日t1と一致させている。また、マイルストーンバッファの長さは、マイルストーンバッファに先行するタスクの計画日数に応じて設定することができる。

例えば、図４に示したタスクｗ１、ｗ５、ｗ６のそれぞれの予定工期が１０日である場合、これらのタスクの合計の予定工期３０日の半分（１５日）をマイルストーンバッファの長さとして設定する。そして、予定工期が２日遅れた場合には、２日分の遅れが生じていることを示すマークを、マイルストーンバッファのうち、２／１５の範囲だけに色付けする等して視覚的に分ける。このように、マイルストーンバッファの位置は不動とし、先行するタスクの遅れを、マイルストーンバッファを消費する形で吸収する。

図５は、マイルストーンバッファを有するプロジェクトの進行途中のＣＣＰＭ工程表の例を示す図である。図５に示す例では、ＣＣＰＭ工程表に示された進捗管理日ｔ２の日付においてタスクｗ１、ｗ２、ｗ５は完了し、タスクｗ３およびｗ６は仕掛中であることを示している。この場合、タスクｗ５およびｗ６の遅れによって、マイルストーンバッファが消費され、マイルストーンバッファの中の他の部分とは異なるように色づけされた状態となっている。

本実施の形態におけるＣＣＰＭ工程表ではプロジェクトバッファの消費状況の推移をグラフ化することにより、遅延リスクを可視化することも可能である。遅延リスクを可視化することによって、タスクの遅延に対して早期に適切な対策を講じることが可能となり、プロジェクトの納期遅延を防止することができる。本実施の形態におけるＣＣＰＭ工程表では、この考えをマイルストーンバッファにも応用して、プロジェクト進行途中の重要なマイルストーンの遅延防止を図っている。このように、マイルストーンバッファおよびプロジェクトバッファの進捗状況を組み合わせて管理することによって、よりきめ細やかな工程管理が可能となる。

図６は、マイルストーンバッファの消費状況の推移を示すグラフである。図６では、横軸をプロジェクトの進捗率とし、縦軸をマイルストーンバッファの消費率とした場合の例を示している。また、図６に示すグラフにおいて、全体の領域を３つの領域（安全域、警告域、危険域）に区分し、ユーザがプロジェクトの進捗状況を一目で認識することが可能となっている。

ここで、安全域とは、プロジェクトの計画が順調に進行していることを示す領域であり、この領域にプロットされている場合には、ユーザは特にプロジェクトの計画を変更する等の対策は不要である。また、警告域とは、プロジェクトの計画に遅れが生じる可能性のある領域であり、この領域にプロットされている場合には、ユーザはプロジェクトの計画を安全域に移行させるための回復計画を策定する等の措置が必要となる。さらに、危険域とは、既にプロジェクトの計画に遅れが生じている領域であり、この領域にプロットされている場合には、ユーザはプロジェクトの計画を警告域または安全域に移行させるために、あらかじめ策定された回復計画にしたがって対策を講じてプロジェクトの遅れを回復させる。なお、各領域の境界は、あらかじめユーザによって定められるが、プロジェクトの特性に応じて適宜変更することも可能である。

算出部１４０は、工程表ファイルに格納されているデータを用いて、未着手のタスクの実施予定日や終了日、プロジェクトバッファの消費、マイルストーンバッファの消費日数を計算し、進捗グラフやＣＣＰＭ工程表を出力するものである。この算出部１４０が行う具体的な処理については、フローチャートを用いて後述する。

算出部１４０が、後述する各処理を行うことによって、マイルストーンバッファに影響を与えるタスクの全体進捗率と、マイルストーンバッファの消費率をグラフにプロットするので、ユーザは定期的に各タスクの進捗の見通しを確認し、進捗の管理日時点で、プロットの位置する領域に応じた対策を講じることができる。

また、マイルストーンバッファの消費状況を監視することにより、プロジェクト全体の遅れの予兆を捉え、対策を打つべきタイミングが誰にでも明白になり、容易にその状況を把握することが可能となる。さらに、このような工程管理方法によってプロジェクトの進捗を管理することによって、無駄な原価を発生させることなく、マイルストーンの遅延を防止することができる。

なお、プロジェクトが完了した際に、バッファ消費率および進捗率のいずれもが１００％となる位置にプロットされた場合（Ｐ１）には、プロジェクトは計画通りに終了したことを表し、プロジェクトが完了した際に、進捗率が１００％であるがバッファ消費率が１００％を超えている位置にプロットされた場合（Ｐ２）には、プロジェクトは計画から遅れて終了したことを表すこととなる。一方、プロジェクトが完了した際に、進捗率が１００％であるがバッファ消費率が１００％に満たない位置にプロットされた場合（Ｐ３）には、プロジェクトは計画より早く終了したことを表すこととなる。続いて、マイルストーンバッファを有するＣＣＰＭ工程表を作成する処理について説明する。

図７は、コンピュータ１０００において行われるマイルストーンバッファを有するＣＣＰＭ工程表を作成する処理の処理手順を示すフローチャートである。以下に示す処理は、ユーザ（例えば、プロジェクトマネージャ）が、図１Ｂに示したＣＣＰＭ工程管理システムにおいて、タスク定義画面から入力された情報にしたがって、ＣＣＰＭ工程表を作成する手順を示したものでもある。

図７に示すように、入力受付部１１０が、タスク定義画面から入力された情報の入力を受け付けると、算出部１４０は、図２に示したタスク定義テーブルを参照し、各タスク間の依存関係と各タスクの計画工期とを読み取り、最も作業期間が長くなるタスクの流れをクリティカルチェーンとして識別する（ステップＳ７０１）。

例えば、図２に示した例では、算出部１４０は、互いに依存関係のあるタスクｗ１〜ｗ４までの日数の合計が５８日であり、最も作業期間が長くなるタスクの流れであるため、この流れをクリティカルチェーンとして識別する。

そして、算出部１４０は、識別したクリティカルチェーンの長さを元にプロジェクトバッファの長さ（日数）を決定する。算出部１４０は、識別したクリティカルチェーンに一定の比率（ここでは、バッファ率と呼ぶ。）を乗じた長さを、クリティカルチェーンの長さとして算出し、プロジェクトバッファの終了日がプロジェクトの納期と一致するように、プロジェクトバッファを配置する（ステップＳ７０２）。なお、このバッファ率は、プロジェクトの特性に応じて決定するものとする。

その後、算出部１４０は、あらかじめ定められたプロジェクト開始日からクリティカルチェーンの各タスクを順番に実行するように（すなわち、先行タスクの終了日が後続タスクの開始日と一致するように）、各タスクを配置する（ステップＳ７０３）。

算出部１４０は、各タスクを配置すると、マイルストーンに影響を与えるタスクの長さにバッファ率を乗じて、マイルストーンバッファの長さを決定し、マイルストーンバッファの終了日がマイルストーンの期日と一致するように、マイルストーンバッファを配置する（ステップＳ７０４）。

そして、算出部１４０は、非クリティカルチェーンの長さ（例えば、図２に示したタスクｗ５、ｗ６の長さ１４日）にバッファ率を乗じて合流バッファの長さを決定し、合流バッファをクリティカルチェーンへ合流する場所に配置する（ステップＳ７０５）。このとき、算出部１４０は、非クリティカルチェーンのタスクを、合流バッファの左側に配置する。ただし、マイルストーンに影響を与えるタスクについては、マイルストーンバッファに対しても、その左側の位置となるように配置する。

その後、算出部１４０は、それぞれのバッファの長さ分の余裕が確保できない場合は、バッファを消費した計画として、プロジェクトの計画を作成する（ステップＳ７０６）。このステップＳ７０６の処理が終了すると、図７に示した全ての処理が終了する。続いて、マイルストーンバッファを有するＣＣＰＭ工程表による進捗管理の手順について説明する。

図８は、マイルストーンバッファを有するＣＣＰＭ工程表による進捗管理の処理手順を示すフローチャートである。以下に示す処理は、図７に示した場合と同様に、プロジェクトマネージャ等のユーザが、図１Ｂに示すＣＣＰＭ工程管理システムを利用して進捗管理する手順を示したものでもある。

図８に示すように、入力受付部１１０は、定期的に図３に示した進捗入力画面から入力された仕掛中のタスクの見通しを示す残日数の入力を受け付ける（ステップＳ８０１）。

算出部１４０は、受け付けられた仕掛中のタスクの残日数を、ステップＳ７０３およびＳ７０６で配置された後続するタスクの開始日に加算することによって、後続するタスクの予定開始日・終了日を計算し（ステップＳ８０２）、各タスクの遅れに伴って、影響を受けるバッファの消費日数を計算する（ステップＳ８０３）。

そして、算出部１４０は、プロジェクトバッファとマイルストーンバッファの個々のバッファごとに、後述するステップＳ８０５からＳ８０９までの処理を繰り返す（ステップＳ８０４）。

算出部１４０は、当該バッファに影響を与えるタスクの進捗率と当該バッファの消費率とを算出し、図６に示した進捗グラフにプロットして表示部１２０に表示させる(ステップＳ８０５)。例えば、算出部１４０は、あらかじめ定められたタスクの工期に対する入力受付部１１０が受け付けた残日数の割合を算出することによって、上記タスクの進捗率を算出する。

その後、算出部１４０は、ステップＳ８０５でプロットした値（すなわち、現在の進捗状況）が危険領域にプロットされているか否かを判定し（ステップＳ８０６）、現在の進捗状況が危険領域にプロットされていると判定した場合（ステップＳ８０６；Ｙｅｓ）、あらかじめ策定した対策を実施するためのアラーム（警告メッセージ）を出力する（ステップＳ８０７）。

一方、算出部１４０は、現在の進捗状況が危険領域にプロットされていないと判定した場合（ステップＳ８０６；Ｎｏ）、さらに、現在の進捗状況が警告領域にプロットされているか否かを判定し（ステップＳ８０８）、現在の進捗状況が警告領域にプロットされていると判定した場合（ステップＳ８０８；Ｙｅｓ）、危険領域になった際に実施すべき対策を事前に策定するためのアラーム（警告メッセージ）を出力する（ステップＳ８０９）。このように、ステップＳ８０７またはＳ８０９においてアラームを出力されると、プロジェクトマネージャ等のユーザは、上述した対策を実施し、または策定することとなる。

ステップＳ８０８において、算出部１４０が、現在の進捗状況が警告領域にプロットされていないと判定した場合（ステップＳ８０８；Ｎｏ）、何もせずにステップＳ８１０に進み、以降、ステップＳ８０５からＳ８０９までの処理を繰り返す（ステップＳ８１０）。このステップＳ８１０の処理が終了すると、図８に示した全ての処理が終了する。

このように、互いに依存関係にある複数の作業工程によって定義されるプロジェクトの工程を管理する工程管理方法において、入力受付部１１０が、タスクの工期とタスクの進捗情報との入力を受け付け、算出部１４０が、受け付けられた工期と進捗情報とに基づいて、工期の遅れを吸収するためのマイルストーンバッファの消費期間および工期の進捗率を算出し、算出した消費期間のマイルストーンバッファに対する消費率と進捗率とを出力するので、マイルストーンの遅延リスクを把握することが可能となる。

具体的には、マイルストーンの期日を守るためのマイルストーンバッファをＣＣＰＭ工程表に設置し、マイルストーンバッファの消費状況をグラフ化することにより進捗状況を可視化しているので、マイルストーンバッファの消費状況をもとに、遅延の予兆をつかみ、先手で対策をとることにより、マイルストーンの遅延も防止することが可能となる。

すなわち、従来のＣＣＰＭ工程表では、プロジェクトバッファの消費状況をグラフ化することにより、現在の進捗状況（安全、警告、危険）を把握できるが、中間リリース等、プロジェクト途中の重要なマイルストーンの遅延は、このプロジェクトバッファの状況で必ずしも「警告や危険」とならない場合があったが、本実施の形態におけるＣＣＰＭ工程表では、マイルストーン毎にマイルストーンバッファを設置し、この消費状況をプロジェクトバッファと同様に監視することにより、プロジェクト全体の進捗を把握しつつ、マイルストーンの遅延も防止することができる。

なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。

１０００ コンピュータ
１１０ 入力受付部
１２０ 表示部
１３０ 記憶部
１４０ 算出部
Ｐ１ Ｐ２ Ｐ３ プロット値。

Claims (6)

1. 互いに依存関係にある複数の作業工程によって定義されるプロジェクトの工程を管理する工程管理方法であって、
   前記作業工程の工期と前記作業工程の進捗情報との入力を受け付ける入力受付ステップと、
   受け付けられた前記工期と前記進捗情報とに基づいて、前記工期の遅れを吸収するためのマイルストーンバッファの消費期間および前記工期の進捗率を算出し、算出した前記消費期間の前記マイルストーンバッファに対する消費率と前記進捗率とを出力する算出ステップと、
   を含むことを特徴とする工程管理方法。
2. 前記算出ステップにおいて、出力した前記消費率と前記進捗率とに基づいて、前記プロジェクトの進捗状況を示すグラフを生成し、生成した前記グラフを表示部に表示させる、
   ことを特徴とする請求項１に記載の工程管理方法。
3. 前記グラフは、前記プロジェクトが順調に進行していることを示す安全域と、前記プロジェクトに遅れが生じる可能性のあることを示す警告域と、前記プロジェクトに既に遅れが生じていることを示す危険域とに分けられ、
   前記算出部は、算出した前記消費率と前記進捗率とが前記警告域にある場合には、前記プロジェクトを前記安全域に移行させるために、所定の回復計画を策定する旨のメッセージを出力し、算出した前記消費率と前記進捗率とが前記危険域にある場合には、前記プロジェクトを前記警告域または前記安全域に移行させるために、前記所定の回復計画にしたがって所定の対策を講じさせる旨のメッセージを出力する、
   ことを特徴とする請求項１または２に記載の工程管理方法。
4. 前記算出ステップにおいては、前記工期と前記進捗情報とに基づいて、前記プロジェクトに含まれる前記作業工程の進捗状況を示す工程表を出力する、
   ことを特徴とする請求項１〜３のいずれか１項に記載の工程管理方法。
5. 前記入力受付ステップにおいては、前記工期と前記進捗情報とを前記表示部を介して受け付ける、
   ことを特徴とする請求項２〜４のいずれか１項に記載の工程管理方法。
6. 互いに依存関係にある複数の作業工程によって定義されるプロジェクトの工程を管理することが可能な情報処理装置であって、
   前記作業工程の工期と前記作業工程の進捗情報との入力を受け付ける入力受付部と、
   前記入力受付部が受け付けた前記工期と前記進捗情報とに基づいて、前記工期の遅れを吸収するためのマイルストーンバッファの消費期間および前記工期の進捗率を算出し、算出した前記消費期間の前記マイルストーンバッファに対する消費率と前記進捗率とを出力する算出部と、
   を備えたことを特徴とする情報処理装置。

Images