PERT（Program Evaluation and Review Technique）とクリティカルパス法（CPM：Critical Path Method）

PERTやクリティカルパス法（CPM）とは

ネットワーク図の一種で、アクティビティ（作業）の順序や依存関係を表した図のことです。アローダイアグラムとも言われます。関連するアクティビティ（作業）との間を線で繋げることで依存関係を表します。

PERTとクリティカルパス法（CPM）はいずれも同時期に開発されたスケジュール管理手法であることから「PERT/CPM」と呼ばれることもあり、PERTはプロジェクト全体の総所要期間の見積もりに、クリティカルパス法（CPM）はクリティカルパス上のアクティビティ（作業）をあぶり出すことを目的に利用します。

総所要期間の見積もり方法、クリティカルパスについては後ほど説明します。

PERTとは、プロジェクトマネジメントの際に用いられる手法の一つ。特定のプロジェクトの完遂までに必要なタスクを洗い出し、相互関係を明確にすることによってプロジェクトを素早く達成することを目的とする。

引用：ウィキペディア｜PERT

クリティカルパス法（CPM）またはクリティカルパス分析（critical path analysis）は、プロジェクトの一連の活動（アクティビティ）をスケジューリングするための数学的アルゴリズムである。効率的プロジェクトマネジメントのための重要なツールである。

引用：ウィキペディア｜クリティカルパス法

ネットワーク図の種類

ネットワーク図には、PERTやクリティカルパス法（CPM）の他にプレシデンスダイアグラム法があります。作業を「アクティビティ」、マイルストーンを「イベント」と言いますが、アクティビティとイベントの表現方法には2種類あります。

AOA：アクティビティ・オン・アロー（activity on arrow）

丸印や四角形をノードと言います。ノードはイベントを表し、アクティビティ（作業）の矢印で繋げます。

AOAのネットワーク図はアローダイアグラムとも呼ばれます。

アクティビティと イベントの扱い	矢印：アクティビティ（作業） ※点線はダミーと言い、所要期間がゼロのアクティビティです。 　下図では作業Aが完了していないと進めないことを意味します。 ノード（丸印や四角形）：イベント
表し方 （図の例）

AON：アクティビティ・オン・ノード（activity on node）

ノードがアクティビティ（作業）になり、アクティビティを矢印で繋ぐことでアクティビティの前後関係を表します。

プレシデンスダイアグラム法はAONに該当し、アクティビティを丸印から四角形に変形したものになります。

アクティビティと イベントの扱い	ノード（丸印や四角形）：アクティビティ（作業） 矢印：アクティビティ間の前後関係
表し方 （図の例）

PERTの目的

それぞれのアクティビティの依存関係を明確にし、最適な順序にアクティビティを並べることが目的です。

プロジェクトの開始から終了までのアクティビティを書き出した管理資料をWBSと言いますが、WBSはアクティビティを階層で書き出したもので、依存関係まではわかりません。

依存関係がシンプルな小規模プロジェクトであればWBSだけでも問題ないかもしれません。ですが、どんなプロジェクトでも、なにかしらアクティビティ間には依存関係があり、守らなければいけない順序があるはずです。

PERTを利用すれば、それぞれのアクティビティの依存関係を明確にすることができ、最適な順番でアクティビティを進めることができます。

もし、あなたのプロジェクトのアクティビティが100以上ある場合、頭の中だけで依存関係を考慮して順序づけするのが難しいことは容易に想像できるのではないでしょうか。

PERTの3点見積もり

PERTでは、楽観的見積もり、標準的見積もり、悲観的見積もりの3つの見積もりを組み合わせて、最も可能性が高い見積もりを算出する3点見積もりという方法があります。

この3つの見積値を以下の計算式に当てはめて見積もりを算出します。

【計算式】全体の所要期間＝(楽観的見積値+4×標準的見積値+悲観的見積値)÷6

上表の例を当てはめると、(50+4×60+100)÷6＝65となり、プロジェクト全体の所要期間は65日と見積もることができます。

このように、プロジェクトのリスク度合いによって標準的見積もり、悲観的見積もり、3点見積もりのいずれを採用するか決めます。ただし、どんなに小さなプロジェクトでもリスクは付きものですので楽観的見積もりは避けるのが無難です。

クリティカルパス法（CPM）の目的

プロジェクトの全作業のうち、最も重要な作業をあぶり出し、重点的に管理するためです。

クリティカルパスとは

プロジェクトの最初の作業から最後の作業までを繋ぐ経路は、作業の依存関係によって複数の経路ができます。その経路のうち、所要期間が最も長くなる経路のことをクリティカルパスと言います。

