エンジニア採用どうしてますか?

これは

qiita.com

こちらのアドベントカレンダーの9日目の記事です。*1

はじまり

採用に関してここ数年、新しい動きをしていない。
何が正しいとか、何が間違っているかではないと思うけれど、なんだか自分が凝り固まっているんじゃ?という思いと、同様に考えている方がいたら一緒に考えられたらな。と思い書き出してみる。

皆さん、採用どうしているのでしょうか。
自分は社員採用する前に一緒に働くような「お試し採用」をちょっと試したいなと考えています。

前提

ざっくりこういうような組織での採用についてのお話。

組織規模

会社全体:50人〜200人
エンジニア:10〜50人
走っているプロジェクト:大小合わせて3~10

業務内容

Web寄りのプロダクト開発。
自社開発もしくは、受託も無くはないが協業という形である程度の制約、要求がある中での開発。
toC事業が主流。

最初に懺悔しとく

面接なのに1on1や進路相談みたいになることがある…。
これって「不採用です。」って、その場で言っているようなものだよね…。

技術を通して、やりたいことがある人を採用する。

事業に直結しないまでも社会的に活用される技術や活動を考えて行動している人を採用するようにしている。
逆の場合は、時間もお金もただ消費するだけだと思っている。

やりたいことがある人は、そのやりたいことを話し合えば必要なことを自発的に考えて行動してくれる。
組織的に定義づけられた自分の役割があったとしても、それを越えて行動してくれる。*2

「開発やりたいです。」みたいな、開発で得られることが出てこない人は、それ以外はあまり興味がなかったりする。
そうなると、事業だったりチームだったりと目的意識があっていないから*3組織的に動きづらく、成果としても良い結果が出づらくなってしまう。

面接のときにこういう発言をされた場合、念の為、突っ込んで質問をしている。
「どんな開発をやりたいのか。」
「開発の結果なにが得られるのか。」
「なんのために開発をするのか。」

ただし「開発やりたいです。」みたいな人も、手数が欲しい時や組織の方向性として特化した技術力が必要になる場合には必要な人であると考えてもいる。
手数の話は言うまでもないが、技術のアウトプットの質は、インプットを大量にした結果だと思う。
高度な質を求めるには、その技術に常に探求している必要があると思う。
しかし、常に高度な質を求めるか?というと違うことがわりかし多いと思っている。

いや、実のところ手数だとしても管理コストがかかってきたりするから止めたほうがいいと思っているんだけれどね。

正社員の場合は、組織構造を考えて採用をする。

正社員は会社を組織するメンバーになる人を採用する。
突発的なプロダクトに起因する理由などでは採用しない。
会社の事業戦略(明確なものが無かったとしても短期的にでも想定しうる計画に基づいたもの。)に合わせて人員計画をたてて採用を行う。

チームの目標は何か、その目標はいつ達成させるのか。
そのために必要なパフォーマンスは?そして、どんな人で何人構成にするのか。
誰をマネージャーにすえるのか、それをチームごとに時系列で考える。

採用から話はずれるが、プロダクトが無くなった場合のことも念の為考慮しておくこともある。
これは本当に動きづらい。

会社全体でもプロダクトのチームでも受け入れの準備も出来ていないのに人を入れることと、活動の方向性が散らばらないように所属人数と新人の方の人数比が3:2みたいになるような受け入れ方は避けたほういいと思っている。*4

突発的だったり(突発的なのは極力避けたいんですけれどね。)、準備が出来ていないがどうしても助けが必要、特定の技術力が必要という場合だけ、派遣の方や外注の方にお願いするように心がけている。(心がけている。)

契約の分だけ助けてもらってその分しっかりお支払いをする。

一緒に働く人が面接をする。

主にエンジニアだが、ポジションに寄っては営業の方や事業部?の方などにも面接してもらう。
エンジニアは入る想定のチームに拘らず、マネージャーだったりメンバーだったり、チームが解散したとしても引き続きその組織で働けるかどうかを意識している。
何度も足を運んでいただくのも申し訳ないとは思いつつも、間違いに気づくなら早いほうがいいとそのようにしている。
なので時には、四次、五次みたいな場合もでてくる。とはいえ、無駄に回数は重ね無いように、面接の順番を組んでいる。

組織によっては、人事の方が採用を決めたりする所もありますよね。
組織構造も人事の方が考えていたりする場合も。
エンジニアに限らずクリエイティブな業務の場合、人事の方が決めるのには懐疑的です。

「開発という手段で活躍はしたいですけれど、それによって得られる結果はこのプロダクトじゃないんです。」とか「本当は、開発もしたいわけじゃない。」みたいな人が入って来たときの不幸ったらありゃしない。

もしそういう組織があったとしたら、人事の人に声をかけて一緒に活動するようにするのが組織としても採用される側にとっても良いだろう。

技術的スキルは重要だけれど…。

経験年数が長いのに技術力無い方は厳しいけれども、現状の技術的スキルよりはどういう積み方をしているかを重要視している。
技術的移ろいも勿論あるけれども、事業的変化も多分にあるので、変化に対応する力というところが大切だと考えてのこと。

こういう時に「ネットを調べてます」"だけ"の人は苦手。大して知識吸収もしてなければアウトプットもしていないことが多い。
ネットの場合はピンポイントで必要な知識しか調べられないので知識の広さ深さが足りないと思う。*5
本や勉強会などに参加したり、自分でプロダクトを作たりして少しでも見てもらえているような人がよい。

少し話はそれるが、01の経験やリリース経験、リリース後の運用経験、クローズ経験なども頼もしいスキルだと思う。

この先、対応してくれるか、成長してくれるか。が大切だと思っている。
とはいえ、見るっちゃみるけれどね(汗笑

採用フローは定形はありつつも臨機応変に対応する。

メンバー採用の場合
一次面接:エンジニアマネージャー+メンバー
二次面接:エンジニアマネージャー+メンバー
三次面接:役員

マネージャー採用の場合は
一次面接:エンジニアマネージャー+メンバー
二次面接:エンジニアマネージャー or メンバー + 非エンジニアマネージャー
三次面接:役員

とはいえ形に拘らず、互いに納得できるよう繰り返し情報交換をする。
回数が多いと他社に負ける。みたいな場合は、
そもそもマッチングが他社よりスムーズにいかなかったのだから正しい結果だと思う。

採用活動

長くなるから省略…。
でも、一番はリファーラルだと思う。

終わりに「採用の一つ一つを大事にする。」

採用するにせよ、お断りするにせよ、お互いの人生が大きく変わるタイミング。
どちらにせよ自分もよい人生を送りたいし、相手の方にも良い人生を送ってほしい。

同じ方向を向いているなら一緒に頑張れるし、
違う方向を向いていたとしても「またどこかで」と言い合える。

そんな採用活動を心がけたいものだと思っている。

*1:書くの忘れてたので追記

*2:なんて素晴らしい人なんだ!! しかし、こういうタイプの人は積極的である反面あれもこれもと抱え込んでしまったり、その人にフォローされるが故に周りがあるべき役割を果たさない負荷のバランスが悪い組織になったりしまうので、 適宜、仕切る必要がある。

*3:"開発"がやりたいのはエンジニアだけ。

*4:とはいえ、事業をグロース、チームをスケールさせたいときもあるだろうから、そこは自分なりの覚悟を持って進める。

*5:下手したら間違っていることもある。