公開: 2026/4/23|更新: 2026/7/24

クラウドエンジニア採用ガイド｜要件定義から選考・口説き方まで

クラウドエンジニアの採用が難しい理由と要件定義・選考設計・スカウト・口説き方の実践手法を解説

クラウドエンジニア採用を成功させる要点

クラウドエンジニアを採用するには、まず「クラウド設計を任せたいのか、運用を任せたいのか」を明確にし、SRE・DevOps・インフラエンジニアとの役割の違いを整理してから要件を定義することが出発点です。年収相場はミドルで550〜800万円、シニアで800〜1,200万円と高く、求人票にクラウド環境の規模感と設計裁量を具体的に書けるかどうかで応募数が大きく変わります。以下、要件定義から選考・口説き方・定着までを実務目線で解説します。

TL;DR（この記事の要約）

クラウドエンジニアはAWS・Azure・GCPなどのクラウド基盤の設計・構築・運用を担う専門職で、DX推進とクラウド移行の加速により企業の採用需要が急拡大中
経験者の市場価値が高く、正社員の平均年収は550〜660万円、シニアクラスで900〜1,200万円超。マルチクラウド対応やIaC経験者はさらに上振れする
SRE・DevOps・インフラエンジニアとの違いを正しく理解し、自社が求める役割を明確にすることが採用成功の第一歩
求人票ではクラウド環境の規模感・技術スタック・アーキテクチャ設計への関与度を具体的に記載すると候補者に刺さりやすい
選考ではアーキテクチャ設計力・コスト最適化の意識・セキュリティ設計の深さがクラウドエンジニアの実力を見極めるポイント

クラウドエンジニアとは——なぜ今、採用ニーズが高まっているのか

クラウドエンジニアとは、AWS・Azure・GCPなどのパブリッククラウド上でインフラ基盤の設計・構築・運用・最適化を行う専門職です。可用性・セキュリティ・コストのバランスを取りながら事業の成長に耐えるアーキテクチャを設計し、Infrastructure as Code（IaC）で再現性のある基盤を構築する役割を担います。

「オンプレからクラウドに移行したいが、設計できる人がいない」「クラウドコストが膨らんでいるのに、最適化できるエンジニアがいない」——スタートアップや成長企業の採用現場で、こうした声が年々増えています。

採用市場の需要データ

クラウドエンジニアを取り巻く採用環境（2026年）
IT人材の不足規模: 最大約79万人（経済産業省「IT人材需給に関する調査」2019年公表・2030年推計）
エンジニア全体の中途求人倍率: 10.68倍（パーソルキャリア「doda転職求人倍率レポート」2024年、専門職〈エンジニア〉区分）
クラウド関連スキルは求人倍率がとりわけ高く、経験者の絶対数不足が採用難の根本要因

クラウドエンジニアの採用需要が拡大している背景

クラウドエンジニアの需要拡大には、いくつかの構造的な要因があります。

クラウド移行が「導入」から「最適化」フェーズへ: 多くの企業がクラウド導入を完了し、安定稼働・コスト最適化・マルチクラウド戦略の実行段階に入った。アーキテクチャを見直せる人材の需要が急拡大している
DX推進とクラウドネイティブ化の加速: 「2025年の崖」を超え基幹システムのモダナイゼーションに着手する企業が増加。コンテナ・サーバーレス・マイクロサービスを設計運用できる人材が引く手あまた
セキュリティ・コンプライアンス要件の高度化: ゼロトラスト導入やSOC2・ISO27001・PCI DSS対応を理解したエンジニアの希少性が高まっている
AI/ML基盤の構築需要: GPUクラスタ構築・推論基盤設計・MLOps運用といった「AIインフラ」を設計できる人材への需要が急増している

クラウドエンジニア vs SRE・DevOps・インフラエンジニア——違いを正しく理解する

クラウドエンジニアの採用で最初につまずくのが、「SRE・DevOps・インフラエンジニアと何が違うのか」という定義の曖昧さです。採用要件がぼやけると、候補者にも伝わりません。

まずは各職種の主な責務の違いを整理します。

クラウドエンジニア

クラウド基盤全体のアーキテクチャ設計・構築・最適化が主務
AWS・Azure・GCPなど特定クラウドの深い知識が必須
コスト最適化、マルチクラウド戦略、クラウドマイグレーションを担当
IaC（Terraform、CloudFormation、Pulumiなど）による基盤のコード化が中心スキル

