skillup

技術ブログ

プロジェクト管理

エンジニアの評価指標の策定について

投稿日:2022年9月24日 更新日:

営業の方であれば、月間の売上以外に新規の見込み数や、見込み客でも確度別の分類数など様々な指標で評価されることが一般的だと思います。

これらは「結果」に対する指標なのですが、それ以外でも見込み客に対する接触数など「行動」に対する指標なども定量的評価されることが一般的ではないでしょうか。

エンジニアの場合、スキルといった見に見えるものはあるのですが(これも限界はありますが・・・)、日々の業務での「結果」だったり「行動」だったりを評価する必要があると思っております。

ウォーターフォール的な現場ですと、ガントチャートが結果としてそうなったりするのですが、どちらかというと「成果物に対しての進捗の把握」が目的のため、個人の行動や結果の評価などを目的とした場合には別のものが必要になるのかなと思っております。

そういった定量評価をしている現場で仕事はしたことがないのですが、あったとしたら指標はどうあるべきか、どのような指標が良いかを考えてみました。

評価指標の策定

業績評価の基準としては以下のものが大事かなと思っております。

具体性

  • はっきりとした誰にでもわかる指標か
  • 目に見える成果物(資料やソース)が出せるものか

定量性

  • 数値化できるものか
  • 客観的なものかどうか

コントロール性

  • 達成可能かのニュアンスも一部含む
  • 自分自身でコントロールが可能か(NG例としては営業における売上など)

公平性

  • メンバーが納得できる指標か
  • 努力が反映されやすいものか

妥当性

  • 業務量の評価指標として適切か

参考リンク

似たような考え方のリンクがありましたのでのせておきます。

SMARTの法則とは? 目標設定の重要性、目標の立て方、具体例について

具体的な評価指標

現段階で自分が経験したもので評価指標として使えそうなものをあげてみました。

タスク数(タスク管理ツールのチケット数)

RedmineやBacklog、GitHub(issues)などのタスクをどのくらいこなしたか、ステータスが未解決→進行中→解決など遷移していきますので、これらの移り変わりなど(GitHub Actionsなどだと綺麗にグラフ化されています。)

メリット
  • ソース以外のタスクに対応できる
  • やりとりの経緯なども追える
デメリット
  • 人によってタスクの粒度が異なるのでタスクの精査が必要(テンプレートをある程度フォーマット化すればいいかも)

コミット数

Gitのコミット数です。

メリット
  • 集計が容易
  • 業務の評価量としては妥当性が高い
デメリット
  • プログラム変更以外のタスク(Excelを用いたシュミレーションなど)の測定ができない
  • コミットの粒度が人によって違うので、コミット単位に関しての精査がないと不平等な指標になってしまう。

Pull Request

コミットと近いですが、Pull Request数など。

メリット
  • 集計が容易
  • 妥当性が高い
  • レビュー時に他人のチェックが入り、ファイル数や差分などもわかるので、粒度に関する問題をある程度解決できる
デメリット
  • プログラム変更以外のタスク(Excelを用いたシュミレーションなど)の測定ができない

想定できる問題点と対策

指標の運用問題

  • 指標として適切か否か
  • 運用が形骸化しないか
  • 集計コストが高すぎないか
    →いきなり本格運用せず、実験段階で運用して、定例会議などで妥当性が見えそうな段階で本運用に載せるなど。

メンバーからの反発

運用コスト上の問題
→このための仕事が増えないように測定行為自体を軽量化する必要がある。

管理されたくないなど
→管理度が高くない現場だとストレートにこういった発言をするメンバーもいます。特に古くからいて文化に慣れてしまっているメンバーだと難しいかもしれないです・・別のポジションに入ってもらうか、それでも改善されない場合は離脱してもらうしかない・・ですね。

モラルハザード

わざとPRを水増しするなど、評価のための仕事を作成されないか
→PRのテンプレートを作り基準を設ける、最低ファイル数や最低の差分などをあらかじめ告知しておく(評価指標に対して普段からレビューや精査がされているものだと望ましい)

-プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

コードレビュー時のポイント

コードレビュー(仕様的な点ではなくて規約的なところのチェック)などで気をつけることなど。 ポイントとしては検知ツールで確認するコストを減らすことが一番大事(カスタマイズの方法について調べておく)、ある …

no image

設計業務での改善点など

比較的大規模なプロジェクトの設計段階で思ったことなど。会議など頻繁に開かれると思いますが、聞いているだけだったり、各人が色々なことを喋って内容がまとまっていなかったり・・結局何をやりたいかわからなくな …

no image

チーム内の行動変容(定着する、しない仕組みづくりについて)

学習塾時代からそうだったのですが、チーム内で新しいとりくみなどを始めてもなかなか定着せずに忘れ去られてしまう仕組みものというのがいろいろありました。 以下で書きましたね・・ 文化づくりについて(チーム …

no image

自動テストをやる上で今まで障害だったこと

自動テストについて、考え方自体は5年以上前から知っていましたが、プロジェクトで実際に使われているのを見たのは今年4月になってからでした・・・ 自動テスト完備なんて昔は夢物語だと思ってたんですけどね・・ …

no image

テスト分類について

一般的なテスト工程での分類や個人的に大事だと思うこと Contents1 全プロセス共通1.1 テストデータ作成バッチ1.2 ローカル、開発、ステージング、本番の分岐2 PT(プログラムテスト)、単体 …

アーカイブ