連載:プロジェクトの闇、見積もりに光を!(1)

見積もり、まずはざっくり理解せよ

株式会社オープントーン
佐藤 大輔

2008/8/7

前のページ1 2第2回

(A)機能ベースの見積もりアプローチ

 機能ベースのアプローチは、例えば画面の枚数であり、ユースケースの数といったシステムの機能の数を見積もりの基準とする方法です。FPのような外部から見た機能の数を計測するような手法で、最初に行うアプローチです。

 例えば経理システムであれば、帳簿の管理という機能のほかに、自動的に振り込む機能や給与明細を送付する機能といった、1つ1つの機能のコストを積み上げていく方法です。以下の表のようにして「見積もり」をすることができます。

機能ベースのアプローチの例
プロジェクト初期に数えられるもの
ビジネス的要求
機能
ユースケース(粒度:粗)
ストーリー
基本設計後に数えられるもの
画面(あるいはWebページ)
データベース
クラス
コード行数(想定で)
テストケース
ユースケース(粒度:密)

(B)タスクベースの見積もりアプローチ

- PR -

 今度はタスクベースの見積もりを見てみましょう。フェイズやアクティビティ、タスク、といった要素も見積もりの計測対象となります。

 例えばフェイズのうち、要件定義にどれくらいのコストが掛かり、設計にどれだけ掛かるかという見積もりのアプローチです。

 もちろんフェイズの粒度では粗過ぎますので、大抵はWBSを作成し、アクティビティ、可能であればタスクレベルまで落とし込み、見積もりを行う方法です。

 例えば、現行システム分析を行い、文書に起こすのには、5人日、新システムのモデルを検討するのに10人日かかります、という形で積み上げていく見積もりのアプローチになります。

 つまり、機能の数・規模が計測の対象であると同時に、実行せねばならないフェイズが見積もりの「深さ」を決定します。

 そして、フェイズはより粒度の細かいアクティビティやタスクによって、WBSレベルに分解されることで精度を増します。

 WBSレベルで分解していくことにより、より正確な見積もりが可能になっていきます。こうした、フェイズ、アクティビティ、タスクによる見積もりはFPやLOCを用いた見積りよりもより正確である半面、タスクの組み換えやフェイズの変更による柔軟性が欠けているともいえます。

(C)要求品質ベースの見積もりアプローチ

 今度は要求品質ベースの見積もりです。機能の数やタスクの多さのほかに非機能要件がさらに、重さを決定付けるともいえます。

 品質管理に割くコストはプロジェクトの特性によって大幅に変化します。社内掲示板と金融機関の基幹システムが同じ画面数・同じデータ項目だとしても、その品質管理コストが大幅に違うために、まったく違う見積もりを出すことになるでしょう。

 よってソフトウェアの特性や、見積もりの観点によっていくつもの手法を上手に用いる必要があるのです。

複数の見積もり手法を用いるための尺度

 先ほ見積もり手法間の情報共有のため変換可能な見積もりの尺度として、LOCとFP、MMを挙げました。

 LOCはプログラム行数のことです。近年オブジェクト指向言語により機能の数とコード行数が必ずしも一致しないとはいえ、コード行数は最も客観的で確実な尺度といえます。さらには、過去の資産を測り比べることができ、計測がツールで容易に計測できます。

 もちろん、過去の資産と比較するにしても、異なる言語、例えば、COBOLとJavaをコード行数で単純に比較することは無意味です。そのため、下記のように比較のための「変換値」が発表されています。

言語
C言語に対する比
C
1:1
C#
1:2.5
C++
1:2.5
COBOL
1:1.5
FORTRAN 95
1:2
Java
1:2.5
マクロアセンブラ
2:1
Perl
1:6
Smalltalk
1:6
SQL
1:10
Visual Basic
1:4.5
表2 言語ごとのC言語に対する比の比較表。『ソフトウェア見積り――人月の暗黙知を解き明かす』(スティーブ マコネル著、日経BPソフトプレス刊)の71ページの表を引用

 次にFPは、これまで何度か取り上げたファンクションポイント法のことです。FPの考え方は、本連載第2回以降で詳しく紹介する予定なので、ここでは尺度としての説明にとどめます。FPの大前提は言語によらない見積もりの手法として開発された尺度です。ですから、コード行数を計測するLOCに対して機能を計測する尺度になります。

 言語ごとに1FP当たりにどの程度の実装行数が必要かなどが研究されています。

