エンジニア履歴書・職務経歴書完全ガイド〜採用担当が読む書き方・テンプレ・NG例〜

「エンジニアの履歴書・職務経歴書って、普通の事務職と何が違うの?」「技術スキルってどこまで書けばいい?」「自己PRに何を書けばいいかわからない…」——本記事は、エンジニア向けの履歴書・職務経歴書の書き方を、現役エンジニア(週5フルリモート/年収900万超/採用面接官として20名以上面接経験あり)の視点で、採用担当が実際に読むポイントから逆算して解説するものです。テンプレートで終わらせず、Before/After例・NG例10選・OK例10選・STAR法・定量化テクニックまで、実務で「内定が出るレベル」に持っていく具体策を網羅しました。

本記事は約9,000字、表は10個以上、Before/After例は20組以上含みます。「結論だけ知りたい人」向けに最初に5秒サマリーを置きましたので、興味があるセクションだけ拾い読みしてください。最後にフロントエンドエンジニア学習ロードマップ2026とレバテック完全レビュー2026を組み合わせた、書類通過後の流れも提案します。

1. エンジニアの履歴書・職務経歴書の特徴

1.1 他職種との根本的な違い

エンジニアの書類選考は、一般職と評価軸が大きく異なります。営業職なら売上数字、事務職なら正確性・効率化が評価されますが、エンジニアは「技術スタック・課題解決力・チーム貢献」の3軸で評価されます。特に職務経歴書は事実の羅列ではなく、技術的な意思決定の記録として読まれます。「Reactを使った」ではなく「なぜReactを選んだか、その結果どうなったか」が問われるのです。

項目	一般職	エンジニア
履歴書の重み	50%	20%
職務経歴書の重み	30%	60%
ポートフォリオ/GitHub	不要	20%(必須化進む)
評価軸	業務遂行能力	技術力+課題解決+設計思想
数字化対象	売上・効率	処理時間・障害率・ユーザー数
志望動機の重要度	高	中(技術の話の方が重要)
写真の重要度	高	中

1.2 採用担当が見ているポイント

採用担当(現場エンジニア+人事)が職務経歴書を見るのは、平均1〜2分です。最初の5秒で読み飛ばすか深掘りするか決まります。判断基準は(1)技術スタックが募集要件と合うか、(2)プロジェクト規模感が会社の事業フェーズと合うか、(3)直近の業務で何を成し遂げたかの3点。「何を作った」より「どんな課題をどう解決した」が刺さるのは、現場が欲しいのは作業者ではなく問題解決者だからです。

1.3 履歴書と職務経歴書の役割分担

履歴書は「身元と最低限の経歴」を伝える事務書類、職務経歴書は「あなたの技術力と思考プロセスを売り込む営業資料」です。書く順番も、まず職務経歴書から書き始め、そこから抜粋して履歴書を整える方が効率的です。多くの転職失敗者は逆順で書き、履歴書の自己PRに力を入れすぎて職務経歴書がスカスカになる傾向があります。

2. 履歴書の書き方(基本)

2.1 基本項目と推奨フォーマット

履歴書はJIS規格か厚生労働省様式の2択で十分です。エンジニア転職の場合、市販の凝ったデザインの履歴書を使う必要はありません。むしろシンプルで読みやすいPDFの方が好印象です。「履歴書 テンプレート JIS」で検索して出てくる定番フォーマットをそのまま使ってください。

項目	書き方のポイント	注意点
氏名・ふりがな	戸籍通り正確に	旧字体に注意
生年月日	西暦推奨	和暦と混在しない
連絡先	携帯+業務用Gmail推奨	会社メール厳禁
写真	3ヶ月以内・スーツ可・私服可	自撮り・加工厳禁
学歴	高校卒業から記載	中退も正直に
職歴	正社員・派遣・業務委託を明記	1ヶ月未満は要相談
資格	取得月+正式名称	失効資格は書かない
本人希望欄	「貴社規定に従います」推奨	具体的金額は職務経歴書へ

