【ITエンジニア転職講座 第4回】ポートフォリオ戦略。GitHubとQiitaで「技術力」を可視化する

「勉強しています」という言葉に、1円の価値もない。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、書類選考を突破するための「職務経歴書」の書き方について解説しました。
しかし、書類でどれだけ立派なことを書いても、エンジニアの世界には残酷な真実があります。

それは、「コードを見せないエンジニアは信用されない」ということです。
特に2026年の今、AIを使えば誰でもそれっぽい文章やコードが書ける時代になりました。
だからこそ、「あなたが実際に手を動かし、悩み、解決した痕跡（ログ）」であるポートフォリオや技術ブログの価値が、以前にも増して高まっているのです。

コウ君

先生、GitHubのアカウントは持ってるんですけど、ほとんど「草（Contribution）」が生えてません……。
それに、僕の書いたコードなんてスパゲッティだし、恥ずかしくて公開できませんよ！
凄いエンジニアの人たちみたいに、OSS（オープンソース）に貢献なんて夢のまた夢ですし。
やっぱり、完璧なアプリが完成するまで非公開にしておいた方がいいですよね？

リナックス先生

コウ君、それは大きな間違いよ！
採用担当が見たいのは「完成された芸術作品」ではなく、君の「成長の過程」と「課題解決のプロセス」なの。
真っ白なGitHubは「何もしていない」のと同じ。
「汚いコード」でも、そこからどうリファクタリング（改善）したかを見せることこそが、最強のアピールになるのよ。
今回は、恥ずかしがらずに自分を売り込むための「ポートフォリオ戦略」を徹底的に教えるわ！

本記事では、採用担当者が注目するGitHubプロフィールの作り方、評価されるReadMeの書き方、QiitaやZennでの技術発信のコツ、そしてコードを見せにくいインフラエンジニアのためのポートフォリオ戦略までを徹底解説します。

🚀 ITエンジニア転職攻略講座 カリキュラム

第1章：GitHubは「履歴書」以上の証明書。プロフィールを整備せよ

エンジニアの採用面接において、面接官（現場のエンジニア）は職務経歴書よりも先にGitHubのURLをクリックします。
そこで表示される「プロフィールページ」がスカスカだと、その時点で興味を失われてしまいます。

1. プロフィール用ReadMeの設置

自分のユーザー名と同じ名前のリポジトリ（例: kou/kou）を作成し、そこに README.md を置くと、プロフィールページの一等地に表示されます。
ここに何を書くかが勝負です。

書くべき内容：

  • 自己紹介： どのようなエンジニアを目指しているか（Will）。
  • 技術スタック： 使える言語、フレームワーク、ツール（アイコンを使うと見やすい）。
  • 現在取り組んでいること： 学習中の技術や開発中の個人アプリ。
  • Zenn/Qiitaの記事リンク： 最新の投稿を自動表示するGitHub Actionsなどを使うと効果的。

2. 「Pinned（ピン留め）」の活用

たくさんのリポジトリがあっても、全てを見てもらえるわけではありません。
自信のあるリポジトリ（自作アプリ、ライブラリ、学習記録など）を最大6つまでピン留めできます。
「Forkしただけのリポジトリ」ではなく、「自分がコミットしたリポジトリ」をピン留めしましょう。

3. 草（Contributions）を生やす意味

「草が生えていない（活動履歴が緑色になっていない）とダメですか？」という質問をよく受けます。
結論から言うと、「毎日生えている必要はないが、継続性は見られている」です。

「転職活動を始めた先月から急に草が生えている」よりも、「週末だけだけど1年間コンスタントに生えている」方が、技術への継続的な関心を示す証拠になります。
どうしても草が生やせない（業務コードがPrivateリポジトリ）場合は、プロフィールの設定で「Private contributions」を表示するようにしましょう（詳細は見えませんが、活動量は伝わります）。

第2章：ReadMeを書かないリポジトリは「存在しない」のと同じ

