インフラエンジニアの採用要件の作り方｜必須と歓迎を分ける基準

インフラエンジニアの求人票の必須要件には、「オンプレとクラウドの両方」「サーバとネットワークの両方」「運用と構築の両方」「特定の資格」「経験五年以上」が並びがちです。全部を満たす人は、市場にほとんどおらず、いても条件が高い。結論を先に書くと、インフラエンジニアの採用要件は、先に「運用か構築か」の層を決め、必須を「入社初日に自社の環境で業務が成り立つか」で三つ以内に絞り、資格と年数は必須にしないのが、母集団が生まれる形です。層を決めずに要件を積むと、運用の人と構築の人の両方の要件が混ざり、誰にも当てはまらなくなります。開発エンジニアの要件の作り方はエンジニアの採用要件の作り方に、代行に出す工程の線はインフラエンジニア採用を代行に出す判断基準にまとめています。

インフラ職で要件が膨らむ理由

開発職と共通する理由（現場の希望を全部書く、前任者を基準にする、失敗を避けたい）に加えて、インフラ職に特有の理由があります。

一つ目は、領域が広いことです。サーバ、ネットワーク、ストレージ、クラウド、セキュリティ、監視、自動化。インフラと呼ばれる領域は広く、一人で全部を担ってきた人は少ない。求人票に領域を全部並べると、それぞれの経験を求めることになります。

二つ目は、運用と構築を一人で求めることです。「運用しながら、構築もできる人」は、市場に少なく、いても運用の負担が大きい会社を避けます。両方を書くと、両方の人が「自分には片方が足りない」と見送ります。

三つ目は、オンプレとクラウドの両方を求めることです。オンプレからクラウドへ移行中の会社は、両方の経験を求めますが、両方を深く経験した人は限られます。移行の設計ができる人と、移行後の運用ができる人は、別のことが多い。

四つ目は、資格を必須にすることです。資格は経験の証明として書きやすいですが、資格があっても自社の環境の経験が無いことはあり、資格が無くても経験が深いことはあります。資格を必須にすると、後者を弾きます。

五つ目は、年数です。「五年以上」は書きやすい代わりに、年数と技術の深さは一致しません。運用を五年やった人と、構築を二年やった人では、構築の募集なら後者が合うこともあります。

必須と歓迎を分ける基準

基準は、開発職と同じく「入社初日に、これが無いと業務が成り立たないか」です。インフラ職では、「自社の環境で」を添えます。自社の環境がオンプレなら、クラウドの経験は初日には要りません。移行の設計を任せるなら、移行の経験は要ります。

基準の要点は、「資格と年数を必須にしない」ことです。資格は歓迎に置き、年数は「〇〇規模の環境を設計から運用まで一人で担った経験」のように、経験の中身に置き換えます。

エラベルの見解

相談で多いのは、「オンプレからクラウドへ移行するので、両方の経験がある人を必須にしたい」というご相談です。両方を深く経験した人は市場に少なく、いても移行を何度も経験している人で、条件が高い。移行の設計ができる人（クラウドの設計の経験があり、オンプレは概念が分かればよい）と、移行後の運用ができる人は別で、まず前者を採り、後者は既存の担当が学ぶか、移行後に採る、という順番のほうが現実的です。

見ていて差がつくのは、「自社の環境で、初日に何を触ってもらうかを言えるか」です。「初日からオンプレのサーバの運用に入る」なら、オンプレの運用が必須で、クラウドは歓迎。「初日から移行の設計に入る」なら、クラウドの設計が必須で、オンプレは概念の理解で足りる。初日の業務が決まれば、必須は自然に絞れます。エラベルでは、インフラ職の要件を整理するとき、依頼側に「初日と一か月後に触る環境と業務」を伺い、そこから必須を決めていただいています。

必須を三つに絞る手順

インフラ職向けに、絞る手順を番号付きで整理します。

1. 運用か構築か、採る層を決める。 両方なら優先を決める。ここが決まらないと要件は決まらない。
2. 初日と一か月後に触る環境と業務を、現場に書き出してもらう。 オンプレかクラウドか、どの領域か、運用か構築か。
3. 現場の希望を全部書き出す。 領域、技術、資格、年数、規模。ここでは絞らない。
4. 一つずつ、「初日に自社の環境で、これが無いと業務が成り立たないか」を問う。 成り立たないものだけ残す。
5. 残ったものが三つを超えたら、「社内か委託先の誰かが数か月補えるか」を問う。 補えるものは歓迎へ。
6. 資格と年数を、経験の中身に書き換える。 「〇〇の資格」ではなく「〇〇の設計を担った経験」。「五年以上」ではなく「〇〇規模の環境を一人で運用した経験」。
7. 歓迎に回したものを、優先順位を付けて三〜五つ書く。 面接で見る点になる。
8. 現場・人事・経営で確認する。 「この三つがあれば、他は入社後に補える」と三者が言えるか。