SRE（Site Reliability Engineer）

サービスの信頼性・可用性の維持が主務
SLI/SLO設計、障害対応、ポストモーテム運用がコア業務
オンコール対応やインシデントマネジメントの仕組みづくりを担当

DevOpsエンジニア

開発と運用の橋渡し、CI/CDパイプラインの構築・改善が主務
デプロイの自動化、開発者体験の向上がコア業務
ツールチェーンの選定・導入を通じて開発サイクルを高速化

インフラエンジニア

サーバー、ネットワーク、ストレージなどインフラ全般の設計・運用が主務
オンプレミスとクラウドの両方を扱うケースが多い
物理層からOS・ミドルウェアまで幅広い知識が求められる

実際の求人ではこれらの役割が重なることも多いですが、「自社が最も重視する責務は何か」を明確にしてから採用要件を定義することが、ミスマッチを防ぐ最大のポイントです。SREやインフラエンジニアの採用についてはSRE・インフラエンジニア採用の完全ガイド、DevOpsについてはDevOpsエンジニア採用ガイド、プラットフォームエンジニアについてはプラットフォームエンジニア採用ガイドもあわせてご覧ください。

「クラウドの設計ができる人」なのか「障害対応を主にやってほしい人」なのかで、採るべき人材像はまったく異なります。

クラウドエンジニア採用はなぜ難しいのか——5つの構造的要因

1. 経験者の絶対数が少ない

クラウドの本格普及はここ10年ほどの話です。設計・構築の実務経験を5年以上持つエンジニアの数は、市場のニーズに対して圧倒的に不足しています。特にマルチクラウド環境でのアーキテクチャ設計経験者は極めて希少です。

2. 技術の進化スピードが速く、スキルの陳腐化が起きやすい

AWSだけでも年間数千のアップデートがあり、新しいサービスが次々とリリースされます。1〜2年前の知識がすでに古くなっているケースも珍しくなく、「クラウド経験あり」の一言では候補者のスキルレベルを判断できません。

3. 年収水準が高く、採用競合が激しい

クラウドエンジニアの市場年収は上昇傾向にあります。一般的にミドルクラスで550〜750万円、シニアクラスで800〜1,200万円、アーキテクトレベルで1,000〜1,500万円が相場観です（エンジニア全体の年収データはエンジニア年収相場2026を参照）。外資系企業やメガベンチャーとの採用競合が常態化しており、スタートアップが正面勝負で勝つのは難しい状況です。

4. 資格と実力が必ずしも一致しない

AWS認定ソリューションアーキテクト（SAA/SAP）やGCP Professional Cloud Architectなどの資格保持者は増えていますが、資格を持っていても設計の実務経験が浅いケースは少なくありません。逆に、資格を持たなくても優れた設計力を持つエンジニアもいます。

5. クラウドベンダーの違いによるスキルの互換性問題

AWSに精通していてもAzureやGCPの経験がないエンジニアは多く、その逆もまた然りです。自社の技術スタックと候補者のクラウドベンダー経験が一致しないケースが頻発し、候補者プールがさらに狭まります。

クラウドエンジニアの要件定義——スキルマトリクスの設計方法

要件定義が曖昧だと、スカウトの的が定まらず、選考でも判断基準がぶれます。以下のフレームワークで要件を整理しましょう。

ステップ1: 自社のクラウド利用状況を棚卸しする

まず、現在のクラウド環境を以下の観点で整理します。

利用クラウド: AWS / Azure / GCP / マルチクラウド
利用規模: 月額利用料、アカウント数、リージョン数
アーキテクチャ: モノリス / マイクロサービス / サーバーレス
IaCの導入状況: Terraform / CloudFormation / CDK / Pulumi / 未導入
コンテナ利用: ECS / EKS / GKE / AKS / 未利用
セキュリティ要件: SOC2 / ISO27001 / PCI DSS / HIPAA など

ステップ2: 「何を任せたいか」を具体的に定義する

クラウドエンジニアに任せたい業務は企業によって異なります。次の4パターンから自社の優先度を明確にします。

