HOME > ソフテックだより > 第70号(2008年7月16日発行) 現場の声編「ソフトウェア開発の見積もり2」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第70号(2008年7月16日発行)

現場の声編

「ソフトウェア開発の見積もり2」

1. はじめに

2008年5月21日発行のソフテックだより第66号「ソフトウェア開発の見積もり」に続きまして、具体的な見積もり方法の説明と、 現実の難しさについて考えてみたいと思います。まずは、どのようなソフトウェア見積もり方法があるのかを次に示します。

2. 見積方法について
(1). 概算法(KKD法)

最も多く利用されている方法(方法と呼べるものでもないですが・・・)です。

いわゆる概算であり、見積担当者の主観性:「経験(K)、勘(K)、度胸(D)」と技術力に依存するため、精度がまちまちです。
主観性の強い見積もりですので、見積もりの根拠性も薄く、お客様への説明もままならないことがあります。
同様に根拠が薄いため、同一プロジェクトの他のエンジニアへの説明もままならない場合があります。

それでも、熟練者の見積もりは概算法でも説得力があることも事実です。
また、見積担当者の経験や失敗をナレッジベースとしてまとめたりすることで、精度を上げられるのも事実です。

(2). 積算法(WBS法)

積算法では開発で必要となる作業を洗い出し、その作業ごとの工数を見積もって積み上げます。作業の洗い出しはワーク・ブレイクダウン・ストラクチャー(Work Breakdown Structure)の技法を用います。WBSとはプロジェクト全体を細かい作業に分割していく手法です。
見積もり精度は、WBSによって洗い出された作業項目の細かさに依存します。つまり、作業項目を洗い出せば精度をアップさせることができます。
しかし、欠点としまして洗い出し作業のために見積自体の工数が大きくなり、トータル費用や見積もり提示期間に影響してしまいます。

(3). COCOMO

COCOMO(COnstructive COst MOdel)は、開発規模をソースコード行数(LOC: Line Of Code)で表し、対応工数を見積もります。
簡単に式を示しますと、
[作業量]=[パラメータ1]×(ステップ数 ^ [パラメータ2])
となり、ステップ数とその作業量(工数)に一定の関係式があるという統計的推論に基づいてます。
担当者の経験に左右されない見積もりが得られますが、パラメータの設定が非常に困難です。また、開発もしていないプログラムのステップ数をどう把握するのかという欠点もあります。

(4). COCOMOII

オリジナルのCOCOMOは最近のソフトウェア開発環境の動向において、従来型の開発環境ほどには適合しにくくなってきました。
COCOMOIIは、COCOMOを改善し、1990年代から2000年代の開発環境に焦点が当てられた見積もり技法です。

COCOMOIIでは、開発プロジェクトの初期から設計・開発に向けて、3つのモデルがあります。

モデル 特徴
アプリケーション組み立てモデル GUIビルダーでの開発やプロトタイピングのような初期のステージに適用
初期設計モデル 全体のシステム構造が明確にされる前の一般的なレベルの見積もり
ポストアーキテクチャモデル 詳細なCOCOMOIIでシステム構造が決定された後に利用できる

表1. COCOMOII 3つのモデルの特徴

開発規模はソースコード行数で表し、それを工数に変換する式になっています。さらに、開発規模を推定するために、ファンクションポイントを用いて推定する事もできます。また、開発がまったくの新規ではなく、一部のシステムを再利用する場合にも使用できるように調整方法が組み込まれています。

(5). ファンクションポイント法(FP法)

FP法は、開発するソフトウェアの規模をその機能数(Function Point ファンクションポイント)で測ろうとするものです。機能を画面入力や帳票出力、使用ファイル、外部インターフェースの数によって測ろうという考え方です。
ユーザーにも分かりやすく、合意を得やすい見積もり手法です。但し、基準値の実績データ収集・評価基準が必要です。FP法にはいくつかの計測手法があり、IFPUG法やCOSMIC-FFP法という計測方法が存在しています。

信頼性・客観性を持ち合わせている手法ですが、欠点もあります。
FP法の算出は、要求仕様書から行います。つまり、要求仕様書が確定する以前には算出できません。また他の手法に比べると見積もり作業工数もアップしますし、見積もり手法の習得にも時間が必要です。

3. 見積方法の選択について

以上のようにいろいろな見積もり方法がありますが、それぞれにメリット・デメリットがあります。また、お客様が要求している見積もりレベルでも、どの方法が得策なのかを考える必要があります。たとえば、「予算申請用の概算レベルでよいから、とにかく早く欲しい」との要求に対してFP法で見積もりをしたのでは、お客様の要求を満たすことができません。

ただし、いずれの方法を選択する場合でも必ず考えなければいけないのは、「工数ではなく規模を見積もるように考える」ということです。
工数をいきなり見積もろうと考えるから、根拠がない見積もりが完成し、見積もり精度にずれが生じてしまいます。あくまでも工数は規模と生産性から計算されるものであり、そうすることで見積もり工数の裏付け(根拠付け)がされると考えています。

見積もり工数に根拠があれば、工程管理もスムーズに進み、品質面も確保しやすくなると考えます。

4. 現実の難しさ

私自身、これまでもいろいろとソフトウェア見積もりを対応してきました。
しかしながら、私自身もこれだという方法をつかみ切れていません。

ソフテックだより第66号「ソフトウェア開発の見積もり」でも記述しておりますが、見積もり方法に限らず、顧客要求の把握が一番難しい要因となります。
この部分、「要求仕様があいまい」であれば、正しい方法にて見積もりを作成しても、現実はずれが生じ、見積もりミスという結果になってしまいます。
見積もりミスは恐ろしいもので、コスト面だけではなく、品質、納期にも影響します。

とはいっても、引き合い初期の段階では、明確な要求仕様など決まっていないことがほとんどです。お客様によっては「一緒に要求仕様をまとめていきましょう」というお客様もいらっしゃいます。そういう場合は、概算見積もりという形で提示することになりますが、要求仕様が明確になり、いざ詳細見積もりを行ったら概算見積もりよりも金額がアップしてしまうということがあり、トータル予算に合わずお客さまからのクレームに発展する場合があります。

上記のような場合、概算見積段階では規模を計れませんから、「要求仕様をまとめるまでは工数ベースで見積もりを行い、要求仕様がまとまった後は規模ベースでの見積もりを行う」という2段構えで対応を行うこともあります。
また、概算見積もりであっても見積もりを提示するわけですから、見積もり条件の細目を明示して、お互い納得するようにコミュニケーションをとる必要があります。

私も多くの見積もりミスを経験してきましたが、やはり要求仕様の曖昧さからの見積もりミスが多くあります。
ソフテックでは極力見積もりミスを減らすために、見積もりのレビューを実施し、上司や同様なプロジェクトの経験者による意見を取り入れるような取り組みを行っております。

5. 終わりに

以上のように見積もりについて記述いたしましたが、やはり見積もりは難しいものです。
プロジェクト反省会の際に、良かった場合も悪かった場合も項目として「見積もり精度」があげられます。やはり、それだけ見積もりは重要であるということです。
ソフテックでも、日々努力を重ねて見積もり方法について良い物を取り入れていき、常に上を目指していければ良いと考えております。

(K.N.)

[参考文献]
経営情報研究会
「図解でわかるソフトウェア開発のすべて」 日本実業出版社 2000年

関連ページへのリンク

関連するソフテックだより

ページTOPへ