2.2 学歴・職歴欄の書き方

学歴は高校卒業から、職歴は正式な会社名(株式会社含む)+部署+役職を記載します。職歴欄に「Web系企業に入社」のような抽象表現はNGです。退職理由は履歴書には書かず、職務経歴書または面接で言葉で説明します。派遣・業務委託・フリーランス期間も正直に書くのが原則で、隠すと後で問題になります。

2.3 資格欄に書くべきもの・書くべきでないもの

エンジニアの場合、資格は「あれば加点、なくても減点なし」がほぼ標準です。書くべきは応用情報・基本情報・AWS認定・GCP認定・LPIC・OracleMaster・TOEIC700以上あたり。逆に書くべきでないのは「自動車運転免許のみ」「失効した古いベンダー試験」「3級以下の英検・漢検」。スペースが余る場合は「現在AWS Solutions Architect Professional取得に向けて学習中」のような形で代用できます。

3. 職務経歴書の構成

3.1 4ブロック構成が王道

エンジニアの職務経歴書は(1)職務要約 (2)業務経歴(プロジェクト別)(3)技術スキル一覧 (4)自己PR/志望動機の4ブロック構成が定番です。A4で2〜3枚、長くても4枚以内に収めます。8枚も10枚もある職務経歴書は、それだけで「要点を絞れない人」と評価されます。

ブロック	分量目安	読まれる時間	役割
1. 職務要約	150〜250字	5秒	第一印象を決める
2. 業務経歴	A4で1〜2枚	30〜60秒	技術力の証明
3. 技術スキル一覧	A4で0.5枚	10秒	スキルマッチング
4. 自己PR/志望動機	各300〜500字	20秒	カルチャーフィット判定

3.2 ファイル形式とファイル名

ファイル形式はPDF一択です。Word/Excelで送るとレイアウトが崩れる、編集される、フォントが置換されるなどのリスクがあります。ファイル名は「職務経歴書_山田太郎_20260401.pdf」のように「種類_氏名_日付」を入れます。「shoumei.pdf」「経歴書.pdf」のような汎用名は、採用担当のフォルダ内で迷子になります。

3.3 書く順番のコツ

多くの人が冒頭から書き始めて挫折します。推奨順は(2)業務経歴から書く→(3)技術スキルを抽出→(1)職務要約をサマリーとして書く→(4)自己PR・志望動機で締める。事実から書き始めると、自己PRや要約も具体的な根拠を持って書けるようになります。

4. 職務要約(Before/After例)

4.1 職務要約の役割

職務要約は職務経歴書の冒頭150〜250字で、採用担当が最初の5秒で読む箇所です。ここで「読む価値がある」と思わせないと、残り全部が流し読みされます。書くべき要素は(1)経験年数 (2)主要技術スタック (3)直近の役割 (4)強みの4つだけ。長く書く必要はありません。

4.2 Before/After例 ケース1:Webエンジニア5年目

Before(NG例)
Web系企業に新卒で入社し、5年間さまざまなプロジェクトに携わってきました。フロントエンド・バックエンド両方を経験し、チームでの開発にやりがいを感じています。新しい技術を学ぶことが好きで、日々スキルアップに励んでいます。御社でも貢献できるよう頑張ります。

After(OK例)
SaaS企業にて5年間、Webアプリケーション開発を担当。直近3年はReact/TypeScript/Node.jsを用いたBtoB SaaSの開発リーダーとして、5名のチームで月間アクティブユーザー3万人規模のサービス運用を主導。特にパフォーマンス改善が得意で、SSR導入によりLCPを2.8秒→0.9秒に短縮した実績あり。次のキャリアでは技術選定から関われるテックリードを目指したい。

4.3 Before/After例 ケース2:インフラエンジニア3年目

Before(NG例)
インフラエンジニアとして3年間、サーバー構築や運用保守を担当してきました。AWSの経験があります。チームワークを大切にし、責任感を持って業務に取り組んでいます。

