1 Masato Ishigaki July. 16, 2026 誤解だらけの開発生産性 ── DMM.comで見てきた誤解 ── 

2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム開発本部 副本部長 2 新刊 

書籍について 2026年7月21日 翔泳社より発売 「はじめに」より引用 「うちの開発、もう少し早くならないか」 開発生産性に対するこうした問いは、言われる側にも時には言う側 にも居心地の悪いもの になりました。経営は数字で語れといい、現 場は数字で測りきれない仕事を抱えています 

ストーリー（感情）と解説（根拠）で展開 

2023年〜 2024年〜 2025年〜 2026年〜 

開発生産性は、”誤解”だらけ <人月の誤解> - 人を増やせば、速くなるの誤解 - AIを入れれば、速くなるの誤解 <標準化の誤解> - 同じ数字を全チームに当てはめれば比較も改善も進 むという誤解 - トップダウン決めた指標を追えば現場の生産性は揃う という誤解 ..etc <速く出せば、生産性が上がるという誤解> - テストを削ればスピードが上がるという誤解 - 動くものを早く出せば仕様は固まるという誤解 - 「もっと早く」と押せばアウトプットは増えるという誤解 <小手先の指標による誤解> - 測れる数字が正しい生産性という誤解 - エンジニアだけが生産性を求められればよいという誤解 <測れないから説明できないという誤解> - 技術的負債は測れないから語れないという誤解 - 認知的負債は見えない語れないという誤解 - 今動けばよくて、負債はあとで解消すれば良いという誤解 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 Outline 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 Outline 

9 書籍の物語展開 1. 「うちって、開発遅くないか？」という、 いきなりの感覚的な問い が、主人公に対して発生する 2. 部長から「数字を出せ／すぐに改善して」と言われるが、何を測り何を直せば改善したかが証明できるかが共 有されておらず、定義なき重圧 だけがのしかかる 3. 生産性向上の宿題と同日にPMから「来月末リリース必須」の案件がきて、計画の信頼性が「 とにかく早く 」に すり替わる 4. 「とにかく早く」で要件は 大枠のまま 、仕様変更・手戻り・テスト削り・残業が連鎖し、現場の痛み（疲弊・負債・ 品質不安）が蓄積する 5. 結果として、ユーザーからのクレームによる障害対応の酷使で「速く出すこと＝正義」が崩壊 1.すぐに改善して！の重圧 

10 1.1「開発生産性」という言葉が持つ構造的問題（定義なき重圧）の理解 ● 重圧の正体は「遅さ」 そのものではなく、何が問題か・何を測るかが揃っていない状態で イメージだけが作ら れること ● 立場ごとに分子・分母が違い、現場の「速くなった体感」と経営の「価値の数字」には時間差がある ● 最初に揃えるのは何のため／どの指標／誰の何のために使うか ● 開発生産性の外発的動機、 約束の信頼性（いつまでに、どの品質で届くか） である 1.すぐに改善して！の重圧 これがほぼ結論 

11 ● 開発生産性の議論には、外から開発生産性を求められる「外発的動機」と自分たちの成長のために開発生 産性をあげていく「内発的動機」がある ● 外発的動機 においては監視・管理の意味合いが強い（アンチパターン） a. 本来、信頼が積み上がれば チーム外から開発生産性は気にならなくなる ● 内発的動機 によるエンジニアが自分たちのため（ケイパビリティ）にやる開発生産性は良い 1.すぐに改善して！の重圧 開発 チーム 「開発遅い！計測」 (外発的動機) 「もっとユーザーに早く価値を届けたい！」 (内発的動機) 「もっとユーザーに早く価値を届けたい！」 (内発的動機) 目的は一緒なのに すれ違う 

12 改善の体感とのズレ 価値はプロダクトが良くなったか（顧客価値が向上したか）、売上・利益が改善したか = 最終成果 でしか確定しない。 現場の「速くなった実感」は先に現れ、経営の求める「数字」や「開発生産性」はあとから しか見えないズレ。先行指 標と遅行指標とも言える。 1.すぐに改善して！の重圧 物的生産性と付加価値生産性の 議論とも関連 

