Skip to content

Instantly share code, notes, and snippets.

@ssig33
Forked from mohemohe/20180906.md
Last active July 26, 2023 20:40
Show Gist options
  • Save ssig33/ff60e8a7ed50c5f3d5699a9dcc2cc9c1 to your computer and use it in GitHub Desktop.
Save ssig33/ff60e8a7ed50c5f3d5699a9dcc2cc9c1 to your computer and use it in GitHub Desktop.
M社の採用について

MoneyForward社のエンジニア採用について

自分がやめた時点でのバックエンドエンジニア採用フロー

  1. 各プロダクトの開発責任者1名(規模が大きい家計簿・会計は +1名)が採用担当者
  2. 応募が来たら各採用担当者が自分のチームにほしいかどうか(会いたいか会いたくないか)を決める
  3. 会いたい意思を出したメンバーからMAX4名までを面接官とする。4名以上いたらランダムで4名選出する
  4. 1名につき15 - 30分面接する(ので採用希望者は2時間くらい面接を受ける。。)
  5. 面接官は全員が面接を終えるまで、原則、評価を共有してはいけない。全員が終わったら、取る、他のチームならありえる、取らないの3択で評価を共有する
  6. 他のチームならの意見が面接官で一致していて、そのチームの担当者が面接官に含まれていないときだけエンジニア2次面接がある。それ以外であればそのままCTO面接
  7. CTO面接はカルチャーのフィットくらいしかみない。ので実質取るか取らないかは各チームの責任者に委ねられている

↑のフローになった経緯とか

  • 昔、人事が面接に出てきて〜〜みたいな記事がネットでバズったので、基本的にエンジニアだけで合否を決めることになった
  • 以前は一部のエンジニアが面接をしていたため基準が不明確だったので、どういう評価を出すかルール化した
  • チームによって求める人材像を出してみると、意外と求めることが全然違ったので各チームで代表者を出すことになった
  • 以前は4人中一人でも「取らない」の評価を出したら取らない制度だったが、とあるチームが例外で採用した人がチームにマッチしてよく機能していたので、誰かが「取らない」にしたら必ず落とすルールは廃止された

M社が遭遇した失敗パターン

人が足りないから、という妥協

積極的に来てほしいとまでは思わないが、悪くはないので採用、という判断をしていた結果、
エンジニアレベルに格差が生まれ、あとから入ってきた優秀なエンジニアと軋轢が生まれた
最終的にエンジニア文化の違いに耐えられなくなり、やめてしまった

  • どういう文化にしたいかの明確化は必須
  • 人が足りないという誘惑に負けない。悪くないから取るのではなく、来てほしいから取るの徹底

知識はあるがコードを書いてみると、、

面接では高評価だったが、いざ仕事についてもらうとオレオレコードを書く人だった
最終的にコードレビューを無視してマージするなどの横暴が見られたので面談が開かれたが、
最終的に文化の違いでやめてしまった

  • 誰もコードを確認していなかった
    • 面接の段階でホワイトボードコーディングをしてもらうか、githubを見る
    • M社では入社希望者のgithubアカウントを教えてもらうことが必須になった(なにもないから落とす、とかまではなくあくまで参考情報)
  • 会話の雰囲気だけで会社の文化にマッチしていると判断していないか確認が必要

評判だけで高評価採用

rubyの書籍を出したこともあるという話で、面接でも特に問題点は見つからなかったので当時のエンジニア給料平均の2倍近くの報酬で採用した
実際に仕事をしてみると(申し訳ないが、、)スキルの低い人だった
数年後、人事施策で給与レンジを定めることになった際にレンジから大幅に外れているにもかかわらず、評価が全く伴っていないという自体になった。
通常の給与レンジまで減給するかやめてもらうかしかないという厳しい面談をすることになり、結局やめてしまった。
その噂が広まり、給料を公開すべき/しないべき論争まで発展して大炎上した

  • スキルレンジと給与レンジをある程度決めておくべきだった
  • 本を書いてるから優秀、といったうわべの評価ではなく、実際のスキルを確認するべきだった
  • 優秀な人を金の力で採用する手段は何かが壊れる気がする。エンジニア給料がインフレしているので見劣りしない額は必要だが、通常ではありえない額は昇給で出すほうが低リスク
  • ちなみにM社では給与額はCTO以上が決めていたので、採用を決めてもいくらになったのかは不透明なままだった

採用関連でやっていたこと

内部向けにやっていたこと

会社としてどういうエンジニアがほしいのかブレスト

  • 参加者は各チームの開発責任者がmustでその他希望者
  • まずはどういうエンジニア文化にしたいのかを共有した
    • こういうのはいい、こういうのは嫌だとかざっくり
  • そのためにはどういう人が来てくれるとありがたいかを共有

チームごとに欲しい人像を決める

  • チーム内のエンジニア全員で話し合う
  • フォーマットにしたがって具体的にどういう条件が必要かをまとめて記事を共有

本読む

この辺を読んでいる前提でいろいろ会話されていたと思う...

外部向けにやっていたこと

エンジニアブログ

  • 当番制で毎週誰が書くかローテされていた
  • ローテ以外でも書きたい人が書くのはOK
  • だんだんネタがなくなって書かなくなっていった...
  • 採用受ける側からしたらあったほうが印象が良い。書く意欲がある人がいるならやるべき

チーム紹介、エンジニア紹介の記事を作る

Rubyのコミッター採用

  • 知名度や露出機会の増加には相当効果があった
  • 技術に強くない企業相手なら技術力の証明としてのセールストークにも使えた
  • コミッターの方がいい人だったのでRuby以外でも技術的相談に乗ってくれたりしていた
  • Rubyへのロックイン感は否めず

カンファレンス等のブース展開、協賛

  • 名前が売れるのと現地で興味持ってくれたエンジニアが入社したということもあった
  • ただ、ブースにずっと人がいないといけなかったりかなりエネルギーを使う

FAQ

何人くらい受けに来て何人くらい通ったか

月に5 - 20くらいは来ていた
多分30人に1人くらいしか合格していない。年間で10人くらい

どこから来ていたか

主にエージェント、wantedly、紹介
エージェントは高い割に質が微妙だった
紹介が圧倒的に質が高いので、そもそもエンジニアネットワークが広い人を採用するのがよい

フロントエンド、スマホ、インフラエンジニア、デザイナーはどうしていたか

基本的にどういう人がほしいかチームで議論して記事を書くところまでは共通
どういう面接フローにするかはそれぞれバラバラ
(例えばインフラエンジニアは1対多メンバーで1時間面接等)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment