本文へ移動

インフラ転職コンパス現場・技術・キャリアをつなぐ専門メディア

メニュー

インフラエンジニア転職のポートフォリオ例|構成図・手順書・AWS検証の作り方

転職で成果を出すには、Webアプリ作品を無理に作らせず、構成図・手順書・検証ログ・障害対応記録などインフラ職に合う成果物を示す必要があります。一般論だけでなく、求人・採用側・現場業務の3視点で条件を分けて判断します。ただし、同じ職種名でも担当工程や会社によって中身は大きく変わります。この記事では、求人側の事情と現場の仕事内容を分けて、判断基準を具体化します。

この記事では、応募するか、学習を続けるか、求人条件を見直すかを具体的に決めるについて、求人票、実務の成果物、設定・確認結果のいずれかで判断できるところまで具体化します。

インフラエンジニア転職にポートフォリオは必要?

転職で成果を出すには、Webアプリ作品を無理に作らせず、構成図・手順書・検証ログ・障害対応記録などインフラ職に合う成果物を示す必要があります。一般論だけでなく、求人・採用側・現場業務の3視点で条件を分けて判断します。

ポートフォリオは成果物のつながりを見せる

最初に要件を書き、その要件を構成図、設定、試験へつなげます。例えば「管理端末からだけ接続できる」という要件なら、ネットワーク分離、許可ルール、正常・異常系試験が対応します。

完成画面だけでは、偶然動いたのか設計したのか分かりません。採用側が要件から試験結果まで追える構成にすると、判断過程が伝わります。

