7月3日から7月4日の2日間、東京で開催された開発生産性カンファレンス 2025に参加してきました。
Kent Beckさんをお目にかかれることはなかなか無いので、参加することにしましたが、その他のセッションや交流の中で学びになることがたくさんあった2日間でした！
印象に残ったセッションを取り上げながら、学んだことをまとめます。
- 聞いたセッション
- セッションの振り返り
- セッション以外に経験したこと
- 思ったこと
- さいごに
聞いたセッション
Day1
- 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった
- 整頓のジレンマとの戦い 〜Tidy First?で振り返る事業とキャリアの歩み〜
- AIを前提とした開発プロセスとマネジメントの変革 - 開発生産性+2000%達成に向けた取り組み
- 品質と速度の両立：生成AI時代の品質保証アプローチ
- GitHub が見据える開発の次：AIと人間の共創最前線
- 高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
Day2
- 開発生産性向上の探求：DevOpsの進化、普遍的な原則、そして生成AIがもたらす変革
- スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
- 開発生産性を測る前にやるべきこと：組織改善の実践
- デジタル庁におけるAI活用の最前線：内製化の推進と行政事務効率化の取組み
- MIXIが挑む 自律的組織と自律型AIエージェントの土台となる透明性と仮説検証
- セキュリティ診断AIエージェント「Takumi」の雇用によって実現する開発生産性の向上
- 失敗から再構築した開発推進チームの立ち上げ
- エンジニアが主体的にビジネスに貢献する〜開発現場からの変革
- AI時代の開発生産性戦略：エンジニアは何を武器にすべきか？
- AI時代のソフトウェア開発を考える
セッションの振り返り
開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった
ケント・ベックさんのキーノートです。
ケント・ベックさん
生産性の定義
はじめに、「生産性」という言葉をこのように定義します。
グッドハートの法則
グッドハートの法則は、指標が目標になると、それは良い指標ではなくなるという法則のことです。
たとえ指標が成果と一定の相関のあるものだったとしても、指標を目標値として設定し、成果をコントロールしようとすると途端にその指標は機能しなくなります。
そして、指標が機能しなくなるだけではなく、むしろ期待した効果と逆方向に働いてしまい、むしろ会社全体の仕組みを壊しかねないです。この逆方向の効果は思っているよりも大きな効果であり、警戒すべきことです。
そのため、グッドハートの法則（指標の効果がなくなるという程度の認識）は、楽観的すぎました。
これを極端に捉えて、計測はしないほうがいいということ？と反論する人もいるかもしれませんが、それは100%違い、開発する限りは計測・分析をします。
例えば、「良いプログラマは、コンフリクトの起こりにくく、読みやすい、小さなプルリクをたくさん作る」ということが、計測したことによりわかったとします。そのため、社内でプルリク数を計測して社員同士に競わせることにしました。これは終わりの始まりで、数で評価されるので、数を増やすためにプルリクを分割するようになり、そのプルリクは読みにくくなり、読みにくいプルリクはレビューが遅くなります。これが、より良くしようと思ってやっていることが、結果的により悪くなっている例です。他にも以下のようなものがあります。
- 障害の発生件数：障害が起きても報告しなければ良くなる
- 何時間働いたか：成果に関わらず残業すれば良くなる
- どのくらい売り上げを上げたか：売上の数字だけに着目し顧客の行動に目を向けなくなる
全ての指標は仕組みに意図しない方向に影響を与えてしまうものです。「この指標があれば全てうまくいく」という指標をみんな導入したがっていますが、このセットがあれば一連の開発がうまくいくなんて指標はこの世にありません。
「生産性」をこういうふうに計測すると、本当にそこにプログラマ（人間）がいるかわからなくなっていきます。コンピュータと同じくらい早くコードを書くのは、本当にやりたいことですか？
これは、よりクリエイティブに仕事をするということとは逆です。指標によりクリエイティビティは損なわれてしまいます。クリエイティビティは指標に落とし込むことはできません。
ソフトウェアの素晴らしいところは、数学的な美しさもありますが、計測することも理解することも重要であり、1つに絞れるものではありません。
成果の計測の仕方
成果・価値はアウトカムで評価します。
例えば、アプリケーションに押すと機能する新しいボタンを追加した時、この時点ではまだ価値は出ていません。お客様がそのボタンを押して、今までと違う価値を感じて初めて成果になります。
このような、どういう実装でどうお客様の行動が変わったかということは、すごく計測が難しいです。
プログラマの工数をいくら評価しても、お客様の行動が変わったかどうかはわかりません。プログラマがどれだけ労力を費やしたかは全く見ておらず、お客さんのことしか考えません。
AIがより問題を複雑にさせていること
AIで時間短縮できたとしても、ソフトウェア開発全体がどうか、ということを評価していく努力をしないといけません。
「AIを使えばジュニアプログラマは不要なのではないか」という論は、選択の問題です。
単純に若手を採用した際の工数ベースで見るのか、若手に成長してもらうという学びにフォーカスするのか、という選択なんです。
AIは、新しいことを学ぶ時にチューターのような役割をしてもらうと、わからないことはなんでも説明をしてくれます。若手にもっと学びのペースを上げてもらうために、AIを活用する方法を考えていくことが重要です。
まとめ
週に1回、プログラムがどのくらい早く動いているかをグラフにして見せれば、大抵のプログラマは喜ぶと思います。プルリク数の競争などでプレッシャーをかけるのではなく、プレッシャーを与えなくても自ら動くようになる仕組みを考えましょう。
測定・KPIはしてもいいですが、測定結果の数値をコントロールしようとしてプレッシャーをかけてはいけません。
人々が最高の状態で目標に進むことができることが重要です。
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ - Speaker Deck
事業やプロダクトの理想を定義していますか？
事業やプロダクトにおけるアーキテクチャの理想を定義していますか？
理想があることで目指す先と、理想と現在とのギャップがわかります。
Dress Code株式会社さんの発表では、会社が出来て3ヶ月で、どうして高速にプロダクトを開発できたのかを、アーキテクチャに着目してお話ししていました。
アーキテクチャは、高速な開発を可能にするための土台であり、全体の方向性と目的地を示すものです。
エンタープライズアーキテクチャは、組織のビジネス・データ・アプリケーションとそれらの関係性を整理する枠組みです。整理する上で、理想のゴールを見据えて、必要なものだけを選び抜くことが重要です。これは、DDDの「どこを目指すかを見極める」という考え方と通ずるため、結果的にDDDの実践が必要になります。
そして、プロダクト特性を考えた上で、アーキテクチャ特性を考えます。アーキテクチャ特性はトレードオフになるため優先順位付けをして考えていく必要があります。
設計に関する専門知識の話が多く、まだ理解できなかった部分も多かったのですが、会社の立ち上げ期ではこれだけのことを考えて方向性を定め、その上でもトレードオフを判断し続けないといけないということを学びました。
開発生産性を測る前にやるべきこと：組織改善の実践
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity - Speaker Deck
株式会社カオナビの富所さんの発表でした。
個人的に富所さんの Podcast を聞いたことがあったので、スポンサーブースでご挨拶ができたのが嬉しかったです。
内容としては会社の組織改善の流れと、これまでの取り組みについてのお話でした。
マルチテナントのSaaSアプリを、顧客ごとに機能カスタマイズをしていたことで、100社のクライアントに対し100個のアプリがあるような状態だったところへ、急成長したことで急ぎ対応すべき課題が表面化しました。
元々は企画・開発・QAなどがチームに分かれている職能別組織だったことで、職能ごとにサイロ化しており、プロトタイプの開発など小回りの効いた動き方ができない状態でした。
これを、職能別のチーム分けではなくミッションごとのチーム分けにしたことで、今のところ良い結果となっており、スタッフも楽しく開発ができるようになりました。
しかし、今度はチームがサイロ化してしまったため、社内のチーム間のコミュニケーションを促すさまざまな取り組みについて紹介されました。チーム開発になったからといってそれは銀の弾丸ではなくて、発生する様々な問題に私たちは取り組んでいかないといけません。
生産性を上げるのではなく生産性を下げないという点に着目し、派手なことはせず、1つずつカイゼンを積み重ねた結果であり、取り組みを続けていると従業員にも「うちの会社はこういうことを改善する気持ちがあるんだ」と伝わっていくということでした。
この発表を聞いて、一気に解決しようとせず、諦めず、目の前の問題に向き合い少しずつ改善のための行動を積み重ねていくことが重要だと感じました。
また、「リモートであまり会話しない状態が、出社したからといってうまくいくと思うなよ」という言葉がフルリモートの自分には刺さりました！
診断AIエージェント「Takumi」の雇用によって実現する開発生産性の向上
GMO Flatt Security株式会社の米内さんの発表でした。
米内さんも今月スタッフとして携わる TechRAMEN 2025 Conference のキーノートの発表をしていただく関係で、事前にお会いしてご挨拶できて個人的に嬉しかったです。
発表内容としては、自社のプロダクトである Takumi の紹介をしながらも、AIコーディングとレビューに関する課題についてのお話がメインで話されていました。
Vibe Cordingとセキュリティについて
登壇中にも紹介されていましたが、こちらの記事で詳しく言及されています。
前提として、AI生成コードは安全ではないと断言するとか、セキュリティの脆弱性が発生するかしないかの白黒の話ではなく、起こりやすさの話であるということです。
現状は、AIの書いたコードではそれなりに脆弱性が発生する、とは考えておく必要があり、人間が気にしてレビューしないといけません。
AIが出したコードのレビューをすることは、人間を相手にするよりも疲れることがあり、これをAI疲れと呼んでいます。AIコーディングにおいて脆弱性が発生するのは、AIの高速なコーディングに対し人間が耐えられる速度を超えた時に、疲れて「このままでも大丈夫だろ」とApproveしてしまうことなどで起こるのではないかと考えられます。
補足として、これはAIだからということでなく、人間も脆弱性を含むコードを書いてしまうことはあります。また、限界速度を超えることも、AIコーディングでなくても、リリース前の忙しい時など切羽詰まっている時はリスク増大につながります。
そのため、「AIは安全でないから使わない」ではなく、AIコーディングで得られるメリットは活用しながら、負荷を超えた速さになっていないか注意し、脆弱性リスクが起こらないよう対策をすることが重要です。
AIによるセキュリティレビューについて
セキュリティ診断AIエージェント Takumi と、一般的なAIエージェントによる診断結果を比較しながらTakumiの性能について紹介されていました。
AIエージェントによるセキュリティレビューの課題に以下のことが挙げられます。
- 検知するがそこまで脅威ではないことを報告すべきとして取り上げてしまうため、お客様に伝える情報の判別は人間でする必要がある
- AIを使用しても結局最後の責任は人間に集約されている
これらの課題は、AIコーディングレビュー全般に言える壁であり、努力して打開していかないといけない点だということでした。
私は、AIコーディングについて、そこまで情報が追いきれておらず実践できていなかったのですが、現状AIコーディングとセキュリティに関する課題があることを知れたことがとても勉強になりました。
エンジニアが主体的にビジネスに貢献する〜開発現場からの変革
このカンファレンスを運営するファインディ株式会社の代表の山田さんと、株式会社一休の伊藤 直也さんによる、対談形式のスペシャルセッションでした。
本当に良い話でした。
生産性とは
本来すべきことは、「お客さんの問題を品質高く解決できているのか」というなので、「生産性」という言葉に対して狭い意味を考えすぎたり、そこだけに注力しない方が良いです。
また、「生産性」と言うと工場で同じものを製造し続けるような意味合いが感じられますが、ソフトウェア開発は同じものを大量生産するわけではないし、欲しいものがわかっていて作るわけでもありません。そこに言葉のニュアンスのずれを感じます。
お客様の課題が解決して満足してもらえた時、その時の生産性や効率はどうだったか、ということはお客様からはそこまで気にされないことが多いため、「お客様の問題をどれだけ解決できるか」に注力すると良いと思うとのことでした。
エンジニアがビジネスに貢献するためには
株式会社一休では、顧客の解像度を上げるために、しょっちゅうソフトウェアエンジニアがお客様の元に出向いて、会って話しています。
前提として、エンジニアがビジネスに貢献するということは、お客様の課題から出発する考え方であるべきです。ビジネスの視点というと、企画を立てるとかKPIを伸ばすことに目が向きがちですが、これは自分の視点から出発していて、課題から出発した考え方ではないからです。
お客様の元へ訪問すると、多くのことがわかります。机上で考えていただけでは、実際の要件とずれてしまうなど危なかっただろうなと思うほどです。
お客様から話を聞く上では、機能のレイヤーではなく問題解決のレイヤーで考える必要があります。なぜなら、「どういう問題を抱えていて、どういうことを解決したいのか」という部分が重要だからです。ある機能を追加したからといって、根本となる問題が解決するとは限らないためです。
お客様から追加して欲しい機能の要望を聞いた時、お客様に接するのが営業職だけで、又聞きしかしていないとこういったコンテキストが抜け落ちてしまいます。
例えば、レストランでは当日の予約は紙で運用されていた時、エンジニアは一生懸命その紙の運用フローをデジタル化しようとしがちです。そして、開発したものが導入されて、思うようにお客様に使用してもらえない時、「デジタルに慣れていないから使いにくいんだ、使いやすいように直そう」と考えがちです。お客様が本当に望んでいたのは、前日までの予約管理はデジタルで行い当日は紙で運用することで、本当に必要だった機能は、当日の状況を出力・プリントする機能でした。
現場訪問をして現場の運用を確認した上で、どこをシステム化するのが効果的かをお客様と一緒に考えていく必要があります。
こういったことを無視して、プルリクをどれだけ早く何個出しましたとかそういうものでは測れません。生産性が高いのに・開発は上手くやれているように感じるのに、なぜかお客様に刺さっていないことの方が問題です。本来の意味でお客さんにとって品質の高いものを作らなければいけません。
ビジネスに貢献するためのエンジニア組織とは
株式会社一休では、最近は役割分担を明確にしなくなってきています。マネジメント側がサイクルを動かすのではなく、主従関係を逆にして、エンジニアスタッフがサイクルを回しマネジメント側はそれをサポートするような形になっています。
ただ、このような状態になるまでは時間がかかりました。エンジニア自身に、何をどう作るかをちゃんと考えて欲しかったですが、ディレクターが頑張れば頑張るほど、エンジニアの自発性がなくなっていきました。なので、ディレクターがマイクロマネジメントしないように構造を変えていかないといけないと思います。
さいごに
今日の話を聞いたからといって、いきなりスタッフにお客さんのところに行けと言ったり、焦って一気に進めようとすると、みんなついていけなくて失敗します。
地に足をつけて、少しずつ始めて、続けていくことが大事です。一足飛びに転換しようとしないで、ちょっとずつやってたら気づいたらすごく進んでました、という心づもりがいいです。
AI時代のソフトウェア開発を考える
AI時代のソフトウェア開発を考える（2025/07版） / Agentic Software Engineering Findy 2025-07 Edition - Speaker Deck
t_wadaさんのキーノートです。
Vibe Cordingの登場
今年、Vibe Cordingが登場し、プログラミングの速度（物理生産性）が圧倒的に高速化しました。さらにClaude Codeが従量課金ではなく定額制になったのも大きな影響でした。
高速化したことで起こったことは、技術的負債の積み上げなどの速さも加速し、これまでは開発段階の後の方で起こるはずだった問題がすごく早く発生するようになりました。
しかし、これは新たに発生した問題ではなく、これまでも問題とされていたことの顕在化が早まっただけと言えます。また、大規模な企業（プロダクト）だから起こる問題だと思っていたことが、AIで成長速度等も高速化することにより大企業でなくても自分ごととして関わる問題になってきました。
我々は何を学んだか
問題の構造自体はこれまでと変わらないので、AI登場以前から我々が学んできたことを振り返りましょう。TDD、DDD、リソース効率とフロー効率、ビルドトラップを避ける方法、などが例に挙げられます。（資料参照）
ビルドトラップとは、顧客やビジネスの成果ではなく、とにかく早く沢山機能をリリースすることが目的化してしまう状態を指します。AIによるコーディングも基本的に足し算思考であり、この状態に陥りやすいです。
アウトプット（どれだけ作ったか）ではなく、アウトカム（成果）とインパクト（与えた影響）を重視しましょう。アウトカムに繋がらないアウトプットはいくら増やしても意味がありません。
目指すべきはAIとソフトウェアエンジニアリングの融合
AIを使う際は、「伴走」と「委託」の2つのモードがあります。
伴走とは、Copilotやチャットボットのような、AIと対話しながら開発することです。この方法は、人が必ず介在するためコントロールしやすい反面、スピードは出しにくいです。
委託とは、自走するAIに任せて、その間人間は並列して別の開発ができる状態のことです。夜のうちに小人さんが仕事を終わらせておいてくれるようなイメージです。この方法は、スピードは圧倒的に早い反面、人が介在しないためコードレビューが課題となります。
この2つのモードを適切に使い分ける必要があります。現状は、中核となるところは「伴走」で、そうでないところは「委託」で開発すると効果的です。
自動化から自働化へ
AIは自走しますが、暴走・迷走もします。ミニ四駆のように、コースが設計されていればうまく走りますが、コースがうまく設計できていないとどこに走っていくか分からず、人間がついていけなくなります。
Agentic Cordingでは、望ましい状態を定義して、出力に対して評価を与えることを繰り返すことで、エージェントは望ましい状態に収束するように自律的に働くようになります。このように単純な「自動化」ではなく、人偏のつく「自働化」の重要性が高まっています。
そのため、人間側が「良いコードとは何か」といったことを定量化して伝えられることが大事になってきています。
そして、AIコーディングは、自分の把握していない範囲のコードが増えてそれが定常状態になっており、「確信」の度合いが減っていきます。業界全体として、バグがゼロでないといけないというような、リスク信仰の考え方からは離れていかないといけません。
正直に現実を見つめよう
一番最初に考えた設計が正しかったことはありませんよね？我々は、基本的に正しい設計はできず、コードを書き始めてからわかってくるものです。
しかし、我々が自分の手でコードを書かなくなってくるとすると、これまで「手を動かしてコードを書くからこそ、そのフィードバックとして得られていた気付き」にいつ気づくんでしょうか。
そして、正しい設計だと思っていたことも時間が経つと正しくなくなります。設計に終わりはなく、意思決定の連続です。
AIはあくまで増幅器であり、無から有を生み出すものではありません。したがって人間側が能力を上げつつ、労力を減らしていくように活用していく必要があります。そもそも、能力を上げないで物事をなんとかする方法はそんなにありません。
そのため、自分たちの能力を上げるためにもAIを使いましょう。これは、初学者の学習において特に役立っています。
1. 何回同じことを聞いても怒られず即時フィードバックを得られる
— Takuto Wada (@t_wada) 2025年1月16日
2. フワッとした曖昧な質問から専門用語（≒検索キーワード）に辿り着ける
この2点は（特に初心者の）ソフトウェアエンジニアの教育あるいは独学においてChatGPT等の対話型生成AIが果たした画期的な進化だと考えています。
変化を抱擁せよ
最近よく、「AIが登場したから人間はコーディングをやめるべきなんだろうか」「採用の際に新人の代わりにAIで良いのではないか」などの問いが立てられていますが、これは問いの立て方から間違っています。
「何をすべきか否か」という問いの立て方は、大抵間違っていることが多いです。極端な2択になってしまっている時点で、視野が狭まっているからです。人間はものすごいものを見ると視野が狭くなりこのような状況に陥りがちなので注意が必要です。
我々は今、生成AIの輝きに目が焼かれており、バイアスがかかっています。現在のような不確実な状況では、選択肢を狭めるべきではありません。もっと引いて全体を見て、「AIに賭ける」ではなく「両にらみ」を続け、可能性を並べた状態で評価し続けていくべきです。そしてこのAIによる変化を楽しんでいくと良いです。
セッション以外に経験したこと
- ケント・ベックさんのサイン会に参加し、握手と一緒に写真も撮ってもらった
- t_wadaさんにもサインをいただけた
- Day1でRubyistの方々と沢山お話しできた
- オンラインで交流のあった方と初めてオフラインで会えた
- スクールの同期も参加していて会えた
思ったこと
AIとの付き合い方
カンファレンス全体を通して、AIとの付き合い方について話しているセッションが多かったです。
プログラマ2年目で、AIがあれば新人不要説に少し不安を感じていた自分にとっては、キーノートの方々が特にそれを覆してくださるお話だったため、少しほっとしました。
AIそのものが何か問題なのではなく、リファクタリング・セキュリティ面など元々存在していた問題を顕在化・高速化させることに対して、向き合っていく方法を考えないといけないと思いました。
また、t_wadaさんのキーノートでも歴史は繰り返されるという旨を話されていました。AIに関わらず、これからも何らかの新しい技術は出てくると思います。インパクトの大きさにかかわらず、振り回されることなく、使い方を学んで、より良い方法を考えるほかないと思いました。新しい技術を学び続けていく姿勢を忘れないようにしようと思います。
開発生産性とは何か
開発生産性カンファレンスという名前なのに、その言葉の意味を根底から問い直すような、キーノート、スペシャルセッションが多くありました。
参加するまでは、開発生産性は高い方が良いんだろう、というふんわりした考えしか持っていませんでした。しかし、スタートから、ケント・ベックさんの登壇で「指標を追い求めすぎると、目的がすり替わり、思ってもいない悪い方向に進んでしまう」という話を聞いて、開発生産性という言葉の使い方について考えさせられました。
プログラマーの仕事はアウトカムとインパクトを出していく必要があり、クリエイティビティも重要であり、それは単純な指標では測れないということがわかりました。
自分のパフォーマンスを上げられるよう努力することは重要ですが、指標にとらわれすぎず、本当に達成すべきことを見失わずに向かっていけるプログラマーでありたいと思いました。
環境の変化と目の前のことに1つずつ向き合うこと
GMO Flatt Security株式会社の米内さんの話では、AIによるコードレビュー疲れや、人間のついていけないスピードを超えないについて話されていました。
飛躍かもしれませんが、AIに関わらず、自分のついていけないスピードを超える変化があった時は、リスクが生じたり、向き合い方を考えないといけないタイミングだということは、同じだと感じました。
例えば、転職や、コミュニティへの参加など、人間関係や環境が大きく・早いスピードで変わっていく時も、追いつけなくなりそうな感覚が生じたり、自分なりの付き合い方や乗り越え方を考えないといけないと思います。
それがAIだと、影響範囲が広いので途端に話が大きくなったり、不安を煽られたりしますが、個人で向き合うレベルでは「環境の変化」という点で似ているように感じました。
伊藤 直也さんのお話、富所さんのお話からは、「これがあれば全てを解決するベストプラクティスなんてない、少しずつ1つずつ向き合ってより良くしていく」というメッセージを感じました。
カンファレンスを通して、AIとの付き合い方、さまざまな課題への取り組み方、といった視点から、プログラマとしてこれからどう過ごしていくかを考えさせられる経験となりました。
さまざまな変化がある中で、大切なことを見失わずに、目の前のことに1つ1つしっかりと向き合っていきたいです。
さいごに
このような貴重な機会を作ってくださったカンファレンス運営の方、平日の開催に関わらず参加させてくれた会社へ感謝します。ありがとうございました！
今回の学びを忘れずにこれから過ごしていきます！