採用担当者は忙しいです。
コードの中身を読む前に、まずリポジトリの README.md を読みます。
ここに何も書かれていなかったり、デフォルトのままだったりすると、「ドキュメントを書けない（人に説明する気がない）エンジニア」と判断され、コードすら読まれません。

評価されるReadMeの構成テンプレート

以下の項目を網羅していれば、それだけで「ちゃんとしたエンジニア」に見えます。

  1. プロダクト名と概要： ひとことで言うと何をするアプリか？（3行以内）
  2. デモURL / スクリーンショット： 動いている様子を見せる（GIF動画がベスト）。
  3. 使用技術： フロント、バック、インフラ、AIモデルなど。バージョンも明記。
  4. 解決した課題（Why）： なぜこれを作ったのか？ 誰のどんな悩みを解決するのか？
  5. こだわったポイント（How）： 技術的な工夫、苦労した点、アーキテクチャの選定理由。
  6. 環境構築手順： git clone から npm start まで、誰でも起動できるように書く（Docker化されていると高評価）。

💡 プロの視点：アーキテクチャ図の威力
AWS構成図や、クラス図、ER図などを Mermaid記法 でReadMeに埋め込んでおくと、評価が爆上がりします。
「設計してからコードを書いている」という証明になるからです。
GitHubはMermaid記法をネイティブサポートしているので、ぜひ活用してください。

第3章：「汚いコード」こそ公開せよ。リファクタリングの履歴を見せる

「完璧なコードが書けるまで公開しない」というのは、初心者が陥りがちな最大の罠です。
完成されたコードだけを見せられても、採用担当者は「本当にこの人が書いたの？（AIじゃないの？）」と疑うこともあります。

Pull Request (PR) をポートフォリオにする

個人の開発であっても、main ブランチに直コミットするのではなく、トピックブランチを切って Pull Request (PR) を作り、自分でマージするフローを踏みましょう。

ここが見られている：

  • コミットメッセージの粒度： 「fix」「update」だけでなく、「〇〇機能の追加」「バグ修正: 〇〇の原因対応」など、意図が明確か。
  • PRの説明文： 変更の目的、影響範囲、スクリーンショットが貼られているか。
  • セルフレビュー： 自分のPRに対して自分でコメントし、「ここは後でリファクタリングが必要」「パフォーマンス懸念あり」などのメモを残しているか。

Before / After を見せる

最初は「動くけど汚いコード（巨大な関数、ハードコーディング）」をコミットします。
その数日後に、「リファクタリング」というPRを出して、コードを綺麗にします。
この「改善の履歴」こそが、あなたの成長力と技術への誠実さを証明する最強のポートフォリオになります。

「最初から完璧な人」よりも、「悪いコードを良いコードに直せる人」の方が、現場では圧倒的に重宝されるのです。

第4章：Qiita/Zenn活用術。トラブルシューティング記事が最強の武器になる

コードだけでなく、日本語でのアウトプット（技術ブログ）も重要な評価対象です。
特に2026年は、ZennやQiitaのアカウントリンクを貼ることが当たり前になっています。

「やってみた」記事はもう古い

「Reactのチュートリアルをやってみた」という記事は、ネット上に溢れかえっており、評価されにくいです。
評価されるのは、以下のような「一次情報」を含む記事です。

1. エラーハマり記録（トラブルシューティング）

開発中に遭遇したエラーと、それをどう解決したかの記録です。

  • 発生したエラーログ： そのまま貼る。
  • 仮説と検証： 「最初はAだと思ったが違った。次にBを試したら……」という思考プロセス。
  • 解決策と原因： 最終的に何が原因だったのか。

これは、同じエラーに遭遇した世界中のエンジニアを助けるだけでなく、採用担当者に「問題解決能力」を示すことができます。

2. 技術選定の理由

「なぜNext.jsではなくRemixを選んだのか」「なぜMySQLではなくPostgreSQLなのか」。
正解である必要はありません。自分なりの基準で比較検討したプロセスを書くことで、「技術選定ができるエンジニア」として評価されます。

