Huney

応用情報（AP） / マネジメント

コストマネジメントとは？COCOMO・ファンクションポイント法・EVMを基礎から理解しよう

プロジェクトのコストマネジメントで使われる標準タスク法、COCOMO、ファンクションポイント法、類推見積法と、進捗・コストを管理するEVMについて基礎から解説します。

読了時間：約15分
  • #コストマネジメント
  • #標準タスク法
  • #COCOMO
  • #ファンクションポイント法
  • #類推見積法
  • #EVM
  • #PV
  • #EV
  • #AC
  • #CPI
  • #SPI
  • #応用情報技術者試験

はじめに

システム開発を始めるときには、

このシステムを作るのに
何人必要？

何か月かかる？

いくら必要？

ということを考えなければなりません。

しかし、システムはまだ完成していません。

そのため、

完成していないシステムの規模や必要な工数を予測する

必要があります。

また、プロジェクトが始まった後には、

予算どおり？

予定どおり進んでいる？

このままのペースで大丈夫？

ということも確認する必要があります。

そこで今回は、

コストマネジメント
│
├─ 開発規模・工数の見積り
│   ├─ 標準タスク法
│   ├─ COCOMO
│   ├─ ファンクションポイント法
│   └─ 類推見積法
│
└─ 実行中の管理
    └─ EVM
        ├─ PV
        ├─ EV
        ├─ AC
        ├─ SV・CV
        └─ SPI・CPI

という流れで学んでいきましょう。

1. コストマネジメントとは

**コストマネジメント（Cost Management）**とは、

プロジェクトを承認された予算内で完了させるために、必要なコストを見積もり、予算を設定し、実績を管理すること

です。

システム開発では、

人件費
機器購入費
ソフトウェア費
クラウド利用料
外注費

など、さまざまなコストが発生します。

その中でもシステム開発では、

どれくらいの作業量が必要なのか

を見積もることが重要です。

開発規模の見積り

2. なぜ開発規模を見積もるのか

例えば、あるシステムの開発に、

100人月必要

だと分かったとします。

1人月とは、

1人が1か月作業する量

を表す単位です。

例えば、

10人 × 10か月
= 100人月

のように考えられます。

必要な工数が分かれば、

工数
 ↓
必要な人員
 ↓
開発期間
 ↓
人件費
 ↓
プロジェクト予算

というように、コストやスケジュールを検討できます。

そのため、プロジェクトの早い段階で開発規模や工数を見積もることが重要です。

標準タスク法

3. 標準タスク法とは

標準タスク法とは、

開発作業をタスクに分解し、それぞれに標準的な工数を設定して積み上げることで、全体の工数を見積もる方法

です。

例えば、

システム開発
│
├─ 要件定義
├─ 設計
├─ プログラミング
├─ 単体テスト
└─ 結合テスト

という作業があるとします。

それぞれについて、

タスク 見積工数
要件定義 10人日
設計 20人日
プログラミング 40人日
単体テスト 20人日
結合テスト 10人日

と見積もれば、

10 + 20 + 40 + 20 + 10

= 100人日

となります。

4. WBSとの関係

標準タスク法を考えるときは、前の記事で学んだWBSと結び付けると分かりやすくなります。

WBS
 ↓
作業を細かく分解
 ↓
各作業の工数を見積もる
 ↓
工数を積み上げる
 ↓
プロジェクト全体の工数

つまり、

仕事を細かくして、一つずつ見積もって足す

という考え方です。

細かい作業まで分かっているほど、具体的な見積りを行いやすくなります。

COCOMO

5. COCOMOとは

**COCOMO（Constructive Cost Model）**とは、

ソフトウェアの規模などをもとに、開発に必要な工数や期間を数理モデルによって見積もる方法

です。

代表的には、

プログラムのコード量

を規模の指標として利用します。

例えば、

想定コード量
      ↓
   50 KLOC
      ↓
COCOMOのモデル
      ↓
必要工数を推定

というイメージです。

6. KLOCとは

COCOMOを学ぶと、

KLOC

という単位が登場します。

KLOCは、

Kilo Lines Of Code

のことで、

1 KLOC
= 約1,000行のコード

