Linuxエンジニア向けポートフォリオの作り方｜GitHubで評価される構成

リナックスマスター.JPの宮崎智広です。
いつもありがとうございます。

「Linuxの勉強は続けているのに、採用担当者にGitHubを見せると反応が薄い」
「インフラエンジニアに転職したいけど、ポートフォリオに何を載せれば評価されるのかまったくわからない」
この悩みは、転職支援の現場でよく耳にします。
GitHubのアカウントを作って草（コントリビューション履歴）を積み上げても、それだけでは採用担当者の目に留まりません。
インフラエンジニアのポートフォリオには、アプリ開発者のそれとは明確に異なる「見せ方の型」があるからです。
私自身、20年以上サーバー構築・運用の現場に関わってきた経験から言えば、インフラの仕事の価値は「動いているシステムの裏側」にあります。
その裏側を可視化して採用担当者に伝えるのが、GitHubを活用したポートフォリオの本質です。
言い換えれば、GitHubは「自分の技術を言語化する場」です。
コードを書くだけでなく、なぜその設計にしたのかを伝える記録を残すことが、他の候補者との決定的な差になります。
インフラ ポートフォリオをGitHubで公開するという行動は、単なる自己PRではありません。
「実際に手を動かして構築した」という事実の証拠であり、採用担当者が最も求めているシグナルです。
特に未経験・異業種からのLinux転職では、このポートフォリオの質が書類選考の通過率を大きく左右します。
この記事では、インフラエンジニア志望の方がGitHubで評価されるポートフォリオを作るための構成・実践ステップ・チェックリストを具体的に解説します。
転職全体の戦略をまだ把握していない方は、先にLinux転職の全体像はこちらから戦略の輪郭を確認しておくと、この記事の各論が立体的に理解できます。

インフラエンジニアの転職でGitHubが重視される理由

「インフラはコードを書かないから、GitHubは不要では？」という声をまだ聞くことがあります。
しかしこれは2010年代前半までの話です。
現在のインフラ領域は、IaC（Infrastructure as Code）・CI/CD・コンテナ化が当たり前になり、構成管理のほとんどがコードで表現されます。
オンプレミス環境でも、Ansibleで構成管理・シェルスクリプトで自動化・PrometheusやGrafanaで監視という組み合わせは珍しくありません。
採用担当者が候補者を比較するとき、口頭での自己申告よりもGitHubの実物を重視する傾向が強まっています。
「Ansibleを3年使っています」という発言よりも、実際のPlaybookリポジトリを見せられる候補者の方が、説得力が圧倒的に違います。
スタートアップや技術力を重視する中堅SIerでは、GitHubのURLを書類選考の段階で求めるところも増えています。
「インフラ GitHub 公開」で検索してくる採用担当者がいるのもこの理由からです。
もうひとつの理由は、インフラ業務の「再現性」をアピールできることです。
採用担当者が候補者に期待するのは「この人が入ったら、うちの環境で同じことができるか」という再現性の証拠です。
コードとREADMEで環境構築手順が残っていれば、それ自体がスキルの実証になります。
私が20年以上の現場経験で一貫して感じるのは、インフラエンジニアの価値は「説明できる技術」にあるということです。
口頭でどれだけ流暢に説明できても、実物がなければ採用担当者には伝わりません。
GitHubは「技術の透明性」を示す場であり、採用担当者が安心して採用判断を下せる根拠になります。

GitHubで評価されるインフラポートフォリオの基本構成

評価されるインフラポートフォリオには、おおむね共通する「型」があります。
私が転職支援の中で多くの方のGitHubを整備してきた経験から、以下の3層構成が最もバランスが良いと感じています。
① メインリポジトリ（1～2本）
最も力を入れたプロジェクトです。
たとえば「Terraform + AnsibleでAWSに本番相当の3層構成を構築するコード一式」「DockerComposeで監視・ログ収集まで含めたLAMP環境を一発構築するリポジトリ」などが典型例です。
このリポジトリのREADMEは特に丁寧に書きます。なぜこの構成を選んだか、どの課題を解決したか、どこで詰まりどう乗り越えたかを文章で説明できることが重要です。
採用担当者はREADMEを読んで「この人と話してみたい」かどうかを判断します。コードより先にREADMEを読む、という担当者がほとんどです。
② サブリポジトリ（3～5本）
Bashスクリプト集・dotfiles・ログ分析ツールなど、日常業務や学習で使う小さなツールをまとめたリポジトリです。
「こういうことを日常的に考えているエンジニア」という習慣の積み重ねを見せる役割を果たします。
1本あたり数十行のスクリプトでも、丁寧なREADMEと組み合わせれば十分に価値が伝わります。
サブリポジトリが3～5本ある状態は「アクティブに手を動かしているエンジニア」という印象を与えます。
③ プロフィールREADME（profile/README.md）
GitHubのプロフィールページに表示されるREADMEです。
スキルスタック（Linux/AWS/Docker/Ansibleなど）・経歴の一言サマリー・問い合わせ先を簡潔にまとめます。
採用担当者がURLをクリックして最初に目を通す「表紙」になるため、整っているだけで第一印象が大きく変わります。
長文は不要です。箇条書き5行＋スキルバッジ＋メールアドレスで十分です。

採用担当者が実際に確認する3つのポイント

採用担当者がGitHubをどう見ているか、私が現場で得てきた情報を整理します。
「コード量」「スター数」「コントリビューション数」を見ているわけではありません。
実際に見ているのは次の3点です。
ポイント①　READMEの質
「何のためのリポジトリか」「動かすのに何が必要か」「どうやってセットアップするか」が5分で理解できるかどうか。
これが不明瞭なリポジトリは、スキルがあっても「説明できないエンジニア」という印象を与えます。
READMEに図や表・動作確認コマンドの出力例を1つでも入れると、印象が大きく変わります。
「前提条件（OS・バージョン・必要ツール）→インストール手順→起動手順→動作確認」という流れで書くと、採用担当者が迷わず読めます。
ポイント②　構成の合理性
ただ動くだけでなく「なぜこの設計か」の痕跡があるかどうかです。
コミットメッセージが「fix」「update」「test」だけのリポジトリは、思考の過程がまったく見えません。
「〇〇の問題を解決するために△△を採用した」「最初はXXで実装したが、YYの理由でZZに変えた」という文脈がREADMEやコミットメッセージに残っていると、評価は格段に上がります。
設計の理由が書けるということは、業務で同じ判断を再現できるということです。採用担当者はそこを見ています。
ポイント③　実際に動く環境の証拠
スクリーンショット・アーキテクチャ図・動作確認コマンドの出力例など、「実際に構築して動かした」という証拠があるかどうかです。
環境の証拠がないと、コピー&ペーストのコードではないかと疑われる可能性があります。
draw.ioやMermaid記法で作ったシンプルなアーキテクチャ図1枚でも、掲載があるだけで信頼感が大きく変わります。
Linuxのコマンド出力をそのままREADMEに貼るだけでも「実際に動かした」という証拠になります。
インフラエンジニアとしての転職活動で重視すべき軸については、20代Linux転職は売り手市場？未経験が狙うべきポジションの記事でも詳しく解説しています。年代別の戦略と合わせて読むと、ポートフォリオで打ち出すべき強みが明確になります。

リポジトリを充実させる実践的な4ステップ

