転職や案件獲得のためにポートフォリオを作ろうとして、何を作れば評価されるのか分からず手が止まっている方は少なくありません。「TODOアプリでは弱い」「もっと凝ったものを作らないと」といった不安を抱えがちですが、実は評価する側が見ているポイントは、作品の派手さとは少しズレています。本記事では、採用側・発注側の視点から、ポートフォリオで何を示すべきかを整理します。
ポートフォリオで見られているのは「何を作ったか」ではない
ポートフォリオを準備する際、多くの人が「テーマ選び」に時間をかけます。ECサイト、SNSクローン、チャットアプリ……。しかし採用担当者やエンジニアリングマネージャーが見ているのは、テーマの独自性そのものではありません。見られているのは主に次の3点です。
- コードを書く上での基本的な設計力があるか
- 課題に対して技術をどう選び、どう組み立てたか
- 完成させて公開まで持っていく実行力があるか
特に3点目は軽視されがちですが、実務では「作りかけで止まっている」プロジェクトが山ほど存在します。小さくても最後まで動く形で公開できていること自体が、一定の評価につながります。
逆に言えば、テーマが目新しくなくても、設計や実装の質、そして完成度が伴っていれば評価対象になり得ます。「何を作るか」で悩みすぎるより、「作ったものをどう説明するか」に時間を使うほうが、結果的に評価される可能性が高いと考えられます。
技術選定の理由を語れるかが差になる
面接やカジュアル面談でポートフォリオの話になったとき、よく聞かれるのが「なぜこの技術構成にしたのですか」という質問です。ここで「流行っていたから」「チュートリアルがそうだったから」としか答えられないと、技術に対する主体的な判断力が伝わりにくくなります。
一方で、次のように答えられると印象は変わります。
- 「認証機能を自作せず外部サービスを使ったのは、セキュリティリスクを自前で抱えたくなかったため」
- 「状態管理ライブラリを導入しなかったのは、画面数が少なく複雑な状態共有が発生しない規模だったため」
- 「DBに正規化を崩した箇所があるのは、参照頻度の高いクエリのパフォーマンスを優先したため」
重要なのは、正解の技術選定をすることではなく、選定の背景にある思考プロセスを言語化できることです。むしろ「今振り返ると、この選定は過剰だった」といった反省点まで話せると、技術に対して誠実に向き合っている印象を与えられます。
ポートフォリオを作る段階から、「なぜこの技術にするか」をメモしておく習慣をつけておくと、後で説明に困りません。
READMEの書き方
コードそのものより先に読まれるのがREADMEです。忙しい採用担当者やエンジニアは、リポジトリを開いてまずREADMEに目を通し、そこで続きを見るかどうかを判断することが多いと言われています。最低限含めておきたい項目は以下の通りです。
- アプリの概要（何を解決するためのものか、1〜2行で）
- 主な機能一覧
- 使用技術とバージョン
- 動作しているデモへのリンク（後述）
- 環境構築手順（ローカルで動かせるように）
- 工夫した点・苦労した点
- 今後の改善予定
この中でも「工夫した点・苦労した点」は差がつきやすい項目です。ここに前述した技術選定の理由や、実装中にぶつかった課題とその解決方法を書いておくと、READMEを読むだけである程度の技術力と思考の筋道が伝わります。
スクリーンショットや簡単な構成図を添えるのも有効です。文章だけのREADMEより、視覚的に構造が伝わるものの方が、短時間で内容を把握してもらいやすくなります。
動くデモを用意することの重要性
コードだけが公開されていて、実際に触れる状態になっていないポートフォリオは、評価する側にとって手間がかかります。ローカル環境を構築してまで動作確認をしてくれる採用担当者は、決して多くありません。
そのため、Vercel、Netlify、Renderなど無料枠のあるホスティングサービスを使って、実際にブラウザから触れるデモを用意しておくことは、評価してもらう機会を増やす上で有効です。バックエンドを含む構成であっても、DBをサービス側の無料プランに乗せるなどして、できる限り「クリックしてすぐ動く」状態を目指すとよいでしょう。
ただし、無料プランには稼働時間の制限やスリープ挙動があるサービスも存在します。初回アクセス時に起動待ちで時間がかかる場合があることは、READMEに一言添えておくと親切です。この点は利用するサービスによって仕様が異なるため、各サービスの公式ドキュメントで最新の条件を確認することをおすすめします。
デモがどうしても用意できない場合は、操作画面を録画した短い動画やGIFをREADMEに埋め込むだけでも、静止画やコードだけの状態よりは伝わりやすくなります。
よくある失敗パターン
ポートフォリオ準備でつまずきやすいパターンをいくつか挙げます。
チュートリアルをなぞっただけで終わっている
書籍や動画教材のコードをほぼそのまま写経したものは、独自の技術判断が見えにくく、実装力の証明としては弱くなりがちです。最低限、機能を1つ追加する、UIを変更するなど、自分の判断を加える工夫が求められます。
過剰な機能を詰め込んで未完成のまま止まっている
意欲は伝わりますが、動かない状態では評価のしようがありません。機能を絞ってでも完成させ、公開まで到達させることを優先したほうが、実行力の証明になります。
READMEが簡素すぎる、あるいは存在しない
前述の通り、READMEは最初の窓口です。ここが薄いと、コードの中身を見てもらう前に離脱されてしまう可能性があります。
技術選定の説明が「流行だから」で止まっている
技術そのものの巧拙より、判断の過程が問われる場面が多いため、選定理由を自分の言葉で説明できる状態にしておくことが重要です。
セキュリティ的に危険な状態で公開している
APIキーやDBの接続情報がリポジトリに直接コミットされているケースは、実務では致命的な問題として扱われます。環境変数の扱いなど、基本的なセキュリティ対策ができているかどうかも、地味に見られているポイントです。
まとめ
ポートフォリオで評価されるのは、テーマの目新しさよりも、技術選定の理由を説明できるか、READMEで思考の過程を示せているか、そして動くところまで完成させられているかという点です。派手な機能を追加するより先に、今あるポートフォリオのREADMEを見直し、技術選定の理由と工夫した点を言語化することから始めてみてください。
