The HIRO Says

If you smell what The HIRO is cooking!!!

ソフトウェア開発者の評価指標を考えてみた2019

私の勤めている会社は、ちょうど今が(人事)評価の時期です。 今日もチームメンバーと「どんな評価指標を使うのが良いのか」という雑談をしていたのですが、その内容が他のチーム・会社でも使えそうな気がしたので、ブログにまとめてみました。ちなみに雑談のまとめなので、あくまでアイデアの1つとして読んでいただければ幸いです。

ちなみに評価対象は、ソフトウェア開発に関わる人、具体的にはプログラマ・インフラエンジニア・QAあたりを想定しています。


1. ダメな評価指標例

まずは、「これは(アカン)」というものから。

(1) プログラム・コードを作成・追加した行数

そもそも、「行数が多い == 生産量が多い」ではないです。

何も考えずに行数だけ増やしてしまうと、メンテナンスコストやバグの混入確率が増え、結果としてチーム・会社にマイナスになります。 (実際に学術的にも実証されています。)

(2) GitHubへのコミット回数

これも、「コミット回数 == ユーザーへ提供した価値」ではないです。

コミットをしただけでは、ユーザーへ何の価値も提供できていないので、評価指標としては使えないです。

(3) 稼働率

稼働率を100%に近づけるということは、それ以外のことをする余裕をなくすということです。

稼働率を高くすることは、チーム・会社にとっては明確なマイナスとなります(これも実証されています)が、不勉強なマネージャーにとっては魅力的な指標に映るのも事実です。


2. 評価指標を考えるための軸

上記のダメな例に共通しているのは、従業員・チーム・会社としてユーザーに提供する価値(outcome/delivery)の観点が抜けている点です。我々は、ユーザーに何らかのソフトウェアの機能を提供し、ユーザーからお金・情報などの対価をいただくことで、社会に存在しています。であれば、我々とユーザーとの接点となるoutcome/deliveryを軸に評価指標を考える必要があると考えます。

以下に、ポイントを列挙してみます。

  1. ソフトウェアの機能は、リリースして初めて、ユーザーに価値を提供できる。
  2. 従って、ソフトウェアのリリースに関するパフォーマンスを、評価の主軸として考えることには妥当性がある。
  3. ソフトウェアのリリースパフォーマンスの向上と、組織のパフォーマンスの向上・従業員満足度との間には、正の相関があるという研究結果が最近出てきた。
  4. 個人単位だけではなく、チーム単位でもパフォーマンスを見る必要はありそう。


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

まとめ

  • 自分たちは何を持って評価されるか
  • 自分たちは何を持って評価されたいか
  • 自分たちは何を持って他者を評価するか

これらの問いは、仕事のしやすさやモチベーションにも直結するので、同僚や上司とできるだけ話をした方が良いです。


参考資料

上記の内容の多くは、この書籍を参考にしました。

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (English Edition)

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (English Edition)

日本語版も出たようです。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)


2014年にAgile Allianceに投稿した論文。論点が割と今と比較してもブレていなくて、自分でもびっくり。

https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Ito_.pdf