「何を作ればいいかわからない」という方のために、実際に着手できるリポジトリのテーマをステップ順に紹介します。
焦らず1つずつ積み上げることが大切です。
ステップ1：シェルスクリプト集から始める
ログローテーション・サービス死活監視・定期バックアップなど、日常的なLinux管理タスクをBashスクリプト化してまとめます。
最初のリポジトリとして最も着手しやすく、運用経験がある方であれば実務の再現をそのまま形にできます。
shellcheckでLintをかけてエラーゼロにしておくと、品質意識もアピールできます。
リポジトリ名は「linux-admin-scripts」や「bash-tools」など、中身が伝わる名前にしてください。
ステップ2：DockerComposeで環境を一本化
NginxとMySQLとアプリを組み合わせた構成を`docker-compose.yml`ひとつで起動できるようにします。
ポイントは「リポジトリをクローンして`docker compose up`一発で動く」状態まで仕上げることです。
依存関係の解決・ポート設定・ボリューム管理まで含めたCompose設定を一本化できると、「環境をコードで管理する」という現代インフラの基本を理解していることが伝わります。
手順書が不要な再現性こそが、採用担当者に最も刺さるポイントです。
ステップ3：AnsibleかTerraformで本番相当の構成を書く
AWSの無料枠・Vagrant・手元の仮想環境などを使い、実際に稼働させたIaCコードをリポジトリに上げます。
「Linux ポートフォリオ GitHub」で検索してくる採用担当者が特に注目するのが、このIaC/コンテナ層のリポジトリです。
ゼロから書いたものでなくとも、公式サンプルを参考にしながら自分の環境に合わせてカスタマイズし、その変更理由をREADMEに書くだけで十分なオリジナリティが出ます。
Ansibleなら「roles/」構成でロールを分離する、Terraformなら「modules/」でリソースを分割するだけで、構成管理の知識があることが伝わります。
ステップ4：CIでテストを自動化する
GitHub Actionsを使い、シェルスクリプトのLint（shellcheck）やAnsibleのsyntax-checkを自動実行する設定を加えます。
CI設定があるリポジトリは「品質と自動化を意識しているエンジニア」という印象を与え、DevOps寄りのポジションを狙う場合に特に有効です。
設定ファイルは`.github/workflows/ci.yml`1本から始めれば十分です。
プルリクエストのたびにLintが走る仕組みを作るだけで、エンジニアとしての習慣が伝わります。
このポートフォリオ戦略は、失敗しないLinux転職の戦略【完全ガイド】で解説している「スキルの可視化」フェーズに直結します。書類選考を突破できない方は、全体ガイドと合わせて読むと突破口が見えてきます。
40代でのLinuxエンジニアへのキャリアチェンジを検討している方は、40代未経験でLinux転職は可能か？成功者の共通点5つもあわせてご覧ください。ポートフォリオで何を強調するかは年代によって戦略が変わります。

よくある失敗パターンと回避策

実際にインフラポートフォリオを整備するとき、よくやりがちな失敗をまとめます。
私が支援した方たちを見てきて、この4パターンで大半がカバーされます。
失敗①　READMEが「インストールしました」だけ
「Nginxをインストールして動かしました」というREADMEは、何の差別化にもなりません。
「なぜNginxにしたか」「どんな問題を解決したか」「設定で工夫した点は何か」まで書いて初めて価値が出ます。
私が支援した方の多くは、このREADMEの深さが書類通過率の分かれ目でした。
1つの工夫を3行で説明するだけでも、採用担当者の印象は大きく変わります。
失敗②　認証情報をそのまま上げてしまう
AWSのアクセスキー・DBのパスワード・APIキーなどをコードに直書きしてGitHubに上げると、即座にスキャンされて悪用されます。
秘密情報は必ず環境変数・`.env`ファイル（`.gitignore`に追加）・AWS Secrets Managerで管理してください。
過去のコミットに含まれている場合も危険です。`git log -p | grep -i "password\|secret\|key"` で履歴を確認してください。
これをやらかしているリポジトリは、採用担当者に「セキュリティ意識がない」と即判断されます。スキルがあっても挽回が難しい失点です。
失敗③　1つのコミットに全部詰め込む
「initial commit」で全ファイルを一気にコミットするリポジトリは、作業の過程がまったく見えません。
試行錯誤の記録がコミット履歴に残っている方が、エンジニアとしての思考プロセスが伝わります。
「まず動くものを作る→リファクタリング→テスト追加→README整備」という流れをコミット単位で分けるだけで、作業の丁寧さが伝わります。
コミットメッセージは「何をしたか」より「なぜしたか」を書く習慣をつけてください。
失敗④　動かない状態で公開している
依存パッケージのバージョンが違う・OSが違うと動かない・手順が途中で途切れているなど、手順通りにやっても動かないリポジトリは逆効果です。
公開前に別の仮想環境でゼロから手順を追って確認してください。
「試したら動かなかった」という経験をした採用担当者は、候補者の評価を大きく下げます。
Vagrantやmultipassで使い捨ての仮想環境を作り、READMEを一字一句なぞって確認する習慣を持ってください。

公開前に必ずやるべきチェックリスト

リポジトリを採用担当者に見せる前に、以下を必ず確認してください。
この8項目を満たしているだけで、大多数のインフラエンジニア志望者のGitHubより完成度が高くなります。
□ READMEに「このリポジトリの目的」が1段落で書いてあるか
□ セットアップ手順が番号付きで順序通りに書いてあるか
□ 動作確認コマンドと期待される出力が書いてあるか
□ 認証情報・秘密鍵・APIキーがコードに含まれていないか（`git log`で過去のコミットも確認）
□ `.gitignore`が適切に設定されているか
□ アーキテクチャ図またはスクリーンショットが1枚以上あるか
□ 別の仮想環境でゼロから手順通りに動くことを確認したか
□ プロフィールREADMEに連絡先（メールまたはLinkedIn）が書いてあるか
一見地味な作業ですが、採用担当者はこのような細部から候補者の仕事の丁寧さを判断します。
特に認証情報チェックと動作確認は、怠ると取り返しのつかない失点につながります。
リポジトリを公開する前と、面接直前の2回このチェックリストを通すことをすすめます。

