情報管理技術士 学習ノート
← 一覧へ
プロジェクト・組織管理
#PERT#CPM#주공정법#여유시간#일정단축
最終更新 · 2026-09-30

PERT/CPM(スケジュールネットワーク分析・クリティカルパス法)

1. 概要

A. 定義

PERT/CPMとは、プロジェクトを構成するアクティビティ(Activity)とその先行後続関係をネットワーク(グラフ)で表現し、各アクティビティの所要期間を用いて前進・後退計算によりフロート(Float)とクリティカルパス(Critical Path)を導出することで、全体スケジュールの最短完了期間と統制の優先順位を定量的に算出するスケジュールネットワーク分析技法である。CPM(Critical Path Method、クリティカルパス法)はアクティビティ期間を確定値とみなす決定論的技法であり、PERT(Program Evaluation and Review Technique)は期間を三点見積り(3-point estimate)で扱う確率論的技法である。

両技法が強力である根本的な理由は、「どの作業が遅れるとプロジェクト全体が遅れるか」を明確に見分ける点にある。プロジェクトには数十〜数百のアクティビティが並列・直列に絡み合っており、単にアクティビティ一覧と期間を並べるだけでは「今どこに管理資源を集中すべきか」が分からない。PERT/CPMはアクティビティ間の依存関係をネットワークとして構造化し、最も長い経路(クリティカルパス)を見つけ出すことで、スケジュール遅延に直結する少数の重要アクティビティを識別する。クリティカルパス上のアクティビティはフロートが0であるため一日遅れればプロジェクトはそのまま一日遅れ、クリティカルパス外のアクティビティはフロートの範囲内で遅れても全体スケジュールに影響しない。管理者はこの区別を根拠に資源・監督を選択的に配分する。

B. 登場背景と必要性

両技法は1950年代後半にほぼ同時に、しかし異なる動機から生まれた。CPMは1957年にデュポン(DuPont)とレミントンランドのケリー・ウォーカー(Kelley & Walker)が、化学プラントの定期保守・建設のように期間と費用が比較的よく分かっている反復事業の工期と費用を同時に最適化するために開発した。一方PERTは1958年に米海軍のポラリス(Polaris)潜水艦ミサイル開発事業において、数千のアクティビティが絡み期間を確定しにくい新規研究開発(R&D)事業の不確実性を扱うために考案された。すなわちCPMは「費用-工期のトレードオフ」、PERTは「スケジュール不確実性の管理」という異なる問題意識から出発したが、今日ではネットワーク分析という共通の骨格を共有するため、しばしば「PERT/CPM」としてまとめて扱われる。

この技法が必要な理由は、大規模で多アクティビティのプロジェクトほど直観と経験だけでは完了期間とボトルネックを予測できないためである。アクティビティが数十個になるだけでも経路の組み合わせは爆発的に増え、「体感的に急いで見える作業」が実はフロートの大きい非クリティカルなアクティビティで、静かに進んでいた作業が実はクリティカルパスであることも多い。PERT/CPMはこうした錯覚を取り除き、スケジュールベースラインの確立・進捗統制・資源平準化・スケジュール短縮の意思決定に対する定量的根拠を提供する点で必要性を持つ。PMBOKでも「アクティビティの順序設定 → 期間見積り → スケジュール策定」と続くスケジュール管理知識エリアの中核ツールとしてこの技法を扱う。

C. 主要な特徴

PERT/CPMの特徴は第一に、依存関係に基づく構造的分析である点である。アクティビティを単に並べるのではなく先行後続の論理で結ぶため、あるアクティビティの遅延がどの後続アクティビティへ波及するかを追跡できる。例えば要件分析が3日遅れると、その後続である設計・開発・テストが連鎖的に押し出されるのか、それとも並列作業のフロート内で吸収されるのかを図の上で判別する。第二に、フロートという定量的統制指標を提供する。各アクティビティの総フロート(Total Float)と自由フロート(Free Float)を計算して管理優先順位を数値で付けるため、「感覚的に急ぐ仕事」ではなく「実際に完了日を決定する仕事」に資源を配分できる。

