開発生産性カンファレンス2025の感想(2日目)


開発生産性カンファレンス2025 に参加してきました。ここでは2日目のセッションの感想を書きます。

開発生産性向上の探求:DevOpsの進化、普遍的な原則、そして生成AIがもたらす変革

スピーカー:

  • Gene Kim

スライド: 最後にメール送ってくれれば資料送るって紹介されてたけど、それを写真に撮る前に消えちゃった。悔しい

ジーン・キム氏は LeanとDevOpsの科学 の著者の1人だ。 DevOps界隈の第一人者と言っても過言ではないだろう。

まずFour Keysをベースにしたエリートとローパフォーマーの比較表を話していた。 まぁこれはLeanとDevOpsの科学を読めばよし。

次に3つの魔法(だったかな?)の話を始めた。 紐解くと何ら新しいことは言っていないけど、覚えておくべきこと。

  • スロー化
  • 単純化
  • 増幅

という3つのキーワードを紹介していた。

スロー化:

大規模な障害を避けるために訓練をしたり一時的にシステムを止めたりすること。 例として、Netflixのカオスエンジニアリングが挙げられていた。 一部のDBインスタンスをわざと止めてみてどうなるのかを観測し、どうやって復旧させるかを本番環境で試すというもの。 カオスエンジニアリング を読んでみるしか。

単純化:

Amazonはかつて受注担当のチームが80ぐらいあったらしい? そこでデジタルな商品を販売しようとしたが、配送先住所を入力するフォームはデジタルだと要らないので省こうとした。 しかし、各チームに要件を伝えると「そんなことをやっている時間はない」と言われてしまい、進まなかったとか。 今では、各モジュールが単純化されて独立したチーム・プロセスで開発が動いているので、上記のことは起こらない。

例え話として、ソファを運ぶ・作るというタスクの話をしていた。 大量の開発者が1つのソファを一緒に運んだり作ったりすると、意思疎通がうまくいかない。 複数のソファ(椅子)に分割して、それぞれのソファを適切な人数のチームで、独立して開発・保守するとうまくいく。

増幅:

増幅という言葉からは分かりにくいが、情報の透明性とか心理的安全性とかの話。 小さなエラーなどの兆候や小さな違和感なども、透明性や心理的安全性が高ければ適切にエスカレーションされる(シグナルが増幅される)ということ。

最後に、AIによる話。 Vibe Codingという本を秋に出すらしい。

バイブコーディングの価値:

  • F: 欲しいものをもっと迅速に構築する
  • A: 自分で構築できるものについてもっと高い目標を設定する
  • A:(他のメンバーやチームを必要とするのではなく)一人で構築できるようにする
  • F: もっと楽しく作業する
  • O: もっと挑戦し、より多くの選択肢を検討する

というのを紹介していた。

スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略

スピーカー:

  • 株式会社スリーシェイク
  • 株式会社enechain

10人ぐらいだった開発部門が、70人ぐらいまでに拡大するとともにどのように組織を分割していったかというような話。 早めにそれぞれのプロダクトで利用する共通プラットフォームを構築するチームを作ったおかげで、各プロダクトがバラバラに技術スタックを積み上げてしまうという状況を回避できた、というようなことを言っていて、参考になりそうだった。

ただ、そもそもの話だが「プラットフォームエンジニアリング」はプロダクトのアプリケーションプラットフォームの話じゃないと思うのだが。。 聞き逃しただけかも?

ビズリーチが挑む、メトリクスを活用した技術的負債の解消

スピーカー:

  • 株式会社ビズリーチ

ビズリーチは15年ぐらい続くサービスなので、さまざまな技術的負債が溜まっている。技術的負債はさまざまな良くない影響を及ぼすので、色々と対策を行っている。

  • リアーキテクティング
  • ボトルネックを解消するプロセス改善
  • AIの活用
  • SODA

途中で聞くのを止めた。

理由は、このセッションはメトリクスを見てリアーキする箇所の選定とかデータドリブンな意思決定とかそういう話かと思っていた。 蓋を開けてみると、リアーキした結果デプロイ頻度が上がったとか、ビフォーアフターを計測しましたという話だった。

開発生産性を測る前にやるべきこと:組織改善の実践

スピーカー:

  • 株式会社カオナビ

オアシス ADR 全社スプリントレビュー フィーチャートグル パッケージバイフィーチャー(モジュラーモノリス)

ビズリーチから移動してきて途中から聞いた。かなり面白そうな話をしている感じだったので、後で資料が公開されたら補完したい。

コードのその先へ:開発者体験を活性化させる方法

スピーカー:

  • Netflix

生産性を測る指標・数値としてコード行数とか分かりやすい数字を採用するのは良くない。 例えるなら、本の良し悪しをページ数が多い少ないで判断するようなもの。

評価する基準によって、行動が決まる。(グッドハートの法則みたいな感じかな)

スピードを測る指標:

  • PRマージ数
  • コード行数
  • チケットのストーリーポイント

これらは持続しない。

心理的安全性とか、コミュニケーションとかを重視してる感じがした。

一つ途中で紹介されていたエピソードが面白かった。 アンドリューカーネギーという人の会社で、新人幹部が100万ドルのプロジェクトを台無しにしてしまったそうだ。その幹部は、社長のカーネギーにクビかどうかを尋ねると、社長は「クビだって?君の訓練に100万ドルをかけたばかりだぞ」と答えた、というエピソード。 これは非常に素晴らしいエピソードだと思う。ここまで心理的安全性が高い組織はそうそうない。

なぜ「無責任な横軸」がうまくいかないのか〜組織の生産性にインパクトを与える振る舞いを考える

スピーカー:

  • KINTOテクノロジーズ株式会社

スライド: https://speakerdeck.com/ahomu/naze-wu-ze-ren-naheng-zhou-gaumakuikanainoka-zu-zhi-nosheng-chan-xing-niinpakutowoyu-eruzhen-ruwu-iwokao-eru-6ad0a515-e895-4ed1-8740-1088e0d05ae2

「無責任な横軸」というのは、抽象テーマだったり全社標準だったりカルチャーだったりと、位置付けが曖昧で責任や影響力が薄いような横軸のこと。 横軸がうまくいかないのは、関係者を “その気” にさせることが難しいから。

ついやってしまいがちなアンチパターンとして以下があるそうだ。

  1. べき論を押し付ける
  2. 摩擦を避ける
  3. 受け身が常態化する

これらのアンチパターンに陥らないためのアドバイスが以下。

  1. “これまで” と “これから” をセットで話す
  2. 場を整えて異議をぶつけてもらう
  3. 種まきを諦めない

結局のところ、地道に根気よく諦めずに続けることが大切だなと思った。 自分もDevOps・継続的デリバリーの啓蒙を諦めないようにしようと思った。

感想

後半は寝不足と疲れであまり話を集中して聞くことができなかった。 資料公開されるものは後で見て、あと録画配信とかあると嬉しいんだけどなぁ。

全体としては、なんかとにかく「AIをどうする!?」みたいな話が多かったか。 AIの話は正直お腹いっぱいになりつつあるなぁ。 まだ過渡期感が凄いし、キャッチアップしなきゃという圧も感じるけど、ほとぼりが覚めて枯れてから学び直すでも遅くないような気もしなくもない。