を意味します。

つまり、

50 KLOC
≈ 50,000行

です。

コード量などの開発規模を入力として、モデルに基づいて工数を見積もります。

7. COCOMOの特徴

COCOMOのポイントは、

ソフトウェアの規模と開発工数には一定の関係がある

と考えて見積もることです。

単純なイメージでは、

ソフトウェア規模
        ↓
     大きい
        ↓
必要な開発工数
        ↓
     大きい

となります。

ただし、実際の開発工数はコード量だけでは決まりません。

  • 開発者の能力
  • システムの複雑さ
  • 開発環境
  • 要求される信頼性

など、さまざまな要因の影響を受けます。

8. COCOMOの注意点

COCOMOはコード規模を利用するため、

開発前なのに、
コードが何行になるか分かるの？

という問題があります。

特にプロジェクトのかなり早い段階では、最終的なコード量を正確に予測することは簡単ではありません。

そこで、

利用者から見たシステムの機能

に注目して規模を見積もる方法があります。

それがファンクションポイント法です。

ファンクションポイント法

9. ファンクションポイント法とは

**ファンクションポイント法（Function Point Method）**とは、

利用者から見たシステムの機能をもとに、ソフトウェアの規模を見積もる方法

です。

コードが何行になるかではなく、

どんな入力がある？

どんな出力がある？

どんなデータを扱う？

どんな問い合わせ機能がある？

といった機能に注目します。

10. ファンクションポイントの考え方

例えばECサイトなら、

ユーザー登録
ログイン
商品検索
商品登録
注文
決済
注文履歴表示

などの機能があります。

それぞれについて、

機能の数
   ×
複雑さに応じた重み

などを考えてポイント化します。

そして、

FP（Function Point）

という値でシステム規模を表します。

11. なぜファンクションポイント法を使うのか

例えば同じシステムを、

Javaで作る

Pythonで作る

C#で作る

場合を考えてみましょう。

同じ機能でも、使用する言語によってコード量は変わる可能性があります。

しかし、

商品を検索する
注文する
注文履歴を見る

といった利用者から見た機能そのものは変わりません。

そのためファンクションポイント法には、

特定のプログラミング言語に依存しにくい

という特徴があります。

12. COCOMOとファンクションポイント法の違い

大まかに整理すると、

手法 主に注目するもの
COCOMO ソフトウェア規模・コード量など
ファンクションポイント法 利用者から見た機能

覚え方としては、

COCOMO
→ どれくらいのソフトウェア規模？

ファンクションポイント
→ どれくらいの機能がある？

と考えると分かりやすいです。

類推見積法

13. 類推見積法とは

**類推見積法（Analogous Estimating）**とは、

過去に実施した類似プロジェクトの実績を参考にして、新しいプロジェクトの工数やコストを見積もる方法

です。

例えば過去に、

社員管理システム
開発期間：6か月
工数：50人月

というプロジェクトを行っていたとします。

今回、

顧客管理システム

を開発するときに、

前回と規模や機能が似ている

↓

前回は50人月だった

↓

今回は少し大きいから
60人月くらいでは？

というように見積もります。

14. 類推見積法の特徴

過去の実績を利用できるため、

  • 比較的簡単に見積もれる
  • プロジェクト初期でも利用しやすい

というメリットがあります。

一方で、

過去のプロジェクトと
今回のプロジェクトは
本当に同じ？

という問題があります。

技術・メンバー・要求・規模などが大きく異なれば、過去の実績をそのまま使うことはできません。

つまり、

似たプロジェクトの実績がどれだけ参考になるか

が重要になります。

15. 見積手法を整理しよう

ここまでの4つを整理します。

手法 基本的な考え方
標準タスク法 作業を分解して工数を積み上げる
COCOMO ソフトウェア規模などからモデルで工数を推定する
ファンクションポイント法 利用者から見た機能から規模を求める
類推見積法 過去の類似プロジェクトから推測する

🍯 「作業を足す＝標準タスク」「コード規模＝COCOMO」「機能を見る＝FP」「過去を見る＝類推」と整理すると覚えやすいです。

EVM

16. EVMとは

ここまでは、