第三に、What-if分析の土台となる。期間を変えたりアクティビティを並列化したときに完了日がどう変わるかをネットワーク再計算で即座に確認できるため、スケジュール短縮(Crashing・Fast Tracking)の意思決定を支える。第四に、コミュニケーション・統制の共通言語を作る。クリティカルパス・マイルストーン・フロートが一つの図で共有されるため、発注者・PM・現場が同じ根拠の上で進捗を議論し、遅延発生時には責任の所在と挽回策を客観的に協議できる。ただしこれらの特徴はいずれもアクティビティ定義と期間見積りが正確であるという前提の上でのみ成立し、資源制約を反映しない純粋なネットワークは実際の実行スケジュールと乖離しうるという限界も併せて認識すべきである。

2. 全体構造と構成要素

スケジュールネットワーク分析は、WBSで分解された作業をアクティビティとして定義し順序を並べたのち、ネットワークを構成してクリティカルパスを導出し、必要に応じてスケジュールを短縮する一連の流れで進む。以下はその全体構造図である。

flowchart TD
  WBS["WBS(作業分解構造)"] --> ACT["アクティビティ定義(Activity Definition)"]
  ACT --> SEQ["アクティビティ順序設定(依存関係の設定)"]
  SEQ --> EST["アクティビティ期間見積り"]
  EST --> NET["スケジュールネットワーク構成(AON/AOA)"]
  NET --> FWD["前進計算(ES·EF)"]
  FWD --> BWD["後退計算(LS·LF)"]
  BWD --> FLOAT["フロート(Float)算出"]
  FLOAT --> CP["クリティカルパス(Critical Path)識別"]
  CP --> BASE["スケジュールBaseline確定"]
  CP --> COMP["スケジュール短縮(Crashing/Fast Tracking)"]
  COMP --> NET

構成要素を順に見ると、まずアクティビティ(Activity)は資源と時間を消費する作業単位であり、WBSの最下位ワークパッケージを実行可能な単位へさらに分割したものである。イベント/ノード(Event/Node)はアクティビティの開始・終了時点を表す瞬間であり時間を消費しない。依存関係(Dependency)はアクティビティ間の論理的先行後続の制約で、必ず守るべき義務的依存(Mandatory、hard logic)、慣行上選択する任意的依存(Discretionary、soft logic)、外部要因による外部依存に分かれる。所要期間(Duration)は各アクティビティを完了するのにかかる時間である。

一方、期間が0の特殊なアクティビティであるマイルストーン(Milestone)は、契約・承認・フェーズ完了のような重要な統制時点を示すのに用いられ、実際の作業はないがステークホルダーとの合意点をネットワークに明示する役割を果たす。マイルストーンをクリティカルパス上に配置すると「この承認が遅れればプロジェクトはそのまま遅れる」という事実を契約的に強調できる。

アクティビティを図に移す記法には二つある。AON(Activity-on-Node、ノード型・PDM)はアクティビティを長方形ノードで、依存関係を矢印で表現し、今日ほとんどのPMツール(MS Project、Primavera P6)が採用する標準である。AOA(Activity-on-Arrow、矢線型・ADM)はアクティビティを矢印で、イベントをノードで表現する古典的方式で、論理を整えるため実際の作業がないダミーアクティビティ(Dummy Activity)が必要であり、現在ではあまり使われない。PDMはアクティビティ間の関係を四種類に細分する。

依存タイプ 意味 例
FS(Finish-to-Start) 先行が終わってから後続開始(最も一般的) 設計完了後に開発着手
SS(Start-to-Start) 先行が始まれば後続開始可能 掘削開始後すぐ配管開始
FF(Finish-to-Finish) 先行が終わってから後続終了可能 テスト終了後に文書終了
SF(Start-to-Finish) 先行が始まってから後続終了(まれ) 新システム稼働後に旧システム終了