13 1.2 スピード重視の技術的背景と問題点を理解する ● 「大枠で進めて」は計画柔軟ではなく、 修正コストを後工程に先送りする選択 。 a. 大枠のまま実装→変更のたび設計ごとやり直し。 「変化に柔軟 」と「計画が不要 」は別物 b. NIST The Economic Impacts of Inadequate Infrastructure for Software Testing （2002） 1.すぐに改善して！の重圧 <欠陥修正コストの段階的増大> 5倍〜30倍の修正コスト 

14 1.2 スピード重視の技術的背景と問題点を理解する ● 設計の軽視 → テスト省略 → 負債・疲弊 → またスピード、の負のスパイラル a. 削った時間は障害対応として利息で返る。内部品質にこだわるのは 速さの敵 ではない b. Martin Fowler Is High Quality Software Worth the Cost? は、内部品質の低下が数週間で変更速 度を鈍らせると論じる 1.すぐに改善して！の重圧 損益分岐点は 1ヶ月後ぐらい 

15 1.2 スピード重視の技術的背景と問題点を理解する ● 「品質かスピードか」は偽の二択。ただ、その思考スキルと技術スキルを身につけるためには.... a. t-wadaさん : 質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） 1.すぐに改善して！の重圧 AI駆動な今の時代の時系列にど う当てはめていくかは悩み 

16 1.3 ソフトウェアは複雑だ ● 難しさは本質的複雑性（銀の弾丸なし） と偶有的複雑性（設計・負債で減らせる） に分かれる a. フレデリック・ブルックス : Brooks No Silver Bullet（銀の弾丸はない） b. フレデリック・ブルックス : The Mythical Man-Month（人月の神話） ● 転換点は特効薬探しではなく、 本質に向き合い、定義・測定・説明可能性を関係者で揃えること 1.すぐに改善して！の重圧 偶有的複雑性は、本質的複雑性に付随する 本質を無視してHowをしても改善効果は長引かない 

17 1.3 プロジェクトも複雑だ ● DORA やSPACE はデリバリーパイプラインの健全性（Four Keys）、開発者の多次元の生産性を整理する枠 組み ● 価値を作り出すパイプラインの役割として フロー（変更が価値として届く速さと安定性）と 価値・計画 （何をい つまでに約束するか）はプロジェクトマネジメントの枠組み（TOC / CCPM） 1.すぐに改善して！の重圧 

18 1.3 プロジェクトも複雑だ 1.すぐに改善して！の重圧 資源制約 = 開発者のリソースがほとんど 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 Outline 

20 書籍の物語展開 1. バグ対応が続き、新規開発が遅れる中で「今のやり方は継続的な開発か」という問い 2. 平均プルリクエスト数などは動いているように見えても、同じ規模の機能が遅くなる現象。 見た目の指標と実 態の乖離 が説明できない痛み 3. 負債の影響を可視化しようとしても一人では限界で経営が求める「数字」に 翻訳できず孤立する 4. コスト換算と予兆の観点を手がかりにチームへ共有し「測れない価値」を議論する土台に初めて手が届く 2. 測れない開発生産性を求められる重圧 

21 「測れる数字 = 正しい生産性」 とは限らない 裏にある測るのが難しい指標にこそ課題がある - 測るのが難しいもの - 「技術的負債（保守性観点）」の深さ - 「認知的負債（Cognitive Debt）」の深さ（AI駆動開発でより顕著に） - メンバーのモチベーション・熱量 - それらが与える開発生産性への影響度合い 2. 測れない開発生産性を求められる重圧 

