読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

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

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

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

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

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

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

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

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

理想論だとね。

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

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

変化に強いソフトウェアが求められる時代

基準を満たすコードはバグが少なく、保守性が高い。つまり変化に強い。ソフトウェアは日々成長するし、要件もいずれは変わるものだ。この前提を認める世界でこそ、メトリクスは生きる。

オープンソース開発はメトリクスと親和性が高い。開発者のレベルが高く、高品質を追求する姿勢はメトリクスの理念と合致する。「オープンソース開発のような開発手法」を採用する企業は、メトリクスをもっと積極的に導入してほしい。そして、共同研究を盛り上げてほしい。

日本でも。