工数と行数
SIer寄りの風土で開発をしていると工数見積もりに実効行数(ステップ数)を基準にすることが多い。個人的には全くあてにならない指標だと思うのだけど、それについて少し考えてみた。
言語機能がショボく、既存設計の把握や機能テスト、結合テストに費やされる時間が多くを占める場合(①)は、
工数 = 実効行数 * 係数
という式が成り立つと思われる。
組み込みの世界では実際、言語機能がショボいC言語が主に使われるし、フリースタンディングな環境の場合、標準ライブラリについてもほぼ使わないので、この仮定は成り立ちそうだ。
さらに、組み込みでは過去の機種からの派生で開発を進めたり、機種別にソースコードを分けたりする文化がある。そのため、他機種で開発に掛かった工数と実効行数から、係数を求めることができる。
おそらく、あるコードを別の銀行システムに流用したりとかで、金融系でも似たような事情があるのだろうと思う。
でも、WebやPCアプリの世界で使われる言語では、C言語で何百行も書かないといけない処理がラムダ式やライブラリに任せてしまうと1行で済んだりすることもよくある。
つまり、コード行数とソフトの規模が一致しない。
また、新規開発には全く通用しない。行数も係数も未知だからである。機能の80%ぐらいを実装したかなってところで欠陥が見つかって0%に戻るなんてこともありうるし、デバッグでいくらでも工数が膨れ上がるということもある。人間の技能にも左右される。
あと、以下のような見方もできると思った。
工数 = (派生ソフトと)共通部分の工数 + 差異部分の工数
この見方だと、行数って開発工数に関係なくね？となる。よくよく考えれば派生ソフトなのだから実効行数が近いのは当然*2だし、掛かる工数が近いのも当然である。当然ながら係数も近い。
なので、共通部分の占める割合が支配的なうちは、これで見積もりがうまくいってしまう。
さらに言えば、差異部分の大半が移植などではなく新規開発部分と仮定した場合、差異部分の工数は未知になってしまう。つまり、新規開発が多い場合は、感覚で見積もりするのと変わらない。つまり、本当に世の中に革新的な製品を作るという目的のプロジェクトにおいては行数で見積もることに全く意味はないと思う。
できあいのモジュールを付けたり外したりしてるだけの開発で、先ほどの前提条件（①）が成り立つうちならうまくいくかもしれない。
青字は追記
