熾烈を極めるエンジニア採用競争に打ち勝つためには、自社の面白さ・魅力を過不足なくアピールする施策と、入社後に活躍・定着してもらうためのオンボーディングが重要です。

今回は、2/27に当社が主催したエンジニア採用とオンボーディング設計に関するセミナーの様子をお届けします。

登壇者の株式会社ヘンリーVPoEの松木氏からは「中途採用のアンチパターン」、LAPRAS社CTOの興梠からは「入社後のオンボーディング」をテーマに、採用とオンボーディングにおけるベストプラクティスについて、具体的な成功と失敗の事例も交えてお話ししました。

エンジニア採用を強化したい、オンボーディングをより良くしたいと考えていらっしゃる方はぜひご一読ください。

登壇者プロフィール

株式会社ヘンリー/VP of Engineering / 松木 雅幸 (Songmu)

Webアプリケーションのコード開発だけでなく、クラウド・インフラ技術に精通したソフトウェアエンジニアであり、ISUCONに過去3度優勝するなど、インフラを意識して信頼性の高いWebアプリケーションコードを高速に書くことを得意とする。 プロダクトマネージャーやCTO経験から、事業においてアジャイルに顧客に価値を届けることにもこだわりを持ち、フルサイクル志向でプロダクトチームを運営することを由とする。OSS活動も活発におこなっており、GoやPerlを中心に200個以上のツールやモジュールをGitHub上に公開している。それも含め、Blog 等での発信力にも大きな強みを持つ。著書に「みんなのGo言語」(共著) 等。

LAPRAS 株式会社 / 執行役員 CTO / 興梠 敬典

豊田高専を卒業後、ソフトウェアエンジニアとして多様な開発案件に従事。複数の新規事業立ち上げに関わり、ビジネス/ソフトウェア双方の設計と構築を経験。 2015年より株式会社Nextremer高知AIラボの代表として、事業や組織の立ち上げを主導。地域コミュニティや行政とも協力関係を構築し、地方でも先端技術に触れられる場作りにも貢献。掲げるミッションと価値観に共感し、2019年8月にLAPRASに入社。2020年10月、執行役員CTOに就任。

中途採用のアンチパターン

松木さん：アンチパターンとは、ソフトウェア開発でよく使われる言葉です。一見有益そうに思えるため、多くの方が適用してしまうのですが、最終的に悪い結果をもたらす開発パターンのことを指します。

当社では中途採用をメインに、ミドルシニアクラス以上のエンジニアをターゲットにした採用活動をしています。それを前提として、中途採用におけるアンチパターンについて解説していきます。

アンチパターン①言語や技術要件を求人票で絞りすぎてしまう

言語だけではなく、開発経験や基礎力を重視したいという考えもありますし、転職を機に新しい言語や技術を習得したいと考えている方も多いので、そういった成長意欲のある方を採用したいと考えています。

言語を極めるには膨大な時間がかかりますが、業務で使える最低限のレベルには1ヶ月程度で到達可能なので、自社で使っている技術の経験を必須にする必要はないと思っています。ただ、技術の好みはあるので、当社の場合なら「KotlinとTypeScriptを使っています」と求人票に明示して、興味のミスマッチを起こさないための配慮はとても重要です。

アンチパターン②事業について説明しない

松木さん：転職先を選ぶ理由としては、技術への興味だったり、事業内容が好きだったりといろいろあると思いますが、事業会社である当社がターゲットとする優秀なエンジニアの方は事業への関心が高いですし、企業側としても関心が高い方に入社してほしいと考えています。

自分たちのつくっているサービスがお客様にどんな良い影響を与えているか、あなたの技術を事業にどう活かし、世の中にどんな価値をもたらせるのか。ビジネスモデルとまではいかなくても、意義を含めた事業説明は必要です。

「こんな技術を使っていて、こんな面白い開発ができます」といった、開発だけに閉じた話で終わらせてしまうのは良くない、もったいないと思ってます。

アンチパターン③福利厚生をアピールしすぎる

松木さん：働きやすさはもちろん大事ですが、働きやすい環境やサポート体制などの福利厚生を会社の魅力として前面に打ち出してしまうと、プロフェッショナルな方にとっては逆に失礼になるケースも考えられます。

会社としても「一緒に会社を良くしていきたい」と考えている方を採用したいと思うので、福利厚生につられて入社するような方を引き込まないためにも、アピールしすぎないように気をつけましょう。

アンチパターン④エンジニアを特別扱いしすぎる

