"優秀なエンジニアを採用したい"とは
煽りタイトルでごめんなさい。笑
Noteを始めた所、次のようなリクエストを頂いたので、僕の観点でエンジニア採用のポイントについてお話します。
自分の採用の経験
楽天でTech Lead, EMを始めた頃から採用面接に携わっています。
今はWealthParkのVPoEとして、エンジニアの採用プロセスには全て入っています。
おそらく特徴としては圧倒的に海外のエンジニアのInterviewをした回数の方が多いこと、海外で働いている方の面接をすることが多いので、リモートでの面接に慣れていることが特徴だと思います。
優秀という言葉の危うさ
まず、これはやや非エンジニアや、エンジニアの採用に対して一定のメッセージを発信する経営層、人事担当者に向けたメッセージですが、"優秀なエンジニアを採用したい/してほしい"というメッセージは基本的には使わない方が良いです。(バックグラウンドやコンテキストが十分に共有されている場合、その限りではありません。)
理由は至極明確で、"優秀の定義って?"ってなるからです。こんなのエンジニア10人に聞いても絶対そろいません。ブレます。コンフリクトします。結果何かしらのベクトルでは優秀なエンジニアがフィットせず、パフォーマンスが出ないというケースの温床になります。
結局の所、優秀は会社 or ポジションが 大切 or 必要としている要素にどれ位フィットしているか、そのフィットしている項目のレベル(スキル)がどれほど高いか、に着地するケースが多いと考えます。その為、"会社 or ポジションが 大切 or 必要としている要素"これを明文化することが大切であり、その共通認識がある場合のみ優秀という言葉はワークすると思います。
例えば、メルカリさんのEngineering Cultureのページには、次のように優秀という言葉の定義が書いてあります。但し、メルカリさんでは、「優秀な人が生み出される組織」を目指されていて、優秀な人を採用する、という主旨ではないです。
メルカリが定義する「優秀な人」とは、「数々の挑戦を経て、感性と判断能力を研ぎ澄まし、理想を現実にできる人」を意味します。
例え今の会社のフェーズに合ってなくとも優秀な人はいるので、やっぱり優秀という言葉を採用の観点で使う必要はあまり無いと個人的には考えています。
さて、では実際にどのような指標が例えばあるのでしょうか。
実際は、スキルの中とかはめちゃくちゃ深ぼることだとは思いますが。
- スキル
- 経験
- ポテンシャル
- マネジメント
- チームワーク
- 問題解決力
- 仕事の適性
- マネジメントとの適性
- カルチャー
- モチベーション(やる気ある)
などに傾斜をかけてみるのが(1-5点くらいで傾斜)なにが大切かを考える上で一旦分かりやすいと思います。何人かでやっていると、あ、この人はスキル高いひと求めているんだとか、この人は色んな問題に柔軟に対応できる人を求めているんだな、とか分かってきます。なので、自分の頭の中で整理してみるのも、人事とエンジニアの責任者の方がやってみるのも、エンジニア何人かでやってみるのも良いと思います。
そういうところから意識を揃えたり、議論していって、段々計算式とかを組んでいくと、何かが見えてきます。そして、どこからこのポジションはこの式でとか10点満点にして7-8点以上目指したいとか、そういう微調整をしつつ、自分たちが今何を大切にしているかをアップデートしたら良いかと。ただ、個人的にはあくまで"自分たちが今何を大切にしているか"を知ることが大事で、最終的な採用基準をこの点数でやるかはケースバイケースだと考えています。
良い環境で高いパフォーマンスを発揮する人と、環境そのものを良くできる人は違う
これは全ての会社で気にするトピックではないと思いますが、結構直面した場面が多いです。
言葉の通りです笑。
例えば、特定の専門領域について非常に強い知識をもっていて、(分かりやすさの為に)例えば、GAFAなどである程度整備された環境、プロセスでその専門領域に特化して仕事していたAさんがいたとします。
一方、その方を採用した会社は、環境としては改善の余地が多く、例えばレガシーな技術を使ったプロダクトが多くある、要件定義が曖昧、ややウォーターフォールな風潮が残っている状態だったとします。
もしも、採用する側が、Aさんに対して、このような環境を改善し、GAFAのような環境を作ってほしいという期待値をなんの気無しに持っていて、面接時ではあくまでスキルにばかり着目したとするならば、入社後、上手くいかない可能性はそれなりに高いでしょう。
※これは決してGAFAのような職場で働いていた人や、専門領域に特化していた人が、環境を改善できないという意図ではありません。
※実際はAさんの方がその期待値のギャップを汲み取るケースもあるでしょう
環境を良くしていくコンピテンシーを発揮するには、高いソフトスキルもしくはマネジメント層によるサポートが必要ですし、良くすることに対するモチベーションも必要です。
そうすると、何が起きるかというと
A : 「この会社はなんてイケてないんだ。レベルも低いし。仕様も曖昧だし。。」
採用担当者, マネジメント : 「Aさんにこの環境を改善してほしいと思っていたが、一向に改善しないな・・」
なんてことが起こります。これは典型的なミスマッチングですが、日本のスタートアップではこのケースが比較的多い気がします。特に序盤からスキルセットの高いエンジニア中心にプロダクトを開発してこれなかった場合このニーズのミスマッチングは起きやすい感覚があります。
これはお互いにとって良く無いので、正直に面接で聞いてみてもいいですし、BEI(Behavioral Event Interviewing/行動特性)やPSQ(Problem-solving Question/問題解決)、MSA(Most Significant Accomplishment/実務での最も重要な達成)を活用して、ケーススタディ的に環境改善に対して、その人がどのようなアプローチの行動をとるか、問題解決を図るかを確認するのが良いと思います。
BEIの例 : 利害がコンフリクトした場合, どのようにあなたはその場を収束させますか?
(実際は具体的なポジションや履歴に合わせて最適化する)
-> 行動特性をみる
PSQの例 : 弊社の重要なプロダクトの1つである、管理画面のリニューアルを予定しています。あなたがそのプロジェクトの責任者にアサインされた場合、どのような手順や状況を考慮して管理画面のリニューアルを進めていきますか?
- 何からはじめますか?
- 大体どのポジションの人何人くらいでやりますか?
- なぜリニューアルが必要だと思いますか?
- もっとも大事にすることはなんですか?
- 納期と品質のトレードオフが必要になった場合、どのような選択をしますか？
などなど(いくらでも質問出せると思います)
(実際は具体的な会社の仕事に限りなく近いケースが良い)
-> 問題解決能力をみる
MSAの例 : 上記のPSQと同じような問題解決を発揮した、実際のプロジェクトはありますか？もしもそういった経験があれば、プロジェクト概要、その時抱えていた問題とそれに対するあなたの具体的なアクションについて教えてください
-> 問題解決の実行例をみる
この質問は
良い環境で高いパフォーマンスを発揮する
かどうかをみるのにも勿論利用できます。良い環境で働いていれば、より局所的で高度な問題に挑戦している可能性が高いです。質問の具体例を帰ればそちらのユースケースでも使えると思います。
Job Descriptionにストーリーを明記すること
上のような面接時の質問に加えて、JD(職務記述書)をストーリーを含めて書くことで、応募者にメッセージを伝えることが出来ます。
WealthParkで1ポジションを例にとって説明します。
ここでは、ちょっと変わった募集しています(Ruby + Go)。中身を読んでいただけると分かりますが、ざっくりいうならば、スキルという観点であればRubyのスキルがあり、かつGoのスキルがある / もしくはGoを実務として経験することに強いモチベーションがある方を募集しています。
かつ、レガシーなプロダクトを管理・改善していくことに対するこちら側の期待値を明記しています。これを、単純にバックエンドエンジニア(RubyまたはGo)あるいはそれぞれ別々に募集をかけることで、それぞれのエキスパートは採用しやすくなります。もちろん、各専門分野においてスキルが高いことはこの上なく望ましいですが、このポジションにおける、僕らが一番達成したいパフォーマンスプロファイル(具体的な成果目標)は、アーキテクチャの変更をドライブできる人材であり、各言語を突き詰めるエキスパートではないのです。(※語弊を防ぐ為にいうならば、Goのエキスパートについては今後採用ポジションを出す可能性はあります)
このJDから分かる、RubyやGoを使う以上の情報としては
- Rubyの技術/知識は必要だが、最終的にはRubyを業務として使わなくなる可能性がある
- Golangを利用した開発に携わるチャンスがあり、またそれに対する期待値はRubyに対して求める技術/知識よりは敷居が低い
という2点です。
これによって、ある程度利用するスタックについての具体的なイメージが持てることと、バックエンドの主な言語を変えたい、変えてみたいと考えている方には刺さることがあります。(元に、このJDの内容を魅力に感じて応募して下さった方もいらっしゃいます)
こちらは、結構極端な例ですし、毎回ここまでの特色を出す必要もないかもしれませんが、単に技術スタックとプロダクト紹介を行うだけではなく、ストーリーを混ぜることで、何を何故やってほしいか・こういう人をうちの会社を求めている、ということを伝えることができると思います。
採用は漸進的であること
前回の記事と同じ言葉を使っていますが、アーキテクチャと同じく、組織も漸進的に変わってきますし、必要な人材はタイミングタイミングで変わってきます。例えば、先のあまり整っていない環境がある程度整ったことで、最新の技術スタックのエキスパートを採用したいというニーズや、優先度があがったりすることがあります。
優秀な人だからいつでも入社してほしい、という建前はたしかにあるのかもしれませんが、専門領域や活躍の領域が明確にある方ほど、その力をベストで生かせるタイミングは変わってきます。
現場の意見を聞きつつ、今彼らが必要としている領域とそうでない領域を見極めることは必要でしょう。
あるべき組織を考える
一方で、マネジメント観点でいうと、常に現場が欲しい人材のみを採用するのが最善でない場合はあります。例えば、自分のマネジメントの領域が過度に及ばなくなるサイズまで組織を大きくしたくない現場や、人によっては自分よりも優秀な人とのコンフリクトを恐れるケース、あるいは、自分の干渉領域が狭くなることを恐れるケースなどは、正直あります。
現場とのコミュニケーション、新しい人を入れるタイミングで発生しうるハレーションには最新の注意を払いつつ、組織としてこうしていきたい、こうあるべきだというメッセージをマネジメントから発信し、べきろんの組織図と現場のニーズを組み合わせる必要があります。
履歴書で僕が気にすること
ポイントを凄く絞るなら、プロジェクトに関しては書いてあることの中で、"その人がやったこと"と"その組織がやったこと"を区別していく。大体の場合、プロジェクトの内容そのものが書いてあるけど、実は本人がやったことはそのうちの1部であるというのが大抵の場合。新しい技術で新しいプロダクトを作ったとしても、ベースを他の人が作って、その上に乗っかって機能の実装をしたケースと、スクラッチから書いた人とかで答えられることは違う。あとは、自分が実装していない所だとしてもどれ位概要を理解できているかは気にする。"認証は僕の担当じゃないから全く分かりません"ではなくて、OauthでGoとHydraを利用していて作られていて、僕らはこういう使い方をしています、loggingやAPI Docは共通の仕組みでやっています。ただ、内部の実装には携わっていません。"の方が良いです。
プロジェクトについて確認する場合は、自分ごとで考えているかどうかをみます。
-> 履歴書とは別に、スキルチェックは必ず必要です。どんなにプロジェクトに対する受け答えが良くとも、スキルそのものに対するチェックは必ず入れてください。プログラミング言語に関する質問など
Github
Open Sourceへの明らかなコントリビューションがあれば確認。自作のプロダクトで気になるものがあれば確認。ちゃんと使ってる人ならPRの書き方とかも見れるので尚良い。仕事でgithub使ってたら草生えまくるの当たり前なので、草がどれ位生えてるとか気にしない。必須でもない。
逆に言えば、あのGithubでスコアリングする方法、あんまり使えない気がするんですよね。超貢献している人はそれはスコア高いと思いますが、そういった方のことは知っていたり、別の所で見かけたりするので。
なので、非常に多いエンジニアのなかからGithubの活動で欲しいエンジニアフィルタリングするの結構難しいんじゃないかなって思ってます。
参考資料
この記事の内容が響いた方は、次の本を読んでみることを強くおすすめします。
グローバル人材と銘打っていますが、あんまグローバル関係なくというか、
普遍的に使える情報が非常に良くまとまっているのでおすすめです。
最後に
WealthParkでは、エンジニア、エンジニア以外の職種も含めて幅広く募集しております。是非一度JDを読んでいただき、興味があるポジションがありましたら、是非！エンジニアの方で、僕とカジュアルに話してみたい方とかもいらっしゃいましたら、気軽にご連絡下さい。
この記事が気に入ったらサポートをしてみませんか？