プロジェクト開始前の見積り

を中心に見てきました。

しかしプロジェクト開始後には、

予定どおりのコストで、予定どおり作業が進んでいるか

を確認する必要があります。

そこで使われるのが、

EVM（Earned Value Management）

です。

EVMとは、

プロジェクトの進捗とコストを金額などの共通尺度で定量的に管理する手法

です。

17. なぜ「使った金額」だけではダメなのか

例えば、

予算：1,000万円
現在までに使った金額：500万円

だったとします。

一見すると、

まだ半分しか使っていない！
順調！

と思うかもしれません。

しかし実際の進捗が、

20%

だったらどうでしょうか。

予算の50%を使っているのに、仕事は20%しか終わっていません。

これは問題ですよね。

つまり、

コストだけではなく「そのコストでどれだけの仕事を終えたのか」を見る必要がある

ということです。

18. EVMの3つの基本指標

EVMでは、まず次の3つを覚えます。

PV
EV
AC

それぞれの意味を見ていきましょう。

19. PV

**PV（Planned Value）**は、

現時点までに完了する予定だった作業の予算額

です。

日本語では、

計画価値

などと呼ばれます。

例えば、

現在までに
600万円分の作業を
終えている予定

なら、

PV = 600万円

です。

つまり、

「今ごろ、いくら分の仕事が終わっている予定だった？」

を表します。

20. EV

**EV（Earned Value）**は、

実際に完了した作業を予算額で評価した値

です。

例えば、

実際に完了した仕事
= 500万円分

なら、

EV = 500万円

です。

重要なのは、

実際に使った金額ではない

ことです。

EVは、

「実際に、いくら分の仕事を終えた？」

を表します。

21. AC

**AC（Actual Cost）**は、

実際に完了した作業のために発生した実コスト

です。

例えば、

実際に使った金額
= 700万円

なら、

AC = 700万円

です。

つまり、

「実際にいくら使った？」

を表します。

22. PV・EV・ACを整理する

ここはEVMで最重要です。

PV
→ いくら分終わっている予定？

EV
→ 実際にいくら分終わった？

AC
→ 実際にいくら使った？

例えば、

PV = 600万円
EV = 500万円
AC = 700万円

だったとします。

この3つから、

  • スケジュールは遅れているのか
  • コストを使いすぎているのか

を判断できます。

スケジュール差異

23. SVとは

**SV（Schedule Variance：スケジュール差異）**は、

SV = EV - PV

で求めます。

先ほどの例なら、

EV = 500万円
PV = 600万円

SV
= 500 - 600
= -100万円

です。

SVがマイナスなので、

予定より進捗が遅れている

と判断できます。

24. SVの見方

SV > 0
→ 予定より進んでいる

SV = 0
→ 予定どおり

SV < 0
→ 予定より遅れている

です。

SVでは、

EVとPVを比較する

のがポイントです。

コスト差異

25. CVとは

**CV（Cost Variance：コスト差異）**は、

CV = EV - AC

で求めます。

先ほどの例では、

EV = 500万円
AC = 700万円

CV
= 500 - 700
= -200万円

です。

CVがマイナスなので、

実際の成果に対してコストを使いすぎている

と判断できます。

26. CVの見方

CV > 0
→ 予算面で良好

CV = 0
→ 予算どおり

CV < 0
→ コスト超過

です。

SPI

27. SPIとは

差額ではなく、割合でスケジュール効率を見ることもできます。

それが、

SPI（Schedule Performance Index）

です。

計算式は、

SPI = EV ÷ PV

です。

先ほどの例なら、

SPI
= 500 ÷ 600
≒ 0.83

となります。

28. SPIの見方

SPI > 1
→ 予定より進んでいる

SPI = 1
→ 予定どおり

SPI < 1
→ 予定より遅れている

です。

今回の、

SPI ≒ 0.83

は1未満なので、予定より遅れていると判断できます。

CPI

29. CPIとは

コスト効率を見る指標が、

CPI（Cost Performance Index）

です。

計算式は、

CPI = EV ÷ AC

です。

今回なら、

CPI
= 500 ÷ 700
≒ 0.71

です。

