Claude CodeでEVM・コスト集計・バーンダウンを自動化｜PMのコスト管理実装レシピ

EVM（Earned Value Management）の理屈は知っている。PV・EV・ACの定義も言える。それでも実プロジェクトで毎週SPI/CPIを計算し、バーンダウンを描き続けているPMは少数派です。理由は単純で、Excelで手集計を毎週続ける気力が持たないからです。

「AIで効率化したい」と聞きますが、コスト数字をAIに丸投げするのは危険。求められるのは、数字の出処を仕組みで固定し、AIには集計と可視化だけ任せ、判断はPMがやる運用です。

この記事では、Claude CodeのSkill＋MCPで、PV/EV/ACを稼働データから組み立て、SPI/CPI・バーンダウンを毎週自動生成する実装を、現場で動かせる粒度で解説します。

なぜEVMは運用が続かないのか

EVMが現場で機能しないのは、計算が複雑だからではなく、データソースが分散しているためです。

PV（計画値）：プロジェクト計画書やスケジュールに埋もれていて、毎週手で書き出す必要がある
EV（出来高）：JIRAのチケット完了状況やマイルストーン進捗から計算する必要がある
AC（実コスト）：タイムシートや経理システムにあり、PMが毎週手で集計している

3つのデータをExcelに転記するだけで2時間が消える。これでは続きません。Claude Codeは、MCPで3経路を読み取り専用接続し、Skillで集計フォーマットを固定することで、転記作業を丸ごと巻き取れます。

Claude Codeを「EVM自動集計器」にする全体像

必要な要素は次の3つです。

データ取得MCP：JIRA・タイムトラッキングツール・予算管理スプレッドシートの3経路（読み取り専用）
EVM集計Skill：PV/EV/ACを算出し、SPI/CPI・バーンダウンを生成する
CLAUDE.mdコスト運用ルール：出来高の判定基準、AC計上ルール、報告タイミングを明記

これが揃うと、毎週月曜にSkillを叩くだけで、SPI/CPI・バーンダウン・ACの内訳が揃います。

ステップ1：プロジェクト計画値（PV）をYAMLで管理する

docs/projects/{project-id}/baseline.yaml に計画値を保存します。

project_id: "PROJ-2026-A"
total_budget_pd: 300
phases:
  - name: "要件定義"
    planned_pd: 30
    planned_end: "2026-05-15"
    weight: 0.10
  - name: "基本設計"
    planned_pd: 40
    planned_end: "2026-06-15"
    weight: 0.13
  - name: "実装"
    planned_pd: 120
    planned_end: "2026-08-31"
    weight: 0.40
  - name: "結合テスト"
    planned_pd: 60
    planned_end: "2026-09-30"
    weight: 0.20
  - name: "総合・受入"
    planned_pd: 50
    planned_end: "2026-10-31"
    weight: 0.17

weight は各フェーズの予算配分（合計1.0）。EVを「フェーズ完了率 × weight × total_budget_pd」で計算するための基礎数値になります。

ステップ2：EVM集計Skillを定義する

.claude/skills/evm-weekly/SKILL.md を作成します。

---
name: evm-weekly
description: 過去1週間のJIRAチケット完了状況・タイムシート・予算管理シートから、PV/EV/ACとSPI/CPI、バーンダウンチャート用CSVを tmp/evm/{project-id}/{YYYY-MM-DD}.md に出力する
disable-model-invocation: true
allowed-tools: Read, Write, Bash, mcp__jira__*, mcp__sheets__*
---

# EVM週次集計Skill

## 入力
- `docs/projects/{project-id}/baseline.yaml`：計画値
- 実行日（過去7日のデータを取得）

## 処理
1. JIRAから当該プロジェクトの全チケットステータスを取得
2. フェーズごとに「完了率」を算出（チケット重み付け加算）
3. EV = 各フェーズの完了率 × weight × total_budget_pd を合計
4. PV = 当日までに「計画上完了しているはず」のフェーズ進捗を線形補完
5. AC = タイムシートMCPから当週までの累計実工数を取得
6. SPI = EV / PV、CPI = EV / AC を算出
7. バーンダウン用CSV（日付・残予算PD）も生成

