PERT/CPMでプロジェクトの遅延を防ぐ！クリティカルパスの特定と三点見積もりの実践ガイド
「スケジュールに余裕がないのに、次々と差し込み依頼が来る……」
「どこを削って、どこを守ればプロジェクトが破綻せずに済むのか、客観的な判断基準が欲しい」
現場で日々スケジュールと向き合っていると、想定外のトラブルや遅延は避けて通れません。そんな時、どのタスクを死守し、どこなら調整が効くのか。
その判断基準を明確にする「PERT」と「クリティカルパス法（CPM）」について、現場での実践的な使い方を解説します。
PERTやクリティカルパス法（CPM）とは
これらは、タスク（アクティビティ）の順序や依存関係を視覚化した「ネットワーク図」を用いてスケジュールを管理する手法です。一般的に「アローダイアグラム」と呼ばれることもあります。
PERTは主に「全体の所要期間がどれくらいになるか」の見積もりに強みを持ち、CPMは「どこが遅延のデッドライン（クリティカルパス）か」を特定することに特化しています。現代のプロジェクト管理では、これらを組み合わせて「PERT/CPM」として活用するのが一般的です。
ネットワーク図の種類
作業のつながりを表す図には、主に2つの書き方があります。
AOA：アクティビティ・オン・アロー（activity on arrow）
矢印（アロー）の上に作業名を書き、丸印（ノード）でイベントの区切りを表す形式です。
- 矢印： 実際の作業。
- 点線の矢印（ダミー）： 作業時間はゼロですが、順序関係だけを示すために使います。
- 丸印： 作業の結合点（イベント）。
AON：アクティビティ・オン・ノード（activity on node）
ノードの中に作業名を書き、それらを矢印でつなぐ形式です。現在のプロジェクト管理ツール（Microsoft Projectなど）やプレシデンスダイアグラム法（PDM）でよく使われるのはこちらの形式です。
- ノード（箱）： 実際の作業。作業名や期間、担当者などを書き込みます。
- 矢印： 作業の順序関係（依存関係）。
- ダミー作業： 不要。AOAと違い、論理的な矛盾を防ぐためのダミーを置く必要がありません。
直感的で、作業ごとの属性を書き込みやすいのが大きな特徴です。
※プレシデンスダイアグラム法（PDM）の具体的な書き方やルールについては、こちらの記事で詳しく解説しています。
PERTの目的
PERTの最大の目的は、タスク同士の「依存関係」を明確にし、最も効率的な順序を導き出すことです。 WBS（作業分解構成図）でタスクを洗い出しただけでは、「Aが終わらないとBに取り掛かれない」といった前後の縛りが見えにくいものです。大規模なプロジェクトになればなるほど、この「つながり」を整理せずにスケジュールを引くと、後から必ず矛盾が生じてしまいます。
PERTの三点見積もり
現場のエンジニアなら、見積もりを出す際に「順調にいけば5日だけど、トラブルがあれば10日かかる」と悩むことが多々あるはずです。PERTでは、そうした不確実性を考慮して以下の3つの値を使います。
| 見積もり種類 | 意味 |
|---|---|
| 楽観的見積もり（a） | 全てがスムーズに進んだ場合の最速タイム |
| 標準的見積もり（m） | 通常のトラブルを考慮した、最も可能性が高い現実的なタイム |
| 悲観的見積もり（b） | 最悪の事態を想定した、最大にかかるタイム |
これらを以下の式に当てはめて、期待値（E）を算出します。
期待値 (E) =（a + 4m + b）÷ 6
なぜ単純な平均（3で割る）ではいけないのか？
「最高＋現実＋最悪」を足して3で割る「単純平均」では、悲観的な数値（最悪のケース）の影響を強く受けすぎてしまうからです。
例えば、「通常5日、最高4日、最悪20日」というタスクがあった場合、単純平均だと8日になります。しかし、実際には20日かかるのは極めて稀なケースであり、最初からスケジュールを8日と引いてしまうと、今度は逆に「余裕がありすぎてダラダラしてしまう（学生症候群）」のリスクが生まれます。
そこでPERTでは、最も確率が高い「標準値（m）」に4倍の重みをつけ、合計6で割ります。これにより、「現実的に起こりやすい5日」という感覚を大切にしつつ、最悪の事態への備えもわずかに加味した、「最も的中率が高い予測値」を導き出しているのです。
現場での活用ポイント
「5日で終わります！」と断言して、結局トラブルで8日かかってしまうと信頼を失います。一方で、最初からリスク全振りの「10日」と言うと、今度は期限ギリギリまで着手しないという心理的な油断を招く原因にもなります。
この三点見積もりで「最悪のケース（悲観値）」をあらかじめ合意しておけば、単なる勘ではなく、リスクの振れ幅を考慮した説明ができるようになります。「順調なら5日ですが、過去の類似トラブルを考慮すると最大10日かかるリスクがあるため、期待値として6日で設定しています」と伝えることで、ステークホルダーへの説得力と信頼感が格段に高まります。
クリティカルパス法（CPM）の目的
プロジェクト全体の中で「絶対に遅れが許されないタスク」を特定し、リソース（人員や時間）を重点的に投入するべき場所を明らかにすることが目的です。
クリティカルパスとは
プロジェクトのスタートからゴールまで、複数の経路がある中で「最も時間がかかるルート」のことです。 このパス上の作業が1日でも遅れると、プロジェクト全体の完了日も1日遅れます。文字通り「クリティカル（致命的）」な経路です。逆に言えば、ここに含まれない作業には、多少の「余裕」があることになります。
フロートとは
「特定の作業が何日までなら遅れても、プロジェクト全体の完了日に影響を与えずに済むか」という余裕時間のことを「フロート（またはスラック）」と呼びます。
クリティカルパス上の作業は、このフロートが「ゼロ」の状態です。リーダーとしては、常に「どのタスクにどれくらいのフロートがあるか」を把握しておくことで、トラブル時の人員調整（リソース・レベリング）が可能になります。
クリティカルパスとフロートの求め方
具体的な求め方を解説します。まずはWBSでタスクを出し、それぞれの期間を見積もっておく必要があります。
※WBSの基本から、作業を漏れなく書き出すための具体的な手法をこちらで解説していますので、あわせてご参照ください。
所要期間が見積もれたら、それぞれのアクティビティの最も早い開始日と終了日、および最も遅い開始日と終了日を求めます。最早開始日と最早終了日、最遅開始日と最遅終了日を求めることでクリティカルパスが明らかになります。
下図を例にクリティカルパスとフロートの求め方を説明します。
【前提】
4月1日からプロジェクトを開始し、開始日と終了日には日だけを記述しています。また、休日は考慮していません。
①全てのアクティビティの最早開始日と最早終了日を求める
プロジェクトの開始から終了に向かってアクティビティをたどります。一番最初のアクティビティの最早開始日は4月1日になります。最早開始日に所要期間を足したものが最早終了日になります。
後続アクティビティは、先行アクティビティの最早終了日の翌日を最早開始日として最早終了日を計算します。以降、同様にして全てのアクティビティの最早開始日と最早終了日を求めていきます。
プロジェクト開始の4月1日から最後のアクティビティの最早終了日（図では作業Fの12日）までの日数が総所要期間になります。
②全てのアクティビティの最遅開始日と最遅終了日を求める
最早開始日と最早終了日が求まったら、今度は逆にプロジェクトの終了から開始に向かってアクティビティをたどります。
終了の直前のアクティビティに、①で求めた最早終了日（4月12日）を最遅終了日に設定します。最遅終了日から所要期間を引いたものが最遅開始日になります。
先行アクティビティは、後続アクティビティの最遅開始日の前日を最遅終了日として最遅開始日を計算します。以降、同様にして全てのアクティビティの最遅開始日と最遅終了日を求めていきます。
③全てのアクティビティのフロートを求める
わかりやすいように図のアクティビティを表にします。前述の通り、フロートは下記の式で計算して記述します。
フロート＝最遅終了日ー最早開始日ー所要期間
| アクティビティ | 所要期間 | 最早開始日 | 最早終了日 | 最遅開始日 | 最遅終了日 | フロート |
|---|---|---|---|---|---|---|
| 作業A | 6日 | 4月1日 | 4月6日 | 4月5日 | 4月10日 | 4 |
| 作業B | 3日 | 4月1日 | 4月3日 | 4月1日 | 4月3日 | 0 |
| 作業C | 2日 | 4月1日 | 4月2日 | 4月5日 | 4月6日 | 4 |
| 作業D | 7日 | 4月4日 | 4月10日 | 4月4日 | 4月10日 | 0 |
| 作業E | 3日 | 4月3日 | 4月5日 | 4月7日 | 4月9日 | 4 |
| 作業F | 2日 | 4月11日 | 4月12日 | 4月11日 | 4月12日 | 0 |
| 作業G | 3日 | 4月6日 | 4月8日 | 4月10日 | 4月12日 | 4 |
③クリティカルパスを特定する
クリティカルパスの作業はいずれも余裕がなく繋がっています。つまり、フロートがゼロのアクティビティがクリティカルパスということです。
この例では、作業B、作業D、作業Fがクリティカルパスのアクティビティであることが特定できます。
まとめ：プロジェクトを「見える化」して守り抜く
PERT/CPMは、単なる管理理論ではなく、現場で「どこに注力すべきか」を判断し、チームを迷わせないための強力な武器になります。
- 根拠のある見積もり： 三点見積もりを使うことで、担当者の「勘」を組織の「予測」に変えることができます。
- リスクの特定： クリティカルパスを明確にすれば、トラブル時に「絶対に死守すべきポイント」にリソースを集中投下できます。
- 柔軟な調整： フロート（余裕）を把握しておくことで、急な割り込み案件にも「いつから着手可能か」を論理的に回答できるようになります。
まずは身近な小規模案件から、ネットワーク図を書いてタスクの「つながり」を意識することから始めてみてください。その一歩が、厳しい現場を切り抜ける確かな力になるはずです。
