スカウトの返信や求人への応募で「まずはレジュメを送ってください」と言われ、履歴書と職務経歴書のどちらを出せばよいか迷う人は少なくありません。レジュメという言葉は、会議の資料にも大学のゼミにも使われるため、転職の場面で何を指すのかがあいまいになりがちです。
国内の転職でのレジュメは、履歴書と職務経歴書の両方を指すことが多く、エンジニアの選考で中心になるのは職務経歴書です。エンジニアの場合、レジュメに何を書くかは求人の応募条件を手がかりに決められます。Offers が扱うエンジニア求人の応募条件から、レジュメに何をどう書けば選考で伝わるのかを整理しました。
レジュメの意味は「要約」で、転職では履歴書と職務経歴書を指す
レジュメ(résumé)はフランス語で「要約」を意味する言葉で、転職活動では経歴を要約した応募書類、つまり履歴書や職務経歴書を指します。会議や講義では話の要点をまとめた配布資料を、大学のゼミでは発表内容の要旨を指し、同じ言葉でも場面によって中身が変わります。
日本の中途採用で企業が「レジュメ」と言うときは、履歴書と職務経歴書の両方を指すことが多く、エンジニアなど技術系の採用では職務経歴書だけを指す場合もあるというのが、転職サイトや人事メディアの一般的な説明です。外資系企業や海外の企業では、履歴書と職務経歴書をまとめた1通の書類をレジュメと呼ぶこともあり、英語で書いた英文レジュメの提出を求められる場合があります。求人票やメールの文面だけで判断できないときは、「履歴書と職務経歴書の両方をお送りすればよいでしょうか」と確認すれば失礼になりません。
場面ごとにレジュメが指すもの
レジュメが指すものは、会議・学術・転職の3つの場面で異なります。
場面 | レジュメが指すもの | 主な中身 |
|---|---|---|
会議・プレゼン | 議題や論点をまとめた配布資料 | 日時・議題・論点・決めること |
大学のゼミ・講義 | 発表や講義の要旨 | 目的・要点・参考文献 |
転職(国内企業) | 履歴書と職務経歴書(技術系の採用では職務経歴書が中心) | 基本情報・学歴・職歴、職務要約・経験した業務・スキル・成果 |
転職(外資系・海外企業) | 履歴書と職務経歴書をまとめた英文の書類(resume/CV) | 職歴・スキル・学歴を英語で簡潔に |
会議用のレジュメは読み手が話の流れを追うための資料で、転職用のレジュメは読み手が「この人に任せられるか」を判断するための資料です。目的が違うので、書き方の型も別物と考えてください。
レジュメに含まれる履歴書と職務経歴書の違い
履歴書と職務経歴書の違いは、履歴書が氏名・学歴・職歴を決まった欄に書く基本情報の書類であるのに対し、職務経歴書は決まった様式がなく、仕事の中身と成果を自分で組み立てて書く書類だという点です。履歴書で「どこに何年いたか」を、職務経歴書で「そこで何をして、何ができるか」を伝えます。
履歴書には国が示す様式例があります。厚生労働省は2021年4月、日本規格協会が示していた日本産業規格(JIS)の履歴書の様式例が削除されたことを受けて、性別欄を任意記載にし、「配偶者」「扶養家族数」「配偶者の扶養義務」「通勤時間」の欄を設けない様式例を公表しました(厚生労働省「履歴書の様式例の作成について」・2021年4月16日)。この様式例に法的な拘束力はなく、どの様式を使うかは企業が判断します。
項目 | 履歴書 | 職務経歴書 |
|---|---|---|
目的 | 応募者の基本情報を確かめる | 経験とスキルから任せられる仕事を判断する |
様式 | 様式例がある(厚生労働省の様式例など) | 決まった様式はない |
主な中身 | 氏名・連絡先・学歴・職歴・資格・志望動機 | 職務要約・プロジェクトごとの業務内容・技術・成果・自己PR |
書き方 | 時系列で1行ずつ | 読み手に合わせて構成を組み立てる |
エンジニアの選考では、判断の材料になるのは主に職務経歴書です。応募時は履歴書と職務経歴書をセットで出すのが一般的なので、提出する書類は応募先の指定に従ってください。
エンジニア求人の条件で記載率を数えた4つの項目
エンジニアのレジュメで示しておきたい項目として、この記事では実務経験の中身、技術ごとの経験年数、リードやマネジメントの経験、GitHub などのアウトプットの4つを取り上げ、Offers の正社員エンジニア求人の必須条件と歓迎条件にそれぞれが書かれている割合を数えました。求人に書かれた条件は、レジュメと照らし合わせられやすい項目だと考えられます。
Offers に掲載された正社員のエンジニア求人のうち、必須条件に実務経験を求める記載がある求人は73.9%、「3年以上」のように経験年数を書いた求人は53.6%でした(Offers(株式会社overflow)調べ・必須条件の記載がある正社員エンジニア求人 n=1,700・2022年3月〜2026年9月公開・2026年10月2日集計)。
項目 | 数えた欄と語 | その語がある求人の割合 |
|---|---|---|
実務経験 | 必須条件に「実務経験」「開発経験」「運用経験」「構築経験」「設計経験」のいずれか | 73.9% |
経験年数 | 必須条件に「3年以上」のような、数字に続く「年以上」 | 53.6% |
リード・マネジメントの経験 | 必須条件か歓迎条件に「テックリード」「リードエンジニア」「マネジメント」「リーダー」のいずれか | 32.1% |
アウトプット | 必須条件か歓迎条件に「登壇」「技術ブログ」「ポートフォリオ」「技術発信」「外部発信」のいずれか、または OSS の公開・貢献・コントリビュート・コミット・活動、GitHub での公開・提示・提出を求める記載 | 4.7% |
出所: Offers(株式会社overflow)調べ・正社員エンジニア求人 n=1,700・2022年3月〜2026年9月公開・2026年10月2日集計。
実務経験は担当した工程まで書く
実務経験は、使った技術の名前だけでなく、設計・実装・テスト・運用のどの工程を担当したかまで書くと、求人の条件と照らし合わせてもらえます。必須条件の「開発経験」「運用経験」「設計経験」には工程まで指定した書き方もあり、担当工程が書かれていれば照らし合わせやすくなると考えられます。
たとえば「Go での開発経験」という条件に対して、「Go」とだけ書くより「Go で決済 API(外部のシステムから機能を呼び出す窓口)の設計から実装、本番運用まで担当」と書く方が、条件を満たしているかが一読で伝わるはずです。
経験年数は技術ごとに分けて書く
経験年数は、言語・フレームワーク・インフラなど技術ごとに分けて書きます。先の集計でも、求人の53.6%が必須条件に「◯年以上」の年数を書いており、技術ごとの年数がレジュメから読み取れれば、この条件と照らし合わせてもらいやすいと考えられます。
在籍年数と技術の経験年数は一致しません。5年在籍した会社で TypeScript を使ったのが後半の2年なら、スキル欄には「TypeScript 2年」と書く方が正確で、面接で食い違いを指摘されることもありません。
リードやマネジメントの経験は人数と役割で書く
リードやマネジメントの経験は、チームの人数と自分の役割(技術選定・設計レビュー・メンバーの育成・採用面接など)を添えて書きます。エンジニア求人の32.1%が、必須条件か歓迎条件にテックリード・マネジメント・リーダーの経験を挙げていました。
肩書きがなくても、設計レビューを担っていた、新メンバーの受け入れを任されていたといった経験は書いてかまいません。「リーダー」という肩書きより、何人のチームで何を決めていたかの方が、読み手は役割の大きさを判断できます。
GitHub や技術ブログは補足として載せる
GitHub・技術ブログ・登壇資料などのアウトプットは、あれば職務経歴書の末尾に URL を添える補足の扱いで足ります。登壇・技術ブログ・ポートフォリオ・技術発信の語か、OSS の公開や貢献、GitHub での公開や提示を求める記載が、必須条件か歓迎条件にある求人は4.7%でした。
業務のコードは公開できないことも多いうえ、4.7%は歓迎条件を含めた割合なので、必須条件として求める求人の割合はこれを上回りません。この集計から推して、アウトプットが無いだけで不利になる求人は多くないと考えられます。載せる場合は、何を作ったか・どの技術を使ったかを1行ずつ添えると、読み手がリンクを開くかどうかを決めやすくなります。見せ方の詳細は「エンジニア転職で差がつくポートフォリオの作り方」が参考になるはずです。
求人の条件に GitHub の名前があっても、アウトプットを求めているとは限りません。「GitHub」の語が必須条件か歓迎条件にある求人は1,700件のうち138件(8.1%)で、その大半は GitHub を使ったチーム開発の経験や、GitHub Actions を使った CI(継続的インテグレーション)の構築経験といった開発ツールの利用経験として書かれていました。
こうした条件と照らし合わせてもらうには、スキル欄のツールの行に GitHub と使い方(プルリクエストでのレビュー、CI の構築など)を書いておくのが手堅い方法です。
レジュメを書く前に、応募したい求人の必須条件と歓迎条件を並べて読むと、どの経験を厚く書けばよいかが決まります。Offers では、エンジニア・PdM・デザイナーの正社員求人を探せるほか、経歴とスキルを登録しておくと企業からスカウトが届きます。
エンジニアの職務経歴書の構成と書き方
エンジニアの職務経歴書は、職務要約、活かせる技術(スキル欄)、プロジェクトごとの職務経歴、自己PRの4つで構成するのが基本です。読み手は最初の職務要約とスキル欄で求人の条件に合うかを判断し、合いそうならプロジェクト欄を読み込みます。
順番 | 項目 | 書くこと |
|---|---|---|
1 | 職務要約 | 経験年数・得意な領域・直近の役割を3〜5行で |
2 | 活かせる技術 | 言語・フレームワーク・インフラ・ツールと、それぞれの経験年数 |
3 | 職務経歴 | プロジェクトごとの期間・規模・役割・担当工程・技術・成果 |
4 | 自己PR | 次の職場で活かしたい強みと、その根拠になる経験 |
形式に決まりはありませんが、新しいプロジェクトから順に書く逆編年体にすると、直近の経験が最初に目に入る構成です。書き方の細かなポイントとフォーマットは「エンジニアの職務経歴書の書き方とフォーマット」にまとめています。
職務要約は経歴の軸を3〜5行で書く
職務要約は、経験年数・得意な領域・直近の役割の3点を3〜5行にまとめ、読み手が「どんなエンジニアか」を最初の数行でつかめるようにするのが役目です。会社名を並べるより、担当してきたプロダクトの種類と技術の軸を書く方が伝わります。
記入例は次のとおりです。「Web サービスのバックエンド開発に7年従事。直近3年は SaaS の決済基盤で、Go と Amazon Web Services(AWS)を用いた API の設計・実装・運用を担当し、4名のチームでテックリードとして設計レビューと技術選定を担ってきました。」
スキル欄は技術ごとに経験年数と使い方を添える
スキル欄は、技術を分類ごとに並べ、それぞれに実務での経験年数と使い方を添えます。求人の必須条件にある「◯年以上」と、読み手がそのまま照らし合わせられる形にするのが狙いです。
分類 | 技術 | 経験年数 | 使い方 |
|---|---|---|---|
言語 | Go | 3年 | API の設計・実装 |
言語 | TypeScript | 2年 | 管理画面のフロントエンド |
インフラ | AWS(ECS・RDS) | 3年 | 構築・運用・監視 |
ツール | Terraform | 2年 | インフラのコード管理 |
表の値は記入例です。独学や個人開発で触れただけの技術は、実務の年数と分けて「個人開発で使用」と書き添えると、面接で深掘りされたときに説明がぶれません。
プロジェクト欄は期間・規模・役割・成果の順で書く
プロジェクト欄は、1件ごとに期間、チームの規模、自分の役割と担当工程、使った技術、成果の順で書きます。同じ形で並べると、読み手はプロジェクトどうしを比べながら、経験の幅と深さを読み取れるはずです。
項目 | 記入例(決済基盤のリプレイス) |
|---|---|
期間 | 2023年4月〜2025年3月 |
規模・役割 | エンジニア6名・テックリード |
担当工程 | 要件定義・設計・実装・運用 |
技術 | Go/AWS(ECS・Aurora)/Terraform |
内容 | モノリスの決済処理を API として切り出し、段階的に移行 |
成果 | 障害時の復旧手順を整備し、リリース頻度を月1回から週1回に上げた |
成果は、数字で示せるものは数字で、示せないものは「何を判断し、何が変わったか」で書きます。数字だけを並べるより、自分が下した判断を1文添える方が、面接で話を広げてもらいやすいのです。
自己PRは次の職場で活かせる強みに絞る
自己PRは、応募先で活かせる強みを1〜2個に絞り、その根拠になるプロジェクトを職務経歴の中から指し示して書きます。職務経歴の繰り返しにせず、「だから次の職場でこれができる」という結論を置く場所です。
採用担当者がどこを読んでいるかは「採用担当者が重視する職務経歴書の要点」が、転職の回数が多い場合の書き方は「転職回数が書類選考に与える影響」が参考になります。
書類選考がない求人でも面談の前にレジュメを整えておく理由
書類選考を選考ステップに書いていない求人でも、レジュメは面談や面接の前に目を通され、質問の材料になることがあります。Offers に掲載された正社員エンジニア求人のうち、選考ステップを記載した求人の66.9%がカジュアル面談をステップに含んでいました(Offers(株式会社overflow)調べ・選考ステップの記載がある正社員エンジニア求人 n=1,508・2022年3月〜2026年9月公開・2026年10月2日集計)。
カジュアル面談は選考の前に互いを知る場ですが、一般的には、企業の担当者がレジュメやプロフィールに目を通したうえで話す内容を考えます。スカウトを受ける場合も、企業は登録された経歴を読んで声をかけるかを判断するのが通常です。面談の前にレジュメを整えておくと、話が経験の深掘りから始まり、限られた時間で自分に合うポジションかを確かめやすくなります。
外資系企業に出す英文レジュメで変わる点
外資系企業や海外の企業に出す英文レジュメは、日本の職務経歴書より短くまとめるのが一般的です。よく勧められる書き方として、1行ごとに成果を動詞から書き始める、写真や生年月日・性別を載せない、職歴と学歴を新しいものから順に並べる、といった慣行がありますが、国や企業によって違うため応募先の指定を確認してください。
米国では resume(レジュメ)が1〜2ページの職務経歴の要約を、CV(Curriculum Vitae)が研究や学術の経歴を含む長い経歴書を指すことが多い一方、英国などでは CV がレジュメと同じ意味で使われます。応募先がどちらを求めているかは、求人票の指定に従ってください。エンジニアの英文レジュメでも、スキル欄に技術と経験年数を並べる点は日本語の職務経歴書と変わりません。
職務経歴書を人と一緒に作る方法
職務経歴書を1人で書くのが難しいときは、経験を聞き出してもらいながら作ると、自分では当たり前だと思っていた経験を書き落とさずに済みます。エンジニアは、担当した技術や工程を細かく説明できても、それがどの求人の条件に合う強みなのかを言葉にするところで手が止まりがちです。
Offers の「職務経歴書作成・添削」は、エンジニアとPdMに特化したサービスで、β版の期間中は無料です(2026年9月時点)。キャリアコンサルタントが30分のオンラインインタビューで経験を深掘りし、職務経歴書を Google ドキュメントで納品します。転職の意思が固まっていなくても、キャリアの棚卸しに使えます。
レジュメの要点
国内の転職でのレジュメは履歴書と職務経歴書の両方を指すことが多く、エンジニアの選考で中心になるのは職務経歴書です。履歴書が基本情報を伝える書類なのに対し、職務経歴書は経験とスキルから任せられる仕事を伝える書類です。エンジニアの場合、Offers の正社員求人の73.9%が必須条件に実務経験を、53.6%が経験年数を書いており(Offers(株式会社overflow)調べ・n=1,700・2026年10月2日集計)、レジュメはこの2つを読み取れる形にすることが出発点になります。
書くときは、職務要約・スキル欄・プロジェクト欄・自己PRの4つで構成し、技術ごとの経験年数と担当工程を具体的に書いてください。応募したい求人の条件を先に読んでから書くと、どの経験を厚くすればよいかが決まります。

