超先進企業にお勤めされているスーパープログラマは例外として、それ以外の職業開発者にとって、コード行数という指標は開発業務において大きな位置を占めていると思う。コード行数予測をもとに工期や人員算出をしたり、コード行数をもとにテスト件数や欠陥密度などを測ったり、etcetc。。。
だが、これがどうもよろしくない。コード行数は大まかには見積もり（つまり予測）に使われることと、結果指標に使われることがあるが、どちらにもよろしくない。端的に言えば、予測の段階では「そんな細かいことまでわからない」し、結果の段階では「そんな曖昧なもので正確な評価が行えない」からだ。
見積もりコード行数
そもそも、見積もりを行う時点では仕様と概要アーキテクチャくらいしか決まってないことが多く、この時点で「コードが何行になるか」なんて誰にもわかるわけがない。にも関わらず、（そして必要工数を別に出しているにも関わらず）コード行数を絶対の根拠としていろんなことを決めようとする人間の多いこと多いこと、、、。
実際はかなり適当な根拠に基づいて算出しているというのに。
コーディング方面に知見がないと自覚しているPMなどは、機能ごとにコーダーを割り当てて行数見積もりを出させたりする例もあるが、これもあまり意味がない。コーダーはコードが何行になるかを気にしないからだ。物書きであれば、「紙面の都合上原稿用紙n枚に収める技術」的なものを持っているかもしれないし、それを持つメリットもあるのだが、コーダーにはそのような技術を持つ意味がないからだ。つまり、コーダーに任せても「適当な数字」しか出てこない。
そのような適当な数字を元に何かを決めるというのは危険なことであるし、ここで「見誤まった」結果後で苦労することもよくある。
結果指標としてのコード行数
一度でもまともにコーディングをしたことがあるのならわかるはずだが、コード行数という単位はひどく曖昧だ。単純に書き方によって何行になるかが変わるし、行が多いから複雑というわけでもない。言語（特に{ }などのスタイル）によってかなり左右されるし、皆が思うほど汎用な指標ではないのだ。
にもかかわらず、1000行あたり何個テストしていなかったらテスト不足だとか、かけた時間とコード行数の比がm:n以下だったら生産性未達だとか、そのような観念の根深いこと根深いこと。
最近では単体テスト時のc0カバレッジなど、非常に理にかなった指標を採用する例も多いが、そういうよい指標を「発見」できた分野以外では、コード行数をもとにした“雑な”統計理論で基準点が設けられることが多い。
そのような雑な指標を元になにかを判断するというのは危険なことだし、往々にして不毛な作業が増えることになる。
じゃあどうすればいいか
とはいえ、じゃあどうすればいいかと言われると困ってしまう。
結果指標であればまだその「測りたい対象」に応じて適切な指標を取捨選択するということができそうだが、予測に使う指標はどうすればよいのだろうか。ソフトウェア開発の予測なんて本質的には不可能だってのが広く知れ渡るとよいのですが。
まあ一つあるとすれば、指標云々より、開発がどう行われるかなんて1ミリも考慮できずに、指標と実測値を見比べてあれが悪いだのこれが悪いだの言っている人間を排除できれば一定の効果はあるんでしょうけど。
余談
ちなみに、コード行数以外に開発規模を定量的に表す指標として、FP（ファンクションポイント）があるが、わたしは嫌いである。
予測という観点でみると、FPの算出には「テーブル・画面・画面とテーブル入出力の関係*1」がそろっている必要がある。いやいやいやそこまでそろってりゃだいたいどんな方式とってもだいぶ精度が良い見積もりできるだろと。
結果という観点でみると、正確なFPは「テーブル・画面・画面とテーブル入出力の関係」に様々な係数をかけて算出する。が、これだと昨今の主流であるUI部分がリッチなアプリケーションとか、ビジネスロジックが複雑なアプリケーションに対応できない。
UIとはDBのデータをちょこっと加工するくらいの想定しかなされてないのだ。静的なデータ構造とそこにアクセスするSQLがフォームにべたべた書きされたVB6アプリの時代から全く進化していないし、基本概念がそこにあるので、変化する現実に適用できないのである。
要するに、「使えない」から嫌いなのだ*2。