これにリード(Lead、重なり)とラグ(Lag、待ち)を付与して関係を精緻化する。例えば「FS + 2日のLag」は先行終了後2日待ってから後続を開始するという意味であり、コンクリート養生・承認待ちのような現実の制約をモデル化する。逆に「FS − 3日のLead」は先行が終わる3日前に後続を先に開始できるという意味で、設計が完全に終わる前に確定した部分から開発に着手する形の工程重なりを表現する。

AONが標準となった理由も実務的な文脈で理解する必要がある。AOAは二つのアクティビティが同じ開始・終了イベントを共有しつつ論理が異なるとき、これを区別するためダミーアクティビティを挿入せねばならず、ネットワークが大きくなるほどダミーアクティビティが急増して作成・解釈が煩雑であった。AONはアクティビティをノードに置き関係のみを矢印で表現するためダミーアクティビティが不要で、FS·SS·FF·SFとLead/Lagを自然に収められ、電算化に有利であった。このため今日の商用スケジュール管理ツールは事実上すべてAON(PDM)を採用している。

3. クリティカルパス計算手順(前進・後退計算)

クリティカルパス導出の核心は、各アクティビティの最早開始/終了(ES·EF)と最遅開始/終了(LS·LF)を計算し、その差であるフロートが0のアクティビティを結ぶことである。計算は二方向で進む。

前進計算(Forward Pass)はネットワークの開始から終了へ進み、ES(Early Start)とEF(Early Finish、= ES + 期間)を求める。あるアクティビティのESはすべての先行アクティビティEFのうち最大値である(複数の先行がすべて終わってから始まるため)。こうして最後まで計算すると、最終アクティビティのEFがすなわちプロジェクト最短完了期間となる。後退計算(Backward Pass)は逆に終了から開始へ進み、LF(Late Finish)とLS(Late Start、= LF − 期間)を求める。あるアクティビティのLFはすべての後続アクティビティLSのうち最小値である(後続のうち最も早いものに合わせる必要があるため)。

両計算が終わると総フロート(Total Float、TF) = LS − ES = LF − EFで求める。TFはプロジェクト完了日を遅らせずにアクティビティを先送りできる最大時間である。自由フロート(Free Float、FF)は後続アクティビティのESを遅らせずに先送りできる時間で、「後続アクティビティESの最小値 − 当該アクティビティEF」で計算する。クリティカルパス(Critical Path)はTF = 0のアクティビティの連続経路であり、ネットワークで最も長い経路であり完了期間を決定する経路である。

直観的に、前進計算は「できるだけ早く出発すると各アクティビティがいつ終わるか」を、後退計算は「完了日を守るには各アクティビティが遅くともいつまでに終わるべきか」を問うものである。前進計算で「先行EFの最大値」を用いる理由は複数の先行がすべて完了してから後続が始まるためであり、後退計算で「後続LSの最小値」を用いる理由は複数の後続のうち最も早く始めるべきものに合わせてこそ全体スケジュールが守られるためである。二方向の値が出会ってフロートとなり、そのフロートが0の地点がすなわち遅延の余地がないクリティカルパスとなる。

以下の例題ネットワークで計算過程を具体化する。アクティビティA(3日)から始まりB(4日)・C(2日)へ分岐し、BはD(5日)へ、CはE(6日)へ続いたのちF(2日)で合流する。

flowchart LR
  START(("開始")) --> A["A (3日)"]
  A --> B["B (4日)"]
  A --> C["C (2日)"]
  B --> D["D (5日)"]
  C --> E["E (6日)"]
  D --> F["F (2日)"]
  E --> F
  F --> END(("終了"))

経路は二つである。「A→B→D→F」は3+4+5+2 = 14日、「A→C→E→F」は3+2+6+2 = 13日である。したがって最短完了期間は14日でクリティカルパスはA-B-D-Fである。前進・後退計算の結果とフロートを表にまとめると次のとおりである。

アクティビティ 期間 ES EF LS LF TF クリティカル
A 3 0 3 0 3 0 ●
B 4 3 7 3 7 0 ●
C 2 3 5 7 9 4
D 5 7 12 7 12 0 ●
E 6 5 11 9 12 4
F 2 12 14 12 14 0 ●

