ラクーンのエンジニア評価制度について

こんにちは、たむらです。
今回は、ラクーンのエンジニア評価制度についてのアレコレを書こうと思います。
ラクーンがエンジニアに活き活きと仕事してもらう為にどの様に評価制度を考えているかを知ってもらうキッカケになればと思っています。

評価制度の一般論
　さて、会社の評価制度というものはエンジニアという職種に限らなくてもどの会社でも非常に苦慮して作り上げているものです。働くすべての人のあらゆる状況を正しく評価することはとても難しく、過不足やいびつさを抱えているものが殆どなのではないかと思います。みなさんの会社ではどの様な評価制度で評価されているでしょうか？またその評価制度に満足されていますか？
　私は人事の専門家では無いので正確性は危ういところがありますが、経験上エンジニア界隈で適用されている評価制度は以下の様なものが一般的かと思います。
1. 職能給制度
スキルレベルにより評価されるものです。号棒と呼ばれるレベル表を定義し、その昇降により給与（＝評価）を決めるような方式になります。スキル評価としての建前がありますが、実際にスキルを詳細に定義することは難しく、得てして年功序列的な運用になりやすい面があります。
2. 成果主義による評価制度
その名の通り、業務の過程は考慮せず、成果のみによって評価する方式です。売上や利益といったもので定義されることが多く、評価基準の分かりやすさがメリットと言えます。エンジニア職種に対しては絶対的な評価基準は定義し難い為、指標が多岐にわたることが殆どです。その為分かりやすさは一段劣る印象があります。
3.目標管理との連携
多くは期初に業務に則した目標を立て、その達成度により評価をします。個々人のレベルに合せてそれぞれが定義することが多く、成果主義を属人化させたものといえるかもしれません。売上等の統一の評価基準を用いない場合はメンバー間での絶対的な評価が分かりにくくなる傾向にあります。

実際のところ多くの企業では、上述のどれかを適用しているというよりは、それぞれの良い所をうまく取り入れつつ評価制度を組み立てているところが殆どなのではないかと思います。中には名目上は「成果主義」だが、実際にはろくに予実管理も面談もせずに上司の胸先三寸で決まる「ブラックボックス評価制度」というところもあるのかもしれません。

過去のラクーンのエンジニア評価制度
　ではラクーンではどうなのかというと、過去ラクーンでは上で述べたものの１つである「目標管理と連携した評価制度」をエンジニアの評価に利用していました。しかし、この制度には職務的に合わない部分があり見直されることになりました。
　合わない点は２点あります。１つ目は業務内容が目標設定時から変化することが多い点です。例えば目標設定時はプロジェクトAに参画することが予定されていた為、「プロジェクトAでの不具合摘出率を前回参画プロジェクトの半分にする」という目標を立てたが、プロジェクトA自体が実施されなかった、というようなケースです。ラクーンでは実施する案件はその時の状況により都度見直しが入るので、この様な目標倒れがしばしば起きました。
　２つ目は実業務との乖離です。１つ目の反省を踏まえて、目標を実業務から離れたものに設定したことがありました。例えば「未経験のRuby on Railsをマスターし、公開アプリを作成する」などです。業務の隙間時間でスキルを向上させてもらい、その成長を評価しようとの目論見でしたが、逆に本来評価の対象とすべき実業務の評価と離れたものとなってしまい、妥当性を欠く結果となってしまいました。

評価制度見直しに際してのポリシー
　この様な経緯から然るべき評価制度に対しての必要性が高まったのを踏まえて、評価制度の見直しが行われることになりました。策定にあたりポリシーとしたのは以下の点です。
「エンジニアのスキルアップの指針(キャリアパス)となり得るもの」
「客観性・納得感があるもの」
「エンジニア以外に対しても分かり易い評価軸を持ったもの」
「モチベーションの向上に繋がるもの」
このポリシーに則り、実際に働くメンバーにも検討に加わってもらいながら、評価制度の見直しを行いました。
その結果、現在適用している評価制度は「スキルベース評価」、「スキルシート管理」、「資格制度」、「３６０度評価」に表されるものです。順に概要を説明させてもらいます。

