ポートフォリオが必要な理由
※本記事はプロモーションを含みます。
「ポートフォリオはアプリ開発者だけのもの」——そう考えているインフラエンジニアやネットワークエンジニアは少なくないとされています。しかし実際の転職市場では、ポートフォリオを持つインフラエンジニアは、そうでないエンジニアに比べて書類通過率が高まる可能性があります。Infrastructure as Codeや技術ブログを通じて実績を可視化することで、採用担当者への訴求力は大きく変わるとされています。
本記事では、インフラ・ネットワーク系エンジニアが自分のスキルをどのように可視化し、転職・キャリアアップに活かすかを、具体的な実例と4週間の行動スケジュールを交えて解説します。
読了目安：約25分
ポートフォリオが必要な理由
採用担当者が見るもの
転職活動において採用担当者が確認したいのは「職務経歴書に書かれた経歴が本当か」「実際のスキルレベルはどの程度か」という2点とされています。特にインフラエンジニアの場合、資格や職務経歴書だけでは「本当に構築経験があるのか」「運用の深さはどのレベルか」が判断しづらいとされています。
GitHubに公開されたコード、技術ブログの記事、構成図などを通じて「このエンジニアは実際に何ができるのか」を具体的に示すことができます。採用担当者やCTO、エンジニアリングマネージャーは、職務経歴書に加えて「実装の品質」「説明の丁寧さ」「継続的な学習姿勢」を評価するとされています。
また、Zennやブログでの技術記事発信は「わかりやすく説明できる能力」を示す材料にもなるとされています。複雑なシステム構成を正確に言語化し他者に伝えられるエンジニアは、プロジェクトリーダーやアーキテクトとしても評価されやすい傾向があるとされています。
インフラ系特有の壁
インフラエンジニアのポートフォリオ作成には、アプリケーション開発者とは異なる固有の課題があります。アプリ開発者は完成したアプリケーションをそのまま公開することで動作する成果物を示せますが、インフラエンジニアが構築した環境は本番環境そのものであり、セキュリティ上の理由から直接公開することはできません。
この制約を乗り越えるために有効な方法が「Infrastructure as Code（IaC）」です。構築経験をTerraformやAnsibleといったツールでコード化しGitHubに公開することで、実際の構築能力を示すことができるとされています。コードに加えて構成図とREADMEを整備することで、採用担当者は「このエンジニアが何をどのように構築したか」を具体的に把握できるとされています。
つまり、インフラエンジニアのポートフォリオは「どのような環境を構築したか」を文書化・コード化・図解化して初めて成立するとされています。この3点セットを意識することが、効果的なポートフォリオ作成の第一歩とされています。
転職市場の現状
クラウドインフラ・DevOpsエンジニアの需要は継続的に高まっているとされています。AWS・GCP・Azureのいずれかのクラウド経験とIaCツールを組み合わせたスキルセットを持つエンジニアは、特に市場価値が高いとされています。
求人票に記載される「必須スキル」として、TerraformやAnsibleなどのIaCツール経験を求めるケースが増加しているとされています。ポートフォリオでIaCコードを公開することは求人要件を満たすことの「証拠」にもなり得るとされています。未経験分野へのキャリアチェンジを検討している場合も、学習中の環境をIaCで構築して公開することで「実際に手を動かした証拠」を示せるとされています。
実例で学ぶ活用法
GitHubの活用事例
最も評価されやすいポートフォリオのひとつが「GitHubにIaCコードを公開する」方法です。以下にインフラエンジニアに特に有効な構成例を示します。
AWS 3層アーキテクチャ
VPC・EC2・RDS・ALBを組み合わせた3層アーキテクチャをTerraformで実装した事例は、採用現場での評価が高いとされています。READMEには以下の要素を含めることで訴求力が大きく高まるとされています。
- アーキテクチャ選定の理由（なぜECSではなくEC2を選んだか等）
- セキュリティグループの設計思想（最小権限の原則に基づく設定）
- マルチAZ構成の必要性と実装方法
- コスト見積もりと最適化のポイント（Reserved Instance活用等）
- スケーリング戦略（Auto Scaling Groupの設定と閾値の考え方）
- 監視・ロギング設定（CloudWatch・CloudTrailとの連携）
Kubernetes環境構築
コンテナ基盤の経験を示す場合は、EKSやGKEのクラスター構築をTerraformで実装し、HelmChartでアプリケーションをデプロイする構成が有効とされています。PrometheusとGrafanaによる監視環境も含めることで「SRE的な視点」をアピールできるとされています。
| テーマ | 使用ツール | 難易度 | 訴求対象 |
|---|---|---|---|
| AWS 3層アーキテクチャ | Terraform / EC2 / RDS | 初〜中 | クラウドインフラ全般 |
| EKSクラスター構築 | Terraform / Helm / Prometheus | 中〜上 | SRE / DevOps職種 |
| CI/CDパイプライン | GitHub Actions / CodePipeline | 中 | DevOps全般 |
| NWシミュレーション | GNS3 / Ansible | 中 | NW系転職・CCNP学習 |
Zenn・ブログの活用
技術記事の発信は、GitHubのコード公開と並ぶ重要なポートフォリオ要素とされています。Zennは日本のエンジニア向け技術共有プラットフォームであり、Google検索でのSEO効果が高いとされています。
記事を書く際のポイントは「読者が実際に困っている課題を解決する内容にする」ことです。以下は特に読まれやすいテーマの例です。
- 「AWS VPCでよくある設計ミスとその対策5選」
- 「TerraformのstateファイルをS3とDynamoDBで管理する方法」
- 「オンプレからAWSへの移行時に直面した5つの壁と解決策」
- 「CCNP取得後に実感したネットワーク設計力の変化」
- 「KubernetesのPodが再起動し続ける原因の切り分け手順」
- 「セキュリティグループとNACLの違いを構成図で徹底解説」
これらのテーマは「タイトルに具体的な技術用語や数字を含む」という共通点があります。技術系の検索クエリは非常にロングテールであり、具体的なキーワードを含む記事ほどピンポイントで読者に届きやすいとされています。
また記事を書くプロセス自体が「自分の理解の整理」にもなるとされています。曖昧だった知識が記事を書く過程で明確になり、読者からのコメントを通じてさらに理解が深まるという経験は多くのエンジニアが報告しているとされています。
構成図の作成法
インフラエンジニアのポートフォリオで「構成図のわかりやすさ」は重要な評価ポイントとされています。インフラエンジニアは必ず「経営層や他部門に技術内容を説明する」場面に直面するため、図解スキルが実務評価にも影響するとされています。
| ツール | 特徴 | 費用 | 難易度 |
|---|---|---|---|
| draw.io | AWS/Azure/GCPアイコン充実。ブラウザ・デスクトップ両対応 | 無料 | 低 |
| Mermaid | コードで図を生成。GitHubに直接埋め込み可能 | 無料 | 中 |
| Lucidchart | 高度な図作成。チーム共同編集に強い | 有料 | 中 |
| Excalidraw | 手書き風のシンプルな図。軽快で使いやすい | 無料 | 低 |
特にdraw.ioは無料で利用でき、AWSの公式アイコンセットが組み込まれているため、ポートフォリオ作成の最初のツールとして最適とされています。GitHubのREADMEにPNG形式で埋め込むことで、コードを読む前に全体像を把握できるポートフォリオが完成します。
4週間で作る手順
第1週：GitHub整備
まず第1週でGitHubアカウントを整備します。採用担当者がプロフィールを確認した際の第一印象を整えることが目的です。
- プロフィール画像：専門家としての一貫したイメージを持たせるため、仕事用の写真かプロフェッショナルなアバターを設定する
- 自己紹介欄：「CCNP保有・AWS構築経験5年・Terraform活用中」など、簡潔にスキルを記載する
- プロフィールREADME：GitHubのユーザー名と同じリポジトリを作成し、スキルバッジ・経歴・学習中の技術を記載する
- ピン留めリポジトリ：将来公開予定のポートフォリオリポジトリを6つまでピン留めできるため、計画的に準備する
- 外部リンク：ZennやQiitaのプロフィールへのリンクを記載し、横断的な実績を参照できるようにする
プロフィールREADMEにはshields.ioなどのバッジサービスを利用してスキルバッジを掲載することで、視覚的なインパクトを高めることができるとされています。
第2週：コードの公開
過去の構築経験から「最も説明しやすいもの」を1つ選び、Terraformコードとして実装します。重要な注意点は「本番環境のコードをそのままコピーしない」ことです。理由は2点あります。第1に、セキュリティ情報（IPアドレス・ドメイン名・認証情報など）が含まれる可能性があること。第2に、実際の本番環境は「その会社の資産」であり、外部公開は契約上問題になる可能性があることです。
そのため「同じ構成を再現した教育用の環境」として新規で実装することが推奨されるとされています。ディレクトリ構成は以下を参考にするとよいとされています。
- main.tf：VPC・EC2・RDS・ALBなどのリソース定義
- variables.tf：変数定義とデフォルト値（機密情報は変数化して外部管理）
- outputs.tf：出力値（ALBのDNS名など、確認に必要な情報）
- README.md：全体構成・前提条件・実行手順（terraform init〜applyまでの流れ）
- architecture.png：draw.ioで作成した構成図
第3週：記事の執筆
第2週で作成したコードの「設計思想」を説明するZenn記事を執筆します。記事の構成として以下が有効とされています。
- 課題の定義：「なぜこのアーキテクチャが必要か」を背景から説明
- 設計の方針：選択した構成の理由と採用しなかった選択肢との比較
- 実装の詳細：Terraformコードの主要部分の解説（ポイントをコードブロックで示す）
- 動作確認：実際に試した通信確認・パフォーマンス測定の方法
- 改善点・次のステップ：現状の課題と今後取り組みたい改善内容
特に「採用しなかった選択肢との比較」を含めると、技術選定の判断力をアピールできるとされています。例えば「ECSではなくEC2を選んだ理由：今回のユースケースでは常時稼働が必要で〜」という形式で説明することで、設計プロセスの深さが伝わるとされています。
第4週：仕上げと公開
draw.ioで構成図を作成し、GitHubのREADMEとZennの記事に埋め込みます。構成図に含めるべき主要要素は以下の通りです。
- VPC・サブネット（パブリック・プライベート）の境界線
- セキュリティグループの適用範囲（色分けで表示）
- 各コンポーネント間の通信フロー（矢印で方向を明示）
- インターネットゲートウェイ・NATゲートウェイの位置関係
- データ永続化コンポーネント（RDS・S3）とバックアップ設定
図が完成したらREADME全体を見直します。「実際にこのリポジトリをCloneして試せるか」を確認し、再現性を確保することが重要とされています。再現できないポートフォリオは採用担当者に「本当に動くのか」という疑問を持たせる可能性があるためです。
採用に刺さる工夫
READMEの書き方
GitHubリポジトリのREADMEは、ポートフォリオの「第一印象」を決める重要な要素です。採用担当者が最初に見るのはコードではなくREADMEとされています。効果的なREADMEには以下の要素が含まれるべきとされています。
- プロジェクト概要（50〜100字）：何を実装したか、なぜそれが価値があるのか
- 技術スタック：使用したAWSサービス・ツール・バージョンの一覧
- アーキテクチャ図：PNG画像でREADMEに直接埋め込み
- 前提条件：AWSアカウント・IAMポリシー・Terraformバージョン要件など
- 実行手順：クローン→変数設定→init→plan→applyの流れをコマンド付きで記載
- コスト見積もり：このアーキテクチャを実装した場合のAWS費用目安
- 改善・拡張の可能性：今後どのように発展させられるか
- 参考資料：AWS公式ドキュメントや参考にした記事へのリンク
特に「前提条件」と「実行手順」を丁寧に書くことで「再現性の高いポートフォリオ」という印象を与えることができるとされています。逆にこれらが省略されている場合、採用担当者は「自分しか使えないコード」と判断する可能性があるとされています。
継続更新の重要性
ポートフォリオの「最終更新日」は採用担当者が必ず確認する項目のひとつとされています。最終更新が1年以上前のリポジトリは「このエンジニアは現在もこの技術を使っているのか」「最新のベストプラクティスを把握しているのか」という疑問を持たれる可能性があるためです。
更新が難しい場合でも、以下の軽量な更新方法が有効とされています。
- TerraformやAnsibleのバージョン更新（変更ログをコミットメッセージに記録）
- 最新のAWSベストプラクティスに合わせたセキュリティグループの調整
- READMEへの新しい参考リンクや説明の追加
- 新しい学習内容をブログ記事として発信し、リポジトリからリンクを追加
Gitのコミット履歴が「更新されている」という事実そのものが、採用現場での信頼獲得に大きく貢献するとされています。毎月のタスクとして「GitHubのポートフォリオリポジトリを1件確認・更新する」習慣を持つことが長期的なポートフォリオ維持に有効とされています。
よくある失敗と対策
ポートフォリオ作成で陥りやすい典型的な失敗例と対策を以下に整理します。
- 失敗1：ツール選びに時間を使いすぎる
「どのブログプラットフォームが最も検索に強いか」「どのIaCツールが業界標準か」といった判断に迷い、結果的にポートフォリオを公開しないままになるケースがあるとされています。対策としては「GitHub＋Zenn＋draw.ioの3つから始める」のが最善とされています。 - 失敗2：完璧を目指して公開しない
「もう少し充実してから」「もっとコードが綺麗になってから」と先延ばしにしている間に、競合するエンジニアが公開し始めるとされています。「60点でも公開する」が大原則とされています。コードは後から改善できます。 - 失敗3：更新なしで放置する
作成後に放置すると、採用担当者に「現役のスキルではないのでは」という印象を与える可能性があります。月1回の確認タスクをカレンダーに登録し、習慣化することが有効とされています。
資格との連携戦略
資格別の活用法
資格とポートフォリオを組み合わせることで「知識の証明（資格）」と「実践能力の証明（ポートフォリオ）」の両輪が揃い、採用担当者への説得力が大幅に高まるとされています。資格の学習過程で得た「設計の考え方」をポートフォリオに反映させることで「資格のための知識」が「実践の知識」として示せるとされています。
| 資格 | ポートフォリオでの活用方法 | 組み合わせの効果 |
|---|---|---|
| AWS認定ソリューションアーキテクト | 3層アーキテクチャのTerraformコード公開＋設計記事 | クラウド設計力のアピールに最適とされています |
| CCNP | ネットワーク設計の記事執筆、VPC設計の実例紹介 | NW知識とクラウドの橋渡し役として評価される可能性があります |
| LPIC-2 / RHCE | Linux環境構築のAnsibleコード、サーバ管理の工夫を公開 | オンプレ〜クラウド移行経験として訴求できるとされています |
| AZ-900 / AZ-104 | AzureとAWSの比較記事、マルチクラウド構成例を公開 | マルチクラウド対応力として差別化できる可能性があります |
初心者の次のステップ
インフラエンジニアのポートフォリオ作成は「難しそうに見えて、実は段階的に進められる」とされています。特に「作業量が多くて途中で挫折する」というケースを防ぐため、最初の1ヶ月は以下の4ステップに集中することが有効とされています。
- 第1週：GitHubプロフィール整備・README作成・プロフィール画像設定
- 第2週：過去の構築経験から1つを選び、Terraformコードとして実装・公開
- 第3週：README作成と構成図をdraw.ioで作成・GitHubに埋め込み
- 第4週：Zennで「このコードを作成した理由と設計思想」を技術記事として執筆・公開
このペースで進めれば、1ヶ月後には「採用現場で説得力のあるポートフォリオ」が完成するとされています。完成後は「毎月1本の技術記事執筆」と「半年に1回のメンテナンス」を続けることで、ポートフォリオは「生きた実績データベース」として機能するとされています。
また、キャリアパスの方向性によってポートフォリオの内容を調整することも重要とされています。「スペシャリスト（特定技術の深掘り）」を目指す場合はAWSやKubernetesなど1分野を深く掘り下げ、「ジェネラリスト（クラウド・DevOps・SRE横断）」を目指す場合は複数のクラウドや自動化ツールを組み合わせた幅広い構成例を示すことが効果的とされています。
ポートフォリオの整備は、転職活動のためだけでなく「自分のスキルを言語化・構造化するプロセス」そのものとして、エンジニアとしての成長にも直結するとされています。まずは第1週の「GitHubプロフィール整備」から始めることをお勧めします。
免責事項
本記事の情報は執筆時点のものです。資格試験の合格・年収は個人差があります。