C・Eはフロートが4日であるため4日まで遅延してもプロジェクト完了日(14日)に影響しないが、A・B・D・Fはフロートが0であるためわずか一日の遅延もそのまま完了日を遅らせる。この表一つで管理者は「監督をA-B-D-Fに集中し、C・Eは資源を再配置する余地がある」という結論を即座に得る。

総フロートと自由フロートの区別も実務で重要である。総フロートは「プロジェクト完了日を遅らせない限度」であり、自由フロートは「すぐ次の後続の開始を遅らせない限度」である。上の例でアクティビティEの自由フロートは後続FのES(12) − EのEF(11) = わずか1日である。すなわちEは総フロートが4日であっても一日を超えて遅延すると後続Fを押し始めるため、同じ非クリティカルなアクティビティでも自由フロートが小さいアクティビティは実質的な統制強度を高めるべきである。このようにフロートの種類を区別して管理強度を差別化することが、単なるクリティカルパス識別を超えた精緻なスケジュール統制の核心である。

4. PERTの確率論的見積りとCPMとの比較

CPMが期間を一つの確定値とみなすのに対し、PERTは不確実性を明示的にモデル化する。各アクティビティについて楽観値(O、Optimistic)・最頻値(M、Most likely)・悲観値(P、Pessimistic)の三値を見積り、ベータ分布を仮定して期待期間 te = (O + 4M + P) / 6、標準偏差 σ = (P − O) / 6、分散 σ² = ((P − O)/6)²を求める。例えばある設計アクティビティがO=4日、M=6日、P=14日と見積られるとte = (4 + 24 + 14)/6 = 7日、σ ≈ 1.67日、σ² ≈ 2.78となる。最頻値が6日でも悲観値の裾が長いため期待期間が7日へ伸びる点に注目すべきである。

三値にそれぞれ異なる重みを置く理由も押さえておくべきである。係数 (O + 4M + P)/6はベータ分布の平均を近似したもので、実際の経験上、最頻値(M)近くの値が最も頻繁に現れるため4倍の重みを与え、極端値である楽観・悲観値は1倍ずつのみ反映する。標準偏差を (P − O)/6とするのは、正規分布で平均 ± 3σが全体の約99.7%を包含するという性質(範囲 = 6σ)を活用した近似である。したがって楽観値と悲観値の間隔が広いほどそのアクティビティの不確実性(分散)が大きくなり、これがすなわち完了日リスクの源泉となる。

PERTの真価は完了日についての確率的な言明を可能にする点にある。クリティカルパス上のアクティビティのteを足してプロジェクト期待期間を、分散を足して(中心極限定理を根拠に正規分布近似)全体標準偏差を求めたのち、Z = (目標日 − 期待期間) / σで標準化すると「目標完了日以内に終わる確率は約何%」という答えを出せる。例えば期待期間100日・標準偏差5日のプロジェクトが110日以内に終わる確率はZ = (110−100)/5 = 2.0、すなわち約97.7%と計算される。これは経営陣に「余裕バッファを何日置けば目標信頼水準を確保できるか」を定量的に提示する強力な根拠となる。

実際の産業事例で見ると、大型SIプロジェクトでは要件分析・アーキテクチャ設計・中核モジュール開発・統合テストがおおむねクリティカルパスを成し、画面UIや文書化のようなアクティビティはフロートの大きい非クリティカルに属する場合が多い。このときPMが画面進捗率に気を取られ、肝心の統合テスト環境構築(クリティカルパス)を見落とすとオープン日程はそのまま押し出される。逆に新薬・衛星のように前例のないR&Dはアクティビティ期間の不確実性が大きく、単一値ではなく三点見積りで完了確率を提示してこそ経営陣がリリース時期のリスクを納得する。このように同じネットワークの骨格でも事業の性格に応じてCPMとPERTの選択が分かれる。

両技法の差が生じる根本原因は対象事業の性格にある。CPMは期間が安定して分かっている反復・建設型事業に適し費用-工期の最適化に強く、PERTは前例がなく期間を確定できないR&D・新製品開発に適する。実務的含意として、安定事業にわざわざ三点見積りの負担を課すのは無駄であり、逆に不確実性の大きい事業に単一確定値を用いるとスケジュールリスクを過小評価することになる。

