チームメンバーに喜ばれる評価測定について考える

はじめに

誰からも喜ばれる、そんなパフォーマンスの測定指標はあるのでしょうか。

残念ながら、完璧な指標は存在しないかもしれません。

• 定量的指標だけでは、数値化できない貢献が見えなくなる
• 定性的評価だけでは、説明責任を果たせない
• 一方に偏ると、必ず誰かが不満を持つ

しかし、定量的指標と定性的評価を適切に組み合わせることで、多くの人に納得してもらえる評価方法を実現できるのではないでしょうか。

本記事では、AさんとBさんという2人のロールモデルを通じて、この問いの答えを探っていきます。

今回の登場人物

本記事では、エンジニアの評価方法を考える上で、2人のロールモデルを想定します。

敏腕エンジニアのAさん

Aさんは、いわゆる敏腕エンジニアです。

社内外から技術力が高いと評価され、外部のカンファレンスにも登壇経験があり、積極的に技術的な知見を深める姿勢があります。結果としてチームメンバーが解決できない難しい実装を解決し、チームに貢献します。

一方、内向的な側面があり、会議のファシリテーションやチームメンバーの教育などは、本人も向かないと自負しているため、消極的です。

チームクリエイターのBさん

Bさんは、チームメンバーの架け橋となるような、いわゆる「チームクリエイター」です。

チームメンバーの相談に乗ったり、まめにドキュメントの更新をしたりと、チームがより良い方向に進むための方法を常に考えています。そのため、チームメンバーから常に頼られ、時には開発の時間を使って、メンバーのサポートにあたることもあります。

一方、技術力は普通で、Aさんより多くのタスクを一定期間でこなすことや、技術的な難題を解決することはできません。

以降はお二人を例に、定量的指標、定性的指標の二つの軸でパフォーマンスを評価していきたいと思います。

今回はわかりやすいように、両極端にいる架空のお二人を例示しました。

定量的な指標で評価する

定量的な指標とは、どのような指標でしょうか。

様々な指標の出し方があるかと思いますが、Googleで提唱されているGSMフレームワークを今回は例として取り上げたいと思います。

書籍『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』(出典１)には以下のように記載があります。

ソフトウェアプロセスを計測すると決めた後には、どのメトリクスを利用するか決定する必要がある。コード行数（LOC:line of code）が役に立たないのは明白だろうが、実際はどのようにしてエンジニアリング生産性を計測するのだろうか。
Googleでは、メトリクス作成の指針としてGSM （Goals/Signals/Metrics：ゴール／シグナル／メトリクス）フレームワークを用いている。

• ゴールは、望ましい最終結果である。ゴールは、ハイレベルでの理解が望ましいとの見地からこのような言葉で表されており、特定の計測方法への参照を含むべきではない。
• シグナル（signal：信号、合図）は、最終的な結果を達成したことを知る方法である。シグナルは我々が計測を望むものだが、それ自体は計測できないかもしれない。
• メトリクスは、シグナルの代用品である。メトリクスは実際に計測可能なものだ。メトリクスは理想的な計測手段でないかもしれないが、それに十分近いと信じられるものである。

引用元: 出典1

こちらのフレームワークをもとに、お二方のパフォーマンスを定量的に見るというGOALを掲げ、以下の軸で定量的に評価してみます。

シグナル	メトリクス	Aさんの結果	Bさんの結果
開発タスクを効率的に完了している	PRスループット（月間マージ数）	15件/月	8件/月
コードの品質を保ちながら開発している	コードレビューコメント件数（月間平均）	5件/月	25件/月
ビジネス価値を継続的に提供している	デプロイ頻度（月間）	12回/月	6回/月
変更を迅速に本番環境に反映できている	リードタイム（PR作成からマージまで）	平均1.5日	平均3日
チーム全体の開発速度に貢献している	チーム全体のPRスループットへの影響	+20%	+5%

興味深いことに、Bさんが大事にしてきたチームワークを高めるための取り組みを評価するメトリクスは、一つも含まれていません。

Bさんを評価するために、半ば無理やり、以下のようなメトリクスを追加することもできるでしょう。

シグナル	メトリクス	Bさんの結果	Aさんの結果
チームメンバーのサポートを積極的に行っている	相談対応回数（月間）	30回/月	5回/月
知識共有に貢献している	ドキュメント更新回数（月間）	20回/月	3回/月
チーム内のコミュニケーションを促進している	Slackメッセージ数（月間）	500件/月	100件/月
メンタリングに時間を割いている	メンタリング時間（月間）	15時間/月	2時間/月

ところが、Bさんが掲げるゴールはチームワークを向上することであって、回数という定量的な数値を追っているわけではありません。メンバーに対する細かいメンタリングや、Slack上での一文一文に気を使いメンバーに送るメッセージの質が評価されることこそが本来求められることです。

