2025年 開発生産「可能」性向上報告

今年、はじめてのアドベントカレンダーに挑戦しています。
本記事は開発生産性コミュニティD-Plus🐬 Advent Calendar 2025の16日目の記事です。
昨日は@Kuchitamaさんによる記事でした！

qiita.com

このブログでは、D-Plusさんの12/16のイベント「2025年を総括しよう！今年の開発生産性を振り返る大忘年会」での登壇に向けて、資料作成のための思考の整理も兼ねてまとめた内容となります。
私の今年の開発生産性について振り返ります。

d-plus.connpass.com

はじめに

今年、私の携わる開発の領域にも生成AIがやってきました。
私自身、新規プロダクトの仕様駆動開発に携わっています。
今年の開発生産性を振り返る時、AIによる圧倒的な生産量の増加が思い浮かびます。
それと同時に今まで以上に、エンジニアにソフトウェアを作ること以外での成長が求められるようになったと感じています。
今回、開発生産性を上げていくための可能性を「開発生産可能性」として整理し、今年の私の開発生産可能性の向上を振り返ります。

開発生産可能性について

開発生産可能性とは

開発生産性を考えるとき、私はそれを測定可能な出力値として意識します。
アウトプット、アウトカム、インパクト。
いずれも出力されたものに対する捉え方だと考えています。
本記事では、そうした出力のために必要となる入力を、開発生産可能性として扱います。

開発生産可能性は「面積」で捉える

開発生産可能性とは、生産のためのエネルギーの総量と表現できます。
その総量は「協働できる人数×活用できる知識」で定義できると考えています。
「協働できる人数」を幅、「活用できる知識」を高さで表すことで、開発生産可能性を面積で捉えることができます。

面積 (生産のためのエネルギーの総量) = 幅 (協働できる人数) × 高さ (活用できる知識)  

この面積を拡張していくことが、開発生産可能性を向上させることとなります。
では、幅を広げ、高さを伸ばすとはどういったことなのか、を整理していきます。

「幅 (協働できる人数)」を広げる：サイロを壊す

幅の定義

開発生産可能性における「幅」は、協働できる人数、つまり共通目的に向かって一緒に考え動くことができる人数と考えています。
1人だと1人分の生産性が見込めますが、10人だと10人分の生産性が見込めるわけではありません。
1つの物事に対して複数の役割を設けている場合、人数がそのまま生産性に反映される訳ではないと考えているためです。
そのギャップを埋める考え方として、役割の壁を越えてひとつの価値に向かうDevOpsやチームトポロジーといった視点が重要になると考えています。
人数が増えても、共通目標に向かう協働が成立しなければ、生産性には結びつきにくいと考えています。

幅のふりかえり

私が昨年携わっていた新規プロダクトをリリースするためのプロジェクトでは、リリースを目的とした役割ごとのチームを設けていました。
リリースという短期的な成果は得られましたが、チームごとの属人性が生まれ、リリース後の長期的なプロダクト開発には厳しい状態になっていました。
今年、リリース後にワンチームとして役割が見直された開発チームだけで、プロダクト開発を推進することができる状態を実現できました。
それまでチーム間で発生したボールのやり取りやお見合いはなくなり、一つのチームがプロダクトの成長のために協働できる状態となりました。
チーム間のサイロを壊すことで幅を広げることができた1年になったと思います。

「高さ (活用できる知識)  」を伸ばす：未知の視点を取り込む

高さの定義

開発生産可能性における「高さ」は、活用できる知識、つまり自分たちが抱える課題に対して解決に導いてくれる知識量であると考えています。
複雑な課題、はじめての課題をどれだけ最適な状態に導いていけるかが、生産性をあげるカギになると考えています。
そのためには、自分の環境における試行錯誤を通した学習に加え、外部からの学びが重要と考えています。
既に最適な実践例がある中で、それを知らずに試行錯誤するのは、もしかしたらチームや組織に知識が循環していない不健全な状態かも知れません。
知識が意思決定の質を上げ、課題解決を促進すると考えています。

高さのふりかえり

今年、私個人で言えば書籍や勉強会、カンファレンスを通じ、自分の環境からだけでは得られなかった学びを得ることができました。
学んだことをチームに展開し、内容によってはメンバーと議論し、試行錯誤して適応を試み、自分たちのチームを新しく成長させていく試みを行うことができました。
既に知ったつもりでいたことに対して、浅い理解でいたことに気づくことも多くありました。
特にマイクロマネジメントでのウォーターフォール開発経験が長かった私にとって、チーム開発についての学びは大きな転換となりました。
チーム成長が長期的なプロダクト成長を実現することを学ぶことができました。
また、今年は学びを通し、実践したことをアウトプットすることもできました。
他の組織の開発生産可能性に繋がっていればと思います。

「面積 (生産のためのエネルギーの総量) 」を拡張する：チームや組織で価値を実現する

面積の定義

開発生産可能性における「面積」は、生産のためのエネルギーの総量、つまり開発生産性を実現するための可能性であると考えています。
チームや組織で知識を高めていくことが、開発生産可能性を高める上で重要であると考えています。

面積のふりかえり

今年、個人で知識を求めるだけではなく、チームで同じ課題感のもと知識を求める動きができました。
チーム内で課題図書を決めての勉強会、部を越えたAI駆動開発についての勉強会、メンバーと同じカンファレンスに参加しての感想戦などを開催できています。
そうしたやり取りを通じて、幅のある高さをチームで実現し面積を広げる取り組みができました。

「バネ」を持つ：面積拡張を可能にする原動力

バネの定義

これまで、幅、高さにより面積を拡張していくことの重要性を整理してきました。
ただ、面積は与えられるものではなく、拡張するものであると考えています。
そこで、面積の拡張のために重要となるのが「バネ」であると考えています。
チームが知識を高めていくことに能動的であることをバネと表現しています。

バネのふりかえり

今年はプロダクト開発にチームで取り組める状態を作ることができました。
個人に依存せずチームでプロダクト成長に向き合える状態を実現できました。
プロダクト成長のために何か課題が起こったときに、自分たちで解決していけるオーナーシップを持って取り組むことができています。
そうした、個々のメンバーが自主的に役割を分担し、問題解決や意思決定を行える状態が、面積を広げていくバネになっていると思います。

まとめ

今回、開発生産「可能」性をもとに1年の開発生産性に対する取り組みを振り返ってきました。
生成AIがアウトプットの速度を劇的に加速したために、今まで以上に作ることに向けたメンバーの連帯や判断が重要になっていると感じています。
チームがオーナーシップを持てたからこそ、開発生産性をあげていけると考えています。

後日談

この内容を無事に登壇資料にできました！

speakerdeck.com

明日はおおいしさんの記事となります！！