よくある質問

GitHubアカウントが空でも転職活動できますか？

できます。ただし書類選考の通過率に差が出ます。
「実務経験がない分、GitHubで補う」という意識が、未経験・異業種からのLinux転職では特に重要です。
私が見てきた中で、同程度のスキルの候補者が2人いたとき、GitHubが整備されている方が書類を通過するケースが圧倒的に多いです。
最低1本のメインリポジトリを整備してから活動を始めることを強くすすめます。

プライベートリポジトリしかない場合はどうすればいいですか？

業務で使ったコードはプライベートにしておく必要があります。
業務コードをそのまま公開するのは守秘義務違反になる可能性があるため、学習目的で作成したサンプルリポジトリを別途パブリックで用意してください。
面接で「業務では〇〇をやっています。公開できる範囲のサンプルはこちらです」と説明すれば、採用担当者も理解します。
実際に業務でやっていることを抽象化・単純化して再現したリポジトリが、説明力と実力の両方を伝える最良の形です。

LinuxポートフォリオにクラウドAWSの要素は必須ですか？

必須ではありません。ただし、あると評価が上がるポジションが多いのは事実です。
オンプレミスのLinux環境に特化したリポジトリでも、Vagrant・KVM・仮想環境での構築記録があれば十分評価されます。
AWSが要件に含まれる求人を狙う場合は、EC2・VPC・IAMの基本構成をTerraformで書いたリポジトリがあると明確な強みになります。
AWSアカウントの無料枠（12ヵ月）を使えば、実際に稼働させたコードをリポジトリに残せます。

GitHubへの公開で情報漏洩が心配です。どう対処すればいいですか？

まず守秘義務の範囲を確認してください。
前職・現職のコードをそのまま上げることは基本的にNGです。
自分で一から書いた学習用コードであれば公開して問題ありません。
公開前に`git log --all --full-history -p`で認証情報が過去のコミットに含まれていないかを必ず確認してください。
間違えて上げてしまった場合、`git filter-branch`や`BFG Repo-Cleaner`で履歴ごと削除する必要があります。
「心配だから公開しない」という選択は転職活動上の大きな機会損失です。学習コードを安全に公開する習慣を早めに身につけてください。

まとめ

インフラポートフォリオをGitHubで評価されるレベルにするための要点を振り返ります。
・採用担当者はコード量よりも「READMEの質」「構成の合理性」「動く証拠」を見ている
・メインリポジトリ1～2本＋サブリポジトリ3～5本＋プロフィールREADMEの3層構成が基本
・シェルスクリプト集→DockerCompose→IaC→CIの順に積み上げると無理がない
・認証情報の漏洩と「動かない状態での公開」は採用に直結する致命的なミス
・公開前の8項目チェックリストを通過させてから採用担当者に見せる
ポートフォリオは一夜で完成するものではありません。
私がこれまで支援してきた方の中でも、GitHubをしっかり整備した方の書類通過率は、そうでない方と比べて明らかに差がありました。
今日、まずシェルスクリプト1本を書いてリポジトリに上げてみてください。
その小さな一歩が、半年後の書類選考通過に直結します。
未経験からLinux転職する方法を詳しく解説している記事も合わせてご覧ください。転職活動全体の進め方を体系的に把握した上でポートフォリオ戦略を組み立てると、効果が倍になります。

P.S
GitHubのリポジトリは、一度整備すれば転職活動が終わった後も自分の技術の記録として残り続けます。面接で「あのときこう考えた」と語れる資産が積み上がっていくことが、エンジニアとしての成長の証拠になります。焦らず、1つずつ丁寧に積み上げてください。
【Linuxセミナー】リナックスマスタープロセミナー

[失敗しないLinux転職のポイント｜転職サイト・転職エージェント厳選]

---

• 前のページへ：運用監視から脱出する方法｜構築・設計職へのキャリアアップ
• この記事の属するカテゴリ：Linux転職へ戻る