そのため、この場合には、Bさんのパフォーマンスは定量的な指標ではなく、定性的な指標で評価する必要があります。

定性的な指標で評価する

定性的な指標とは、Bさんの定量的な指標では評価できないパフォーマンスを評価するための指標です。

より具体的に、書籍*『エンジニアリングマネージャーのしごと―チームが必要とするマネージャーになる方法』* に以下のような記載がありました。

• 個人の技術スキルレベルはどれくらいか？大きくて曖昧で技術的に難しい問題を解決するコードを作成できるか？問題を分割するのに助けが必要だが、分解した問題は自分だけで実装できるか？
• チーム全体としてのスキルをどう向上できるか？会話したり、やってみせたり、一緒にやったりしながら、周りの人のスキルを向上できる辛抱強い熟練したメンターか？
• チームに良い影響を与えているか？楽観的でチームを鼓舞し、模範となっているか？他の人が同じようにやるようになっているか？
• 開発しているソフトウェアの全体像、会社のニーズを理解しているか？

引用元: 出典2

1については、定量的な評価に該当しますが、2以降については、「チーム全体へいい影響を与えられたか」や「メンバーにとって模範となっているか」など、数値としては表現が難しい、チームへの影響度についての評価指標であることがわかります。

具体的な手法としては、以下のような方法がありますが、定量的な指標と比較して、どの指標も一貫して、Bさんのパフォーマンスを正当に評価できる可能性を秘めたものであると言えそうです。

• 360度評価（多面評価）: 同僚、後輩、上司など複数の視点からフィードバックを得る方法。実際の働き方や協調性を多角的に評価できます。(liskul.com)

• 1on1面談（自己評価と面談の組み合わせ）: 定期的な自己評価と、それに基づく1on1面談を組み合わせた手法。自身の強みや課題を言語化し、成長を促進します。(liskul.com)

• コンピテンシー評価: 職種ごとに求められる行動特性を明文化し、その実践度を基準に評価する方法。「自発的に取り組む姿勢」や「後輩を支援する能力」などが評価項目になります。(liskul.com)

• ピアレビュー: チームメンバー・同僚から率直な意見を受ける、メンバー相互のフィードバック手法。気付けない改善点を発見し、チーム全体の成長を促します。(sejuku.net)

• プロジェクト振り返り（レトロスペクティブ）: プロジェクト完了時に、技術的な貢献だけでなく、チームへの貢献も振り返る手法。チームの雰囲気や協働の質など、数値化できない側面を評価できます。

私が経験した現場では、360度評価ではなく、マネージャー、リーダー以上の役職の方の評価がほとんどでした。そのため、チームメンバーレベルで感謝されていても、最終的な評価には反映されなかったことが幾度かありました。確かに、チームメンバー全員がメンバーそれぞれに対して、フィードバックをするのは大変だと思いますが、リーダー意識の醸成という観点でも、決して無駄な時間にはならないと個人的には感じています。

まとめ: 定量的かつ定性的な評価

改めて、AさんとBさんの評価を通じて、以下がわかりました。

• Aさん: 定量的指標で優秀な成果を出し、説明責任を果たすことに貢献
• Bさん: 定性的評価で真の価値が認められ、チームの長期的な成功に不可欠

「定量的指標と定性的評価を適切に組み合わせる」

これこそが、エンジニアの多様な価値を認め、説明責任も果たせる評価方法だと感じます。

私自身も、Aさんのような方には、複雑なプロジェクトにおけるバグが起きないような開発の段取りを教えていただいたり、Bさんのような方には、チームでコミュニケーションがしやすくしてくださったおかげで、発言がしやすくなったりと、それぞれ違った観点で助けられました。

また、サッカーにおいても、点をとる役割のストライカー（Aさん）だけではなく、守りを固めるディフェンダー（Bさん）と、様々なポジションがあり、それぞれが重要な役割を果たしています。ストライカーは得点数という数値で評価されやすい一方、ディフェンダーの貢献は数値では測りにくいものの、チームの勝利には欠かせません。

そのため、現場の声に耳を傾け、寄り添いながら、指標を使うことが重要だと感じました。

正解はありませんが、AさんとBさんの両方の価値を認められる組織文化を築くことが、長期的な成功につながるのではないでしょうか。

出典

1. 『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』(Titus Winters、Tom Manshreck、Hyrum Wright著, オライリージャパン 2021年11月, p147-159)

2. 『エンジニアリングマネージャーのしごと―チームが必要とするマネージャーになる方法』(James Stanier　著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、竹葉 美沙　訳 2022年8月)