【ITニュース解説】Why Engineering Retention Isn't About Money (And What Our Year-Long Hiring Overhaul Taught Us)

多くの企業が人材採用を単なる数合わせと捉え、とにかく多くの人を面接し、早く採用し、問題があれば後で対処しようとする傾向がある。しかし、このアプローチには大きな落とし穴がある。不適切な人材を一人採用してしまうと、その損失は単に給料だけにとどまらない。チーム全体の生産性が6ヶ月から12ヶ月にわたって低下し、質の低いコードによる技術的負債が積み上がり、既存の優秀なエンジニアが余計な負担を強いられることで、チームの士気や文化にも悪影響が及ぶのだ。このような事態を避け、真に価値のあるチームを築くため、ある企業は抜本的な採用プロセスの見直しを決意した。

この企業は、採用プロセスをゼロから作り直すために、丸一年という膨大な時間を費やした。単に面接の質問を変えたり、コーディングテストを追加したりするような表面的な変更ではない。彼らが最適化したい「もの」とは何かを根本から再考したのだ。その結果として得られた重要な洞察は、「多くの企業が、より良い条件を提示されたエンジニアを失う」という問題とは異なる、という点だった。この企業が抱える課題は、会社の規模が大きくなるにつれて、共に成長できるエンジニアのみを採用することだった。つまり、お金だけではない、持続的な成長ポテンシャルを持つ人材を見極めることが重要だと気づいたのだ。

新しい採用プロセスを導入した後、彼らは次の3人のエンジニアを見つけるのに6ヶ月以上を費やした。何百もの履歴書をレビューし、何十回もの面接を行い、数えきれないほどの技術評価を実施した。これほどの大規模な投資は、まさに途方もなく感じられた。しかし、その後の結果を見ると、この投資がどれほど価値あるものだったかが明らかになった。最終的に、採用候補者として選ばれた3人が90日間の試用期間に進んだが、その中で正式採用に至ったのは2人だけだった。一見すると、3人中2人という「低い」成功率は失敗のように思えるかもしれない。しかし、この企業にとって、これはプロセスが正しく機能していることの最大の証明であり、大きな勝利だった。

具体的な事例を見てみよう。

エンジニアAは、最初から並外れた才能を示した。初日から、開発環境のセットアップに加えて、ビジネスロジックやシステムアーキテクチャに関する質問を投げかけた。最初のプルリクエスト（コードの変更提案）は、通常数週間かかるところを数日以内に提出された。最初の1ヶ月間は「学習速度テスト」として評価されたが、彼の質問は「どう実装すればいいか」という具体的な方法論から、「なぜこのアプローチを選んだのか」という戦略的な思考へと進化していった。コードレビューで得たフィードバックは単に修正するだけでなく、それを基により良い解決策を導き出し、継続的な成長を示した。30日目の評価では、すべての基準で一貫して高い点数を維持し、上向きの勢いがあった。2ヶ月目から3ヶ月目にかけては、その変貌ぶりは目覚ましかった。タスクの見積もり精度は毎週向上し、「Xをどうすればいいか」と尋ねるのではなく、「Zという制約がある中でXとYのどちらが良いか」と自ら提案するようになった。3ヶ月目には、ほとんど指導なしで複雑な機能を最初から最後まで推進する能力を身につけた。最終的には、85%の納期遵守率を達成し、すべてのオンボーディング目標を上回ったため、即座に正式採用された。

一方、エンジニアBは全く異なる結果だった。最初の2週間は、一見すると問題なく見えた。セットアップ作業をすべて完了し、会議にも参加し、質問もした。しかし、彼の質問は常に実装レベルに留まり、意思決定の背後にある「なぜ」に対する好奇心は見られなかった。1ヶ月目に入ると、チームの週次健康チェックシステムがその乖離を浮き彫りにした。エンジニアBは「問題なし」「タスク100%完了」と報告していたが、チームの観察では、中程度の複雑さのタスクに予想以上に時間がかかり、コードレビューのフィードバックに対して何度も同じ概念を修正する必要があった。30日目の評価では、自己評価と実際のパフォーマンスの間に深刻なギャップがあることが判明した。2ヶ月目から3ヶ月目にかけても、同じような複雑さのタスクをこなす能力に改善は見られず、ルーティン化すべき作業にも依然として多大なサポートが必要だった。最も懸念されたのは、週次の自己評価において、自信と実際の能力の間に根強い隔たりがあることだった。最終的に、納期遵守率は45%にとどまり、主要なオンボーディング要件を満たせなかったため、正式採用には至らなかった。

