- 公開日
『その「エンジニア採用」が不幸を生む』を読んだ ~優秀エンジニアをどう採用するか~
目次
エンジニア採用について最近いろいろ考える機会が増えたので読んでみた。
本書の概要
本書ではIT分野で人材採用のコンサルタントとして活動している著者が、「エンジニアと企業のミスマッチ」はどうして起こるのか、それをどう解決していったらよいのかを紹介している。
本書前半部分ではイケてない会社やエンジニアの採用失敗例および就職失敗例が紹介されており、後半部分では企業サイドがどうエンジニアを惹きつけ採用に結びつけたらよいかの話が書かれている。
エンジニアと企業のミスマッチ
本書では下記のようにエンジニアが特性に応じて２タイプ・４分類に分けられている。
どんなに採用対象となるエンジニアが優秀であろうと、会社にフィットしないこともあるので気をつけなければならないと著者は警鐘を鳴らす。
これは確かにそうで、例えばどんなに優秀なSI系システム開発エンジニアであろうとも、SIとは全く毛色が異なるWeb系企業に就職したとして即戦力ですぐ活躍するイメージは湧かない。逆に、小さな企業でずっとゆるふわに開発をやってきたWeb系エンジニアがSI業界に飛び込んだとして、すぐに活躍できるイメージも湧かない。
また会社のアーリーフェーズにおいて人も少なく新規開発が多い場面においては、エンジニアはフルスタック的な能力が求められることが多いだろう。その状況において、大きいシステムの一部機能の保守・運用のみをメインでやってきたエンジニアは（どんなにその運用・保守能力が高くとも）活躍できないだろう。
企業は「今採用したいエンジニアのタイプはどんなタイプか？」という前提を明確にした上で、エンジニアの特性を見極めて採用を行う必要があるだろう。
良いエンジニアは市場に出ない
本当にすごいエンジニアほど、労働市場に出ることはなく、知人を介した紹介や、WebやSNSを介した直接応募で転職が決まっている
これもよく言われることだが、優秀なエンジニアであればあるほど転職市場には出てこない。なぜなら優秀なエンジニアは引く手あまたで、信頼のおける知人の紹介であったり勉強会などで出会った人づてで就職を決めてしまうことが多いからだ。
これは企業側にとっても採用を難しくさせる要因になっていると思う。なぜならいざ転職市場から優秀なエンジニアを見つけようと思っても、優秀なエンジニアがそもそも転職市場には居ないので転職市場を掘っても掘ってもなかなかお目当てのエンジニアには出会えないからだ。
逆に言うと企業側が優秀な人の採用に一人成功すればその人づてに紹介の輪が広がるケースもあるので、最初の優秀な一人の採用は極めて重要と言える。
リファラル採用が一番多い
本書でも転職者のルートで一番多いのは知人を介した紹介であり、エンジニアの転職も同じエンジニアからの紹介ルートが一番多いと書かれている。エンジニアを介したルートがなぜエンジニアにとって合理的なのかの理由は下記のように書かれている。
- エンジニア同士、技術トークを共有することができ、エンジニアの思考や行動のどこにつまずきやすいのかを理解している
- （エンジニアに限らないことだが）求人企業サイドの情報より利害関係がない人間関係から収集した情報のほうが信じやすい = オーバーハードコミュニケーション
転職ルートの多様化
僕がカナダ・バンクーバーから帰国後、エンジニアとして就職活動をしていて一番驚いたこととしては、新卒就活生時代にさんざん経験したようなお堅い面接からスタートするのではなく、カジュアルな面談からスタートできるという点だ。
今でこそ当たり前になっているカジュアル面談だが、当時はカジュアルな面談から気軽にスタートできるマッチングサービスがそこまで多くはなく、当時使っていたWantedlyは非常に重宝した思い出がある。
※なお当時の僕の就活の様子は当ブログにまとまっているので興味がある方はどうぞ: 就活日記(0) エントリー（就活日記シリーズ一覧）
また最近では、ドラフト型、スカウト型の求人サービスも多く登場している。例えば下記のようなものだ。
年収の透明化
中でも転職ドラフトは個人的にかなりのブレークスルーであったと感じる。企業に年収をセットで提示させることで、今まで暗黙的にタブーとされてきた年収をつまびらかにしたからだ。これはエンジニアにとってもたいへん有益で、なぜなら自身の市場価値を＜年収＞という圧倒的にわかりやすく明確な数値で知ることができるからである。
僕も転職ドラフトが話題になった当時、市場価値を測るという目的で試しにドラフト対象者として登録してみたのだが、やはり現年収を大きく上回る年収が提示されたときのインパクトは大きかった。それが数十万くらい高いくらいの話であれば「まぁ現職に不満はないしこんなもんかー」程度で済むのだが、数百万単位で現年収を上回る提示をされたときはたとえ現職に全く不満はないとしても心が揺らぐというものである。
もちろん転職を決めるファクターとして年収が全てではないのでそれで転職を決めましたという話ではないし、転職を年収のみで決めるべきだとも思っていないのだが、転職ドラフトによってエンジニア自身の中で「自分の市場価値は年収ベースでこれくらい」という相場観を持てる意義は大きい。
企業サイドからすると、優秀なエンジニアであればあるほど高い年収の相場観を持っているはずなので、本当に優秀なエンジニアを採用したいと思うのであれば、最低でもその相場のレベル以上の年収を設定することが必要になってくると思う。
採用担当者のリテラシー
転職ドラフトは一例だが、エンジニアの転職チャネル・転職サービスは多様化している。採用担当者はエンジニア採用チャネルに対する感度の高さやそれを使いこなすためのリテラシーが求められてくる。本書でも下記のように述べられている。
どのようなエンジニアがどこにいるのか、全体像を捉えるのは困難だからです。
全体像が捉えづらい中で、あなたの会社に必要なエンジニアがどこにいるのか仮設を立て、検証し、採用活動をおこなって試行錯誤しながら、採用に必要なノウハウを蓄積していくことが、エンジニア採用を成功させるためには重要です。
このへんのPDCAサイクルが回せる採用担当者もまた、エンジニアと同様に企業には必要となるだろう。
企業の情報発信
企業ブランドや情報発信力は重要です。コストをかけてでも良くしていかなければ、事業はもちろん、採用もうまくいかない現実があることを再認識しましょう。
近年ははてなブログMediaなどを利用したオウンドメディアによる企業の情報発信も当たり前となってきた。例えば下記のようなオウンドメディアである。
テック系企業だとエンジニア向けにテックブログを持つのも当たり前の時代となった。
企業にとってみれば、エンジニアに企業について知ってもらい、興味を持ってもらわなければカジュアル面談にすらたどり着けない。まずはオウンドメディアによる情報発信あるいはテックブログによる技術的な情報発信を積極的に行って企業について認知してもらい興味を持ってもらう努力が必要になる。
SmartHR 社が面接で使っている資料を Speaker Deck で公開しました！昇給実績や、いま入社した場合にもらえるストックオプションのシミュレーション結果もアリます。ほぼ全職種募集してるので、お気軽にご応募ください！https://t.co/d1hl3rXeC6 pic.twitter.com/ey6dBB7B8z
— 宮田 昇始 (@miyasho88) August 8, 2018
↑SmartHR社は会社紹介資料をそのままWebに公開している。会社ヴィジョンやユニークな制度が資料内でわかりやすく紹介されておりお手本としたい会社紹介資料だ。
企業の差別化ポイント
IT企業が数多く存在する中、良いエンジニアに働いてもらうには他社と決定的な差別化を図る必要がある。エンジニア採用における企業の差別化ポイントとしては本書では下記が紹介されている。
- 報酬
- 就業条件
- 評価と処遇
- 企業内教育の制度
- キャリアパス
報酬
一番わかり易いのは報酬での差別化だ。
エンジニアが転職する第一の要因は「報酬の低さ」であるといわれています。
本書ではエンジニア報酬が低くなる要因を、年功序列による賃金テーブルが運用されているからだとしている。古き良き日本企業であれば年功序列による賃金テーブルを運用をしたくなる気持ちもわかるのだが、エンジニアにおいてはそれは絶対NGといえる。
エンジニアにとっての成長は人によって千差万別で、学生時代から技術を身につけたエンジニアならば入社時点で先輩社員より開発力が高い、いやはるかに高い人もいます。年齢≠技術であり、技術力と実績が賃金と比例する大前提と社内規定が矛盾し、能力と実績を反映した報酬を出せない企業が非常に多いからです。
これら既存の日本企業の運営ルールを打ち破ることができれば、良いエンジニアに働いてもらえる環境の整備に向けて大きく前進することになります。
転職すると年収が上がるバグ
思い切った賃金テーブルの改定が行えない企業が世の中には多いようで、転職すると年収が上がるというバグが報告されている。
エンジニアを採用したい企業側にとってはそのバグを突くことが採用チャンスと言えるだろう。幸い、上述したような転職ドラフトのようなサービスが世の中には存在しているので、各社どんどん年収バグを突いていっていただきたい1。
また転職ドラフトなどでガンガン高い入札をしている企業であれば、それだけで「エンジニアを高く評価する企業」というイメージにもなるので、一つの企業ブランディング活動にもなりそうだ。
※ 余談にはなるが、転職ドラフトのように企業名が出る形で高い年収を提示する際には、社内実態との乖離には気をつけなければならない。さもないと社内で変な軋轢を生むこととなる。
逆に社内で手放したくないエンジニアがいるという企業は、年収バグ起因で他の企業に転職されちゃう前にきちんと実力・成果に応じた報酬設定を行うべきた。
就業条件
福利厚生を含む就業条件をユニークにするというのも最近多く聞く。例えば下記のような例である。
- リモートワーク
- フレックスタイム制
- 副業推奨
- 英語などの学習支援
- 勉強会や海外カンファレンス参加のサポート
- 子育て支援制度
など細かい制度を上げるとキリがないが、エンジニアを惹きつける就業条件を設定する企業も多くなっている。
エンジニア仕事は比較的場所・時間を選ばず働くことができるので、例えばリモートワーク・フレックスタイム制を好むエンジニアは多くいる。またエンジニアは普段から英語ドキュメントを読んだり、OSS活動の中でGitHubで英語でコミュニケーションをとったり、海外のテックカンファレンスに行ったり、英語を使用することも多いので英語の学習支援があると嬉しいという声も聞く。
最近僕が見た中で充実した福利厚生・就業条件がある企業を下記に列挙する。
評価と処遇
本書でも述べられている通り、エンジニアの評価システムほど難しいものはない。公平な評価システムを作る上で下記が重要だと述べられている。
- 評価システムをルール通り運用する
- システム開発経験のあるマネージャーもしくはエンジニアが一次評価を実施する
- 対象のエンジニアの技術領域と評価者の技術領域をそろえる
エンジニアの評価制度に関しては、下記のVOYAGE GROUPのエンジニアの技術力評価の歴史の資料が参考になるだろう。
また処遇に関しては実力・実績ベースで決めるべきであり、本書では下記のアンチパターンが紹介されている。
- 創業期のメンバーと仲良しになってしまい、キャリア採用で優秀なエンジニアが入社して実績を出しても昇格できない
- 経営陣と優秀なエンジニアの間に創業時からいる低スキルのエンジニアが上長として入り込み、優秀なエンジニアの成果を自分のものにして、優秀なエンジニアのモチベーションを消滅させる
「創業メンバーだから」「創業メンバーと仲良しだから」という理由で登用させるのは危険信号なので、見直すべき人事といえる。
企業内教育の制度
企業としてエンジニアの育成に投資することや成長環境を整備することも重要だと述べられている。
この例としては、CTOやエース級エンジニアからの技術研修であったり、彼らとのペアプログラミング・レビューであったりすると思う。最近だとそういったことが実施できるエンジニアを外部から技術顧問として招く例も聞く。
そのような成長環境をエンジニアに定常的にしっかり用意することができれば、エンジニアの離職率の低下につなげることができるだろう。
技術研修の例として、技術研究を行っている企業がブログにてその内容を紹介している。
またGitHubに研修資料をアップして、研修の充実度をアピールするのも有効な手段である。
- mixi git, Android, iOS, JavaScript, Ruby, Perl
- はてなの教科書
- ドワンゴ Scala
- 株式会社万葉の新入社員教育用カリキュラム(Ruby on Rails)
ペアプロの事例に関しては下記のt-wadaさんの資料が参考になるだろう。
キャリアパス
エンジニアがキャリアパスを描きやすい環境を作るのも企業にとって重要だ。
開発を通じてエンジニアが成長でき、成長後も働けるキャリアパスを構築できる事業運営が重要になってきます。
- 最先端の技術・開発手法による開発プロジェクトを社内で１つは確保する
- 枯れた技術・古い技術だけではエンジニアが離れてしまうこともあるので、最先端の技術・開発手法による開発プロジェクトを社内に１つは用意することでエンジニアをつなぎとめる
- マネージャーのキャリアパスを用意:
- 35歳エンジニア定年説という言葉が流布されているように、エンジニアとしての成長が頭打ちになるタイミングがいつかは来る。それに備えてエンジニアがマネージャとしてキャリアを進めていけるようなキャリアパスも用意する
- 年老いてもいかに技術者としてのマインドを持ち続けるかに関しては、過去にこのような記事を書いたことがある: 技術者としてスポンジであり続けること あるいは老害回避戦略の話
- 社内のキャリアパスを公開
- 社内エンジニアの中にはスペシャリストとしてエンジニアリングを突き詰める人であったり、マネージャーにジョブチェンジしてマネージャーとしてキャリアを歩んでいく人もいるだろう。そういったキャリアパスの事例を社内に蓄積していき、1on1などの面談の場面で具体的なキャリアパスを社内事例とともに紹介して、エンジニア自身がキャリアパスをイメージしやすい環境を作れると良いだろう
- 1on1についてどのような話をしたら良いかに関してはこちらの記事を参考にされたし: ヤフーの1on1とシリコンバレー式1on1の本を読んだ ~1on1の目的、進め方、何を話すべきか~
迷ったら採用しないという原則
最後に本書には触れられていない内容だが、個人的に採用する側として気をつけたらよいと思うことがある。それは「迷ったら採用しない」ということだ。
日本は解雇規制が厳しいので米国のように簡単にクビにはできない。つまり間違った人材（全くカルチャーフィットしない人材、人間性に難ありな人材、技術力が著しく悪い人材）を間違って採用してしまったとしても、なかなか簡単には解雇できないということだ。従って採用は失敗しないように気をつけなければならないと思うし、迷ったら採らないというのが原則だと僕は考えている。
企業は偽陽性（False Positive）を避けようとしているからだと思います。要するに間違って企業に合わない人（人間として、人材として）を採用するのが最悪だと思われています。良い人材を見過ごすよりも合わない人材を採用する方がコストが高いからです。
Square の採用プロセスについて – Benoît Quenaudon – Medium
米国の採用ですらそのような状況なのだから2、日本の採用はFalse Positiveな採用に陥らないようになおさら気をつけるべきだと思う。