ブログ

ryuzeeによるブログ記事。不定期更新

採用プロセスを真剣に考えろという話

人材流動性の高まりを日々感じているみなさんこんにちは。

最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。

ポイント

▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか?」

  • 悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません
  • …だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう

▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか?」

  • 期待値を明文化しているかを確認すること。すなわちJob Descriptionがきちんと書けているかどうか
  • インタビューをする人がその職種で期待することを全員理解しているか、候補者の何をチェックするのかを明らかにすること
  • 採否に悩んだ場合に、「人が足りない」という理由で採用していないか

▼「採用のインタビューが多すぎて他の仕事が進まないんですが、どうしたらよいですか?」

  • 採用のプロセス決めること
  • 採用は社員の大事な仕事の1つ。特に優秀な人・評価の高い人ほど採用に時間を使うべき。優秀な人は優秀な人を見極める力があることが多い
  • 片手間でできるほど採用は軽い仕事ではないので、他の仕事が忙しいならそれをオフロードすること

▼「自分や現場が良いと思った人が、人事部の面接とかで落とされてしまいます。どうしたらよいですか?」

  • 採用で怖いのは、良い人を落としてしまうことよりも「悪い人を採用してしまうこと」であるのを肝に命じる
  • スクリーニングの結果は0/1で仕方ないが、その後の意思決定プロセスは合議制にすることを考える。人それぞれ持つ意見も違う
  • もし合議で判断がつかなかったら安全な方に倒す(採用しない)か、または追加でインタビューを設定すること
  • 全力を尽くしてそれでもダメなら最後は結果を受け入れること

▼「特定の人がインタビューするとザルのようなのですが、どうしたらよいですか?」

  • 採用のメトリクスを取ること。それを定期的に分析すること
  • 例えば候補者数、スクリーニングを通った数、それぞれの社員がインタビューした回数、OK/NGの投票結果の分布
  • いつも通してしまう人はJob Descriptionを見ていないとか、自分が採用の人数の責任を背負っていて通したいか、そもそも判断できていないか、のような理由による
  • 逆にいつも落としてしまう人がいる。その人の場合は期待値の確認ができていないとか、過度に高望みしている可能性もある。フィードバックの中身を確認するとよい

▼「打率が低くて泣きそうです」

  • 人が会社の命運握っているのだからある意味当然
  • 自分の会社の出せる条件と求めている要件があっていない可能性はもちろんある
  • 優秀な社員が紹介する人は優秀である、という法則があるので、採用されたらボーナスを出すという形で社員紹介による候補者の母数を増やす

▼「優秀なんだけど文化にあわない人を採用すべきですか?しないべきですか?」

  • It dependsではあるが、個人的には採用しないべきと考える。もちろん「文化もへったくれもなくどっかに送り込める頭数がいればいいだけなんだ」と言われたら好きにしろになる
  • 文化や信頼を醸成するには非常に長い時間がかかるが、壊れるのはあっという間であるという事実を踏まえる

▼「現時点では必要なスキルはもっていないけど文化にはとてもあう人を採用すべきですか?しないべきですか?」

  • そのポジションで要求されることができないのであれば、そのポジションでは採用すべきではない
  • 他のポジションや下のポジションでフィットするところがあれば、そのポジションで検討する
  • その時採用しなくても、数年後にはポジションにあうかもしれないので、定期的にコンタクトするのも良い

▼「インタビュー開始後すぐにダメだと思ったのですが、早く切り上げてよいですか?」

  • 特にスクリーニングの場合はそういうこともあるが、あらかじめプロセスで決めた時間はやった方がよい
  • なぜならその人が今すでに自社のお客さんだったり将来のお客さんだったりする。サービスのお客様と同様に扱うこと
  • 同じ理由で圧迫面接みたいなことは絶対しないこと
  • 悪い点ではなく良い点も探すこと

▼「採用いろいろ面倒くさそうなんだけど、そういうのは人事部が考えればいいんじゃないの?」

  • だったら配属されて来た人がイマイチだったり、チームのメンバーがどんどん他社に転職しても文句いうな

以下、有名どころの採用プロセスを参考まで。

