フロントエンドエンジニアとして案件へ応募するとき、ポートフォリオだけでは伝えきれない情報があります。
完成画面を見せるポートフォリオに対して、スキルシートや職務経歴書では、どの案件で、どの工程を担当し、どの技術をどのように使ったかを説明します。
ところが、実務を経験していても、「HTML・CSS・JavaScript」と技術名を並べるだけになったり、反対に案件説明が長くなりすぎたりしがちです。
この記事では、Web制作・フロントエンド案件を想定し、スキルシートと職務経歴書の違い、案件ごとの書き方、数値を覚えていない場合の表現、守秘義務がある案件の扱いまで整理します。
ページ内には、この記事の項目をそのまま入力できる無料のExcelテンプレートも用意しています。Googleスプレッドシートへアップロードして使うこともできます。
先に結論：1案件を6項目で説明できれば土台になる
まず、案件ごとに次の6項目を整理します。
- 何のサイト・サービスだったか
- 何を目的とした案件だったか
- 自分が担当した工程
- 使用した技術と用途
- チーム内での連携
- 工夫・改善・品質確認
たとえば、次のようにまとめます。
| 項目 | 記載例 |
|---|---|
| 案件概要 | エンジニア向けイベントの集客LP制作 |
| 目的 | イベント内容を分かりやすく伝え、申込みへつなげる |
| 担当工程 | デザインカンプ確認、コーディング、レスポンシブ対応、アニメーション実装、動作確認 |
| 使用技術 | HTML、Sass、JavaScript、Astro、GSAP |
| 連携 | ディレクター・デザイナーと仕様や動きの認識を確認 |
| 工夫 | 共通パーツをコンポーネント化し、長い文言や画面幅の違いでも崩れにくい構造へ調整 |
「LPを制作しました」だけよりも、任せられる工程と考え方が伝わります。
スキルシートと職務経歴書の違い
提出先によって名称や書式は変わりますが、役割は大きく分けられます。
| 資料 | 主な目的 | よく書く内容 |
|---|---|---|
| 職務経歴書 | キャリア全体と強みを伝える | 職務要約、会社・部署、担当業務、実績、自己PR |
| スキルシート | 案件ごとの技術経験を判断してもらう | 期間、案件概要、役割、工程、技術、環境、チーム |
| ポートフォリオ | 完成物と実装・設計の判断を見せる | 画面、公開URL、担当範囲、使用技術、工夫 |
転職では職務経歴書が中心になりやすく、フリーランスエージェントや業務委託案件では、案件単位のスキルシートを求められることがあります。
どちらか一方だけを作るのではなく、まず案件情報を共通の台帳へ整理し、提出先に合わせて見せ方を変えると管理しやすくなります。
最初に作る「経歴の元データ」
文章を書き始める前に、経験を表へ並べます。
基本情報
- 在籍会社・部署
- 職種
- 在籍期間
- 雇用形態
- 主な担当領域
- 転職・キャリアチェンジの流れ
案件情報
- 期間
- 業界
- サイト・サービスの種類
- 新規制作、改修、運用・保守の区分
- 担当ページ・機能
- 担当工程
- 使用技術
- 開発環境
- 連携した職種
- 工夫・改善
- 公開できる範囲
案件を思い出すときは、カレンダー、Gitの履歴、過去のタスク、チャット、デザインファイル、公開URLなど、確認できる記録を使います。
記憶だけで埋めると、案件間で期間や技術が矛盾しやすくなります。
職務要約の書き方
職務要約は、最初の数行で現在地を伝える部分です。
おすすめの順番は次のとおりです。
- 現在の職種と経験領域
- 経験したサイト・業界
- 主な担当工程
- 前職を含む強み
記載例
ゲームプランナーとして企画・進行管理を経験した後、フロントエンドエンジニアへキャリアチェンジしました。就職支援、金融、保険、教育、クラウドサービスなどのWebサイト制作に携わり、HTML・CSS・JavaScriptを用いた新規制作を中心に、既存サイトの改修、運用・保守も担当しています。デザインの意図を確認しながらレスポンシブ対応やUI実装を行うほか、前職で培った仕様整理と関係者との調整力を生かして業務を進めています。
職務要約は自己PRの全文ではありません。細かい技術や案件は後ろへ回し、「どのような人か」を短時間で把握できる長さにします。
案件概要の書き方
案件名をそのまま書けない場合でも、業界・対象・目的を組み合わせれば説明できます。
弱い例
Webサイト制作を担当。
伝わりやすい例
新卒向け就職支援サービスのキャンペーンサイト新規制作。イベント内容を伝え、申込みページへ誘導することを目的としたLPを担当。
案件名を公開できない場合
- 金融系企業のアプリ紹介LP
- 保険会社のサービス紹介サイト
- 教育系企業の採用・サービスサイト
- クラウドサービスの機能紹介ページ
- 社内イベントの紹介サイト
企業名を伏せても、業界・サイトの種類・目的が分かれば経験を判断しやすくなります。
担当範囲の書き方
「制作を担当」だけでは、デザイン・実装・進行のどこを担当したか分かりません。
工程を分けて書きます。
工程の例
- デザインカンプ・仕様の確認
- HTML・CSS・Sassによるコーディング
- PC・タブレット・スマートフォンのレスポンシブ対応
- JavaScriptによるメニュー、モーダル、タブ、アニメーション実装
- Astro・Reactなどを使ったコンポーネント実装
- 既存ページへの追加・改修
- CMS・テンプレートへの組み込み
- ブラウザ・端末での表示確認
- Gitを使った差分管理とレビュー対応
- 公開後の運用・保守
記載例
支給されたデザインカンプをもとに、PC・スマートフォン向けのコーディングを担当。共通ヘッダー、カード、CTAをコンポーネント化し、JavaScriptでナビゲーションとスクロール演出を実装しました。実装後は主要ブラウザと複数画面幅で表示・操作を確認し、デザイナーのレビューを受けて調整しました。
担当外の工程も明記すると信頼性が上がります。
デザインは別担当者が制作し、フロントエンド実装以降を担当。
使用技術は「用途」とセットで書く
技術一覧は検索や選考の判断材料になるため必要ですが、一覧だけでは経験の深さが分かりません。
技術一覧の例
| 分類 | 技術・経験 |
|---|---|
| マークアップ | HTML、セマンティックな見出し構造、フォーム |
| スタイル | CSS、Sass、レスポンシブ対応、既存CSSの改修 |
| JavaScript | UI実装、DOM操作、フォーム制御、スクロール演出 |
| フレームワーク | React、Vue、Astroなど実際に使用したもの |
| アニメーション | GSAP、CSSアニメーション |
| 開発環境 | Git、GitHub、npm、Vite、VS Code |
| デザイン連携 | Figma、Photoshop、画像書き出し |
| 品質確認 | ブラウザ確認、アクセシビリティ、表示速度、リンク確認 |
案件内での記載例
Astroで共通レイアウトとカードをコンポーネント化し、記事追加時の修正箇所を減らしました。GSAPはスクロールに連動する演出へ使用し、表示タイミングと過剰な動きを調整しました。
技術名を多く見せるために、教材で少し触っただけのものを実務経験へ含めてはいけません。実務、個人制作、学習中を分けます。
経験年数・習熟度の表現
経験年数は便利ですが、案件によって使用頻度が異なるため、数字だけで判断しにくいことがあります。
おすすめは、次の情報を併記することです。
- 初めて使用した時期
- 実務で使用した案件数・期間
- 直近で使用した時期
- 何を実装できるか
- レビューを受けながらか、単独で担当できるか
記載例
JavaScript：実務で複数のWebサイトに使用。ナビゲーション、モーダル、タブ、フォーム制御、スクロール演出の実装と既存コードの改修を経験。
「上級」「80％」のような独自の評価だけでは基準が伝わりません。具体的な作業へ置き換えます。
工夫・成果の書き方
売上やCV率の数字を持っていない案件でも、書ける成果はあります。
数字がなくても書けること
- 共通化して修正箇所を減らした
- 長い文言や複数画面幅で崩れにくくした
- 既存コードのルールへ合わせた
- デザイナーとの認識違いを早い段階で解消した
- 再利用できるコンポーネントへ整理した
- 画像サイズや読み込みを見直した
- キーボード操作や見出し構造を改善した
- 公開後の更新方法を分かりやすくした
PREPで書く
- 課題
- 対応
- 理由・判断
- 結果
記載例
カード内のCTA文言が端末幅によって不自然に折り返していたため、意味のまとまりで改行できる構造へ変更しました。2行表示でも高さがそろうように最小高さと上下余白を調整し、比較カード全体の視線の流れを整えました。
大きな成果を作るのではなく、実際に判断したことを具体的に書きます。
人数・ページ数・成果を覚えていない場合
分からない数字を推測で埋める必要はありません。
避けたい書き方
- 実際には確認できないチーム人数を書く
- 正確でないページ数を断定する
- 効果測定をしていないのに「売上を向上」と書く
- 自分以外の成果を自分の実績として書く
代わりの表現
| 不明な項目 | 書き方の例 |
|---|---|
| ページ数 | 複数ページのサイト、担当した主要ページ名を列挙 |
| チーム人数 | ディレクター・デザイナー・エンジニアと連携 |
| 制作期間 | 確認できる場合のみ年月を記載。難しければ省略 |
| 数値成果 | 実装・品質・運用面で行った改善を記載 |
| 担当割合 | 自分が担当した工程と対象を具体的に記載 |
概算を使う場合は、根拠があり、誤解を生まない範囲で「約」を付けます。
守秘義務がある案件の書き方
公開できない情報がある場合、提出先が限定された資料でも企業のルールを守ります。
伏せる可能性がある情報
- 企業名・サービス名
- 未公開機能
- 管理画面・社内システムの画面
- 売上、ユーザー数、予算
- 顧客固有のコードや設計
- 契約条件
記載例
金融系企業のサービス紹介サイトにて、デザインカンプからのフロントエンド実装を担当。企業名と画面は非公開ですが、レスポンシブ対応、JavaScriptによるUI実装、公開前の表示確認を担当しました。
伏せた結果、何をしたか分からなくならないよう、業界・サイト種類・担当工程・技術は可能な範囲で残します。
異業種からのキャリアチェンジを強みに変える
前職がエンジニア以外でも、仕事内容とつながる経験があります。
ゲームプランナーからフロントエンドエンジニアへ転職した場合、次のような経験を整理できます。
- 仕様を文章や画面で整理した経験
- デザイナー・エンジニアとの認識合わせ
- スケジュールと進捗の管理
- 不具合や要望の優先順位付け
- ユーザー視点での操作確認
- 関係者へ分かりやすく説明する力
ただし、「コミュニケーション能力があります」だけでは抽象的です。
記載例
前職のゲームプランナーでは、仕様作成、進行管理、デザイナー・エンジニアとの調整を経験しました。現在のWeb制作でも、デザイン意図や実装条件を早い段階で確認し、認識違いによる手戻りを減らすことを意識しています。
前職経験を現在の行動へつなげます。
案件ごとの記載テンプレート
次の形式を複製して使えます。
案件名・概要
〇〇業界の〇〇サイト新規制作。〇〇を目的としたページ・機能を担当。
期間
YYYY年MM月〜YYYY年MM月
役割・担当工程
- デザイン・仕様確認
- フロントエンド実装
- レスポンシブ対応
- JavaScript実装
- テスト・レビュー対応
- 公開・運用支援
使用技術
HTML / CSS / Sass / JavaScript / React / Astro / GSAP / Git など、実際に使ったもの
連携
ディレクター、デザイナー、バックエンドエンジニアなど
工夫・改善
課題、対応したこと、判断した理由、確認結果
スキルシートの構成例
| セクション | 内容 |
|---|---|
| 基本情報 | 希望職種、稼働開始日、働き方、資格など |
| サマリー | 経験領域と強みを3〜5行で要約 |
| 技術一覧 | 分類、使用期間、実務・個人制作の区分、できること |
| 案件経歴 | 期間、概要、担当、技術、環境、工夫 |
| 自己PR | 仕事の進め方、連携、継続して伸ばしていること |
| 希望条件 | 職種、担当領域、稼働、勤務地など必要な場合のみ |
エージェント指定の書式がある場合は、その形式を優先します。自分の元データからコピーできるようにしておけば、書式が変わっても対応しやすくなります。
職務経歴書の構成例
- 職務要約
- 活かせる経験・知識・技術
- 会社ごとの職務経歴
- 案件・プロジェクト実績
- 保有資格
- 自己PR
フロントエンド職では、「会社で何をしていたか」だけでなく、案件ごとの役割が重要です。会社単位の説明の中に、代表的なプロジェクトを入れます。
ポートフォリオとの内容をそろえる
ポートフォリオと応募書類は、同じ経験を別の角度から見せる資料です。
| ポートフォリオ | スキルシート・職務経歴書 |
|---|---|
| 完成画面を見せる | 担当工程と技術経験を説明する |
| 工夫を図や文章で詳しく見せる | 複数案件を同じ形式で比較できるようにする |
| 公開可能な作品が中心 | 非公開案件も担当内容を文章で整理できる |
| 応募先に近い作品を先に置く | 直近・関連性の高い経歴を読みやすくする |
作品説明の作り方は、フロントエンドエンジニアのポートフォリオの作り方で詳しく整理しています。
同じ案件について、ポートフォリオでは「デザインと動作」、スキルシートでは「期間・担当・技術」が一致しているか確認します。
よくある弱い書き方
技術名だけを大量に並べる
何ができるか分からないため、実装内容を添えます。
「チームで制作した」だけで終わる
自分の担当工程と連携相手を書きます。
自己PRが性格の説明だけになる
「責任感があります」ではなく、どのような行動を取ったかを書きます。
すべての案件を同じ分量で書く
応募先に近い案件や直近案件を詳しくし、古い・関連性の低い案件は短くします。
学習経験を実務経験として書く
個人制作・学習・実務を明確に分けます。
読み手に判断を委ねすぎる
「幅広く対応」ではなく、担当できる工程を明記します。
60分で初稿を作る手順
0〜10分：案件を時系列で並べる
会社名、期間、業界、サイト種類だけを書きます。
10〜25分：担当工程をチェックする
デザイン確認、HTML・CSS、JavaScript、レスポンシブ、レビュー、公開、運用などを案件ごとに選びます。
25〜40分：技術と工夫を1つずつ書く
各案件に、技術の用途と判断したことを最低1つ入れます。
40〜50分：職務要約を書く
案件を見渡して、共通する経験と強みを3〜5行へまとめます。
50〜60分：誇張と矛盾を確認する
期間、技術、担当範囲、ポートフォリオとの一致を確認します。
最初から美しい文章にせず、まず表を埋めると進みやすくなります。
提出前チェックリスト
内容
- 職務要約だけで現在の職種と経験領域が分かる
- 案件ごとにサイト・サービスの目的が分かる
- 自分の担当工程と担当外が区別されている
- 技術名に用途や実装内容が添えられている
- 実務・個人制作・学習中が区別されている
- 不明な数字を推測で埋めていない
- 守秘義務や公開範囲を守っている
読みやすさ
- 日付表記と技術名の表記が統一されている
- 1案件の情報量が極端にばらついていない
- 重要な案件が前半にある
- 誤字・リンク切れがない
- PDFにしたとき表や見出しが途中で崩れていない
応募先との一致
- 募集要件に近い技術・案件が見つけやすい
- ポートフォリオと担当範囲が矛盾していない
- 希望条件が現実の経歴と合っている
- 面談で各項目を自分の言葉で説明できる
まとめ
フロントエンドエンジニアのスキルシート・職務経歴書では、技術の多さより、案件の目的・担当工程・技術の用途・連携・判断したことを明確にすることが重要です。
- まず全案件の元データを表へまとめる
- 1案件を6項目で説明する
- 技術名は実装内容とセットで書く
- 分からない数字は推測しない
- 非公開案件も業界・担当・技術の範囲で説明する
- 前職の経験は現在の行動へつなげる
- ポートフォリオと内容を一致させる
書類を作り終えたら、フロントエンド向けフリーランス案件サービス3社の比較で相談先を比較できます。登録後の質問や希望条件まで準備する場合は、フリーランスエージェントの面談対策へ進みましょう。まだ実績の整理から始めたい場合は、スキルなしから個人で仕事を始めるロードマップへ戻って現在地を確認してください。