1からインフラエンジニア採用を始めるあなたへ｜インフラエンジニア採用の教科書
「インフラエンジニアの採用ってどのように行うのですか？」
と、あるエンジニア採用に関わる方からご質問をいただきました。
インフラエンジニアは、いわゆる自ら手を動かして開発を行うエンジニア(バックエンドエンジニアやフロントエンドエンジニア等)とは業務内容が異なることはもちろん、エンジニアの属性/性質が異なります。
ゆえに、最適な採用戦略/戦術が異なるため、他のエンジニア職種と同じやり方ではうまくいかないことが多いです。
エンジニアが市場に少ない中で、いきなりエンジニアにアプローチしても良いですが、早い段階で手詰まりになることがあります。そのため、具体的に採用活動を始める前にどのようなことを理解し、どのような戦略/戦術で採用活動を進めていくかが非常に大事です。
そこで今回は、インフラエンジニア採用に必要な前提情報や施策、手法について本noteで説明します。ゼロから採用を始める方にも、本noteを読んで全体感を理解していただければと思っております。
※あくまで本noteではポテンシャライトで日々採用のご支援をさせていただく中で感じた内容を元に書いておりますので、一意見として参考程度にご覧いただけますと幸いです。
1. インフラエンジニアの採用を進める前に把握するべきこと
インフラエンジニアを採用するための手法を公開する前に、よりスムーズに採用活動を進めるために事前に把握した方が良いことをお伝えします。
1-1. インフラエンジニアの採用市場
どのような職種を採用するにしても、市場にターゲットがどれくらいいるのかは大前提知る必要がありますので、まずは、インフラエンジニアの市況感について説明します。
個人的にインフラエンジニアが最も多く登録していると思っている採用媒体で、母集団の調査をしましたのでデータ(2024年5月調査)をご覧ください。
インフラエンジニアの母集団調査のみだと、少ないのか多いのか判断がしにくいため、開発(web問わず / フルスタック含む)エンジニアの母集団調査も行いました。その結果がこちら👇
上記のデータをご覧いただき、どのように感じられたでしょうか。
「インフラエンジニア」とひとえに言っても、環境面(オンプレミスメイン/クラウドメイン)の違いもあれば、得意領域(サーバorネットワーク等)の違い、在籍企業(Sler/事業会社)の違いもあるため、大枠の所感になってしまう部分もあるかと思います。
各企業さまで採用ターゲットになりうるような、より詳細な母集団の情報を知りたい場合は、採用媒体さまや弊社にお問い合わせいただけますと幸いです。
◾️母集団データに関する補足説明
・どの採用媒体で調査をするかによって、該当人数や求人数は変化しますので、あくまで参考値としてご参照ください。(全職種向けの採用媒体で調査するか、Web系エンジニアメインの採用媒体で調査するかによって実際に数字は変化しています)
・最終ログイン「2週間」で検索条件を絞っていますが、上記の求職者が全員転職を考えている可能性は低いので、その点はご認識ください。
1-2. インフラエンジニアの業務範囲
続いて、インフラエンジニアの業務範囲についてです。
実際に各企業さまではどのような業務内容を求人票に記載しているかを10社ほど取りまとめましたので、下記をご覧ください。(中項目の業務内容に若干の重複は存在します)
インフラエンジニアの業務内容は「設計・構築・運用・保守」に大きく分かれます。企業さまによってインフラエンジニアの業務範囲は若干変化し、サーバのみを担当する場合もあれば、ネットワーク関連まで担当する場合もあります。
また、インフラエンジニアと近しい職種として、ネットワークエンジニア、サーバエンジニア、SREがありますが、一般的には下記のような使い分けをされることが多いです。
インフラエンジニア：
インフラ（サーバー、ネットワーク、データベースなど）の設計、構築、運用、保守、監視を担い、最適なインフラ環境を作り上げるエンジニア
ネットワークエンジニア：
ルータ、スイッチなどのネットワーク機器を扱い、最適なネットワーク環境を作り上げるエンジニア
サーバエンジニア：
インフラの中で特にサーバ部分を担当し、DBサーバ・Webサーバ等のサーバの設計・構築・保守・運用を担い、最適なサーバ環境を作り上げるエンジニア
SRE：
システムの信頼性を高めるための活動全般を担当する職種
「監視」「障害対応」「パフォーマンス向上」「セキュリティ対策」などの業務が該当
インフラエンジニアが大項目で、インフラエンジニアの中にネットワークエンジニアとサーバエンジニアが内包されるイメージが近しいかと思います。SREとインフラエンジニアは業務範囲や必要なスキルが異なるとご理解ください。求人票を作成する際の参考にしていただければと思います。
2. インフラエンジニア採用の全施策をまとめてみる
さあ、ここからが本題です。一体、インフラエンジニア採用において取り組むべき施策・取り組んだほうが良い施策はいくつあるのか。まずはインフラエンジニア採用において出来ることを項目別で洗い出してみました。
それがこちら👇
これをレベル別にまとめてみると・・・👇
レベル5に近づけば近づくほどインフラエンジニア採用において「強者(レベル高)」になるイメージです。(個人的な所感ですが、レベル5まで到達している企業さまはほとんどないかと思います。)
また、冒頭にもお伝えしましたが、インフラエンジニアの採用手法はバックエンドエンジニア等の開発を行うエンジニアとは異なり、エージェント・エージェントが使用している採用媒体が優先的に挙げられることが多いので、媒体選定の際の参考にしていただけましたら幸いです。(ちなみに、上述の経路以外でも、採用決定している実績はあります。)
3. インフラエンジニアの魅力設計
ここまでインフラエンジニア採用の大枠について、触れてきました。大枠がわかっても、具体的な採用戦術や手法を理解しなければ、採用成功は難しいです。ということで、採用成功の鍵を握る魅力設計についてお伝えします。
魅力設計をする際に重要なことは、「ターゲットから逆算したインサイト/メッセージング設計」です。インサイトとメッセージングとは何かを下記にて紹介します。(詳細を知りたい方はこちらのブログをご覧ください。)
インサイトとは：
「人を動かす隠れた心理」のこと
メッセージングとは：
企業や職種における「魅力」のこと
それでは詳細を見ていきましょう。
3-1. 魅力設計例①
まず、自社サービス企業さまに在籍しているインフラエンジニアの魅力設計例をお伝えします。
【想定インサイト】
現職はすでに組織ができている環境に入って経験を積むことを選択したが、これまでの経験を生かし、次回の転職は組織の立ち上げフェーズに関わりたい。
【想定メッセージング】
弊社は創業から増収増益を続け、主力サービスの領域では業界トップクラスの企業(サービス)に成長をし、資金的には投資できる安定感が出てきました。一方で弊社のエンジニアグループの人数は10名であり、企業規模から比較すると未成熟な状態です。
技術的に長けているかと言われると「これから」というフェーズになります。ただ、新しい技術をどんどん導入していく気概はあり、前述した「安定感」と後述した「未成熟感」の両者を感じることができる環境であり、資金面の安定感を感じながら、組織立ち上げをしたい方にとっては、これ以上ない環境ではないかと感じています。
上記の魅力設計について簡単に解説します。
まず、インサイトは企業のフェーズに関するものを記載しました。企業/組織フェーズに関するインサイトはどの職種でも持ちやすいため、一つのインサイトの例として持っておけると良いでしょう。
メッセージングは企業さまによりけりですが、今回は主力サービスが一定ラインまで売り上げを伸ばしているが、エンジニア組織の体制は未成熟の状況であり、新しい技術を導入していきたい意欲もあるという企業を仮定し、インサイトに刺さる可能性が高いであろうと思い作成しました。
ここでのポイントは「事業的にやや余裕ができているが、エンジニア組織は未成熟」という点です。スタートアップ/ベンチャー企業さまで働いているエンジニアのインサイトとして生まれやすいのはユーザー目線ではなく、事業面を考慮しながら開発をせざるを得ない状況が起こりうる場合があり、本質的なユーザーに寄り添った開発がしにくいということです。
事業的にやや余裕があるため、エンジニアとしてはユーザーに寄り添った(より必要な)サービス開発ができること、また、エンジニア組織が未成熟だからこそ、これまで自分が培ってきた経験を存分に活かせる可能性を伝えたく、メッセージングを作成しています。
3-2. 魅力設計例②
続いて、Sler/受託企業さまに在籍しているインフラエンジニアの2つ目の魅力設計例です。
【想定インサイト】
プロジェクト単位での仕事はやりがいがあり楽しかったが、そろそろ1プロダクトの開発/事業会社での開発にキャリアをシフトしたいと考えている
【想定メッセージング】
弊社は、 SaaSを中心にWebサービスを複数持っています。創業から増収増益を続けていますが、まだ序盤だと捉えており、今後もサービスを大きくし続けていく意向を持っています。
今あるサービスを運用し続けて大きく成長させていくことも必要ですし、新しいサービスの開発も着手していく予定です。そのため、SIerのような開発のプロジェクトごとに開発するシステムに大きく変動があるわけではなく、弊社がさらに拡大するために、長期的なサービス開発/インフラ構築にかかわることができるため、魅力的な環境を提供できると感じています。
こちらも簡単に解説します。
まず、インサイトですが、Sler/受託企業さまに在籍している方の転職理由として挙げられやすいものを記載しています。(私も採用コンサルの事業を行なっていて、プロジェクト単位での仕事は一社に在籍しているよりも、様々な経験ができるため、スキルが身に付きやすい/やりがいを感じやすいというメリットがあります。ただ、人によっては一つの企業さまに腰を据えて中長期的に長く関わりたいという方もいらっしゃいますので、参考までにご覧ください)
次に、メッセージングですが、一言でいえば、「中長期的なビジョンから逆算しながら、1社で複数のフェーズ・複数のプロダクトに関われること」を訴求しています。
今あるサービスを大きくさせていくのは、いわゆる1→10、10→100を指し、サービスの規模に応じてインフラの規模感も変化させていく必要があります。一方で、新しいサービスの開発も着手していくのは、いわゆる0→1のフェーズを指します。今あるサービスをより大きくさせていくこととは、異なる能力が求められる部分のため、1→10、10→100を経験した後に、自社でこれまでインフラ環境の構築してきたサービスと近しい領域の0→1のインフラ環境の構築に携われるのは大きな魅力になりえます。
また、事業会社として一つの大きな方向性に向かって、目の前の業務にチームで取り組むことができるのもSlerや受託企業出身者にとって魅力になる項目の一つです。
3-3. 魅力設計例③
最後に3つ目の魅力設計例をお伝えします。
【想定インサイト】
自社にてインフラをやや軽視する風潮を感じており、開発エンジニアにスポットが当たりがちのカルチャーに何とも言えないモヤモヤ感を覚えている。
【想定メッセージング】
弊社では「開発」メインのエンジニアや「インフラ」メインのエンジニアの両者が存在しています。 単一プロダクトを運用する事業会社の場合、そのプロダクトや紐づくシステムに適応すれば良いですが、弊社の場合、複数プロダクトが存在しており、かつ複雑なインフラを対象としています。
また金融領域のサービスになるため、セキュリティなどの品質が何よりも求められます。ゆえに、インフラエンジニアとしてシステムの安定性やパフォーマンスの向上に対して、組織として優先度が高いと考えています。そのため一般的なIT企業よりもインフラエンジニアの重要性が高いと自負しておりますので、やりがいも感じていただけると思っています。
まず、インサイトですが、今回は事業会社でもSlerでも当てはまるインサイトだと思います。インフラ領域は「縁の下の力持ち」という表現がされやすいですが、事業/サービスに目に見える形で直接的に影響を与えているかと言えばそうではありません。
つまり、事業/サービスを運営していく上でとても重要な領域ですが、その重要性を理解されにくい領域であると言えるため、今回のようなインサイトが生まれやすいです。
そのインサイトに対するメッセージングはインフラ領域を組織として重視していることを伝えられたら良いですよね。その伝え方はさまざまありますが、今回は事業領域(金融業界)に紐づく形で組織としてインフラ関連の重要性を理解していると伝えています。ぜひ参考にしていただければと思います。
4. インフラエンジニア採用の落とし穴
最後に、インフラエンジニア採用における落とし穴を紹介しますので、ぜひ参考にしていただけますと幸いです。
4-1. 事業会社のインフラエンジニアに固執し、採用に至らない
一つ目は事業会社のインフラエンジニアに固執し、採用に至らないことです。当たり前と思うかもしれませんが、採用においてやはりターゲットはものすごく重要です。
これまで10社弱のベンチャー、大手×DX企業さまでインフラエンジニアの採用に直接的に関わってきた私の経験上ではありますが、事業会社から事業会社へ転職した方は2~3割のイメージです。つまり、7~8割はSlerや受託企業さまの方です。まずはこの実態をご理解いただけると良いと思います。(採用した方は皆さん、自律自走できるレベルのインフラエンジニアでした)
元々、事業会社のみにターゲティングをして、インフラエンジニアの採用を行うケースは少ないかもしれませんが、ターゲットに優先度をつけるとしたら、やはり事業会社に在籍している方をまずは対象にされる企業さまが多いのではないのでしょうか。
個人的な回答としては、上述の背景から最初からSlerで一定の経験を持っているインフラエンジニアを初期からターゲットにすることをおすすめしています。もちろん、事業会社のインフラエンジニアへの魅力を複数個訴求できるのあれば、話は別ですが、Slerに在籍している方へのアプローチの方が魅力的にうつる部分が多いと思いますので、ぜひ参考ください。
4-2. 会社としてインフラエンジニアにとって最適な環境を整備できておらず、採用に至らない
二つ目は、インフラエンジニアにとって最適な開発環境を整備できていないことです。なぜ、最適な環境を整備できていないかを考えてみると、組織フェーズ的に注力できていないことを除くと、会社/組織としてインフラ領域を軽視していることが一つの要因として挙げられます。
上述しましたが、インフラ領域は経営陣やビジネスサイドメンバーのからは見えにくい領域であり、バックエンドやフロントエンドの領域と比較して「その領域にそこまでコストをかける必要があるのか？」と思われてしまうケースも少なくありません。この状況を解消するためにも、経営陣に技術をわかる人を採用することは昨今のITを前提としている事業においてほぼマストだと考えています。
インフラ領域に力を入れている/軽視していないと感じる要素をいくつか挙げると、
・社内にインフラチーム専用のコミュニティが存在している (プロダクトのチームに加え、インフラチームも存在しているイメージ)
・社内にCCoE(部署の垣根を超えて全社的に戦略的なクラウド化を進めていくための組織)が存在している
・社内にSREチームが存在している
・開発の上流部分(企画等)からインフラエンジニアも携わることができる
このようなイメージかと思います。やはりチームとして存在していると、ある程度力を入れているのだなと感じていただきやすいですよね。
また、昨今、エンジニアが働く環境を決める上で、「開発者体験(Developer Experience)」を重視しているという話をよく聞きますので、開発環境の状況を一度整理してみるのも良いかもしれません。整理する上で、日本CTO協会が監修・編纂し、2021年4月に公開したソフトウェア活用のガイドライン『DX Criteria（DX基準）』というものがありますので、参考にしていただければと思います。
5. 最後に
いかがでしたしょうか。
ここまでインフラエンジニア採用に必要な前提情報や魅力設計、採用手法に触れてきました。インフラエンジニア採用をこれから始めようとしている方や、悩んでいる方に読んでいただけましたら幸いです。
長文でしたが、最後までご覧いただき、ありがとうございました！
🔽 その他の職種の採用の教科書 (参考までにご覧ください。)
また、弊社の採用/人事組織系支援にご興味がある方はお気軽にお声掛けください。