エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～
#2024.08 #ReadLog
https://c.media-amazon.com/images/I/71KJPa3WPPL._SL1500_.jpg
Kindleのまとめ買いセールにて購入。
開発生産性とか開発者体験のようなものについて最近考えることが多かったので手に取った。
今まではすでにある程度基盤が整えられていた環境にいたし、自分が何もしなくても開発生産性について誰かが考えてくれて先回りしてもらっていることが多かったため、開発生産性高い方がいいよね〜みたいなざっくりした感想は抱きつつもしっかりと理解できていなかった。
さらに、いざ自分が開発生産性向上を推進していきたい！ロードマップ整えていきたい！！となったとき、どのようなメリットがあってどのような道筋で進めていけばいいのか？？何も分かってなかったことに気づいた。
読んで良かったポイントは、開発生産性の歴史や、その分野の研究からどのような効果やメリットがあるのかを説明してくれていたことと、開発生産性の定義やどのように可視化すれば良いかという基本のところから説明してくれていたこと。
開発生産性レベル3: 実現付加価値の生産性
特に他書籍を引用して開発生産性をレベル分けして、それらがどのような状態であるかを明確にしてくれたのは助かった。読んだことある書籍からの引用だったが完全に忘れていた。
自分がなぜ生産性を高めたいと思っていたのか。それはレベル3の「実現付加価値の生産性」のレベル・・・つまりプロダクトによる売上やKPIに貢献できるレベルでエンジニアリングを評価したいと思っているからだった。それが腹落ちしたのは非常に良かった。
広木大地氏の著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』注1.1では、開発生産性のレベルとして3つの階層が定義されています。
佐藤 将高,Findy Inc.. エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ (Kindle の位置No.300-302). Kindle 版.
レベル3：実現付加価値の生産性
このレベルは、売上やKPIなど、実際のサービスに対する具体的な貢献を評価する段階です。このレベルの生産性は、開発チームだけではなく、カスタマーサクセス、セールス、マーケティングなど、組織全体で評価に取り組んでいく必要があります。このレベルでは、「そのタスクが実際にビジネスの目標に貢献できているか」という観点で評価することになります。たとえば以下のような観点が挙げられます。プロダクトにより、売上がどれだけ変化したかプロダクトにより、KPIをどれだけ達成できたかなど
佐藤 将高,Findy Inc.. エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ (Kindle の位置No.315-321). Kindle 版.
『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』は通読したことがあって、不確実性との向き合い方という面で多大な影響を受けたのだけど、開発生産性に関する言及は完全に見落としていた。反省。
文化への影響
個人的になんとなく感じていたことだったが、高いパフォーマンスを示す組織の文化的特徴への言及は興味深いと思った。私が好きだなと思う組織の文化は、高いパフォーマンスを示す組織の特徴と一致する。高いパフォーマンスを発揮しようと思うと自然とこのような文化になるのだとすると、それも含めて無意識的に開発生産性に着目していたのかも。
DORAの調査では、高いパフォーマンスを示す組織には表4.6のような文化的特徴があることが明らかになっています。こ
佐藤 将高,Findy Inc.. エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ (p.161). Kindle 版.
https://gyazo.com/50d32e016dd55024f7eeeefa0bfff25f
後半は特定のプロダクトに関する言及が増えるのだけど、その導入事例も含めて読んで良かったなと思えた。
Four Keys 開発生産性の指標のひとつ
DevOps Research and Assessment（DORA）チームが策定したソフトウェア開発チームのパフォーマンスを示す 4 つの指標。開発生産性を計測する指標として、本文中でたびたび出てくる。
エリート DevOps チームであることを Four Keys プロジェクトで確認するの記事にもある。Four Keysの指標を示すことで開発生産性を可視化することができるのは良いことだし、モチベーションにもなりそう。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
一方で、これらは指標が大きすぎてチームからドリルダウンして個人の開発生産性の指標にしづらいという課題があるとのこと。
Four Keys以外の指標
プルリクエスト作成数
⭕️目標を設定しやすい
⭕️手動でも計測しやい
🔺レビューなどとも関連するのでチームで足並みを揃える必要あり
自動テストのコードカバレッジ
⭕️テストが存在しない既存コードに対してもテストを書くモチベーションになる
🔺どの程度の目標値にするかを決めるのが難しいことも
🔺テストカバレッジ自体が目標になると本質的ではなくなる
マージ時間
プルリクエストがオープンされてからマージされるまでの時間
⭕計測が比較的容易
🔺プルリクエストの粒度や複雑度にも依存するためある程度足並みを揃えた方が良い
🔺プルリクエストを作成するタイミングなどもチームで足並みを揃える必要がありそう
自動テスト・CI/CDの実行速度
⭕️計測が比較的容易、改善しやすい