8/11に開催したイベント「[Lancers × VOYAGE GROUP]エンジニア評価制度についての公開雑・相談」では、ランサーズVPoEの倉林とVOYAGE GROUP(CARTA HOLDINGS)CTOの小賀さんによる、リアルな雑談・相談の様子をライブ公開しました。
テーマのエンジニア評価制度は多くのエンジニア組織がぶつかる課題です。
ランサーズではLancers Open & Flat Recruitingというプロジェクトを発足し、エンジニア組織・採用の改革を行っており、その中でも評価制度は避けては通れない課題です。そんな中で独自の技術評価制度を実施し、また10年以上に渡って改善を繰り返しているVOYAGE GROUP(CARTA HOLDINGS)の取り組みを聞きながら、自社に合った評価制度の形を探すために実施したのが本イベントです。
今回の記事では、当日の雑談・相談の内容からいくつかのトピックをピックアップしてご紹介します。
スピーカープロフィール
ランサーズ株式会社 VP of Engineering 倉林昭和
ECサイト構築、受託開発、運用業務、要件分析、新技術検証、マネジメントなどシステムエンジニアとして2000年より多岐にわたる業務に従事する。ランサーズの社会的意義の強いビジョンに共感し、入社から約10年前に当時まだサラリーマンだった代表の秋好と一緒に働いていた縁もあり、2019年2月に入社。現在はランサーズのVP of Engineeringとしてエンジニア組織のパフォーマンス向上、組織作りやマネジメントに取り組んでいる。
株式会社VOYAGE GROUP(CARTA HOLDINGS) 取締役CTO 小賀 昌法
VOYAGE GROUP 取締役CTO、日本CTO協会 理事。 VOYAGE GROUP CTOとして、エンジニアの採用・育成・評価戦略における様々な仕掛けを構築・運用し、事業開発会社としてのエンジニア文化の醸成に大きく貢献。また、サービスインフラや社内インフラの構築・運用を手がけるシステム本部長、セキュリティ委員長、複数の子会社取締役、人事部門担当役員などを兼任した。2020年1月からはVOYAGE GROUPの親会社であるCARTA HOLDINGSのCTOも兼任。他に、日本CTO協会(CTOA) 理事にも従事。
営業とエンジニアが同じ基準で評価できない理由は……
倉林さん
今日はよろしくお願いします。
おそらく本日参加されている方々も、エンジニア評価に苦労されてるんじゃないかなと思っています。評価制度には正解がない、ともいえるかもしれませんね。
その中でもVOYAGE GROUPさんの技術評価制度などの取り組みにはみんな注目してるところでしょう。ランサーズと同じ悩みを抱えてる方にも役に立つようにいろいろ会話させていただければと思ってます。
小賀さん
エンジニアの評価については、本当にみんな悩んでるところだと感じていますね。
私がCTOになった2010年当時に感じていた大きな課題も評価に関連していました。
元々VOYAGE GROUPではシステム本部にエンジニア全員が所属して複数のサービスを開発していた体制だったのですが、私が入社する2、3年前に事業部ごとにエンジニアが所属する事業部制に変わりました。
そこで何が起こるかというと、システム本部の時には評価者はエンジニアだったのが、事業部制では評価の最終決定がエンジニアではない人になる場合がありました。
そうすると、目標の立て方や評価の割合が変わってエンジニア職からの評価に対する不満が増えていきました。
入社した当時から私には、エンジニア職に対して営業職と同じような定量評価をやるとうまくいかないという考えがあって、まずはそこから変えていこうと人事と一緒に進めていきました。
倉林さん
ランサーズの組織はまさにそういうフェーズですね。
一昨年くらいまでは開発部という一つの組織で対応してきたのですが、事業も増えてきました。
本体の「lancers.jp」という最大の事業には事業部直属のエンジニアがいた方が良いという方向性になり、2020年にグループ化したMENTAというサービスも事業部直属でスピーディーに開発したいということで事業部制に移行し始めています。
一方で、全社横断と事業部直属というエンジニア職の所属の違い、そして事業部直属の部門は評価者がエンジニアではないというケースも生まれて、評価の課題が浮き彫りになっている状態です。
ランサーズの評価制度は、至って普通です。
半期ごとの目標設定をベースにした評価制度で、成果評価と行動評価の目標を定量で設定します。期の中間には目標の見直しや改善のための1on1を行い、期末に振り返りとフィードバックしています。
課題に感じているのは、この評価制度がエンジニアにとってモチベーションが上がるものなのか、自己成長に結びついているのかということですね。
まず小賀さんに相談したいのは、事業部・コーポレート・全社横断など様々なエンジニアがいる中で、
・事業貢献とスキル評価
・自己成長にどうつなげるか
そして、これらをどうバランスをとっていくべきかということです。
小賀さん
その話をするときに良く出すのが、営業とエンジニアの違いです。
例えば、営業では200社のターゲットリストに5人で担当を分けてアプローチしたとします。
一人のメンバーが担当分を失敗してまったく受注できなかったというケースがあった場合、他のメンバー個人個人の成果には影響はあまりないんですよね。
一方でエンジニアは基本的に全員で一つのシステムに関わることが多いです。
スキルが足りないメンバーがそこでまずいことをやると他のメンバーにも影響するんですよね。エンジニアの成果はチームメンバーのスキルや行動によって大きく変動する。これが大きな違いなんです。
だからこそ、同じような定量評価の手法では、エンジニアのスキルや貢献は正確に評価できないと思っています。
エンジニア以外の評価者に対しては、リリースの数や新規機能の数など、営業の達成目標と同じような目標の設定ではうまくいかないということを理解してもらうことが大事です。
倉林さん
ランサーズでも一昨年くらいにそこにエンジニアの評価もビジネスサイドと同様に定量でできないかと頭を捻っていましたが、なかなかうまくいかないですし、目標に対してみんな納得感がないという状況になり、いろいろと改善を続けているところです。
エンジニアの技術を評価することの大切さ、難しさ、その手法
司会
参加者からの事前に「エンジニアの評価、給与レンジを他職種と分けていますか？」という質問をいただいていました。お二人ともいかがでしょうか？
倉林さん
ランサーズでは、元々ビジネス職もエンジニア職も同じ給与テーブルだったのですが、今年の初めに分けるようにしました。
ランサーズ、エンジニア給与制度の改善について
https://engineer.blog.lancers.jp/2021/09/lancers-open-flat-recruiting-kyuyo-adjust/
小賀さん
VOYAGE GROUPは、私が入社した2010年当時からエンジニア職には別のグレードの定義がありましたね。
①事業貢献、②能力、③クリードコンピテンシー(行動指針やバリューを360°評価するもの)という3つの軸で評価していて、それぞれ評価者が異なっています。
事業貢献では上司、能力についてはエンジニア同士が評価しています。
司会
事業貢献と能力はどれぐらいの比率で評価されてるんですか？
小賀さん
そこは掛け算として考え、総合的に判断しています。
例えば、能力が突出していたとしても事業に活かせていないのであれば高い評価になりませんし、能力がそこまで高くなくても活かし方がうまい人は事業貢献が高く、結果的に掛け算方式で総合値が高くなることもあります。
倉林さん
事業貢献と能力、そしてクリードという3つの軸での評価はすごくいいですね。
能力を評価するエンジニアというのは、CTO中心に各分野のマネージャーでしょうか？
小賀さん
基本的には自分より高いグレードの人が能力評価をするようにしています。そこで特徴的なのが”他のチームの”自分より高いグレードの人から評価してもらうという制度設計です。
私が入社した当時、優秀なエンジニアはいたのですが、チーム毎に偏りがありました。
優秀なエンジニアがいて、上手いエンジニアリングをしているチームがある一方、あるチームでは優秀なエンジニアが少なくてうまくいってないということもありました。
そこで高いグレードのエンジニアの能力を全社的に活かしたいと思い、現在の評価体制を設計しました。
VOYAGE GROUPの技術評価会の取り組み
倉林さん
評価者の工数について少し深堀りしてお聞きしてもいいですか？
ランサーズの評価でも各メンバーとマネージャーが1on1するなど工数もかなりかかっています。
VOYAGE GROUPさんのやり方でも高いグレードの優秀なエンジニアこそ、評価に時間を割かれると思うのですが、みなさんどう感じているんでしょうか。
小賀さん
評価の作業にかかる前は、大変だなとみんな言いますが、高いグレードの優秀なエンジニアこそ、同じ部署に長くいることが多かったりして、日々の業務に飽きが来ることもあります。そんな中で、他部門のメンバー評価をすると、その部門のシステムのアーキテクチャを理解したり、ビジネスの状況を理解したり、コードを読んだりすることが新鮮に感じられるといいます。
やる前はめんどくさいなあと思いつつ、やった後は面白いですねって言ってくれる、それが何年も続いていますね。
評価の目的を理解してもらうためのコミュニケーション手法とは？
倉林さん
評価を行う目的は色々あると思いますが、VOYAGE GROUPさんは個人の成長や意欲を上げることと目標設定・評価が結びついている印象がありますね。
小賀さん
なぜそれをやっているのか、その目的をきちんと持つことは大事だと思っています。
今、偉そうに評価についてお話していますが、もちろん完璧なわけではなく、社内では「360°評価って意味あるの？」って思っている人もいますよ。評価制度の仕組みや評価自体に全員が完全に納得している訳ではないです。
それでも自分たちの考えをしっかりと持つことは大事です。
例えば、「なぜグレードがあるのか」ということを真剣に考える機会は少ないですが、会社としては高いグレードの人が増えれば増えるほど会社はうまくいくと考えているわけです。
だからメンバーには高いグレードになってほしいんですよね。評価っていうのは「あなたが今どこにいるのか」を知ることと「目指すべきグレードはどこなのか」を定めるためにあると考えています。
会社としてこうなって欲しいという姿と、あなたの今の姿を照らし合わせて、次はここを目指そうと期待値調整をしつつ、評価していきます。
360°評価についていえば、高いグレードになるために他のメンバーからもこういう風に見てもらえると理想に繋がるよね、という話に繋げることで、メンバーの納得度も高まっていくと考えています。
倉林さん
その考えをメンバーに伝えて理解してもらうのってすごく大事だと思っているのですが、メンバーとのコミュニケーションの工夫などはありますか？
小賀さん
定期的に考え方を伝える場を作る、それに対してメンバーからフィードバックをもらう仕組みを作るということをしています。当たり前かもしれませんが、これしかないと思っています。
具体的には、半年に1回の評価の機会を利用してコミュニケーションの機会を作っています。
評価会のタイミングで、「今回の技術力評価会は一部変更します、なぜなら……」という説明や「VOYAGE GROUPにとって価値あるエンジニアとは」「会社としての技術を向上させる方向性について」といった評価に関する考え方をインプットするようにしています。
そして、評価制度自体についてもメンバーからフィードバックをもらって、私自身も次回までの宿題をもらうなど、改善を続けています。
ちょっと話は逸れてしまいますが、評価会で説明に使っている「VOYAGE GROUPにおける技術力とは」という資料があります。これはカジュアル面談でもお見せしていますので、もし見たい方がいたらぜひカジュアル面談を申し込んでいただけると嬉しいです。笑
倉林さん
定期的に会社の考えをインプットしていくことは、地道ですが本当に大事ですよね。
評価というと値付けをされるような悪い印象を持ってしまうこともありますが、会社としてはグレードを上がっていってほしい、そのために評価というフィードバックを行っているということはきちんと説明していかないと意識が薄れていってしまいそうですね。
話が少し変わりますが、VOYAGE GROUPさんは各メンバーのグレードについて社内で公開していますか？
ランサーズでもここは考えている途中なのですが、中途入社メンバーが増える等の影響でグレードには少しづつ歪みも生まれています。グレードを公開することで目標となる人が明確になり、成長に繋がりやすいと思う一方、問題も起きるのではないかと危惧しています。
小賀さん
VOYAGE GROUPではグレードを公開しています。一方で年収は公開していません。
グレードを公開する目的は、グレードが高い人の行動を参考にしてほしいからです。
面白い仕組みとしては、中途入社の方は入社時の年収が高い人でも高い年収のままでまずは一番下のグレードからスタートします。技術力評価会を経て、初めて高いグレードになれます。
倉林さん
グレードと年収はリンクしていないんですか？
小賀さん
もちろん相関はあります。
ただ、グレードの考え方については、「グレードって給与を決めることですよね」だったり「給与レンジをこのレンジにしたいからそのグレードに当てはめる」というものは順序が逆だと思っています。
まず最初に、その価値があると周囲から見られている、あるいは相当のパフォーマンスを出しているから高いグレードにいるべきで、高いグレードにいるから年収も高いという相関になるべきです。
年収をこれぐらい払わなきゃいけないからこのグレードにプロットしておかなきゃいけないという考え方は逆なんですよね。
先程お話したように、評価は何のためにあるのかということを考え抜いて、きちんと伝えていく、そうしていくことでグレードについても理解を持って、評価についてメンバーが前向きにとらえてくれると思っています。
おわりに
ランサーズでは今回の雑・相談を経て、評価制度でいくつかの改善を行う予定です。
真似できることばかりではないですが、少しでも読んでいただいた方の参考になれば幸いです。