クリティカルパスの作業はいずれも余裕がなく繋がっています。作業Aが終了後すぐに作業Bを開始し、作業Bが終了後も間を空けずに作業Cを開始するという具合です。

そのため、クリティカルパス上の作業が1つでも遅れると、プロジェクト全体の進捗に影響することになります。まさに、非常に重要（クリティカル）な経路（パス）というわけです。

フロートとは

作業の開始が遅れても、プロジェクトの最終期限に影響しない（最後の作業が遅れない）期間を「フロート」や「スラック」と言います。

また、フロートは下記の式で求めることができ、クリティカルパス上の作業はフロートがゼロになります。

　フロート＝最遅終了日ー最早開始日ー所要期間

フロート (float)またはスラック (slack)は、プロジェクト管理では、プロジェクトネットワーク内のタスクが遅延しても、次の遅延を及ぼさない余裕時間のこと。
　・後続タスクに遅延を及ぼさない（フリーフロート）
　・プロジェクト全体に遅延を及ぼさない（トータルフロート）

引用：ウィキペディア｜フロート (プロジェクト管理)

クリティカルパスとフロートの求め方

準備として、プロジェクトの開始から終了までの各アクティビティを洗い出し、所要期間（所要時間）を見積もる必要があります。

WBSの作業の書き出し方やポイントをこちらで分かりやすく解説していますのでご参照ください。

所要期間が見積もれたら、それぞれのアクティビティの最も早い開始日と終了日、および最も遅い開始日と終了日を求めます。最早開始日と最早終了日、最遅開始日と最遅終了日を求めることでクリティカルパスが明らかになります。

下図を例にクリティカルパスとフロートの求め方を説明します。

前提として、4月1日からプロジェクトを開始し、開始日と終了日には日だけを記述しています。また、休日は考慮していません。

手順は次のようになります。

①全てのアクティビティの最早開始日と最早終了日を求める

プロジェクトの開始から終了に向かってアクティビティをたどります。一番最初のアクティビティの最早開始日は4月1日になります。最早開始日に所要期間を足したものが最早終了日になります。

後続アクティビティは、先行アクティビティの最早終了日の翌日を最早開始日として最早終了日を計算します。以降、同様にして全てのアクティビティの最早開始日と最早終了日を求めていきます。

プロジェクト開始の4月1日から最後のアクティビティの最早終了日（図では作業Fの12日）までの日数が総所要期間になります。

②全てのアクティビティの最遅開始日と最遅終了日を求める

最早開始日と最早終了日が求まったら、今度は逆にプロジェクトの終了から開始に向かってアクティビティをたどります。終了の直前のアクティビティに、①で求めた最早終了日（4月12日）を最遅終了日に設定します。最遅終了日から所要期間を引いたものが最遅開始日になります。

先行アクティビティは、後続アクティビティの最遅開始日の前日を最遅終了日として最遅開始日を計算します。以降、同様にして全てのアクティビティの最遅開始日と最遅終了日を求めていきます。

③全てのアクティビティのフロートを求める

わかりやすいように図のアクティビティを表にします。前述の通り、フロートは下記の式で計算して記述します。

　フロート＝最遅終了日ー最早開始日ー所要期間

③クリティカルパスを特定する

クリティカルパスの作業はいずれも余裕がなく繋がっています。つまり、フロートがゼロのアクティビティがクリティカルパスということです。この例では、作業B、作業D、作業Fがクリティカルパスのアクティビティであることが特定できます。

繰り返しのなりますが、クリティカルパス上の作業が1つでも遅れると、プロジェクト全体の進捗に影響するため、クリティカルパスのアクティビティを把握する必要があるわけです。

スケジュールの立て方について、こちらでスケジュール完成までの6つのステップを解説しています。スケジュール作成に不安のある方はあわせてお読みください。

WBSだけでスケジュールは完成しない！プロジェクトのスケジュールの立て方プロジェクトマネジメントにおいて、WBSの作成はとても重要です。しかし、無事にWBSが完成しても、スケジュールが完成したわけではありません。WBSでは作業の依存関係や順序がわからないためです。作業の依存関係や順序、工数と所要期間、作業の時期と担当者を決めてスケジュールが完成します。ここでは、プロジェクトのスケジュールの立て方を6つのステップでわかりやすく解説します。...

ABOUT ME

hidechi

メーカーに入社し、その後IT部門が分社独立、情報システムエンジニアとして30年以上勤務しています。これまで多くのプロジェクトに携わり、それらの経験から得た知見を覚え書きとして記録することで、厳しい現場で奮闘しているSEの皆さんの一助となれば幸いです。

BLOG：https://oboegakit.blog/self-introduction/