- この記事は、チームの生産性を測定しようとする試みがどのように失敗したかを説明している
- 個人評価および育成目的で、個人パフォーマンス指標の導入を決定
- コード行数やバグ数は操作されやすいため除外し、代わりにストーリーポイントまたは完了したストーリー数で成果を測定することにした
Tim Mackinnonの成果は「0」
- チームの生産性測定ツール（Jira など）を通じて、全チームメンバーの成果を測定
- Timの成果スコアは 0 → ストーリーポイントを1つも記録していなかったため
- マネージャーは Tim の成果が0であることを理由に、Tim を交代させるよう求めた
Tim Mackinnonが成果を出せなかった理由
- Tim はストーリーを直接担当していなかった
- その代わり、チームメンバーとのペアプログラミングに集中していた
- 経験の浅い開発者と一緒に作業し、問題解決を促した
- 自分で解決するのではなく、質問を通じて解決策を導き出せるよう支援した
- シニア開発者とは課題を一緒に考え、解決策を改善した
- Tim は自分でコードを書いてはいなかったが、チーム全体の成果を向上させた
Tim Mackinnonの本当の貢献
- Tim の貢献は、個人の成果スコアでは測定できない
- Tim のおかげで、チーム全体の生産性とコード品質が向上した
- Tim と一緒に作業すると、より速く、より良い結果を得ることができた
評価方式をチーム生産性ベースに変更
- マネージャーに Tim の貢献度を説明し、観察の機会を提供
- チーム全体の成果が向上していることを確認した後、個別成果の測定方式を放棄
- 個人の成果ではなく、チーム成果とビジネスへの影響を基準とする評価方式へ転換
要約 (tl;dr)
- 生産性はビジネス成果（例：コスト削減、収益創出など）で測定すべき
- 複雑なシステムでは、個人の成果測定には意味がない
- DORA Metrics などはシステムの成果を測定するためのツールであり、個人の貢献度を測るツールではない
- Tim Mackinnon と一緒に働く機会があるなら、逃さないこと
5件のコメント
実際、シニアを超えてスタッフエンジニアくらいになると、実際に現場へデプロイされるコードからはだんだん離れていって……その代わり、シニアやジュニアを相手にしたコーチングの比重が大きくなるように思います。マネージャーたちの愚痴も聞いてあげなければならないし……問題が起きればあちこちに呼ばれて解決策を示さなければならないし……
やっていることがこういう感じなので、Jiraのチケットやポイントでも定量化するのは不可能でしょう。
テックリードとしてこのような作業をかなり多くやっています。ストーリーポイントに基づく定量化を試みるのも似たようなものですが、幸い会社がそれほど大きくないので、役員をはじめとするメンバーが私がどのような役割をしているのかを認識してくれており、今のところは問題は発生していないようです。
組織が大きくなったら、定量化の方法も考えてみる必要がありそうですね。
どこかで見た話だと思ったら……2023年の記事だったんですね。
2年前にも同じ記事が上がっていましたね https://ja.news.hada.io/topic?id=10680
GitHub Copilotみたいな方ですね……。
Hacker Newsの意見
個人開発者の生産性を測定するのはばかげている。コード行数やストーリーポイントの測定は、生産性とは逆行する。開発者がより少ないコードでより多くの価値を生み出すことが重要だ
Timの名前をチケットに付けて問題を解決する方法を見つけた。チームメンバーは喜んで手伝ってくれるだろう
Timがチームに残り、プロセスを正しい方向へ導いているのはうれしい。耳を傾けるマネージャーが必要だ
あるプログラマーが個人作業をせず、ひたすら支援ばかりするモデルは不自然だ
Timが個人作業をしないのは不自然だ。チーム生産性を最大化するには、個人の貢献とチーム協業のバランスが必要だ
Timがチームに貢献していないなら、仕事に取りかかってストーリーを届けるよう求めるだろう。Timが他人を助けるのはよいが、自分の作業もすべきだ
すべてがグループ活動である必要はない。平均的な開発者がTimの継続的な支援なしに機能を提供できないなら、チームに問題がある
最高のチームには常にTimのような人がいる。Timの支援は他の人にも波及し、チーム全体が成長する
ストーリーポイントで開発者の生産性を測定するのはよくない。Zeroという開発者はストーリーを割り当てられず、チームを支援していた
支援の価値を定量化するのは難しい。しかし支援は不可欠だ。リーダーが正しく判断できるよう信頼すべきだ