M社のエンジニア採用について
自分がやめた時点でのバックエンドエンジニア採用フロー
- 各プロダクトの開発責任者1名（規模が大きい家計簿・会計は +1名）が採用担当者
- 応募が来たら各採用担当者が自分のチームにほしいかどうか（会いたいか会いたくないか）を決める
- 会いたい意思を出したメンバーからMAX4名までを面接官とする。4名以上いたらランダムで4名選出する
- 1名につき15 - 30分面接する（ので採用希望者は2時間くらい面接を受ける。。）
- 面接官は全員が面接を終えるまで、原則、評価を共有してはいけない。全員が終わったら、取る、他のチームならありえる、取らないの3択で評価を共有する
- 他のチームならの意見が面接官で一致していて、そのチームの担当者が面接官に含まれていないときだけエンジニア2次面接がある。それ以外であればそのままCTO面接
- CTO面接はカルチャーのフィットくらいしかみない。ので実質取るか取らないかは各チームの責任者に委ねられている
↑のフローになった経緯とか
- 昔、人事が面接に出てきて〜〜みたいな記事がネットでバズったので、基本的にエンジニアだけで合否を決めることになった
- 以前は一部のエンジニアが面接をしていたため基準が不明確だったので、どういう評価を出すかルール化した
- チームによって求める人材像を出してみると、意外と求めることが全然違ったので各チームで代表者を出すことになった
- 以前は4人中一人でも「取らない」の評価を出したら取らない制度だったが、とあるチームが例外で採用した人がチームにマッチしてよく機能していたので、誰かが「取らない」にしたら必ず落とすルールは廃止された
M社が遭遇した失敗パターン
人が足りないから、という妥協
積極的に来てほしいとまでは思わないが、悪くはないので採用、という判断をしていた結果、
エンジニアレベルに格差が生まれ、あとから入ってきた優秀なエンジニアと軋轢が生まれた
最終的にエンジニア文化の違いに耐えられなくなり、やめてしまった
- どういう文化にしたいかの明確化は必須
- 人が足りないという誘惑に負けない。悪くないから取るのではなく、来てほしいから取るの徹底
知識はあるがコードを書いてみると、、
面接では高評価だったが、いざ仕事についてもらうとオレオレコードを書く人だった
最終的にコードレビューを無視してマージするなどの横暴が見られたので面談が開かれたが、
最終的に文化の違いでやめてしまった
- 誰もコードを確認していなかった
- 会話の雰囲気だけで会社の文化にマッチしていると判断していないか確認が必要
評判だけで高評価採用
rubyの書籍を出したこともあるという話で、面接でも特に問題点は見つからなかったので当時のエンジニア給料平均の2倍近くの報酬で採用した
実際に仕事をしてみると（申し訳ないが、、）スキルの低い人だった
数年後、人事施策で給与レンジを定めることになった際にレンジから大幅に外れているにもかかわらず、評価が全く伴っていないという自体になった。
通常の給与レンジまで減給するかやめてもらうかしかないという厳しい面談をすることになり、結局やめてしまった。
その噂が広まり、給料を公開すべき/しないべき論争まで発展して大炎上した
- スキルレンジと給与レンジをある程度決めておくべきだった
- 本を書いてるから優秀、といったうわべの評価ではなく、実際のスキルを確認するべきだった
- 優秀な人を金の力で採用する手段は何かが壊れる気がする。エンジニア給料がインフレしているので見劣りしない額は必要だが、通常ではありえない額は昇給で出すほうが低リスク
- ちなみにM社では給与額はCTO以上が決めていたので、採用を決めてもいくらになったのかは不透明なままだった
採用関連でやっていたこと
内部向けにやっていたこと
会社としてどういうエンジニアがほしいのかブレスト
- 参加者は各チームの開発責任者がmustでその他希望者
- まずはどういうエンジニア文化にしたいのかを共有した
- こういうのはいい、こういうのは嫌だとかざっくり
- そのためにはどういう人が来てくれるとありがたいかを共有
チームごとに欲しい人像を決める
- チーム内のエンジニア全員で話し合う
- フォーマットにしたがって具体的にどういう条件が必要かをまとめて記事を共有
本読む
- ワークルールズ
https://www.amazon.co.jp/dp/B010UV1QTW - How Google Works
https://www.amazon.co.jp/dp/B00OJVMK5O - シンプルに考える
https://www.amazon.co.jp/gp/product/B00Y2F7818
この辺を読んでいる前提でいろいろ会話されていたと思う...
外部向けにやっていたこと
エンジニアブログ
- 当番制で毎週誰が書くかローテされていた
- ローテ以外でも書きたい人が書くのはOK
- だんだんネタがなくなって書かなくなっていった...
- 採用受ける側からしたらあったほうが印象が良い。書く意欲がある人がいるならやるべき
チーム紹介、エンジニア紹介の記事を作る
- https://moneyforward.com/engineers_blog/2017/02/14/mf_interview7/
- https://www.wantedly.com/companies/moneyforward/post_articles/82920
- ↑こういうの。記事を作っていたのは広報の人（人事部所属で採用広報という担当だった）
- インタビューから記事起こしまでは結構大変で時間がかかる。片手間だと難しいと思う
- どういうバックグラウンドの人たちが何を思って何をやっているのか、ということを伝えることが目的
Rubyのコミッター採用
- 知名度や露出機会の増加には相当効果があった
- 技術に強くない企業相手なら技術力の証明としてのセールストークにも使えた
- コミッターの方がいい人だったのでRuby以外でも技術的相談に乗ってくれたりしていた
- Rubyへのロックイン感は否めず
カンファレンス等のブース展開、協賛
- 名前が売れるのと現地で興味持ってくれたエンジニアが入社したということもあった
- ただ、ブースにずっと人がいないといけなかったりかなりエネルギーを使う
FAQ
何人くらい受けに来て何人くらい通ったか
月に5 - 20くらいは来ていた
多分30人に1人くらいしか合格していない。年間で10人くらい
どこから来ていたか
主にエージェント、wantedly、紹介
エージェントは高い割に質が微妙だった
紹介が圧倒的に質が高いので、そもそもエンジニアネットワークが広い人を採用するのがよい
フロントエンド、スマホ、インフラエンジニア、デザイナーはどうしていたか
基本的にどういう人がほしいかチームで議論して記事を書くところまでは共通
どういう面接フローにするかはそれぞれバラバラ
（例えばインフラエンジニアは1対多メンバーで1時間面接等）
