【開発生産性カンファレンス 2025】 無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI

エンジニアが抱える「開発生産性」という重圧

石垣：DMM.comの石垣と申します。私は副本部長として約200名のメンバーを率いる組織で、予算権限、プロダクト戦略、AIの取りまとめなどを行っています。本日は、クリエイター組織（開発組織）の取り組み内容をご紹介します。なお、クリエイター組織は、エンジニア、デザイナー、PdMといったものづくりに関わる1,200～1,300名のメンバーで構成されています。

テーマは「無意味な開発生産性の議論、開発生産性という重圧」「感覚に頼らない開発生産性低下の予兆検知」「AIによって開発生産性はどう変化したのか」「AIへの投資と人への投資によるお金の変化」の4つです。

1つ目の「無意味な開発生産性の議論、開発生産性という重圧」について、よくある生産性の議論として「すぐに改善してほしい」と言われるなどの重圧があると思います。例えば、ボタンの色を変える、ページにタイトルを入れるといった要求です。要求がすぐに反映されないと「開発が遅いのではないか」という開発生産性に関する議論が発生します。

弊社には約300のアジャイルチームがあり、横断的な大規模プロジェクトでは10チームほどで進行することも珍しくありません。このような状況では、要件定義が不十分なまま開発が進み「とにかく早く対応してほしい」という重圧の中で開発側が窮屈になり、曖昧な議論が発生しがちです。

生産性の議論においては、小手先の指標が使われることもあります。重圧やプレッシャーがかかることで「なんとなくFour Keysを導入する」といった安易な選択に繋がってしまうのです。しかし、Kent Beck氏の講演「開発生産性測定のトレードオフ 『グッドハートの法則』はもっと悲観的に捉えるべきだった」でも話されていたように、数字目標を設定するとハックしようとする人が出てくる可能性もあります。

さらに、エンジニアは「測るのが難しい生産性を説明する重圧」を感じています。最近では技術負債のレベルやスパゲッティコードの度合いを説明する場面もありますが、「なぜ遅いのか」をエンジニア自身が定量化するのは困難です。加えて、エンジニアだけが生産性を求められる重圧もペインの一つだと思います。



複数のチームが連携する大規模プロジェクトでは、遅延の原因が要件定義の曖昧さや会議の多さにあっても、開発工程で発見されやすい傾向があります。

この点に関しては、全体的なリードタイムの中で最適化を考えることが重要だと考えています。詳細は、後ほどお話しします。

開発生産性低下の予兆を検知する具体的な手法4選

石垣：続けて「感覚に頼らない開発生産性低下の予兆検知」について、具体的に説明します。

生産性低下の構造と解消を考える上で、まず全体像を捉える必要があります。そこで私は、0→1開発の初期段階では、アーキテクチャ、コード、チームの開発スタイルを含めて、最初は健全であるという点に着目しました。

しかし、イテレーションを重ねていく中でメンバーのスキルレベルなどが原因で変更容易性の低いソフトウェアができあがり、それをリプレースなどで解消して元に戻っていくというサイクルがあると考えています。


予兆検知、抑制、解消の3つのフェーズの中で、抑制に注力しているチームは多いですが、私と同じチームに在籍しているミノ駆動さんは、リファクタリングの重要性を強く訴えています。

▼技術愛好家の履歴書～ミノ駆動さんが設計・リファクタリングのスペシャリストになるまで～
https://findy-code.io/media/articles/techbio-minodriven

健全なソフトウェアから変更容易性の低いソフトウェアにするまでのリードタイムを伸ばすことは可能です。リファクタリングには時間がかかりますし、ソフトウェアは減価償却資産と同様に古くなりますが、リファクタリングやリプレースで劣化を抑制できます。根本的な部分の問題は、リアーキテクトで解消することができます。



ただ、どのプロセスで生産性が低下するのかという予兆をモニタリングし、アラートを出すことも必要でしょう。難しい観点ではありますが、取り組むべき課題だと思います。

健全なソフトウェアから変更容易性の低いソフトウェアに変わる背景には、コードやアーキテクチャだけではなく、複数の原因が組み合わさっています。例えば、仕様書や要求が曖昧なまま開発が進んで負債がたまりやすい環境、開発環境やCI/CDの未整備、開発環境とプロト環境の差異が大きいことによる障害など、様々な要素があります。これらは現場ごとに異なり、一概に標準化できるものではないため、どこで生産性が低下しているかの予兆検知が必要です。

ここからは、私がおすすめする4つの予兆検知を紹介します。

①計画見積もりと実績値の差分で予兆検知（ブラックボックステスト）
②障害件数の再発防止策完了件数で予兆検知（ポストモーテム分析）
③投資している開発区分で予兆検知（新規での開発）
④エンゲージメントスコアの低下で予兆検知（社員モチベーションの移動平均）

一番簡単なのは①のブラックボックステストです。



この図は横軸が計画工数、縦軸が見積もりの実績工数で設定されています。図を見てわかる通り、プロジェクトの規模が大きくなるにつれて、見積もりと実績の乖離が大きくなる傾向があります。1人月などの小規模なものは、比較的正確です。これを前提としてお話しします。



弊社では大規模プロジェクトについては、企画段階で超概算見積書を作成します。システムの詳細は見ずに「会員登録機能には約1～2人月かかるだろう」といったざっくりとした形で企画を通すことが多いです。

その後の詳細見積もりでは、PRDやデザインを書いて、APIのエンドポイントの設計などを行います。そういった詳細設計を経て、開発開始時にバックログアイテムに分解されます。

この図で見ると、PRDやDD作成後のバックログ分解段階で、見積もりが大きくズレることはあまりありません。

最もズレが生じるのは、画像一番右に書かれている「予測（見積もり）」でPRDやDDを作成した際に工数が膨れ上がった場合です。これは技術負債の蓄積やチームへの影響が背景にあることが多いです。

開発からリリースまでの実績値のズレに注目されがちですが、ここにはスコープクリープやチームメンバーの離脱など、多くの要素が絡んでいます。技術負債が溜まって生産性が下がっているかという観点では、超概算（もしくは累進見積もり）とPRD/DD作成時の見積もりとの差分を見ることが多いです。



②について、弊社では障害発生件数を追跡し、恒久対応だけでなく再発防止策が実施されているかをトラッキングしています。

すると、生産性が下がっている部署は、再発防止策が積み上がっていく傾向があります。結果としてバグが増え、同じ場所で障害が再発するケースがありました。この指標のトラッキングはおすすめです。



③については、Lookerを活用して、正しいプロダクトに適切な工数を投資できているかを可視化しています。例として持ってきているのは、プロダクトや部門ごとに、毎月どれほどの工数がかけられているかを示すグラフです。

これらの可視化を通して「新規開発に時間をかけたいけれど、技術負債が多くて運用工数がかさんでいる」「プロジェクト内で管理工数やミーティングが多くなっている」といった状況が明らかになります。

ちなみに、弊社の勤怠管理システムでは、働いた時間とその内訳を入力しないと承認されないようになっています。そのデータをBigQueryに送り、Lookerで可視化するというイメージです。



④については、Wevoxというサーベイでエンゲージメントスコアを見ています。

技術負債が多く生産性が低いチームは、スコアも低い傾向にあります。そこでこういったスコアを見せながら、モチベーション低下の解消が必要であることを経営層に伝えています。

ここまで、予兆検知は4つ紹介しましたが、ここは組織ごとに適切な指標を複合的に見て判断すべきだと思います。

AIが変える開発生産性の未来と「AI-BPR」の必要性

石垣：ここからは、予兆検知を踏まえて、AIをどう活用するかについて述べます。

これまでは、成果物が人の手で作られ、物理的な時間と人が同期していたため、人が動かないと開発したものは出てきませんでした。

