最初にまとめ
こちらの本は個人のエンジニアの生産性向上に焦点を当てた本ではなく、チーム、組織として生産性向上を上げていくにはどうするとよいかを書かれた本です。
全体的に自社開発とアジャイル開発の組織向けの内容に感じました。
ですがエンジニア個人としてもやれることも多かったのでスモールスタートでできることから始めて行くのが良さそうです。
第1章 開発生産性とは何か
生産性向上について取り組む前にプロダクトのゴールを明確化する
プロダクトから得られる売上や利益が重要
プロダクトを使ってもらう事で達成されるKPIが重要
KPI（Key Performance Indicator）とは、業績を評価し管理するための定量的な指標です。KPIを用いて、目標達成に至る各プロセスでの達成度合を計測、監視することで、組織のパフォーマンス状況が確認できます。またKPIで目標達成に対するギャップを明らかにすれば、取り組むべき施策が明確になり、効率的な目標達成にもつながります。
1.2 開発生産性の定義
「開発生産性」が指す範囲は広い
得られた成果物（アウトプット）÷ 投入した生産要素（インプット）＝ 生産生
重要なのは自分たちの組織や開発チームにとって何がアウトプットであり、何がインプットであるか、そして何を開発生産性と呼ぶのかを明確にすること
開発生産性を考える上でのインプット、アウトプットの例
| 種別 | 項目 |
|---|---|
| 開発生産性におけるアウトプット | リリースされた機能や修正の数 開発されたコードの行数 提供された価値 |
| 開発生産性におけるインプット | 開発に費やされた時間（人時、人月など） 開発に使用された予算 開発に必要なインフラやツールのコスト |
1.1.2 開発生産性向上に取り組むべき箇所
エンジニアリングに特化した部分は取り組みやすくコントロールしやすい
組織を横断した取り組みはすり合わせなどに時間がかかるため手が出しづらい
エンジニアリングのみ開発生産性が高くてもそれぞれの工程の連携が不十分であったりするとプロダクト全体で見た時にあまり生産性が上がっていない可能性がある為注意すること
1.2.3 開発生産性のレベルについて
レベル１： 仕事量の生産性
- 個人の生産性の部分
レベル２： 期待付加価値の生産性
- 期待される価値がどの程度リリース出来たか
レベル３： 実現付加価値の生産性
- プロダクトにより売り上げがどれだけ変化したか
1.3 開発生産性レベルごとの分類とタスク例
開発生産性レベル１
いろいろな取り組みがあるが代表的な例として下記のようなものがある
- ソースコードのメンテナンス性向上
- リファクタリング
- UTの強化
- タスク自動化スクリプト作成
- ビルド、デプロイスクリプトの自動化
- コードレビューの効率化
- リンターを使った軽微なエラー検出、コード品質可視化、依存関係のチェックなどをCI／CDを使って自動化
- コミュニケーションとチームワークの効率化
- 自分の抱える課題間や持っている情報を口頭で共有する会を開く
- ペアプログラミング
開発生産性レベル2
- プロジェクトの最適化
- チーム連携・情報共有の円滑化
- リスクマネジメントの強化
- 品質保証の強化
開発生産性レベル3
- 分類、評価が難しいらしい
1.4 なぜ開発生産性向上が必要なのか
- 人口減少と高齢化による労働者不足
- 働き方改革
- デジタルトランスフォーメーション
などで開発生産性の向上が必要になってきた
エンジニアリングの場合
エンジニアチームの開発生産性を上げることで以下のようなメリットがある
- 少ない投資でより多くの成果を獲得
- 組織の可視化による課題の明確化
- 改善のサイクル
- プロダクトサイクルへの貢献
- 採用への好影響
第二章 開発生産性のためのステップ
2.1 現状の可視化
- 開発生産性を何故高める必要があるのか
- 自分たちにとってどのようにポジティブな結果につながるのか
をチームのエンジニア全員が理解を示しノウハウや考え方を共有する状況を作ることが最初の重要ステップ
以下の指標を元に観測し、分析する。
開発生産性フレームワーク Four Keys vs SPACE
FourKeys
Four Keysとは開発チームの生産性を測る 4 つの指標で、以下の指標が含まれます:
| 指標 | 説明 |
|---|---|
| デプロイの頻度 | デプロイ（開発した機能をお客様が使える状態にすること）した回数 高いほどよい |
| 変更のリードタイム | 機能を開発してからデプロイまでにかかる時間 短いほどよい |
| 変更障害率 | プロダクトに障害が発生する割合 低いほどよい |
| サービス復元時間 | プロダクトに障害が発生してから復元するまでの時間 短いほどよい |
SPACE
SPACEフレームワークは、2021年に「LeanとDevOpsの科学」の著者、Nicole Forsgren氏がGithub、ビクトリア大学、Microsoft Researchなどのチームと共に開発した、開発チームの生産性を測定するためのツールです。
このフレームワークでは、生産性を総合的に評価するために以下の5つの重要な指標を用います。
| 指標 | 説明 |
|---|---|
| Satisfaction & Well-being | 仕事、チーム、使用するツール、職場文化にどれだけ満足しているかを評価 |
| Performance | チームが生成したコードがもたらした成果の大きさを評価 |
| Activity | メンバーが業務遂行の過程でどれだけの行動や成果を出しているかを評価 |
| Communication & Collaboration | チーム内外でのコミュニケーションや協力の様子を評価 |
| Efficiency & Flow | チームや組織全体の活動がどれだけ効率的に、スムーズに運ばれているかを評価 |
SPACEフレームワークを導入して開発生産性の改善活動ができる環境作り
観測・分析を終えたら、メンバーにヒアリングなど行い課題の洗い出しを行う
その中で見つけた課題に対して優先順位づけを行い目標と改善策を実行する
例：
課題
デプロイ頻度が低い → レビューに時間がかかっている → 変更内容が大きすぎてレビュアーが内容確認に時間が取れない
改善案
- タスクのサイズを分割する
- レビュアーの数を増やす
注意点として、生産性向上の取り組みを継続的に行う際にはチームメンバーに負担がかからないように調整すべき
チームメンバーを大切にしよう
第三章 生産性向上の取り組みを阻害する原因とその対策
エンジニア個人に関連する阻害原因とその対策
技術の進歩に伴う技術的知識、スキル不足
- 新しい技術の活用ができていない
- モチベーションの不足
対策
- 勉強会の開催
- 外部イベントへの参加
適切な技術選定とその活用ができていない
- 技術的負債の蓄積
- メンテナンスコスト増加
- 属人化
対策
- 使用しようとしている技術の成熟度を考慮し、組織のレベルに合わせてキャッチアップ可能か確認する
セキュリティ対策ができていない
- 顧客からの信用低下
- セキュリティ対応のために既存の開発を止め、調査する必要があるリスク
対策
- 脆弱性診断の定期実施
テスト自動化や継続的インテグレーションが導入されていない
- 手動テストに時間がとられすぎる
対策
- ユニットテストを書く
- プルリクのタイミングでテストの自動実行をし、変更に問題がないかを自動で確認
品質の重要性の認知
- 品質面の意識が低いためやり直しやバグが発生しやすくなる
- 不具合対応で新規開発が出来ない
- 顧客からの信頼の低下
対策
- 顧客満足度、手戻りコストの可視化
- トップダウンでのアプローチ
エンジニアチームに関連する阻害原因とその対策
ナレッジ共有とドキュメント不足
- 過去の問題に対して重複した対応が発生する
- 特定メンバーへの負担
- システムの理解が難しい
対策
- ナレッジ共有
- 勉強会の開催
- ドキュメントをきちんと更新する
技術的負債の管理と優先順位づけが出来ていない
- セキュリティ対策不足
- システムのパフォーマンス悪化
- コードの複雑化
対策
- 使用ライブラリのバージョン可視化
- GithubのDependabotの活用
自動化が推奨されていない
- 手作業によりミスが発生しやすい
- 品質の低下
対策
- ビルド、デプロイ、テスト、コードレビューなどの自動化
- 手作業の時間を可視化
開発環境の整備がされていない
- 本番ではバグが発生するが開発環境では起きないなどが起こる可能性がある
対策
- 環境のコンテナ化
- インフラのコード化
- 開発端末の設定の共有
インフラ環境が最適さされていない
- 開発コスト増加
- リソースの無駄使い
対策
- 測定を行い、最適化する
- キャッシュの活用
- オートスケーリング設定
- DBのクエリ最適化
品質管理が十分に出来ていない
- バグが多発し、信頼の低下
- 手戻りや不具合対応で生産性の低下
- モチベーションの低下
対策
- コーディング規約と静的コード解析ツールの導入
- ユニットテスト、結合テスト、E2Eテストの自動化
- カバレッジの測定
- 品質改善のための振り返りと施策実行
開発生産性向上に対するチームの意識が低い
- 開発生産性の取り組みがそもそもされていない
- 一部メンバーの努力だけではチーム全体の生産性向上は難しく、結果としてモチベーションの低下につながってしまう
- 新しい取り組みへの抵抗感
対策
- 現在の開発生産性に対する認識の共有
- 開発生産性の指標の設定と定期的な観測・共有
- 開発生産性向上をテーマにした社内イベントの開催
開発生産性向上に有用なツール紹介
海外事例の紹介
ネットフリックスが従業員を解雇するときに使う｢キーパーテスト｣とは
プラットフォームエンジニアリングとは？アプリケーション開発のトレンドをわかりやすく解説
【DevSecOpsとは？】入門者向けにメリットなどの概要をわかりやすく解説
最後に
開発現場のリーダーやIT企業の経営層の方に読んでほしい内容でした。