skillup

技術ブログ

プロジェクト管理

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

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

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

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

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

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

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

評価指標の策定

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

具体性

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

定量性

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

コントロール性

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

公平性

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

妥当性

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

参考リンク

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

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

具体的な評価指標

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

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

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

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

コミット数

Gitのコミット数です。

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

Pull Request

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

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

想定できる問題点と対策

指標の運用問題

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

メンバーからの反発

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

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

モラルハザード

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

-プロジェクト管理
-

執筆者:


comment

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

関連記事

no image

ディレクション時に重要な視点

ディレクション(ベンダーや内製時)時に留意するポイント Contents1 開発ルールの構築2 アサインと人材スクリーニング3 言葉の共通化(特にアウトプット)4 問題化のキャッチアップ5 リソースの …

no image

アジャイル開発について

エンジニアとして仕事をしてから7〜8年立ちましたが、その間9割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・ が、先日 …

no image

採用の重要性と一般的な採用の問題点について

私自身は現時点では経営者でも人事でもないのですが、学習塾運営スタッフ時代から講師の採用は少ししていたのと、以前の会社でも規模が小さいということもあり、多少関わらせていただきました。 そこで思ったことを …

no image

新しいプロジェクトに入った時にやること

新しいプロジェクトに入った時に最初にすべきことややっておくことなど Contents1 仕様理解編1.1 ユーザーの行動遷移の理解1.2 キー系のデータの理解1.3 データグルーピング1.4 サンプル …

no image

開発時最低限必要かつ有用なドキュメントに関して

ウォーターフォール型の開発をかれこれ1年近くやっております。 自分がやってきた仕事とすると別職種に近いようなイメージでしたが、得ることも多かったため、ここに記しておこうと思います。 以前書いたことの記 …

アーカイブ