プログラムには、ステップ数と呼ばれる数値があります。これは、コードの行数（コメントや空白行は除く）をステップ数として、プログラムの規模を見積もること等に使われる数値です。
しかし、ステップ数による評価は既に時代遅れとなっています。今回は、そんなステップ数について過激にまとめてみたいと思います。
ステップ数を評価基準にするべきではない
面談などで「過去に携わったプロジェクトのステップ数を教えてください」などと聞かれると、現代のプログラマは「このプロジェクトはヤバイ！」と直感的に感じるはずです。
そもそも、プログラムの規模というものは、ステップ数では測れません。フレームワークを上手く活用していれば、実装コードは劇的に少なくなりますし、そうでなくても、ステップ数が増減する要因は山のようにあります。
例えば、以下の２つのコードは同じ結果を返しますが、コード行数には大きな差があります。
public String hello(String name) {
String message = "Hello ";
message += name;
message += " !";
return message;
}
public String hello(String name) {
return "Hello " + name + " !";
}
ステップ数を基準にすれば、より多くの行数である上のコードが、より優れていると判断されかねません。それが正しいかどうかは別として。
ステップ数は見積もれない
上述したような理由で、ステップ数を正確に見積もるようなことはできません。
実績やメソッド数などからステップ数を大まかに見積もることはできるかもしれませんが、フレームワークや開発手法の多様化が進んできた現代では、誤差の範囲がとんでもなく、±50%などザラにあります。
また、面談で「月10万ステップ書きました！」とアピールした応募者を、「おおー、すごい」と採用してみたら、for文すら知らないコピペマンだったというような笑い話にもならない悲劇が起こりうるわけです。
ステップ数を工数見積もりに使うべきではない
大抵の場合、コーディングよりも設計やテストのほうに数倍の時間が掛かるわけですから、ステップ数は有力な基準とはなり得ません。それが説得力を持っていたのは既に何十年も前の話です。
とはいえ、工数見積もり手法などというものは、感覚的に（都合の良いように）見積もった工数に論理的な説得力を与えるだけの道具にすぎませんから、ステップ数が通じる相手であればステップ数で話を付けたほうが早いケースもあります。
テスト密度の指標にステップ数を使うべきではない
ブラックボックステストやホワイトボックステストなどのテスト手法を使って適切なテストケースを導き出すべきです。
そして、それらは適切にレビューされるべきです。たとえば100件/KLOCの密度基準を満たしたとして、それがあらゆるテストを網羅しているとどうして保障できるのでしょうか。
テスト密度を絶対的なノルマとして設定しているの場合、足りなければ無意味なテストケースを増やすことになりますし、多ければ本当に必要なテストケースを見逃す可能性があります。余計な基準を設定すべきではありません。
まとめ
かつてのハンガリアン記法のように、技術や文化の盛衰は非常に激しいものです。常に流行を捉えながら、より良い技術を使って、より素晴らしい仕事を行いたいものです。