営業の方であれば、月間の売上以外に新規の見込み数や、見込み客でも確度別の分類数など様々な指標で評価されることが一般的だと思います。
これらは「結果」に対する指標なのですが、それ以外でも見込み客に対する接触数など「行動」に対する指標なども定量的評価されることが一般的ではないでしょうか。
エンジニアの場合、スキルといった見に見えるものはあるのですが(これも限界はありますが・・・)、日々の業務での「結果」だったり「行動」だったりを評価する必要があると思っております。
ウォーターフォール的な現場ですと、ガントチャートが結果としてそうなったりするのですが、どちらかというと「成果物に対しての進捗の把握」が目的のため、個人の行動や結果の評価などを目的とした場合には別のものが必要になるのかなと思っております。
そういった定量評価をしている現場で仕事はしたことがないのですが、あったとしたら指標はどうあるべきか、どのような指標が良いかを考えてみました。
Contents
評価指標の策定
業績評価の基準としては以下のものが大事かなと思っております。
具体性
- はっきりとした誰にでもわかる指標か
- 目に見える成果物(資料やソース)が出せるものか
定量性
- 数値化できるものか
- 客観的なものかどうか
コントロール性
- 達成可能かのニュアンスも一部含む
- 自分自身でコントロールが可能か(NG例としては営業における売上など)
公平性
- メンバーが納得できる指標か
- 努力が反映されやすいものか
妥当性
- 業務量の評価指標として適切か
参考リンク
似たような考え方のリンクがありましたのでのせておきます。
具体的な評価指標
現段階で自分が経験したもので評価指標として使えそうなものをあげてみました。
タスク数(タスク管理ツールのチケット数)
RedmineやBacklog、GitHub(issues)などのタスクをどのくらいこなしたか、ステータスが未解決→進行中→解決など遷移していきますので、これらの移り変わりなど(GitHub Actionsなどだと綺麗にグラフ化されています。)
メリット
- ソース以外のタスクに対応できる
- やりとりの経緯なども追える
デメリット
- 人によってタスクの粒度が異なるのでタスクの精査が必要(テンプレートをある程度フォーマット化すればいいかも)
コミット数
Gitのコミット数です。
メリット
- 集計が容易
- 業務の評価量としては妥当性が高い
デメリット
- プログラム変更以外のタスク(Excelを用いたシュミレーションなど)の測定ができない
- コミットの粒度が人によって違うので、コミット単位に関しての精査がないと不平等な指標になってしまう。
Pull Request
コミットと近いですが、Pull Request数など。
メリット
- 集計が容易
- 妥当性が高い
- レビュー時に他人のチェックが入り、ファイル数や差分などもわかるので、粒度に関する問題をある程度解決できる
デメリット
- プログラム変更以外のタスク(Excelを用いたシュミレーションなど)の測定ができない
想定できる問題点と対策
指標の運用問題
- 指標として適切か否か
- 運用が形骸化しないか
- 集計コストが高すぎないか
→いきなり本格運用せず、実験段階で運用して、定例会議などで妥当性が見えそうな段階で本運用に載せるなど。
メンバーからの反発
運用コスト上の問題
→このための仕事が増えないように測定行為自体を軽量化する必要がある。
管理されたくないなど
→管理度が高くない現場だとストレートにこういった発言をするメンバーもいます。特に古くからいて文化に慣れてしまっているメンバーだと難しいかもしれないです・・別のポジションに入ってもらうか、それでも改善されない場合は離脱してもらうしかない・・ですね。
モラルハザード
わざとPRを水増しするなど、評価のための仕事を作成されないか
→PRのテンプレートを作り基準を設ける、最低ファイル数や最低の差分などをあらかじめ告知しておく(評価指標に対して普段からレビューや精査がされているものだと望ましい)
