フレームワーク活用ガイドひとことで言うと#
各タスクに楽観値・最頻値・悲観値の3点で見積もりを出し、加重平均で期待値を算出する手法。さらにタスク間の依存関係をネットワーク図にして**クリティカルパス（最長経路）**を特定することで、プロジェクト全体の所要期間とリスクを定量的に評価する。
押さえておきたい用語#
- 3点見積もり（Three-Point Estimate）
- 楽観値（O）・最頻値（M）・悲観値（P）の3つの値から期待値と標準偏差を算出する見積もり手法。
- 期待値（Expected Time: tE）
- PERT計算式 tE = (O + 4M + P) / 6 で求める加重平均。最頻値に4倍の重みを置くベータ分布近似。
- クリティカルパス
- プロジェクトのネットワーク図における最長経路。この経路上のタスクが1日遅れると、プロジェクト全体が1日遅れる。
- スラック（余裕時間）
- クリティカルパス以外のタスクが持つ遅延許容時間を指す。スラック=0のタスクがクリティカルパス上にある。
- 標準偏差（σ）
- σ = (P - O) / 6 で算出。見積もりの不確実性の大きさを表し、σが大きいほどリスクが高い。
PERTの全体像#
こんな悩みに効く#
- 見積もりがいつも楽観的で、プロジェクト終盤に遅延が発覚する
- 「どのタスクが遅れるとプロジェクト全体に影響するか」がわからない
- スケジュールバッファをどこに・どれだけ置くべきか判断できない
基本の使い方#
WBS（作業分解構成図）をもとにタスクを洗い出し、各タスクの先行・後続関係を定義する。
- タスクはノード（丸）、依存関係は矢印で表現
- 並行して進められるタスクは分岐させる
- 「タスクBはタスクAが完了しないと着手できない」のような制約を明示する
- タスク数が多い場合はMS ProjectやSmartsheetを使うと効率的
タスクの担当者または有識者に、3つの値をヒアリングする。
- 楽観値（O）: すべてが順調に進んだ場合の最短所要時間
- 最頻値（M）: 最もありそうな所要時間（過去の経験ベース）
- 悲観値（P）: 問題が多発した場合の最長所要時間
- 見積もりのバイアスを避けるため、必ずOを先に聞き、次にP、最後にMの順で聞く
各タスクの期待値 tE = (O + 4M + P) / 6 と標準偏差 σ = (P - O) / 6 を計算する。
- ネットワーク図上で期待値を合算し、最長経路（クリティカルパス）を特定
- クリティカルパス上のタスクにはバッファとリスク対策を重点配置
- プロジェクト全体の標準偏差は、クリティカルパス上のσ²を合算して平方根を取る
- 「95%の確率で○日以内に完了」という確率的な見積もりが可能になる
具体例#
状況: Web制作会社。クライアントから「3か月で納品できるか？」と聞かれたが、過去の類似案件は 65〜100日 とばらつきが大きい。営業は「90日で大丈夫」と回答したいが、根拠がない。
主要タスクの3点見積もり
| タスク | O（日） | M（日） | P（日） | tE（日） | σ |
|---|---|---|---|---|---|
| 要件定義 | 5 | 8 | 15 | 8.7 | 1.7 |
| デザイン | 10 | 15 | 25 | 15.8 | 2.5 |
| コーディング | 12 | 18 | 30 | 19.0 | 3.0 |
| テスト・修正 | 5 | 10 | 20 | 10.8 | 2.5 |
クリティカルパス（全タスク直列）の期待値は 54.3日、プロジェクト全体のσは 5.0日。90日なら完了確率は 99%以上。「75日で完了する確率が約95%」と根拠付きで伝えられるようになった。
状況: 電子機器メーカー。新製品の市場投入を 10か月後 に控えるが、開発・金型・認証の3ラインが並走し、「どこがボトルネックかわからない」と開発部長が悩んでいる。
ネットワーク図で分析した結果
- パスA（設計→試作→金型→量産）: 期待値 185日、σ = 12日
- パスB（設計→EMC認証→安全認証）: 期待値 160日、σ = 18日
- パスC（設計→ソフト開発→結合テスト）: 期待値 170日、σ = 15日
クリティカルパスはパスA。10か月（約200日）以内に完了する確率は 89%。σが大きいパスBの認証工程に早期着手するよう調整し、バッファ15日をパスAの金型工程後に配置した。結果、予定通り 192日 で量産開始に成功。
状況: フリーランスのデザイナー。3件の案件を同時進行で受けたが、それぞれの納期が近接している。「全部間に合うか」を感覚でしか判断できず不安。
簡易PERTで可視化
- 案件A（ロゴ制作）: tE = 4日、σ = 0.5日
- 案件B（LP制作）: tE = 9日、σ = 2.0日
- 案件C（バナー10本）: tE = 6日、σ = 1.0日
BとCは並行可能。A→B→Cの直列部分の期待値は 13日。3件を19稼働日以内に収める確率は 98%。σが大きいLP制作に先行着手し、ロゴとバナーを合間に進める計画に変更。全案件を 17稼働日 で納品し、2日のバッファも確保できた。
やりがちな失敗パターン#
- 最頻値だけで見積もる — 「だいたい10日」では不確実性が見えない。3点で見積もることで初めてリスクの大きさが定量化できる
- クリティカルパスだけに注目する — σが大きい非クリティカルパスが遅延すると、途中でクリティカルパスが入れ替わることがある。σの大きいタスクは要注意
- 悲観値を「最悪」に設定しすぎる — 天災レベルの極端な値を入れるとσが膨らみ、見積もりが使い物にならなくなる。「現実的に起こりうる最悪」に留める
- 一度計算したら更新しない — PERTは計画段階の分析だが、プロジェクト進行中も実績値で見積もりを更新し続けることで精度が上がる
まとめ#
PERTは「見積もりに幅がある」という現実を受け入れ、その幅を数学的に扱うための手法だ。3点見積もりで期待値とσを出し、ネットワーク図でクリティカルパスを特定することで、「〇%の確率で△日以内に完了」という確率的なスケジュール管理が可能になる。計算自体はシンプルなので、大規模PJだけでなく個人の案件管理にも応用できる。