開発生産性カンファレンス2025の感想（1日目）
開発生産性カンファレンス2025 に参加してきました。ここでは1日目のセッションの感想を書きます。
開発生産性測定のトレードオフ「グッドハートの法則」はもっと悲観的に捉えるべきだった
スピーカー:
- Kent Beck
ケントベックといえばエクストリームプログラミングで有名な人。テスト駆動開発なども提唱している。 アジャイル開発やDevOpsと通ずる要素も多数ある。
生産性というのは、基本的に以下の式で算出する。
Productivity = Output / Input
ここで問題となるのがInputとOutputを「何にするのか」であると。 このInputとOutputの定義によって、良い効果が出たり悪い効果が出たりする。
例えばPull Requestの数を測定したとする。 一般的に、Pull Requestが多いということは小さな変更を頻繁に行うということなので、優秀な開発者であればこの傾向がある。 なので、Pull Requestの数を計測して、数が多いほど素晴らしいという風に定義する。
ここで、Pull Requestの数に対して各開発者に「プレッシャー」を与えるとどうなるか。例えばPull Request数のランキングを貼り出すなどだ。 すると一部の開発者はズルを始めてしまう。最下位になりたくないからだ。分ける必要もない変更を複数のPull Requestに分割したりし始める。 それに意味はない。
[!NOTE] 「開発者ごと」にランキングにするというのが良くないような気がする。複数人・チームとして計測すれば、あまりそういうことは起こらないような気もする。
ただ、チームごとで比較を始めると、今度は数が少ないチームメンバーを批判したりし始めるかもしれない。「相対的な比較をしない」というのが重要なのかもしれない。
あるいは「本番環境の障害の回数」などを指標に設定したとする。 すると、障害が発生しても報告しなくなる（数を減らす）という不正が起こるようになる。 確かにあり得るかもしれない。
あと、投資家から見ればPull Requestの数などはどうでも良い。 いくら投資（Input）した結果、どの程度利益（Output）が出たのか、しか興味がない。
まとめ:
ケントベックの話を聞けると期待していたけど、話していることは 開発生産性について議論する前に知っておきたいこと とほぼ同じだったかな。 特に目を見張るような内容ではなかった。とはいえ、グッドハートの法則として数字を目標にするとロクなことにならない、というのはそうなんだろうなと感じた。
ペアプロ × 生成AI：現場での実践と課題について
スピーカー:
- 株式会社コドモン
スライド: https://speakerdeck.com/codmoninc/generative-ai-in-pair-programming
コドモンではエクストリームプログラミングを全面導入していて、基本的に1日8時間あればそのうち6時間はペアプログラミングをしているらしい。 2025年4月からClineを全面導入しているが、それによって開発のスタイルがどう変わったのかの話。
AIの導入をして、1ヶ月ぐらい経ってアンケートを取ったら、6割ぐらいは「まぁ生産性が上がった」という回答だったらしい。 この「まぁ」という部分に注目して、何が「まぁ」なのかを確認した。
するとネガティブな意見には「AIがいるとオペレーターが暇なことが多い」みたいな意見もあったとか。 ドライバーがAIと会話していると、オペレーターが黙っている時間が増えて「コレジャナイ感」が出てしまった。
あと、AIを含めたモブプロをすると、人間同士は口での会話でお互いの認識を合わせる。 そしてやりたいことが決まり、それをAIに指示するのだが、プロンプトで人間同士の理解度を完全に伝えきれない。 思ってたのと違うコードを書いてくるので、まるで「話を聞いていないモブが一人増えた」みたいな感覚に陥ってしまうとか。
後半は、AIによって組織や個人のエンジニアリング能力とかの話をしていた。 AIを使いこなしている人って冷静にみると元々優秀な人が多いよねと。AIに対する指示が的確なんだと。
優秀なエンジニアは将来的なことも想像しながらコードを書いて、状況に変化が起こっても適応できるような柔軟性の高いアーキテクチャにしようとする。 しかしその観点を持たないままAIにコードを書かせると、現時点ではそれで十分だけど、というようなコードが出てくることが多い。 結局のところ、AIが書いたコードが使い物になるのかを見極められる能力を有していないといけない。
まとめ:
現時点では色々なAIエージェントがあって、それぞれの特色があるみたいだけど、これがこのままずっと続くのか、あるいは巨大な1つのエージェントに統合されていくのか。 AIとのペアプロを考えると、AIが画面も見るし、音声で話しかけると答えてくれるしみたいな、そんな感じになるとかなり良いかもなと感じた。
レベル1の開発生産性向上に取り組む─日々の作業の効率化・自動化を通じた改善活動
スピーカー:
- ソーシャルデータバンク株式会社
自動化の話:
まず自動化ツール作った話をしていた。
- AWS開発環境へのIPアドレス自動登録ツール
- 開発環境の自動更新ツール
結構凝ったツールを作っているような感じがした。 うーん、、この手のツールはメンテナーがいるうちは良いかもしれないけど、その作った人が会社辞めちゃったらどうするのかなぁ。 良かれと思って作ってくれた自動化ツール、それをメンテできる人がいなくて技術的負債になったケース、めっちゃ経験している。
なるべく誰でも理解できる程度にシンプルにして、ある程度の手動作業は許容したほうが持続可能性が高いと思う。
ドキュメンテーションの話:
障害対応のポストモーテムの議事録なんかを残しているが、読まれないので、どうしたのか。 ChatGPTを使って絵本にしてみたそうだ。
絵本ぐらいだと、ちょっと眺めてみる、というようなことは起きたそうだ。 それで学びになりそうなことがあれば、ちゃんとした議事録も読むという流れが生まれたとか。
これは面白いと思った。
Pull Request管理の人間ボット:
WIPのPull Requestが100件以上溜まっているというような状況があったらしい。 そうするとコンフリクトまみれになっていたりして手がつけられないというような状況だったりもしたとか。
典型的なWIP制限が効果ありそうだが、システム的な制限はやらなかったとのこと。 そういう状況になっている人がいたら、サポートをするというような方針で進めたと。
LeanとDevOpsの科学 でWIP制限が効果あるとか書いてあったが、あまりピンと来ていなかった。 この人がコンフリクトが大量発生した、みたいな話を聞いて合点がいった。そういうことか。
で、WIPが増えすぎないために多くなっているところへ「人間が」赴くというやり方は、効果がありそうだなぁと感じた。
まとめ:
自動化の部分はあまり参考にすべきじゃないかなと感じた。仕組みをシンプルにして、GitOpsで作業ログをGitとしてすべて残すというようなやり方がいいと自分は思っている。 それ以外のポストモーテムの絵本化や、WIP制限を人間が見て回るというのは面白いなと思った。
開発組織の進化・スケーリングと「開発生産性」
スピーカー:
- 吉羽龍太郎
スライド（ブログ）: https://www.ryuzee.com/contents/blog/14602
全体を通して、開発生産性というものはプロダクトの成長具合やチームの特性などによって、見るべき指標は異なるということを主張していた。 まとめとしては本人のブログにまとまっている通り。
7ページ目に「文脈のないデータは無意味である」と書かれているが、これの延長線上にある話。 文脈は英語でコンテキストであり、コンテキストというのは、プロダクトの成長具合やチームの特性・状況のこと。 なので、コンテキストに合わせた指標を参照する必要があるということ。
という話より、個人的にはチームの編成の方が興味が湧いた。 チームトポロジー の話のようだ。 この本も読みたい本リストだなぁ。。
自分の役割としては、DevOpsのイネイブリングチームという立ち位置を目指したいところ。
マネジメントの効力感で実現する、持続可能な開発組織
スピーカー:
- 株式会社Hacobu
斜め読みならぬ斜め聞きしかしていないが、マネジメントの決定もADRの形式で残しているというのはいい取り組みだなと思った。 どういう議論が行われてどういう決定が下されて、なぜ今こうなっているのか分からないということは非常に多い。 結果、透明性の低い状況で上層部が何を考えているのか分からず、決まったことを頭ごなしに命令され、訳のわからない施策を強制されるという。
自分が考える理想としては、以下のようにできれば理想だなぁと思っている。
- 議題はMarkdownで草案を作成し、GitHubでPull Requestを出す
- テキストで議論できる程度ならPull Request上で議論する
- 込み入った話が必要であれば適宜会議を開催する
- 会議はすべて録画し、Pull Requestから辿れるようにする
- 話し合われた内容や決まったことのサマリをコメントする
- 決定権を持つ人がApproveする
こうすれば議題や議論の内容、誰が承認したのかもすベて後から振り返ることが可能。
GitHub が見据える開発の次：AIと人間の共創最前線
スピーカー:
- 服部佑樹
始めの方にサラッと触れていたが、GitHub Copilotの特徴はGPLライセンスのコードの混入を防ぐなどのスクリーニングをしっかりやっているところだと。 これ、大企業だと重要なので、大企業はやっぱりGitHub Copilotが第一の選択肢に挙がるし、採用されていくだろう。 大企業に採用されると、ユーザー数的には圧倒的になるし、やっぱり最終的にはGitHub Copilotが勝者になりそうな予感がする。
GitHub Copilot はオープンソースになっているらしい。
Open Source AI Editor: First Milestone
具体的にどういう感じでオープンなのかはよく分からないが、結構革新的な話のように聞こえた。 「プロンプト」を色々設計していたが、これを「秘伝のタレ」として育てて競争優位性にしていくというフェーズは終えた、と考えているらしい。
GitHub Copilot のエージェントは裏で GitHub Actions で動いていて、そこでタスクをこなしているらしい。 これ、ユーザー側からも API か何かで呼べるようになってほしいなぁ。毎日、今日の自分のアクティビティをまとめる、みたいなタスクをスケジュールでやらせたい。
おまけ
お昼にお弁当も配っていた。無料のイベントなのに太っ腹だなぁ。 司会や設備もかなり大掛かりな感じでやっているので、気合の入ったイベントだった。
