エンジニアを目指す大学生はポートフォリオを作れ

「プログラミングできます」。就職活動の面接でそう言ったとして、面接官はどう判断するだろう。「どのくらいできるんですか」、「何を作ったんですか」。返せる答えがなければ、その一言は空気に溶ける。

ポートフォリオとは、その答えを形にしたものだ。

ポートフォリオは作品集ではない

「ポートフォリオ」と聞くと、デザイナーが見せるような洗練された作品集を想像するかもしれない。エンジニアのポートフォリオは違う。美しさより、中身だ。

エンジニアのポートフォリオとは、自分が何を考え、どんな問題に取り組み、どう解決したかの記録だ。作品の出来栄えだけではなく、その裏にある思考の過程に価値がある。なぜその技術を選んだのか。どこで詰まり、どう乗り越えたのか。何がうまくいき、何がうまくいかなかったのか。

採用担当者がポートフォリオを見るとき、完成度だけを見ているわけではない。この人がどのように考え、どのように学ぶのかを見ている。完璧なアプリケーションひとつより、試行錯誤の痕跡が残った複数のプロジェクトのほうが、その人の技術力と成長の軌跡をよく伝える。

大学生の段階で完璧なポートフォリオを求める必要はない。成長の途中であることは、むしろ強みだ。重要なのは、その成長が記録されていることだ。

GitHubだけでは足りない

GitHubにコードを置いているから大丈夫、と思っているなら再考したほうがいい。

GitHubはソースコードの管理には優れている。しかし、採用担当者の多くはエンジニアではない。人事部の担当者がGitHubのリポジトリを開いて、コードの品質を読み取ることは期待できない。たとえ技術に詳しい面接官であっても、初対面の候補者のコードを一行ずつ読む時間的余裕はめったにない。

GitHubは素材の置き場であって、ポートフォリオそのものではない。素材を整理し、文脈を添え、読み手に伝わる形にまとめる必要がある。

具体的には、各プロジェクトのREADMEを丁寧に書くことが最低限の対応だ。プロジェクトの概要、使用技術、動機、工夫した点、実行方法。これだけで、コードを読まなくてもプロジェクトの輪郭がつかめる。スクリーンショットやデモのGIFがあれば、なお良い。

しかし、READMEの充実だけでは限界がある。プロジェクト単体の説明はできても、自分のスキルセットの全体像や、プロジェクト間のつながりは見えにくい。それを補うのがポートフォリオサイトだ。

何を載せるか

ポートフォリオに載せるべきものは、大きく三つに分けられる。

個人プロジェクト

自分ひとりで企画し、設計し、実装したもの。小さくていい。動くものであればいい。

大切なのは「何を解決したか」を軸にすることだ。技術スタックの羅列ではなく、どんな課題があり、なぜその技術を選び、どう実装したかの物語として記述する。

たとえば「Pythonで作ったスクレイピングツール」よりも、「特定のWebサイトから必要な情報を手動で収集する手間を省くために、Pythonでスクレイピングツールを作った。Beautiful Soupでは対応できない動的コンテンツがあったため、Seleniumを併用した」のほうが、技術力も思考力も伝わる。

チーム開発の経験

大学の授業やハッカソン、サークル活動などでのチーム開発経験があれば、積極的に載せるべきだ。

チーム開発で見られるのは、コードの品質だけではない。自分がチームの中でどんな役割を担い、どのようにコミュニケーションを取り、どう貢献したかが問われる。設計の議論をリードしたのか、コードレビューを行ったのか、ドキュメントを整備したのか。技術力とは別の能力が可視化される。

自分が書いたコードだけでなく、チーム全体の成果物における自分の貢献範囲を明確にしておく。「6人チームの中でUI設計と実装を担当し、ペアプログラミングで品質を維持した」のように、具体的に書く。

インターンシップの成果

企業でのインターン経験は、実務に近い環境で何ができたかを示す有力な材料だ。ただし、業務内容の詳細を公開してよいかどうかは企業のNDA（秘密保持契約）による。

公開できない場合でも、扱った技術領域、担当した業務の抽象的な説明、そこで学んだことは書ける。「ビルドシステム領域で開発ツールの実装を担当し、PythonとGitを用いた」程度の粒度であれば、多くの場合問題にならない。具体的な社内情報や製品名を出す必要はない。

