20代SE(システムエンジニア)の職務経歴書|転職成功のポイントと例文
- 20代SEが採用担当者に評価される職務経歴書の書き方
- 経験が浅くても「即戦力候補」として見せる方法
- 担当フェーズ・使用技術・成長の軌跡を数字で伝えるコツ
- 書類が通らない20代SEに共通する失敗パターン
- 経験年数別(1〜2年・3〜4年・5年前後)の書き方の違い
- NG例・改善例つきで今日から使える例文
「SEとして実務経験は積んできたのに、職務経歴書に何を書けばいいかわからない」「担当フェーズが限られていて、上流工程の経験がないのでアピールしづらい」20代SEの転職活動でよく聞く悩みです。
20代SEの転職市場では「経験の深さ」より「成長の速さ」と「技術習得のポテンシャル」が評価されます。しかし多くの20代が「まだ担当フェーズが狭い」「大規模案件を経験していない」と思い込み、自分を過小評価した職務経歴書を書いてしまっています。
採用担当者が20代SEに期待しているのは「完成されたエンジニア」ではありません。「担当してきた技術領域の明確さ」「成長の速さ」「周囲と協働できる素地」です。この3点を職務経歴書で伝えられれば、経験が浅くても十分に評価されます。
採用担当は何を見ている?
20代SEの採用担当者が職務経歴書で確認しているのは、主に次の3点です。
| 観点 | 内容 |
| 使える技術スタックの明確さ | 担当してきたプログラミング言語・フレームワーク・DB・クラウドを確認している。20代では「幅広く使える」より「この技術なら即戦力」と言える領域があることが評価される |
| 担当フェーズと成長の軌跡 | 要件定義・基本設計・詳細設計・実装・テスト・運用のどのフェーズを担当してきたかを確認している。「1年目は実装中心→2年目から基本設計も担当」のような成長の変化が書いてあると評価が高まる |
| チーム内での立ち位置・協働経験 | レビュー対応・ペアプロ・ドキュメント作成・他部署調整など、一人で閉じた作業ではなく組織で動ける素地があるかを見ている |
よくある失敗(書類が通らない人に共通する3つのパターン)
パターン①:プロジェクト名とフェーズの羅列で終わっている
「プロジェクト○○:Java・Spring Boot、担当:実装・単体テスト」という記述を並べるだけでは、採用担当者には何も伝わりません。そのプロジェクトの規模(チーム人数・開発期間・扱ったデータ量)、自分が担当した機能の具体性、工夫した点が書かれて初めて評価材料になります。
パターン②:使用技術を並べるだけで習熟度が伝わらない
「Java・Python・JavaScript・SQL・AWS」と並べるだけでは、どの技術がどの程度使えるのかが判断できません。「Java(業務で3年・Spring Boot使用のAPI開発が中心)」「Python(業務で1年・データ処理スクリプト)」「AWS(ECS・RDS・S3を用いた本番環境構築経験あり)」のように習熟レベルと使用場面をセットで書くことが重要です。
パターン③:「担当した」で終わり、工夫や判断が見えない
20代SEで最も差がつくのは「何をやったか」より「どう考えて動いたか」です。「テストコードを整備した」だけでなく「既存プロジェクトにテストがなくリグレッションが頻発していたため、まず主要機能から単体テストを追加。テストカバレッジを0%から55%に引き上げた」のような判断の流れが書けるかが評価の分かれ目です。
書き方のポイント|20代SEならではの伝え方
ポイント①:「業務での使用期間と使用場面」を技術ごとに明記する
「Java(業務3年・Spring BootでのREST API開発)」「Python(業務1年・データ集計スクリプト作成)」「AWS(ECS・RDS・S3・CloudWatch の構築・運用経験あり)」のように、技術ごとに期間と使用場面を書くことで採用担当者が即戦力度を判断できます。
ポイント②:担当フェーズの変化を時系列で書く
「1年目:既存機能の改修・バグ修正中心。2年目:新機能の詳細設計・実装を担当。3年目:基本設計・顧客レビューへの参加・後輩へのコードレビューも担当」のように、入社時からの変化を書くことで成長スピードが伝わります。
ポイント③:技術面の「工夫・判断」を具体的に書く
20代SEで評価を左右するのは「自分で考えて動いた経験」です。「レスポンスタイムが3秒→0.8秒に改善(N+1クエリの解消と Redis キャッシュ導入)」「テストコードがなかったプロジェクトで単体テストを整備(カバレッジ 0%→55%)」のように、技術的な判断と成果をセットで書きましょう。
20代SEならではの悩みに答える
「SIer からWeb系への転職でアピールできるか不安」
SIer での「要件定義・設計書作成・顧客折衝・品質管理」の経験は、Web系でも「ユーザー要件の整理・仕様書の読解力・チーム内ドキュメント整備」として評価されます。反対に Web系特有の「開発サイクルの速さ・モダンな技術スタック」への適応力を示すために、個人開発・GitHub公開リポジトリ・技術記事の投稿などがあれば併記すると好印象です。
「担当してきた技術が古い場合、どうアピールすればいい」
古い技術だけでなく「基礎的なプログラミング能力・設計の考え方」はどの技術でも通用します。「Java/Struts での開発経験を通じて MVC アーキテクチャ・OOP の基礎を身につけた。現在は Spring Boot と React を独学で学習中」のように、過去の経験から学んだ本質と、現在の学習意欲を併記することで転換力をアピールできます。
例文
例①:Web系エンジニア(経験1年半・第二新卒)
従業員数約150名のWeb系事業会社(自社SaaSプロダクト開発)にて、バックエンドエンジニアとして勤務。開発チーム6名体制で、主要プロダクト(BtoB向け業務管理SaaS)のAPI開発を担当。
【業務内容】
・BtoB向け業務管理SaaSの API 開発(Ruby on Rails / PostgreSQL)
・新機能の詳細設計・実装・単体テスト
・既存コードのリファクタリング・パフォーマンス改善
・GitHub でのコードレビュー(週平均5〜8件対応)
・顧客からの不具合報告の調査・原因特定・修正
【実績】
・担当した主要新機能3件を予定納期内でリリース(累計開発工数:約180人日)
・API レスポンスタイムの改善:主要エンドポイントで平均 1.2秒 → 0.4秒に短縮(N+1 クエリ解消による)
・単体テストの整備:既存コードに対するテストカバレッジを 15% → 58% に向上
・チーム内コードレビューで主要な品質指摘者の一人として定着
・入社1年目に社内「新人MVP」を受賞
【主な取り組み】
入社時に既存コードのテストがほぼ整備されていない状態だったため、主要機能から優先度をつけて単体テストを追加した。テスト追加の過程で「N+1 クエリが複数箇所で発生している」ことに気づき、bullet gem を導入してチーム全体で検出可能な仕組みに変更。これが API レスポンス改善につながった。コードレビューでは「なぜそのコードにしたか」をコメントで残すルールを自発的に提案し、ジュニアメンバーの理解促進に貢献した。
自己PRでのアピールポイント
実装スピードだけでなく「品質」「パフォーマンス」「チームへの共有」のバランスを意識して動く姿勢が強み。入社1年半で既存コードベースの改善から新機能開発まで担当範囲を広げてきた経験を活かし、次の職場でもプロダクト品質と開発効率の両立に貢献したい。
例②:SES・業務系SE(経験3年・中堅手前)
従業員数約500名のSESベンダーに所属し、金融系・流通系の大手企業向け業務システム開発案件に参画。直近は大手保険会社の契約管理システム再構築プロジェクト(チーム15名・開発期間18ヶ月)に常駐。
【業務内容】
・Java(Spring Boot)・Oracle Database を用いた契約管理システムの実装・単体テスト
・基本設計書・詳細設計書のレビュー対応(2年目以降)
・結合テスト計画の作成・テスト実施(自担当モジュール)
・本番リリース時の作業計画策定・夜間リリース作業の実施
・顧客側担当者との進捗報告・仕様確認のミーティング(3年目以降)
【実績】
・担当モジュール3つの詳細設計・実装・単体テストを予定工数内で完遂
・バグ密度:自分の担当モジュールで平均 0.4 件/KL(チーム平均 0.8件/KL)
・結合テスト工程でのリグレッション検出数ゼロを3期連続で達成
・夜間リリース作業を通算12回リード担当し、全件で計画時間内に完了
・プロジェクト後半から後輩SE2名へのコードレビューを担当
【主な取り組み】
バグ密度を下げるために「コーディング前にテスト観点を先に書き出す」習慣をつけた。実装着手前に想定される異常系・境界値をリスト化してから実装に入ることで、単体テストのカバレッジを担保しやすい設計が自然にできるようになった。この習慣を後輩にも共有することで、チーム全体のバグ密度改善にも寄与した。夜間リリース作業では手順書に「想定外事態発生時の切り戻し判断フローチャート」を追加することを提案し、トラブル時の判断時間短縮に貢献した。
自己PRでのアピールポイント
業務システム開発での3年間の経験で、基本設計〜本番リリースまでの全フェーズを担当してきた。特に「品質を担保するための事前設計」を意識した働き方で、バグ密度ゼロ・リグレッションゼロを継続してきた。次の職場ではWeb系モダンスタックでのキャッチアップも進めつつ、これまでの品質意識を活かして貢献したい。
例③:Web系エンジニア・リーダー候補(経験5年・20代後半)
従業員数約80名のスタートアップ(BtoC向けマッチングサービス)にて、Web系エンジニアとして勤務。開発チーム10名体制。直近2年はサブリーダーとしてジュニアメンバー3名の技術指導とスプリント計画の補助を担当。
【業務内容】
・Next.js + TypeScript によるフロントエンド開発
・Node.js (Express) + PostgreSQL によるバックエンド API 開発
・AWS(ECS Fargate・RDS・S3・CloudFront)でのインフラ構築・運用
・GitHub Actions での CI/CD パイプライン整備
・サブリーダーとしてスプリント計画・タスク分解・コードレビュー統括(4年目以降)
【実績】
・主要機能リリース:担当した主要機能7件をすべて予定スプリント内でリリース
・サービス全体のパフォーマンス改善:Core Web Vitals(LCP)を 4.2秒 → 1.6秒に短縮
・インフラコスト削減:ECSタスクサイズの最適化により月額AWSコストを約35%削減
・新人エンジニア3名のオンボーディング:独り立ちまでの期間を従来3ヶ月→6週間に短縮
・GitHub Actions の導入により、デプロイ時間を手動30分→自動8分に短縮
【主な取り組み】
サブリーダーとして「なぜそのコードにしたか」「なぜその設計を選んだか」を言語化する習慣をチームに広げた。レビューコメントに判断基準を書き残すことで、ジュニアメンバーが自走できるようになるまでの期間が短くなった。パフォーマンス改善では感覚で手を入れず、Lighthouse・Chrome DevTools・Sentry でのパフォーマンス計測を前後比較できる形で残すことを徹底した。
自己PRでのアピールポイント
実装・インフラ・チーム貢献の3領域を並行して担ってきた経験があり、技術的な判断とチームへの還元を両立できる点が強み。次の職場では、プロダクトの技術基盤整備と、若手エンジニアの育成を通じて、チーム全体のエンジニアリング品質を引き上げることに貢献したい。
書き方ステップ
① これまでの担当プロジェクトと使用技術をすべて書き出す
プロジェクト名・期間・チーム人数・使用技術(言語・フレームワーク・DB・クラウド・ツール)・担当フェーズ・担当した機能を思い出せるだけ書き出します。「アピールになるか」はこの段階では考えなくてOKです。
② 行動量・処理量の数字を探す
対応チケット数・実装した機能数・コードレビュー件数・バグ修正件数・リリース回数など、数字で示せる活動量を書き出します。20代では「量」もアピールポイントになります。
③ 成長の軌跡を時系列で整理する
「1年目はこの技術でこの工程だけ担当→2年目からこの工程も担当→3年目でこの役割を任された」のように、入社時から現在までの担当変化を時系列で整理します。これが20代の成長スピードを証明する核心になります。
④ 業務内容・実績・主な取り組みを3ブロックで整理する
「何をしていたか(業務内容)」「どんな成果が出たか(実績)」「なぜその成果が出たか(主な取り組み)」の3ブロックに分けて整理します。数字は実績に、技術的な判断・工夫は取り組みに書く切り分けを意識してください。
⑤ 転職理由と今後の方向性を前向きに書く
「なぜ今転職するか」「次の職場でどんな技術・役割に挑戦したいか」を前向きな言葉で整理します。20代の転職理由は「ポテンシャルを活かせる環境への挑戦」として書きましょう。
NG例 → 改善例|通らない書き方の直し方
失敗①:技術スタックの羅列で終わっている
失敗②:プロジェクト記述が薄い
失敗③:成長の軌跡が見えない
失敗④:工夫や判断が書かれていない
経験年数別アドバイス
経験1〜2年(第二新卒・若手)
「担当してきた技術スタック」と「短期間での担当範囲の拡大」が最大のアピールポイントです。まだ担当フェーズが限られていても「入社○ヶ月で○○を任された」「担当モジュールが○件→○件に増えた」という変化を書くことで成長速度が伝わります。転職理由は「ポテンシャルを活かせる環境への挑戦」として前向きに書きましょう。
経験3〜4年(中堅手前)
「担当フェーズの広がり」「バグ密度・品質指標の数字」「設計レビューへの参加経験」が評価の軸になります。実装中心だった1〜2年目から、基本設計・レビュー・顧客折衝へと担当範囲が広がっている様子を時系列で書くことで、中堅候補として見てもらえます。
経験5年前後(20代後半)
「サブリーダー・リーダーとしてのチーム貢献」「インフラ・CI/CD 整備などプロジェクト基盤への貢献」「後輩指導・オンボーディング改善」が評価の軸になります。30代に近づくにつれ「個人の実装スピード」より「チーム全体の開発効率を高めた経験」が求められ始めます。
よくある質問
まとめ
- 採用担当者は20代SEに「完成されたエンジニア像」ではなく「成長スピード」と「技術習得のポテンシャル」を求めている
- 使用技術は「期間と使用場面」をセットで書き、習熟度が判断できるようにする
- 担当フェーズの変化(1年目→現在)を時系列で書くことで成長の軌跡を伝える
- プロジェクトの規模感(チーム人数・期間・データ量)を必ず明記する
- 「なぜその技術的判断をしたか」の工夫を書くことで再現性をアピールする
- 経験年数に応じて「行動量と担当拡大」「バグ密度・品質」「サブリーダー・基盤貢献」を使い分ける
20代SEの経験は「伸びしろ」と「技術適応力の証明」として必ず評価されます。まずは担当してきたプロジェクト・使用技術・担当フェーズの変化・自分が工夫したポイントを書き出すところから始めてみてください。

