キャリア

エンジニアの生産性を可視化する方法について考えてみる

どうも、Kohei(@koheinishino_)です。

自分自身3社の会社でエンジニアとして働いてきましたが、評価ってそれぞれの会社でマチマチだったなと思い、「エンジニアの評価って難しいのでは?」と考えるようになりました。定性面ではなく特に定量面の部分です。

もちろん定性的な評価も必要なので、コミュニケーションが円滑であるとか勤務態度が良好とかは当然評価されるべきとは思いますが、エンジニアの定量的な評価ってけっこう難しいなと…。

となった場合に、自分の中で「生産性を見える化すれば良い」という結論に至りました。

ビジネスサイドの依頼をシステムに反映する上で、短時間でスピーディに変更を加えられるエンジニアは評価できると自分は考えています。バグは出さない、保守性の高いコードを書くことはもちろん大前提です。

というわけで、本記事ではタイトルの通り「エンジニアの生産性を可視化する方法」について自分なりに考えをまとめて、自分が現在所属している会社ではこうやったほうが見える化できそうだ、という意見を提示してみようと思います。

  • エンジニアの生産性を可視化する方法が思いつかない
  • 何が適切な方法かわからない
  • 評価シートが定量的になっていない

とお悩みのエンジニアやマネージャーの参考になれば幸いです。

執筆にあたり、下記の記事が大変参考になりました。

エンジニアの生産性の可視化はなぜ難しいのか?

まずはエンジニアの生産性を可視化する方法について考える前に、エンジニアの生産性の可視化はなぜ難しいのか?について考えてみたいと思います。

※ 以下「課題≒タスク」と表現します。(ex.「 A画面に検索機能を実装する」など)

1. コードの変更量や工数が必ずしも成果に直結しないため

まず、エンジニアのアウトプットとして代表的なものがコードです。コードが変わることで機能が変わり、それによってビジネスサイドに好影響を与えるのがエンジニアの主な仕事です。

このコードの変更量やプルリクエスト数はGitHub等から算出できますし、それにかかった時間もBacklog等のツールである程度計測は可能ですがコードの変更量や工数は成果には必ずしも直結しません。

例えば、1行変更しただけでレスポンス速度が大いに改善してシステムが使いやすくなったりだとか、逆に大量のコードを書いて変更を加えたものの後任のエンジニアが保守しにくいコードとなってしまい将来的に工数が増えてしまったりすることも考えられます。

コードの変更量や工数が必ずしも成果に直結しないため、エンジニアの仕事は生産性として可視化しにくいと考えられます。

2. 内容が全く同じ課題はほとんど存在しないため

生産性を算出する上でキーとなるのが前回との差分です。例えば、前回2時間かかっていた作業が1時間でできるようになった場合、生産性が2倍になったと言えそうです。

しかし、エンジニアの仕事において内容が同じ課題はほとんど存在しません。

例えば検索機能をシステムAに実装する課題があって2時間かかったとします。次に同じ検索機能をシステムBに実装する課題に2時間かかったとしても、生産性が変わっていないとは言えません。実工数が同じでもシステムAとシステムBの既存のコードの状態が違うことも考慮しなければいけないからです。

この場合は「Bの方が導入しづらいコードだったから時間がかかった」と推測できるため、検索機能単体の実装時間で考慮すべきとも言えますが、前回との差分が定量的に算出しにくいため、本当に生産性が上がったのかと言われると少しグレーな部分が残りそうです。

3. 担当分野によって評価軸が異なるため

大企業となれば特にそうだとは思いますが、主にフロントエンド、バックエンド、インフラ、などで各エンジニアの担当分野が別れており、担当分野それぞれで評価軸は異なるものであるべきと考えられます。

例えばフロントエンドやバックエンドはコードの変更量がインフラに比べて多いですが、インフラは一度作ってしまえばそこから大きな変更はあまり発生しません。

そのため全エンジニアの評価軸にコードの変更量を入れてしまうとインフラエンジニアの評価が相対的に低くなってしまいます。この場合、インフラエンジニアの評価は例えばアラートの作成件数やセキュリティインシデントの発生件数(少ないほうが良い)などであるべきでしょう。