パターンA: クラウドマイグレーション — オンプレからの移行設計と実行（リフト&シフト〜リアーキテクト）
パターンB: クラウドアーキテクチャ設計 — 新規サービスの可用性・拡張性・セキュリティを両立する構成設計
パターンC: クラウドコスト最適化 — 既存環境のコスト分析・削減、リザーブド/Savings Plans戦略
パターンD: AI/MLインフラ構築 — GPUクラスタ・推論基盤・MLOpsパイプラインの設計運用

ステップ3: スキルマトリクスを作成する

以下のマトリクスをベースに、自社の要件に合わせてカスタマイズします。

必須スキル（Must）

主要クラウド（AWS / Azure / GCP）いずれかでの設計・構築経験3年以上
IaCツール（Terraform推奨）による基盤のコード化経験
ネットワーク設計（VPC、サブネット、セキュリティグループ、ロードバランサー）の実務経験
Linux/Unixの基本操作とトラブルシューティング能力

歓迎スキル（Want）

マルチクラウド環境での設計・運用経験
コンテナオーケストレーション（Kubernetes / ECS）の運用経験
CI/CDパイプラインの構築経験
クラウドセキュリティの設計経験（IAM設計、暗号化、監査ログ設計）
コスト最適化プロジェクトの経験
クラウド関連資格（AWS SAP、GCP PCA、Azure Solutions Architect Expert）

求める人物像

「なぜこの構成にするのか」をビジネス要件から説明できる
コスト意識を持ち、過剰設計を避けられる
新しいサービスやアーキテクチャパターンを継続的にキャッチアップしている
開発チームやビジネスサイドと円滑にコミュニケーションが取れる

求人票の書き方——クラウドエンジニアが応募したくなる要素

クラウドエンジニアは市場価値が高く、求人を選ぶ側です。「他の求人と何が違うのか」が一目でわかる求人票を書くことが重要です。求人票の基本的な書き方についてはエンジニアが応募したくなる求人票の書き方完全ガイドも参考にしてください。

求人票に書くべき5つの要素

クラウドエンジニアの求人票で候補者に刺さる要素は、次の5つです。

クラウド環境の規模感と技術的な面白さ — 月額利用料・サービス数・トラフィック規模を具体的に開示する
技術スタックの全体像 — クラウドサービスに加えIaC・CI/CD・監視・セキュリティツールまで記載する
アーキテクチャ設計への関与度 — 「運用だけ」か「設計から任せる」かを明記する
チーム構成と自分の立ち位置 — 一人目か増員か、開発チームとの関わり方を書く
キャリアパスと成長環境 — 資格支援・カンファレンス補助・検証環境の有無を示す

以下、それぞれを詳しく解説します。

1. クラウド環境の規模感と技術的な面白さ

「AWS利用」だけでは伝わりません。月額利用料の規模感・利用サービス数・マルチアカウント構成の有無・トラフィック規模など、候補者が「この環境で働いてみたい」と思える具体情報を開示します。「AWSでインフラの設計・構築・運用をお任せします」ではなく、「月間1億リクエストを処理するAWS環境（月額利用料: 数千万円規模）で、ECS Fargate + Aurora + ElastiCache 構成の進化をリードしていただきます」のように書きましょう。

2. 技術スタックの全体像

クラウドサービスだけでなく、IaCツール、CI/CDパイプライン、監視ツール、セキュリティツールなど、関連する技術スタック全体を記載します。

3. アーキテクチャ設計への関与度

「運用だけ」なのか「設計から任せてもらえる」のかは、クラウドエンジニアにとって最大の関心事の一つです。設計の裁量がどれだけあるかを明記しましょう。

4. チーム構成と自分の立ち位置

クラウドチームの人数、チーム内での役割、開発チームとの関わり方を具体的に書きます。「一人目のクラウドエンジニア」なのか「既存チームの増員」なのかで、候補者の判断は大きく変わります。

5. キャリアパスと成長環境

クラウド資格の取得支援、カンファレンス参加費の補助、技術検証に使えるサンドボックス環境の有無など、学習・成長の機会を具体的に示します。

スカウト文面の書き方——クラウドエンジニアの返信率を高めるコツ

クラウドエンジニアへのスカウトで陥りがちなのが、「AWS経験がある方を探しています」のような汎用的なメッセージです。返信率を上げるには、候補者の経験と自社の課題を具体的に結びつける必要があります。スカウトメールの基本はエンジニア向けスカウトメールの書き方と返信率を上げる例文集で詳しく解説しています。

