デザイナーとフロントエンド開発者にとって、ポートフォリオは履歴書よりも重要なことが多いです。それは証拠です。履歴書は仕事ができると主張し、ポートフォリオは仕事そのものと、より重要なこととして、それについてどう考えるかを示します。
ほとんどのポートフォリオは2つのうちどちらかで失敗します。平凡なプロジェクトが多すぎるか、美しいスクリーンショットはあるが問題・自分の役割・成果の説明がないか。このガイドは両方を直します。
要点
- 強い3〜5件のプロジェクトは、平均的な12件に勝ります。レビュアーが費やすのは合計で2〜3分です。
- どのプロジェクトにも同じ背骨が必要です。問題、あなたの役割、プロセス、解決策、影響。
- 整った最終画面だけでなく、雑然とした途中経過 — スケッチ、反復、トレードオフ — を見せましょう。
- 開発者：公開リンク＋整ったREADME＋読みやすいコードは、凝ったサイトより重みがあります。
何を載せるか選ぶ
- 1見せられるプロジェクトをすべて挙げます — 仕事、フリーランス、個人プロジェクト、授業課題、ハッカソン、オープンソース。
- 2それぞれを次の観点で評価します。望む仕事との関連性、成果のうち自分の貢献と言える割合、自分の具体的な貢献を説明できるか。
- 3上位3〜5件を残します。大量の注釈が必要なもの、NDAのため話せないものは外します。
- 4セットが幅を示すようにします — 同じ画面の5つのバージョンではなく、異なる種類の問題。
深く語れる自主プロジェクトは、ほとんど触れていない実案件に勝ります。使っている製品を再設計する、必要だったツールを作る、オープンソースのリポジトリに貢献する。
ケーススタディの構成
ケーススタディは、形の決まった短い物語です。読者が2分でざっと見られ、5分で最後まで読めるものを目指しましょう。
1. 概要（2〜3文） 製品は何か、誰のためか、プロジェクトは何だったか。 2. 自分の役割 肩書き、チーム、期間、責任を持ったことと貢献したことの違い。 3. 問題 ユーザーまたはビジネスの問題と、それが実在すると分かった根拠（データ、調査、苦情）。 4. プロセス 行った3〜4の重要な動き。成果物を示す：スケッチ、フロー、プロトタイプ、実験、PR。 少なくとも1つのトレードオフや行き止まりと、方向を変えた理由を含める。 5. 解決策 最終結果を、ビジュアルまたは公開リンクとともに。重要な意思決定に注釈を付ける。 6. 影響 数字があれば（コンバージョン、読み込み時間、タスク成功率、利用率）。なければ定性的な成果と、次に測るもの。 7. 学んだこと 正直な振り返りを1〜2点。
こう書く代わりに
「ユーザー体験を改善するために購入フローを再設計した。」＋整ったスクリーンショット4枚。
こう書く
「モバイルのカゴ落ちは68%だった。ユーザーセッションを5回行い、住所フォームが離脱地点だと分かり、2項目の自動補完を元の9項目と比較テストして勝った方をリリース。6週間でカゴ落ちが51%に低下した。」＋ビフォーアフター＋テストした2つのプロトタイプ。
開発者の場合
- 各プロジェクトに、動作する公開デモのリンクとリポジトリのリンクの両方を。壊れたデモはデモなしより悪いです。
- 本物のREADMEを書く：何をするか、スクリーンショットまたはGIF、技術スタック、ローカルでの実行方法、次にやること。
- GitHubプロフィールに最良のリポジトリ4〜6件を固定し、プロフィールREADMEを追加する。
- コード品質のシグナルを目立たせる：テスト、CI、明確なコミット、妥当な構成。レビュアーは実際にコードを開きます。
- オープンソースへの貢献も数に入る — マージされたPRをリンクし、それぞれが何をしたか簡潔に書く。
- 視覚要素がないバックエンドやデータの役割では、明確なアーキテクチャ図と文章での説明がスクリーンショットの代わりになります。
# プロジェクト名 何をするか、誰のためかを一文で。  ## 作った理由 2〜3文。 ## スタック 言語、フレームワーク、主要ライブラリ、ホスティング。 ## ローカルで実行する 手順。 ## 主要な意思決定 - 意思決定とその理由 - 行ったトレードオフ ## 次にやること 短いリスト。
デザイナーの場合
- 最終カンプだけでなくプロセスの成果物を見せる：調査メモ、ユーザーフロー、ワイヤーフレーム、反復。
- リリースされなかったバージョンも入れ、理由を述べる — 判断力を示せます。
- ポートフォリオサイト自体の視覚的な作り込みを高く保つ。意図せずとも、それが作品サンプルです。
- すべての意思決定を、個人の好みではなくユーザーのニーズやビジネス目標に結びつける。
- UXの役割では思考から入り、ビジュアルやブランドの役割では作り込みから入る — ただしどちらも両方が必要です。
どこにホスティングするか
- 自分のドメインの個人サイトが最も強い選択肢です — 完全な管理、本気度が伝わります。
- 早く公開できる：サイトビルダーのテンプレート、またはGitHub Pages、Vercel、Netlifyの簡単な静的サイト。
- デザイナーはBehanceやDribbbleでリーチを補えますが、本物のケーススタディは自分のサイトに置きましょう。
- 開発者：GitHubは必須。ポートフォリオサイトはプラスです。
- メールで求められたときのために、1〜2件のケーススタディのPDF版またはスライド版を常に用意しておきましょう。
数週間かけたカスタムアニメーション付きのポートフォリオに、まだ1件しかプロジェクトがなければ誰の役にも立ちません。まず本物のケーススタディ3件を載せたシンプルで速いサイトを公開し、それから改善しましょう。
よくある間違い
- プロジェクトが多すぎて、どれも深く説明されていない。
- 問題の説明、役割、成果のないスクリーンショット。
- 自分が個人的に何をしたか言わずに、チームの成果を自分のものとして主張する。
- 連絡先情報がない、または連絡する明確な手段がない。
- 採用担当者に送るバージョンで、パスワード保護または切れたリンク。
- 最良のプロジェクトを3ページ目に埋もれさせる。
よくある質問
ポートフォリオにはいくつプロジェクトを載せるべきですか？
3〜5件です。レビュアーが3件目より先へ進むことはめったにありません。少数の深さは、多数の広さに勝ります。
NDA対象の仕事を載せてもよいですか？
まず勤務先に相談しましょう。多くの場合、機密の詳細や未公開の画面を出さずに、プロセスと成果を高い視点で示せます。迷ったら、見せる代わりに言葉で説明しましょう。
バックエンド開発者にもポートフォリオは必要ですか？
ポートフォリオサイトは任意ですが、固定リポジトリ、良いREADME、目に見える貢献のある充実したGitHubプロフィールが同じ役割を果たします。
ポートフォリオと履歴書、どちらが先ですか？
ポートフォリオのリンクを履歴書とLinkedInの上部に置きましょう。デザインやフロントエンドの役割では、履歴書がじっくり読まれる前にポートフォリオが見られると考えてください。