区分 CPM(クリティカルパス法) PERT
期間見積り 単一確定値(決定論) 三点見積り(確率論)
焦点 費用-工期のトレードオフ スケジュール不確実性・完了確率
適合事業 反復・建設・保守 新規R&D・非反復事業
時間 vs 費用 双方を考慮 時間中心
代表事例 デュポンのプラント保守(1957) ポラリスミサイル(1958)

スケジュール短縮を先の例題で具体化すると理解しやすい。クリティカルパスA-B-D-F(14日)を12日へ減らさねばならないとしよう。各アクティビティの費用勾配がB=1日あたり20万ウォン、D=1日あたり15万ウォン、F=1日あたり30万ウォンなら、最も安いDから1日短縮(15万ウォン)、再びDまたはBのうち勾配の低い方をもう1日短縮する形で計2日を最小費用(例:15+15 = 30万ウォンまたは15+20 = 35万ウォン)で達成する。ただしDを過度に減らすと並列経路A-C-E-F(13日)が新たなクリティカルパスとして浮上するため、短縮一段階ごとにネットワークを再計算し、どの経路が完了日を支配するか再確認せねばならない。この手順を省くと「もはやクリティカルパスではないアクティビティ」に費用を注ぐ無駄が生じる。

スケジュール短縮(Schedule Compression)はクリティカルパス分析の代表的な活用である。Crashing(工程圧縮)はクリティカルパスのアクティビティに資源(人員・費用)を追加投入して期間を減らすが、「費用勾配(Cost Slope) = (緊急費用 − 通常費用)/(通常期間 − 緊急期間)」が最も小さいアクティビティから短縮し最小費用で目標工期に合わせる。Fast Tracking(工程重なり)は本来順次行っていたアクティビティを並列に重ねて進めて期間を減らすが、手戻り(rework)とリスクが増える。両技法とも必ずクリティカルパスにのみ適用してこそ効果があり、非クリティカルなアクティビティを短縮するのは完了日に影響せず無意味である。ただしクリティカルパスを短縮していくと別の経路が新たなクリティカルパスになる「クリティカルパスの移動」が発生するため、各段階で再計算が必要である。

5. 深化:モンテカルロシミュレーションと現代的拡張

伝統的なPERTは「クリティカルパス一つだけを確率分析する」という限界がある。実際には非クリティカルな経路もアクティビティの遅延によりいつでもクリティカルになりうるが(経路収束・合流バイアス、Merge Bias)、これを無視すると完了確率を楽観的に過大評価する。この限界を克服する現代的代替がモンテカルロシミュレーション(Monte Carlo Simulation)である。各アクティビティ期間を三角・ベータ・PERT分布などの確率分布として定義したのち、数千〜数万回の無作為標本を抽出し、反復ごとにネットワーク全体を再計算し、完了日の分布と各アクティビティがクリティカルパスに含まれる頻度(クリティカリティ度、Criticality Index)を算出する。例えばあるアクティビティのCriticality Indexが80%なら「全シナリオの80%でクリティカルパスに属する」という意味で、単一の決定論的分析よりはるかに現実的なリスク優先順位を提供する。Primavera Risk Analysis、@RISK、Safran Riskのようなツールがこれを支援し、大型EPC・SI事業の定量的スケジュールリスク分析(Schedule Risk Analysis)で標準的に用いられる。

モンテカルロが明らかにする代表的な落とし穴が先に述べた経路合流バイアス(Merge Bias)である。複数の経路が一つの合流地点で出会うとき、完了日はそのうち「最も遅く終わる経路」に支配される。各経路が平均的に定時で終わる確率が50%であっても、二つの経路がともに定時で終わってこそ合流が定時になるため、合流時点が定時である確率は0.5 × 0.5 = 25%へ急落する。決定論的CPMはこの効果を見られず完了確率を過大評価するが、モンテカルロは数万回のシミュレーションでこれをそのまま再現し現実的な完了日分布を提示する。したがってフロートの小さい近接クリティカルパス(Near-Critical Path)が複数あるプロジェクトほどシミュレーション基盤の分析の価値が大きくなる。

