生産性をコードの行数で測らない
コードの行数は、最も数えやすく、最も誤読しやすい数字です。AIが数秒で千行を書く今は特にそうです。この記事は理由を説明し、マイナス2000行の話を紹介し、チーム単位の代わりの指標と害のない使い方を示します。
プログラマー、チームリーダー、プロダクトマネージャーのための記事です。技術用語には短い説明を付けます。
数字は末尾の公開情報によるもので、多くはテクノロジー企業の発表です。慎重に読んでください。登場する「フン」と「プラムチーム」は、イメージしやすいように作った例で、実在の人物ではありません。
先に要点#
- コードの行数は、書いた量を測るもので、届けたものを測りません。 良い解決は短いことが多く、余分なコードを消すのも貢献です。
- 数字が目標になるとゆがみます（グッドハートの法則）。人は数字をよく見せようとし、製品を悪くしてまでそうします。
- AI時代にはさらに意味が薄れます：AIは数秒で数千行を書くので、行数は増えても価値は増えないかもしれません。
- チームと成果で測ります：リードタイム、変更失敗率、レビュー待ち、手戻り、満足度。
- 指標は傾向として使い、速度と品質を組み合わせ、個人の順位づけには使わない。
むずかしい言葉をやさしく#
| 用語 | やさしい意味 |
|---|---|
| LOC（コードの行数） | コードの行の数。 |
| グッドハートの法則 | 指標が目標になると、良い指標ではなくなる。人が数字をよく見せようとするから。 |
| DORA | 長く続く研究プログラムによる、ソフトウェアの提供についての4つの指標。 |
| SPACE | MicrosoftとGitHubの研究者が提案した、生産性の5つの側面の枠組み（2021年）。 |
| リードタイム | コミットから、実際の利用者に動くまで。 |
| 変更失敗率 | リリースのうち、緊急の修正や取り消しが必要になった割合。 |
| 手戻り | 書いたばかりなのに、すぐ変更や破棄が必要になったコード。 |
1. マイナス2000行の話#
1982年の初め、AppleのLisaチームで、ある管理者が、エンジニアの生産性を毎週書いたコードの行数で測ろうとし、全員が用紙に記入することになりました。アンディ・ハーツフェルドがfolklore.orgで語るところでは、ビル・アトキンソンはそのとき、グラフィックスライブラリQuickDrawの領域を扱う部分を最適化していました。より単純なアルゴリズムに置き換えて、領域の操作を約6倍速くし、その副産物として約2000行のコードが減りました。
用紙の欄に、彼は**-2000**と書きました。話によると、数週間後には、彼に記入を求めなくなったそうです。
これは逸話で、いくつもの情報源を通して語り継がれているので、細部を正確と思わないでください。それでも要点は成り立ちます：その週の最良の仕事が、行数を減らしたのです。
2. なぜ行数は誤解を招くのか#
単純な理由が3つあります。
- 文字を測るもので、結果を測らない。 利用者はコードの行にお金を払いません。自分の問題が解決されることに払います。
- 少ないほうが良いことが多い。 コードが少なければ、不具合の場所も、読むものも、保守するものも少なくなります。
- ゲームにされやすい。 行数が目標だと、増やす最も安い方法は、長く書く、意味なく分ける、コピペすることです。
最後がグッドハートの法則です：指標が目標になると、良い指標ではなくなります。コードの行数、コミット数、ストーリーポイントは典型的な例です。
3. 例：プラムチームとランキング#
作った人物による例です。
プラムチームは4人です。管理者は、やる気を引き出すという善意から、「週ごとのコード行数」の表を共有チャンネルに貼り始めます。
- 1週目。 フンは900行を書く。ランは120行だけ。顧客が不満を言っていた難しい不具合を追って、1週間を使ったから。
- 3週目。 ランは自分の名前が表の下にあるのを見る。古いコードの整理をやめ、小さな機能を足す方に回る。
- 6週目。 フンはAIで3000行を生成し、その多くは互いのコピー。表は良く見えるが、レビュー時間は倍になり、2つの不具合がリリースに紛れ込む。
- 8週目。 チームは、表が管理者の知りたいことを示していないと分かるが、全員もう行動を変えてしまっている。
要点は、行動は、物差しの欠陥に気づくより速く変わることです。
4. AI時代には問題が重くなる#
AIはコードを作るのを安くするので、コードの量に基づく物差しはどれも膨らみます。
- Faros AIのデータ（2025年7月、1,255チームの1万人超の開発者）では、AIをよく使うチームは変更の統合が約98%多く、1件が約154%大きく、1件あたりのレビュー時間が約91%増えていました。測定ツールの会社のデータで、相関であり、私は要旨を読んだだけです。
- METRの研究（2025年7月）では、経験豊富な16人の開発者が、2025年初めのAIツールで約19%遅くなったのに、本人たちは約20%速くなったと信じていました。標本は小さくツールも変わっていますが、速いという感覚と本当の速さがずれうることを示します。
合わせると、活動の数字（行、コミット、PR）と成果の数字は離れうることが示唆されます。AI時代に活動を測るのは、車が滑っているのに、車輪の回転数で速度を測るようなものです。
5. 代わりに何を測るか#
広く使われる枠組みが2つあり、どちらもチームと多くの側面を重んじます。
DORA、提供についての4つの指標
| 指標 | 答える問い |
|---|---|
| デプロイ頻度 | チームはどのくらいの頻度でリリースするか？ |
| リードタイム | コミットから利用者に届くまでどのくらいか？ |
| 変更失敗率 | リリースの何割が障害を起こすか？ |
| 復旧時間 | 壊れたとき、直すまでどのくらいか？ |
**SPACE（2021年）**は、生産性を5つの側面で捉えます：満足度と健康、成果、活動、コミュニケーションと協働、効率とフロー。核心の主張は、単一の指標では足りないことと、1つの側面の最適化は他の側面を下げがちなことです。
どちらもチームとシステムを見るためのものです。個人の採点に使うのは目的を取り違えています。ばらつきの大半は、個人ではなくプロセスとツールから来るからです。
6. 小さなチームのための出発点の指標表#
5つの指標から始め、毎週か毎月記録し、傾向を見ます。
| 指標 | 測り方 | 注意すべきとき |
|---|---|---|
| リードタイム | 作業を開いてから実際に動くまでの日数 | 着実に長くなる |
| 変更失敗率 | 緊急修正の数をリリース数で割る | 速度が上がると増える |
| レビュー待ち | PRを開いてからレビューされるまでの時間 | AIを多く使うと増える |
| 手戻り | 2週間以内に再び変更されたコードの割合 | 行数と一緒に増える |
| チームの満足度 | 毎月の3問のアンケート | 少しずつ下がる |
組み合わせます。 速度の指標には必ず品質の指標を添えます。リードタイムが短くなり失敗率が上がるのは、進歩ではありません。
7. 害のない使い方#
- チームを測り、人の順位づけはしない。 「誰が最も劣るか」ではなく、「私たちのシステムはどこで詰まるか」を問うために使う。
- 傾向を見て、硬い目標は置かない。 硬い目標はゲームを生みます。
- 測り方と理由を公開する。 チームは、数字が何のためか知る必要があります。
- 数字を信じる前に人に聞く。 15分の会話のほうが、ダッシュボードより明確なことが多い。
- 四半期ごとに指標を見直す。 指標もコードのように保守が要ります。
8. 上司との話し方#
上司が行数を使いたがるなら、反論からではなく、その人の必要から始めます：
- 「チームが着実に安全に届けているかを知りたいのですよね？」
- 「2つの指標を提案します：リードタイムと、リリース後の不具合率です。3か月、傾向を追いましょう。」
- 「マイナス2000行を書いたエンジニアの短い話があります。これは何を語っていると思いますか？」
目標は、人ではなく問いを変えることです。
9. バランスの取れた見方#
- 行数が完全に無用なわけではありません。 変更の大きさを示し、レビューの仕方を決める助けになります（3000行の変更は分割が要る）。警告として使い、採点には使いません。
- 他の指標もゲームにされます。 コミット数、ストーリーポイント、リードタイムでさえゆがみえます。グッドハートの法則から逃れる指標はなく、ましなものがあるだけです。
- 測ること自体は必要です。 何も測らないのも悪い選択です。正しいものを正しい使い方で選ぶのが課題です。
- データは限られます。 生産性の測定についての文章の多くは、ツール会社かブログのものです。単一の指標が生産性をよく予測すると示す独立したデータは、見つけられていません。
10. 結論#
コードの行数は数えやすいので、よく使われます。しかし重要でないものを測り、AI時代にはほとんど無料のものを測ります。チームの成果を測りましょう：速く届け、安全に届け、手戻りが少なく、チームが今も一緒に働きたいと思えること。
今日の小さな一歩：6章の表から成果指標を2つ選び、この4週間を記録し、次の会議で傾向を示してください。
参考資料#
よくある質問
- なぜコードの行数は生産性の悪い物差しなのですか
- 量を測るもので、価値を測らないからです。良い解決は短いことが多く、余分なコードを消すことも貢献です。数字が目標になると、人はそれを増やします。肥大したコードでも。グッドハートの法則の言うとおりです。AIを使うと価値の増加を伴わずに急増もします。
- エンジニアの生産性は何で測ればよいですか
- 個人ではなくチーム単位の指標を使います。DORAには4つあります：デプロイ頻度、コミットから本番までのリードタイム、変更失敗率、復旧時間。MicrosoftとGitHubの研究者によるSPACE（2021年）は、満足度、コミュニケーション、フローを加え、単一の指標では足りないという原則を持ちます。速度の指標には品質の指標を組み合わせます。
- AIは生産性の測定をどう変えますか
- AIは活動の指標を、価値が増えるとは限らないまま急速に上げます。Faros AIのデータ（2025年）では、AIをよく使うチームは変更の統合が約98%多く、1件あたり約154%大きく、レビュー時間が約91%増えていました。測定ツールの会社のデータなので慎重に読む必要がありますが、活動と成果が離れうることを示しています。
- 行数で測りたい上司とどう話しますか
- 上司が必要としていること、つまりチームが着実に安全に届けているかを知りたい、という所から始めます。リードタイムとリリース後の不具合率のような成果指標を2、3個、チームの傾向として追うことを提案します。マイナス2000行の話や、自分のプロジェクトの例で示します。