22 技術的負債が開発速度に与える影響の理解 ● 負債は、確実に速度を落とすのに 従来の指標では測れず説明できない構造 ● 可視化は単一KPIではなく、多角的な予兆検知が要る（ 石垣「技術負債の『予兆検知』と『状況異変』のスス メ」） 2. 測れない開発生産性を求められる重圧 開発 0→1 健全な ソフトウェア 変更容易性が低い ソフトウェア t 健全な ソフトウェア 【抑制】 負債の進行をできるだけ遅らせる 【解消】 負債の解消を早める 【予兆検知】 予兆をモニタリングし、アラートをかける 予兆検知→抑制→解消 

23 予兆検知 = 負債のキャッチアップはどこか 1. 計画見積もりと実績値の差分で予兆検知 a. ブラックボックステスト 2. コードの変更やレビューにかかる時間が増加で予兆検知 a. 主にFour keysデータ 3. 障害件数の再発防止策完了件数や平均復旧時間（MTTR）で予兆検知 a. ポストモーテム分析 4. エンゲージメントスコアの低下で予兆検知 a. 社員モチベーションの移動平均 2. 測れない開発生産性を求められる重圧 t 

24 IPA 「IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 最新定量データと分析結果」 計画より上回っている 計画より下回っている 2. 測れない開発生産性を求められる重圧 計画が大きいほど 見積もりが実態とズレる 

計画工数 予測 フェーズ 超概算 (予測) 詳細 (予測) 開発 (予測) リリース （実績） 1人月 10人月 一般的に このぐらいだろう (類推見積もり) バックログ アイテムに分解した 結果、倍ぐらいか かった PRD / DD 書いた 企画 設計→Ready 開発中 振り返り 予測（見積もり） コミットメント（約束） 実績 25 

計画工数 予測 フェーズ 超概算 (予測) 詳細 (予測) 開発 (予測) リリース （実績） 1人月 10人月 一般的に このぐらいだろう (類推見積もり) バックログ アイテムに分解した 結果、倍ぐらいか かった PRD / DD 書いた 企画 設計→Ready 開発中 振り返り ここのズレが大きいと予 兆あり 色んな原因が混在 ・スコープクリープ ・技術スキル 26 

27 予兆検知 = 負債のキャッチアップはどこか 1. 計画見積もりと実績値の差分で予兆検知 a. ブラックボックステスト 2. コードの変更やレビューにかかる時間が増加で予兆検知 a. 主にFour keysデータ 3. 障害件数の再発防止策完了件数や平均復旧時間（MTTR）で予兆検知 a. ポストモーテム分析 4. エンゲージメントスコアの低下で予兆検知 a. 社員モチベーションの移動平均 2. 測れない開発生産性を求められる重圧 おすすめ順 

28 「今は動くから」の先にある認知的負債 ● 「動いている／テストも通る」でも、理解が追いつかないと負債は加速する = 認知的負債 2. 測れない開発生産性を求められる重圧 速度が理解力を上回るとき 技術的負債はシステム障害や保守コストとして顕在化するのに対し、認 知的負債は開発速度の指標には現れません 。 コードは正常に動作し、テストもパスし、機能もリリースされます。しか し、この負債はシステムを構築したエンジニアの心の中にのみ存在し、 彼ら自身の仕事に対する不安として現れます。 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 Outline 

30 書籍の物語展開 1. チームの振り返りで本音が出ると、要件・負債・時間・コミュニケーション・評価のズレが構造的な痛みとして共 有される 2. 課題が言語化される前に数値目標だけが先行し、 指標を測ること自体が新たな重圧 になる 3. ストーリーポイント / 見積もりのバッファ水増し、簡単なタスク偏重。形骸化した指標が本当の改善を食え潰し ていると気づく 4. 「私たちは何を大切にしたいか」を合意し、役割別の小さなアクション（要件／負債返済／QA／対話）が動き 始める 3. 重圧から生み出される小手先の指標 