(出典:https://docs.github.com/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)

インフラ職で評価されやすい成果物

この論点は、制度名や製品名ではなく、実際の入力、判断、成果物、完了条件へ置き換えて確認します。

現場では、対象、変更前の正常値、実施内容、期待結果、異常時の停止条件をそろえてから作業します。転職記事でも同じように、求人票の文言を具体的な担当工程と成果物へ置き換えて判断します。

ネットワーク構成図の作成例

ルーター、L2・L3スイッチ、AP、端末をVLANと接続ポートまで記載したオンプレ検証構成図
オンプレ検証構成図の例。機器名だけでなく、VLAN、IPアドレス、接続ポート、access・trunkの役割まで対応させます。

この図を構成表、interface一覧、VLAN一覧、疎通試験表へ展開すると、設計意図から試験結果まで一続きの成果物になります。

この論点は、制度名や製品名ではなく、実際の入力、判断、成果物、完了条件へ置き換えて確認します。

現場では、対象、変更前の正常値、実施内容、期待結果、異常時の停止条件をそろえてから作業します。転職記事でも同じように、求人票の文言を具体的な担当工程と成果物へ置き換えて判断します。

Linuxサーバー構築・手順書の作成例

READMEに構成・手順・確認方法を書く

READMEには目的、対象読者、構成図、前提、構築手順、試験、既知の制約、削除手順を置きます。各ファイルへのリンクを付け、最初の数分で全体像を把握できるようにします。

手順はコマンドの羅列ではなく、実行前の状態、期待結果、失敗時の確認先を添えます。長い資料を全部読む前提にせず、要点から詳細へ進める構造にします。

AWS検証環境と設計書の作成例

2つのAvailability ZoneにALB、ECSまたはEC2、RDSを配置したAWS三層構成図
AWS検証構成図の例。VPC・subnetのCIDR、通信ポート、Security Group、Multi-AZ、IaC・監視の対応を示します。

構成図のCIDR、Security Group、route、Terraformコードが一致し、CloudWatchの監視結果まで提示できると、単なる画面キャプチャより再現性を説明できます。

この論点は、制度名や製品名ではなく、実際の入力、判断、成果物、完了条件へ置き換えて確認します。

現場では、対象、変更前の正常値、実施内容、期待結果、異常時の停止条件をそろえてから作業します。転職記事でも同じように、求人票の文言を具体的な担当工程と成果物へ置き換えて判断します。

GitHub・PDF・ブログでの見せ方

この論点は、制度名や製品名ではなく、実際の入力、判断、成果物、完了条件へ置き換えて確認します。

現場では、対象、変更前の正常値、実施内容、期待結果、異常時の停止条件をそろえてから作業します。転職記事でも同じように、求人票の文言を具体的な担当工程と成果物へ置き換えて判断します。

セキュリティ情報や料金で注意すべきこと

AWS検証はセキュリティと費用も成果物にする

VPC、EC2、IAMを作る場合、公開範囲、ログ、バックアップ、予算通知、タグ、削除まで記録します。アクセスキーや実在IP、顧客名をリポジトリへ入れないことは最低条件です。

設計案を一つだけ示すのではなく、可用性、コスト、運用負荷の比較を短く書くと、サービス選定の理由が伝わります。

(出典:https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html)

職務経歴書・面接への組み込み方

選考では、担当範囲、制約、自分の判断、使用した証跡、結果の順に話し、チーム成果と個人担当を分けます。

「障害対応を経験した」だけでは範囲が分かりません。「利用者影響を確認し、正常時ログと比較し、上位者へ三つの仮説を報告した」のように、判断と根拠を入れると質問されても説明できます。

実務で確認するポイントと判定基準

確認項目 現場での見方 判定基準
設計理由 作業名だけでなく、入力情報、確認手順、期待結果、異常時の報告先まで分けて確認する。 誰が・いつ・何を根拠に完了判定するか決められれば実務で使える。
テスト項目 作業名だけでなく、入力情報、確認手順、期待結果、異常時の報告先まで分けて確認する。 誰が・いつ・何を根拠に完了判定するか決められれば実務で使える。
障害切り分け 作業名だけでなく、入力情報、確認手順、期待結果、異常時の報告先まで分けて確認する。 誰が・いつ・何を根拠に完了判定するか決められれば実務で使える。
機密情報除去 作業名だけでなく、入力情報、確認手順、期待結果、異常時の報告先まで分けて確認する。 誰が・いつ・何を根拠に完了判定するか決められれば実務で使える。
AWS料金管理 資格名だけでなく、学習項目を構成図、設定、確認コマンド、試験結果へ変換する。 第三者が再現でき、失敗時の切り分けを説明できれば学習成果として使える。

評価されにくいポートフォリオの特徴

面接では失敗と改善を説明する

最初から正しく動いた話より、どこで失敗し、どのログから原因を特定し、再発防止をどう入れたかを話します。設定ミスを隠さず、検証環境で安全に学んだ過程を示します。

面接前に5分版と15分版の説明を用意します。5分版は要件、構成、難所、結果に絞り、詳細質問で試験や切り戻しを見せます。

ポートフォリオを完成させる6ステップ

  1. STEP 1:狙う求人と証明する技術を一つに絞る
    応募候補を5件ほど読み、頻出する担当工程と技術を拾います。READMEの冒頭に「どの求人の、何を証明する成果物か」を1文で書ければ完了です。
  2. STEP 2:IP・VLAN・接続ポートまで入れた構成図を作る
    機器名だけで終わらせず、interface、subnet、default gateway、access・trunkを記載します。構成図とparameter表の値に食い違いがないことを確認します。
  3. STEP 3:Linuxサーバーを手順書だけで再構築する
    新しいVMへOS設定、user・権限、service、firewall、log確認を順番に実施します。手順書だけを見て初期状態から再現できれば完了です。
  4. STEP 4:AWS環境を安全に作成・削除する
    VPC、public・private subnet、Security Group、監視を作り、秘密情報をrepositoryへ置かない構成にします。Terraformなどで再作成でき、不要resourceを削除できるところまで確認します。
  5. STEP 5:正常系と異常系の試験証跡を残す
    疎通成功だけでなく、routeやSecurity Groupを意図的に崩した症状、確認箇所、復旧結果も記録します。期待値と実測値を並べた試験表が完成条件です。
  6. STEP 6:第三者が3分で読める形に公開する
    GitHubのREADMEへ構成図、設計判断、手順、試験結果、制約、費用をまとめ、credentialや顧客情報を除去します。職務経歴書から成果物へ誘導し、面接で担当範囲を説明できれば完成です。

あわせて確認したい関連記事

インフラエンジニアが案件で考えること

案件の成果物は、構成図だけ、手順書だけでは完結しません。例えばACL変更なら、通信要件表の一行が設計値になり、設定差分になり、試験項目の正常系・異常系になります。ポートフォリオでも同じIDを要件、設定、試験で使うと、なぜその確認が必要なのか追跡できます。

証跡は成功画面を大量に貼るのではなく、判定に必要な出力を選びます。投入前の設定、投入差分、適用後の状態、疎通結果、ログの時刻をそろえます。問題が起きた場合は、仮説と確認順を障害メモへ残します。これは現場のレビューで説明しやすい形式です。

設計構築チャンネルのポリシーテスト解説では、通信要件をパケット単位で確認する実務を扱っています。ポートフォリオも「作ったもの」ではなく、「要件をどう試験したか」まで見せてください。

公開前には第三者レビューを想定し、環境固有値を伏せたことで手順が再現不能になっていないかも確認します。サンプル値、変数一覧、前提バージョンを分けると、秘密情報を守りながら設計意図を伝えられます。

(出典:https://www.youtube.com/watch?v=ar5ypVx_Bfs(ネットワークのポリシーテストと証跡))

インフラ向けポートフォリオのファイル構成
成果物 記載する内容 採用側が見られる力
README 目的・構成・リンク・制約 説明力と全体設計
design 構成図・要件・パラメータ 要件を設計へ落とす力
procedure 手順・確認・切り戻し 安全な変更
test 正常・異常系・証跡 品質確認と切り分け

要件、設定、試験を相互に追跡できるようにします。

(出典:https://findy-code.io/engineer-lab/techtensei-yuta)

(出典:https://linuc.org/textbooks/linux/)

まとめ|作ったものより設計意図と検証結果を説明する

インフラ向けポートフォリオは、要件、構成、手順、試験、切り戻しを一つの流れで示します。完成した環境より、判断と確認の過程が重要です。

READMEから全体をたどれるようにし、秘密情報、費用、削除まで管理してください。面接では失敗と改善を含めて説明すると、実務に近い準備が伝わります。

最近の記事
お知らせ