担当分野によって評価軸が異なるため、同じ評価軸で「フロントエンド担当のAさんよりインフラ担当のBさんのほうが生産性が高い」とは必ずしも断言できません。

エンジニアの生産性の可視化する方法

ここまでエンジニアの生産性の可視化はなぜ難しいのか?について考えてみました。

ここからは上記の問題点の対策を交えながら、エンジニアの生産性を可視化する具体的な方法について考えてみたいと思います。

例として、「システムAに検索機能を実装する」というシチュエーションで考えてみたいと思います。

1. 課題の規模感や難易度を記載する

まずは課題の規模感や難易度を考えます。必要であれば優先度等も考慮して良いと思います。

自分にとってその課題がどのくらいのレベル感なのか、重要度はどのくらいなのか、工数はどれくらいかかりそうなのか等を3段階や5段階くらいで重み付けすることで、定性的な感覚から定量的な指標に落とし込み、各課題を比較できるようになります。

例えば検索機能の実装を3段階で重み付けする場合、下記のようなイメージです。

  • 比較的に小さな機能のため課題の規模感は1
  • 未経験部分の機能要件のため難易度は2

また、同じ課題であっても経験値の異なるAさんとBさんで課題の成果を区別できるようになります。

2. 類似課題を割り出す

1と似ている部分はありますが、類似課題を探すことで経験のある課題かどうかを判断します。

「内容が全く同じ課題はほとんど存在しない」と前述しましたが、例えば「作業の20%は未経験だが80%は以前に経験がある。」という課題は存在する可能性が高そうです。類似課題を探し一部経験のあるゾーンの工数だけでも比較することで成長をアピールできます。

簡易的な検索機能の実装で考えてみると、下記のように予想できます。

  • 作業の80%はシステムBでの実装の知見があるため1時間くらいかかる見込み。
  • 残りの20%は2時間くらいかかる見込み。
  • おそらく計3時間ほどの工数となる。

もし仮に課題に4時間かかったとしても、下記のような振り返りができるようになります。

  • 作業の20%の部分は3時間30分くらいかかってしまい見積もりが甘かった。
  • しかし、80%の部分は30分で完了できたため、以前に実装したシステムBのノウハウを活かせられた。

3. 課題の成果とプロセスを補足する

この項は定性面が比較的強いですが、完了した課題の成果とプロセスについて補足します。

具体的に自分なりに工夫したポイントや動機を補足することで、よく話題にあがることの多いエンジニアとしての自走力をアピールできます。

簡易的な検索機能の実装で考えてみると、下記のようなイメージです。

  • システムBで似たような検索機能を実装していたが自動テストがなかったため、工数的に影響がない範囲でシステムAとBに検索機能の自動テストを導入した。
  • システムAは触ったことがなかったため、システムAに詳しい〇〇さんに1時間ほど仕様説明の時間を設けていただいたことで、スムーズに実装に着手できた。

まとめ:必ず上長と部下で評価方法の検討を!

本記事ではエンジニアの生産性を可視化する方法についてまとめてみました。

エンジニアの生産性を可視化する方法
  1. 課題の規模感や難易度を記載する
  2. 類似課題を割り出す
  3. 課題の成果とプロセスを補足する

現在所属している会社の定量的な評価において評価軸がぼんやりしている場合は、今回紹介した生産性であったりその他の評価軸を上長に提案してみてください。上長にとっても評価軸が定まり、自分にとっても何を頑張るべきかが明確になるのでWin-Winになると思います。

会社の評価のときだけではなく転職活動の際も流用できる方法だと思うので、必要な部分はマスクして自身のSNSに最新の状態を掲載しておくのが良さそうです。

ABOUT ME
Kohei Nishino
Webエンジニア、ブロガーです。新卒未経験で開発エンジニアとして大手SIerに入社し2年で退職。その後、派遣と業務委託を半年ほど経て都内のWeb系企業にエンジニアとして転職。しばらくは本業コミットのため技術的な話が多めです。Ruby on Rails / React.js / AWS