もう一つの拡張は制約理論(TOC)に基づくクリティカルチェーン法(CCPM、Critical Chain)である。伝統的CPMが資源制約を無視し論理依存のみを扱うのに対し、CCPMは資源競合まで考慮した「クリティカルチェーン」を定義し、個々のアクティビティに隠れていた安全余裕を除去してプロジェクトの末端にプロジェクトバッファとしてまとめて管理する(詳細は[[critical-chain-project-management]]参照)。アジャイル・ハイブリッド環境ではスプリント単位の反復が主なリズムとなり詳細ネットワークの比重が減ったが、リリース計画・マイルストーン間の依存管理、大規模プログラムのSAFeロードマップの水準では依然としてネットワーク論理とクリティカルパスの概念が活用される。実際にMS Project・Primavera P6・Jira Advanced Roadmapsなどは依存関係とクリティカルパスのハイライト機能を標準で提供する。

6. 考慮事項および示唆点

第一に、見積り品質が分析の信頼度を左右する(Garbage In, Garbage Out)。 どれほど精緻なネットワークでもアクティビティ期間・依存関係の見積りが不十分ならクリティカルパスと完了日が歪む。類似事業の実績(Historical Data)・専門家判断・三点見積りを併用し、楽観バイアス(Optimism Bias)と学生症候群を牽制する見積りガバナンスが前提とならねばならない。

第二に、資源制約を併せて見なければならない。 純粋なCPMは資源が無限であると仮定するため、理論上はクリティカルパスと実際に実行可能なスケジュールが乖離しうる。資源平準化(Resource Leveling)を適用するとクリティカルパスが変わったり完了日が延びたりするため、ネットワーク分析と資源管理を統合しCCPM・資源制約スケジューリングで補完する戦略が必要である。

第三に、クリティカルパスは固定ではなく動的に移動する。 進捗・遅延・短縮に応じてクリティカルパスは随時変わるため、着手時点に一度計算して終わりにせず、周期的に再計算(進捗反映後に再分析)せねばならない。近接クリティカルパス(Near-Critical Path、フロートの小さい経路)も併せてモニタリングし潜在リスクを先制的に管理することが技術士の観点の実務戦略である。

第四に、短縮の意思決定は費用・品質・リスクのトレードオフである。 Crashingは費用を、Fast Trackingは手戻り・品質リスクを増やす。費用勾配の低いアクティビティから段階的に圧縮しつつ、各段階でクリティカルパスの移動を再確認し、短縮が後続リスク(過労・品質低下)へ転移しないか総合的に判断せねばならない。

第五に、スケジュールと他の成果領域を統合して管理する。 クリティカルパス分析はEVM(アーンドバリュー管理)のスケジュール効率指数(SPI)と結び付くとき真価を発揮する。SPIが悪化するとき、その原因がクリティカルパスのアクティビティの遅延なのか非クリティカルなアクティビティの問題なのかをネットワークで区別してこそ正確な挽回策が出る(連携:[[earned-value-management]])。

第六に、ツール・手法の適合性を事業特性に合わせて選択する。 反復・建設型はCPM+Crashing、不確実性の大きいR&DはPERT+モンテカルロ、資源競合が激しければCCPM、要求変動の大きいSWはアジャイルとのハイブリッドが有効である。展望すると今後は実績データ基盤のAIスケジュール予測とモンテカルロシミュレーションが結び付き、完了確率とリスクアクティビティをリアルタイムで更新する知能型スケジュール管理へ進化するであろう。

参考資料

一言まとめ: PERT/CPMはアクティビティをネットワークで結び前進・後退計算でフロートとクリティカルパスを導出するスケジュール分析技法であり、CPMは決定論的な費用-工期最適化に、PERTは三点見積り基盤の確率的完了予測に強く、モンテカルロ・CCPMへ拡張される。