• 株式会社VOYAGE GROUP
  • CTO
  • 小賀 昌法

VOYAGEのエンジニア評価制度の全貌。「技術力評価会」による、人が育つ組織の作り方

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

〜「技術力評価会」を中心とした、VOYAGE GROUPのエンジニア評価制度。被評価者だけでなく、評価者も育てる仕組みとは〜

売り手市場が続く、エンジニア採用。その中で、優秀なエンジニアを採るためには、何をするべきなのか。

その問題への1つの解として、人が育つ「評価制度」を綿密に構築しているのが、株式会社VOYAGE GROUPだ。同社では、半期の取り組みを評価する「技術力評価会」を中心とした評価制度を、CTOの小賀 昌法さんを中心に、6年という歳月をかけて作り上げた。

「なぜそのように実装したのか」を90分間ディスカッションする「技術力評価会」、それをサポートするための「サポーター制度」、その評価資料の「GitHub(ギットハブ)」での全公開など、随所に工夫が施されている。

(※技術力評価会の詳細は、新入社員目線で書かれたこちらの記事もどうぞ)

そして、それらの評価制度を運用していくためには、「評価者を育てること」も必要不可欠だと、小賀さんは語る。

今回はそんな小賀さんに、設計し尽されたエンジニア評価制度の全貌を詳しく伺った。

6年かけて作り上げた、VOYAGEの評価制度

私は2010年にVOYAGE GROUPに入社し、その半年後にCTOに就任しました。

CTOに就任した頃は、まだエンジニアも40人程度の組織でした。それが今では、100人以上のエンジニアが在籍する組織になっています。

VOYAGE GROUPの小賀 昌法さん

弊社では、4段階のグレード制度を導入しているのですが、5年前と比較すると、グレード3・4の割合が増えており、組織づくりが上手くいっていると感じますね。

▼社員数だけでなく、上位グレードの割合も増加

CTOに就任した当時、昇格候補者が妥当かどうかを、一番上のグレードの人たちを集めて議論していました。ですが、組織が大きくなり、事業部が増えていく中で、全員を見きれなくなってしまって...。

そこで、エンジニアの評価制度を、6年かけて改善し続けてきました。

事業には当たり外れがあるからこそ、評価制度が重要

やはり事業って、中の人たちが真面目に仕事をしていたとしても、うまくいかない場合も多いじゃないですか。それでも、しっかりと取り組んでいるメンバーがいたら、そこは評価して、グレードも上げていきたいですよね。

なので、ビジネス面だけではなくて、能力面でもしっかりと評価できる制度を作るというのが、健全だと思います。

例えば、今となっては「テストコードを書こう」というのは、業界的に凄く浸透しているじゃないですか。ですが以前は、テストコードはあった方がいいけど、基本的には書かなくてもいいよね、という時代もあったと思うんです。

でもそれって当たり前で、テストを書かずに早くリリースしたほうが給料が上がるなら、人はそっちに動きますよね。技術に詳しくない事業責任者が評価すると、そうなりがちだと思います。

VOYAGE GROUPの小賀 昌法さん

しかし私は、妥当な技術や、やるべきことを選択している人を、正しく評価したいなと思ったんです。

なぜそうしたのか?を問い続ける「技術力評価会」

能力面を評価する仕組みとして、現在、グレード1と2の人は、半年に1度「技術力評価会」を実施します。自分の半年間の仕事の中から、1つネタを選んで発表し、上のグレードの人が評価をします。

全体の流れとしては、まず被評価者に対して、サポーターが1人付きます。そして、評価会にどんなネタを持っていくのかを、被評価者と一緒に考えます。

評価会のネタは、半年間の仕事の中で、「この仕事についてを評価してもらいたい」というのを決めますが、どれでも良いわけではありません。

VOYAGE GROUPの小賀 昌法さん

なぜこれを作ったの?と聞くと、「プロデューサーが欲しいと言ったからです」と言う人がいます。そんなときは、「欲しいと言われたら何でも作るの?そんなエンジニアは、うちでは評価されないよ」と伝えます。

技術の選択も同じで、例えば、使う技術はチームリーダーが決めるという場合も多いですよね。そのときも、「なぜチームリーダーはその技術を採用したのか」を、自分の言葉で説明できる必要があります。

そういったネタをサポーターと一緒に考えて、評価会に出します。そして評価会では、2人の評価者に対して90分間、発表とディスカッションをします。

「ビジネスとしてのインパクトは?」に答えられるか

評価会には、「ビジネスとしてどういう課題があったのか」「それを解決するために、どういう施策を考えたのか」といったネタを出します。

例えば、「データベースの負荷が上がっている」という問題に対して、「なんとなくインデックスを付けてみたら早くなりました」ではダメなんですね。

課題はパフォーマンスチューニングなので、「現状のパフォーマンスを計測して、AとBの2つの改善案でもそれぞれ計測してみて、Aの方が良かったので、最初に考えていたところがボトルネックでした」というところまで考えられていると、良いですよね。

「ビジネスとしてのインパクトがあるのか」という視点も重要です。パフォーマンスを50%改善したものと20%改善したものを比較して、ビジネスのインパクトがほとんど変わらないのであれば、少ない労力で20%上げましょうという判断ができると、より良いですね。

「正しく評価してもらうため」のサポーター制度

最初は、サポーター制度というものはありませんでした。ですが、実際の評価会の場で、「なんでこのネタを持ってきたの?」「別のネタのほうが良かったんじゃないの」という事も多く...。

経験が浅いと、本質的にちゃんと評価してもらいやすい内容を考えるというのが、上手にできなくて。やはり高いグレードの人がサポートしてあげることが大事だなと思いますね。