After(OK例)
SIerにて3年間、AWS基盤の設計・構築・運用を担当。直近1年はTerraformによるIaC化を主導し、新規環境構築の所要時間を平均5営業日→4時間に短縮。CloudWatch・Datadogを用いた監視基盤の整備にも従事し、深夜障害対応の月平均件数を12件→2件まで削減。次はSRE文化が根付いた組織で、より上流の信頼性設計に関わりたい。

5. 業務経験の書き方(プロジェクト別)

5.1 プロジェクト単位で記述する

業務経歴はプロジェクト単位で書きます。1社で複数プロジェクトに関わった場合は会社内で分割します。各プロジェクトには(1)期間 (2)プロジェクト概要 (3)役割・メンバー数 (4)担当業務 (5)使用技術 (6)成果の6項目を最低限含めます。

項目	記載例
期間	2024年4月〜2026年3月(2年)
プロジェクト概要	不動産検索SaaSのリプレイス(Rails→Next.js移行)
役割	フロントエンド開発リーダー(8名チーム)
担当業務	技術選定・設計・実装・コードレビュー・新人教育
使用技術	Next.js 14 / TypeScript / Tailwind / Prisma / Vercel
成果	LCP 3.2s→0.8s / 開発リードタイム30%短縮 / E2Eカバレッジ70%達成

5.2 工程フェーズ表記の標準化

「設計」「実装」だけでは粒度が粗すぎます。要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト・運用保守のどこに関わったかを明示します。とくに上流工程(要件定義・基本設計)に関わった経験は、Webエンジニアでは差別化要素になります。

5.3 「担当しただけ」を「主導した」に変える書き方

同じ業務でも書き方で価値が10倍変わります。「テストを担当」ではなく「PlaywrightによるE2Eテスト基盤を新規構築し、リグレッション検出率を70%向上」と書く。主語を「私が」にすると、能動性が伝わります。「チームで対応」「アサインされた」のような受け身表現は最小限に減らしてください。

6. 技術スキル一覧(マトリクス形式)

6.1 マトリクス形式の威力

技術スキルは「言語/フレームワーク/インフラ/ツール」のカテゴリごとに、レベル+経験年数を表で示すのが最も読みやすい形式です。文章で「Reactを使えます」と書くより、表で「React 4年 / 業務上級」と書く方が情報密度が10倍高くなります。

カテゴリ	技術名	経験年数	レベル
言語	TypeScript	4年	業務上級(設計から実装まで)
言語	Python	2年	業務中級(データ処理スクリプト)
フロントエンド	React	4年	業務上級(Hooks/RSC実装可)
フロントエンド	Next.js	3年	業務上級(App Router移行経験あり)
バックエンド	Node.js	3年	業務上級(Express/Hono/NestJS)
インフラ	AWS	2年	業務中級(ECS/RDS/CloudFront運用)
インフラ	Vercel	3年	業務上級(ISR/Edge Functions実装)
DB	PostgreSQL	4年	業務上級(インデックス設計可)
ツール	Git/GitHub	5年	業務上級(レビュー・CI/CD設計)

6.2 レベル定義は事前に明文化する

レベルの記述は定義をスキル表の前に明記しておきます。例:「初級=チュートリアルレベル/中級=ドキュメントを見ながら実装可/上級=設計から主導可/エキスパート=他者に教えられる」。これがないと「React 業務上級」がチームで一番できる意味なのか、ググりながら書ける意味なのか伝わりません。

6.3 触っただけのスキルを書かない

「Rust 1ヶ月 個人学習」のような触っただけスキルは書かないか、別枠で「学習中の技術」として整理します。業務スキルと混ぜると全体の信頼性が下がります。面接官は表の中の最弱項目を必ず質問してきます。

7. 自己PR(Before/After例)

7.1 自己PRに書くべき3つの要素

