【保存版】プログラマ・エンジニアを評価する方法

掲題に関する問いを Facebook に投げたところ、素晴らしい回答がたくさん集まったので、この知をより広く知ってもらうため、そして後世に残すために、内容をまとめておく。 

【問い】 プログラマ・エンジニアを評価する方法

先日「自分が正当に評価されていないと嘆く君へ」という、組織における人事評価に関するエントリを書いたせいで、読者の方からこんな相談が寄せられました。
皆さまの忌憚なきご意見・知見をお寄せいただきたく！

<相談内容>

例えばゲームやアプリの開発って、結果(アウトプット)が現れるまで数年ぐらいかかったりします。
その数年間の間に、真剣に作業に取り組む人もいれば、適当にサボる人など、色々差が出ると思うのですが、どうすればその差を、数年ではなくより(なるべく)短いサイクルで可視化できるものでしょうか？

評価の制度や指標をどのように設計すればいいか、あるいは、どのような設計方法があるのか、アドバイスいただけると幸いです。

(補足：相談者は、名古屋を拠点とする株式会社フリースタイル (http://freestyles.jp/) に勤めており、経営レイヤーから「エンジニアの評価制度を作る」というミッションを与えられた、エンジニア未経験者 - ご本人および経営陣から OK 出たので会社名追記しましたw)

集まった回答のまとめ

エンジニア組織にいる 3 つのジョブレイヤー

まず気をつけるべきことは、被評価者を「エンジニア」という 1 つのバケツにいっしょくたにせず、いくつかのレイヤーに分けること。つまり；

1. 設計図とスケジュールが与えられていて、その通りに作るのが仕事の人
2. ものを完成形まで作り上げることに責任を持つ人
3. ビジネス課題を解決する、事業ゴールを達成するのがミッションの人

の 3 つのパターンがあることを理解する。

これらの 3 つは、必ずしも 3 > 2 > 1 の順番に偉い / 給与が高い必要はない。

「3」が達成出来ていなくも「1」がズバ抜けていれば「1」で評価すべきだし、掛け算でさらに高い給与にすることも必要かもしれない。

人材マーケットとの需給バランスでもあるため、高度人材になればなるほど評価は市場に依存させれば良い、という考え方もある。

評価する順番としては、

• ビジネス課題から考えて解決できるレベルの人材に対しては「3」ベースで評価
• もし3が達成出来なかった場合、プロセスおよび職能としての「2」で評価
• そこでも評価しづらいエンジニアに対して「1」で評価する

という流れになる。

それぞれのレイヤーに対する評価方法

【3. ビジネス課題を解決する、事業ゴールを達成するのがミッションの人】はいわゆる KPI や KGI にコミットして貰って、そこで目標に対する達成度合いを計測する方法をとる。

あまりエンジニアかどうかは関係ない。

逆にこのレベルの人は、単に綺麗なコードをスケジュール通りに書ける、プロダクトを期限までに完成させられる、というだけでは評価されない。

それによって、会社や組織の定める事業ゴール・解決すべき課題を、達成できていないといけない。

定量的に評価できるので、ある意味では最も評価しやすいのがこのレイヤー。

【2. ものを完成形まで作り上げることに責任を持つ人】はアウトプットに対して評価する。

モノ自体を作る能力なので、QCD(※) のような一般的な SIer のノウハウで一定は観測可能。

(※ 「Quality (品質)」 「Cost (費用)」 「Delivery (納期)」 の頭文字を取った言葉で、主に製造業において設計・生産時に重視される3つの視点)

まず前提として、管理者が自分の裁量で、与えられたチーム・メンバーの実力で、アウトプットと開発スケジュールについてゴールを決めて関係者に共有・合意形成する。

(途中で大きな前提条件の変更があった場合は、計画をたてなおす)

その上で、できれば管理者として目標達成。

できなければ (自分がヘルプに入る、仕事を他の人に振り分ける、などで対応することが出来なかったということなので) 管理者のスキルが足りていないという評価になる。

管理者クラスにならないと成果物でのインセンティブは発生するべきではないという考えの人が多いようだ。

逆に、成果物でのインセンティブが欲しいのであれば、管理者になる (そのためのスキルを積む) ことが必要。

なおここでいう管理者とは、プログラマならプログラマの、グラフィックならグラフィックの責任者というイメージ。

他の職種の評価および業務の振り分けは難しい。

【1. 設計図とスケジュールが与えられていて、その通りに作るのが仕事の人】は "個の技術資産" に対する評価であり、「エンジニアの能力を評価する」と言ったときに恐らく多くの人が想起するであろうものがコレ。

ここは内容が厚いため、下記に別途章立てする。

"個の技術資産" に対する評価 - 誰が行うべきか

最も多く出た意見は「エンジニアの評価は、(優秀な) エンジニアが行うべき」というもの。

いくつかコメントを引用する。

• エンジニアは特に、同僚からの評価が一番正しい
• エンジニア未経験者がエンジニアを評価すると、だいたいエンジニアはどこかへ行く
• ソースコードのよしあしは偉い人にはわからないし、売上にも進捗にも関係ない

なので、単に「上の人」が評価するだけでなく、例えばカヤックの行なっている「360度評価 (https://at-jinji.jp/blog/14848/ )」がいいのではないかという意見も。

エンジニア相互での評価のランクが【Aさん > Bさん > Cさん】で、給与も【Aさん > Bさん > Cさん】となってさえいれば納得感がある、という意見もあった。

どうして「エンジニアの評価はエンジニアが行うべき」なのか

エンジニアの「技術力」と呼ばれるものは、2 つの要素にブレイクダウンできるという意見が複数の人から出た。それは何かと言うと；

• 他の人より仕事が早い 
• 他の人が出来ないことができる

である。

この掛け合わせで、面積的に評価する必要がある。

前者の「早く作れる能力」は、比較的、体感で計測可能。

なにしろ早いので笑。

後者は言い換えると「より難しい問題を解ける」能力で、これが特にエンジニア以外に計測が難しいポイント。

例えば；

• 3 年後にきっとこういう改修が必要だから、エンドポイントを作っておいこう
• 今はトラフィック少ないけど、1,000 倍になっても今書いているコードがボトルネックにならないように、ある程度高い処理性能が出ることを考えて実装しておこう

など、こういうことを考え予め実装できる能力が技術資産にあたる。

(もちろん、現在直面している難問を解ける、ということも含む)

こちらの方は「早さ」に比べて観測が極めて困難である。

なぜなら、初期に "未来を想定して" 実装されるものなので、アウトプット (完成物) やアウトカム (KPI/KGI) には現れないからである。

ゆえに、共に働くエンジニア以外には評価不能と言える。

具体的にどのように "個の技術資産" を評価するのか

①まずは、決められたスケジュールで、決められたものを作ることが出来たのかどうか。

その前提としては、上で出てきた「管理者」ロールの人が、誰に・何を・いつまでにやらないといけないのか、をきちんと定義できないといけない。

ちなみに欧米の会社だと、JD (Job Description = 職務記述書) や定期的 (半年とか四半期ごと) な目標設定で上記を明記し、 それを遂行できる人には決められた給料を払う、できなければクビ、という風になっている...っぽい。

たぶん。

たまたま自分が知ってる会社が "ちゃんと" 出来てるだけで、ほとんどの会社は実はグズグズなのかもしれないけど。笑

この評価は、ある意味では「進捗管理」とニアリーイコールになる。

「早さ」に対する評価はここに含まれる。

②次に、「スケジュール通りに決められたものを作った」とき、その中身を評価するプロセス。

中身とは具体例でいうと、 バグの少ない綺麗なコードを書けるとか、速く動くコードが書けるとか、ライブラリの使い方に精通しているとか、将来を見越して先に問題を潰しておけるかとか。

ちゃんと要求通りの味でチャーハンを作った 2 人のシェフがいたときに、こっちのシェフはニンジンの形を綺麗に揃えて切れてるねとか、完成した瞬間にすでにキッチンが片付いてるとか、翌日分の仕込みまで終わってるとか、そういったことかな。

客からは見えないし、「わかってる」シェフじゃないと良し悪しが判断できない。

「エンジニアの評価は、(優秀な) エンジニアが行うべき」というのは、エンジニアではない人、またはエンジニアとしてのレベルが高くない人には、この観点での評価ができないことが理由。

この観点での評価をどう行うかは、出ていた意見としては「数値化・制度化は困難」というもの。
まぁ確かに、決められたゴールを達成した上で、それプラスアルファの部分なので、定性的な評価にならざるを得ないという面はあるのかもしれない。

評価者となるのは、被評価者の管理者/上長など "上の人" が基本。
その人が日々の業務の中で、ソースコードをマージして読んでいれば、おのずとエンジニアのレベルは分かる、少なくとも複数いるエンジニアの相対的な評価は出来るはずだ、ということだ。

例えばお相撲さんが毎日稽古していて、誰が誰には勝てる・負けるというのは、稽古を毎日見ていれば自ずと解ってくるもの。
同じ組織で仕事していれば、相対的にだれが優秀かは解ってくるとのことだ。

この前提になっているのは、評価者がソースコードを見て、コードを書いた人のレベルを判断できる程度に十分優秀だ、ということ。
評価者は過去に、リードプログラマーとしてプロダクトをリリースまで持っていけた、など一定の実績がある必要がある。

なお、さらに 1 つ上のレイヤーの人になると、ソースコード読んでも分からない (あくまで管理職としてそのポジションにいる人であり、エンジニアとしての能力が高いからいるわけではないケース) こともあるので注意が必要。

インターネットサービス・プロダクトを開発するのは建築物を建てるのに似ていて、大工から電気工事から玉掛さんまで、いろんな能力を保有している人が必要になる。
なので、広く深く技術を理解して、評価できる人が 1 人でもいれば、評価としてrは安定する。それを CTO に求めているのが今の日本マーケットだと思うが、本質的には job description に分解して、情報工学上がりの人事部長がやることも可能。
今の日本では難しいかもしれないが - だそうな。 

評価者になれる人物が社内にいない場合は？

"個の技術資産" を評価出来ない組織、つまり、絶対的技術のトップがいない組織は、高電圧人材 (= 凄く難しいものをポンと解決できる人材) がいなくなる。
なので、常にアウトプットが出るわけではない (簡単な問題を解き続けることが不得意、飽きる) が、難問が発生した時に活躍する人材が欠乏する。

こういう組織は新規事業を作るのが遅かったり、トラフィックが突然増大した時にサーバーが落ちてどうしようもなかったり、といった事態が発生する。
また、そういう人材が評価されづらいので、その後も長きにわたってそういう人が集まりにくくなる。

以下は、上記の本論でどこに含めるべきか分からなかったが、トピックとして興味深かった点。

【オフトピその 1 - 日本と欧米の違い】

エンジニアの給料は欧米 (特に米国のテック系企業に顕著だと思う) のほうが日本よりも高い、特に優秀なエンジニアに対する払いは海の向こうのほうが随分高い、という議論がある。

この理由として、欧米では job description に書かれた業務が遂行出来なかったらクビ (契約解除) になることが前提だからこそ。
決められた仕事が出来ない人にまで給料を払う必要がないため、出来る人の給料が日本よりも相対的に高い (物価を考慮してもなお高い) のではないか、という議論があった。

そういう社会では、給料上げたければ、より給料の高い (仕事を出来るようになるか、スピード上げて仕事自体をたくさんやるかのどちらかしかない。

【オフトピその 2 - 正社員ではなく業務委託・契約社員】

より「出来る人に報いる」ため、日本でも欧米のような「出来なかったら去る」という状況を作り出すのは、雇用形態を正社員にすると難しい。
(解雇の条件が厳しいため)

むしろ、エンジニアを全員個人事業主の常駐委託契約にして、個別に条件交渉し、働き方も報酬も本人に決めさせる (合意の条件のもとで働いてもらう) という案も出た。
契約更新するかや、条件変更するかどうかは、都度判断というもの。

そのような世界線では、企業間での人材確保競争がより激しくなるので、企業としては優秀な人材を抱え込むこと難易度が高くなる。
が、他の企業が正社員中心で必ずしも優秀でない人材も雇用している状況のなかで、自社だけがこのような仕組みを導入したら、プロフェッショナルが残りやすくなる (優秀な人材はそうじゃない人材と一緒に働くのを嫌うという側面や、単に優秀な人材により高い報酬を払うことが出来るようになるので、相対的に採用力が増すという側面など) かもしれない。

【オフトピその 3 - アウトプットに対する報酬】

アウトプットに対して評価されるべきなのは、管理職・リーダークラス以上だけだ、というのがこれまでの論旨だが、高いアウトプットが出たときにそれより下のレイヤーのメンバーに報いてはいけないという決まりはない。

ある若いスタートアップの founder は、正社員の給与に関しては、基本給とインセンティブ給を分けるべきだという持論を語ってくれた。
(業務委託の場合は、決められた成果を達成したら決められた報酬が支払われるという契約関係なので、最初からインセンティブ給込み = わりと高給)

基本給はやってくれた仕事に対してあげるもので、インセンティブ給は成功を分かち合うというイメージ。
頑張ったことと、プロジェクト自体が成功するかどうかは別という考え方であり、頑張ったことに対しては基本給、成功したことに対してはインセンティブ給で報いましょう、と。

ぼく個人としては、これはいくつかの面で有効だなと思った。

• 社内に「言われたことやってればいいんでしょ」というドライな雰囲気ではなく、「みんなで協力してプロジェクトを成功させようね」という一体感、協力し合おうという空気を醸成できる可能性がある
• エンジニアが組織に属している目的が、「与えられたミッションを遂行して、決められた報酬をもらう」 + 「仕事を通じでスキルを高める (そしてより報酬の高い仕事を得る)」 だけでなく、「プロジェクトを成功させる」になる
• それによって、エンジニアが自己と組織とをより同一視し、組織のゴールに対するコミットメントが深まったり、在籍期間が長くなったり (この組織が好きなんだ、この組織を成功させたいんだ、だからここにいるんだ) といった効果が期待できる (ような気がする)

また関連して、あるメガベンチャーの創業時からの CTO は、特に彼の新規事業チームに配属するエンジニアには全員「基本サービスがローンチして、利益出るまで据え置き」ベースで入ってもらっていると教えてくれた。
理由としては、"途中の評価は難しい" ことと、"評価プロセスが挟まることそのものがコストになってしまう" こと。
それよりは、2 年後成長してたらこのくらいの年収にはなってるよね、という年収をまず提示して頑張ってもらう方が良いかなと思っており、1 人 1 人とそういう話をして握っているとのこと。

(ただし、明らかに報酬が低いなと思ったメンバーは、途中で上げることもあるそうな)

この方法も、サービスを最低でも期待以上のクオリティでローンチさせ、成長させ、利益を出すことに対するメンバーのコミットメントを高めることができるという点がメリットになる。
また、スタートアップや新規事業など、全員がプロダクトの完成や成長にコミットすべきシーンでは、評価制度がどうとか報酬がどうとか議論するのに時間を使うのが勿体無いので、リソースを本来やるべきことにフォーカスさせるという利点もある。

一方で、想定通りにいかなかった場合 (サービスがリリースされなかった、リリースされたけどうまくいかず利益が出なかった、など) にどうするのかという問題がある。
また、口約束ベースだった場合、約束が果たされないとか、約束した相手が途中でいなくなってしまったりといったトラブルも考えられるので、よほど性善説にもとづいてやるか、よほど信頼のおける相手・組織でないと、安易に導入するのは難しいのではないか。

【オフトピその 4 - 評価その他】

某大企業歴戦のマネージャーからはこんな意見もあった。
"エンジニアに限らずだけど、1. 会社として定める「仕事に臨む姿勢」についてその人を周囲の人が評価する、2. その人が挙げた「成果・実績」をマネジメントが評価する、の2本柱でやってる。"

頑張ってやっていても、たまたま成果や実績につながらないときは確かにあるわけで、そのときにバサッとマイナス評価されてしまうと、確かに従業員としてはやる気なくしてしまう。
そんなときに「ちゃんと頑張ってたよね、見てたよ」と言われると救われるというのは納得できるし、そのときの評価者は (ともすると日々の仕事への取り組みまで細かく見てはいないかもしれない) 上長・管理者ではなく、周囲の人 (peer) だというのも納得感ある。

先日の自分の post 「自分が正当に評価されていないと嘆く君へ」でも、上の人が正しく自分を評価してくれることは期待するな！と断言したので、その主張にも合っていてちょっと自信がついたぜ。

最後に、エンジニア・マネジメントとしての大先輩 2 名からのメッセージを (若干編集して) お届けして、本 post を締めたいと思う。

- エースのエースたるゆえん - 

「ルーキーとエースを一緒くたにしたらあかん」
それなりの成績を長期間安定して続けてきたからこそのエースですから、かりにまぐれ当たりでルーキーが 20 勝してもエースと同じ年俸上げるわけにはいかないですよ。

ルーキーからエースになるまでには、それなりには年棒は上がっていることでしょう。
じぇどそこから先は、プロダクツによる成果が上がらないと評価されませんよ。
エースが 10 勝程度では評価されませんよと。

チームを勝たせてこそのエースです。

- エンジニアが正しく評価される組織作り、未だ道半ば -

若い業界ですし、現場上がりの管理職が増えるのはあと10年後くらいでしょうか。
先陣の皆様には頭が上がりませんが、後陣により良い道を残せるように頑張って参ります。

元スレ→ https://www.facebook.com/tatsuojapan/posts/10156073918866328  (ぼくのフレンド限定)

この記事が役に立った！という方は、よければ下記ボタンから投げ銭 (300円 | クレカ払い) をお願いします！ぼくのモチベーションが上がって、また良い記事を書くかもしれません！w
↓

Q