インフラエンジニアを探すときの検索条件とターゲティング

インフラエンジニアにスカウトを送る前の検索で、「クラウドの経験、年数〇年以上」だけで条件を組むと、構築を専門にしてきた人と、運用を長くやってきた人が同じ一覧に出てきます。二つの層は求めるものが違い、同じ文面ではどちらにも刺さりません。もう一つ、基盤の名前で検索すると、「触ったことがある」人と「その基盤で本番環境を設計して運用した」人が同じに出ます。インフラの検索で最初にやるべきは、「構築か運用か」を決め、必須だけで条件を組み、出てきた人を「規模と構成と何をしたか」で読むことです。結論を先に書くと、検索条件は、先に「構築か運用か」を決め、要件の必須だけで組み、基盤の名前より「規模と構成と何をしたか」で読み、工程（設計・構築・移行・運用・改善）と体制（一人か、チームか、当番の経験）で絞り、プロフィールの記述の量と更新時期で送る順を決めます。文面の型はインフラエンジニアへのスカウト文面に、要件の作り方はインフラエンジニアの採用要件の作り方に書いていますので、ここでは「検索条件とターゲティング」に絞ります。媒体ごとの検索の仕様には触れません。仕様は各媒体の公式情報でご確認ください。

先に「構築か運用か」を決める

自社が求めているのが「これから作る（設計・構築・移行）」なのか「守る（運用・監視・改善）」なのかで、探す層が変わります。両方を求めるなら、割合を決めて主のほうで探します。

止まりやすいのは、決めずに「インフラ全般」で探すときです。出てきた一覧が混ざり、文面も混ざります。

条件は「必須」だけで組む

要件の必須だけを条件にします。歓迎まで入れると狭くなりすぎ、必須を外すと広くなりすぎます。基盤の名前を条件に入れる場合も、複数を「かつ」で組まず、「または」にします。

要件に必須と歓迎の区別が無ければ、先に分けます。分け方はインフラエンジニアの採用要件の作り方に書いています。

基盤の名前より「規模と構成と何をしたか」で読む

基盤の名前の一致だけでは、経験の中身は分かりません。プロフィールを読むときは、規模、構成、その人が何をしたか、を見ます。

止まりやすいのは、基盤の一致だけで送るときです。「〇〇の経験あり」の人に「〇〇の設計を任せたい」と送っても、経歴と合わず返信は来ません。

エラベルの見解

相談で最も多い思い込みは、「クラウドの経験があれば、インフラは誰でも大体できる」というものです。実際には、構築を専門にしてきた人と運用を長くやってきた人は、経験も関心も違い、同じ条件で探して同じ文面を送ると、どちらからも返信が来ません。ある会社では、クラウドの経験と年数だけで検索し、構築と運用が混ざった一覧に同じ文面を送っていました。担当者が入って、自社の求めるものを「移行の設計が主で、運用は既存メンバーと分担」と現場と決め、検索を「移行」「設計」の言葉で読む形にし、出てきた人を規模と何をしたかで絞ったところ、送る相手は減りましたが、一行目に書ける一点が見つかり、返信が来るようになりました。インフラの検索は、基盤の名前で機械的に絞るより、構築か運用かを決めて人が読むほうが合います。

工程と体制で絞る

規模と構成の次に、工程（設計・構築・移行・運用・改善）と体制（一人で守ったか、チームで分担したか、当番の経験、開発チームとの関係）を見て、自社の任される範囲と体制に合う人に絞ります。

止まりやすいのは、任される範囲と体制が決まっていないときです。「インフラ全般をお願いしたい」では絞れません。先に現場と決めます。

プロフィールの読みどころ

一つ目は、直近の経験です。数年前の基盤より、いま何を守っているか、何を作っているかを見ます。

二つ目は、自分で書いた文章の量です。基盤の一覧だけの人より、「なぜこの構成にしたか」「障害でどう対応したか」を書いている人は、一行目に触れる一点が見つかりやすい。

三つ目は、働き方の記述です。「当番の少ない環境を希望」「改善に時間を使いたい」と書いてあれば、自社の条件と合うかを先に見ます。合わない人には送りません。

