ソフトウェア開発者の評価指標を考えてみた2019
私の勤めている会社は、ちょうど今が(人事)評価の時期です。 今日もチームメンバーと「どんな評価指標を使うのが良いのか」という雑談をしていたのですが、その内容が他のチーム・会社でも使えそうな気がしたので、ブログにまとめてみました。ちなみに雑談のまとめなので、あくまでアイデアの1つとして読んでいただければ幸いです。
ちなみに評価対象は、ソフトウェア開発に関わる人、具体的にはプログラマ・インフラエンジニア・QAあたりを想定しています。
1. ダメな評価指標例
まずは、「これは(アカン)」というものから。
(1) プログラム・コードを作成・追加した行数
そもそも、「行数が多い == 生産量が多い」ではないです。
何も考えずに行数だけ増やしてしまうと、メンテナンスコストやバグの混入確率が増え、結果としてチーム・会社にマイナスになります。
(実際に学術的にも実証されています。)
(2) GitHubへのコミット回数
これも、「コミット回数 == ユーザーへ提供した価値」ではないです。
コミットをしただけでは、ユーザーへ何の価値も提供できていないので、評価指標としては使えないです。
(3) 稼働率
稼働率を100%に近づけるということは、それ以外のことをする余裕をなくすということです。
稼働率を高くすることは、チーム・会社にとっては明確なマイナスとなります(これも実証されています)が、不勉強なマネージャーにとっては魅力的な指標に映るのも事実です。
2. 評価指標を考えるための軸
上記のダメな例に共通しているのは、従業員・チーム・会社としてユーザーに提供する価値(outcome/delivery)の観点が抜けている点です。我々は、ユーザーに何らかのソフトウェアの機能を提供し、ユーザーからお金・情報などの対価をいただくことで、社会に存在しています。であれば、我々とユーザーとの接点となるoutcome/deliveryを軸に評価指標を考える必要があると考えます。
以下に、ポイントを列挙してみます。
- ソフトウェアの機能は、リリースして初めて、ユーザーに価値を提供できる。
- 従って、ソフトウェアのリリースに関するパフォーマンスを、評価の主軸として考えることには妥当性がある。
- ソフトウェアのリリースパフォーマンスの向上と、組織のパフォーマンスの向上・従業員満足度との間には、正の相関があるという研究結果が最近出てきた。
- 個人単位だけではなく、チーム単位でもパフォーマンスを見る必要はありそう。
3. 使いたい評価指標例
outcome/deliveryを軸に、使いたい/使ってみて効果のあった評価指標を、以下に挙げます。
ちなみに下記 (1) - (4) は、「4 Key Metrics」の名称で、世界的にも利用者が広がり始めています。
www.thoughtworks.com
(1) リリース頻度
「1日あたりのリリース回数をひたすら増やす」ではなく、「3ヶ月に1度リリースしていたものを、1週間に1度まで短くすることが出来た」というようなイメージです。
(2) 機能追加・変更のリードタイム
ユーザーニーズを把握してから、実際にユーザーに価値を提供するまでにかかる時間です。
ユーザーからのフィードバックを、迅速にプロダクトに反映できている指標にできます。
(3) MTTR (Mean Time To Repair)
障害・問題を発見してから、ユーザーに修正版を提供するまでにかかる時間です。
上述のリリース頻度と組み合わせれば、事実上の「品質の向上」とみなすことも可能かも知れません。
(4) Change Failure Rate
リリースしたものに、価値提供に致命的な問題(バグなど)が混入していた比率です。もちろん少ない方が良いです。
(5) Shift Left on Test
一通り開発を終えてから行うQAではなくて、開発より前のフェーズでどの程度テストに関するアクティビティを実践できているか?の度合いです。
要件定義やアーキテクチャ策定の段階から「テストのしやすさ」を組み込めれば、プロダクト開発の早期から「品質の作り込み」がしやすくなります。
また同様のことは、セキュリティや「リリースのしやすさ」についても言えるでしょう。
(6) Rework/Unplanned workの削減量
「品質」が悪いと辛いのは、ユーザーからの評価や利益が減ることももちろんですが、Rework/Unplanned workが増えてしまうことにも当てはまります。 つまり、Rework/Unplanned workを削減することは、QAないし品質に関わる全てのメンバーの評価につなげられます。
ただし、これを指標として使う場合は、テスト自動化・DevOpsは前提・必須となるでしょう。
(7) eNPS (Employee Net Promotor Score)
従業員やチームメンバーの満足度を測る指標の1つで、自分たちの部署およびチームを、友人や同僚にどの程度推奨できるかで計測できます。
詳しくは、こちらをご覧ください。
cultureiq.com
まとめ
- 自分たちは何を持って評価されるか?
- 自分たちは何を持って評価されたいか?
- 自分たちは何を持って他者を評価するか?
これらの問いは、仕事のしやすさやモチベーションにも直結するので、同僚や上司とできるだけ話をした方が良いです。
参考資料
上記の内容の多くは、この書籍を参考にしました。
- 作者: Nicole Forsgren PhD,Jez Humble,Gene Kim
- 出版社/メーカー: IT Revolution Press
- 発売日: 2018/03/27
- メディア: Kindle版
- この商品を含むブログを見る
日本語版も出たようです。
LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
- 作者: Nicole Forsgren Ph.D.,Jez Humble,Gene Kim,武舎広幸,武舎るみ
- 出版社/メーカー: インプレス
- 発売日: 2018/11/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
2014年にAgile Allianceに投稿した論文。論点が割と今と比較してもブレていなくて、自分でもびっくり。
https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Ito_.pdf