PERT/CPMの実践ガイド｜三点見積もりとクリティカルパスの求め方

「スケジュールに余裕がないのに、次々と差し込み依頼が来る……」
「どこを死守すればプロジェクトは破綻せずに済むのか、客観的な判断基準が欲しい」

現場で日々スケジュールと向き合っていると、想定外のトラブルや遅延は避けて通れません。そんな時、勘や経験といった「個人の感覚」に頼らず、論理的な裏付けを持って判断を下すための手法が「PERT」と「クリティカルパス法（CPM）」です。

今回は、エンジニアの見積もり精度を劇的に上げ、プロジェクトの「命運を握るタスク」を特定するための実践的な使い方を解説します。

この記事でわかること

PERTとCPMの役割と、ネットワーク図の基本
勘から脱却する「三点見積もり」の計算式と、標準値を重視する理由
【図解実践】クリティカルパスとフロート（余裕時間）の求め方（4ステップ）
PMが現場で使える、納期説明やリソース調整のテクニック

PERT/CPMとは何か？
- ネットワーク図の2つの形式（AOAとAON）
エンジニアの信頼を高める「三点見積もり」
- なぜ「単純平均」ではなく標準値を4倍するのか？
クリティカルパス法（CPM）で「死守すべきタスク」を特定する
- クリティカルパスとフロート（余裕時間）とは
実践：クリティカルパスとフロートの求め方（4ステップ）
PMの実務での活用ポイント
まとめ：プロジェクトを「見える化」して守り抜く
あわせて読みたい：要件定義から工程設計へのステップ

PERT/CPMとは何か？

これらは、タスク（アクティビティ）の順序や依存関係を視覚化した「ネットワーク図」を用いて、スケジュールを管理・最適化する手法です。

PERT（パート）： 主に「全体の所要期間がどれくらいになるか」の見積もりに強みを持ちます。
CPM（クリティカルパス法）： 「どこが遅延のデッドラインか」という急所（クリティカルパス）の特定に特化しています。

現代のプロジェクト管理では、これらのお互いの強みを組み合わせて「PERT/CPM」として活用するのが一般的です。

ネットワーク図の2つの形式（AOAとAON）

PERTやCPMでスケジュールを計算する際、タスクのつながりを表す図には「AOA」と「AON」の2つの記述方式があります。

AOA（アクティビティ・オン・アロー）： 矢印（アロー）の上に作業内容を記述します。丸印はイベント（節目）を表します。伝統的なPERT図で使われますが、ダミー作業（点線）が必要になるなど図が複雑になりがちです。
AON（アクティビティ・オン・ノード）： 箱（ノード）の中に作業内容を記述し、矢印は順序のみを表します。現在のプロジェクト管理ツールの主流（PDM）はこちらです。

【AOA（アクティビティ・オン・アロー）のネットワーク図サンプル】

【AON（アクティビティ・オン・ノード）のネットワーク図サンプル】

エンジニアの信頼を高める「三点見積もり」

現場のエンジニアなら、見積もりを出す際に「順調にいけば5日だけど、トラブルがあれば10日かかる」と悩むことが多々あります。PERTでは、この不確実性を考慮して以下の「3つの値」を使います。

見積もりの種類	意味・現場での捉え方
楽観的見積もり（ $a$ ）	すべてがスムーズに進んだ場合の最速タイム
標準的見積もり（ $m$ ）	通常のトラブルを考慮した、最も可能性が高い現実的なタイム
悲観的見積もり（ $b$ ）	最悪の事態を想定した、最大にかかるタイム

これらを以下の式に当てはめて、期待値（ $E$ ）を算出します。

期待値 (E) = \frac{楽観値(a) + 4 \times 標準値(m) + 悲観値(b)}{6}

なぜ「単純平均」ではなく標準値を4倍するのか？

単に3つの数値を足して3で割る「単純平均」では、現場の実態に即したスケジュールは作れません。PERTが「標準値」に4倍の重みを置くのには、実務上の深い理由があります。