自己PRには(1)強み (2)エピソード (3)転職後の活かし方の3要素を含めます。300〜500字でコンパクトにまとめ、技術的な強みと人間的な強みを1つずつ書くと幅が出ます。「責任感があります」「協調性があります」だけは、もはやAIが書いた文章としか思われません。

7.2 Before/After例

Before(NG例)
私の強みは責任感と協調性です。これまでの業務でも、チームメンバーと協力しながら最後まで責任を持って取り組んできました。新しいことに挑戦する姿勢も大切にしており、御社でも貴重な戦力になれると考えております。

After(OK例)
私の強みは「技術的負債を可視化し、合意形成しながら段階的に解消するスキル」です。前職では10年蓄積されたjQuery主体のレガシーUIを、React+TypeScriptへ4半期ごとに10%ずつ移行する計画を立案・実行。事業を止めずに14ヶ月で完全移行を達成し、新規開発スピードを推定2.5倍に向上させました。御社のリプレイス案件でも、同じ「合意形成→段階移行」のアプローチで価値を出せると考えています。

7.3 抽象キーワードを具体エピソードに置き換える

「コミュニケーション力」「主体性」「柔軟性」のような抽象キーワードは、必ず具体的なエピソード+定量的な成果とセットにします。「コミュ力」→「企画と開発の橋渡しを担当し、月次仕様変更を平均5件→1件に削減」のように。エピソードがないキーワードは削除した方が伝わります。

8. 志望動機(Before/After例)

8.1 志望動機の評価基準

志望動機で評価されるのは「なぜその会社なのか」と「入社後にどう貢献できるか」の2点です。会社理念だけ褒めても、自分の経歴と接続しなければ評価されません。逆に経歴だけ語っても「うちじゃなくてもいいのでは?」となります。両方の橋渡しが必要です。

8.2 Before/After例

Before(NG例)
御社の理念に共感し、成長中の事業に貢献したいと考え志望しました。最新技術を扱える環境で、スキルアップしながら長く働ける会社で頑張りたいと思っています。

After(OK例)
御社の「業務効率化SaaSを日本中の中小企業に届ける」というミッションに、強く惹かれました。私は前職のSIerで中小製造業の業務システム導入を10案件以上担当し、「現場が使いこなせる柔軟なUI」がいかに重要かを痛感してきました。御社の製品はNo-Code志向の設計が高度で、まさにその課題を解決する設計思想だと感じています。私のReact/TypeScriptと業務知識の経験を、入社後はカスタマイズ機能の改善に活かしたいと考えています。

8.3 使い回しはバレる

10社一斉応募で同じ志望動機を使い回すと、採用担当の目には「うちじゃなくていい人」と映ります。会社名だけ差し替えただけの文は瞬時に見抜かれます。最低でもその会社のプロダクト・技術ブログ・採用ページを30分読んで具体名を挙げるのが、志望動機作成の基本工数です。

9. STAR法での実績記述

9.1 STAR法とは

STAR法は外資系コンサル発祥のエピソード記述フレームワークで、Situation(状況)・Task(課題)・Action(行動)・Result(結果)の4要素で実績を語ります。職務経歴書・面接の両方で使え、特に自己PR・業務経歴の「成果」欄に絶大な効果を発揮します。

要素	書く内容	記述例
S: Situation	前提となる状況	「BtoB SaaSのレスポンスタイムが平均3.5秒で、解約率が月5%」
T: Task	解決すべき課題	「1秒以内に短縮し、解約率を2%以下にする必要があった」
A: Action	あなたが取った行動	「ボトルネック分析→N+1問題特定→Prismaクエリ最適化+CDNキャッシュ導入」
R: Result	定量的成果	「レスポンスタイム3.5秒→0.7秒/解約率5%→1.8%」

9.2 STAR法 完成例

9.3 STAR法 適用範囲

