※ 当記事はエンジニアから管理職側に移った者のボヤキです。生産性はないです。
何を話したいか？
定量的な評価に対する疑問点
開発生産性(DPE)と定量的な評価
組織は何を評価の拠り所にすべきなのだろうか
定量的評価至上主義に対する疑問
MBOとかOKRなど目標管理において、定性的な目標ではなく定量的な目標を設定してくださいと僕の観測範囲ではよく言われています。
カオナビの人事用語集には、
OKRでは、SMARTの法則に基づき目標を設定することが一般的です。
Specific：具体的に
Measurable：測定可能な
Achievable：達成可能な
Related＝経営目標に関連した
Time-bound＝時間制約がある
といった話も書いていて、特に測定可能な指標として定量的なものが求められているのかなと思います。(利用用途や達成度に違いはありますが、MBOも同様かと思います。)
実際に私もチームメンバーの評価に一部関与した経験があるのですが、数値があるとどの程度達成できているのかが、 割合で分かるのでパイプライン的に評価し易いなと思ったりしました。
でも、評価ってパイプライン的に行っていいんでしょうか？そんなわけないですよね。
実際に僕の観測範囲では、MBO以外にも多面評価(360度評価、上司からの推薦など)の別軸での評価も行われ、そちらと合わせて最終的な人事考課として反映される認識です。
こういうことがなんで行われているかというと、数値では表せないことがあるからだと認識しています。つまり、定量化できないことがあるというのを経営陣は理解しているから定性的な判断も行っているわけです。
で、本題に戻ると経営陣がそう思っているからと言って、組織がそう思っているわけではないです。部課長クラスで定量的評価至上主義に陥っていて、それが文化として根付いてしまっている場合があるということです。そして、それを良しとしている管理職と組織に僕は疑問持っているわけです。
僕が持っている疑問点を列挙すると
その数値、本当に目標貢献に繋がるの？
その数値、どうなるのが理想か分かってるの？
数値化できていない(できない)要素を想定(理解)しているの？
それ数値化しなくても良くない？
こんな感じです。これらの疑問はSMARTの原則違反ですよでほぼ終わりなんですが、乱暴すぎるので開発生産性と照らし合わせ、少し深ぼってみます。
開発生産性と定量的な目標
最近流行りの開発生産性(DPE)では
Gradle Inc.が提唱するDeveloper Productivity Engineering（DPE）は、管理指標やベストプラクティスではなく、自動化技術やツールに焦点を当てた、ソフトウェア開発チームの生産性を向上させるアプローチです。具体的には、この新しいソフトウェア開発規律は、ソフトウェアのビルドとテストプロセスをスピードアップするためにアクセラレーション技術を使用し、トラブルシューティングとソフトウェア品質保証をより効率的にするためにデータ分析を使用します。その目的は、より速いフィードバックサイクル、より信頼性の高い実用的なデータ、満足度の高い開発者体験を実現することです。また、DPEは反復的なアジャイルアプローチと連動するため、フィードバックサイクルも高速化します。
といったように定量化する箇所を絞っていたりします。
Four Keysとかはまさにそれだと思います。
DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
これらの概念・フレームワークは開発生産性において定量化できない箇所があり、それを認め、定量化できる部分を観測していくといった活動だと思っています。例えば、「エンジニアリング組織論への招待」では「生産性という指標が日常語としては曖昧な意味で用いられ、組織の効率性を表す指標として向いていない」といったような記述があります。こういった管理指標がDPEの嫌うとこではないのでしょうか？
僕が持っている疑問点を改めて列挙すると
その数値、本当に目標貢献に繋がるの？
その数値、どうなるのが理想か分かってるの？
数値化できていない(できない)要素を想定(理解)しているの？
それ数値化しなくても良くない？
これを開発生産性に当てはめてみます。1,2,3に関して、DPE観測範囲外の定量化は複雑な要素があるので困難そうな印象を受けます。4に関しては、まだ判断がつかないです。
4に関しては、SPACEフレームワークを用いて、5つの次元で指標を考えていくと良いのかもしれないです。
Satisfaction and well-being
Performance
Activity
Communication and collaboration
Efficiency and flow
エンジニアリング活動を定量的に評価するなら、こういった多角的な指標管理を持つべきだと思います。ただ、これも結局上手く指標化して運用していくにはそれなりの困難さがつきまとうと思います。
組織は何を評価の拠り所にすべきなのだろうか
確実なのは、評価で扱う指標をすべて定量化することは難しいということです。
例えば、先程も触れたやめたほうがいい指標「生産性」についてですが、色々と種類があったりしますが、ざっくりいうと「売上 / 人件費」から算出されます。これがKPIだったりMBOに設定されているとします。この売上や人件費、NSMやSPACE等でしっかりと補強しないとハックされ放題です。人件費を下げるために、採用活動をやめて一人あたりのみなし残業時間を増やせば生産性は数値上増えます。でもそんなことをすれば、離職者が増えたり、GPTWが下がったりと負の側面があるわけです。経営陣はそれを良しとしたくないはずですが、管理職が定量的評価至上主義だと起こり得ます。
では、NSMやSPACE等でしっかりと補強したらいいのではとなると思うのですが、そもそもそういう組織であれば、定量的評価至上主義にはなっていないはずです。つまり、
重要業績評価指標や人事評価をテコ入れする仕組みを作る
仕組み化は無理なので、定性的な指標と結果で見る
のどちらかになるのかなと思っています。どちらにせよ、組織レベルの話になると経営陣や部課長クラスがやるべきことであり、僕のような末端の管理職には提案・エスカレーション以外できることはないですが。(「ボヤキです。生産性はないです。」といったのはそういうことです)
仕組み化は試行錯誤するしかないかなと思います。
「定性的な指標と結果で見る」については、定量的な指標を達成値としてではなく、割合等で見ているものに関しては定性的な指標に置き換えてしまえばいいと思います。結局数値化するということは測量が必須になるわけで当然コストが掛かります。これをマイルストーンとして定性的にしてしまい、コスパよくできた・できていないを判断すれば良いわけです。どうせ測量した値も妥当性のあるものなのか分からないのなら、そこにコストを投下するのは無駄なわけです。
もちろん、KGI・KPIなどは社外に公開される指標である可能性が高く、それは数値を置く必要があると思います。しかし、会社の目標値をそのまま組織に投下する必要はないんじゃないかと思います。「定量->定性->定量」のようなレイヤー構造にして、その境界面でフォーマットするような状態が望ましかったりしないのかなと思うところです。例えば、経営陣は数値を求め、組織(管理側)は文化・あるべきを求め、個人(エンジニア)は開発生産性を求めるといった感じです。結局、境界面でフォーマットが厳しい気もしますが、すべて定量化よりは実現可能なのではと思います。