ランチとエンジニアの生産性
「エンジニアの生産性を測るのは難しいですね」
と隣でランチを食べているエンジニアが話を振ってくる。
『一般的にLOCのイメージだけど』と前置きして『同じ機能で1000行のコードと10行のコードとどっちが生産性が高いんですかね』と質問を被せてくる。
そんなものは決まっているじゃないか、と答える。
同じ機能なら、1000行のコードはリリースした瞬間、いや書いているときから（10行のコードと比較して）保守性がない。存在する瞬間から負債でしかない。
「じゃあ、どうしてLOCなんですかね」
「計測できるものがLOCと工数しかないからだよ」
まあ、LOCさえ計測していることはないのだが。なにせ、開発環境がお利口になって自動的にコードを補完するので業務ロジックの部分は少ない。でもコードとしては色々と情報を持っている。分離できないそれをどう測るのか。
第一、計測してどう使うのか。月間1700stepが多いのか少ないのか。少なければ生産性は悪いのか。
少なければ少ないLOCの方がマシだ。できたら作らないことが一番だ。これの考え方を否定するエンジニアはいないと思うのだが。
新しい指標として（それほどでもないが）価値があるかどうかという考え方がある。これは使われる機能のことであるが、これもまた計測できない。
「1000行のLOCでも使われていれば価値があることになりますね」
使うかどうかを稼働している時間と定義してしまうとそれも間違ったデータを稼働としてしまいかねない。1000行と10行のLOCと同じになる。
保守性が高いということは可読性も期待でき、結果、残すドキュメントも少なくすることができるはずだ。
あらかた食べ終え、テーブルでチャージして席を後にする。
