クリティカル・パス
Critical Path
「革新的生産スケジューリング入門」第2章講義4

プロジェクト・スケジューリングの理論は、PERT技法と、このクリティカル・パスという概念の発見(発明)からスタートしたと言っていい。PERTは米海軍のポラリス・ミサイル開発の中で生まれ、クリティカル・パスはデュポン社が考え出した。いずれも1950年代の終わりごろ、ほぼ同時期のことである。

PERTは基本的にプロジェクトの期間と見積のための手法であるが、その分析のためにプロジェクトを有向ネットワーク・グラフで表現する。そのグラフにおいて、プロジェクトの始点から終点まで、さまざまなタスクアクティビティ)が網の目のようにつらなっている。つまり始点から終点まで、タスクの組合せにより多数の経路がある。そのすべての経路の中で、最長の経路をクリティカル・パスとよぶ。

クリティカル・パスがなぜ重要かというと、この経路を完遂するのに必要な時間が、プロジェクト全体の開始から終了までの所要時間を決定するからだ。あらゆる経路の中で最長の経路なのだから、当然である。そこで、プロジェクト計画立案においては、これをいかに短縮するかが問題となる。逆にいうならば、クリティカル・パス以外のタスクの所要時間を短縮しても、プロジェクト期間の短縮には貢献しない。

一般に、多数のタスクを持つプロジェクトの場合、クリティカル・パスに属するタスクの比率は1-2割程度しかないと言われている。プロジェクト遂行段階におけるスケジュール・コントロールでは、全体の中で重点を置いて監視すべきタスクは、ほんの一部だけなのである。

最近は進捗管理手法としてアーンドバリュー分析(EVA)が非常に注目を浴びつつあるが、EVAはコストの世界の手法であるため、すべてのタスク要素を積算していく必要がある。したがって手を抜いていい場所がない。ところがクリティカル・パスに注目した進捗管理では、一部のタスクだけ追えばよいことになる。プロジェクト・マネージャの観点から言うと、重点管理が可能だというこの特性は重要だ。

EVAのもう一つの問題点は、進捗度(進捗率ともいう)のごまかしが可能だという点である。かりにクリティカル・パス上のタスクが遅れていても、非クリティカル・パスの達成を前倒しに早めて出来高を稼げば、プロジェクト全体の進捗度は遅れていないように見せかけることができる。しかし、クリティカル・パスに着目した進捗管理では、その場合は明らかに納期遅れが懸念されることになる。

プロジェクト・スケジュール上では、しばしば重要なマイルストーンを定義しておくことが多い。基本設計完了、だとか機材の納品、などである。マイルストーンを予定通り達成できたかも、進捗の大事な指標になる。そのためには、クリティカル・パス上のイベントをマイルストーンとして選んでおく必要がある。

なお、プロジェクト・スケジュールを立案すると、各タスクの最早着手日(EPST)ならびに最遅着手日(LPST)が計算できる。このEPSTとLPSTの差をフロートと呼ぶが、クリティカル・パス上のタスクは、フロート=0になる性質がある。

プロジェクト遂行段階では、クリティカル・パス上のタスクだけを重点管理しておけばよいと書いたが、ただしそこには限界がある。もし、非クリティカル・パスのタスクの実行が遅れて、上記のフロート日数を食いつぶしてしまうと、今度はそのタスクを含む経路がクリティカル・パスになってしまうからである。つまり、クリティカル・パスは、遂行段階では動的に変わっていく可能性を持っているのだ。このように、計画段階のみならず遂行段階においても、クリティカル・パス概念は重要な意義を持っている。

ところで、優れたプロジェクト・マネージャは、マスタ・スケジュールを立案する際に、クリティカル・パスの終点をプロジェクトの最終納期とするような計画はふつう作らない。そんなことをすれば、クリティカル・タスクが少しでも遅れたらプロジェクト全体が沈没してしまうからだ。そのかわりに、クリティカル・パスを短縮する工夫をした上で、その末尾にフロート期間を追加する。これを、プロジェクト・バッファーと呼ぶ。このバッファーの存在がプロジェクト全体を沈没から救ってくれるのである。

余談だが、某・著名プロジェクト・ソフトウェアは、このバッファーを設定するためにプロジェクトの最終期日をずらすと、クリティカル・パスの赤色表示が消えてしまう。どうやら、「始点から終点までの最長の経路」という基本定義を忘れてしまったらしい。このソフトを使ってマスタ・スケジュールを引いていた著者の同僚は、あきれてこう語った。「この会社が出す次期OSのリリースがいつも遅れるのも、無理はないよなあ」