## 出力フォーマット
- ファイル名：`tmp/evm/{project-id}/{YYYY-MM-DD}.md`
- 章立て：①サマリー（PV/EV/AC/SPI/CPI） ②フェーズ別進捗表 ③SPI/CPI推移 ④バーンダウン参照CSV ⑤PMコメント（**空欄**）

## 厳守
- 数値はMCP経由のみ。前週の値を引用しない
- データ取得失敗の項目は `（取得失敗）` と明記
- ⑤PMコメントはAIが書かず、PMが手で埋める

「PMコメントは空欄」がポイント。EVMは数字より「数字の解釈」が重要なので、AIに解釈まで任せると経営報告でブレます。

ステップ3：CLAUDE.mdにコスト運用ルールを書く

## EVM・コスト管理運用ルール

### 出来高（EV）判定基準
- 「ステータス=Done」のチケットを完了とカウント
- 「In Review」「QA」段階のチケットは0.5として扱う
- フェーズの完了率は「フェーズに紐づくチケットの重み付け加算」で計算

### AC計上ルール
- タイムシートの「PROJ-2026-A」タグ付き工数のみ集計
- 営業・提案フェーズの工数はACに含めない（別管理）
- 残業・休出は通常工数と同じ単位で計上（コスト換算は別ファイル）

### 報告タイミング
- 月曜：evm-weekly Skill実行
- 火曜：PMコメントを埋め、ステアリング前日資料に展開
- SPI<0.85またはCPI<0.85が2週連続でステアリングへエスカレーション

「SPI<0.85が2週連続でエスカレーション」のような閾値ルールを書いておくと、毎週の判断に迷いません。

ステップ4：実際の運用フロー

毎週月曜の運用は次の通りです。

PMが claude を起動し /evm-weekly PROJ-2026-A を実行
生成された tmp/evm/PROJ-2026-A/{date}.md を開き、サマリー欄を確認
⑤のPMコメントに「先週のSPI低下要因」「今週の打ち手」を記入
docs/reports/evm/ に確定保存し、ステアリング向け資料に展開

慣れれば月曜午前で30分。残り時間を「SPI/CPIから何を意思決定するか」に振り向けられます。

期待効果と運用上の注意点

導入チームから報告される効果は3点です。

EVMが本当に毎週回る：手集計の苦痛が消えるため、運用が続く
数字の信頼性が上がる：MCP経由のため、PMの転記ミスがなくなる
経営報告に耐える数字が揃う：SPI/CPIの根拠を「ここから取った」と即答できる

落とし穴は次の3つ。

baseline.yamlの更新を忘れない：スコープ変更時はweightと予算を更新する。これを怠るとEVが歪む
ACの境界を曖昧にしない：「営業工数」「PMO工数」をACに混ぜると、CPIの意味が崩れる
SPI/CPIの解釈をAIに任せない：数字の意味は文脈次第なので、PMが必ず判断する

まとめ

EVMが続かないのはデータの分散と手集計の苦痛が原因
Skill＋MCPで3経路を統合し、PV/EV/AC/SPI/CPIを毎週自動算出する仕組みが作れる
baseline.yamlで「計画」を構造化することがEVM自動化の前提条件
数字の解釈はAIに任せず、PMがコメント欄で判断する設計が報告の信頼性を担保する

ここまでで「動くEVM自動集計器」は手に入ります。実務でこれを“経営の意思決定材料”に育てるには、コストモデルの設計、リスクバッファとコンティンジェンシーの分離、契約条件との接続といった上位設計が必要です。

IPJ-104『見積とリスクバッファ設計』と BIZ-201『数字で語るPM』を組み合わせると、本記事のSkillをベースに、見積〜実行〜経営報告まで一貫した「数字で語るPM」の体系を学べます。EVMの理屈は知っているが運用に乗らないPMが、最短で“動く運用”に到達するための導線です。