開発生産性Conference2024

開発生産性を可視化するツールを多数提供している
Findy株式会社主催のカンファレンスに参加しました。

テスラ、Redwood Materialsにみるビジネスグロースに貢献するエンジニア組織とは

Tesla共同創業者のJ.B. StraubelさんによるKeyNote。
このCTOの元で働きたいと思える素晴らしい内容でしたが
（マスクさんの元では相当タフでないと働けないですが）
記事化NGとのことで、残念ながら共有は控えさせていただきます。

マイクロサービスの現場からプラットフォームエンジニアリングの可能性を探る

株式会社スリーシェイクさんの講演。
よく耳にする「プラットフォームエンジニアリング」とは何ぞやというところから
具体例もお伺いすることができました。

プラットフォームエンジニアリングとは

事業インパクトにつながる生産性=アウトカムを増やす、
デリバリの速度・頻度を改善
→PDCA高速に、試行する回数を増やす必要がある一方、
開発者の認知負荷が増している。

→開発者の認知負荷を削減するための基盤を提供することが
プラットフォームエンジニアリング

マイクロサービスのデメリット

各プロダクトチームで車輪の再発明
→共有されない知見
→組織全体での生産性が低い
ポリレポ
→レビューの負荷高い
→K8sの設定ファイル、レビュー内容は大体同じ

プラットフォームエンジニアリング担当の役割

各チームのステークホルダーと横断的にコミュニケーションして基盤を提供
CICDを止めないためのプラクティスを実践
- 異なるAZにPod分散
- Nodeオートスケーリング
- Balloon Podテクニック
  などなど

感想

昔からある「基盤チーム」と何が違うのか初めは疑問でしたが、実例を拝聴し
自らコミュニケーションの主体となってヒアリングを行うことや、
自らもプラットフォームを使ってみて、PDCAの一員となることなど、
技術スキルだけでなくソフトスキルも必要とされる役割であることが理解できました。

開発組織の生産性を加速させる: 継続的価値提供を実現する文化と仕組み

日頃お世話になっているQiitaさんの企業文化をお伺いすることができました。

仮説検証型アジャイル開発

開発者自らユーザインタビュー
小さい開発を意識する
雑に作るのではなく、小さく作る

実際に仮説をたて、プロトタイプで検証を行った結果
効果が少ないことわかり、開発に至らなかった例を示していただきました。

「AIによる内容修正が記事執筆体験向上につながる？」
↓
「記事執筆体験向上とは？」価値の定義
記事執筆スピードが上がる
記事の内容の品質が上がる
↓
仮説を立てる
AIが記事を修正してくれたら見直す手間が減って
記事執筆スピード・質が上がるのでは？
↓
プロトタイプで仮説の検証
↓
「自分で記事を見直す人は、AIが修正した内容をさらに見直すので
余計な作業が増えるだけ」であることがわかった

ただし単純なスペルミスの指摘など一部分は効果があったため、最近リリースされた
文章校正機能の開発につながったとのこと。

定着させる取り組み

高い生産性をみんなで目指す、全員が手触り感を持つまでやる

取り組んでいることを言語化
成果内容は定性でもOK
価値基準を定義する
目標をみんなで考える

高い開発生産性を維持

振り返り
やれている感
スプリントレビュー
レトロは労いから
レトロだんだん形骸化するため「むきなおり」を行う
- 数スプリントごとにチームの意思の掘り起こし
- これからどうするか価値あるもののアップデート
- アクションの形骸化を防ぐ

感想

開発者自らユーザインタビュー、仮説検証を行う取り組みは
「価値があるか不明な機能を開発し結局使われない」を防ぐ効果がありそうです。
またレトロは毎週行っていますが
「むきなおり」は実施したことがなかったので、ぜひ取り入れてみたいです。　

価値創造と開発生産性

株式会社アトラクタFounder兼CTO / アジャイルコーチで
多数の書籍の和訳も手掛けている吉羽龍太郎さんの
パワーワード満載のセッション。

「ゲームに勝つのはフィールドに集中する選手であって、スコアボードに釘付けになっている選手ではない」
→エンジニアがフィールドに集中できるようにするのがEMの仕事

開発者とマネージャは生産的であることの意味に対する考え方が一致していない

物的生産性(効率)
付加価値生産性(効果)

開発「者」生産性？Developper Productivity指標も複数ある

Four keys：デリバリーに焦点
SPACEフレームワーク：開発者の生産性、アウトカムに焦点
- 実際包括的に測定し定量化することはほとんど不可能
- パフォーマンスを定量化するのは困難
Yes,you can measure software developer productivity
- 個人的にはお勧めしない

指標の単純比較について

ゴミを高速に開発するチームと
価値あるものを普通の速度で作るチーム
で比較するのは無意味

価値創造の方が大事

価値を定義して全員に何度でも伝える
価値が提供できていることを示す指標を考える
ゴールを定める
- ある期間内で何にフォーカスすべきか
- 達成できたかは頻繁に検査
- 達成したら次に取り組む

まずは「効果」その後に「効率」

不要な機能はガンガン消せ
ユーザインタビューや設計などはコードをあまり書かなくても「価値あるプロダクトを提供する」本質に集中しているので、数値が出なくても問題ない

感想

物的生産性(効率)の数字だけを追うのは意味がなく、付加価値生産性(効果)を定義して全員で共有することが必要であることを理解しました。
また、ツイートされている方がいましたが、価値あるプロダクトを提供するという意味では「削除したコード、機能の数」は参考になるかもしれません。

企業ブース

ゴリラのぬいぐるみが可愛いKong株式会社さんは
セッションの合間にミニプレゼンを行なっていました。

メンバー全員がAIを安全かつ効率的に使用するためのGatewayサービスとのことで
同一プロンプトに対してはキャッシュを使うなど、費用削減に効果がありそうです。

まとめ

可視化できる便利なツールが増え、数値にとらわれがちになりますが
まずは「届けたい価値が何であるか」を定義し、
メンバーと共有していくことが何より重要！ということが理解できました。