キーワードマッチングからの脱却、エンジニア採用成功の分かれ道
執筆：木下牧子
協力：雨宮百子
作図：髙橋麻実
「TypeScriptでバックエンド開発できるエンジニアを採用したい」
こういった言葉を受けてスカウト文面や求人票を書き始めた経験のある採用担当者は多いのではないでしょうか。しかし、「TypeScript」という技術ワードだけでは、求めるエンジニアの具体的な経験やスキルを正確にイメージすることは困難です。本当に重要なのは、単に「TypeScriptが書ける」ということではなく、「TypeScriptをどのように活用して課題を解決してきたか、どのような設計思想を持っているか」という理解です。
多くの企業がエンジニア採用という壁に直面しています。特にエンジニア出身以外の採用担当者にとっては、現場の使う用語や開発の実態を把握しきれず、「なんとなく」でスカウト送付や書類選考を進めてしまい、採用に至らないケースも少なくありません。その最大の要因は、「エンジニアとしての実務経験がないなかで、技術の理解を深めることが難しい」という点にあります。今回の記事では、現場のニーズを正確に捉え、最適なマッチングを実現するために重要な視点を提供します。
技術を”エンジニアの視点”から捉える
エンジニア採用の担当者が現場のニーズと候補者のスキルを正確に理解するためには、単に技術ワードを知るだけでは不十分です。そこで重要になるのが、「エンジニアから見た技術の視点」です。
例えば「MySQL」（マイエスキューエル：リレーショナルデータベースの一つ）という技術ワードについて考えてみましょう。
まず、真っ先に気を付けたいのはスペルミスです。エンジニアは技術用語のスペルミスに対して厳しく評価する傾向があります。本来なら「MySQL」と書くべきところを、「my SQL」と誤って記載するような事故は、よくあります。採用担当者にとっては小さなミスでも、技術に対する尊重の姿勢や細部への注意力を測ることを重視するエンジニアにとって、違和感につながりやすいポイントであることを忘れないようにしましょう。
次に、求人票やスカウト文面の作成では、エンジニア組織が向き合っている課題を伝えることを意識しましょう。表面的な情報の記載だけでは、候補者側に「なぜ今自分に声がかけられているのか」「自分のスキルが役に立つのか」「なぜ必要とされているのか」が伝わらず、応募しようという意思の獲得が難しくなります。先ほどの例にもだした「MySQL」という言葉が候補者の職務経歴書に書かれているとき、採用担当者は「このエンジニアはMySQLを使ったことがあるんだな」という理解で留まってしまいがちです。
しかし、現場のエンジニアが本当に知りたいのは、候補者であるエンジニアが、どのようなスキーマ設計（データベースの構造設計）、クエリ最適化（データベースの処理を高速化する工夫）、トランザクション制御（データの整合性を保つ仕組みづくり）をしてきたのか、それらをどういう理由で選択してきたのかといった技術への理解です。
採用担当者は、ひとつひとつの技術ワードから、エンジニアが何を連想するのかを理解しておく必要があります。エンジニアの実務を経験していない採用担当者にとって、この「連想」に難しさを感じる人は多いのが実情ですが、そこで役に立つのが技術を具体と抽象に分けて理解するスキルです。
なぜ”具体”と”抽象”を構造的に理解することが重要なのか
ここからは、技術の具体と抽象を理解するための構造化について説明します。
私たちが普段利用するスマートフォンアプリやWebサービスは、直接ユーザーが操作を行うフロントエンド、それらの操作を処理してレスポンスを返すバックエンド、アクセスの土台となるインフラストラクチャなど、様々な専門分野を持つエンジニアが連携して開発を進めることで成り立っています。
ここでは、バックエンド開発に必要な機能や役割を構造化します。下記の図は、バックエンド開発に必要な要素を抽象的な概念から具体的な技術キーワードへと段階的に示しています。最も抽象度の高い「バックエンド開発」の下に、「データ処理」「機能開発」「システム連携」という主要なカテゴリがあり、さらにそれぞれがより詳細な要素に分解され、最終的に具体的な技術キーワードに繋がります。
*技術的なキーワードはあくまでも一例で、技術の選択肢は幅広くあります。また、今回の図解はバックエンド開発とはどのような技術要素で成り立っているかを理解するための構造化を行っています。
図1 バックエンド開発技術の分解
「データ処理」はデータを受け取り加工する流れ、「機能開発」はシステムが提供する個々のできること、「システム連携」は他のシステムとの情報のやりとりを表しています。
この図から、「バックエンド開発」という言葉が示す範囲の広さと、具体的な技術キーワードまでの多岐に渡る要素が見えてきませんか？
主要技術と実現する機能・特性
ここからは、バックエンド開発の各機能領域が、具体的にどのような技術によって実現されるのかを見ていきましょう。
ツリー図のなかにはTypeScriptやPython、Javaといったプログラミング言語は含まれていません。これは、「データ処理」「機能開発」「システム連携」が料理を作る手順だとすれば、TypeScriptはこれらを実現するための手段に該当するからです。各機能領域は、特定のプログラミング言語やフレームワークなどの技術によって実装されます。例えば、「NestJS (TypeScript)」は「機能開発」における「ビジネスロジック」の実装や「API」の提供を効率的に行うためのツールです。
もし職務経歴書に「NestJSを用いたREST API開発経験」とあれば、TypeScriptを用いて「機能開発」層の「ビジネスロジック」と「API」、「システム連携」層の「他システム連携」に関わるスキルを持つエンジニアである可能性が高いと推測できます。大規模なWebアプリケーション開発において、効率的かつ他のシステムと連携可能なAPIを構築してきた経験があるということが読み取れると、自社のエンジニア組織が今必要とする人物像とのマッチ度合いも測りやすくなります。
このように、職務経歴書に書かれた技術スタックやプロジェクト経験からスキルの深さや適性を推測することができます。そして、より精度の高いマッチングには、現場のニーズを正しく把握する視点も欠かせません。
「誰を採用するか」は「何を解決したいか」から決める
エンジニア採用の経験が豊富な採用担当者は、現在の開発における課題や優先順位を把握することで、候補者に求めるスキルや経験値を推測することができます。
例えば、サービスのマーケティング戦略が成功しトラフィックが急増している場合、新規機能の開発だけではなく、大量のデータを効率的に処理するためのアルゴリズム改善やインフラのスケーリングに関する知識を持つエンジニアの優先度が高まることが予測されます。また、プロダクト開発の現場では、将来的な改修コストの増大や開発効率の低下を招く可能性のある技術的な課題が積み残されることがあります。これがいわゆる技術負債です。
もし開発チームが技術負債の解消に注力しているのであれば、機能を維持しつつ既存コードの可読性や保守性を高めるリファクタリング経験、開発されたプログラムの変更を自動的にテストして品質を保証するテスト自動化の知識、そして開発から本番環境への反映を効率化する継続的インテグレーション／継続的デリバリー（CI/CD）の構築経験などが重要な要素となります。
このように、開発組織が直面する技術負債の状況や、サービスの成長フェーズによって、必要となるスキルや経験は異なります。また、開発における優先順位づけや技術の選定には、そのエンジニア組織が何を大切にしているのかという「価値観や思想」が表れます。そのため、エンジニア採用はスキルと経験の表面的なマッチングだけでは成功しません。職務経歴書から、候補者となるエンジニアが本当に経験してきた内容を読み解き、技術力だけでなく、自社のエンジニア組織の文化や開発に対する価値観とマッチするかを判断することが、長期的なチームの成功、ひいては事業の成長に繋がるのです。