こんにちは。Findy Tech Blog編集長の高橋（@Taka-bow ）です。
前回の記事 では、全体の44.3%が開発生産性に前向きという結果をご紹介しました。今回は開発手法別に深掘りすると、予想外の事実が浮かび上がってきました。
【調査概要】
調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など調査方法： インターネット調査調査期間： 2025年4月2日(水)～2025年5月21日(水)調査主体： ファインディ株式会社実査委託先： GMOリサーチ&AI株式会社有効回答数： 798名（95%信頼区間±3.5%）統計的検定力： 80%以上（中程度の効果量d=0.5を検出）調査内容：
開発生産性に対する認識
開発生産性に関する指標の活用状況
開発生産性に関する取り組み
開発環境・プロセス評価
組織文化と生産性
開発生産性への印象は多様 ── 約半数が中立的立場も抵抗感は少数派
あらためて、「開発生産性」という言葉に対する印象を見てみましょう。
開発生産性への印象に関する回答分布
選択肢
回答者数
割合
詳細内訳
どちらでもない
384人
48.1%
–
ポジティブ
354人
44.3%
とてもポジティブ + どちらかというとポジティブ
ネガティブ
61人
7.6%
とてもネガティブ + どちらかというとネガティブ
合計
798人
100.0%
–
「開発生産性」という言葉に対してネガティブな印象を持つ人はわずか7.6% （61人）。一方で、44.3%がポジティブ （354人）な印象を持っており、約半数（48.1%）が中立的 （384人）な立場を取っています。
この結果から、多くのエンジニアが生産性向上に対して前向き、あるいは少なくとも抵抗感を持っていないことが分かります。これは、日本の開発現場が変化を受け入れる準備ができていることを示唆しています。
意外な結果 ── アジャイル実践者の59.6%が開発生産性に前向き
私がこれまで出会ったアジャイルコーチの多くは、口を揃えて「生産性は測れない」「生産性に意味はない」と言っていました。そのため、アジャイル実践者ほど開発生産性という概念に抵抗を示すのではないかと予想していました。
しかし、調査結果は意外でした。
開発手法別の開発生産性に対するポジティブ印象の比較
フレームワーク
対象者数
ポジティブ印象者数
ポジティブ率
アジャイル系
245名
146名
59.6%
ウォーターフォール
294名
116名
39.5%
差
–
–
20.1ポイント
アジャイル実践者の約6割（59.6%）が開発生産性に前向きという結果は、ウォーターフォール開発者（39.5%）と比べて20.1ポイントも高い数値でした。
さらに、実際の取り組み状況を見てみましょう。
開発手法別の開発生産性向上への取り組み状況の比較
フレームワーク
対象者数
取り組み実施者数
取り組み率
アジャイル系
245名
117名
47.8%
ウォーターフォール
294名
105名
35.7%
差
–
–
12.1ポイント
アジャイル系では47.8%が実際に取り組みを実施しているのに対し、ウォーターフォールでは35.7%にとどまっています。しかし、ポジティブ印象の差（20.1ポイント）に比べて、実際の取り組み率の差（12.1ポイント）は小さいことが分かります。
つまり、アジャイル実践者は「開発生産性」に対して前向きな印象を持っているものの、実際の取り組みに落とし込めていない人が多いということです。ポジティブな印象を持つ59.6%のうち、実際に取り組んでいるのは47.8%。この差は何を意味するのでしょうか？
前回の記事で指摘した「測定指標の混乱」を考慮すると、このギャップの原因が見えてきます。実際、組織が重視する指標は千差万別です。
コード行数、バグ数、残業時間、機能数、ストーリーポイント──組織によって測定する指標はバラバラで、業界全体で「何を測るべきか」の共通認識が欠けています。DORA指標（デプロイ頻度、リードタイム、MTTR、変更失敗率）の認知度がわずか4.3%という事実も、この混乱を裏付けています。
アジャイル実践者の多くは開発生産性の重要性は理解しているものの、「何を測るべきか」「どう測るべきか」が分からず、結果として行動に移せていない可能性があるのです。
なぜアジャイル実践者は開発生産性に前向きなのか
アジャイルの価値観と生産性改善の親和性
なぜアジャイル実践者の方が前向きなのでしょうか。私の経験から考えると、アジャイルの実践と生産性改善の考え方には、次のような共通点があるのかもしれません。
1. 継続的な改善が文化として根付いている
スプリントやイテレーション（短期間の開発サイクル）ごとにレトロスペクティブで定期的に振り返り、改善を繰り返す。この習慣により、「生産性を向上させる」という考え方が自然に受け入れられています。
2. 測定と可視化が日常的な実践
ベロシティ、バーンダウンチャート、イテレーション完了率など、アジャイルチームは様々な指標を日常的に活用しています。そのため、「測定する」ことへの心理的抵抗が少ない。
3. 変化への適応力
「変化を歓迎する」というアジャイルの原則により、開発生産性という概念も「改善の機会」として前向きに捉えられます。
4. チームの自律性と当事者意識
アジャイルでは、チームが自ら課題を発見し解決策を考えます。開発生産性も「上から押し付けられる」ものではなく、「自分たちが主体的に改善する」ものとして受け止められています。
Kent Beck氏が語る測定の本質 ── 「測定が目標になると、システムは歪む」
しかし、アジャイル実践者の59.6%が前向きだという事実は、彼らが「正しく」生産性を理解していることを意味するのでしょうか？
実は、この問題について、アジャイル界のレジェンドであるKent Beck氏が重要な示唆を与えています。19年ぶりに来日し、開発生産性Conference 2025で登壇した彼は、測定と生産性の本質的な問題について警鐘を鳴らしました。
Kent Beck 氏（開発生産性Conference 2025にて）
Kent Beck氏は「グッドハートの法則」を引用しながら、こう語りました。
"When a measure becomes a target, it ceases to be a good measure. If we exert pressure on that system, the regularity will disappear. It's worse than that. If we exert pressure on that regularity to make things better, we will destroy the system that created that regularity in the first place."
「測定が目標になると、それは良い測定ではなくなります。システムにプレッシャーをかけると、規則性は消えます。それよりも悪いことに、物事を良くするためにその規則性にプレッシャーをかけると、最初にその規則性を作り出したシステムを破壊してしまうのです」
プルリクエストの例を挙げて、具体的に説明しています。
"I'm going to take my pull request that made some sense and I'm just going to slice it up. Their less readable leads to less cooperation leads to more waste leads to fewer pull requests. So by applying pressure to the software development process to make it better, we have made it worse."
「理にかなった1つのプルリクエストを細かく分割します。読みにくくなり、協力が減り、無駄が増え、プルリクエストが減ります。ソフトウェア開発プロセスにプレッシャーをかけて改善しようとすることで、悪化させてしまったのです」
このような単一メトリクスの問題に対して、「では複数のメトリクスでバランスを取ればよいのでは？」という反論が予想されます。Kent Beck氏は、この点についても次のように警告しています。
"People say well you need a balanced set of metrics. That doesn't solve the problem. Every metric that you introduce is going to distort the system that you're working in in ways that aren't what you want it to be."
「『バランスの取れたメトリクスのセットが必要だ』と言う人もいます。しかし、それでは問題は解決しません。導入するすべてのメトリクスは、望ましくない方法で作業しているシステムを歪めます」
つまり、メトリクスを増やしても、歪みが複雑化するだけで根本的な解決にはならないということです。これは、日本の組織でよく見られる「各チームが異なるKPIを追求する」状況と重なります。
ただし、Kent Beck氏自身も「測定自体は極めて価値がある」 と強調しています。
"I've been measuring my own software development process as long as I've been developing and I find it extremely valuable to turn what I'm doing into numbers that I can analyze and interpret."
「私は開発している限り、自分のソフトウェア開発プロセスを測定してきました。私がしていることを分析し解釈できる数字に変えることは非常に価値があると思います」
つまり、問題は測定そのものではなく、何を測るか とどう使うか なのです。
アジャイル実践者の「前向きさ」に潜む3つの勘違い
Kent Beck氏の警告を踏まえると、アジャイル実践者の「前向きさ」には次のような勘違いが潜んでいる可能性があります。
1. ベロシティ＝生産性という誤解
ベロシティが上がると「生産性が向上した」と感じてしまいがちです。しかし、ベロシティはあくまでもチーム内での前イテレーションとの相対比較でしかなく、チーム間の比較や組織全体の生産性を示す指標ではありません。さらに、ストーリーポイントのインフレーション（見積もりの甘さ）や、価値の低いタスクの量産でも数字は上がります。Kent Beck氏が指摘するように、これはまさに「測定が目標になった」状態です。
2. プロセスの遵守をアウトカムと混同
アジャイルの「儀式」を正しく実行していることと、実際に価値を生み出していることは別物です。毎日スタンドアップをやり、レトロスペクティブを欠かさず、バーンダウンチャートが美しい右肩下がりを描いていても、それは「プロセスを守っている」だけかもしれません。顧客が本当に必要としている機能を届けているか、ビジネスアウトカムにつながっているか、技術的負債を積み上げていないか──これらの本質的な問いを忘れ、「アジャイルをちゃんとやっている」ことに満足してしまうリスクがあります。
3. 複数メトリクスの罠 ── なぜ全体最適が失われるのか
日本の組織では、各チームが自分たちの領域で完璧を追求する傾向があります。開発チームはベロシティを上げ、QAチームはバグ検出率を誇り、運用チームは安定性を守る。それぞれが「うちのチームは生産性が高い」と思っています。しかし、これはまさにKent Beck氏が警告する「バランスの取れたメトリクス」の問題です。各チームが異なるメトリクスを最適化することで、システム全体に複雑な歪みが生じます。開発が早くても、QAで長時間滞留し、運用への引き渡しで調整に時間がかかり、結局顧客に価値が届くまでのリードタイムは改善されない。
Kent Beck氏が指摘するように、「システムを歪めるメトリクスが多いほど、理解しにくく影響を与えにくくなる」のです。各チームの「優秀さ」が、かえって全体のボトルネックを見えなくし、誰も全体像を把握できない状況を生み出しています。
つまり、アジャイル実践者が「前向き」なのは、自分たちの測定方法や改善活動が正しいと信じているから かもしれないのです。
何を測るべきか ── Kent Beck氏が示す価値創造の道筋
本調査から明らかになったのは、どの開発手法でも「何を測るべきか」の共通認識が欠けていることです。この根本的な問題について、Kent Beck氏は価値創造の道筋を次のように説明しています。
Kent Beck 氏（開発生産性Conference 2025にて）
"We start out with effort... That's effort. We can measure it in time... Now we have some output... But we still haven't created value until the customer does something, behaves in some new kind of way... And finally the value that we created... comes back to the company in terms of increase in revenue, increase in customer satisfaction."
(*下図を示しながら)「まず努力（Effort）から始まります。これを時間で測定できます。次に何らかの成果物（Output）が生まれます。しかし、顧客が新しい行動を取るアウトカム（Outcome）が生まれるまでは、まだ価値は生まれていません。そして最終的に、創出された価値が収益増加や顧客満足度向上という影響（Impact）として会社に還元されます。」
Kent Beck 氏のプレゼン資料から引用 (p.8)
そして、この価値の道筋における測定の難しさと歪みの関係について、次のように述べています。
"The further over here we are towards effort the easier things are to measure. But also the more likely that measurement is to distort the system... The further over here you are... the harder it is to attribute value to any one person or one team but the less prone that measurement is to distorting the system."
「投入した努力（作業時間など）に近い指標ほど測定は容易ですが、同時にその測定がシステムを歪めるリスクも高まります。一方、創出された価値（ビジネスアウトカム）に近い指標ほど、そのアウトカムを特定の個人やチームに帰属させることは困難になりますが、測定によるシステムの歪みは生じにくくなります」
測定を「コントロール」ではなく「認識」のツールとして ── Kent Beck氏の4つの提言
では、どうすればこの問題から抜け出せるのでしょうか。Kent Beck氏は講演の結論で、4つのアプローチを提示しています。
Kent Beck 氏のプレゼン資料から引用 (p.11)
1. Observe later（後で観察する）
価値連鎖の早い段階（努力やコード量）ではなく、後の段階（アウトカムや影響）を観察することを推奨しています。「開発者1人あたりの利益を見てください」と彼は例を挙げています。
2. Encourage awareness（認識を促す）
「システムを高速化する最良のテクニックの1つは、システムがどれだけ速いかをグラフ化することです」と述べ、可視化によって自然な改善を促すことを提案しています。
3. Avoid pressure（プレッシャーを避ける）
「リーダーとしてプレッシャーをかけないことは最も難しいことです。しかし、プレッシャーをかけると、システムの歪みが生じます」と警告しています。
4. Instill purpose（目的を植え付ける）
「今のような頻度で本番環境のインシデントが発生しない世界は素晴らしいと思いませんか？」という形で、プレッシャーではなく共通の目標として提示することの重要性を語っています。
この観点から見ると、DORA指標 （デプロイ頻度、リードタイム、MTTR、変更失敗率）も実は「Output」レベルの測定です。これらは「コード行数」のような純粋な努力（Effort）レベルよりは価値に近いものの、依然として「どれだけ速く・頻繁にリリースしたか」を測っているに過ぎません。顧客の行動変化（Outcome）やビジネスへの影響（Impact）を直接測定しているわけではないのです。
それでも、DORA指標には意味があります。なぜなら、これらの指標をプレッシャーツールとしてではなく、チームの健全性を把握し、改善の機会を見つけるための認識ツール として使うことができるからです。
重要なのは、どんな指標であっても、それを目標化してプレッシャーをかけるのではなく、現状を理解し、チーム自身が改善方法を考えるためのツールとして活用すること です。
アジャイル実践者への提案
ベロシティだけでなく、顧客価値の提供速度を測る
チームの指標とビジネス指標を接続する
DORA指標やDevExの考え方を取り入れる
ウォーターフォール開発者への提案
現在の指標（バグ数、納期）を維持しつつ、先行指標を追加
小さな改善サイクルを導入して効果を検証
リスクを最小化しながら段階的に変化を進める
次回予告
第3回は「開発生産性を阻む『日本の3大悪習』── 要件定義、会議、コミュニケーションの罠 」をお届けします。
日本の開発現場が抱える構造的な課題と、その改善への道筋を探ります。
また、ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。
興味を持っていただいた方はこちらのページからご応募お願いします。
herp.careers