四つ目は、更新の時期です。

五つ目は、経歴の一点です。一行目に書ける具体の一点（基盤、規模、構成、移行、改善のどれか）が見つかるか。見つからない人には送りません。

送る順の付け方

止まりやすいのは、「せっかく出てきたから全員に」と送るときです。構築の人に運用の文面を送ると、返信が来ないうえに「読んでいない」と受け取られます。

条件の保存と見直し

組んだ条件は、「構築用」「運用用」のように役割ごとに名前を付けて保存し、送った結果と一緒に記録します。月に一度、返信が来た人の共通点（規模、工程、体制、働き方の希望）を見て、条件と読み方を直します。担当者が替わっても同じ検索ができるように、条件を担当者の頭の中に置きません。保存の仕方は検索条件の保存と使い回しに書いています。

エラベルの見解

担当する側から見ると、インフラの検索で会社ごとに差がつくのは、「当番と障害対応の体制が決まっていて、それに合う人を探しているか」です。条件の組み方と読み方は担当者が持てますが、自社の当番が月に何回で夜間はどうしているかが曖昧だと、「当番の少ない環境を希望」と書いている人に送ってしまい、面談で辞退されます。当番の体制が事実として決まっている会社では、検索の段階で働き方の希望が合う人に絞れ、面談後の辞退が減ります。エラベルでスカウトの検索を担当する人には、条件を組む前に、現場に「構築か運用か」「当番の頻度」「開発チームとの関係」を聞いてもらっています。それが分かると、検索も文面も面談も一本につながります。文面の型はインフラエンジニアへのスカウト文面に書いています。

代行に出す場合の範囲

担当者が持つのは、要件から必須を取り出して条件を組むこと、出てきた人を規模と構成と工程と体制で読んで絞ること、働き方の希望が合う人に送る順を付けること、条件と結果を記録して月に一度見直すこと、です。会社が持つのは、構築か運用かの決定、要件の必須と歓迎の区別、当番と障害対応の体制の事実、現場が担当者に話す時間、です。担当者がインフラの経歴（規模、構成、工程）を読める経験があるかは、担当者を選ぶときに確かめます。担当者の経歴の見方は担当者の経歴の見方に書いています。

まとめ

• 先に構築か運用かを決める。混ぜて探すと混ざった一覧に混ざった文面を送ることになる
• 検索条件は要件の必須だけ。基盤の名前は「または」で組む
• 基盤の名前の一致ではなく、規模と構成と何をしたかで読む
• 工程（設計・構築・移行・運用・改善）と体制（一人・チーム・当番・開発との関係）で、任される範囲と合う人に絞る
• 働き方の希望が自社の当番の体制と合わない人には送らない。面談で辞退される
• 条件は構築用・運用用で分けて保存し、返信が来た人の共通点で月に一度直す

よくある質問

構築の経験者が少なく、出てきません

構築の経験は市場に少ない傾向があります。条件を「設計」「構築」「移行」「立ち上げ」の言葉で読む形にし、基盤の名前は問わず、規模が近い人まで広げます。それでも少ないなら、運用の経験が長く「改善」「自動化」を書いている人を、構築への転向の候補として含めます。文面では「運用のご経歴から、構築に軸足を移したい方へ」と、転向であることに先に触れます。

オンプレミスからクラウドへの移行を任せたいのですが、どちらの経験者を探せばよいですか

移行は、旧環境と新環境の両方を知っている人が向きます。プロフィールで「〇〇から〇〇への移行」の記述がある人を最優先にし、次に、クラウドの構築の経験があり旧環境の運用も経験している人を見ます。クラウドだけの人は旧環境の制約を知らず、旧環境だけの人はクラウドの設計を知りません。両方を書いている人は少ないので、見つけたら一行目でその点に触れます。

年数の条件はどう置けばよいですか

年数は目安にとどめ、条件に入れるなら低めにします。インフラは、年数より「本番環境をどの規模で、何をして守ったか、作ったか」で経験の中身が決まります。年数を高く置くと、規模の大きい環境で数年の経験がある人が漏れます。年数で絞らず、規模と工程で読みます。