PERT分析

英語名 PERT Analysis
読み方 パート ぶんせき
難易度
所要時間 2〜4時間(タスク分解〜ネットワーク図作成)
提唱者 米国海軍・ブーズ・アレン・ハミルトン(1958年)
目次

ひとことで言うと
#

「このタスクは何日かかりますか?」に対して1つの数字で答えるのが従来の見積もり。PERTは楽観値・最頻値・悲観値の3点で見積もり、加重平均で期待値を算出する手法。1958年に米国海軍のポラリスミサイル計画で開発され、不確実性の高いプロジェクトほど威力を発揮する。「だいたい3日」ではなく「最短2日、普通なら4日、最悪8日」と分解することで、現実的なスケジュールとリスク管理が可能になる。

押さえておきたい用語
#

押さえておきたい用語
3点見積もり(Three-Point Estimate)
各タスクについて**楽観値(O)、最頻値(M)、悲観値(P)**の3つの所要時間を見積もる方法。PERT期待値は(O + 4M + P)÷ 6で算出する。
クリティカルパス(Critical Path)
プロジェクト全体の工期を決定する最長の経路。このパス上のタスクが1日遅れると、プロジェクト全体が1日遅れる。
スラック(Slack / Float)
クリティカルパス以外のタスクが持つ余裕時間。スラックが大きいタスクは多少遅れてもプロジェクト全体に影響しない。
標準偏差(Standard Deviation)
見積もりのばらつきの大きさ(P − O)÷ 6で算出し、値が大きいほど不確実性が高い。

PERT分析の全体像
#

PERT分析:3点見積もりから期待値を算出する
楽観値(O)すべて順調なら最頻値(M)最も起こりやすい悲観値(P)トラブルが重なればPERT期待値(O + 4M + P) ÷ 6各タスクの期待値をつなぎ → クリティカルパスを特定3つの見積もりを加重平均して現実的な工期を算出
PERT分析の実施手順
1
タスクを分解
WBSで作業を洗い出し、依存関係を整理
2
3点見積もり
各タスクにO・M・Pの3つの所要時間を設定
3
期待値を算出
(O+4M+P)÷6で各タスクの期待値を計算
クリティカルパス特定
最長経路を見つけ、重点管理の対象にする

こんな悩みに効く
#

  • 見積もりが「だいたい3週間」のような勘に頼りがちで、いつも遅れる
  • プロジェクトのどのタスクが全体の遅延リスクになるかわからない
  • ステークホルダーに工期の根拠を説明できない

基本の使い方
#

タスクを分解し、依存関係を整理する

PERT分析の精度はタスク分解の細かさで決まる。

  • WBS(Work Breakdown Structure)でプロジェクトを作業単位に分解する
  • 各タスクの前後関係(AがBの前提条件、など)を明確にする
  • タスクの粒度は「1人が1〜5日で完了できるサイズ」が目安
  • 並行して進められるタスクと、順番に進めるタスクを区別する
各タスクに楽観値・最頻値・悲観値を設定する

3つの数字を出すことで、「不確実性の大きさ」が可視化される。

  • 楽観値(O):すべてが順調に進んだ場合の最短日数
  • 最頻値(M):最も起こりやすい所要日数(過去の実績がベース)
  • 悲観値(P):トラブルが重なった場合の最長日数
  • 担当者に聞くとき「最短・普通・最悪の3パターンで教えて」と伝えると出しやすい
  • 悲観値は楽観値の3〜5倍になることが多い(これが不確実性の正体)
期待値を計算し、クリティカルパスを特定する

計算自体は単純。重要なのは結果をどう活用するか。

  • 各タスクのPERT期待値 =(O + 4M + P)÷ 6
  • タスクの依存関係に沿って期待値を積み上げ、最長経路(クリティカルパス)を見つける
  • クリティカルパス上のタスクを重点管理対象にする(進捗の遅れ = プロジェクト全体の遅れ)
  • スラック(余裕)のあるタスクは多少遅れても全体に影響しないため、リソース調整の余地として活用する

具体例
#

例1:Webサービスのリニューアルプロジェクト

