[チームビルディング] エンジニアの評価

この記事・・ずっと下書きのままだったので出します。未完成部分は一旦削除して出します。

---

今まで小規模～大規模の開発チームをまとめてきました。色々な評価基準を採用してきましたが、今はこれに落ち着いています。

# グレード区分

当然ですが、給料やグレードが高いと期待値（その人に求められるモノ）もあがります。なので、まずは期待する職務をグレードに分け、該当するエンジニアがどのグレードにいて、会社は何を期待しているのかを伝える必要があります。開発チームのサイズによってはさらに細かく分ける必要がありますが基本概念はこれです。勝手に任侠グレードも追加しました。

- プリンシパル - 組長
    - 外部の人も認めるリーディングエンジニア。執筆、公演などもこなし会社の目指すべきエンジニア（みんなの目標）。経営目線をもって開発事業をリードするような存在（CTOポジション）でもあります。また、エンジニア採用の責任者でもあります。
- シニア - 若頭
    - 開発に精通し、プロジェクトのアウトプットに対して品質を担保する人。白紙から設計を起こせる、設計の責任者でもあり、適切な設計で開発が進むよう目を光らせる開発のリーダー。幅広い知識をもち、総合的な知識をベースに最善の判断ができる現場トップな人。
- II - 舎弟
    - 自己完遂能力をもって、ただしいコード、テスト、ドキュメントをかける人。自身のコードに対しての品質を担保することができ、設計時に適切な意見やアドバイスをすることができる人。
- I - 若衆
    - 自己完遂能力を鍛錬していて、ただしいコード、テスト、ドキュメントをサポート（指摘）してもらいながら仕事をしている人。設計書やドキュメントを正しく読むことができ、設計通りのコードがかけている人。

# 評価区分
まず、評価を 

**1. スキル、2. パフォーマンス 3. コンピテンシー にわけます。**　

ソフトウェア開発は直接売上に関与しない、もしくはしずらいので、スキルとパフォーマンスを重視します。売上はマーケ、セールス、経営者の人にがんばってもらいましょう。

## 1. スキル

スキルとは該当エンジニアのできる事、できない事を分解して評価することになります。できる事、しっている事、経験値から学んで体感染みついている事などを評価します。スキルにはあまりアップダウンはなく、じっくり積み上げていくものだと思っています。グレードIのころはたくさんの事を吸収しスキルの評価がガンガンとあがっていきますが、シニアになるとそのスキルは高度化し一つ一つのスキルアップにも時間がかかります。

毎日同じ仕事していては新しいスキルを身につけることはありません、新しい技術や手法に積極的に取組スキルを上げていく事がスキル評価につながります。

## 2. パフォーマンス

パフォーマンスとは、スキルをそのまま生かしたら100となるところ、どこまでやったかという事になります。開発のプロとして、スキルを活かして100のパフォーマンスを出す事は当たり前なのですが、難しいプロジェクトにとき、もしくはチームを引率して「他のメンバーのアウトプットをどこまで引き上げたか」を評価します。　私の考えでは、IIまではスキルにマッチしたアウトプットを出すことを目指し、シニア以上に対しては、他のメンバーのアウトプット引きあげを、どこまでやれたかを評価しています。

「できる」がスキルだとしたら、パフォーマンスは「やった」です。テストコードがちゃんと書けるのに、書かない人は「できる」けど「やらなかった」人です。パフォーマンスは実際にやったことを記載するようにしましょう。

パフォーマンスはスキルと違い、前期やったから今期やったとも限らずアップダウンがある「場合」があります。（ない方が望ましい）。去年ホームラン50本打ったからといって今年も打つとは限らないわけで、コンスタントに20本ぐらい打てる人がほしいです。

## 3. コンピテンシー
コンピテンシーはとても基本な部分になり、会社のカルチャーを語る場所でもあります。私がメインに見るコンピテンシーは他メンバーに仕事のしやすい環境を与えられたかを見ています。ちゃんと必要なコミュニケーションをしているか、コアタイムに所定の場所にきてチームの効率を引き上げているか、オフィス環境をきれいにしているか、他の人の時間を無駄にしていないか（ミーティングとか）などを評価項目にいれています。

## 1,2,3の比重に関して

会社のカルチャーを大切にするならコンピテンシーの比重を高く、そして採用時はカルチャーフィットするか重視。　ドライにいくなら2を重視、そして採用時は1を見ながら2が高いか見る。 個人的には 1が3割、2が5割、3が2割ぐらい。

# 評価方法

## 10段階セルフ評価

各評価項目に関して10段階評価をします。これらは評価する側とされる側が識別することができるアウトプットをベースに行います。

|点数|状態|
|:---|:---|
|0|全く達成していない|
|1|まだ改善点やできてない点が多くあると認識している|
|2|まだ改善点やできてない点があると認識している|
|3|まだ改善点やできてない点が多少あると認識している|
|4|ほぼ達成できていると認識している|
|5|達成できていると認識している|
|6|達成し続けられている|
|7|達成し続けていることを1人の同僚に認められている|
|8|達成し続けていることをチームメンバー全員に認められている｜
|9|達成し続けていることをリーダーもしくは上司から認めらている|
|10|誰もが達成して超越していることを認めている|

### アウトプットない人は評価できない（しずらい・・）

普段アウトプットとは量を指します。ソフトウェア開発においては量だけ多くても質や効率への追求も必要されます。長期間仕事した人が評価されるのでなく、決められた時間内で最速かつ効率よく品質を担保するアウトプットが評価されます。手戻りがない、バグが少ないコードを書くためにどのような努力を日々しているのかをアウトプットの評価としています。

# 給料表

グレードごとに給料幅をあらかじめ決めて公開しておきます。公開することによって自分の立ち位置が明確になり自身の向上心を刺激してくれます。

あとはそのレンジを10分割して評価に照らし合わせ決めます。

# 評価のフィードバック

例えば IIの3のというフィードバックだとしたら、どうやったらIIの4または5,6になれるかを明確に伝えましょう。なんとなく評価されては納得いきません。　フィードバックの場は次の評価までに何ができていれば上がるのか、これを明確にする場にしましょう、そしてフィードバックをもらった人はそれを達成するために計画を立ててがんばりましょう。

# 評価疲れにも注意

評価はとても大切なのですが、正直工数もかかるし相当な労力を費やします。なので、できるだけ簡潔にしておくべきだと思います。あまり複雑なものをつくらずに各項目大切なモノのTOP10ぐらいに抑え、評価されるほうも、するほうも負担を減らすことをお勧めします。

# なぜ先にグレード区分や評価レンジを先に決めておくか、または共有するか

エンジニア市場は上昇トレンドであり、前職の給与をベースに決めていたら今いるメンバーとの矛盾が生じてしまうからです。強いエンジニア集団を作ろうと思ったらブレない基準（評価基準）がとても重要となります。前職で高給だったからといって自社で同じ価値を出せるとは限りません、やはり長い目で見た時にしっかりとした評価基準をもっていることがパフォーマンスの高いチームを作ることができると思います。