開発生産性

一言でいうと

開発組織が価値を継続して届ける力を、速さ、品質、安定性、開発者の働きやすさといった複数の面から捉える考え方です。

提唱者と登場年

開発生産性の指標としては、DORA（DevOps Research and Assessment）の調査がよく参照されます。DORAは2014年にPuppetと共同でState of DevOps Reportを発表し、バージョン管理、継続的インテグレーション、自動テストなどの技術的な実践と、組織の成果との関係を示しました。DORAのソフトウェアデリバリーの指標は、当初の4つの指標から、現在はスループットと不安定性を測る5つの指標へと更新されています。

開発者の生産性そのものを扱った文書としては、Nicole Forsgrenらが2021年2月にACM Queueに発表した「The SPACE of Developer Productivity」があります。この論文は、開発者の生産性は個人の活動量やシステムの効率だけで決まるものではなく、単一の指標や次元では測れないと述べ、複数の次元で捉える枠組みを示しました。

何を解決するか

開発組織の成果を、書いたコードの行数やプルリクエストの件数といった個人の活動量で評価する誤りを防ぎます。活動量は増やしやすく、数字を上げること自体が目的になると、品質の低下や手戻りの増加を招きます。

複数の指標を組み合わせると、どこが流れを止めているかを特定できます。たとえば変更のリードタイムが長いなら、レビューの待ち時間やテストの実行時間に原因がある可能性があります。前提として、指標を個人の評価に使わず、組織の改善に使うという合意が必要です。

実際の進み方

DORAの指標では、変更のリードタイム、デプロイの頻度、失敗したデプロイからの復旧時間、変更の失敗率、デプロイのやり直しの割合を測ります。これらはバージョン管理とデプロイの記録から自動で集計することができます。

数値だけでは開発者の負担や満足度がわからないため、定期的なアンケートを組み合わせる組織もあります。測定の結果をもとに、改善する対象を一つ選び、施策の前後で指標がどう動いたかを確認します。

導入でよくある失敗

• 指標をチームや個人の評価に使い、数字を良く見せる行動が増える
• デプロイの頻度だけを追い、変更の失敗率や復旧時間を見落とす
• 測定の仕組みを作ることが目的になり、改善の施策に進まない

求人票にこの語がある場合に読み取れること

エンジニアリングマネージャーやプラットフォームエンジニアの求人に開発生産性の向上とある場合、開発の流れを測り、ボトルネックを取り除く役割が期待されていると読み取れます。開発生産性を専門に扱うチームを置く組織もあります。候補者には、どの指標を使ったか、測定の結果から何を変え、指標がどう動いたかを確認してください。

隣接手法との違い