💡 プロの視点：Zenn Scrapsの活用
ブログ記事としてまとめるのが大変なら、Zennの Scraps（スクラップ） を使いましょう。
Twitter（X）のように気軽につぶやきながら、試行錯誤の過程をスレッド形式で残せます。
「完成品」だけでなく「悩んでいる過程」も立派なコンテンツです。

第5章：インフラエンジニアのポートフォリオ。IaCと構成図で見せる

「インフラエンジニアだからコードがない」というのは言い訳になりません。
現代のインフラはコードで管理される（IaC）からです。

1. Terraform / Ansible のコード公開

AWSやGCPの環境構築を Terraform や CloudFormation でコード化し、GitHubに上げましょう。
機密情報（アクセスキーなど）を環境変数やSecrets管理できているかどうかも、重要なチェックポイントです。

2. 自宅サーバー / Kubernetesクラスタ

ラズパイや古いPCを使って自宅Kubernetesクラスタを構築し、そのマニフェストファイル（YAML）を公開するのも強力なアピールです。
「GitOps（ArgoCDなどでGitHubの変更を自動デプロイ）」を実践していれば、DevOpsエンジニアとして即戦力扱いされます。

3. ネットワーク構成図

コードだけでなく、draw.io などで描いたネットワーク図（VPC、サブネット、SG、LBの配置）をReadMeに貼りましょう。
インフラエンジニアにとって、構成図はコード以上に雄弁にスキルを語ります。

第6章：2026年流。AIとの「共創」履歴を残す

最後に、2026年ならではのポートフォリオ戦略についてです。
「AIを使って開発しました」は、もはやマイナス評価ではなくプラス評価です。

Copilot / ChatGPT との対話ログ

開発中にAIとどう対話したかを記録に残しましょう。
例えば、リポジトリの中に prompts.md というファイルを作り、そこに「どのようなプロンプトを投げて、どのようなコードを出力させ、それを人間がどう修正したか」を記録します。

「AIが出したコードのセキュリティホール（SQLインジェクション脆弱性など）を人間が見つけて修正したコミット」があれば、それはあなたがAIの上位互換であることを証明します。

AIを活用したツールの開発

OpenAI APIやAnthropic APIを使った簡単なアプリ（チャットボット、要約ツールなど）を一つ作っておくと、「AIをシステムに組み込むスキル」のアピールになります。
コード量は少なくても、APIキーの管理やレートリミットへの対応など、実務的なポイントを押さえていれば高評価です。

まとめ：アウトプットは裏切らない

お疲れ様でした。
第4回では、GitHubと技術ブログを使ったポートフォリオ戦略について解説しました。

今回の重要ポイント：

  • GitHubプロフィールとReadMeは「顔」。徹底的に作り込む。
  • 完璧なコードよりも、PRを通じた「改善のプロセス」を見せる。
  • Qiita/Zennには「エラー解決ログ」や「技術選定の理由」を書く。
  • インフラエンジニアはIaCと構成図で勝負する。
リナックス先生

「公開するのが恥ずかしい」という気持ちは分かるわ。
でも、ネット上のエンジニアは意外と優しいのよ。
間違っていたら教えてくれるし、何より「行動している人」を笑う人はいないわ。
今日から一つでいいから、草を生やしてみましょう！

さて、武器（スキルシート）と防具（ポートフォリオ）が揃いました。
いよいよ戦場（転職市場）へ出陣です。

次回、第5回は「企業選び。エージェント vs ダイレクトリクルーティング徹底比較」です。
大量に来るスカウトメールの捌き方、本当に良いエージェントの見分け方、そして「隠れ優良企業」の探し方を伝授します。お楽しみに！

▼ アウトプットを始める ▼

ポートフォリオサイトを公開
「おすすめVPS」

VPSランキングを見る

GitHubを評価してもらう
「ITエンジニア転職」

転職エージェントを見る

コメント