スキルベース評価
　まず、前提とするのはラクーンでのエンジニア評価はスキルをメインとしているということです。エンジニアという職種である以上、その技術力を評価の中心に据えようという思いがあります。そこで観点とする「スキル項目」を選定し、それに沿って評価することを評価の主軸としました。「スキル項目」は大きく分けて５つのカテゴリに分かれており、①技術スキル、②言語スキル、③ヒューマンスキル、④業務スキル、⑤アドオンスキルとなっています。①～③は６段階評価、④、⑤は３段階評価としています。

スキルカテゴリの概要

評価の際に一番重きを置かれるのは ①技術スキルになります。なぜ ②言語スキルや ④業務スキルが入らないのかというと、言語やシステムは新陳代謝がある為です。そこで、よりエンジニアスキルの本質となる要素にターゲットを絞ることで、評価に恒常性をもたせることを意図しています。

スキルシート管理
　スキル項目に沿って、全エンジニアのスキルをスキルシートという表にまとめ、一覧できる様にしています。これは部門内で誰でも参照できる様にしていてスキルの見える化に繋げています。但し、過剰に上下関係を表し人間関係が崩れてしまうことがないように、①技術スキル～③ヒューマンスキルに関しての数値は評価者及び本人以外には公開せず、全体公開するのはある一定のレベル以上かどうかのみ公開するようにしています。
　元々見える化というのは会社にエンジニアの評価を分かり易く伝えたいという意図の他に、メンバー間での教育関係が生まれやすくすることも目的の一つとしています。その為メンバー間においては上下関係を知るというよりも誰に聞けばいいのか？誰が教えるべきなのかが分かることが見える化の大事なポイントだと考えています。

実際のスキルシート

資格制度
　ラクーンでは会社独自の資格制度を持っていて、その中に「特定分野の専門知識、経験を持つ人」に与えられるスペシャリスト資格（社内では通称S資格と呼んでいます）が存在します。レベルによりS1,S2と2段階あり、年収の想定レンジで言えば750万円～1000万円以上をイメージしています。
技術戦略部のS資格としては、シニアエンジニアや、プロジェクトリーダ、インフラエンジニア等が定義されています。
　さて、このS資格はそれぞれ資格取得条件を定義することになるのですが、それをスキルレベルと紐付ける形で定義しています。それにより、「自身の現在のスキル」、「伸ばすべきスキルの方向性」、「会社的な評価（S資格の取得）」が同じ軸で考えられるようにしています。

技術部で現在用意しているS資格とその資格条件
スキルマップ1

スキルマップ2

３６０度評価
　評価査定は年に２回半期毎に行いますが、その時に上述のスキルシートの更新を行い、評価資料として用います。
スキルシートの更新の際にはなるべく多角的な評価を集めるため、メンバー間相互評価を集めたり、資格所有者に更新内容の妥当性の検証をしてもらったりといった360度評価の仕組みを取り入れています。
上司からの評価だけだと実業務の目線から離れていることも多く、実際の技術スキルを測るには限界があります。その補完としてメンバー同士からの評価を用いています。また、いつも進捗が遅れがちだが、実際には他メンバーの相談や質問に親身にのっていて他メンバーからの信頼がとても厚い人等、目に見える成果では測れない貢献者を認知する手段にもなっています。

まとめ
　ザックリとした説明になってしまいましたが、こんな仕組みでラクーンではエンジニア評価をしています。
この評価方針はここ１年位で見直した結果なのですが、この事実が物語る通り、今後も必要があれば都度見直しをしてどんどん変化していくことになると思います。ただ、あくまでその目的は、エンジニアが活き活きと仕事ができることや、長くラクーンで働いていきたいと思えることに繋がるべきであると思っています。

最後に・・・
私達は一緒に働く仲間を随時募集しています。
この評価制度の話なり、ラクーンのビジネスモデルなりをちょっとでも面白そうだなと思ってくれた方、是非一緒に働いてみませんか？
ご応募お待ちしております！！