状況: 自社ECサイトのフルリニューアル。チーム6名。経営層から「3ヶ月で完了」と言われているが、根拠のない期限に不安を感じている

PERT分析の適用:

  • 主要タスクを12個に分解し、各タスクに3点見積もりを設定
  • 例:「決済システム連携」→ O:5日、M:10日、P:25日 → 期待値 = (5+40+25)÷6 ≒ 11.7日
  • クリティカルパスは「DB設計→API開発→決済連携→結合テスト」で合計52日
  • 非クリティカルパス(デザイン→フロント実装)は38日でスラック14日

結果: 経営層に「最短78日、期待値92日、最悪120日」と3パターンで説明。「3ヶ月(約90日)は期待値通りだが、決済連携にリスクがある」と伝え、決済連携の事前検証を前倒しで実施。実際のリリースは88日で完了し、初めて「予定通り」のリリースを達成。

例2:建設会社の工期管理

状況: 中規模の商業施設建設。工期12ヶ月。過去3件のプロジェクトがすべて2〜3ヶ月遅延しており、発注者からの信頼が低下している

PERT分析の適用:

  • 全工程を45タスクに分解し、各工程の監督に3点見積もりをヒアリング
  • 基礎工事:O:20日、M:30日、P:60日 → 期待値32日
  • クリティカルパスを特定したところ、「鉄骨建方→外壁施工→内装→設備検査」のラインが最長
  • 外壁施工の悲観値が最頻値の3倍(天候リスク)と判明し、雨季を避けるスケジュールに調整

結果: クリティカルパス上のタスクに毎週の進捗確認を集中し、非クリティカルのタスクはスラックの範囲でリソースをシフト。工期11ヶ月18日で竣工し、4件ぶりに予定内完了。「見積もりに3パターンを使うようになっただけで、管理の質が変わった」と現場監督はコメントしている。

例3:結婚式の準備スケジュール

状況: 結婚式まで6ヶ月。共働きで準備時間が限られる中、「式場」「衣装」「招待状」「引き出物」「演出」など膨大なタスクがあり、何から手をつけるべきかわからない

PERT分析の適用:

  • タスクを15個に分解し、依存関係を整理(衣装が決まらないと前撮りできない、など)
  • 各タスクに3点見積もり:例「引き出物選定」→ O:3日、M:7日、P:14日 → 期待値7.5日
  • クリティカルパス:「式場最終打ち合わせ→席次決定→招待状発送→出欠確認→テーブルコーディネート」
  • 衣装選びはクリティカルパス外(スラック3週間)と判明

結果: 「衣装を先に決めなきゃ」という焦りは不要で、クリティカルパスの招待状発送を最優先に。2人の休日をクリティカルタスクに集中配分し、6ヶ月のスケジュールを2週間の余裕を残して完了。「PERTのおかげで、何を急ぐべきかが明確になった。ケンカが減った」と新郎は振り返っている。

やりがちな失敗パターン
#

  1. 楽観値で計画を組む — 「最短でいけるはず」という期待でスケジュールを引くと、ほぼ確実に遅れる。期待値か、リスクが高い場合は期待値+標準偏差で計画する
  2. 悲観値を過小評価する — 「さすがにそこまでかからないだろう」と悲観値を控えめにすると、PERT分析の意味がなくなる。最悪ケースは真剣に見積もる
  3. クリティカルパスを特定しただけで満足する — 特定した後の重点管理(進捗確認の頻度を上げる、バッファを積む、リソースを優先配分する)がなければ単なる計算練習
  4. 3点見積もりを1人で完結させる — 実際に手を動かす担当者にヒアリングしないと、現実離れした数字になる

まとめ
#

PERT分析の本質は「不確実性を数字にする」ことにある。1つの見積もりでは見えないリスクが、3点見積もりでは可視化される。クリティカルパスを見つければ、どこに管理の力を集中すべきかが明確になる。プロジェクトの遅延は能力不足ではなく、不確実性を無視した計画が原因であることが多い。「最短・普通・最悪」の3つの数字を出す習慣だけでも、スケジュールの精度は大きく改善する。