手順の要点は、「一と二を先にやる」ことです。層と初日の業務が決まっていない状態で三から始めると、希望の羅列に戻ります。

経歴で確かめられる要件と、面接でしか分からない要件

インフラ職では、経歴の言葉が実態を表さないことが多いので、確かめ方の区別がとくに重要です。

分け方の要点は、「『構築経験あり』の実態を、書類の段階で確かめる」ことです。一台の設定と数百台の設計は、どちらも「構築経験」と書かれます。書類の一次絞りで、規模と方法（画面かコードか）を確かめる項目を入れると、面接の時間を経歴の確認に使わずに済みます。

要件が決まらないときの原因

原因の要点は、「委託先との分担」がインフラ職に特有だという点です。インフラの一部を外部に委託している会社では、委託先が持つ領域を自社の要件に入れてしまうことがあります。分担を先に決めれば、自社で持つ領域だけが要件になります。

代行に出せる工程

分け方の要点は、開発職と同じく「判断は社内、進行と言語化は代行」です。加えて、インフラ職では「委託先との分担の整理」を代行が手伝えます。委託先と自社と代行の三者で分担を一覧にすると、要件が定まります。

エラベルの見解

担当する側から見ると、インフラ職の要件で最も時間がかかるのは、「運用か構築か」と「委託先との分担」を依頼側から引き出すことです。どちらも依頼側の中では曖昧なままで、聞くと「両方」「委託先と相談しながら」と返ってきます。ここを「優先は構築」「ネットワークは委託先、サーバとクラウドは自社」まで具体化しないと、必須は決まりません。

エラベルでは、インフラ職の案件で要件が整理されていない場合、担当者の最初の仕事を「層と分担を決める打ち合わせの進行」にすることをお勧めしています。募集が始まるのは数週間遅れますが、層と分担が決まった要件で募集を始めると、合わない応募が減り、面接の時間が有効に使えます。飛ばして募集を急ぐと、「オンプレもクラウドも運用も構築も」という要件で、誰も来ない数か月になります。

まとめ

• インフラ職の必須要件は、先に運用か構築かの層を決め、「入社初日に自社の環境で業務が成り立つか」で三つ以内に
• 要件が膨らむインフラ職特有の理由は領域が広い・運用と構築を一人で求める・オンプレとクラウドの両方を求める・資格を必須にする・年数で書く
• 資格と年数は必須にしない。資格は歓迎に、年数は経験の中身に
• 絞る手順は層の決定→初日の業務の書き出し→全部書き出す→初日に成り立つか→誰かが補えるか→資格と年数を中身に→歓迎に優先順位→三者で確認
• 「構築経験あり」の実態（規模、画面かコードか）を書類の段階で確かめる
• 決まらない原因に委託先との分担がインフラ職特有。分担を先に決める
• 代行に出せるのは進行・言語化・分担の整理・市場との照らし合わせ・一次絞り・面接の質問の案

よくある質問

資格を必須にすると、一定の技術水準が保証されませんか

資格は、一定の知識があることの目安にはなりますが、自社の環境での実務の経験は保証しません。資格があって実務が浅い人と、資格が無くて実務が深い人がいて、必須にすると後者を弾きます。資格は歓迎に置き、必須は「〇〇の設計を担った経験」のように、経験の中身で書きます。面接で技術の考え方を聞けば、資格の有無に関わらず、水準は分かります。資格を評価の材料にするのは構いませんが、入口の条件にはしないほうが、母集団が生まれます。

移行中で、オンプレとクラウドの両方に触ってもらう必要があります

両方に「触る」ことと、両方を「深く経験している」ことは別です。移行の設計を任せるなら、クラウドの設計の経験を必須にし、オンプレは「概念が分かり、既存環境を読める」程度を歓迎に。移行後の運用を任せるなら、クラウドの運用を必須にし、オンプレは移行が終わるまでの一時的な業務として、既存の担当と分担する。両方を必須にすると市場にいないので、どちらを軸に採るかを決め、もう一方は入社後に自社の環境で覚えてもらう形にします。

委託先がいるので、要件を委託先に決めてもらってよいですか

委託先は自社の環境を知っていて、「どういう人が入れば分担がうまくいくか」を言えるので、要件の整理を手伝ってもらうのは有効です。ただし、委託先が決めるのではなく、自社が決めます。委託先の視点は「自分たちの仕事がやりやすい人」に寄ることがあり、自社が将来持ちたい領域（内製化したい部分）と合わないことがあります。委託先に分担の一覧を出してもらい、自社で持つ領域を自社が決め、その領域の要件を自社と委託先と（代行がいれば代行と）で整理する、という形にします。