エンジニアCは、最も興味深いケースだった。技術的には非常に優秀で、チーム文化への適合性も高かったが、旧来の採用プロセスでは見逃されていたであろう微妙な兆候があった。初期段階はスムーズに通過したが、実行段階で成長が停滞した。なんとか業務はこなせるレベルだったが、会社の規模が拡大する中で活躍し続けるには不十分だった。決定的な要因は、3ヶ月目に入って課題の難易度が上がった際、自律性を高めるのではなく、より多くの指導を求めた点だ。90日間の試用期間の構造が、彼が成長に伴う曖昧さよりも、明確に定義された問題を好むタイプであることを明らかにした。

このように、3人中2人という「低い」成功率は、決して失敗ではない。むしろ、このプロセスが機能していることの強力な証拠だった。考えてみれば、この企業は、候補者を探し、評価するために6ヶ月以上を投資した。そして、その後の90日間のプロセスで、会社の成長軌道と真に合致する人材が2人しかいないことを発見できたのだ。もし旧来のシステムであれば、この3人全員を採用していただろう。そして、そのミスマッチは6ヶ月から12ヶ月後に判明し、その時にはチームと会社に計り知れないコストがかかっていたはずだ。

採用プロセスの再設計に12ヶ月、適切な候補者を探すのに6ヶ月以上、何百もの履歴書レビューと面接、数えきれないほどの技術評価という数字は、確かに途方もない投資に見える。しかし、本当に重要な数字は、採用されたエンジニア全員が期待以上のパフォーマンスを発揮していること、採用後の後悔や改善計画がゼロであること、全員が全力で貢献できるためチームの生産性が向上したこと、そして誰もが余計な負担を背負うことなく文化的な結束が強化されたことだ。多くのリーダーが忘れがちなのは、不適切な人材を採用するコストは、その給料だけではないという事実である。それはチーム全体の生産性の低下であり、彼らが作り出す技術的負債であり、彼らの間違いを修正する代わりに解決できたはずの問題の機会損失なのだ。

この企業が再設計したプロセスで実際に測定していたのは、従来の面接で試されるコーディングスキルだけではない。実際のエンジニアリングの仕事には、システム全体の思考力、コミュニケーション能力、そして不確実な状況下でのトレードオフの意思決定能力が求められる。

彼らの3段階評価は、具体的に以下の点を重視した。 1ヶ月目：学習速度テストでは、新しい文脈、ツール、チームのダイナミクスをどれだけ早く吸収できるか、質問が具体的な戦術レベルから戦略レベルへと進化しているか、フィードバックを統合し、それを基にさらに発展させられるかを見ていた。 2ヶ月目：曖昧な状況下での実行では、指導が減る中で中程度の複雑さの課題をどう扱うか、自己評価がチームの観察と一致しているか、成長が加速しているか、それとも停滞しているかを確認した。 3ヶ月目：オーナーシップへの移行では、最小限の監督でプロジェクトを推進できるか、アーキテクチャに関する議論に意味のある貢献ができるか、複雑な仕事を引き受けながら80%の納期遵守率を維持できるかを評価した。

この集中的な再設計と初期の結果から、長期的な成功を予測する明確なパターンが見えてきた。 成長するエンジニア、つまりエンジニアAのような人材は、質問が「どうすればいいか」から「なぜそうするのか」、さらには「そうすべきか」へと進化する。フィードバックは単に指示として実行するだけでなく、それを基により良いものを構築しようとする。問題を早期に発見し、自ら解決策を提案するような積極的なコミュニケーションを取る。そして、同じ複雑さのタスクをこなす速度が目に見えて速くなる「学習の加速」が見られる。 一方、苦戦するエンジニア、つまりエンジニアBやCのような人材は、質問が常に実装レベルに留まり、進化が見られない。フィードバックに対しては、それを受け入れずに説明をつけ加えたり、正当化したりすることが多い。指示を待つような受動的なコミュニケーションになりがちで、パフォーマンスの停滞が見られ、数週間にわたって改善の兆しが見られないという共通のパターンがある。

