チーム内のエンジニアを評価する
エンジニアの評価は一言で言ってしまうと非常に難しいものである。ひとえにソフトウェアエンジニアと言っても、ウォーターフォールで開発をし続けていたSIerの中のプログラマーと、ベンチャー企業でスクラムをぶん回してシングルページアプリケーションを作っているプログラマーとでは、持っている技術セットもマインドセットも大きく違う。だが、2017年現在はどこもかしこもソフトウェアエンジニアが枯渇して、有象無象の中から採用をしてプロジェクトを回す必要がある。プロジェクトに採用している言語を、多少齧ったことがある、というだけで参画してくるエンジニアも珍しくはない。
そんな彼らが果たして活躍するだろうか？それは実のところ誰にもわからない。経歴書に踊っている技術も、実際のところは全く使い物にならない（そしてそれは改善されない）こともあるし、力なく「頑張ってみます」と言った若者がメキメキと頭角を表すことも有る。そしてその生産性は10倍以上差がついてしまう。そういうところで戦っているしソフトウェアエンジニアを正当に評価するのは至難の業だ。（生産性が１０倍の彼に１０倍の給料を払えるところは別だが）
実際のところ、エンジニア自身も評価をされたがっているのだから、マネージャーはその評価軸に乗ってしまうのが良いだろう。もちろんある程度の指針はあるべきで、たとえば新卒２年目は技術の習得を目指し、１０年選手はアーキテクト責任者かリーダーかを選ばせるのは自然の流れだろう。その上で、エンジニア自身に「自分はどういう形で仕事をして、所属する企業に貢献するか」を考えさせると良い。エンジニアは自分のなりたい姿を想像して、どのように仕事がしたい、と言ってくるはずだ。そうなればしめたもので、あとは「ある程度の指針」に添って、彼らにミッションと言うかたちで目標に整理させる。たとえば、新卒２年目は「１つの言語を習得し、品質に貢献」程度で良いだろうし、１０年選手は「新技術領域の習得し、習得した技術のアーキテクチャ担当をの全う」といった形になるだろう。
あとはマネージャーが、ミッション難易度の高い低いをチーム全体を見ながら調整すれば良い。そしてそのミッションが達成できれば評価は並、それ以上はハイ達成として評価をあげてやる。そうすることで、エンジニア側から見れば最終的にミッションをコミットすることでチーム内での活動を正当に評価される、と感じられるようになるだろう。