STAR法はすべてのプロジェクト・全成果に必ず使うものではありません。重要なのは「アピールしたい代表的成果3〜5個に絞ってSTAR法で深く書き、残りは要点だけ書く」ことです。すべてSTAR法だと、職務経歴書が冗長になり、要点が埋もれます。

10. 数字を入れる(定量化)

10.1 エンジニアが数字化できる指標一覧

「定量化できることがない」というエンジニアは多いですが、ほぼ全ての業務に数値化可能な指標があります。性能・規模・効率・品質・リーダーシップの5カテゴリで考えると見つけやすくなります。

カテゴリ	具体的指標
性能	レスポンスタイム / LCP / TTFB / バンドルサイズ / SQL実行時間
規模	月間アクティブユーザー / リクエスト/秒 / DB行数 / コードベース行数
効率	デプロイ頻度 / リードタイム / 自動化件数 / 工数削減率
品質	テストカバレッジ / 障害発生数 / バグ報告件数 / SLA達成率
リーダーシップ	メンバー数 / レビュー件数 / 新人教育数 / 外部登壇回数

10.2 数字がなくても「規模感」だけは書く

具体的KPI数字を出せない場合(NDA・公表禁止)でも、「ユーザー数規模」「チーム規模」「コードベース規模」の3つは比較表現で書けます。例「数十万人規模のサービス」「8名チーム」「マイクロサービス5系統」。これだけでも採用担当には十分情報になります。

10.3 数字の誇張は必ず追及される

「1人で全部やりました」「100倍改善しました」のような誇大表現は、面接の技術質問で必ず詰められます。誇張するより、正直に小さく書いて、面接で深掘りされたとき詳細に説明できる方が、圧倒的に評価が高いです。書類で盛って面接で破綻、が一番もったいないパターンです。

11. NG例集10選

No	NG例	なぜダメか
1	「Web系企業に入社」	会社名不明、虚偽の疑い
2	「最新技術を学んでいます」	具体性ゼロ、誰でも書ける
3	「責任感と協調性が強みです」	エピソードなしは無価値
4	「React、Vue、Angular、Svelteすべて使えます」	レベル不明、信頼性低下
5	「8枚に及ぶ詳細な職務経歴書」	要点絞れない人と判定
6	「成果:プロジェクトを成功させた」	数字なし、抽象的
7	「写真:自撮りスマホ加工アプリ」	論外、社会人マナー欠如
8	「資格:普通自動車運転免許のみ」	エンジニアには無意味
9	「志望動機:成長したい」	会社主語の欠落
10	「退職理由:人間関係」	面接で必ず突っ込まれる

12. OK例集10選

No	OK例	なぜ強いか
1	「LCP 2.8s→0.9s短縮」	性能指標で定量化
2	「8名チームの技術選定主導」	役割+規模感が明確
3	「N+1問題解決でレスポンス▲80%」	原因→アクション→成果が連続
4	「TypeScript 4年 業務上級」	マトリクスで一覧性高い
5	「月次障害12件→2件削減」	運用品質指標が具体的
6	「テックリードを次のキャリアで目指す」	目標が具体的、将来像が見える
7	「Terraform IaC化で構築5日→4時間」	効率化指標の劇的改善
8	「E2Eテスト基盤を新規構築」	主語が自分、能動性が高い
9	「貴社の○○製品の××機能に貢献したい」	会社理解を具体名で証明
10	「正直に学習中スキルを別枠で記載」	信頼性が上がる

13. 業務経験ゼロの場合(独学・スクール)

13.1 未経験者の戦略

業務経験ゼロでも、職務経歴書を空欄にする必要はありません。独学・スクール・個人開発・OSS・ハッカソンを業務に準ずる経験として書き出します。重要なのは「業務」ではなく「成果物」と「学習プロセス」が評価対象だということです。

13.2 ポートフォリオ駆動で書く

