連載
» 2009年01月15日 12時00分 公開

プロジェクトの闇、見積もりに光を!(3):見積もり仮想体験の旅へ、いざ出発! (2/3)

[佐藤大輔(オープントーン),@IT]

COCOMO II法をFP法の係数として利用する

 次はCOCOMO II法です。この方法によりタスクの深さや品質の重さを加味していくのです。

 COCOMO II法は、本来LOC(Lines of Codes)を用いた類推見積もりの方法として用いられてきましたが、近年FP法が一般的になるに従って、FP法の係数要素として用いられるケースが多くなりました。

 本来は算出されたLOC単位の見積もりに対してこれらの因子を用いますが、今回はFPに対する要素として用います。

ALT 表3 COCOMO II法での実測表。因子ごとの影響が一番右の影響度に入る。例えばアプリケーション開発の経験が非常に低いプロジェクトチームが担当すると、アプリケーション開発の経験が非常に高いプロジェクトチームの1.51倍の工数が必要となるという意味。それぞれの因子で影響度は変わる。表の赤で囲った部分が、今回採用した数値

 例えばここに、COCOMO II法の因子を掛けてみましょう。係数の出し方をまず説明します。添付の表にあるように因子を埋めていき、表中の各因子の値と影響度を掛けて、最終的な平均値を出します。

 例えば、アプリケーションの経験の高さは、アプリケーションの開発工数に0.88倍の影響を与えることになります。プロダクトの複雑さが非常に高いことは工数を1.34倍増やすことになります。このことから、出た因子の結果をことごとく乗算していけば、COCOMO II法による工数の補正ができることになります。

 今回の表で計算すると、影響度の合計値は1.075318になります。今回は補正値が少なく出ていますので、あまり影響はありません。この数値で計算すると、次のようになります。

1100万円×1.075318=1180万円

 このようにISBSG法での見積もりでは、チームの規模と金額と納期を推し量ったうえに、タスクの深さや品質の重さなどは、COCOMO IIの因子を利用することで簡易的に組み込むことができます。

 さて、ここまでの方法で、機能の広さからタスクの深さや品質の重さを類推して見積もったことになります。

 ただし、ここまでの計算では、FP法を基本としていることから、どうしても機能の広さによるアプローチが中心となります。そのため、機能の数が同じであれば、同じような見積もりが出てしまう傾向があります。例えば、ミッションクリティカルな金融機関のシステムと簡単なアンケートサービスのような可用性要件の低いシステムで、機能数が同じであれば同じような見積もりが出てしまう可能性があるわけです。

タスク積み上げ法による見積もり

 では次にタスクで見積もる手法、つまりWBS(Work Breakdown Structure)法について見てみましょう。

 WBS法は、かなり以前から用いられている手法です。タスクの数や量を基準に類推を行うので、深さを基準に測ります。

 この方法はタスクを中心に測るので、品質次第で、テスト工程の数やドキュメント化の程度など作業量を測ることができます。そういう意味では品質の重さもカバーします。

 システム開発においては、ミッションクリティカル性などが要求される程度によって、テストの程度はだいぶ変わります。それによって、同じ機能のテストでもコストは大幅に変わります。ミッションクリティカル性の低いシステムであれば、レビューやテストはそれぞれ1度ずつ程度でいいかもしれません。

 しかし、ミッションクリティカルなシステムになれば、単体テスト、チーム内結合、システム内結合、システム間接続、業務シナリオテスト、検収納品テストなど、必要に応じてどんどん膨らんでいきます。

 このことは、機能の数とは関係なく増えていくことになります。では、このシステムのタスクから深さという切り口の見積もりを見てみましょう。

 タスクベースの見積もりからは機能の数だけでなく、テストの階層の深さやレビューの回数、あるいは納品物にマニュアルが含まれるのか、システムのユーザーに教育を行うのか、といったさまざまな要素を把握することができます。

 もちろん粒度をもっと細かくしていけば見積もりの精度も上がっていくでしょう。タスクベースの見積もり手法では一般的に、WBS法を使った見積もりを作成します。

 WBSと連動して管理可能になるので、こういった見積もり手法はよく用いられています。特に作業内容から工数を類推しやすい保守開発などでは、多くの場合この方法が用いられています。

 しかし、WBS法の欠点は、ある程度設計や顧客とのタスクに関する合意が進まなければタスクを割り出すことができず、概算という用い方が困難になるということです。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