「最悪のケース」に引っ張られすぎない: 単純平均だと、1回でも発生する可能性がある「悲観値（最悪の事態）」の数値に全体のスケジュールが大きく引きずられてしまいます。
「いつものパターン」を重視する: 現場で最も起こる確率が高いのは標準値です。ここに重みを置くことで、的中率の高い、納得感のある予測値を導き出せます。
統計的な裏付け: 期間の見積もりは「ベータ分布」に従うことが多く、この式を使うことで数学的にも最も精度の高い期待値を求めることができます。
リスクの幅を可視化する: PERTでは期待値だけでなく、不確実性の幅（標準偏差）も算出できます。「この作業は見積もりのブレが大きいから注意が必要だ」という客観的なリスク評価が可能になります。

クリティカルパス法（CPM）で「死守すべきタスク」を特定する

プロジェクト全体の中で「絶対に遅れが許されないタスク」を特定し、リソースを重点投入すべき場所を明らかにします。

クリティカルパスとフロート（余裕時間）とは

クリティカルパス: プロジェクトのスタートからゴールまで、複数の経路がある中で「最も時間がかかるルート」のことです。このパス上の作業が1日でも遅れると、プロジェクト全体の完了日も確実に1日遅れます。
フロート（バッファ・余裕時間）: 「特定の作業が何日までなら遅れても、全体の完了日に影響を与えないか」という余裕のことです。クリティカルパス上の作業は、このフロートが「ゼロ」の状態です。

実践：クリティカルパスとフロートの求め方（4ステップ）

具体的にどのようにデッドラインを見極めるか、詳細な計算ステップを解説します。

【前提のネットワーク図】 4月1日からプロジェクトを開始し、開始日と終了日には「日付」だけを記述しています（※休日は考慮していません）。

【前提となるネットワーク図（作業A〜G）】

ステップ1：最早開始日・最早終了日を求める（フォワード・パス）

プロジェクトの開始地点から順に、「最速でいつ始められるか」を足し算で計算して前へ進みます。前の作業が複数ある場合（合流地点）は、その中で最も遅い終了日が、次の作業の開始可能日となります。これにより、プロジェクト全体の最短工期が導き出されます。（※今回の図では、最後のアクティビティである作業Fの「12日」が総所要期間になります）

【最早と最遅の開始日・終了日を計算した図】

ステップ2：最遅開始日・最遅終了日を求める（バックワード・パス）

全体の終了日から逆に遡り、「いつまでに始めないと納期に間に合わないか」を引き算で計算して後ろへ戻ります。後ろの作業が複数ある場合（分岐地点）は、その中で最も早い開始日に合わせて計算します。これが、各タスクが許容できる最後限のスケジュールとなります。

ステップ3：フロート（余裕時間）を算出する

以下の式を用いて、各アクティビティにどの程度の「遊び（余裕）」があるかを計算します。

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

アクティビティ	所要期間	最早開始日	最早終了日	最遅開始日	最遅終了日	フロート
作業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

ステップ4：クリティカルパスを特定する

フロートが「0」のアクティビティを線で結びます。これが、プロジェクトの運命を握るクリティカルパスです。

【クリティカルパスを赤線で特定した図】

今回の例では、作業B → 作業D → 作業F のルートがクリティカルパスであることが特定できました。このルート上には一切の余裕がないため、PMは全リソースを注視し、遅延が発生しないよう厳密に管理する必要があります。

PMの実務での活用ポイント

根拠のある納期説明
「順調なら5日ですが、過去の類似トラブルを考慮すると最大10日かかるリスクがあるため、三点見積もりの期待値として6日で設定しています」と伝えることで、ステークホルダーへの説得力と信頼感が格段に高まります。
トラブル時の人員調整（リソース・レベリング）
トラブルが発生した際、フロート（余裕時間）があるタスクから人員を引き抜き、クリティカルパス上のタスクに投入するといった、論理的なリソース調整が可能になります。