ニューノーマル時代のエンジニアの評価とは？

Withコロナの時代が続くいま、多くのIT企業ではエンジニアのリモートワークを推奨しています。
第三回目の今回は、エンジニア個々がそれぞれ遠隔で作業することが前提となる開発プロジェクトにおいて発生した変化と、付随して見えてきた課題を整理し、今後のエンジニアの適正な評価とはどのようなものか、考察します。

■コロナ禍以前の出社型のエンジニアの評価とは

IT企業を中心にした雇用においては、日本でもジョブ型雇用が進みつつありますが、それでも多くの会社がメンバーシップ型雇用であるのが現状です。そのため、開発プロジェクトの多くが、全員が同じ場所で業務を行う「集合型」の形式を取っていたことでしょう。そのような状況で、今までエンジニアの評価はどのように行われていたのでしょうか。受託業務がメインなのか、自社サービス開発なのか、など会社の業務形態によって前提が異なりますが、下記のように多様な評価軸が存在しています。

・携わったプロジェクトがどれだけ会社の売り上げに寄与したかを評価
・「新しい技術」を積極的に用いて開発し、会社全体の知見の拡大に寄与したか
・会社として重要度の高いプロジェクトにどれだけ関わったか
・OJTなど新人/後輩の育成にどれだけ関わったか
・マネジメント層による投票制度により評価を決定

など

■リモートワークにより必要性が増したパフォーマンスの可視化視点

今までの評価制度では、その切り口は違えども、「年功序列」を前提とし、「どれだけ会社に寄与したか」という比較的マクロな視点で上司が評価する、という形でした。
また、半期、または四半期毎の振り返り、という会社的な決算の区切りの影響もあり、社員の評価というのは、中期的なスパンで行われることが通常だったと思われます。
査定という意味では、このマクロ的な中期的評価が無くなることは無いでしょう。しかしリモートワークへの移行により、ミクロ的な評価視点も発生しています。
遠隔で開発を行う分、どうしても業務進捗の確認・把握が個人単位になったことで、個々の作業者の短期的なパフォーマンスに注目がいくようになりました。つまり、今まではチームとして、そしてプロジェクト視点での進捗だったものが、

・この１日または１週間で
・誰が
・どのくらいの作業を行なって
・どのような機能を実装したか

という、個人の動きについて、把握する必要性が発生しました。
今までもコードレビューなどで、個々のエンジニアのパフォーマンスを把握できる状況はありました。誰がどのくらいの業務をどのくらいのレベル/精度で行なったかを、見ていなかった訳ではありませんが、リモートワークによって、より一層、その定量的なパフォーマンスに「目がいくようになった」というのが適切かもしれません。

リモートワークにおけるパフォーマンスを評価する視点では、どうしても数値として現れる「成果」で判断する、という風潮になるのも自然です。ではその数値を何に設定すべきなのか、という評価に対する新たな議題が発生します。

定量的な評価の未来について

定量的な評価への急激なシフトは、行きすぎた成果主義につながる懸念と、その定量的な評価が果たして本当に適切な評価なのか、という問題がつきまといます。
単に「コードの行数」のみで判断するのが適切とは考えられません。では、どのような評価指標を持つことが、今後のニューノーマル時代に則しているのでしょうか。
今まで多くの日本の企業が行なってこなかった定量的な評価をどのように取り入れたら良いのか、その方法論を考えてみたいと思います。

「コードの行数」は一つの絶対的な指標のように思えますが、多ければ良いということでもありません。本来は、目的の機能が実装できるのであれば、行数の少ないシンプルな書き方を取る方が望ましいのですが、評価指標になることで、あえて行数の多くなる記述方法を取るようなケースも出てきてしまうかもしれません。
できるだけ数値的な指標に結びつくようにすることを前提に、多角的な評価方法を取る必要がありますが、その指標のルールメイキングは非常に難しい行為です。そこで今後は、何かしらのツールを活用していくことが有用だと考えられます。
単なる勤怠管理の領域を超えて、エンジニア個々人/チーム内におけるパフォーマンスの可視化について、新たな可能性を持ったサービスが出現し始めています。その理念や機能から、今後の評価のあり方について考えてみましょう。

【git logの活用】
git logは本来的には、チーム間を中心としたソースコードの品質管理を目的としたシステムで特別新しいものではありませんが、活用方法によってはパフォーマンスの把握にも役立つ可能性があります。
各フェーズの活動量、コミュニケーション量の差異、OSS活動の評価などを解析し、
下記のような定量的な情報を把握することができます。

・イシュー増加率
イシュー増加率は課題や議題を新たに提起した割合ですが、正常に動作するのが当たり前のシステム構築において、問題や議題を新たに発見できる力は、その後のバグや不具合を未然に防げるという意味でとても評価するに値する能力です。

・プルリクエスト増加率
プルリクエストは、自分の書いたコードに対してレビューを求めることを指します。第三者からのレビューをしっかり求める行為そのものを管理することは非常に重要であり、クライアントへの納品物の品質担保にも繋がりますので、評価する指標にしている会社も少なくありません。

・レビュー対応率/プルリクエストクローズ増減率
レビューからプルリクエストを完了させるまでをしっかり管理することで、品質担保やチーム内での取り組みに対しての評価に繋がります。ソースコードを人より多く書いたことや、機能実装をすること自体ももちろん評価に値しますが、その裏側で、しっかりと品質担保やチーム内でのプロジェクトが円滑に進行するように取り組む行為も評価しなければいけない指標となってきています。

これらの数値を見ていくことにより、プロジェクトメンバーの誰がいつ、ソースコードやファイルのどの部分をどう変更・追加したのかや、プロジェクトに対してどのように寄与したかが可視化されます。
しかし、その数値をいかに個人に対する適切な評価に繋げるのか、そのアルゴリズムは評価者の裁量であるため、慎重な判断が必要です。

【Pinpoint】https://pinpoint.com/

Pinpointは、昨年1,350万ドルを調達したことを発表したことで注目を集めた、機械学習を用いた「開発チームのパフォーマンス分析ツール」です。日本語でのサービスサイトが無いこともあり、詳細な機能はまだ未知数ですが、スケジュールや進捗に関するフィードバック（例えばbacklogの変更履歴について、目標値から何パーセント更新できたか）やエンジニアの稼働量や負荷を計測し、各エンジニアが最適に作業を行えているか、チーム全体のバランスを取れてプロジェクト進行ができているかを把握できるようです。
各数値をどのように評価に結びつけるのかは、リモート開発での評価における一つの課題ですが、これをAIにより導き出す動きは、今後のスタンダードになっていく可能性がありますので、Pinpointに限らず、このようなパフォーマンス分析ツールが台頭してくるかもしれません。

■まとめ

新型コロナウイルスの感染拡大により新たな時代に突入し、全ての業種で働き方や評価に対する考え方のシフトが余儀なくされたことは間違いありません。上記で挙げたようなパフォーマンス把握ツールの活用はスタンダードになっていく可能性のある反面、今までの定性的な評価軸をどのように反映していくのか、会社やマネージャーなど、評価を行う立場にはそのハイブリッドな方法を模索することが求められるでしょう。また、個々のエンジニアにとっては、自身に対する評価がどのような形で設定されるのかを考慮し、今後の働き方を見直す必要があると考えられます。