31 なぜ指標が形骸化するのか ● 指標が目標化し、本質的価値から 乖離する構造 a. グッドハートの法則・・・「指標が目標になると、その指標は良い指標ではなくなる。」 b. キャベルの法則 ・・・「社会的な意思決定に数値指標が使われるほど、その指標は不正や歪みの対 象になり、本来測りたい現象をゆがめる。」 3. 重圧から生み出される小手先の指標 ● 指標（KPI）は、現実を測るための「ものさし」であるべき ● その指標自体を達成目標にしてしまうと、人は 指標を良く見せる行動 を取り 始め、本来達成したかった価値から離れてしまう 

32 なぜ指標が形骸化するのか ● 人は見えるものを優先的に処理し、 安心感を得る構造 がある a. 不確実性低減理論（Uncertainty Reduction Theory） i. 社会心理学の理論で、人は 不確実性を減らそうとする動機 を持ち、不確実性が下がると安心感 や信頼感が高まる ii. 例 : プロジェクトの進捗が見える / システムの状態が見える b. 認知的流暢性（Cognitive Fluency） i. 人は理解しやすい・処理しやすい情報を、より正しい・安全・信頼できると感じる 傾向がありま す。 ii. 例 : 読みやすいフォントの文章 / 分かりやすいグラフの方が説得力が高い c. 知覚されたコントロール（Perceived Control） i. 人は「状況を把握・制御できている」と感じるだけで、不安が軽減されます。 ii. 例 : エレベーターの「閉」ボタン / ダウンロードの進捗バー 3. 重圧から生み出される小手先の指標 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 Outline 

34 4. 開発者だけが開発生産性を考える重圧からの脱却 書籍の物語展開 1. 成果が出ても「経営層にどう説明するか」が重圧になり、エンジニア指標だけでは伝わらない不安が残る 2. 事業側が見るのは Four Keys の改善そのものではなく、 計画を信じて立てられるか という信頼性 3. 技術の話をビジネス用語へ翻訳し、開発生産性ツリーで「お金と時間がどこに使われているか」を共通言語 化する 4. 評価の軸をビジネスインパクト・持続可能性・効率性へ広げ、「エンジニアだけの問題」から組織の取り組みへ 移る 

35 エンジニア視点とビジネス視点の融合 ● 重圧の背景は、測っているものが層ごとに違い 、共有されないまま評価だけが求められる構造 ● 開発側：リードタイム・デプロイ頻度・失敗率・MTTR（DORA / Four Keys） ● 事業側：計画信頼性・予測可能性（欲しいタイミングで届くか） ● 本質は約束の信頼性。内部健全性の改善がそのまま事業満足になるとは限らない 4. 開発者だけが開発生産性を考える重圧からの脱却 

「開発生産性」が経営層に伝わらない理由は、 “言語”が違うから 

事業責任者 PdM Eng Des Eng Eng Des BM BM 経理 経営 Eng EM PM/Dir PdM PdM 横断 組織 37 開発組織 経営層 CxO・役員 （経営企画 / 経理） 人数サイズ 予算権限 仮体制図 

38 開発組織 経営層 CxO・役員 （経営企画 / 経理） Eng Des Eng Eng Des BM BM 経理 経営 Eng EM PM/Dir PdM PdM 横断 組織 事業責任者 PdM 財務諸表 ・P/L : 販管費への影響度合い ・B/S : 資産、償却、税負担への影響 金額 ・販管費の最適化 ※ 同じ単価でも、施策回数と質が違う ※ 生産性が落ちてくると、追加投資額が必要 工数・工期（計画・ロードマップ） ・生産性が高くなると当初計画よりも短くなる ・もしくは類推見積もりの角度が上がる 開発チーム内の向き合い ・ソフトウェアの内部品質、エコシステム ・Four keys, テストカバレッジ 数値の流れ P/L 販管費 cost（⾦額） cost（⾦額） man-month（⼯数） スループット（1⼈⽉あたりの⽣産性） man-month（⼯数） B/S 資産 / 減価償却 “開発生産性”はレイヤーごとに意味が違う 