スカウト返信率を上げる3つのポイント

クラウドエンジニアのスカウト返信率を上げるコツは、次の3点に集約されます。

候補者のクラウド経験に具体的に言及する — プロフィールや技術ブログから関わったプロジェクトや資格を読み取り、注目した点を伝える
自社のクラウド課題をオープンに伝える — きれいな話よりリアルな技術課題のほうが響く
設計の裁量と技術選定への関与を明示する — シニア層ほど設計裁量を重視する

1. 候補者のクラウド経験に具体的に言及する

プロフィールや技術ブログから、候補者が関わったクラウドプロジェクトや保有資格を読み取り、「あなたの○○の経験に注目しました」と伝えます。

2. 自社のクラウド課題をオープンに伝える

「現在のアーキテクチャにこういう課題があり、ここを一緒に改善したい」と正直に伝えることで、技術的な興味を引き出せます。クラウドエンジニアは「課題解決」にモチベーションを感じる人が多いため、きれいな話よりもリアルな課題のほうが響きます。

3. 設計の裁量と技術選定への関与を明示する

「既存の設計に従ってもらう」のか「ゼロから設計をリードしてもらう」のかを明確にします。特にシニアクラスの候補者は、設計の裁量を重視する傾向が強いです。

スカウト文面のテンプレート（カスタマイズ前提）

クラウドエンジニアが見つかりやすいチャネル

LAPRAS / Findy: 技術力スコアでフィルタリングしやすい
LinkedIn: 外資系クラウド経験者が多く登録
BizReach: マネージャークラス以上のクラウドアーキテクトが見つかりやすい
転職ドラフト: 年収レンジが明示される仕組みでミスマッチが起きにくい
JAWS-UG / Google Cloud User Group: AWSやGCPのコミュニティイベントに参加して直接声をかける
技術ブログ・Qiita・Zenn: クラウド関連の記事を書いているエンジニアに個別アプローチ

年収レンジと報酬設計——クラウドエンジニアの相場観

クラウドエンジニアの採用で年収設定を間違えると、応募が来ないか、採用後すぐに転職されるリスクがあります。市場相場を正しく把握した上で、自社の報酬設計を行いましょう。

2026年のクラウドエンジニア年収相場（目安）

レベル	経験	年収目安	主な役割
ジュニア	1〜3年	400〜550万円	運用・監視が中心、設計はレビュー付き
ミドル	3〜5年	550〜800万円	中規模環境を独力で設計・構築、IaC・コスト最適化を主導
シニア	5〜8年	800〜1,200万円	大規模・マルチアカウント設計とセキュリティ対応をリード
アーキテクト/リード	8年以上	1,000〜1,500万円	全社クラウド戦略の策定、経営層へのROI説明

年収以外の報酬設計ポイント

クラウドエンジニアは年収だけで企業を選びません。次の要素を組み合わせれば、年収水準で劣る場合でも採用競争力を高められます（報酬パッケージ全体は報酬設計と年収戦略の完全ガイドを参照）。

クラウド資格の取得費用全額補助（受験料に加え学習教材・模擬試験も）
技術カンファレンス参加支援（re:Invent・Google Cloud Next・Azure Summit の参加費・渡航費）
サンドボックス環境の提供（業務外でも触れる検証アカウント）
リモートワーク・フレックス（場所を選ばない職種ゆえ柔軟な働き方への期待が高い）
ストックオプション / RSU（スタートアップでは将来の報酬可能性で年収差を埋められる）

選考プロセスの設計——クラウドエンジニアの実力を見極める方法

クラウドエンジニアの選考では、「資格の有無」や「経験年数」だけでは実力を判断できません。設計力・運用力・ビジネス理解力の3つの軸で評価する選考プロセスを設計しましょう。

推奨する選考フロー

Step 1: 書類選考（目安: 2〜3営業日）

レジュメから以下をチェックします。

主要クラウド（AWS / Azure / GCP）での実務経験年数
設計・構築・運用のどのフェーズを中心に経験しているか
IaCの利用経験（ツール名と適用範囲）
扱ったシステムの規模感（トラフィック、月額利用料、アカウント数など）

Step 2: カジュアル面談（30〜45分）

選考要素を入れず、お互いの情報交換を行います。

自社のクラウド環境の現状と課題をオープンに共有
候補者がこれまで手がけたプロジェクトの詳細をヒアリング
技術的な興味の方向性とキャリアの志向を確認

