Agonizing Days: ソフトウェア開発見積もり

またもや更新間隔が空いてしまいました。けっこうプロジェクトで苦しんでいます。うーむ。
現在直面している問題は「ソフトウェア開発見積もり」です。うげげ。
というわけで、改めて色々と整理をしてみるエントリになります。興味の無い人はスルーして下さい。

まずは、「ソフトウェア開発見積もり」の大前提。セントラルドグマかもしれないけど。

「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」
コストは人数と歳月の積に比例するが、仕事の進み方は必ずしもこれとは一致しない
人数と時間には互換性は無い(9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない)
フレデリック・ブルックス「人月の神話」

「プロジェクトを大失敗させる原因は二つある。ひとつは、見積もりミスだ」
楽観的な見積もり：見積もり根拠があいまいで、必要な要素をきちんと見積もっていない
顧客側による(一方的な)コスト削減要求
ムリなプロジェクト
ロバート・L・グラス「ソフトウェア開発55の真実と10のウソ」

あと、個人的に重要だけど忘れられがちなのは次の定理(?)

「コストやスケジュールを予測する場合、まずソースコードの行数を見積もる・・・というのはウソ」
コストやスケジュールより、LOC予測する方が難しい(1980年代に証明済み)
ロバート・L・グラス「ソフトウェア開発55の真実と10のウソ」

現実の見積もり方法に関してですが、とりあえずWebで概要をつかむには日経ITProさんの上流工程AtoZというサイトが良い感じです。

さて、ソフトウェア開発見積もりですが、個人的な理解は以下の通りです。
Step1. まず、開発しようとしているソフトウェアの規模を見積もる。
Step2. 見積もったソフトウェアの規模を実現するための、作業を見積もる。
これをごっちゃにすると、かなり神頼みの見積もりになってしまうというのが個人的な意見です。

■ソフトウェアの規模見積もり
これも個人的な知識のまとめですので、間違っているかもしれませんが、ソフトウェアの規模見積もり方法は以下の3つが代表的です。

勘と経験と度胸法(通称KKD法)
基本的に見積もった人がどれくらい信用できるかに依存しますが、かなり的確な見積もり手法です。そもそも、作ってもいないソフトウェアの規模なんて想像し難いワケですから。ただし、個人的には以下に注意しています。
「見積もった人が冥界にお住まいの場合」→1日が20時間くらいの計算になっている可能性あり。
「見積もった人が勉強不足で、今回のアーキテクチャをよく分かっていない」→論外。しかし、ありがち。