「誰がどう見てもその方法を選ぶよね」というネタだと、評価する側の判断としては「妥当ですね」としか言えないですよね。そうではなく、人によっては判断がぶれるようなところで、自分の意志として決めたというポイントがあった方が、評価しやすいじゃないですか。

VOYAGE GROUPの小賀 昌法さん

そういったネタを出してもらうために、サポーターと一緒に作ってもらっています。

しっかりと「伝える」ために、点数の評価は付けない

そして実際の評価会では、2人の評価者に対して説明していきます。

ここでの評価者は、原則として、被評価者とは別の部署の人にしています。

「その人にはこういう能力がある」「うちのチームに来ても、これくらいの能力が発揮できそうだ」という点を、違うチームの人から客観的に評価してもらうことが目的です。

そして最終的に、評価結果を出してもらうのですが、5段階評価のような点数はつけていません。

点数をつけていた時期もあったのですが、数字って独り歩きしちゃうんですよね。そうではなくて、評価内容をしっかりと文章で書いて、文章で理解してもらう。その後のフィードバックでも補足しながら、しっかりと「伝える」というところに重点を置いています。

点数をパッとつけて、一言だけコメントを添えるような評価のしかたもあるとは思いますが。点数を無くすと、評価者のスキルは求められますが、しっかりと文章でフィードバックするようになるんです。

見逃しがちな、「評価者を育てる」という視点

90分の評価会の後、評価者とサポーターとCTOで、評価結果のすり合わせをします。その後にある、被評価者に対しての対面フィードバック会で、どんなメッセージを伝えたらいいのかも、ここで話し合います。

評価者を2人にしているのは、複数の目線から見るという目的もありますが、一番は「評価者」のためです。

エンジニアの人って、人の評価をしたり、給料を決めるのって嫌ですよね(笑)。評価をすること自体、かなりのストレスなんですよ。だから、評価者を2人にして、負担を減らしているんです。

VOYAGE GROUPの小賀 昌法さん

この評価制度って、関わる人が多いぶん、評価者が「やりたくない」と言ったら、全く機能しなくなるんです。なので、評価者の負担を減らして、「良い評価者が育つ」環境を作るというのが、この制度の肝なんです。

2人で評価することで、もう1人の評価者から「なるほど、そういう視点があるのか」とか「今の質問は良いな」というように、評価のポイントを学んでいく。そういう意味でも、評価は、複数人でしたほうが良いですね。

この制度を始めるときも、まだ40人くらいの規模だったので、評価会に私が必ず同席していたんです。評価者が出した評価に対して、「全部俺が責任を持つ」と言っていました。最初の頃は、そうすることで評価者の精神的な負担を下げていましたね。

今では、私が同席することも少なくなりました。評価者自身が成長してきた結果だと思います。

評価資料も、結果もすべてGitHubで社内に公開!

評価のすり合わせが全員分終わると、昇格候補者を「諮問(しもん)会議」に上げます。そこで私と私が選んだ人で、昇格候補者が妥当かどうかを議論して、最終的な判断をします。

ちなみに、評価資料やその結果は、GitHubにすべて保存しています。以前は、被評価者と上長にだけ渡していたのですが、今では社内のプライベートリポジトリで公開しています。

▼評価資料はプライベートリポジトリで社内に公開

評価結果はGitHubに保管

やはり、評価を書くのって難しいんですよ。「評価者を成長させていく」という観点だと、他の人の評価を見て、どういう風にフィードバックしているのか、どういう視点で見ているのかを知るのは重要です。

また、被評価者からしても、他の人は何をしていて、どう評価されているのかというのは、気になるんですよね。他にも、自分のチームのメンバーがどういう指摘をされているかをまとめて、「チームとしてどう改善につなげられるか」を考えているところもありますね。

「何を大事にしたいのか」を、全員で考えていく制度

この評価制度は、一般的な会社と比べて、評価に関わる人の数が圧倒的に多いので、本当に大変です(笑)。

ただ、どういう状況でどんな課題があり、その課題に対してどんなアクションをしたのか。そして、その結果に対して、次はどんな打ち手を考えているのか。このフレームは、エンジニアという職種に限らず有効なので。運営する人の覚悟と、経営陣がそこに時間を投資する覚悟があれば、どの職種にでも活かせるのかなと思います。

ここまで作ってきて感じるのは、自分たちがエンジニアとしてどう評価されているのか、何を大事にしたいのかを、みんなで決めていっている制度だということです。評価は、1度で決めて、正確なものを出すというのは無理なので、みんなで一緒に考えましょう、という気持ちですね。

VOYAGE GROUPの小賀 昌法さん

エンジニアを採用したいというニーズは、今後も減らずに、それどころか増えていくと思ってます。そうなると、ますます採用が難しくなっていきます。

そうなってくると、人がしっかりと成長できる会社が生き残っていくはずです。今後も、しっかりと「人が育つ」組織を作っていきたいと思います。(了)

SELECKからの特典

当媒体SELECKでは、ツール紹介記事の他にも、500社以上の課題解決の事例を発信してきました。

その取材を通して、目標を達成し続けるチームは「振り返りからの改善が習慣化している」という傾向を発見しました。

そこで「振り返りからの改善」を、botがサポートするWistant(ウィスタント)」というツールを開発しました。

「目標達成するチーム」を作りたいとお考えの経営者・マネージャーの方は、ぜひ、チェックしてみてください。

チームを目標達成に近づけるロボアシスタント「Wistant」無料トライアルはこちら

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet