エンジニアの評価にみんな悩んでいる？

「エンジニアの評価をどうすべきか？」という点に悩む企業は多いと思う。

今いる会社でももちろんそうだし、スタートアップの大きな経営上の論点なのではないかと思う。

エンジニアは日本企業の構造的に、企業内よりもシステム会社に多くいる。

エンジニアを内製化し、優秀なCTOあるいはCPOがいるというのが一般的になっているが、実現できている会社は先頭を走っている企業以外では少ないはず。

それに続きたい企業は多くあると思う。だから、先頭を走っている企業の事例や考え方を整理しておこうと思う。

個人的に特に共感したところを中心に整理をしていきたい。

みんな何に悩んでいるのか？

いろいろ世に出回っている記事をみた結果、ざっとだけど、次のような疑問が多かった。（報酬水準やキャリアパスまでは今回は触れない。）

・エンジニアに求める結果を定量化できるか？明確にできるか？

・結果のみを評価すべきか？技術力も評価すべきか？

・評価すべき技術力とは何か？

・エンジニアに特化した制度を作るべきか？

・どういう手順で評価を導入していけばよいか？

・（前提として）そもそもエンジニアをどうマネジメントすべきか？

・（前提として）エンジニアの組織はどうなっているか？

順に整理してみたい。

エンジニアに求める結果を定量化できるか？

どれだけ頑張っても、エンジニアに求めるパフォーマンスを定量化することは難しい、という立場が多い。

「長らくエンジニアのアウトプットを評価できる制度を作ってきたけど、技術力や生産性を定量化できるなんて幻想。」とクックパッドCTOが一刀両断していて気持ち良い。

定量化できないときの目標については、スケジュール基準（例:期末までに〇〇さんと合意形成する）や状態目標（例:XXの課題が解決されて〇〇部署とも合意形成できている)になる。

コミュニケーションの頻度・量で解決するしかない、というのが現実的な打ち手になっている。

・年2回の評価&フィードバックから毎月フィードバックへ変更
（クックパッド）

・年2回×90分　自分の技術力についてプレゼン&対話をする場をセット
（VOYAGE）

・OKRとバリューに基づく3か月に1度の評価+週1の1on1
（メルカリ）

各社とも「評価」のためというより、「結果をだすため&成長のため」のコミュニケーションという方向に向かっている気がする。

1点気になる論点としては、「エンジニアに定量的な数字意識を持たせなくてもよいのか？」というところでまだ世の中正解が見いだせていないということ。

少なくとも自分が所属するチームやもう1つ大きい単位での組織ゴールまでは腹落ちは必要かも。

（いらんよの立場）

（当然いるよ、の立場）

結果(成果)は明確にできないのか？

そんなことはない。ゴールイメージをすり合わせるということに向かい続けるというのがとても大事。

具体的には、ゴール達成にあたってポイントとなることはフロント/バック/保守/運用などで型化できそうな勘所はありそう。

結果のみを評価すべきか？技術力も評価すべきか？

結果だけで評価をすると、エンジニアに納得感が少ない、ということを多くの会社が感じているようだ。

経営的視点においても、短期的な結果に視点がむくと、中長期的に投資として重要な「技術力」を向上させる方向に向かわないいうことを危惧している企業も多い。

結果ではなく、「技術力」だけの目標設定をする、はてなのようなところも。

また、技術よりもプロダクトが大事という考えの会社でも、技術的なインプットは比較的工数かけて評価している。評価というよりも、みんなで育成していくという概念に近いかも。

そもそもエンジニアの技術力とは何か？

技術力の定義は、各社各様だが、よく見てみると共通しているところがありそう。

技術力もビジネスにどういうインパクトを与えているか？という観点からブレイクダウンされている印象。特に分かりやすかった2記事。

エンジニアだけの評価制度をつくるべきか？

エンジニアの組織をきちんと作ろうというときに、特にエンジニアは特殊だから、という議論があって、そこに特化した制度を創ろうという議論になるのではないだろうか？

ただ、結論としてはエンジニアだけ特別待遇しない。という企業が多そう。

経営観点では、全職種が当然ながらつながっている（例：前工程でデザイナーと、後工程でカスタマーサポートと）のであり、全体の生産性を向上するという観点で制度を作るべしと。

お友達の上場前後のITベンチャーの人事に聞いても、「エンジニアだけ等級や評価の仕組みを分けているということはない。」という会社がほとんど。

次の記事が特にわかりやすい。

評価制度はどういう手順で導入すべきか？

HRの打ち手は、特に日本においては一度実施すると変えられない、という風潮が長らく続いてきた。

「不利益変更」という従業員側を守る大義名分もあった。

しかし、最近はアジャイルHRの概念などもHarvard Business Reviewで特集されて一般的になってきている。

「課題のあるところから小さくスタートし、社内認知が上がった段階で、全社に展開するのがオススメ」とVoyageのCTOの人が言われていた点がとても腹落ち。

評価は事業責任者レベルの人たちが自分事にするのがとても大事。（先ほどのクックパッド、Voyage、メルカリ・・・の記事に記載）

一方で、おそらくだがエンジニア全体にズドーンと入れた事例も。

（前提として）そもそもエンジニアをどうマネジメントすべきか？

採用、育成、評価などのいわゆる組織づくりを担う役割として、VP of Engineering という役割がでてきていることは有名。ただ、エンジニアの組織づくりについては先頭を走っている企業もまだまだ試行錯誤中。

その中でわかりやすかったのはこれ。

（前提として）エンジニアの組織はどうなっているか？

「エンジニアにいかに会社のゴールを意識してもらうか？」という観点でとても分かりやすく整理されている一休のエンジニア組織。

事業部別か機能別かという観点で組織拡大とともに、機能別→事業別組織へとエンジニア組織も拡大していく。

クックパッドは、CTOとテックリードがマネジメントも技術も両方担うというシンプルな構造。グループとかは作らずに、もう少しフラット。
ミッションの達成を目的とする役割と、技術的向上を目的とする役割のマトリクスになっているようだ。

100名を超えてくると、やはり階層構造になってくるようだ。

メルカリはEngineering Managerがマネジメントする構造。EMやEM of EMなんていうのもいて、当然だが結構な階層構造になっている。

技術系のCTOと組織系のVP of Engineeringを分けている点と、最近ではメルカリをさらに小さなサービスに分けた体制（マイクロサービス）も意識しているとのことで、グローバルスタンダードといえど、組織運営はなかなか大変そう。

まとめ

ざっと調べた限りでは、「エンジニアだけ特別な評価制度にしている。」ところはむしろ少なかった。

ビジネス系職種と同じなのは、定量的なゴールが設定しにくくても、定性的なゴールイメージをコミュニケーション頻度を増やして摺合せている。

ビジネス系職種と違うのは、技術力の向上に積極的に取り組んでもらうために、評価を活用して行動促進をしていること。