Step 3: 技術面接（60〜90分）

クラウドエンジニアの実力を見極める技術面接では、以下の3つの軸で質問を組み立てます。

軸1: アーキテクチャ設計力 — 「月間1,000万PVのWebサービスをAWSで設計してください」のようなシステムデザイン問題で、設計の順序・可用性/拡張性/コストのトレードオフ・「なぜその構成か」の引き出しの多さを評価
軸2: 運用・トラブルシューティング力 — 「本番でレイテンシが急増したらどこから調査しますか」の障害対応シナリオ、CloudWatch/Datadog等の監視ツール活用経験、過去の障害対応エピソードを確認
軸3: セキュリティ・コスト意識 — IAM設計のベストプラクティス、「月額利用料が前月比30%増えたらどう分析するか」、インシデント対応フローを確認

技術面接で使える質問例

設計力: 「関わっているシステムのアーキテクチャ図を描き、設計意図と改善したい点を教えてください」「サーバーレスとコンテナベース、それぞれどんなケースで採用しますか」
運用力: 「Terraformのstate分割の考え方を教えてください」「本番デプロイで問題が発生した場合のロールバック手順は」
セキュリティ・コスト: 「AWSアカウントのセキュリティ設計で最初にやるべきことを3つ挙げてください」「最小権限の原則をIAM設計にどう適用していますか」

Step 4: ワークサンプルテスト（任意、持ち帰り課題）

実務に近い課題（例: 「Webアプリ〈ECS Fargate〉+ Aurora + CloudFront + WAF のAWS構成をTerraformで記述、制限時間3時間」）で設計力を評価します。評価ポイントはモジュール分割の考え方・変数設計・セキュリティ設計です。

Step 5: オファー面談（30〜45分）

条件提示だけでなく、入社後3ヶ月・6ヶ月・1年で期待する成果、チーム内での立ち位置と裁量の範囲、報酬パッケージとクラウド資格支援制度を具体的に伝えます。

候補者の探し方——クラウドエンジニアが集まる場所

クラウドエンジニアは技術コミュニティへの帰属意識が強いため、コミュニティ・副業・隣接職種の3ルートを組み合わせて母集団を広げるのが有効です。

コミュニティ経由の接点づくり: JAWS-UG（AWS User Group Japan）、Google Cloud User Group、CloudNative Days、Platform Engineering Meetup などに自社エンジニアを送り込み、登壇・発表で接点を作る
副業・業務委託からのトライハイヤー: まず週2〜3日の業務委託（月額単価60〜100万円程度）でアーキテクチャレビューやIaC導入支援から関わってもらい、3〜6ヶ月で正社員オファーを検討するトライハイヤーアプローチ
隣接職種からのコンバート採用: インフラエンジニア（ネットワーク基礎あり）・SRE（運用即戦力）・バックエンドエンジニア（アーキ理解あり）から育成。入社後の学習ロードマップと資格支援の用意が前提

口説き方——クラウドエンジニアが入社を決めるポイント

クラウドエンジニアが転職先を決める際に重視するポイントを理解し、オファー時に適切な訴求を行いましょう。

クラウドエンジニアが入社を決める5つのポイント

クラウドエンジニアが転職先を決める際に重視するのは、次の5点です。

設計の裁量があるか — アーキテクチャの設計・改善を任せる裁量の大きさ
クラウド環境の規模と技術的なチャレンジ — 大規模・高トラフィック・マルチアカウント環境ほど魅力的
最新技術を触れる環境 — Terraform移行やCDK導入など技術刷新への前向きさ
リモートワーク・柔軟な働き方 — 出社強制は候補者プールを狭める
チームの技術レベル — 一緒に働くメンバーの技術力と議論の文化

1. 設計の裁量があるか

既存の設計をそのまま運用するだけのポジションは敬遠されがちです。「アーキテクチャの設計・改善を任せる」「技術選定に関与できる」という裁量の大きさを具体的に伝えましょう。

2. クラウド環境の規模と技術的なチャレンジ

小規模な環境よりも、大規模・高トラフィック・マルチアカウント・マルチリージョンといった技術的にチャレンジングな環境のほうが、クラウドエンジニアの成長意欲を刺激します。

3. 最新技術を触れる環境

