「ソフトウェア見積り」を読みました。

これを読んで良い見積りができる気はしませんが、できない言い訳をする時に使える薀蓄は得られます。

第5章「見積りに影響するもの」に、COCOMO II(http://sunset.usc.edu/research/COCOMOII/cocomo_main.html)の工数に関する補正因子の紹介があります。ある事柄がどれだけソフトウェア開発を大変にするか、という指標(経験則?)です。以下、一部を引用します。影響度は工数を増加させる割合です。影響度が1.5なら、工数が1.5倍になるという意味です。

• 再利用を考慮した設計: 影響度 1.31
• 文書化要求の程度: 影響度 1.52
• 複数サイトでの開発: 影響度 1.56
• 要員の継続性(離職率): 影響度 1.59
• プログラマの(一般的)スキル: 影響度 1.76
• チームの結束: 影響度 1.29
• ソフトウェアツールの活用: 影響度 1.50

この数値はどういう基準なんだ?、と突っ込みたいものばかりです。再利用の考慮と言っても、レベルはいくらでもあります。プログラマのスキルなんて計測しようがありません。あるタスクにどれだけの工数がかかるかで開発者のスキルは測ったとしたら、上の1.76という数値は、工数の影響度が1.76になるようにスキルを測ったトートロジーになってしまいます。チームの結束の基準も意味不明です。ソフトウェアツールの活用も、基準が分からないとなんとも言えません。emacsを100、catを1として、対象ツールをすべてプロットしてくれれば何か判断できるかもしれません。

これらの数値に意味は感じませんが、とりあえず都合よく利用するのが良いでしょう。「文書化が大変そうなので1.5倍の工数がかかります」と言うと、「なんでそんなに工数が増えるんだ」と突っ込まれますが、「COCOMO IIの文書化要求の補正因子により、工数を1.5倍にします」と言えば、「COCOMO IIなら仕方ないか」と納得してくれるはずです。それでも納得しない場合、COCOMO IIのサイトから難しい数式を引用してください。どうせ誰も分からない数式なので文句を言う人はいません。

第19章「工数の見積りの課題」に、ソフトウェア規模と生産性の表があります。一部だけ引用します。ソフトウェアとコード行数と生産性(一人が一年に書く平均行数)です。

• Lotus 123 v3 : 約40万行 : 1,500 LOC/人年
• MS Excel v3 : 約65万行 : 13,000 LOC/人年
• Windows NT 3.1 : 約288万行 : 1,400 LOC/人年
• スペースシャトル : 約2,560万行 : 1,200 LOC/人年

以前、ソフトウェアの規模に関する見解を書いたことがあります(http://dev.ariel-networks.com/blog/inoue.php?blogid=2&archive=2003-12-24)。この見解は今でも変わっていません。

10万行のオーダーのソフトウェアなら、いつでも開発に参加できる気はしています。100万行のオーダーは、個人的にはNotesの開発で経験していますが、今から100万行のオーダーのソフトウェア開発に参加する気があるかと問われれば、正直、自分の残り寿命との天秤になります。そこまで自分を賭けるだけの価値があるかどうかを見極めないと足を踏み出せません。100万行のオーダーのソフトウェアというのはそういうものです。

そういう目で見るスペースシャトルの2,560万行...スペースシャトルなら人生を賭ける意味があるのでしょう。なんと言っても、NASAには「本物のプログラマ」(http://www.genpaku.org/realprogrammerj.html)がいます。余談ですが、最近、「本物の女子大生はPASCALを使わない」ことが判明しました。

同じく第19章にISBSG(http://www.isbsg.org/)の人月の公式がでてきます。プロジェクトの種類が一般の場合、次のような式です。

人月 = 0.512 x (ファンクションポイント数) ** 0.392 x (最大チーム人数) ** 0.791

冗談にしか見えない式ですが、作った人はマジメなんでしょう。人数が増えると、工数(上の式では人月)が増加することだけは分かります。

第20章「スケジュールの見積りの課題」でも似たような話が続きます。Lawrence Putnamの研究によれば、チームの最適の人数は5から7人という結果がでているようです。これは個人的な経験則とも合致します。