しかし現在では、Devin、Cursor、Claude Code、Clineなどの利用が浸透し、人の物理的な時間とは非同期に成果物が生み出されるようになっています。人はガードレール役に徹して、CodeRabbitなどで短縮しつつレビューをするだけ、といった形が多くなっていると思います。メンバーの生産性が向上し、1日にPull Request（以下、PR）が10個も出てきてレビューが大変といった状況も生まれつつあります。ゆくゆくは、ここもAIが担うようになると考えられます。

今後は人が問いを立てて最終的な判断をするようになり、作業からの脱却が進んでいくのでしょう。Claude Codeの90～95%はClaude Codeが書いているという話もありますし、これからは「人は何をするべきか？」が重要な問いになると思います。

また「GitHub CEO: manual coding remains key despite AI boom」によると、GitHubのCEOが「最終的には人がガードレール役になる。コードの読み書きや修正能力といった基礎が不可欠である」と述べていたそうです。「AIは置き換えではなく『拡張』である」とも言われており、そこは私も同意しています。

未来予測ではありませんが、開発生産性という観点から見ると、品質を伴った生産量が爆発的に増えることは確実であり、これまでの無意味な開発生産性の議論は不要になるでしょう。

開発が高速化しすぎると、経営層が気にするのは、意図したものが意図した時期にリリースされるかどうかです。細かいFour Keysのデータなどには、興味がなくなります。そのため、生産性が向上すれば、生産性に関する議論は減少するのではないかと考えています。

一方で、AIを巧みに活用している組織とそうでない組織との差は、かつてないほど鮮明になるでしょう。活用している組織は生産量が爆増し、活用できていない組織は開発生産性の重圧を感じるようになるかもしれません。

ここからは、DMMの取り組みについてもご紹介します。AI活用は開発フェーズだけに留まらせるのではなく、前半でお話ししたように、リードタイム全体を見るべきだと考えています。開発フェーズだけを短縮しても、しわ寄せがきてしまうため、要件定義や企画といった全体を見直す必要があります。

私がよく言っているのは、既存のプロセスをそのままAIに置き換えるのではなく、AIを前提としたプロセスに作り変える必要があるということです。

ある人はAIでメール返信や要件定義を効率化したり、エンジニアはAIを使ったバイブコーディングをしたり、といった局所最適化ではなく、ワークフロー全体でAIを活用すべきです。エンジニアだけでなく、デザイナー、PdM、事業部長、経営層も含めて全体を作り変える必要があります。

「Measuring AI effectiveness beyond developer productivity metrics」でも「コード行数やAI提案承認数といった単純な指標だけでは生産性は語れず、本質的にはリードタイム全体を見るべきだ」と述べられています。

最近はBPR（Business Process Re-engineering）をよく聞くようになりました。これは業務プロセスを再設計することを意味しています。それを踏まえて、今後は「AI-BPR」を前提に、ゼロベースで業務を作り替えるアプローチが必要になると思います。



そこで弊社で何をしているかと言うと、約200名の業務プロセスをすべて洗い出しました。図の縦軸に運用工数や組織管理（マネージャーや開発部長の業務を含む）、新規開発工数、保守開発などを置いています。その上で、各プロセスの目的と課題を明確にしました。

制約理論に基づき、全てに共通する課題については、本部を立ててトップダウンで投資しています。



1Qが終わったタイミングで、洗い出した業務プロセスが実際にAIに置き換えられているかどうかのアンケートも実施しました。

赤枠で囲っているのは実装フェーズや設計フェーズといったエンジニア領域で、ここは利用率が高い傾向にあり、利用率が95%を超えるチームもいます。このパーセンテージは、AIによる置き換えだけでなく、AIとの共同作業（AIを使ったバイブコーディングなど）も含んでいます。

しかし、全体の工程の前半（特にマネージャーの業務など）では、まだあまりAI活用が進んでいないため、今後はそこに注力していきたいと考えています。具体的には、AIに強いメンバーで構成されたエバンジェリストチームがAI活用が弱い組織に介入して、改善を進めています。

AIエージェントの介在により、エンジニア領域だけでなく、市場調査などのプロセスもAIに置き換えられる時代になるでしょう。プロセス全体が生産性議論の対象になり得ますし、これまでの課題だったリードタイムの前半部分もAIの生産性議論に含めたいと考えています。

