ソフトウェアメトリクスはエンジニアリングの夢を見るか

ソフトウェアの特性を定量的に表す指標として、ソフトウェアメトリクス（以下、メトリクス）がある。広義ではアーキテクチャ設計についての指標も含むが、一般にはソースコードから自動計測して収集できるソースコードメトリクスが有名だ。

メトリクスの例を挙げてみよう。

ソースコードの行数（LOC）: 長すぎるコードは嫌だ
コメントの量: コメントぐらい書けよ！ハゲ！
制御構造の複雑さ: 分岐多すぎ。。。読めねぇ。。。
クラス間の依存関係: 調子に乗って継承使いすぎ
クラスの独立性: このクラスもっと分割できるんじゃね？
メソッド当たりのステートメント数: このメソッド長すぎじゃね？

こういう指標を計測して、それらと保守性との関係を調べる。すると、基準値が算出される。基準を満たすようにプログラムを書けばいいわけだ。例えば、全体の20％ぐらいコメントを書けとか。

SI業界でメトリクスが使われない理由

ソフトウェア工場にメトリクスを導入するとどうなるだろうか？

基準を満たさないコードは作り直しを要求され、高品質なコードのみが出荷される。結果としてバグが少なく、保守性の高いソフトウェアが生産される。ソフトウェアの保守コストが下がり、また顧客要件に対応するための改造工数も減少する。

理想論だとね。

しかし、基準を満たすコードを作るには2倍近い工数が必要になる（と経験的に思う）。さらに、ある程度経験を積んだプログラマが必要になるため人月単価が上昇する。昨日まで何やってたか分からないようなプログラマは、基準を満たすコードが書けるまでかなりの時間を要するだろう。

工数が増加して人月単価が上昇すれば、ソフトウェアの製造コストは爆発的に増大する。こんなことに金をかけてると将来回収できる保証もないし、リスクがでかすぎる。それならば、手っ取り早く安く作れる方法を選ぶわけだ。そもそも、顧客ごとにソフトウェアを再生産してるのだから量産効果が出ない。保守コストで儲けようとしてるのに、コイツを下げるわけにはいかない。