開発者の生産性を測定する際に犯しがちなミス
(thenewstack.io)- 開発者の生産性を測定する際によくあるミス
- 投入量の測定の問題
- 「勤務時間」のような投入量や努力に依存すると、誤った行動を助長する
- たとえば、企業文化が画面の前で過ごした時間を価値あるものとして評価し報いるなら、開発者はそこに時間を注ぎ込むようになるが、作業の品質は保証できない
- より過酷な環境では、「最も早く出社して最も遅く退社する」競争に変質する可能性がある
- 結果の測定の問題
- コード行数やコミット数のような最悪の指標がこのカテゴリーに入る
- 開発者はコード行を非常に速く大量に書けるため、これを測定するのは簡単だ
- すべての結果指標は文脈に応じて理解しなければならない
- 結果と影響の測定の問題
- これら2つの指標における課題は、「DevOpsチームがどれほど責任を負っているか」を把握することだ
- ビジネス収益の増加を測定する際、それを開発者の責任だけに帰するのは不可能だ
12件のコメント
ぞっとしますね。マネージャーの視点と現場担当者の視点には違いがありそうです。
まさにllmが必要な部分のようですね
代案のない文章なので、伝えようとしている意味がやや薄れてしまっている面があります。成果物の量を結果測定から除外すべきだという主張には同意しますが、勤務時間を投入量の測定から完全に除外すべきだという点には、現実に合わないため賛成できません。いずれにせよ、知識労働をしている間も時間は流れるので、意思決定には時間を必ず考慮すべきだと思います。
全体進捗率 = （充足した要件数 / 勤務時間）のような先行指標を測定したうえで開発者の生産性を論じるほうが、理解しやすく効率的だと思います
私は最近、この種の文章をやや批判的に見るようになりました。というのも、人々が結局こうした文章を読んで、「まったく管理しない」という結論を下してしまうと思うからです。どのような指標で管理しても、結局は似たような問題があります。また、何らかの指標を人やチーム間の競争や比較のために使うようになると、副作用が生じます。だからこそ、単一の指標だけで管理してはいけず、相互補完的な指標をあわせて管理する必要がありますし、指標はチームが自ら改善する助けとなるよう活用すべきだと考えます。
意味のある単位のPRを上げた件数で測定するのはどうでしょうか？
実際に、国内のある大企業では、書いたコードの行数で成果を測っているところがあります……
私も見たことがあります。
変数名をずっと変える commit を上げていましたね……（笑）
コードレビューが行われていない環境なんでしょうね？
笑 コードレビュアーもコードレビューを受けないといけないので。
お互いに助け合っているみたいですね..
wwww ああ…
hello hell world ;)
これがあの、噂にだけ聞いていたLOC生産性測定なんですか…？ ﾌﾞﾙﾌﾞﾙﾌﾞﾙ