【かいはつせいさんせい】
開発生産性(Dev Productivity) とは?
最終更新:
💡 成果・仕事の流れ・働く人を合わせて、開発を良くする
開発者やチームが、価値あるソフトウェアを生み出す力。コード行数や配送速度だけでは測れません。SPACEと現在のDORA指標を使い、成果・作業の流れ・開発者の状態を合わせて改善する考え方を解説します。
📌 このページのポイント
- コード行数やコミット数だけで、生産性や個人の貢献を判断しない
- SPACEは満足度・成果・活動・協働・効率と流れの複数の観点を扱う
- DORAはソフトウェアの配送性能を測る指標で、生産性のすべてではない
- 同じサービスの変化を追い、待ち時間や手戻りの改善を確かめる
開発生産性は、書いたコードの量?
量だけでは分からないよ。不要なコードを減らす、調査で問題を避ける、同僚を助けるといった仕事もある。コミット数が少ないから価値が低い、とは判断できないんだ。
何を見ればよい?
SPACEという枠組みでは、満足度と健康、成果、活動、コミュニケーションと協働、効率と作業の流れを扱う。全部を1つの点数に押し込めず、改善したい課題に合う複数の観点を選ぼう。
DORAの4指標も聞くよ。
個人ごとに順位を付けるもの?
DORAはアプリやサービス単位で使い、背景が違うものを単純に競わせないよう説明している。たとえば自分たちのレビュー待ち時間と配送の指標を追えば、どこを改善するかの話につなげられるね。
AIを使えば、必ず生産性が上がる?
入力の速さだけでは判断できないよ。ここでは例として、修正が完成するまでの時間、レビューや手戻り、成果の品質、使う人の負担も確認するとよい。別の条件で得た速度の数値を、そのまま自分たちの改善率とはしないようにしよう。
計測を始めるには?
まずチームで困っていることを具体化する。たとえばビルド待ちを減らす改善を行い、待ち時間と不具合、働きやすさの変化を合わせて確かめる。数字を良く見せるための作業を増やすと目的が逆になるので、改善の手掛かりとして使おう。
もっと詳しく知りたい人へ
現在のDORA指標の「リードタイム」「復旧時間」は、どこから測る?
変更のリードタイムは、バージョン管理へのコミットから本番へのデプロイまでです。失敗したデプロイからの復旧時間は、直ちに対応が必要になったデプロイの失敗から復旧する時間で、すべての種類の障害をまとめた一般的なMTTRとは区別します。
「変更失敗率」と「デプロイの手戻り率」は同じ?
変更失敗率は、ロールバックや緊急修正など直ちに対応が必要になったデプロイの割合です。デプロイの手戻り率は、本番のインシデントを受けて予定外に行われるデプロイの割合です。何を分母や対象にするかを決め、定義をそろえて追跡します。
まとめ:ざっくりこれだけ覚えればOK!
「開発生産性」って出てきたら「価値ある成果を生む力」と思えばだいたいOK!
📖 おまけ:英語の意味
「Developer Productivity」 = 開発者の生産性
💬 productivityは生産性を意味します。開発では、作業量だけでなく、成果や協働、作業の進めやすさなども含めて考えます。