開発生産性カンファレンスに参加しました。忘れないように考えをまとめてみました。
# 開発生産性とは
現場レベルでは、DORAの「Four Keys」などの指標を活用しているケースも多いと思いますが、事業や経営の指標とどう紐づけるかについては、まだ試行錯誤の段階という印象を受けました。
生産性 = アウトプット / インプット
インプット（エンジニアの人数や人件費など）は比較的わかりやすい一方で、アウトプットを売上や利益といった事業KPIで捉えると、どうにもしっくりこない。そのような声は多く、私自身も同様の課題意識を持ちました。
このテーマに関しては、広木大地さんのQiita記事を多くの方が参考にしていたようです。
また、以下の図を用いたセッションも複数見られました：
ワンキャリアさんが、アウトプットの指標にROICを活用している事例を紹介されていましたが、実践するには相応の運用負荷がかかりそうでした。反面エンジニア組織が40名以上でd/d/dが1なのはすごい。
自社で導入する場合、組織構造そのものを見直す必要があると感じます。
# チームのあり方の変化
AIの登場によって、コード出力速度は飛躍的に高まっています。この変化を活かすには、意思決定権を現場に近いエンジニアやPdMに委譲する必要があります。特に、同一チーム内に両者が存在し、その場で判断できる構造が理想です。
また、チームの人数は「ピザ2枚ルール」よりもさらに少ない人数が望ましく、その分チーム数を増やすというアプローチが有効だと感じました。
AIの支援によって、エンジニアはより多能工化が進み、フロントエンド・バックエンド・インフラの境界が曖昧に。フルスタック／フルサイクル型の流れになっていくでしょう。
その結果、課題の理解や仕様詰めはエンジニアが担うようになり、PdMは「課題解決」から「課題発見」へと役割がシフトしていくかもしれません。（こうあるべきなんでしょうが）
一方で、こうしたチームの自律性が高まると「サイロ化」のリスクが増します。これを防ぐには、横断的なナレッジ共有やチームの判断力の底上げ（事業・経営視点のインストール）が欠かせません。
# AIとのエンジニアリング
「vibe coding」から「agentic coding」へ。これは、AIが自律的に一次情報を取りに行き、平均以下の仕事を代替していく流れを示しています。
特に、AIによるコード生成が増えることで、テストの重要性はこれまで以上に高まります。CIの実行コストも上がるため、何をテストすべきかを見極める力が問われるようになります。
たとえば、内部実装に依存しない「振る舞いベース」のテストを重視し、リクエスト中心で、モデル単体のテストを省略するような判断もありそうです。
また、コミットメッセージやコードコメントの在り方も変わりつつあります。従来は「人間が読むため」に書かれていましたが、今後はAIが意図を正しく読み取れるようにすることが求められるかもしれません。typoの修正だけのコミットはノイズとなり、AIにとっても意味のある文脈を意識した記述が重要になっていくでしょう。
# 〆
新たな気づきも多くありましたが、自分が感じていた課題や将来像と、登壇者の皆さんの視点が大きく重なっていたことがとても印象的でした。より深く考えるきっかけになった、非常に有意義なカンファレンスでした。
ケント・ベック様に会えたのも嬉しい！
運営・登壇された皆様、ありがとうございました！
# Appendix：参加セッションの資料