--- title: "生産性をコードの行数で測らない" url: https://www.thinnd.site/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "プロダクト思考" tags: ["生産性", "指標", "DORA", "SPACE", "AI", "エンジニアリングマネジメント"] summary: "コードの行数は書かれた文字の量を測るもので、届けた価値を測りません。目標になった途端にゆがみます（グッドハートの法則）。AIが数秒で数千行を書く今は、さらに意味が薄れます。チームと成果で測りましょう：アイデアから利用者に届くまでの時間、変更の失敗率、レビュー待ち、手戻り、チームの満足度。個人の順位づけではなく、傾向として使います。" license: "Cite with the author name and the canonical URL above." --- # 生産性をコードの行数で測らない > プログラマー、チームリーダー、プロダクトマネージャーのための記事です。技術用語には短い説明を付けます。 > > 数字は末尾の公開情報によるもので、多くはテクノロジー企業の発表です。慎重に読んでください。登場する「フン」と「プラムチーム」は、イメージしやすいように作った例で、実在の人物ではありません。 --- ## 先に要点 - **コードの行数は、書いた量を測るもので、届けたものを測りません。** 良い解決は短いことが多く、余分なコードを消すのも貢献です。 - 数字が**目標になるとゆがみます**（グッドハートの法則）。人は数字をよく見せようとし、製品を悪くしてまでそうします。 - AI時代には**さらに意味が薄れます**：AIは数秒で数千行を書くので、行数は増えても価値は増えないかもしれません。 - **チームと成果**で測ります：リードタイム、変更失敗率、レビュー待ち、手戻り、満足度。 - 指標は**傾向**として使い、**速度と品質を組み合わせ**、**個人の順位づけには使わない**。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **LOC（コードの行数）** | コードの行の数。 | | **グッドハートの法則** | 指標が目標になると、良い指標ではなくなる。人が数字をよく見せようとするから。 | | **DORA** | 長く続く研究プログラムによる、ソフトウェアの提供についての4つの指標。 | | **SPACE** | MicrosoftとGitHubの研究者が提案した、生産性の5つの側面の枠組み（2021年）。 | | **リードタイム** | コミットから、実際の利用者に動くまで。 | | **変更失敗率** | リリースのうち、緊急の修正や取り消しが必要になった割合。 | | **手戻り** | 書いたばかりなのに、すぐ変更や破棄が必要になったコード。 | --- ## 1. マイナス2000行の話 1982年の初め、AppleのLisaチームで、ある管理者が、エンジニアの生産性を毎週書いたコードの行数で測ろうとし、全員が用紙に記入することになりました。アンディ・ハーツフェルドがfolklore.orgで語るところでは、ビル・アトキンソンはそのとき、グラフィックスライブラリQuickDrawの領域を扱う部分を最適化していました。より単純なアルゴリズムに置き換えて、領域の操作を約6倍速くし、その副産物として約2000行のコードが減りました。 用紙の欄に、彼は**-2000**と書きました。話によると、数週間後には、彼に記入を求めなくなったそうです。 これは逸話で、いくつもの情報源を通して語り継がれているので、細部を正確と思わないでください。それでも要点は成り立ちます：**その週の最良の仕事が、行数を減らした**のです。 --- ## 2. なぜ行数は誤解を招くのか 単純な理由が3つあります。 1. **文字を測るもので、結果を測らない。** 利用者はコードの行にお金を払いません。自分の問題が解決されることに払います。 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. 害のない使い方 1. **チームを測り、人の順位づけはしない。** 「誰が最も劣るか」ではなく、「私たちのシステムはどこで詰まるか」を問うために使う。 2. **傾向を見て、硬い目標は置かない。** 硬い目標はゲームを生みます。 3. **測り方と理由を公開する。** チームは、数字が何のためか知る必要があります。 4. **数字を信じる前に人に聞く。** 15分の会話のほうが、ダッシュボードより明確なことが多い。 5. **四半期ごとに指標を見直す。** 指標もコードのように保守が要ります。 --- ## 8. 上司との話し方 上司が行数を使いたがるなら、反論からではなく、その人の**必要**から始めます： - 「チームが着実に安全に届けているかを知りたいのですよね？」 - 「2つの指標を提案します：リードタイムと、リリース後の不具合率です。3か月、傾向を追いましょう。」 - 「マイナス2000行を書いたエンジニアの短い話があります。これは何を語っていると思いますか？」 目標は、人ではなく**問い**を変えることです。 --- ## 9. バランスの取れた見方 - **行数が完全に無用なわけではありません。** 変更の大きさを示し、レビューの仕方を決める助けになります（3000行の変更は分割が要る）。**警告**として使い、**採点**には使いません。 - **他の指標もゲームにされます。** コミット数、ストーリーポイント、リードタイムでさえゆがみえます。グッドハートの法則から逃れる指標はなく、ましなものがあるだけです。 - **測ること自体は必要です。** 何も測らないのも悪い選択です。**正しいもの**を**正しい使い方**で選ぶのが課題です。 - **データは限られます。** 生産性の測定についての文章の多くは、ツール会社かブログのものです。単一の指標が生産性をよく予測すると示す独立したデータは、見つけられていません。 --- ## 10. 結論 コードの行数は数えやすいので、よく使われます。しかし重要でないものを測り、AI時代にはほとんど無料のものを測ります。**チームの成果**を測りましょう：速く届け、安全に届け、手戻りが少なく、チームが今も一緒に働きたいと思えること。 今日の小さな一歩：6章の表から成果指標を2つ選び、この4週間を記録し、次の会議で傾向を示してください。 --- ## 参考資料 - [Negative 2000 Lines Of Code、folklore.org（アンディ・ハーツフェルド）](https://www.folklore.org/Negative_2000_Lines_Of_Code.html) - [The SPACE of Developer Productivity、ACM Queue（2021年）](https://queue.acm.org/detail.cfm?id=3454124) - [DORA 2025: State of AI-assisted Software Development](https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/) - [Faros AI：AIの生産性、実験室と現実](https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings) - [METRの生産性研究についてのSimon Willisonの解説](https://simonwillison.net/2025/Jul/12/ai-open-source-productivity/) - ブログ内の関連記事：[AI時代のITチームの働き方](https://www.thinnd.site/ja/keiken/ai-jidai-no-chimu-no-hataraki-kata/)、[AIが書いたコードのレビュー](https://www.thinnd.site/ja/gijutsu/ai-ga-kaita-code-no-review/)、[実際のプロジェクトでAIエージェントと働いた3時間](https://www.thinnd.site/ja/genba-noto/ai-agent-jissai-no-purojekuto-nikki/)