http://www.coltware.com/2010/02/04/estimate_system_development/ おもにFlex, PHP, Javaといった言語を使った開発のおぼえがきを書いています。 Wed, 09 Nov 2011 00:20:31 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://www.coltware.com/2010/02/04/estimate_system_development/comment-page-1/#comment-72 Y Fri, 12 Feb 2010 01:01:22 +0000 http://www.coltware.com/?p=934#comment-72 面白く、よく考えられた理論だと思います。 体系化して工数を組む方というのは、記事で触れられているように 非常に稀だと感じます。みな、どんぶり勘定で保険の+αを上乗せして 見積もるのが定石でしょうね。 そこで、こういった理論式を実装した見積もりソフトを作り、 商談の際にはそれでパッと工数を提示すれば、 顧客も実績のある開発見積もりと信頼感を抱くでしょうね。 ただしやはり「ぶれ」要因はどうしても予測できない気がします。 そこで、結びにあるように、 いくつかのパターンを用意して、プロジェクトの内容に適した ぶれ係数を加味するのがいいですね。 大抵はメンバーのスキル格差、開発実績の有無、外部要因による遅延 （プロジェクトが輻輳している際には大抵バグフィックスのための 　時間を別プロジェクトに取られてしまいます） あたりが代表的だと思います。 いろいろなソフト開発モデルがあるのに、工数見積もりがなかなか 難しいのは、やはり、人間がソフトを作るからでしょうね。 面白く、よく考えられた理論だと思います。
体系化して工数を組む方というのは、記事で触れられているように
非常に稀だと感じます。みな、どんぶり勘定で保険の+αを上乗せして
見積もるのが定石でしょうね。
そこで、こういった理論式を実装した見積もりソフトを作り、
商談の際にはそれでパッと工数を提示すれば、
顧客も実績のある開発見積もりと信頼感を抱くでしょうね。
ただしやはり「ぶれ」要因はどうしても予測できない気がします。
そこで、結びにあるように、
いくつかのパターンを用意して、プロジェクトの内容に適した
ぶれ係数を加味するのがいいですね。
大抵はメンバーのスキル格差、開発実績の有無、外部要因による遅延
（プロジェクトが輻輳している際には大抵バグフィックスのための
　時間を別プロジェクトに取られてしまいます）
あたりが代表的だと思います。
いろいろなソフト開発モデルがあるのに、工数見積もりがなかなか
難しいのは、やはり、人間がソフトを作るからでしょうね。

]]>