このアプローチが、特に成長中の企業にとって有効である理由はいくつかある。エンジニアには技術的な「快適ゾーン」というものが存在する。特定の技術や問題領域で深い専門知識を培うことは素晴らしいが、会社が成長し、技術的課題が急速に変化する中で、新しい挑戦を学習の機会と捉えるエンジニアもいれば、既存の専門分野に留まることを好むエンジニアもいる。90日間のプロセスは、この違いを即座に明らかにする。2ヶ月目から3ヶ月目にかけて曖昧さが増すにつれて、不確実性に対応できるエンジニアは力を発揮するが、明確に定義された問題を好むエンジニアは苦戦し、結果的に自ら去っていくことにもなる。また、「見た目は良い」コードと「本当に良い」コードの間には、大きな隔たりがある場合がある。エンジニアが動作するコードを納品したとしても、それが数ヶ月後にチームを麻痺させるような技術的負債を抱えている可能性があるのだ。週次の健康チェックシステム（自己評価とチームの観察を比較する）は、この認識の乖離を早期に発見する。エンジニアBのように、高い達成度を報告しながら実際には苦戦しているというパターンは、旧来の方法では延々と続いていたかもしれないが、この新しいプロセスでは90日以内にその実態を把握できるのだ。

この新しいアプローチで最も驚くべきことは、採用の成功率を向上させただけでなく、チーム全体のダイナミクスを変革したことだという。全員が成長マインドセットを持って採用されると、チーム全体がフィードバックを受け入れ、活用する能力が向上する。エンジニアたちは、誰もが知識を吸収し、それを基に発展させられると知っているため、知識の共有により積極的になる。複雑なプロジェクトは、一人の人間が抱え込むのではなく、全員で協力して進めるようになる。あるエンジニアが、チームが理解していると思っていた概念で苦戦しているために重要な作業が滞るといった状況は、もはや起こらない。長期的な安定性が構築され、それが持続的な価値を生み出す。この企業のエンジニアのほとんどが3年以上、中には7年以上在籍しているという事実は、運ではなく、成長の方向性への適合性を見て採用している結果なのだ。不確実性に対応できるエンジニアは、情報が不完全な状況でもより良いトレードオフの意思決定ができる。これは、成長中の企業にとってまさに必要な能力だ。

今回の経験から、いくつか実践的な学びがある。まず、採用プロセスを変更する前に、現在のチームの中で最も優秀なエンジニアたちがどのような成長パターンを示したかを理解し、それを評価基準のベースにするべきだ。次に、構造化された評価ツール、特に自己評価とチームの観察を比較する週次健康チェックに投資すること。これは、単一の面接よりもはるかに多くの情報をもたらした。そして、時間の投資に対する覚悟が必要だ。質の高い採用には初期に時間がかかるが、後で莫大な時間を節約できる。この企業は、2人の優秀なエンジニアを獲得するために、プロセス再設計に18ヶ月もの期間を費やした。最後に、「低い」成功率を受け入れること。試用期間の成功率が3人中2人という数字は低く感じるかもしれないが、それは旧来のプロセスなら3人全員を採用し、問題をはるか後になってから発見していたという事実を考えれば、早期発見の証拠であり、むしろ良いことなのだ。

採用に関する不都合な真実とは、すべての優秀なエンジニアが成長中の企業に適しているわけではない、ということだ。安定した環境で明確な問題に取り組むことを得意とするエンジニアもいれば、要件が流動的で技術スタックが急速に変化する環境でこそ真価を発揮するエンジニアもいる。どちらが良い悪いということではなく、単に異なるタイプなのだ。彼らの1年間にわたる再設計は、エンジニアが望んでいない成長の軌道に無理やり押し込めようとすることは、関わる全員にとってコストが高いということを教えてくれた。本当の洞察は、ほとんどのエンジニアリングリーダーが採用のスピードを最適化しようとするが、彼らは「適合の正確性」を最適化したことにある。時間とプロセスの初期投資は、数ヶ月のうちに高い生産性と後悔のない採用という形で回収されるのだ。

もしあなたがエンジニアリングチームのリーダーで、人材の定着に課題を感じているなら、自問してみてほしい。より良い条件を提示されて人材を失っているのか、それともあなたの会社と共に成長できない人材を採用しているのか、と。この企業は、市場レートに合わせて競争力のある給与を維持しているが、エンジニアが会社の成長軌道と合致していれば、給与が離職の決定的な要因になることはめったにない。彼らのアプローチは、単に採用基準を厳しくすることではなく、適合の精度を高めることだ。完璧なエンジニアを探しているわけではない。会社の成長要件と、そのエンジニアの成長ポテンシャルが合致する人材を探しているのだ。その結果、全員が最大限の能力を発揮し、複雑な問題は協力して解決され、人々が心からここにいたいと願うため、定着が問題にならなくなるチームが生まれている。採用プロセスの再設計に費やした一年は、当時としては費用がかかるように感じられたが、今となってはこれまでで最高の投資だったと感じられている。採用のスピードではなく、適合の正確性を最適化したら、あなたのチームはどう変わるだろうか。