「うちはまだCloudFormationだけ」よりも「Terraformへの移行を検討中」「CDKの導入を進めている」のように、技術の刷新に前向きな姿勢を見せましょう。

4. リモートワーク・柔軟な働き方

クラウドエンジニアの業務はリモートワークとの親和性が高いです。出社を強制するとそれだけで候補者プールが狭まります。

5. チームの技術レベル

一緒に働くメンバーの技術力は、クラウドエンジニアにとって大きな判断材料です。チーム内にどんなスキルセットのメンバーがいるか、技術的なディスカッションの文化があるかを伝えましょう。

カウンターオファー対策

内定後に現職からカウンターオファー（引き留め）が入るケースは珍しくありません。年収だけの勝負に持ち込まず設計裁量・技術的チャレンジ・キャリアパスなど複数の訴求点を用意し、意思決定に必要な情報は選考中に出し切り、オファー後は1週間以内の回答を目安にして他社に取られるリスクを下げます。

入社後の定着施策——クラウドエンジニアが長く活躍する環境づくり

採用して終わりではありません。クラウドエンジニアの定着率を高め、長期的に活躍してもらうための環境整備が重要です。オンボーディングの基本設計についてはエンジニアのオンボーディング完全ガイドもあわせてご覧ください。

クラウドエンジニアの定着施策は、次の3段階で設計すると効果的です。

オンボーディング（初日〜3ヶ月）: 初週にアカウント権限付与・開発環境セットアップを完了（「1週間経っても環境が整わない」は最大の離職リスク）。1〜2週目に既存アーキテクチャの設計意図と過去の障害事例を共有し、1ヶ月目に小さなタスクで成果を出してもらう。3ヶ月目に期待値をすり合わせる
学習・成長機会の継続提供: 資格取得ロードマップの共同策定、週半日〜1日の技術検証時間の公式確保、社内勉強会・LT、技術ブログや登壇の業務時間内支援
エンゲージメント維持: 面接時に約束した設計裁量を守り、1on1で技術的満足度を定期確認し、「コスト○○%削減」「可用性○○%向上」といった定量成果を評価してフィードバックする

FAQ（よくある質問）

Q. クラウドエンジニアの採用にはどのくらいの期間がかかりますか？

ミドルクラスで3〜6ヶ月、シニアクラスで6ヶ月以上が一般的な目安です。クラウドエンジニアは売り手市場のため、「良い人がいたら採る」のスタンスではなく、常時採用活動を行う「通年採用」の体制を整えておくことをおすすめします。

Q. クラウドの資格はどの程度重視すべきですか？

資格は「最低限の知識があること」の証明としては有効ですが、資格＝実力ではありません。選考では資格の有無よりも、実際のプロジェクトでどのような設計判断を行ったかを重視してください。ただし、候補者のスカウト時にフィルタ条件として使う場合は有効です。

Q. AWS・Azure・GCPのどの経験者を優先すべきですか？

自社が利用しているクラウドの経験者を優先するのが基本です。ただし、一つのクラウドに深い経験がある人は、他のクラウドへのキャッチアップも早い傾向があります。自社のクラウドと完全一致しなくても、設計力が高ければ柔軟に対応できるケースが多いです。

Q. フリーランスのクラウドエンジニアを採用するのは有効ですか？

有効な選択肢です。特に「すぐにクラウドの課題を解決したいが、正社員のクラウドエンジニアを採用する余裕がない」という場合に適しています。まずはフリーランスに入ってもらい、並行して正社員の採用活動を進めるハイブリッドアプローチが現実的です。

Q. 未経験からクラウドエンジニアに育てることは可能ですか？

可能ですが、即戦力を求める場合には向いていません。インフラエンジニアやバックエンドエンジニアの基礎スキルがある人材であれば、クラウド資格の取得支援と実務経験を通じて1〜2年で一人前のクラウドエンジニアに育てることは現実的です。育成コストと時間を投資できるかどうかが判断基準になります。

Q. クラウドエンジニアの採用で、SRE・DevOpsとの兼務は可能ですか？

小規模な組織では兼務が一般的ですが、それぞれの役割の優先順位を明確にしておくことが重要です。「クラウド設計もSREもDevOpsも全部やってほしい」という求人は、候補者から敬遠される原因になります。「メインはクラウドアーキテクチャ設計、サブでSRE業務もお願いする場合があります」のように、比率を明示しましょう。