松木さん：働きやすさは全社員にとって重要なので、エンジニアだけを特別扱いしていないかも注意が必要です。

かつてのエンジニア業は3K「きつい、汚い、危険」と言われていて、10年ほど前はエンジニアの就業環境に投資して「エンジニアを大事にすること」が差別化要素になっていた時代がありました。

しかし今ではエンジニアの働き方に対する世の理解も深まり、待遇や働き方も改善し、かなり裁量を与えられて自由に働けるようになってきています。他の職種から見れば、逆に優遇されすぎていると思われる可能性もあると思うので、会社全体としてプロダクトビジネスに取り組んでいくには、エンジニアだけを特別扱いしないことが大事だと考えています。

アンチパターン⑤エンジニアコミュニティーへの理解不足

松木さん：人事担当の方が、エンジニアの技術勉強会やカンファレンスなどに参加することは、エンジニアへの理解を深めるためにも有効です。しかし、そこで手当たり次第に声をかけて自社のアピールをしてしまうと、エンジニアコミュニティー内で「あの会社はアウト」とレッテルを貼られてしまう可能性があります。

エンジニア同士の横の繋がりは強く、ブログの発信やOSSなどを通じて、ビジネス上の関係に限らない友人がたくさんいます。

コアなエンジニアコミュニティーの中では情報伝達がとても早く、「あの会社には優秀なエンジニアがいる」「この会社は面白い技術を使っている」といった良い評判も、「あの会社はエンジニアのことを何もわかっていない」という悪評も、あっという間に共有されます。

エンジニアコミュニティーは狭いので、特定技術領域のエンジニアコミュニティーであれば、友達の友達ぐらいの距離感でも網羅できます。LAPRASさんのデータベースでは技術スコア3.5以上の方が約5000人いらっしゃいますが、それでも友達の友達の友達まで辿れば網羅できると思います。

勉強会やカンファレンスに積極的に足を運ぶなどして、エンジニアコミュニティーの仕組みを理解し、丁寧なコミュニケーションを取るように心がけてください。

アンチパターン⑥テンプレスカウトメールをばらまいてしまう

松木さん：実体験としても長いメールは読まないので、相手に刺さりそうなところを抽出して送る必要があります。

また、名前を貸して別の方がスカウトメールを書くのもNGです。名前を貸した人間がエンジニアであれば候補者と面識がある可能性も考えられます。そこで「初めまして」と書いてしまえば不信感を与えてしまいますし、面識がなくてもブログやSNSでの発信を読まれていれば、文体や内容から違和感を与える可能性があります。

そもそも候補者を騙す行為になるため、丁寧さと誠実さを持って対応しましょう。

アンチパターン⑦飲みニケーションを活用しない

松木さん：エンジニアはコミュニケーションが苦手で飲み会を嫌うイメージを持つ方も多いかもしれませんが、肌感としてはそうでもないと思っています。

当社では、チーム内で開発においてメンバーとコラボレーションしながら業務を遂行できるかを重視しているので、コミュニケーション能力をきちんと確かめたいと考えています。

もちろん飲み会や会食が苦手な方もいるので、選考中に見極めたうえでお誘いします。エンジニアや経営者から、仕事や技術、プロダクトへの熱量の話を聞きたいと思う方に入社してもらえると嬉しいので、気軽なコミュニケーション手段のひとつとして、ざっくばらんに話せる飲みニケーションは有効だと思っています。

新入社員の呪いの解き方

興梠：ラプラスの組織サイズは大体40名弱でエンジニアは正社員が15名、業務委託の方に4名参画いただいてる状況です。3年ほど、同じ形でオンボーディングボーリングをおこなってきて、今のところ問題なく運用できております。

オンボーディングに失敗した場合も損失はとても大きいので、今回はオンボーディングにおいて注意すべき力学について共有しつつ、当社がチームとして工夫していることをご紹介します。

よく聞くオンボーディング失敗パターン

興梠：どんなに能力ある方でも最初は学びのフェーズから入るので、即活躍という感じにはなりません。モチベーションは高いのに、自己肯定感が低い時期が入社してしばらくは続きます。

前職で活躍していた方はとくにギャップが大きくなってしまい、精神的負荷が高い状態になってしまいます。その状態を脱しようと焦った結果、業務や状況への解像度が低いまま課題や改善タスクに手をつけて、爪痕を残そうと頑張ってしまうケースもあります。もちろんそんな状態では成功率も低く、自己肯定感はさらに低下する可能性が高いです。

この状態が長く続くと周囲のメンバーも疑問を抱き始めてしまい、それを感じた当人が弱さを見せづらくなります。他者からの評価を恐れてミスを認められなくなったり、タスクを抱え込んだりして、サポートを受けづらくなるケースはよく聞く話ですよね。

自分は役に立ってるのかという不安と、周囲に「この人はちゃんと仕事してるの？」と思われているのではないかという疑心暗鬼が、「新入社員の呪い」です。呪いにかかってしまうと本来の力が出せなくなったり、防衛反応として良くない行動をとってしまったりする状態になります。

不安も疑心暗鬼も杞憂で、周囲が正しく真摯に向き合っていても、デフォルトで不安と疑心暗鬼の力学を強く受けてしまうのが、呪いだと思っています。ハイクラスな方ほどかかりやすい呪いでもあるので、注意していただきたいです。

ちょっとタイトル詐欺になってしまいますが、呪いは解くことはできないので、呪いとの付き合い方を知って、呪いの影響を軽減する方向で対策をしていきましょう。「色々と狂い始める」まで行ってしまうと、事実としてメンバー間の対立が生まれてしまうので、真ん中の段階をうまく乗り切ることが重要です。

呪いと付き合う方法①期待値を揃える

興梠：ラプラスはオンボーディング期間を3ヶ月設けています。オンボーディングのメンバーは、新入社員を主役として、トレーナー、メンター、オンボーディングPMという布陣です。トレーナーは同じチームからアサインされ、新入社員がパフォーマンスを最大限に発揮するためにサポートする役割を担います。

オンボーディングにおいてもっとも重要なのは、オンボーディングメンバーの期待値を揃えることです。オンボーディングが終了する3ヶ月後までに達していたい目標、そこに至るために必要な行動、方針について明文化し、期待する成長について合意形成をおこないます。

期待の例としては「開発者ロールとしてのイシューに対応できる」「バグの内容から独力で調査解決できる」「的確な改善提案ができる」など、ざっくりとしたものが多いです。

オンボーディング開始後は、最初の2週間程度は最低でも週次でスケジュールを引き、状況を見ながら徐々に先のスケジュールをつくっていく形で丁寧に進めていきます。

スケジュールに関しては、わりと具体的に書くようにしています。最初の1週間における期待の例としては、「何がわからないのか把握できる」「開発チームに質問できる」「作業前後に発生してる作業を把握できる」といった全体感をインプットするための行動を定義します。

スケジュールをつくらずに進めると、無限にフルスロットルで頑張り続ける脅迫感に苛まれてしまいます。「スケジュール通りにできているから、今日はここまでで大丈夫」と安心するための指標としても、不要なすれ違いや勘ぐりを生まないためにも、期待値のすり合わせとスケジュールの作成は重要です。

開発者兼マネージャーとしての期待を受けて入社した方が、まずは開発者としてのキャッチアップに集中しようと動く場合もあります。そこで周囲のメンバーから「開発ばかりでマネージャーとしての仕事を全然していない」と判断されたり、逆にそう思われているのではと不安になったりすることを避けるためにも、期待やスケジュールを明文化して、一歩一歩成長している状態を明らかにしながら進めていけるといいですね。

呪いと付き合う方法②最初の数週間のタスクは原則ペアワークで進める

興梠：既存社員の「ひとり増えた分の成果を出してほしい」と考える気持ちもわかるのですが、新入社員が単独で開発タスクを進めるうえでの障壁はかなり多いです。

つまり失敗因子がとても多い状態であり、新入社員にとっては切り分け難しいものばかりです。そこで、まずは開発における障壁を取っ払うところにフォーカスするために、LAPRASでは最初の数週間のタスクはペアワークで進めています。

複数の課題を同時に解決しようとせずに、一つひとつ倒していったほうが、不要なつまずきが減り、計画がブレないので、フロー効率も良いはずだと考えています。

呪いと付き合う方法③進捗の認識を合わせる・実感可能にする

興梠：進捗の認識を合わせて、成果を実感できる状況を生み出すために、トレーナーとの1on1による振り返りをおこないましょう。成果を実感するための工夫のひとつとして、下記スライドの実績解除マップがあります。

コードを修正してPRを送ってマージされる実績、コードレビューをする実績など、開発プロセスのどこに関わったかをチェックできるようになっています。また、APIの修正・追加など、タスクをグルーピングして並べたものにチェックをつけていくと、少しずつ進んでいることを実感できます。

他にもハードスキル履修マップでは、Vue.jsの基礎などの公式チュートリアルのリストをつくっています。

「Reactは得意だけど、Vue.jsは初めてなんです」という方もいらっしゃるので、業務でいきなり触れて困ることがないように、あらかじめ自信のない部分について認識を合わせて、学習の方向性を合意しておくために活用しています。

呪いと付き合う方法④チームメンバーが活躍をアピールする

興梠：新入社員の活躍を社内に広めることは、本人にとって大きな安心材料になるので積極的にやっていきましょう。当社では新入社員の倒したイシューや共有したTipsに対して、クローズドな場ではなくパブリックチャンネルで感謝を共有して、存在感をアピールしています。

呪いとの付き合い方を考慮したオンボーディングは、結構労力はかかりますが、思っている以上に投資回収時期は早いと感じていますし、このような工夫をしていると公言することで、既存社員は「新入社員をサポートすべきである」という価値観を定着させる効果も期待できます。

パネルディスカッション

LAPRAS社共同創業者の二井がモデレーターを務め、採用とオンボーディングについて、登壇者同士で意見交換をおこないました。

テーマ①自社を面白く見せるために普段から考えていること

松木さん：ポジティブな広報活動を地道に増やしていくしかないかなと思っています。技術ブログやnoteでの発信、登壇を増やして、「あの会社面白そうだな」と思っていただく機会を増やしていきたいです。

個人的なところでは、XなどのSNSでもなるべくポジティブな投稿を心がけています。会社の公式Xの投稿を引用したり、記事の紹介をしたりするだけでは宣伝っぽくなりすぎてしまうので、人間味のある投稿もしながら上手いことバランスをとるのが大事かなと思っています。

興梠：当社も基本的には同じですね。エンジニアさん向けのサービスなのですでに知っていただいてることも多いため、サービスについての周知よりも内部の雰囲気や遊び心がある内容を発信するほうに力を入れています。

ちょっと飛び道具的なところでは、YouTube配信もやっています。週に30分ほど技術の時事ネタに関する雑談を配信したり、週に1時間ぐらいのモブプロ生配信をしたり。アーカイブとして残っていると「チームの雰囲気はどうですか」と聞かれたときにパッと出せるので、あまりマメに更新できないとしても有効なんじゃないかと思います。

二井：普段の行動が資産化していくのは、採用にとっていい循環になっていると感じました。松木さんは、動画配信の取り組みについてどう思われますか？

松木さん：動画や音声メディアはやりたいと思いつつも手が出せていないところなのですが、お話を聞いてやはり素晴らしい取り組みだと思いました。手を出せていない理由としては、トラブルに対する懸念ですね。例えば「生配信中に通知がきて、うっかり個人情報を流出してしまったら？」など、いろいろ考えてしまうと怖くて踏み切れないところがあります。

興梠：まさに今おっしゃった部分は当社でも懸念しているので、参加する社員に対して、通知の切り方などのマニュアルをドキュメント化して共有しています。

また、モブプロ生配信のときには「何を見せたくて、どう思ってほしくて配信してるのか」の認識を事前にすり合わせて取り組んでいます。善意で参加してくれたメンバーが嫌な思いをしたり不当な評価をしたりされないための配慮です。

テーマ②採用KPIの弊害、良い運用方法

二井：採用担当の方は、スカウトの送信KPI、面談目標などの数字を追うケースが多いと思います。おふたりが思う採用KPIの弊害、最適な運用方法を教えてください。

興梠：最適に運用するには、採用基準の明確化が一番大事だと思っています。当社では選考プロセスにおいて誰がどう判断するのか、コーディングの課題や面接の課題におけるチェックリストと配点表、合格点など、線引きのポイントを各セクションで明確にしています。

線引きのポイントは絶対線ではないですが、補助線として用いている形です。数を達成するために誰でも採用するわけにはいかないので、事前に基準を決めておきましょう。

ただし、基準によっては誰も通過しないケースも出てくるので、状況を見ながら基準をアップデートしていく運用をしています。

二井：KPIをセットするときには、採用基準もセットで運用していくことが大切なんですね。

松木さん：当社は採用人数を目標として置いていますが、それはある意味OKR的な目標であり、達成できなかったからといって採用チームの評価が下がる形での運用はするべきではないと考えています。

評価が下がるとなればKPIハックになってしまい、採用の質を落としかねません。絶対に達成したい目標として採用人数をKPIに設定しながら、評価とは別軸で運用する形がいいのではないでしょうか。

また、目標としては置かなくても、全体のアクション数をしっかり取るのも大事だと思っています。ソーシングしてスカウトを送って、カジュアル面談に進み、選考をおこない内定して、内定承諾が出るまでの過程のアクション数を定期的に計測ことで、どこをテコ入れするべきかが見えて、より良い運用に繋がっていくと考えています。

二井：KPIにするかメトリクスとして計測するかで、結構差が出る部分になりそうですね。KPIハックをしないようなモチベーション設計は大事だと思いますし、ハックしない状態で質的なものが担保できた状態でアクション数を取ることが、ある意味理想的で、あるべき姿だとも感じました。

採用の世界ではそこが簡単に崩れやすい傾向があるので、気をつけるポイントでもありますね。

興梠：そうですね。採用KPIの部分では採用基準があるので、採用者数を追いかけるだけでは成立しないですし、かといって基準が厳しすぎて採用できなくなってしまいます。

そこで諸々を考慮して採用基準を設定しても、エンジニアチームが「優秀な方に来てもらうために基準を高く設定したい」と主張した場合、衝突が起きるケースもあります。

現場の人間とエンジニアチームが認識をすり合わせて、一緒に数字を追いかける連携体制が取れるといいですね。

松木さん：OKRのKR設定では、採用件数と質の両方が達成できて両方を補えている状態が理想です。バランスがとれた設定をするために採用成功率を計測したいのですが、採用が成功したかを判断するには一年ほどかかるため、そこが難しさを感じるところですね。

テーマ③オンボーディングの成否を分けるポイントとは

松木さん：興梠さんの発表に、成否を分けるポイントが詰まっていたと思います。個人的に悩ましいと感じているのは、レールが敷かれていることを窮屈に感じる方に対する対処法ですね。ハイクラスでユニークなポジションの場合、それまでの経験とは全然違うことをやるケースも出てくると思うんです。

そうした期待されている働きとは別に、「これをやった方が会社が良くなる」ということを見つけてやってしまうことはあると思っていて、そこでレールがしっかり敷かれているせいで思うように動けない場合、モチベーションを落としてしまうんじゃないかと思っています。

あとはやっぱり「1人目ポジション」のオンボーディング設計に難しさを感じています。

当社の場合、データエンジニアやスクラムマスターを専任で採用していく可能性があるのですが、あまり丁寧なチェックリストはつくれないと思うので、採用した本人と、一緒に考えてくしかないんだろうなと思っています。

二井：1人目ポジションは難しいですよね。当社はハードスキルの指導ができる方が社内にいないので、そこの難易度は高いと感じています。

興梠：オンボーディングの内容を説明するだけではなく、「こういう考えのもと、こう進めています」という、オンボーディングプログラムの説明も必要だと思います。全体をまずテーブルに上げて話して、共通認識を作ってやっていくスタイルですね。抽象化すると全部そこに行き着いてしまう感じはあるのですが。

1人目ポジションの課題については、オンボーディングを担当するトレーナーがどう関わっていくかで解決できると考えています。

新入社員の人に悩みを相談されたときのトレーナーの対応は5段階あり、「〇〇さんに聞くと解決できるよ」と教えるのがレベル1、協力を得るための質問方法を提供するのがレベル2、初動のコミュニケーションに入って当事者を繋ぐのがレベル3、繋いで問題解決までファシリテートするのがレベル4、代わりに課題を解決するのがレベル5です。

なるべくレベル1の範疇で済むようにオンボーディング期間で関係をつくるサポートができれば、ハードスキル面の直接的なサポートはできなくても解決できるのではないかと考えています。

Q&A：オンボーディングに直接関わらないチームメンバーに、内容や進捗状況をどれぐらい開示するか

興梠：基本的に進捗状況や実績はオープンにしていますが、週次でとっているアンケート結果の扱いは慎重にしています。

アンケートは新入社員がオンボーディングPMに提出し、困りごとやトレーナーとの関係についてなどの現状を共有しています。そこで挙がった課題や状況はネガティブなものやセンシティブなものも含まれているため、開示範囲については丁寧に合意形成をしながら取り扱っています。

まとめ

エンジニア採用におけるアンチパターンを理解し、新入社員が呪いと上手く付き合うためのオンボーディングを設計することで、優秀なエンジニアを獲得できる確率が高まります。

また、オンボーディング設計における工夫は、入社を検討している方に対して安心感とサポート体制をアピールする材料にもなります。

本イベントで共有されたエンジニア採用とオンボーディングに関するTipsを、貴社の採用活動にお役立ていただければ幸いです。

（ライター：成澤綾子）