Facebookの採用プロセス

  • 初期スクリーニング
  • 最初にリクルーターによるPhone Screenでスクリーニング
  • それを通れば同僚となる人間によるインタビューをおこない、結果がよければオフィスでの対面インタビュー(Loopへ)
  • インタビューの1スロットは45分。技術者の場合はコーディングにも時間が割かれる
  • 特にデザイナー職などの場合は採用プロセスの初期の段階で過去の制作物を確認する
  • ループインタビュー
  • オンサイトで1日に複数のインタビュー。ホワイトボードでのコーディングもあり
  • NDAを締結する
  • 意思決定プロセス
  • 各インタビューの結果は社内ツールに入力される
  • サマリーやフィードバック、書いたコード、Hire/No Hireの投票が含まれる(4段階)
  • 他の人の入力結果は自分の入力後に見える
  • 結果はまとめられて、1人ごとにマネージャーのミーティングで採否を議論する
  • そこで結論がでない場合はフォローアップインタビューがおこなわれる
  • 重視されている項目
  • 上位レベルの学位は必ずしも必要ではない
  • チーム作業ができるかは重要
  • 良い人を見つける方法は、自分が良いと思ったプロダクトを作っている人を探すこと
  • 熱意・好奇心・モチベーション・ジェネラリズム・アーキテクチャー・コーディング力
  • 参考リンク
  • https://www.facebook.com/notes/facebook-engineering/get-that-job-at-facebook/10150964382448920/
  • Ten Things to Know Before Interviewing at Facebook
  • What happens after an onsite interview at Facebook?

Googleの採用プロセス

How Google Works読めという話ではある。毎年200〜300万人の応募に対して5000〜8000人の採用なので採用率は0.2〜0.4%。その中の10%以上は大学の学位を持っていない。

  • リクルーターによるスクリーニング
  • リクルーターがそれぞれのレジュメに目を通し、技術的なバックグラウンドやGoogleにあうかどうかを確認する。その時点であわないと思われた場合でもそのレジュメは保管され新しいポジションが空いた場合などに再度確認する
  • スクリーニングの結果あうと思われればPhone Screeningに進める
  • Phone Screening
  • リクルーターが候補者にコンタクトし、ポジション・プロセス・期待値などの説明をする
  • 同じ職種の社員によってPhone Screenは実施される。長さは通常30分
  • 複数回行われることもある
  • 技術職の場合は、GoogleDocsなどにコードを書くことが求められることもある
  • オンサイトインタビュー
  • 4-5人とそれぞれ45分間インタビューをする。インタビューワーには類似職種やマネージャーが含まれる
  • ここでも技術職の場合、ホワイトボード上でのコーディングなどを求められる
  • 他の職種の場合でも、例えばPRの場合だと、PR文書を書くといった実作業を求められる
  • 意思決定プロセス
  • インタビューの結果は規定のフォーマットで入力する。そこでは複数の項目で採点(ランキング)付けされる
  • リクルーターにフィードバックが集められ、他の候補者と比較する
  • Google内のデータベースを検索し社員の中で過去に同僚だった人を探しだし、意見を求める
  • 最終的にオファーを出すか出さないかの意思決定をする
  • オファーを出すことにしたら、採用委員会に諮る。採用委員会はディレクターやシニアマネージャもしくは特定領域のスペシャリストから構成されている
  • そこでは全てのフィードバックに目を通し、そこでOKであれば、エグゼクティブレビューにかける
  • エグゼクティブレビューでは全てのオファーに目を通し、そこでOKなら報酬委員会にかけて総報酬額の承認を得る
  • その後最終のエグゼクティブレビューを実施する。これはどれだけ採用が重要であるかのメッセージにもなる
  • 重視されている項目
  • グーグルらしさ
  • リーダーシップ
  • チームプレイができるか
  • 個々のロールに必要なスキル。たとえばエンジニアであればコーディングスキル
  • 学位などよりも物の考え方を重視
  • 大きな挑戦ができるか、変化を好むか
  • 短期的ではなく長期的にみてGoogleにとって好ましいか
  • その他
  • 採用は社員全員の仕事であり、社員はインタビューなどの採用活動は仕事の一部として責任をもって実行する必要がある
  • 紹介した人が採用された場合はボーナスが手に入る
  • インタビューワーはインタビューのフィードバックを書くが、その書き方や内容についても社員にフィードバックがなされる
  • 採用の意思決定は委員会でおこなわれるので、ハイアリングマネージャー(一般的にはそのポジションをオープンしたマネージャー)によって意思決定されるわけではない(人が足りなかったりすると悪い判断をしがちなので…)。
  • 本当によい人だけを採用しムリしてポジションを埋めない
  • 参考リンク
  • http://www.google.com/about/careers/lifeatgoogle/hiringprocess/
  • http://dondodge.typepad.com/the_next_big_thing/2010/09/how-to-get-a-job-at-google-interview-questions-hiring-process.html

日本の普通の会社の採用プロセス

ステレオタイプな感じだと以下のようになる。

  • 人事部が応募を受領し、初期のスクリーニングを実施
  • スクリーニングが通ったら、ポジションをあけている部門にレジュメを送ってインタビューするかどうかを当該部門に決定してもらう
  • 当該部門の人がインタビュー。少ない場合はマネージャーと一回だけ。多い場合はリーダークラス1人とマネージャー
  • 上記を通過すると人事部長とか役員とインタビュー
  • 多くの場合、どこかでNGが出るとそこで完全終了で、合議制で候補者のPros/Consの確認や採否の議論がなされることは少ない(だからダメなんだよ…)

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック