サーバーエンジニアの求人票には、ほぼ必ず「設計・構築」と書かれています。ところが入社してみると担当は手順書どおりの作業だけ、ということが起こります。求人票の言葉と、実際に任される工程がずれているからです。
この記事では、求人票のどこを読み、面談で何を質問すれば、そのずれを入社前に見抜けるかを整理します。
このページはサーバーエンジニア転職完全ガイドの各論です。転職の進め方を最初から確認する場合はそちらへ。
求人票だけでは工程は判断できない
「設計・構築フェーズを担当していただきます」という一文は、ほとんどのサーバー求人に載っています。この表現自体が嘘ということではなく、チームとして設計・構築を請けているという意味で書かれていることが多いためです。そのチームの中で自分が何をするかは、求人票からは読み取れません。
入社前に確かめられるのは、次の4点です。
| 確認する軸 | 求人票で見るところ | 面談で確かめること |
|---|---|---|
| 工程 | 要件定義・基本設計・詳細設計・構築・試験・運用のどこまで書いてあるか | 入社1年目に担当する工程はどこまでか |
| 成果物 | 「設計書」「パラメータシート」「試験成績書」の記載があるか | それを作るのか、レビューするのか、受け取るのか |
| レビュー | チーム構成・教育体制の記述 | 作った資料を誰がレビューするか |
| 商流 | 自社サービスか、SIerか、SESか | 配属先は決まっているか、変更条件は何か |
「設計構築あり」が実態と違う3パターン
求人票の記載と実際の担当がずれるとき、多くは次の3つのどれかです。
1. 構築はするが、設定値は他社が決めている
いちばん多いパターンです。上流のSIerがパラメータシートまで作り、それを受け取って機器やサーバーへ投入する。作業自体は本番環境で、責任も重い。ただし「なぜその値なのか」を決める工程には入っていません。職務経歴書に「構築を担当」と書けますが、面接で「その設定値はどう決めましたか」と聞かれると答えられません。
2. 設計はするが、対象がドキュメントの更新だけ
既存システムの設計書を、変更内容に合わせて修正する作業を「設計」と呼んでいる場合です。方式を選ぶ、比較検討する、といった判断は含まれません。経験としては無価値ではありませんが、上流工程の経験として説明すると面接で齟齬が出ます。
3. 案件次第で、実際には運用に配属される
SESで起こりやすいパターンです。求人票に書かれているのは会社が受注している案件全体の内容で、自分がどこに入るかは配属時に決まります。「設計構築案件もあります」は「設計構築案件もある」という意味です。
面談で担当工程を確かめる5つの質問
抽象的に「設計に関われますか」と聞いても、「関われます」としか返ってきません。答えが具体的にならざるを得ない聞き方をします。
- 入社1年目の方は、どの工程を担当していますか
直近で入社した人の実例を聞きます。「人によります」で終わる場合は、決まっていないと考えます。 - パラメータシートは、どなたが作成していますか
自社なのか、上流のSIerなのか。ここで構築の深さが分かります。 - 作成した設計書は、誰がレビューしますか
レビュー担当がいない現場では、作った資料の良し悪しが分かりません。成長の速度に直結します。 - 試験項目書は、既存のものを流用しますか、案件ごとに作りますか
流用だけなら試験設計の経験は積みにくくなります。 - 配属先は決まっていますか。変わる条件は何ですか
SESで最も重要な質問です。決まっていない場合、求人票の内容は参考情報に留まります。
ネットワーク側の求人でも考え方は同じです。工程の見分け方はインフラエンジニア転職完全ガイドにもまとめています。
担当する層で仕事の中身が変わる
サーバーエンジニアという同じ職種名でも、どの層を見るかで日常業務は変わります。求人票の技術キーワードから、担当範囲を推測できます。
| 求人票のキーワード | 推測できる担当範囲 | あわせて確認すること |
|---|---|---|
| ラッキング、キッティング、データセンター | 物理層が中心。構築の下流 | 設計工程への配属実績があるか |
| VMware vSphere、Hyper-V、仮想基盤 | 仮想化基盤の設計・構築 | 基盤設計まで担当するか、VM払い出しだけか |
| Red Hat、CentOS、Windows Server、Active Directory | ゲストOSの構築・運用 | キッティングだけか、方式設計もあるか |
| Apache、Nginx、PostgreSQL、Oracle | ミドルウェアの構築・チューニング | アプリ担当との切り分けはどこか |
| AWS、Azure、Terraform、Ansible | クラウド基盤・自動化 | 移行案件か、新規構築か、運用か |
担当する層ごとの実際の作業内容はサーバーエンジニアの仕事内容で、進路の広げ方はサーバーエンジニアのキャリアパスで確認できます。
商流によって、確認すべきことが変わる
同じ「サーバーエンジニア募集」でも、その会社がどの立ち位置で仕事を受けているかで、入社後に見える景色が変わります。求人票の会社概要と、面談で聞いた配属の話を突き合わせます。
| 商流 | 担当しやすい工程 | 面談で必ず聞くこと |
|---|---|---|
| 事業会社（自社システム） | 要件定義から運用まで一貫。ただし新規構築の頻度は低い | 直近3年で新規構築案件があったか |
| SIer（元請け） | 要件定義・基本設計。手を動かす作業は協力会社へ出すことも | 実機を触る機会がどのくらいあるか |
| SIer（2次請け以降） | 詳細設計・構築・試験 | パラメータシートを作る側か、受け取る側か |
| SES | 案件次第。運用から設計まで幅がある | 配属先が確定しているか、案件選択の制度があるか |
SESが悪いという話ではありません。案件を選べる制度があり、配属前に現場の工程を確認できるなら、事業会社より早く構築経験を積めることもあります。逆に、配属先が入社後に決まる求人では、求人票の記載は判断材料になりません。
未経験と経験者で、見るところが変わる
未経験から応募する場合
未経験可の求人で最初に見るのは、設計構築の有無ではありません。教育担当が付くかと次工程への配属実例があるかです。運用監視から始まること自体は問題ではなく、そこから動けるかどうかが分かれ目になります。
- 入社後の研修期間と、その後の配属先が具体的に書かれているか
- 運用から構築へ移った人の実例を、面談で聞けるか
- 夜勤・シフトの回数が明記されているか
- 資格取得の支援が、費用補助だけでなく学習時間の確保まで含むか
準備の進め方は未経験からサーバーエンジニアへ転職するにはにまとめています。
運用経験がある人が応募する場合
すでに運用保守を経験しているなら、確認するのは「構築に入れるか」ではなく「いつ、どの案件で入れるか」です。時期と案件が具体的に出てこない場合、入社後も同じ運用作業が続く可能性があります。
あわせて、自分の経験を工程の言葉に翻訳しておきます。「監視をしていました」ではなく、「アラートを受けて一次切り分けを行い、手順書にない事象はエスカレーションしていました」と説明できると、構築寄りの求人でも評価の土台ができます。具体的な進み方はサーバー運用保守から設計構築へ転職する方法で扱っています。
関連する記事
まとめ
求人票の「設計・構築」は、会社が請けている工程を指しています。自分が担当する工程とは別です。工程・成果物・レビュー・商流の4点を求人票で確認し、面談では入社1年目の実例、パラメータシートの作成者、レビュー担当、試験項目書の扱い、配属の確定度を聞きます。抽象的な質問には抽象的な答えしか返らないので、答えが具体的にならざるを得ない聞き方をしてください。