30. CPIの見方

CPI > 1
→ コスト効率が良い

CPI = 1
→ 予算どおり

CPI < 1
→ コスト効率が悪い

となります。

今回の、

CPI ≒ 0.71

は1未満なので、

コスト効率が悪い

状態です。

31. EVMの計算をまとめてみよう

条件が、

PV = 600万円
EV = 500万円
AC = 700万円

なら、

スケジュール差異

SV = EV - PV

= 500 - 600

= -100万円

→ 予定より遅れている

コスト差異

CV = EV - AC

= 500 - 700

= -200万円

→ コスト超過

スケジュール効率

SPI = EV ÷ PV

= 500 ÷ 600

≒ 0.83

→ 1未満なので遅れている

コスト効率

CPI = EV ÷ AC

= 500 ÷ 700

≒ 0.71

→ 1未満なのでコスト効率が悪い

つまり、このプロジェクトは、

スケジュール
→ 遅れている

コスト
→ 使いすぎている

というかなり危険な状態だと判断できます。

32. EVMの覚え方

式だけ暗記すると、

EV - PV？

PV - EV？

EV ÷ AC？

AC ÷ EV？

と混乱しやすくなります。

そこで、

PV = Plan
→ 予定

EV = Earned
→ できた仕事

AC = Actual
→ 実際に使ったお金

と意味から覚えましょう。

そして、

スケジュールを見る

できた仕事 ÷ 予定

EV ÷ PV

なので、

SPI = EV / PV

コストを見る

できた仕事 ÷ 実際のコスト

EV ÷ AC

なので、

CPI = EV / AC

です。

🍯 EVMでは「EVを中心に考える」とかなり覚えやすくなります。

33. コストマネジメントの全体像

今回の内容を整理すると、

プロジェクト開始前
│
├─ どれくらいの規模？
├─ どれくらいの工数？
└─ どれくらいのコスト？
        ↓
見積り
│
├─ 標準タスク法
│   └─ 作業を分解して積み上げる
│
├─ COCOMO
│   └─ ソフトウェア規模などから推定
│
├─ ファンクションポイント法
│   └─ 機能から規模を求める
│
└─ 類推見積法
    └─ 過去の類似案件から推定
        ↓
プロジェクト開始
        ↓
EVM
│
├─ PV：予定
├─ EV：実際の成果
└─ AC：実際のコスト
        ↓
├─ SV：スケジュール差異
├─ CV：コスト差異
├─ SPI：スケジュール効率
└─ CPI：コスト効率

つまり、

開始前は「いくら必要かを見積もる」、開始後は「予定と実績のズレを管理する」

と考えると、コストマネジメント全体が整理できます。

まとめ

この記事で覚えること

  • コストマネジメントでは、コストを見積もり、予算を設定し、実績を管理する
  • 標準タスク法は、作業を分解して各作業の工数を積み上げる
  • COCOMOは、ソフトウェア規模などをもとに数理モデルで工数を見積もる
  • KLOCは約1,000行のコードを表す単位
  • ファンクションポイント法は、利用者から見た機能をもとにソフトウェア規模を見積もる
  • ファンクションポイント法は特定のプログラミング言語に依存しにくい
  • 類推見積法は、過去の類似プロジェクトの実績から見積もる
  • EVMは進捗とコストを共通の尺度で定量的に管理する手法
  • PVは現時点までに完了する予定だった作業の予算額
  • EVは実際に完了した作業を予算額で評価した値
  • ACは実際に発生したコスト
  • SV = EV - PV
  • CV = EV - AC
  • SPI = EV / PV
  • CPI = EV / AC
  • SV・CVがマイナスなら基本的に悪い状態
  • SPI・CPIが1未満なら基本的に悪い状態

🍯 はちみつメモ

コストマネジメントは「始める前」と「始めた後」で整理しよう。始める前は、標準タスク法・COCOMO・ファンクションポイント法・類推見積法で規模や工数を見積もる。始めた後はEVMで「予定＝PV」「できた仕事＝EV」「実際に使ったお金＝AC」を比較する。EVMはEVを中心に考えれば、SV・CV・SPI・CPIの式も覚えやすい！