ポートフォリオは必須ではありませんが、実務経験が少ない人には有効です。構成図だけで終えず、設計理由、設定またはIaC、手順、正常・異常試験、運用・削除方法まで一式で示します。
クラウド転職でポートフォリオは必要？
クラウド転職でポートフォリオは必要？で先に決めるのは、動く画面より、要件、構成図、IaC、監視、費用、削除、障害対応を説明できる成果物にするという基準です。職種名が同じでも案件ごとに任される判断は変わります。 準備の土台は、Web三層等の小規模構成で、VPC、IAM、ログ、バックアップ、秘密情報を設計することです。現在一人で説明できる作業と、レビューがあれば担当できる作業を別々に書き出します。
(出典：https://docs.aws.amazon.com/ja_jp/)
評価される成果物には何が必要？
日常業務の裏には、公開リポジトリへ秘密情報を置かず、サンプル変数、費用上限、削除手順まで含むREADMEを作る場面があります。定型時だけでなく、条件が外れたときの権限と支援体制を確認します。
成果物として確認したいのは、クラウド構成図、Terraformコード、README、障害・削除手順です。作成者、レビュー者、更新契機を聞けば、自分がどこまで設計へ関われるか分かります。 レビュー指摘の理由を理解できる環境かどうかも、成長速度を左右します。
初級例：Web三層構成と監視では何を確認する？
例を作るときは、完成画面ではなく、要件、構成、設定、試験、運用を一式にします。Web構成ならVPC、Subnet、route、Security Group、load balancer、監視を対応付けます。
正常系に加え、経路、権限、監視を一つずつ崩し、症状、仮説、確認方法、復旧結果を残します。第三者が再作成できれば、学習内容を成果物として示せます。
READMEには各コンポーネントを選んだ理由、障害時の検知と切り戻し、月額費用の概算を追記し、構築後の運用判断まで示します。
(出典：https://developer.hashicorp.com/terraform/intro)
中級例：IaC・CI/CD・コンテナでは何を確認する？
構成図にはサービス名だけでなく、通信方向、CIDR、境界、冗長化、監視、外部接続を記載します。READMEでは要件、採用理由、代替案、構築・削除手順、費用上限を構成図と対応付けます。
設計判断は『AWSを使った』ではなく、『可用性と費用の条件から2 AZを選び、片系停止とSecurity Group誤設定を試験した』のように、制約、選択、結果で説明します。
本番へ入る前に、確認者と中止条件を決めます。特に構成をコピーして動かすだけでは、なぜその可用性・権限・監視にしたか答えられない点は、成功例だけでは見えない判断力を示します。 守秘義務があっても、固有名詞と実値を伏せれば判断過程は説明できます。
構成図・README・設計判断はどう書く？
「構成図・README・設計判断はどう書く」は、制度名や平均値ではなく、応募部署の直近実績、担当工程、作る成果物へ置き換えて確認します。
面接では期間と対象者をそろえて質問し、口頭回答、公開情報、労働条件通知書に差があれば、解消するまで要確認として残します。
(出典：https://cloud.google.com/architecture/framework?hl=ja)
セキュリティ・コスト・秘密情報では何に注意する？
きつい、失敗したと感じやすいのは、夜勤や障害対応そのものより、担当工程、勤務回数、支援体制、次工程へ進む条件が入社前の説明と違う場合です。
求人票、面接回答、労働条件通知書を同じ表で照合し、夜間作業の回数、担当工程の割合、レビュー担当、異動・案件変更の実例が確認できなければ『要確認』とします。
避けたいのは、構成をコピーして動かすだけでは、なぜその可用性・権限・監視にしたか答えられない求人です。分からない項目は面接後も未確認として残し、他社と同じ基準で比べます。
- 構成図：構成図には機器・service名だけでなく、IP・CIDR、通信方向、冗長化、境界、接続先を記載します。
- README：READMEには目的、構成、前提、入力、実行・削除手順、確認方法、費用、注意点を記載します。
- IAM：IAMは、Terraformや運用担当者が実行できるAPIを最小限へ絞り、Role・Policy・認証方式を成果物として示します。
- VPC：VPCでは、CIDR、subnet、route、Internet・private接続、Security Group、DNSの関係を構成図で示します。
- 監視：監視ではalertを受けるだけでなく、閾値、正常値、一次切り分け、連絡条件、rule改善を確認します。
- バックアップ：バックアップは取得成功だけでなく、保存先、世代、暗号化、復元手順、復元試験の結果まで確認します。
- Terraform：Terraformでは、HCL、remote State、planレビュー、apply権限、失敗時の復旧を一連の運用として説明します。
- Git：Gitでは変更理由、差分、review、承認、branch保護、戻すcommitを追える状態にします。
面接でポートフォリオを説明するには？
面接でポートフォリオを説明する方法の答えは、動く画面より、要件、構成図、IaC、監視、費用、削除、障害対応を説明できる成果物にすることです。クラウドエンジニア 転職 ポートフォリオという名称だけでは勤務条件と責任範囲まで判断できません。
求人を三件以上並べ、担当工程、作る資料、障害時の役割を比較してください。共通項目が応募前の準備になり、相違点が会社選びの質問になります。
作った物より判断理由をどう示す？
結論として、動く画面より、要件、構成図、IaC、監視、費用、削除、障害対応を説明できる成果物にすることが確認が欠かせません。まずWeb三層等の小規模構成で、VPC、IAM、ログ、バックアップ、秘密情報を設計する状態を作り、応募先で任される判断と照合します。
求人票だけで判断せず、構成をコピーして動かすだけでは、なぜその可用性・権限・監視にしたか答えられない点を質問します。次の成果物をクラウド構成図に置き、Terraform、CI/CD、コンテナを追加し、変更レビューとロールバックを示す経験を積める転職先を選びましょう。
次にあわせて読むべき記事は？
- インフラエンジニア転職のポートフォリオ例｜構成図・手順書・AWS検証の作り方
- クラウドエンジニア転職ロードマップ｜未経験・経験者別の学習順
- Terraform経験はインフラエンジニア転職で有利？IaCスキルの示し方
ポートフォリオの悪い例・改善例・完成例
| 種類 | 掲載内容 | 採用側が確認できること |
|---|---|---|
| 悪い例 | AWSでVPCとEC2を作成した | 設計理由、再現方法、運用・削除方法が分からない |
| 改善例 | TerraformでVPC、Public/Private Subnet、ALB、EC2を再作成し、plan差分と疎通試験を保存した | 構成、IaC、試験の関係が分かる |
| 完成例 | 構成図、README、Terraform、正常・異常試験、監視、削除手順を同じリポジトリで公開 | 第三者が再現でき、費用停止まで確認できる |
インフラエンジニアが案件で考えること
公開リポジトリへ秘密情報を置かず、サンプル変数、費用上限、削除手順まで含むREADMEを作る場面では、技術だけで結論を出せません。作業可能時間、失敗時の影響、復旧に必要な情報、関係者の承認をそろえて初めて変更へ進めます。確認できない項目は設計課題として残し、本番当日の判断に持ち込まないようにします。
準備する成果物はクラウド構成図、Terraformコード、README、障害・削除手順です。作成しただけでは足りず、入力元と更新契機を明確にします。構成をコピーして動かすだけでは、なぜその可用性・権限・監視にしたか答えられない場合ほど、設計値、設定値、試験項目を相互に参照できる形にし、見落としをレビューで検知します。
金融系やオフィス系の変更では、影響を小さく分け、戻せる境界を明確にして本番へ進みます。対象技術が異なっても、この品質管理は変わりません。面接ではデモより先に要件、代替案、失敗、改善点を5分で説明することで、検証と切り戻しが実際に機能するチームかを見ます。
(出典：https://www.youtube.com/watch?v=jfn2KzYorS8（設計構築チャンネル：検証環境がない案件と切り戻し）)
| 成果物 | 結び付ける知識 | 転職で示す証拠 |
|---|---|---|
| クラウド構成図 | 構成図 | 設計理由と代替案 |
| Terraformコード | README | 変更前後の差分 |
| README | IAM | 試験結果と証跡 |
| 障害・削除手順 | VPC | 改善前後とレビュー |
製品名ではなく、判断した内容とレビュー可能な成果物で経験を説明します。
まとめ
次に、候補求人を3件並べ、クラウド転職でポートフォリオは必要、評価される成果物の構成要素、初級例：Web三層構成と監視と面接で残った未確認事項を同じ表で比較してください。
