構成を決める
ネットワーク、サーバー、クラウド、可用性、セキュリティの構成を決める。
- 案件概要: 基本設計、詳細設計、アーキテクト
- 見る点: なぜその構成にしたか説明できるか
01 / Overview
インフラとは何か
インフラは、アプリや業務システムを安定して動かすための土台です。 営業が見るべきなのは、候補者が技術名を知っているかではなく、どの土台を、どの工程で、どこまで担当したかです。
営業が見るべき中心は「どの土台を、どこまで任されていたか」
インフラは、ネットワーク、サーバー、OS、クラウド、セキュリティ、監視、バックアップ、自動化まで範囲が広い領域です。 新人営業は細かいコマンドを暗記するより、案件概要に出る技術名がどの領域を指し、候補者が設計・構築・運用・障害対応のどこを担ったのかを確認します。
新人営業が見るポイント
「知っています」ではなく「本番環境で、どの工程を、どの規模で、どの責任で扱ったか」を見ます。
02 / Work
設計・構築・運用・監視・障害対応の違い
同じインフラ経験でも、工程によって任せられる案件が変わります。 新人営業は「インフラ経験あり」でまとめず、どの工程を一人称で担当したかを確認します。
環境を作る
サーバー設定、ミドルウェア導入、クラウドリソース作成、疎通確認を行う。
- 案件概要: 構築、セットアップ、移行、検証
- 見る点: 手順書通りか、一人称で構築したか
安定稼働を守る
監視、バックアップ、パッチ適用、ログ確認、問い合わせ対応を行う。
- 案件概要: 運用保守、監視、定常作業
- 見る点: 一次対応か、原因調査までできるか
問題を切り分ける
障害発生時に、原因を切り分け、復旧し、再発防止まで整理する。
- 案件概要: 障害対応、トラブルシュート、SRE
- 見る点: 手順実行だけか、判断した経験があるか
新人営業が見るポイント
設計は判断経験、構築は一人称で作った範囲、運用は定常作業と改善、監視はアラート確認と切り分け、障害対応は復旧・再発防止までを分けて見ます。
03 / Foundation
技術基礎を営業実務に接続する
元資料の技術基礎は、案件概要・スキルシート・面談での見方に変換して押さえます。
Network必須
ネットワーク
IPアドレス、サブネット、DNS、DHCP、ポート、ルーター、スイッチ、FW、LB、VPN、SSL/TLS、SSHなど。
営業の見方「NW経験」だけでは広すぎます。設計、構築、運用監視、障害切り分け、機器設定のどれかを確認します。
Server / OS必須
サーバー・OS
Linux、Windows Server、Active Directory、IIS、Apache、Nginx、DBサーバー、ファイルサーバーなど。
営業の見方Linuxコマンド操作だけか、OS設計、ユーザー権限、サービス管理、パッチ適用、性能調査までできるかを見ます。
Cloudよく出る
クラウド
AWS、GCP、Azure。EC2、Lambda、S3、RDS、VPC、CloudWatch、BigQuery、Azure ADなど。
営業の見方資格だけでなく、実案件で触ったサービス、設計した範囲、IaCや運用監視の経験を確認します。
Securityよく出る
セキュリティ
CIA、FW/WAF、IAM、暗号化、パッチ管理、ログ収集、不正アクセス、DDoS、設定ミス対応など。
営業の見方セキュリティ専門職か、インフラ担当として基本対策を扱った経験かを分けて読みます。
Operation必須
ミドルウェア・運用監視
Nginx、Apache、Tomcat、MySQL、PostgreSQL、Redis、MongoDB、CloudWatch、Datadog、Grafanaなど。
営業の見方監視画面を見るだけか、監視設計、閾値設定、ログ分析、障害対応、バックアップ設計までできるかを確認します。
Automation差別化
コンテナ・IaC・CI/CD
Docker、Kubernetes、EKS/GKE/AKS、Terraform、CloudFormation、Ansible、GitHub Actions、Jenkinsなど。
営業の見方モダンインフラ案件で評価されやすい領域です。学習経験と本番運用経験を混同しないようにします。
まず確認すること
必須領域は「運用で触ったか」、差別化領域は「学習か本番経験か」を分けて聞きます。
04 / Job Ticket
案件概要でよく見るキーワード
キーワードを見たら、何を求めている案件なのか、どこを面談で確認するかまでセットで考えます。
工程・役割
基本設計詳細設計構築運用保守監視障害対応移行更改SREDevOps
ネットワーク
TCP/IPDNSVPNFWWAFLBL2/L3CiscoJuniperIPsec
サーバー・OS
LinuxRHELUbuntuAmazon LinuxWindows ServerActive DirectoryIISsystemctl
クラウド・自動化
AWSEC2S3RDSVPCCloudWatchAzureGCPDockerKubernetesTerraformAnsibleCI/CD
新人営業の読み方
案件概要の「AWS経験3年以上」は、EC2を操作した経験なのか、VPC設計やIAM設計まで含むのかで意味が違います。 「Linux経験」も、コマンド実行、運用監視、OS設計、障害解析でレベルが変わります。
監視・運用保守案件
- 案件概要
- 既存Webサービスの運用監視、定常作業、アラート一次対応、手順書更新。
- 必須スキル
- Linux基本操作、監視ツール利用、障害一次受付、手順書に沿った作業。
- 尚可スキル
- ログ調査、CloudWatch / Datadog、簡単なシェル、改善提案。
- 営業が確認すべきこと
- アラート確認だけか、一次切り分け・復旧補助まで担当したか。
- 人材イメージ
- 監視オペレーター、運用保守経験者、Linux定常作業に慣れた若手。
AWS基盤構築案件
- 案件概要
- WebサービスのAWS基盤構築。EC2、ALB、RDS、S3、CloudWatchを利用。
- 必須スキル
- AWS実務経験、Linux、ネットワーク基礎、構築手順書作成。
- 尚可スキル
- VPC設計、IAM、Terraform、可用性設計、障害対応。
- 営業が確認すべきこと
- 資格や個人学習ではなく、実案件でどのAWSサービスを担当したか。
- 人材イメージ
- AWS構築経験者、クラウド運用から構築へ広げた中級候補者。
ネットワーク設計・構築案件
- 案件概要
- 拠点間ネットワーク更改。VPN、FW、LB、L2/L3スイッチの設計・構築・試験。
- 必須スキル
- TCP/IP、ルーティング、FW設定、疎通試験、設計書・パラメータシート作成。
- 尚可スキル
- Cisco / Juniper、クラウドNW、障害切り分け、顧客調整。
- 営業が確認すべきこと
- 物理機器設定か、設計書作成までか、試験・切替に関わったか。
- 人材イメージ
- NW構築経験者、運用から設計補助へ広げた候補者、拠点更改経験者。
提案前に見ること
案件概要は「技術名」より先に、工程・必須スキル・尚可スキル・担当範囲を読みます。
05 / Domains
代表的な案件領域
案件領域ごとに、求められる経験と営業が確認すべきポイントが変わります。
クラウド基盤構築
AWS/GCP/Azure上にサーバー、ネットワーク、DB、監視を構築する案件。VPC、IAM、EC2、RDS、S3、CloudWatchなどが出やすい。
確認すること設計からか、構築のみか。TerraformやCloudFormationの経験があるか。
オンプレからクラウド移行
既存サーバーやDBをクラウドへ移す案件。移行計画、検証、切替、バックアウト、性能確認が重要。
確認すること移行方式、停止時間、データ移行、切替作業の経験があるか。
運用保守・監視
システムの安定稼働を守る案件。死活監視、リソース監視、ログ確認、パッチ適用、バックアップが中心。
確認すること監視オペレーションか、障害一次対応か、原因調査・再発防止までか。
ネットワーク設計・構築
拠点間接続、VPN、FW、LB、ルーティング、スイッチ設定などの案件。L2/L3や機器経験が見られる。
確認すること物理機器設定か、クラウドNWか。設計書作成、疎通試験、障害切り分けの経験を聞く。
セキュリティ基盤
WAF、IAM、ログ監視、脆弱性対応、ゼロトラスト、EDR/SIEMなど。専門性の差が出やすい。
確認すること製品運用か、ポリシー設計か、インシデント対応かを分ける。
DevOps / SRE
開発と運用をつなぎ、CI/CD、監視改善、可用性、パフォーマンス、IaCを扱う案件。
確認すること運用改善を自分で提案したか。Docker、K8s、Terraformの本番経験があるか。
06 / Skill Sheet
スキルシートの読み方
インフラのスキルシートは、技術名の羅列ではなく、工程、規模、環境、障害対応、成果物で読みます。
案件例
スキルシート記載例
- 案件
- ECサイトAWS基盤の構築・運用改善
- 環境
- AWS、EC2、ALB、RDS、S3、CloudWatch、Linux、Nginx、Terraform
- 担当
- 詳細設計、構築、監視設定、障害一次対応、手順書作成
- 成果
- 監視項目を見直し、障害検知から一次切り分けまでの時間を短縮
工程が明確か
設計、構築、運用、監視、障害対応のどこを担当したか。補助か一人称か。
環境が具体的か
AWSだけでなく、VPC、EC2、RDS、CloudWatchなどサービス名まであるか。
運用の深さがあるか
監視だけか、ログ調査、原因切り分け、再発防止、改善提案まであるか。
スキルシート記載の読み替え
| 記載 | 弱く読む場合 | 強く読める場合 | 面談で聞くこと |
|---|---|---|---|
| AWS経験 | コンソールを触った、EC2を起動した程度 | VPC設計、IAM設計、可用性設計、Terraform構築まで経験 | 担当サービスと、設計・構築・運用のどこを担当しましたか。 |
| Linux運用 | 定型コマンド、手順書通りの確認 | プロセス、ログ、権限、サービス管理、障害切り分けまで対応 | 障害時にどのログやコマンドを見て判断しましたか。 |
| 監視対応 | アラートを確認してエスカレーション | 監視項目・閾値設計、ログ分析、再発防止まで経験 | 監視設計や閾値の見直しをしたことはありますか。 |
| Docker経験 | ローカル開発環境で利用 | 本番・検証環境でDockerfile、Compose、コンテナ運用を担当 | どの環境で、何をコンテナ化しましたか。 |
| Terraform経験 | 既存コードの修正、学習のみ | モジュール設計、環境構築、レビュー、運用ルール整備まで経験 | ゼロから書いたか、既存コードを修正したかを教えてください。 |
Practice
この経歴、どう読む？
経歴の文言から、提案しやすい案件と注意が必要な案件を分ける練習です。
AWS資格あり、実務経験は個人学習のみ
- 提案しやすい案件
- AWS運用補助、クラウド移行補助、若手育成枠。
- 注意が必要な案件
- AWS設計、Terraform本番運用、リード枠。
- 面談で確認
- 資格名、個人学習で構築した構成、実務で触った範囲。
監視オペレーターとして2年経験
- 提案しやすい案件
- 監視運用、運用保守、アラート一次対応。
- 注意が必要な案件
- 障害原因調査、運用設計、クラウド構築。
- 面談で確認
- アラート確認後に、ログ調査や復旧補助まで行ったか。
Linux運用経験あり、障害時は一次切り分けまで
- 提案しやすい案件
- Linux運用保守、サーバー運用、障害一次対応。
- 注意が必要な案件
- Linux設計、性能設計、OS更改リード。
- 面談で確認
- 見ていたログ、使ったコマンド、復旧判断の範囲。
オンプレサーバー運用からクラウド案件に挑戦したい
- 提案しやすい案件
- クラウド運用補助、移行支援、ハイブリッド環境の運用。
- 注意が必要な案件
- クラウド設計、IAM/VPC設計、IaC前提案件。
- 面談で確認
- AWS/GCP/Azureの学習状況、オンプレとの差分理解。
Dockerは開発環境で使用、Kubernetesは未経験
- 提案しやすい案件
- 開発環境整備、Docker利用案件、コンテナ化補助。
- 注意が必要な案件
- Kubernetes本番運用、EKS/GKE/AKS設計。
- 面談で確認
- Dockerfile作成、Compose利用、本番コンテナ運用の有無。
07 / Interview
登録面談で聞くこと
インフラ面談では、用語を知っているかよりも、障害時・構築時にどう判断したかを聞きます。
基礎確認
- インフラ案件では、設計・構築・運用・監視のどこを主に担当していましたか。
- Linuxでよく使っていたコマンドと、その用途を教えてください。
- DNS、IPアドレス、ポート番号、HTTPSの違いを業務経験に絡めて説明できますか。
- AWS/GCP/Azureで実際に触ったサービス名と担当範囲を教えてください。
実務深掘り
- 障害が発生した時、最初に何を見て、どう切り分けましたか。
- 監視アラートの閾値や通知先を設計・見直した経験はありますか。
- オンプレからクラウド移行で、移行計画や切替作業に関わりましたか。
- TerraformやAnsibleなど、インフラ自動化を本番環境で使った経験はありますか。
回答の見極め例: △ / ○ / ◎
同じ質問でも、回答の具体性で提案できる案件が変わります。
| 質問例 | 弱い回答 | 提案可能な回答 | 強く推せる回答 |
|---|---|---|---|
| Linuxで障害調査する時、何を確認しますか | ログを見ます。必要なら再起動します。 | systemctlでサービス状態を見て、journalctlやアプリログ、CPU/メモリ/ディスクを確認します。 | アラート内容からサービス、OS、NW、DBのどこが怪しいか仮説を立て、ログ、リソース、疎通、直近変更を確認して復旧と再発防止まで整理します。 |
| AWSでは何を担当しましたか | EC2やS3を触ったことがあります。 | EC2、ALB、RDS、S3、CloudWatchを使ったWeb基盤の構築と運用を担当しました。 | VPC、サブネット、ALB、EC2、RDS、IAM、監視まで設計し、Terraformで環境構築、障害時のログ調査と改善も担当しました。 |
| DNSの名前解決を説明してください | ドメインをIPに変換するものです。 | ブラウザでドメインを入力するとDNSでIPを取得し、そのIPへ通信します。 | クライアント、キャッシュDNS、権威DNSの流れ、A/CNAMEレコード、TTL、障害時の切り分けまで業務例で説明できます。 |
| Terraform経験を教えてください | 少し触りました。既存コードを修正しました。 | AWSリソースの追加や変更をTerraformで行い、plan/applyの流れで反映しました。 | 環境ごとの変数管理、モジュール化、レビュー運用、state管理、既存リソース取り込みまで経験し、手作業ミス削減に使いました。 |
| 監視設計で意識したことは何ですか | CPUやメモリを見ることです。 | CPU、メモリ、ディスク、死活、ログエラーを監視し、閾値超過時に通知するよう設定しました。 | 業務影響の大きい指標からSLOを考え、誤検知と検知遅れのバランスを見て閾値、通知先、一次対応手順まで設計しました。 |
08 / Level
レベル感の見極め
インフラのレベルは、年数よりも「一人称でどこまで判断したか」で見ます。
監視・運用オペレーター
手順書に沿った監視、アラート確認、定型作業、一次エスカレーションが中心。
提案しやすい案件運用監視、ヘルプデスク寄りインフラ、定常作業、手順書作業。
構築・運用改善エンジニア
Linux、NW、クラウド、ミドルウェアの構築や障害切り分けを一人称で進められる。
提案しやすい案件AWS構築、サーバー構築、運用保守、監視改善、移行支援。
基盤設計・SRE・リード
可用性、性能、セキュリティ、DR、IaC、コスト、チーム推進まで設計できる。
提案しやすい案件クラウド設計、アーキテクト、SRE、DevOps、IaC標準化、リード案件。
レベル判断の軸
- 工程: 監視だけか、構築か、設計か、改善提案までか。
- 判断: 手順実行か、原因切り分けか、設計判断か。
- 環境: 検証環境か、本番環境か。小規模か、大規模・高可用性か。
- 自動化: 手作業か、Terraform/Ansible/CI/CDで再現性を作ったか。
- 障害対応: エスカレーションのみか、復旧・再発防止まで担当したか。
09 / Mismatch
営業がミスりやすい提案
インフラ提案では、技術名だけを合わせるとミスマッチが起きます。
新人がやりがちなミスマッチ
| よくあるミス | なぜ危ないか | 面談で確認すること |
|---|---|---|
| AWS資格ありだけでAWS設計案件に提案する | 資格は知識証明であり、本番設計経験とは別 | 実案件で設計したAWSサービス、構成図、判断内容を聞く。 |
| 監視経験を障害対応経験として提案する | アラート確認だけでは原因調査や復旧判断ができない可能性がある | 一次対応、ログ調査、復旧、再発防止のどこまで担当したか。 |
| オンプレ運用経験をクラウド構築案件へそのまま出す | クラウド特有のIAM、VPC、マネージドサービスの理解が不足することがある | クラウドで実際に構築した経験、オンプレとの差分理解を聞く。 |
| Docker学習経験をKubernetes本番運用案件へ出す | DockerとK8sは求められる運用難度が違う | 本番でのPod、Deployment、Service、EKS/GKE/AKS経験を聞く。 |
| Linuxコマンド経験をLinux設計経験として提案する | 操作経験とOS設計・運用設計は別 | ユーザー設計、権限、サービス、ログ、パッチ方針まで経験があるか。 |
| セキュリティ運用をセキュリティ設計として提案する | 製品運用とポリシー設計・脆弱性対応はレベルが異なる | WAF/FW/IAMの設定、ルール設計、インシデント対応経験を聞く。 |
技術名だけの提案を、根拠つきに直す
AWS経験があります。
AfterAWS環境でEC2、ALB、RDS、S3、CloudWatchを用いたWeb基盤の構築・運用を担当しており、監視設定と障害一次切り分けまで経験があります。
Linuxできます。
AfterLinux環境でsystemctl、journalctl、アプリログを用いたサービス状態確認、障害一次切り分け、定常運用を経験しています。
Terraform経験があります。
AfterTerraformで既存コードの修正、plan確認、レビュー後のapplyまで経験しており、手作業ではなくコードで変更を管理していました。
10 / Proposal
提案時の注意点と補足コメント例
提案では「AWSできます」ではなく、案件側が安心できる担当範囲と根拠を添えます。
提案時の注意点
- 資格、学習、検証、本番経験を分けて伝える。
- 設計・構築・運用・監視・障害対応のどこが強いかを明確にする。
- クラウド案件では、サービス名と担当範囲を具体的に補足する。
- 運用案件では、定型作業だけでなく改善・障害切り分け経験を補足する。
- 自動化案件では、TerraformやAnsibleを本番で使ったかを確認してから出す。
提案前に見ること
提案コメントは長くせず、案件側が不安に思う「担当範囲」「本番経験」「障害対応力」を一文で補足します。
11 / Check
確認テスト
案件概要・スキルシート・面談・提案の判断軸が残っているかを確認します。
1. インフラエンジニアの主な業務を4つ挙げてください。
回答の観点:
設計、構築、運用、障害対応。案件概要ではどの工程を求めているか確認する。
2. 「AWS経験あり」と書かれたスキルシートで確認すべきことは何ですか。
回答の観点:
触ったサービス名、担当工程、設計か構築か運用か、本番経験か、IaC経験があるか。
3. 監視経験と障害対応経験は何が違いますか。
回答の観点:
監視は異常検知やアラート確認。障害対応は原因切り分け、復旧、影響確認、再発防止まで含む。
4. Docker経験者をKubernetes案件へ提案する前に何を聞きますか。
回答の観点:
Dockerがローカル利用か本番利用か、K8sのPod/Service/Deployment、EKS/GKE/AKSの経験があるか。
5. インフラ提案コメントで技術名だけでは弱い理由は何ですか。
回答の観点:
技術名だけでは、工程、規模、責任範囲、本番経験、障害対応力が分からないため。
営業判断問題
6. 「AWS資格のみ・実務なし」の候補者をAWS設計案件に提案してよいですか。
回答の観点:
基本は慎重に判断します。資格は知識証明で、本番設計経験とは別です。若手枠や構築補助なら可能性がありますが、設計案件では実務で触ったサービスと構成説明力を確認します。
7. 監視経験を障害対応経験として強く打ち出してよいですか。
回答の観点:
アラート確認のみなら強く打ち出しません。ログ調査、一次切り分け、復旧補助、再発防止まで関与していれば補足できます。
8. Docker経験者をKubernetes本番運用案件に提案する前に何を確認しますか。
回答の観点:
Dockerが開発環境利用か本番利用か、KubernetesのPod、Service、Deployment、EKS/GKE/AKSの実務経験があるかを確認します。
9. Linux運用経験者をLinux設計案件に提案する前に何を確認しますか。
回答の観点:
ユーザー・権限設計、サービス管理、ログ設計、パッチ方針、運用設計書作成など、操作だけでなく設計判断に関わったかを確認します。
10. オンプレ経験者をクラウド移行案件に提案する場合、何を補足すべきですか。
回答の観点:
既存サーバー運用、移行対象の理解、切替・検証・手順書経験に加え、クラウド学習状況やAWS/GCP/Azureで触ったサービスを補足します。
12 / Summary
まとめ
インフラ提案の精度は、技術名ではなく「環境・工程・判断経験」を読めるかで変わります。
案件概要
クラウド、OS、NW、監視、セキュリティ、自動化のどの領域かを読む。
スキルシート
設計、構築、運用、障害対応、改善、自動化のどこまで担当したかを見る。
登録面談
障害時の切り分け、担当サービス、設計判断、本番経験を具体的に聞く。
提案
案件側の不安に対して、任せられる範囲と根拠を短く補足する。
会話で使える提案コメント