言語
最小値
最頻値
最大値
C
60
128
170
C#
40
55
80
C++
40
55
140
COBOL
65
107
150
FORTLAN 95
30
71
100
Java
40
55
100
マクロアセンブラ
130
213
300
Perl
10
20
30
Smalltalk
10
20
40
SQL
7
13
15
Visual Basic
15
32
41
言語ごとに1FP当たりどの程度の実装行数が必要かを表した表。『ソフトウェア見積り――人月の暗黙知を解き明かす』(スティーブ マコネル著、日経BPソフトプレス刊)の218ページの表18-3から一部引用。原典は、『Estimating SoftWare Costs』(Capers Jones、T. Capers Jones著、McGraw-Hill Companies刊)、『Software Cost Estimation with Cocomo U』(Ellis Horowitz、Ray Madachy、Donald Reifer、Bert Steece、Bradford K. Clark著、Barry W. Boehm編集、Prentice Hall刊)、『Estimating Software-Intensive Systems』(Richard D. Stutzke著、Addison-Wesley Professional刊)

 こうして、複数の尺度をさまざまな言語に対して適用可能な形で提供することにより、複数のプロジェクトを横断的に計測することができます。そして、過去の資産の蓄積による見積もりの精度のアップにもつながります。

 MMは人月ですから工数そのものです。1人が1カ月で作業した結果生み出される「成果」を意味します。LOCやFPが算出された後に、そこから、MMが算出されます。「人月」が算出されれば、利益・間接費なども含んだ「1人当たりの価格」を掛けることでコストを算出できます。

尺度を用いるメリット

 MMを算出することで、コストだけではなく、必要な期間までも推し量ることができます。開発期間を導出するには、次の式を使います。なお、以下の式はあくまで参考値です。上の式は、『Software Engineering Economics』(Barry W. Boehm著、Prentice Hall刊)に最も多用されていて有効な概算式として紹介されていたものです。下は、『Structured Computer Project Management』(William Roetzheim著、Prentice Hall刊)に紹介されている式です。

  月 = 3.0 * MM^1/3
  スケジュール=過去のスケジュール * (MM/過去のMM) ^1/3

 もちろん、こんな簡単な式だけでスケジュールが算出できるわけではありませんが、指標として参考になります。

 例えばMMが20人月、50人月の場合は、上の式に当てはめると、開発期間はそれぞれおおむね8.1カ月、11カ月となります。

 この式は単なる乗算式ですから、人月に合わせて無限にスケジュールも伸びていってしまいます。ですから大きなプロジェクトの参考値にするのは厳しいですが、中規模以下のプロジェクトの指標としてはそれほど違和感のあるスケジュールではないのではないでしょう。

 さて、次回以降はいよいよ、さまざまなソフトウェアの特性や「切り口」に合わせて、複数の見積もり手法を使い実際に見積りの作業を行ってみましょう。

 また、今回学んだ尺度を用いて比較の作業も行ってみます。皆さんもぜひ同じように社内や周辺のプロジェクトを持ち寄って試してみてください。

筆者プロフィール
佐藤 大輔(さとう だいすけ)
株式会社オープントーン社長。会社設立前は大手システム会社などで多くのシステム開発に、主にマネージャとして携わった経験を持つ。
■要約■
見積もり手法として有名なものは、IBMのアレン・J・アルブレクトが提案し、その後改良されたファンクションポイント(FP)法だろう。しかし見積もり手法はそのほかにもたくさん存在する。

このようないくつもある見積もり手法間の情報共有のため、変換可能な見積もりの尺度の共通化が図られてきた。その尺度として定着したのが、LOC(Lines Of Code)、FP、それにMM(人月)である。

見積もりを行う際に考慮すべきことは、見積もり手法だけではない。見積もりへのアプローチの仕方も考慮すべきである。このアプローチには3つあり、機能ベース、タスクベース、それに要求品質ベースである。機能ベースのアプローチは、プロジェクトの初期に数えられるものと、基本設計後に数えられるものがある。タスクベースのアプローチは、フェイズやアクティビティ、タスクを見積もりの計測対称にするもの。このとき重要なのは、どこまでWBSなどでブレークダウンするかである。そして要求品質ベースのアプローチは、システムの品質管理の要求レベルによって異なる。

よってソフトウェアの特性や見積もりの観点によっていくつもの手法を上手に用いる必要があるのである。

前のページ1 2第2回

見積もり、まずはざっくり理解せよ
→ Page 1
さまざまな見積もりの手法
  Page2
複数の見積もり手法を用いるための尺度
尺度を用いるメリット



ホワイトペーパーTechTargetジャパン

@IT情報マネジメント メールマガジン 情報マネージャのための情報源(無料)


この記事に対するご意見をお寄せください managemail@atmarkit.co.jp

キャリアアップ

@IT Sepcial

イベントカレンダー

PickUpイベント

- PR -
もっと見る

TechTargetジャパン

@IT Sepcial
ソリューションFLASH

求人情報