20代Webエンジニアの職務経歴書|採用担当が見るポイントと書き方
- 20代Webエンジニアが採用担当者に評価される職務経歴書の書き方
- 経験が浅くても「即戦力候補」として見せる方法
- フロント・バックエンド・インフラなど担当領域別の伝え方
- 個人開発・OSS貢献・技術記事を活かす方法
- 経験年数別(1〜2年・3〜4年・5年前後)の書き方の違い
- NG例・改善例つきで今日から使える例文
「Webエンジニアとして実務経験は積んできたのに、職務経歴書に何を書けばいいかわからない」「担当範囲が一部のフロントエンドだけで、フルスタックでないとアピールしづらい」20代Webエンジニアの転職活動でよく聞く悩みです。
20代Webエンジニアの転職市場では「経験の深さ」より「成長の速さ」「技術習得のポテンシャル」「チームで動ける素地」が評価されます。しかし多くの20代が「まだ大規模サービスを担当していない」「アーキテクチャ設計の経験がない」と思い込み、自分を過小評価した職務経歴書を書いてしまっています。
採用担当者が20代Webエンジニアに期待しているのは「完成されたエンジニア」ではありません。「使える技術スタックの明確さ」「成長の速さ」「PM・デザイナー・他エンジニアと協働できる姿勢」です。この3点を職務経歴書で伝えられれば、経験が浅くても十分に評価されます。
採用担当は何を見ている?
20代Webエンジニアの採用担当者が職務経歴書で確認しているのは、主に次の3点です。
| 観点 | 内容 |
| 使える技術スタックの明確さ | 担当してきた言語・フレームワーク・DB・クラウド・ツールを確認している。20代では「幅広く使える」より「この技術なら即戦力で動ける」と言える領域があることが評価される |
| 担当フェーズと成長の軌跡 | 要件定義・設計・実装・テスト・運用のどのフェーズを担当してきたかを確認している。「1年目は実装中心→2年目から設計も担当→3年目でレビューもする」のような変化が書いてあると評価が高まる |
| チーム内の動き方・協働経験 | レビュー対応・ペアプロ・ドキュメント作成・PM/デザイナーとの調整など、一人で閉じた作業ではなくチームで動ける素地があるかを見ている |
よくある失敗(書類が通らない人に共通する3つのパターン)
パターン①:プロジェクト名と技術名の羅列で終わっている
「プロジェクト○○:React・Node.js、担当:実装」という記述を並べるだけでは、採用担当者には何も伝わりません。プロジェクトの規模(チーム人数・MAU・ユーザー数・データ量)、自分が担当した機能の具体性、工夫した点が書かれて初めて評価材料になります。
パターン②:使用技術を並べるだけで習熟度が伝わらない
「JavaScript・TypeScript・React・Vue・Next.js・Node.js・PostgreSQL・AWS」と並べるだけでは、どの技術がどの程度使えるのかが判断できません。「TypeScript(業務2年・Next.js でのSSR/ISR実装中心)」「Node.js(業務2年・Express/NestJS でのAPI開発)」「AWS(ECS・RDS・S3・Lambda の構築・運用経験あり)」のように習熟レベルと使用場面をセットで書くことが重要です。
パターン③:「担当した」で終わり、判断や工夫が見えない
20代Webエンジニアで最も差がつくのは「何をやったか」より「どう考えて動いたか」です。「テストコードを整備した」だけでなく「既存プロジェクトにテストがほぼなく、リリース後の障害が頻発していた。主要機能から優先順位をつけて Vitest によるユニットテストを追加。テストカバレッジを5%→62% に引き上げ、リリース後障害件数を四半期比で約60%削減」のような判断と成果のセットが書けるかが評価の分かれ目です。
書き方のポイント|20代Webエンジニアならではの伝え方
ポイント①:「業務での使用期間と使用場面」を技術ごとに明記する
「TypeScript(業務2年・Next.js での画面実装が中心)」「Node.js(業務2年・Express を用いた REST API 開発)」「AWS(ECS Fargate・RDS・S3・CloudWatch の構築・運用経験あり)」のように、技術ごとに期間と使用場面を書くことで採用担当者が即戦力度を判断できます。
ポイント②:担当フェーズの変化を時系列で書く
「1年目:既存機能の改修・バグ修正中心。2年目:新機能の詳細設計・実装を担当。3年目:基本設計・PMとの仕様調整・後輩のコードレビューも担当」のように、入社時からの変化を書くことで成長スピードが伝わります。
ポイント③:個人開発・OSS貢献・技術発信を書く
20代Webエンジニアで強い差別化要素になるのが「業務外での学習・発信」です。GitHub の公開リポジトリ・技術記事(Zenn・Qiita・はてなブログ)・OSS への小さな PR ・個人開発したサービスの URL を職務経歴書に書きましょう。「業務時間外でも自発的に手を動かしている」シグナルは20代の評価で大きく加点されます。
20代Webエンジニアならではの悩みに答える
「SES・受託から自社サービスへの転職でアピールできるか不安」
SES・受託での「複数業界・複数プロジェクト経験」は「適応力・キャッチアップ速度」として評価されます。ただし自社サービスでは「一つのプロダクトに長期で関わる執着」が求められるため、自己PR欄で「一つのプロダクトに深く関わって長期で価値を出したい」という方向性を明確に書きましょう。応募先で使う技術スタック(モダンWeb系のTypeScript・Next.js・Reactなど)の自主学習をしている事実も併記しましょう。
「フロント中心 / バックエンド中心しか経験がない」
特化している経験は「その領域なら即戦力で動ける」という強みとして書けます。「フロントエンドの実装を3年やってきたのでReact・Next.js・状態管理・パフォーマンス最適化なら任せられる。直近はバックエンドの基礎学習として Node.js + PostgreSQL の個人開発に取り組み中」のように、強みと学習意欲をセットで書きましょう。
例文
例①:自社Web系エンジニア(経験1年半・第二新卒)
従業員数約120名のBtoB SaaS企業(自社プロダクト:マーケティング自動化ツール)にて、フロントエンドエンジニアとして勤務。開発チーム10名(フロント3名・バックエンド5名・SRE2名)。担当:管理画面UIとレポーティング機能。
【業務内容】
・管理画面UIの新機能実装(TypeScript / React / Next.js)
・レポーティング機能のフロント側実装(Recharts・TanStack Query)
・既存コードのリファクタリング・パフォーマンス改善
・GitHub 上でのコードレビュー(週平均8〜10件対応)
・デザイナーとの実装可否ディスカッション・PMとの仕様調整
【実績】
・担当した主要新機能5件をすべて予定スプリント内でリリース
・管理画面の主要ページの LCP を 4.1秒→1.6秒に改善(Code Splitting・画像最適化による)
・単体テスト(Vitest)の整備:担当領域のテストカバレッジを5%→62%に向上
・リリース後障害件数:自分の担当機能で四半期比約60%削減
・入社1年目に社内「ベストルーキー賞」を受賞
【主な取り組み】
入社時に管理画面のテストがほぼ整備されておらず、リリース後に細かい不具合が頻発していた。主要機能から優先順位をつけて Vitest と React Testing Library によるユニットテスト・コンポーネントテストを追加。テスト追加の過程で「コンポーネントの責務が肥大化している」ことに気づき、PMと相談しながら段階的なリファクタリングを実施した。パフォーマンス改善では Chrome DevTools・Web Vitals での計測を前後比較できる形で残し、改善内容をドキュメント化してチーム全体に共有した。
【業務外活動】
・GitHub:個人開発した家計簿アプリ(Next.js + Supabase)を公開・スター数約120
・Zennで月1〜2本の技術記事を執筆(直近1年で18本・累計閲覧数約4万)
自己PRでのアピールポイント
実装スピードだけでなく品質・パフォーマンス・チームへの共有のバランスを意識して動く姿勢が強み。入社1年半で既存コードの改善から新機能開発まで担当範囲を広げてきた経験を活かし、次の職場でもプロダクト品質と開発効率の両立に貢献したい。
例②:受託開発・Webエンジニア(経験3年・中堅手前)
従業員数約400名のWeb制作・開発会社にて、バックエンドエンジニアとして勤務。中規模Webサービス(月間PV 100万〜1,000万規模)の受託開発案件に参画。直近3案件は基本設計から実装まで一貫して担当。
【業務内容】
・Ruby on Rails・PHP(Laravel)でのWebアプリケーションのバックエンド開発
・API 設計・DB 設計(PostgreSQL・MySQL)・インフラ構築(AWS)
・クライアント向け定例ミーティングでの仕様確認・進捗報告
・結合テスト計画の作成・テスト実施
・後輩エンジニア2名のコードレビュー(3年目以降)
【実績】
・担当案件:3年間で大小合わせて12件・うち7件で基本設計から担当
・API レスポンスタイムの改善:主要エンドポイントで平均 1.8秒→0.5秒に短縮
・担当案件の本番リリース後の重大障害件数:通算ゼロを継続
・バグ密度:自分の担当モジュールで平均 0.3件/KL(社内平均 0.7件/KL)
・後輩2名のレビュー対応:担当案件のコードクオリティを3年でチーム平均以上に維持
【主な取り組み】
受託開発で最も重要だったのは「クライアントの曖昧な要望を技術仕様に翻訳する」ことだった。仕様確認時には「業務フロー図 → 機能一覧 → API設計」の3層で資料を作成し、クライアント・PM・自分の3者で認識合わせを行う運用を確立した。これにより仕様の手戻りを大幅に削減できた。バグ密度の低さは、コーディング前にテスト観点を先にリスト化する習慣が主因で、この習慣を後輩にも展開してチーム全体の品質改善に寄与した。
自己PRでのアピールポイント
受託開発での3年間の経験で、要件定義から本番リリースまでの全フェーズを担当してきた。「要件と仕様のずれを早期に潰す」働き方で、品質と納期の両立を継続してきた。次の職場ではWeb系自社サービスでのモダン技術スタックでの開発に挑戦し、これまでの品質意識を活かして貢献したい。
例③:Web系エンジニア・サブリーダー候補(経験5年・20代後半)
従業員数約100名のスタートアップ(BtoC向けマッチングサービス)にて、Web系エンジニアとして勤務。開発チーム10名体制。直近2年はサブリーダーとしてジュニアメンバー3名の技術指導とスプリント計画の補助を担当。
【業務内容】
・Next.js + TypeScript によるフロントエンド開発
・Node.js (NestJS) + PostgreSQL によるバックエンド API 開発
・AWS(ECS Fargate・RDS・S3・CloudFront)でのインフラ構築・運用
・GitHub Actions での CI/CD パイプライン整備
・サブリーダーとしてスプリント計画・タスク分解・コードレビュー統括(4年目以降)
【実績】
・主要機能リリース:担当した主要機能8件をすべて予定スプリント内でリリース
・サービス全体のパフォーマンス改善:Core Web Vitals(LCP)を 4.2秒→1.5秒に短縮
・インフラコスト削減:ECSタスクサイズ最適化により月額AWSコストを約35%削減
・新人エンジニア3名のオンボーディング:独り立ちまでの期間を従来3ヶ月→6週間に短縮
・GitHub Actions の整備により、デプロイ時間を手動30分→自動8分に短縮
【主な取り組み】
サブリーダーとして「なぜそのコードにしたか」「なぜその設計を選んだか」を言語化する習慣をチームに広げた。レビューコメントに判断基準を書き残すことで、ジュニアメンバーが自走できるようになるまでの期間が短くなった。パフォーマンス改善では感覚で手を入れず、Lighthouse・Chrome DevTools・Sentry でのパフォーマンス計測を前後比較できる形で残すことを徹底した。
自己PRでのアピールポイント
実装・インフラ・チーム貢献の3領域を並行して担ってきた経験があり、技術的判断とチームへの還元を両立できる点が強み。次の職場ではプロダクトの技術基盤整備と、若手エンジニアの育成を通じて、チーム全体のエンジニアリング品質を引き上げることに貢献したい。
書き方ステップ
① これまでの担当プロジェクトと使用技術をすべて書き出す
プロジェクト名・期間・チーム人数・使用技術(言語・フレームワーク・DB・クラウド・ツール)・担当フェーズ・担当した機能を書き出します。
② 行動量・処理量の数字を探す
対応チケット数・実装した機能数・コードレビュー件数・バグ修正件数・リリース回数など、数字で示せる活動量を書き出します。20代では行動量もアピールポイントになります。
③ 担当領域の成長軌跡を時系列で整理する
「1年目はこの技術でこの工程だけ担当→2年目からこの工程も担当→3年目でこの役割を任された」のように、入社時から現在までの担当変化を時系列で整理します。20代の成長スピードを示す核心です。
④ 個人開発・OSS貢献・技術発信を整理する
GitHub・Zenn・Qiita・はてなブログ・登壇実績などを整理します。URLや具体的な記事数・閲覧数を併記すると説得力が増します。
⑤ 業務内容・実績・主な取り組みを3ブロックで整理する
「何をしていたか」「どんな成果が出たか」「なぜ成果が出たか」の3ブロックに分けて整理します。技術判断・工夫は取り組みブロックに書きましょう。
NG例 → 改善例|通らない書き方の直し方
失敗①:技術スタックの羅列
失敗②:プロジェクト記述が薄い
失敗③:成長の軌跡が見えない
失敗④:判断や工夫が書かれていない
経験年数別アドバイス
経験1〜2年(第二新卒・若手)
「担当してきた技術スタック」と「短期間での担当範囲の拡大」が最大のアピールポイントです。まだ担当フェーズが限られていても「入社○ヶ月で○○を任された」「担当モジュールが○件→○件に増えた」という変化を書くことで成長速度が伝わります。
経験3〜4年(中堅手前)
「担当フェーズの広がり」「バグ密度・品質指標の数字」「設計レビューへの参加経験」が評価の軸になります。実装中心だった1〜2年目から、基本設計・レビュー・PM・デザイナーとの調整へと担当範囲が広がっている様子を時系列で書くことで、中堅候補として見てもらえます。
経験5年前後(20代後半)
「サブリーダー・リーダーとしてのチーム貢献」「インフラ・CI/CD 整備などプロジェクト基盤への貢献」「後輩指導・オンボーディング改善」が評価の軸になります。30代に近づくにつれ「個人の実装スピード」より「チーム全体の開発効率を高めた経験」が求められ始めます。
よくある質問
まとめ
- 採用担当者は20代Webエンジニアに「成長スピード」と「技術習得のポテンシャル」を求めている
- 使用技術は「期間と使用場面」をセットで書き、習熟度が判断できるようにする
- 担当フェーズの変化(1年目→現在)を時系列で書くことで成長の軌跡を伝える
- プロジェクトの規模感(チーム人数・MAU・データ量)を必ず明記する
- 「なぜその技術的判断をしたか」の工夫を書くことで再現性をアピールする
- 個人開発・OSS貢献・技術発信を職務経歴書に書いて差別化する
20代Webエンジニアの経験は「伸びしろ」と「技術適応力」として必ず評価されます。まずは担当してきたプロジェクト・使用技術・担当フェーズの変化・自分が工夫したポイントを書き出すところから始めてみてください。

