HTML・CSS・JavaScriptを学び、Webサイトを作れるようになっても、案件応募や転職の段階で「ポートフォリオに何を載せればよいか」と迷うことがあります。
フロントエンドエンジニアのポートフォリオは、作品を並べるだけのギャラリーではありません。依頼者や採用担当者が、どのような課題に対して、どこを担当し、どのように完成させたかを確認するための資料です。
この記事では、未経験・副業準備中・実務経験者のそれぞれが使えるように、作品の選び方、サイト構成、説明文の書き方、公開前の確認項目を順番に整理します。
先に結論：最初は説明できる3作品をそろえる
最初のポートフォリオでは、作品数を増やすことより、異なる目的の3作品を説明できる状態を目指します。
おすすめの組み合わせは次のとおりです。
| 作品 | 伝えられること | 作品例 |
|---|---|---|
| 複数ページのサイト | 共通パーツ、下層ページ、レスポンシブ設計 | 中小企業のコーポレートサイト |
| 1ページの訴求サイト | 情報の優先順位、CTA、アニメーション | 業務効率化サービスのLP |
| UIや業務機能のある作品 | JavaScript・React、フォーム、状態管理 | 問い合わせ受付フォーム、管理画面 |
同じ雰囲気のLPを何本も並べるより、サイト構築・訴求ページ・操作できるUIを見せるほうが、対応範囲を説明しやすくなります。
作品数に決まりはありません。まず3作品を完成させ、応募したい仕事に足りない要素が見つかった時点で追加します。
ポートフォリオで見られる5つの要素
1. 完成画面
最初に見られるのは、PCとスマートフォンでの完成状態です。
- ファーストビュー
- ページ全体
- スマートフォン表示
- メニューやモーダルなどのUI
- アニメーションやフォームの動作
スクリーンショットだけでなく、可能なら公開URLも用意します。動きが重要な作品では、短い操作動画やGIFがあると伝わりやすくなります。
2. 担当範囲
チーム制作や実務案件では、完成物のすべてを自分が作ったとは限りません。
次のように分けて書きます。
- デザイン：支給されたFigmaデータを使用
- コーディング：自分が担当
- JavaScript：メニュー、モーダル、スクロール演出を担当
- CMS：既存環境への組み込みを担当
- 進行：ディレクター・デザイナーと仕様を確認
「制作しました」だけでは、デザイン、実装、企画のどこを担当したか分かりません。担当外も含めて明確にすることで、かえって信頼性が上がります。
3. 使用技術
技術名は、使った理由や担当内容とセットで書きます。
弱い書き方：
HTML、CSS、JavaScript、Astro、React、GSAPを使用しました。
伝わりやすい書き方：
複数ページで共通するヘッダーとカードを再利用しやすくするためAstroでコンポーネント化しました。スクロールに連動した演出はGSAPで実装し、動きを減らす設定にも配慮しました。
技術の数を多く見せるより、何に使い、どの判断をしたかを書きます。
4. 課題と工夫
仕事を任せる側が知りたいのは、完成画面だけでなく、途中で問題が起きたときにどう対応したかです。
- デザインデータにスマートフォン版がなかった
- 長い文言でボタンやカードが崩れた
- 画像が大きく表示速度へ影響した
- 既存CSSとの競合が起きた
- アニメーションが操作を邪魔した
- フォームの入力漏れが分かりにくかった
問題を書いたあとに、確認方法と対応を書きます。
ボタン文言が端末幅によって不自然に折り返したため、意味のまとまりで改行できる構造へ変更し、2行時の上下余白と最小高さを調整しました。
このような説明は、見た目の再現だけでなく、運用や例外まで考えられることを伝えます。
5. 品質確認
完成後に何を確認したかも実務能力の一部です。
- PC・タブレット・スマートフォン表示
- Chrome、Safariなど対象ブラウザ
- キーボード操作
- 画像の代替テキスト
- 見出し構造
- リンク切れ
- フォームの入力・エラー表示
- 表示速度と画像サイズ
- Gitの差分と不要ファイル
すべてを高度に対応する必要はありません。作品ごとに、実際に行った確認だけを書きます。
ポートフォリオサイトの基本構成
ポートフォリオ全体は、次の順番にすると迷いにくくなります。
1. ファーストビュー
名前または活動名と、何を担当できるかを短く示します。
フロントエンドエンジニアとして、デザインカンプからのWebサイト実装、レスポンシブ対応、JavaScriptによるUI・アニメーション制作に対応しています。
「成長したいです」より、現在できることを先に書きます。
2. 自己紹介
経歴をすべて書くのではなく、現在の仕事につながる流れをまとめます。
- 現在の職種
- これまで経験したサイトや業界
- 得意な作業
- 仕事で大切にしていること
異業種から転職した場合は、前職で身につけた進行管理、仕様整理、コミュニケーションも強みになります。
3. スキル
技術を次のように分類します。
| 分類 | 記載例 |
|---|---|
| マークアップ・スタイル | HTML、CSS、Sass、レスポンシブ対応 |
| 言語・フレームワーク | JavaScript、TypeScript、React、Astro |
| UI・演出 | GSAP、フォーム、モーダル、タブ、アコーディオン |
| 開発環境 | Git、GitHub、Vite、npm |
| デザイン連携 | Figma、Photoshop、画像書き出し |
| 品質 | アクセシビリティ、表示速度、ブラウザ確認 |
習熟度を星だけで表すと基準が分かりにくいため、「実務で使用」「個人制作で使用」「学習中」など、経験の種類も添えます。
4. 作品一覧
各カードには、最低限次を載せます。
- サムネイル
- 作品名
- 種類
- 担当範囲
- 使用技術
- 詳細ページへのリンク
カードの説明を長くしすぎず、詳しい内容は作品詳細へ分けます。
5. 作品詳細
作品詳細こそ、ポートフォリオの中心です。後述するテンプレートを使い、1作品ごとに説明します。
6. 連絡先
問い合わせフォームまたはメールへの導線を用意します。外部フォームを使う場合も、何を相談できるかを添えます。
- Webページのコーディング
- 既存サイトの修正
- レスポンシブ対応
- JavaScriptのUI実装
対応できない内容や、返信の目安も明記すると問い合わせ後の認識違いを減らせます。
作品詳細ページに載せる項目
次のテンプレートを作品ごとに使えます。
| 項目 | 書く内容 |
|---|---|
| 概要 | 何のためのサイト・機能か |
| 想定ユーザー | 誰がどの場面で使うか |
| 制作区分 | 架空案件、個人制作、実務案件 |
| 担当範囲 | デザイン、実装、JS、CMS、進行など |
| 使用技術 | 実際に使った技術と用途 |
| 制作期間 | おおよその期間 |
| 要件・制約 | 対応画面幅、既存環境、素材など |
| 工夫した点 | 判断したことと、その理由 |
| 苦労した点 | 問題、調査、解決方法 |
| 品質確認 | 表示、操作、速度などの確認 |
| URL | 公開ページ、コード、操作動画 |
説明文の例
中小企業の採用強化を目的とした架空のコーポレートサイトです。デザインからコーディングまで担当し、会社情報、事業紹介、採用情報、お問い合わせの4ページを制作しました。共通パーツを再利用できる構成にし、PCとスマートフォンで情報の順番が自然になるよう調整しています。
工夫した点の例
採用情報へ移動するユーザーを想定し、トップページの事業紹介から採用ページへ自然につながる導線を設けました。スマートフォンでは文章量が多くなりすぎないよう、要点をカードへ分けています。
技術説明の例
Reactで問い合わせフォームを実装し、入力内容、確認画面、送信完了の状態を管理しました。入力エラーは対象項目の近くへ表示し、どこを直せばよいか分かるようにしています。
架空案件を載せるときのルール
実務案件を公開できない場合、架空案件は有効な選択肢です。ただし、実在の仕事と誤解されないよう明記します。
架空案件でも決めること
- 想定する会社・サービス
- ターゲット
- サイトの目的
- 必要なページ
- 問い合わせや購入までの導線
- 納期を想定した制作期間
「好きなデザインを作った」だけでなく、要件を自分で設定して判断した過程を説明します。
避けたい見せ方
- 架空案件を実案件のように書く
- 実在企業のロゴや文章を無断で使用する
- 教材をそのまま再現し、自分の設計と書く
- テンプレートを使ったことを隠す
- 動かないボタンや未完成ページをそのまま公開する
素材やテンプレートを使用した場合は、どこを自分で変更したかを書きます。
実務案件を公開できない場合の見せ方
守秘義務や企業のルールにより、実務案件をそのまま掲載できないことがあります。許可なく公開してはいけません。
対応方法は主に3つです。
1. 公開許可を確認する
掲載できる範囲を、企業名、URL、画面、担当範囲ごとに確認します。口頭だけでなく記録が残る形で確認します。
2. 情報を伏せて説明する
企業名や画面を出せなくても、次のように経験を説明できます。
金融系サービスのキャンペーンページで、デザインカンプからのコーディング、レスポンシブ対応、アニメーション実装を担当しました。社名・画面は非公開ですが、担当工程と使用技術を記載しています。
3. 経験をもとに別のサンプルを作る
実務で経験した課題を一般化し、企業固有の情報を使わずに新しい作品を作ります。実務案件そのものではなく、個人制作として区別します。
未経験・副業・実務経験者で見せ方を変える
未経験・学習中
- 架空案件で目的と要件を設定する
- コードを自分で説明できる範囲にする
- 完成までの試行錯誤を書く
- 学習中の技術を実務経験として書かない
副業の初案件を探す人
- 対応できる作業範囲を明記する
- LP、下層ページ、修正など小さな仕事に近い作品を載せる
- 納期や修正を想定した制作過程を書く
- 問い合わせ導線を分かりやすくする
実務経験者
- プロジェクト規模とチーム内の役割を書く
- 新規制作、改修、運用のどこを担当したか分ける
- デザイナー、ディレクター、バックエンドとの連携を書く
- 品質改善や保守性のために判断したことを書く
- 非公開案件は担当内容だけ整理する
実務経験者がフリーランス案件を探す場合、ポートフォリオだけでなく職務経歴書やスキルシートも必要です。フロントエンドエンジニアのスキルシート・職務経歴書の書き方で案件ごとの担当範囲と技術を整理したあと、フロントエンド向けフリーランス案件サービス3社の比較で登録先を確認できます。面談を控えている場合は、フリーランスエージェントの面談対策で作品と経歴を短く説明する練習まで進めましょう。
公開前のチェックリスト
内容
- 自分が担当した範囲が分かる
- 架空案件・実案件・個人制作の区別がある
- 使用技術の用途を書いている
- 工夫した点が具体的である
- 誇張した実績や未確認の数値がない
表示・操作
- PCとスマートフォンで崩れていない
- ナビゲーションと作品リンクが動く
- 画像がぼやけていない
- ボタン文言が不自然に折り返していない
- フォームの入力・エラー・送信後表示を確認した
応募資料として
- 応募したい仕事に近い作品が先にある
- 1分ほどで対応範囲を把握できる
- 作品詳細へ迷わず移動できる
- 連絡先が見つかる
- PDFの職務経歴書と内容が矛盾していない
7ステップで公開する
- 応募したい仕事を1つ決める
- その仕事に必要な3作品を選ぶ
- 各作品の担当範囲と使用技術を整理する
- 作品詳細の説明文を書く
- ポートフォリオサイトへ実装する
- PC・スマートフォン・リンク・フォームを確認する
- 第三者に1分だけ見てもらい、伝わらない部分を直す
最初から演出の多いサイトを作る必要はありません。作品へ迷わず移動でき、担当範囲を正しく読めることが優先です。
まだWeb制作の仕事を始める全体像が決まっていない場合は、Web制作副業の始め方へ戻り、受ける仕事の範囲から整理してください。
まとめ
フロントエンドエンジニアのポートフォリオは、完成画面の美しさだけでなく、目的・担当範囲・使用技術・判断・品質確認を伝える資料です。
- 最初は目的の異なる3作品をそろえる
- 作品ごとに担当範囲を明確にする
- 技術名だけでなく、何に使ったかを書く
- 課題と解決方法を具体的に説明する
- 架空案件と実案件を正しく区別する
- 守秘義務のある情報は掲載しない
ポートフォリオが完成したら終わりではありません。応募先や受けたい仕事に合わせて、作品の順番と説明を更新していきましょう。