業務経歴の代わりに「個人開発プロジェクト」セクションを設けます。1〜2個のプロジェクトについて、業務経歴と同じ6項目フォーマット(期間/概要/役割/業務/技術/成果)で書きます。GitHubのスター数、Vercelデプロイ数、ユーザー数(あれば)も入れます。

13.3 スクール経験を最大限活かす書き方

スクール卒業生は「スクール名+カリキュラム概要+成果物+学習時間」を書きます。「TechAcademy受講」だけでは弱く、「TechAcademy Webアプリケーションコース受講(3ヶ月・250時間)。チーム開発でフリマアプリを構築、Next.js+Prisma+Vercel構成」のように具体的に書きます。テックアカデミーレビューやDMM WEBCAMPのような大手スクールはカリキュラム情報を採用担当も把握しているため、追加説明が少なくて済む利点もあります。

14. PMやリーダー職の書き方

14.1 PMの評価軸は「成果+プロセス」

PM・リーダー職の職務経歴書は、技術力よりも「事業成果」「チームマネジメント」「意思決定プロセス」が評価されます。「リリースした機能数」「リードタイム削減率」「メンバーの離職率」のような指標を出します。

記述カテゴリ	PMで重視される指標例
事業成果	MAU増加率 / 売上貢献 / 機能リリース数
チーム運営	メンバー数 / 1on1頻度 / 離職率
プロセス改善	スクラム改善 / レビュー文化整備 / ADR運用
採用	採用面接数 / 採用人数 / 採用ブランディング寄与
外部	登壇回数 / 技術ブログ寄稿 / コミュニティ運営

14.2 「マネジメントだけの人」と思われない工夫

PMやリーダー職のキャリアが長くなると「技術が古い人」と見なされがちです。これを避けるには、現役で関わっている技術的取り組み(技術選定リード・ADR執筆・コードレビュー実施数)を明示します。「コードは書かないが技術的議論はリードしている」と伝わると価値が上がります。

15. キャリアアドバイザー添削の活用

15.1 第三者目線の重要性

自分で書いた職務経歴書は必ず第三者にレビューしてもらうべきです。同僚に頼むのは情報漏洩リスクがあるので、レバテックキャリア・GeeklyのようなIT特化型エージェントのキャリアアドバイザー(CA)による無料添削が最も効率的です。複数社のCAに見てもらい、共通指摘を優先的に修正します。

15.2 添削で確認すべきポイント

確認項目	具体的質問
第一印象	「最初の5秒で何の人とわかりますか?」
技術スタック	「現在の市場ニーズと合っていますか?」
数字	「具体的に何の数字が足りませんか?」
志望動機	「他社にも同じ内容で出せますか?」
長さ	「削るならどこですか?」

16. ChatGPT活用法

16.1 ChatGPTが得意なこと/苦手なこと

ChatGPT(およびClaude等のLLM)は「文章のリファイン」「STAR法への構造化」「定量化アイデア出し」が得意です。一方で「あなただけのエピソード生成」「市場ニーズに合った技術スタック選定」は苦手です。LLMをゼロから職務経歴書を生成させるのではなく、自分の素材を磨くツールとして使うのが正解です。

用途	有効性	使い方の例
文章のリファイン	◎	「以下の自己PRを150字に要約して」
STAR法構造化	◎	「以下の経験をS/T/A/Rに分解して」
定量化アイデア	◯	「この業務で測定できる指標を10個」
ゼロから生成	×	「私の職務経歴書を書いて」←嘘になる
誤字脱字チェック	◎	「以下の誤字を指摘して」

16.2 推奨プロンプト例

「あなたはIT人材の採用に20年関わるベテラン人事です。以下の自己PRを読み、(1)強み (2)エピソード (3)貢献の3要素のうち弱い箇所を指摘し、改善案を提示してください」のように、役割設定+評価軸+具体的アクションを含めると質が劇的に上がります。

17. PDF送信時の注意

17.1 ファイル形式・ファイル名・サイズ