事業責任者 PdM Eng Des Eng Eng Des BM BM 経理 経営 Eng EM PM/Dir PdM PdM 横断 組織 39 開発組織 経営層 CxO・役員 （経営企画 / 経理） 人数サイズ 予算権限 ▼ P/L（予算が操作可能変数） ┗ 人件費（ソフトウェア仮勘定） ┗ 減価償却費 ┗ 採用費（フィー） ┗ 通信費（サーバー費用等） ┗ ライセンス費,etc.. ▼ 個・チームの生産性 ┗ コード ┗ チームパフォーマンス ┗ バックログ ┗ フロー状態 ▼オブザーバビリティー ┗ n ... スループット（1⼈⽉あたりの⽣産性） 立体感 プロセスは 上から下へ 生産性の価値 cost（⾦額） man-month（⼯数） 使 っ て い る 武 器 接続箇所 

事業責任者 PdM Eng Des Eng Eng Des BM BM 経理 経営 Eng EM PM/Dir PdM PdM 横断 組織 40 開発組織 経営層 CxO・役員 （経営企画 / 経理） 人数サイズ 予算権限 スループット（1⼈⽉あたりの⽣産性） 立体感 プロセスは 上から下へ 生産性の価値 cost（⾦額） man-month（⼯数） 接続箇所 無理に飛躍して、 現場の指標を 管理会計に繋げない。 机上の空論になる 

Eng Des Eng Eng Des BM BM 経営 Eng EM PM/Dir PdM PdM 横断 組織 41 開発組織 経営層 CxO・役員 （経営企画 / 経理） 事業責任者 PdM モニタリング基盤を構築して、 正しくレポーティング Sales Mktg BigQuery man-month （⼯数） スループット （1⼈⽉あたりの⽣産性） cost（⾦額） 経理 資産価値 / 減価償却 オーバーラップさせる箇所の意味を変換すればいい 

4. 開発者だけが開発生産性を考える重圧からの脱却 42 BigQuery ヘルスチェックレポートの運用 1. 管理会計 / 財務会計の数値 2. 人員構成（雇用形態 / 等級） 3. 採用計画・育成計画 4. 開発生産性（投入工数の内訳） a. 開発 / 運用の割合 b. AIコスト（トークンマネジメント） 5. プロジェクト 点と点を繋げて、未来を語れる部門運営をしている 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 Outline 

44 標準化を求められる重圧 書籍の物語展開 1. 1年後、速度・品質・負債返済が「測れる価値」として認められるが、次に来るのは 全社標準化せよ という重圧 2. 他チームに同じ数字と目標値を当てはめようとした瞬間、1年前の自分たちが嫌だった「数値だけ追う組織」 を再現しかける 3. 指標そのものより、標準化をやめて学びを広める側へ舵を切る 4. スピード偏重チームとの比較で持続可能性の優位がデータで見え、メンターとして「なぜそのコードが必要 か」を問うリーダーへ育つ 

45 標準化を求められる重圧 トップダウンの標準化では数値を追う組織になる ● 開発生産性に関する 一律の指標を評価に直結させると数値追従の組織 になり、学習文化が育たない構 造 ● 相対優位は「絶対に速い」ではなく 学習速度・適応力 。全社目標達成より、各チームが自分たちで指標を設 計し改善し続けること ● DORA等は学習用の共通語になりうるが、文脈無視の全社公式化・評価直結は形骸化の入口 自分たちで指標を作り、チームの生産性を考えるリーダーへ ● 重圧からの脱却とは重圧がなくなることではなく、 翻訳しながら判断できる ようになること ● 数値を超えた価値（負債返済・育成・説明責任）を評価に組み込む 

1. すぐに改善して！と言われる重圧 2. 測れない生産性を求められる重圧 3. 重圧から生み出される小手先の指標 4. 開発者だけが開発生産性を考える重圧からの脱却 5. 標準化を求めれれる重圧 まとめ 

