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 定型的なものはチェックリストを …

no image

CI/CDに関する取り組み

CI/CDに関して知識としては5年以上昔から持ってましたが、実際にプロジェクトの中に取り組むことができるようになったのはつい最近なので、取り込みが現実的なものに関してどのように取り組んでいくかといった …

no image

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

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

no image

業務フローの分解について

上流工程を担当するようになり、プロジェクトマネジメントや、要件定義、業務フロー分解などについて勉強しておいたほうがいいなーと思い、最近では読書をしております。 本日読んでわかりやすかった本は「はじめよ …

no image

ファジープロジェクト対策 その1

5月ぐらいから着手していたプロジェクト(顧客管理ソフト)が終焉を迎え、検証段階に入ったので、記して置きたいことなど。 数ヶ月程度ですが、自分が携わったプロジェクトの中では過去最大クラスのものでした。 …

アーカイブ