項目	推奨	NG
形式	PDF	Word(レイアウト崩れ) / Excel(印刷面倒)
ファイル名	職務経歴書_山田太郎_20260401.pdf	shoumei.pdf / 新規ファイル.pdf
ファイルサイズ	2MB以下	10MB超(画像入れすぎ)
圧縮	不要	ZIPで送る(開封が面倒)
パスワード	応募先指示時のみ設定	無断PPAP(別メールでPW送信)

17.2 メール本文のテンプレート

18. FAQ

Q1. 職務経歴書は何枚に収めるべき?

A. A4で2〜3枚が標準です。経験10年以上の人でも4枚以内が無難。8枚を超えると「要点を絞れない人」と評価されがちです。長くなる場合は「主要プロジェクト3つに絞り、その他は箇条書きで」と削ります。

Q2. 短期離職(1年未満)は書くべき?

A. 正直に書いてください。隠すと経歴詐称になり、内定取り消しや解雇事由になります。理由は履歴書ではなく面接で説明する形が標準です。短期離職の理由を1〜2行で簡潔にまとめておくと面接でも安定して答えられます。

Q3. ポートフォリオは必須?

A. Web系自社開発企業ではほぼ必須です。GitHub URL、デプロイURLを職務経歴書の冒頭に書きます。SIerや業務システム系では必須でないこともありますが、あれば必ず加点です。

Q4. 年収希望は書くべき?

A. 履歴書には書かず、エージェントに伝えるのが標準です。直接応募の場合は「現職年収+10〜20%」を希望として伝え、ただし「相談可」と添えると柔軟性が伝わります。

Q5. 退職理由はネガティブに書いてもいい?

A. ネガティブな事実をポジティブな未来志向に変換します。「人間関係が悪かった」→「より裁量を持って意思決定できる環境を求めて」のように、自分の意志での選択に置き換えます。嘘ではなく視点を変えるのがコツです。

Q6. フリーランス経験はどう書く?

A. 「個人事業主として」と明記し、案件別にプロジェクトを列挙します。クライアント名はNDA上書けない場合「Web系SaaS企業様」のような表記で代用。継続案件数・案件単価レンジも入れると信頼性が増します。

Q7. 学歴コンプレックスがある場合は?

A. エンジニア転職で学歴が評価に響くケースは10%未満です。技術力と成果物で評価される業界なので、学歴は最低限の記載で十分。むしろ「高卒で独学で実装力を身につけた」というストーリーは強みになり得ます。

Q8. 写真は省略していい?

A. 履歴書には貼るのが標準です。職務経歴書には不要。スマホ自撮りや旅行写真は厳禁で、最低でもセルフタイマー+背景無地で撮るか、駅前の証明写真機(800円程度)を使ってください。

19. まとめ

エンジニアの履歴書・職務経歴書で差がつくのは「何を作ったか」ではなく「どんな課題をどう技術で解決したか」です。本記事で解説した(1)4ブロック構成 (2)プロジェクト別6項目フォーマット (3)技術スキルマトリクス (4)Before/After例 (5)STAR法 (6)定量化指標 (7)NG例10/OK例10を実践すれば、書類通過率は劇的に上がります。

書類通過後の流れについてはフロントエンドエンジニア学習ロードマップ2026でスキル整理を、レバテック完全レビュー2026やGeekly完全レビュー2026で書類添削サービスの活用を、プログラミングスクール完全比較2026で未経験者の学習プランを参照してください。技術スタック整理にはuseState完全ガイドやuseMemo vs useCallback完全比較などのReact深掘り記事も役立ちます。

最後に一言。書類は「あなたが何をできるか」を、忙しい採用担当に5分以内に伝える資料です。完璧を目指して何ヶ月も書き直すより、6〜7割の完成度で第三者レビューを受け、フィードバックで磨く方が10倍速く完成します。本記事のフォーマットをそのままコピペで使い始めても、まず1社目に出してみてください。市場の反応こそが最大のフィードバックです。健闘を祈ります。