ポートフォリオサイトの技術選定

ポートフォリオサイトを作ること自体がひとつのプロジェクトになる。しかし、ここに時間をかけすぎてはいけない。

ポートフォリオサイトの目的は、自分のプロジェクトを見やすく整理して公開することだ。サイト自体の技術的な凝り具合は、ほとんど評価に影響しない。むしろ、ポートフォリオサイトの構築に何ヶ月もかけている時間があれば、載せるプロジェクトをもうひとつ作ったほうが実りがある。

静的サイトで十分だ。GitHub Pagesを使えば、無料でホスティングできる。HTMLとCSSだけでも成立する。JekyllやHugoなどの静的サイトジェネレーターを使えば、Markdownで記事を書くだけでページが生成される。

凝りすぎるな。シンプルで、読みやすく、更新しやすい構成にする。ポートフォリオサイトは中身で勝負するものであって、見た目で勝負するものではない。

ブログを書くことがポートフォリオになる

技術ブログを書くことは、それ自体がポートフォリオの一部になる。

あるツールの使い方を調べ、試行錯誤し、動くようになるまでの過程を記事にする。その記事は、技術力の証拠であると同時に、言語化能力の証拠でもある。エンジニアにとって、技術的な内容をわかりやすく伝える力は、コーディング能力と同じくらい重要だ。

ブログ記事はGitHubのコミット履歴と同じように、学習の時系列を残す。半年前の記事と今日の記事を比べれば、知識の広がりと深まりが見える。それは、どんな資格よりも生々しい成長の記録だ。

ブログのプラットフォームは何でもいい。Zenn、Qiita、はてなブログ、あるいは自前のブログ。大切なのは書き続けることであって、どこに書くかではない。

資格の勉強で学んだことを記事にすれば、資格とブログとポートフォリオが一本の線でつながる。Java Silverの勉強中に躓いたポイントをまとめた記事。AWSの無料利用枠で試したサービスの構成図。基本情報技術者試験のアルゴリズム問題を解く過程で考えたこと。こうした記事は、資格を取ったという事実以上に、その人がどう学んだかを物語る。

コードの見せ方を整える

ポートフォリオに載せるプロジェクトのコードは、見せることを前提に整理しておく必要がある。

READMEを書く。 プロジェクトの目的、使用技術、セットアップ方法、使い方を簡潔にまとめる。READMEのないリポジトリは、表紙のない本だ。何が書いてあるかわからなければ、誰も開かない。

コミットメッセージを意識する。 「fix」「update」だけのコミットが並んでいるリポジトリは、整理されていない引き出しと同じだ。「ログイン機能のバリデーションを追加」「APIレスポンスのエラーハンドリングを修正」のように、何をしたかが一行で伝わるメッセージを心がける。完璧なコミット履歴である必要はないが、最低限の読みやすさは保つべきだ。

ドキュメントを残す。 設計上の判断やアーキテクチャの選定理由をドキュメントに残す。なぜMVCを採用したのか、なぜこのライブラリを選んだのか。コードだけでは伝わらない意思決定の記録が、ポートフォリオの厚みを増す。

完璧を待たない

「もっとスキルがついてから作ろう」「見せられるレベルのものができてから公開しよう」。こう考えて先延ばしにする大学生は多い。

待っている間に就活は始まり、面接の日は来る。そのとき「準備中です」と答えるしかなければ、結局何も見せられないまま終わる。

今の自分のスキルで作れるものを、今の段階で公開する。未熟でいい。大切なのは、ポートフォリオが存在することであり、それが更新され続けていることだ。更新の履歴そのものが、学び続けている証拠になる。

学びの価値は数字では測れない。GPAでは見えない思考の深さや試行錯誤の過程が、ポートフォリオには残る。それは、定量的な指標では捉えられない学びの質を、目に見える形で提示する数少ない手段だ。

まとめ

ポートフォリオは「すごいもの」を見せる場ではない。自分が何を考え、何を試し、何を学んだかを記録する場だ。

GitHubのREADMEを整える。小さくてもいいからプロジェクトを形にする。技術ブログで学びを言語化する。これらを積み重ねていけば、それがそのままポートフォリオになる。

完成を待つ必要はない。完成しないからこそ価値がある。成長し続けている記録は、いつでも最新版だ。