フレームワーク活用ガイドひとことで言うと#
プロジェクトの「計画上の進捗（PV）」「実際に完了した作業の価値（EV）」「実際にかかったコスト（AC）」の3つの数値を比較し、スケジュールとコストの両面から進捗を定量的に可視化する管理手法。
押さえておきたい用語#
- PV（Planned Value / 計画価値）
- ある時点までに計画上完了しているはずの作業量を金額換算した値。「予定ではここまで終わっているはず」を示す。
- EV（Earned Value / 出来高）
- ある時点までに実際に完了した作業量を金額換算した値。「実際にここまで終わった」を表す。
- AC（Actual Cost / 実コスト）
- ある時点までに実際に費やしたコスト。EVと比較して効率を測る。
- SPI（Schedule Performance Index）
- EV ÷ PV で算出するスケジュール効率指標。1.0未満なら遅延、1.0超なら前倒しを意味する。
- CPI（Cost Performance Index）
- EV ÷ AC で算出するコスト効率指標。1.0未満ならコスト超過、1.0超なら予算内で進んでいる状態。
- EAC（Estimate at Completion）
- 現在のパフォーマンスが続いた場合の完了時総コスト予測。BAC ÷ CPI で概算できる。
EVMの全体像#
こんな悩みに効く#
- プロジェクトの進捗が「予定通り」と報告されるが、実態が見えない
- スケジュール遅延とコスト超過のどちらが問題なのか区別できない
- 完了時の総コストがいくらになるか、早期に予測したい
基本の使い方#
プロジェクトの作業を分解（WBS）し、各タスクに予算（人件費+経費）を配分する。
- 全タスクの予算合計 = BAC（Budget at Completion / 総予算）
- タスクの完了基準を明確にする（0/100法、50/50法、達成率法など）
- 各タスクの計画開始日・終了日を設定し、時間軸上にPVを展開する
PVを時系列で累積したグラフがSカーブ。これがプロジェクトの「計画」を表すベースライン。
- 承認後は原則として変更しない（変更管理プロセスを経る場合のみ更新）
- Sカーブはプロジェクト初期と末期で緩やか、中盤で急勾配になるのが一般的
週次または隔週で、実際の進捗（EV）と実際のコスト（AC）を集計する。
- EV: 完了したタスクの予算を合計（進行中のタスクは完了率×予算で按分）
- AC: 実際にかかった人件費・外注費・経費を合計
- PV・EV・ACの3本の線をグラフにプロットする
指標を算出し、プロジェクトの健全性を判断する。
| 状態 | SPI | CPI | 意味 |
|---|---|---|---|
| 理想 | ≧ 1.0 | ≧ 1.0 | 予定通りかつ予算内 |
| スケジュール遅延 | < 1.0 | ≧ 1.0 | 遅れているがコストは管理下 |
| コスト超過 | ≧ 1.0 | < 1.0 | 進捗は順調だがコストが膨張 |
| 危機 | < 1.0 | < 1.0 | 遅れかつコスト超過 |
CPIが 0.8以下 になったプロジェクトが最終的にCPIを1.0以上に回復する確率は非常に低いという研究結果があり、早期の是正判断が重要。
具体例#
状況: 従業員50名のWeb制作会社が、ECサイト構築プロジェクト（予算1,200万円、6ヶ月）を受注。3ヶ月経過時点で「順調」と報告されていたが、PMが肌感覚で不安を感じていた。
3ヶ月時点のEVM計測結果
| 指標 | 値 | 判定 |
|---|---|---|
| PV | 600万円 | 計画では半分完了のはず |
| EV | 420万円 | 実際に完了した作業は35%分 |
| AC | 550万円 | すでに予算の46%を消化 |
| SPI | 0.70 | スケジュール 30%遅延 |
| CPI | 0.76 | コスト効率 24%悪化 |
| EAC | 1,579万円 | このペースだと 379万円超過 の見込み |
「順調」と報告されていたが、EVMで可視化した結果、スケジュール・コスト双方が深刻な状態だと判明。原因は要件の手戻りで、設計工程の作業が3回やり直されていた。
対策としてスコープの一部を次フェーズに移し、開発メンバーを1名追加。最終的なコストは 1,380万円（180万円超過）で着地し、当初ペースで進んでいた場合の1,579万円より200万円抑えられた。
状況: 人口25万人の自治体が基幹業務システムを刷新。契約額 4億2,000万円、期間24ヶ月。過去のシステム導入プロジェクトは全件でコスト超過しており、議会から厳しい目が向けられている。
EVM導入の工夫
- WBSを300タスクに分解し、各タスクに予算を配分
- 月次で受注者（SIer）がEV・ACを報告し、自治体PMOがSPI・CPI・EACを算出
- SPI < 0.9 または CPI < 0.9 になった場合は「イエローフラグ」として対策会議を開催
12ヶ月時点のデータ
| 指標 | 値 |
|---|---|
| PV | 2億1,000万円 |
| EV | 1億9,200万円 |
| AC | 2億500万円 |
| SPI | 0.91 |
| CPI | 0.94 |
| EAC | 4億4,700万円 |
SPIが0.91でイエローフラグ。分析の結果、データ移行の工数見積もりが甘かったことが判明。移行ツールの追加開発（800万円）を承認し、後半のスケジュール圧迫を回避。最終コストは 4億3,200万円（1,200万円超過・超過率2.9%）で、過去プロジェクトの超過率15〜20%と比較して大幅に改善した。
状況: シリーズAのSaaSスタートアップ（従業員18名）。調達資金1.5億円のうち開発予算は 6,000万円（12ヶ月）。投資家への四半期報告でバーンレートと進捗を定量的に示す必要がある。
簡易EVM
重厚なEVMは小規模チームに合わないため、簡易版を設計。
- WBSの代わりに エピック（大機能単位） を12個定義し、各エピックにストーリーポイントと予算を割り当て
- EVはスプリントごとに「完了したエピックの予算」で算出
- ACは月次の人件費+クラウド費用+外注費で集計
6ヶ月時点
| 指標 | 値 |
|---|---|
| BAC | 6,000万円 |
| PV | 3,000万円 |
| EV | 2,700万円 |
| AC | 3,200万円 |
| SPI | 0.90 |
| CPI | 0.84 |
CPIが0.84で、このまま進むとEACは 7,140万円（1,140万円超過）。原因はインフラコストの見積もり不足と、採用が遅れたことによる外注費の増加。
投資家報告でEVMのグラフを提示し、「このまま進めば予算超過するが、採用が完了する8ヶ月目以降は外注費が減りCPIが改善する見込み」と説明。データに基づく報告が投資家の信頼を維持し、追加のランウェイ交渉もスムーズに進んだ。
やりがちな失敗パターン#
- EVの計測が曖昧 — タスクの完了基準が不明確だと「80%完了」のような主観的な数値になり、EVが信頼できなくなる。0/100法（終わったかまだか）が最もシンプルで正確
- ACの集計が遅い — 実コストの集計が月末にしかできないと、差異分析が1ヶ月遅れる。タイムシートとプロジェクト会計を連動させる
- ベースラインを頻繁に変更する — 遅延するたびにPVを修正すると、EVMの意味がなくなる。ベースラインは変更管理を経た場合のみ更新
- 数字を見るだけで行動しない — SPI・CPIを計算しても、是正措置を取らなければただの数字遊び。閾値を決めて「ここを割ったら対策会議」というルールを設ける
まとめ#
EVMはプロジェクトの進捗とコストをPV・EV・ACの3指標で定量的に可視化する手法。SPIでスケジュール効率、CPIでコスト効率を測り、EACで完了時の総コストを予測できる。重要なのは数値を出すことではなく、差異を検知して早期に是正措置を取ること。小規模プロジェクトでも簡易版を導入すれば、「なんとなく順調」という報告を具体的な数字に置き換えられる。