飛行機の
重さを量る人
「今月はこれだけの行数（Step数）を書きました！」。
飛行機を作るプロジェクトの進捗を、飛行機の重さで量りますか？
重い飛行機は、飛べない飛行機です。
コードの行数も同じ。多いことは、誇るべきことではなく、恥じるべきことです。
- エンジニアの評価シートに「生産性（Step/月）」という項目がある
- 不要なコードを削除（リファクタリング）したら、「生産性がマイナス」だと怒られた
- コメントや空白行を大量に入れて、行数を稼ぐエンジニアがいる
- 「100行のコードを書きました」と報告する若手に対し、「20行に減らしてこい」と言えない
プログラミングの目的は「問題を解決すること」であり、コードはその手段（しかも負債）に過ぎません。
01. ビル・ゲイツの言葉
(Bad Code)
(Good Code)
「プログラミングの進捗を行数で測るのは、飛行機製造の進捗を重量で測るようなものだ」。
これはビル・ゲイツの言葉です。
優れたプログラマーは、複雑な問題をシンプルに解決します。
未熟なプログラマーは、簡単な問題を複雑にしてしまいます。
行数が多いコードは、バグの温床であり、読むのが大変なゴミです。
書かれなかったコードだ。
02. マイナスの生産性
本当に評価されるべきは、「1000行のコードを削除して、機能を変えずにシステムを高速化した」エンジニアです。
GitHubの `Additions`（追加行数）よりも `Deletions`（削除行数）が多いプルリクエスト。
これこそが「美徳」として称賛される文化を作りましょう。
コードは資産ではありません。負債です。少ないに越したことはありません。
03. 正しい指標（Four Keys）
では何を測ればいいのか？
GoogleのDevOps研究チームが提唱する「Four Keys」を使いましょう。
1. デプロイ頻度
2. 変更のリードタイム（着手からリリースまでの時間）
3. 変更障害率（バグ発生率）
4. 平均修復時間（バグからの復旧時間）
これらは「速さ」と「安定性」を測る、真に価値のある指標です。