エンジニア組織を強くする「開発生産性の教科書」を読了した
生産性向上の取り込みは、副業先で多く学べたことから「開発生産性」というタイトルに惹かれて本書を購入した。
著者の方はFindy 在籍の方でもあるので、Findy Team + がメインにはなるものの他の会社事例といった部分で、どのような取り組みをしたかといった部分は非常に参考になった。
事例紹介を交えつつ、エンジニア組織の開発生産性をあげていくための教科書になります。
開発生産性の定義
まずはじめに開発生産性の定義についてから始まる。
開発生産性が指す範囲は広い。
生産性とは、得られた成果物 ÷ 投入した生産要素（インプット）で表す。
何を投入して、何を成果物にするのかの定義となる。
開発生産性と連想とすると、効率・早くリリースする部分やコミュニケーションのコスト軽減など様々だ。
どこに重きをおくかはチームによって変わるため範囲が広いと考えた。
アウトプットとインプットの定義をどこにするのか。 それを考えチームとして決めていく必要がある。
自分たちの組織やチームにとって何がアウトプットでありインプットなのか。そして何を開発生産と呼ぶのか。定義は曖昧であるため結論自体はチーム内し組織で決めていく必要がある。
とくにCTO室だったりチームの中でのミーティングを設けていくべきだと感じた。
分類ごとに開発生産性のレベルを分ける
ツールの最適化
自分自身のスキル向上
チームワーク強化
品質保持
プロセス管理
継続的な学習と知識共有
本書ではレベルごとに分類して取り組み例が書かれている。
私が思うにレベルが大きくなるにつれコンテキストが大きくなるようなイメージを持っている。
小さくはじめて徐々に大きくしていく形をイメージしていく。
小さく始めることで振り返りがしやすく軌道修正がしやすいからだ。
大きな目標を掲げて、進めるのではなく小さくFBをもらいつつ進めていくことがチームにとって正しいやり方です。
また、過剰に追求をしないことも書かれている。
これらの問題として、オーバーワークといった面が挙げれる。
過剰にこだわり新しい技術を追求することで、学習負荷が大きくなることは生産性に繋がらない。
一つずつ潰し学習して前に進むことを意識したい。
DevOps の歴史と開発生産性
本書ではDevOpsの歴史をPupper Labs の調査から時系列で書かれていた。
2023年の調査で、生成AIを駆使してチームのパフォーマンス向上を上げていくのが大きかった年。
「生成的な文化」という言葉が生まれた年だった。
エンジニアとして、生成AIを使い始めて感じたことを言葉として学べた。
プログラムを書くプロセス自体が大きく変わったことは身を持って感じている。
Four Keysとは？
DevOps や開発生産性といった分野では、「Four Keys」という言葉が出てくる。
Four Keysとは、GoogleのDORA（DevOps Research and Assesment）チームが、DevOps やソフトウェアの効率と効果を評価を4つの主要な指標として提唱した。
DORAの研究によって特定された4つの指標のことを「Four Keys」と呼ぶ。
デプロイ頻度
ソフトウェアの新しいバージョンをリリースする頻度
変更のリードタイム
コード変更されてから本番環境へデプロイされるまでの時間
変更失敗率
デプロイ後に問題が発生してロールバックした割合
サービス回復時間
インシデント・障害が発生した際に復旧までの時間
エンジニアのチームで取り組みやすい指標としてはデプロイ頻度らしい。
色々な企業をみてもデプロイ頻度についてかなり取り組まれている企業は多いと感じていた。
毎週リリースしています。などなど。かなりスパンは早いという感じ。
その背景としてDXが加速している影響しているのではないだろうか。
SPACEといった発者の生産性を計測するためのフレームワークもあるようだ。
生産性に影響を与える5つの要素
Satisfaction and well-being（従業員満足と幸福）
Performance（パフォーマンス）
Activity（アクティビティ）
Communication and collaboration（コミュニケーションとコラボレーション）
Efficiency and flow（効率性とフロー）
Four Keys 以外にもフレームワークはあるようだ。このあたりは知識としてもっておきたい。
なぜ指標が必要なのか？
指標で何を計測したいのかもチーム内の対話が必要になってくる。
なぜ？我々はこのフレームワークを使うのか。それをチーム内の認識として固定する必要がある。
なぜ指標が必要なのか。例えば自分だと以下が考えてた。
ビルドまで一連の流れのなかで、どこがボトルネックになっているのか。
これらを人の物差しで図るのではなく、リードタイムといった部分を数値化して判断しやすくするためです。
なぜレビューの時間がかかったのか。そこを起点にレビュイーの実装の問題だったのか・単純にレビュワーの見る時間がなかったのか。
状況は様々だ。
これらを図りつつ、なぜ？おきたのか。ではどのように改善するのがよいか議論するテーブルに一つの指標があると会話が進みやすいと感じた。
デプロイ時間だったり、テスト実行時間・テストの漏れ等、ケースは様々あるがこれらを可視化しておくと良いということだろう。人は言葉よりも見たものとして話したほうがイメージや会話が成立しやすいのは長くプロジェクトに在籍していたからわかる。
参考
なぜ指標が必要なのか？
指標で何を計測したいのかもチーム内の対話が必要になってくる。
なぜ？我々はこのフレームワークを使うのか。それをチーム内の認識として固定する必要がある。
なぜ指標が必要なのか。例えば自分だと以下が考えてた。
ビルドまで一連の流れのなかで、どこがボトルネックになっているのか。
これらを人の物差しで図るのではなく、リードタイムといった部分を数値化して判断しやすくするためです。
なぜレビューの時間がかかったのか。そこを起点にレビュイーの実装の問題だったのか・単純にレビュワーの見る時間がなかったのか。
状況は様々だ。
これらを図りつつ、なぜ？おきたのか。ではどのように改善するのがよいか議論するテーブルに一つの指標があると会話が進みやすいと感じた。
デプロイ時間だったり、テスト実行時間・テストの漏れ等、ケースは様々あるがこれらを可視化しておくと良いということだろう。人は言葉よりも見たものとして話したほうがイメージや会話が成立しやすいのは長くプロジェクトに在籍していたからわかる。
GitHub Schedule reminder を活用する
BuySell Thechnologiesの事例ではプルリクエストの通知改善といったものがあがってた。
これは自分も課題と感じてた部分だった。
プルリクエストの統一・Slack通知の改善にreminderを活用するといった取り組みが書かれてた。
GitHub Schedule reminder を使っていきたいと感じた。
まとめ
ほかにもLLMの活用方法なども本書の最後にかかれている。
開発生産性を意識したいのではあれば、一度事例なども含めて読んでおくと知見が貯まると感じた本だった。
開発生産性は日々アップデートされていく部分ではあるので、ツール部分は進化するが考え方やマインドは常に変わらないのではないだろうかと感じた。
この記事が気に入ったらサポートをしてみませんか？