AI投資で生まれた「お金」と「労務」の課題に向き合う

石垣：最後に「AIへの投資と人への投資によるお金の変化」についてお話しします。



組織設計を考える上で、AI投資をした際に人を増やすのか、増やさなくて良いのか、減らすのかといった様々な観点があります。これまでの組織は人を増やしてスケールさせるしか方法がありませんでしたが、今は個の生産性を上げてスケールする、例えば1人1台Cursorを配布することも可能です。

これにより、組織のスケール、つまり開発力を獲得できるようになりました。逆にいうと、完全自律型AIを活用することで、その可能性が広がったと言えます。

必要なリソースを獲得する際に、これまでは採用活動、面接、オンボーディングを経て数ヶ月かかっていましたが、現在は開発力獲得のリードタイムが大幅に短縮されました。



また、人を採用する場合、P/L（損益計算書）で見ると、給与、福利厚生費、地代家賃、採用費など、獲得年収以上にコスト（人件費）がかかります。一方、DevinのようなAIエージェントはライセンス費として手軽に追加できるため、P/Lの見方も変化しています。

AIの投資対効果の測定は現在も非常に難しい課題であり、現時点では利用率を一定の成果としています。しかし、ゆくゆくは「AIに毎月〇〇万円かけた費用対効果は？」と当然問われるようになると思いますし、そこを今考えています。

人を採用する場合、例えば「700万円の人を採用して開発生産性がどれだけ上がったか」といった投資対効果については、あまり問われませんでした。しかし、AIはライセンス料であり、費用対効果が明確に求められるようになります。

AIツールの導入により体感的に作業スピードが上がったように感じる方は多いと思います。AIの効果を示すには「作業が速くなった」という実感を行動ログとして表す必要があります。

定量的なデータで見ると「AIによる置き換え」と「AIとの共同作業」では難易度が異なります。前者の場合は、人件費や工数分がそのままAIの効果として表せます。しかし、後者の場合は、どれだけ速くなっているかを測るのは容易ではありません。

現状では、人間が行った場合の予測値とAIとの共同作業の実績値を比較することで、AIの効果を算出しています。例えば、人間だと5時間かかった作業が、AIとの共同作業では1分で終了した場合、約4時間59分の短縮効果があったと評価できます。



ただ、スピードが向上する一方で、AIが負債を生む可能性もあるため、スピードと品質の両面を見るようにしています。

品質を落として量産しても意味がないため、単一プロセスの最適化ではなく、バリューストリーム全体を見ています。

また、多元的な評価で投資対効果を見るようにしています。ここで最も伝えたいのは、単一的な評価の積み重ねで「1人の生産性が数倍になる傾向がある」ということです。

現状では、特定のチームだと生産性を示すキャップが40→60に向上し、1.5倍になっていることがわかっています。5人のチームで例えると、生産性が1.5倍になった場合、AIエージェントが7.5人分の活動をしていることになります。2人以上の働きが加わったことで、2人分の採用が不要になったと仮定して、1人あたり年収700万円で計算すると年間1400万円程度の削減効果があると言えます。

しかし、AIの効果はコスト削減だけでなく、売上目標達成のために人を増やしてでも生産性を向上させたいという文脈もあります。これについては今後の課題ですが、PR数の増加やキャップのような様々な指標で効果を見ています。



ここでまとめに入ります。最近では、AIを活用して活躍している人が、疲弊し始めているという労務問題も発生しています。

これまでは、残業時間などで個人の負荷が認識できていました。しかし、あるメンバーはミーティング中にDevinを動かし、戻ってきてからバイブコーディングを行うなど、CursorやDevinを常に活用しているため、脳のキャパシティが逼迫し疲弊しています。こういったメンバーが10名ほど出ており、直近では、そういったメンバーの負荷をどのように予兆するのかが課題となっています。とはいえ、全員がAIを最大限活用できる状態になれば、生産性が爆発的に向上する未来も見えているため、その実現を目指したいと考えています。

本日はご清聴ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です