告知 : 2026/07/29(水) 12:00 〜 13:00 

参考文献 DORA metrics guide https://dora.dev/guides/dora-metrics/ Four Keys (Google Cloud) https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance DORA 2025 State of AI-Assisted Software Development https://dora.dev/research/2025/dora-report/ Forsgren et al., The SPACE of Developer Productivity (ACM Queue, 2021) https://dl.acm.org/doi/10.1145/3453928 Noda et al., DevEx: What Actually Drives Productivity? (ACM Queue, 2023) https://queue.acm.org/detail.cfm?id=3595878 Forsgren et al., DevEx in Action (ACM Queue, 2024) https://queue.acm.org/detail.cfm?id=3639443 NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing (2002) https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf Martin Fowler, Is High Quality Software Worth the Cost? https://martinfowler.com/articles/is-quality-worth-cost.html Martin Fowler, Technical Debt (Cunningham) https://martinfowler.com/bliki/TechnicalDebt.html Martin Fowler, Technical Debt Quadrant https://martinfowler.com/bliki/TechnicalDebtQuadrant.html Brooks, No Silver Bullet https://www.cs.unc.edu/techreports/86-020.pdf Brooks, The Mythical Man-Month https://www.amazon.co.jp/dp/4865944583 

Stripe / Harris Poll, The Developer Coefficient (2018) https://stripe.com/reports/developer-coefficient-2018 Besker et al., JSS 2019 https://doi.org/10.1016/j.jss.2019.06.004 Petersen 2011 https://doi.org/10.1016/j.infsof.2010.12.001 Graziotin & Fagerholm 2019, Happiness and the Productivity of Software Engineers https://link.springer.com/book/10.1007/978-1-4842-4221-6 Brynjolfsson 1993, The Productivity Paradox of Information Technology https://dl.acm.org/doi/10.1145/163298.163309 Solow 1987, productivity paradox Goodhart / Campbell Goldratt, The Goal / Critical Chain ISO/IEC 25010 https://www.iso.org/standard/35733.html GitClear, Coding on Copilot / AI Code Quality https://www.gitclear.com/ Faros AI, AI Productivity Paradox https://www.faros.ai/ai-productivity-paradox https://www.faros.ai/blog/ai-software-engineering METR 2025 https://arxiv.org/pdf/2507.09089 Peng et al. / Demirer et al., Copilot RCT 参考文献 

BCG, Where's the Value in AI? https://www.bcg.com/publications/2024/wheres-value-in-ai HBR, AI Doesn't Reduce Work - It Intensifies It https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it Cognitive Debt (Rockoder) https://www.rockoder.com/beyondthecode/cognitive-debt-when-velocity-exceeds-comprehension/ Ankit Jain, How to Kill the Code Review https://www.latent.space/p/reviews-dead Beller et al., DAT (Diff Authoring Time at Meta) https://arxiv.org/pdf/2503.10977 McKinsey, Demystifying Digital Dark Matter https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/demystifying-digital-dark-matter-a-new-standard-to-tame-technical-debt McKinsey, measuring developer productivity / AI governance NBER, firm-level AI adoption vs organizational outcomes CMR, Seven Myths about AI and Productivity https://cmr.berkeley.edu/2025/10/seven-myths-about-ai-and-productivity-what-the-evidence-really-says/ MIT Sloan, Why AI Will Not Provide Sustainable Competitive Advantage https://shop.sloanreview.mit.edu/store/why-ai-will-not-provide-sustainable-competitive-advantage Ishigaki, tech debt early detection (Speaker Deck) https://speakerdeck.com/i35_267/ji-shu-fu-zhai-no-yu-zhao-jian-zhi-to-zhuang-kuang-yi-bian-nosusume Ishigaki, is development productivity profitable (Speaker Deck) https://speakerdeck.com/i35_267/is-development-productivity-profitable Ryuzee, showing working software at short intervals https://www.ryuzee.com/contents/blog/14593 参考文献