この記事では、ITエンジニアの職務経歴書の書き方を採用担当者の視点から解説します。スキルの書き方・プロジェクト経歴の記述法・職種別の例文まで、書類選考通過率を上げる具体的なポイントをまとめました。
ITエンジニアの職務経歴書が書類選考で落ちる本当の理由
多くのITエンジニアは「自分のスキルを正確に書いた」と思っているにもかかわらず、書類選考で弾かれます。原因はスキルや経験のなさではなく、書き方にあります。
採用担当者は職務経歴書を30秒で判断する
大手IT企業の採用担当者が1日に目を通す書類は、多いときで数十〜百件を超えます。1件にかけられる時間は平均30秒から1分程度です。この短い時間で「会いたい」と思わせられるかどうかが書類選考の本質です。
重要なのは採用担当者の多くは非エンジニアという現実です。技術用語を並べるだけでは何ができる人かが伝わりません。「この人に何を任せられるか」をすぐに把握できる書き方が求められます。
採用担当者はここを見ている
- 職務要約（冒頭の3〜4行）：「何者か」がすぐにわかるか
- プロジェクト経歴：規模・役割・使用技術のバランス
- スキル一覧：習熟度が明示されているか、業務で使えるレベルか
- 自己PR：入社後のイメージが「再現できそう」かどうか
「技術の羅列」だけでは採用担当者に何も伝わらない
よくある失敗は、スキル欄に「Java, Python, AWS, Docker, Kubernetes…」と使用技術を並べるだけの書き方です。採用担当者には「どのレベルで使えるのか」「実務でどう使ってきたのか」が見えず、評価のしようがありません。
技術の羅列は「何を知っているか」は伝えますが、「何ができるか」「どう活躍してくれるか」は伝えません。採用担当者が知りたいのは後者です。
ITエンジニアの職務経歴書に書くべき5つの項目
職務経歴書の構成は、どの職種でも基本的な項目は共通ですが、ITエンジニアとして評価される書き方には独自のポイントがあります。
①職務要約：最初の3〜4行で「何者か」を決める
職務要約は職務経歴書の顔です。採用担当者が最初に読む部分であり、「続きを読むかどうか」を左右します。「どんなエンジニアで・どんな経験を持ち・何ができるのか」を3〜4行（150字前後）で伝えます。
良い職務要約例（バックエンドエンジニア 経験4年）
Javaを主軸としたバックエンド開発を4年経験。ECサイトおよびBtoB向けSaaSの設計・実装・リリースに携わり、直近2年間はチームリードとして3〜5名の開発を主導しました。スケーラビリティを意識したAPI設計と、コードレビューによる品質管理が強みです。
②職務経歴・プロジェクト経歴：採用担当者が最も時間を使う部分
プロジェクト経歴は職務経歴書の中で最も重要です。下記の6要素をセットで記載することで、採用担当者が読んだときに「このプロジェクトで何を担ったか」が具体的に伝わります。
| 記載要素 | 記載例 |
|---|---|
| 期間 | 2023年4月〜2024年3月（12ヶ月） |
| プロジェクト概要 | BtoB向けSaaS管理画面の新規開発 |
| チーム規模・役割 | 7名チーム、リードエンジニア担当 |
| 担当フェーズ | 要件定義・設計・実装・テスト・リリース |
| 使用技術 | Java（Spring Boot）、PostgreSQL、AWS（EC2/RDS/S3） |
| 実績・成果 | リリース後3ヶ月でNPS+12ポイント改善、障害件数を前年比40%削減 |
③技術スキル一覧：カテゴリ×習熟度で整理する
スキル欄で差がつくのは、技術名を並べるだけでなく習熟度や実務での活用実績を加えているかどうかです。「Java 5年（設計・実装・コードレビュー可能）」のように、何ができるかがわかる書き方が採用担当者に伝わります。
| カテゴリ | 技術・ツール | 経験年数・習熟度 |
|---|---|---|
| 言語 | Java | 5年（設計・実装・レビュー可） |
| 言語 | Python | 2年（データ処理スクリプト中心） |
| フレームワーク | Spring Boot | 3年（API設計・実装） |
| クラウド | AWS | 3年（EC2/RDS/S3/Lambda/CloudWatch） |
| DB | PostgreSQL | 4年（クエリ最適化・スロークエリ改善まで） |
| その他 | Docker / GitHub Actions | 2年（CI/CD構築・運用経験あり） |
④自己PR：強みを「エンジニアでない人」に伝わる言葉で
自己PRは技術力のアピールではなく、「入社後に何ができる人か」を伝える場です。採用担当者（特に非エンジニアのHR担当）が「この人をチームに入れたい」と思えるかどうかが焦点です。
技術的な実績は数値で補強し、それがビジネスにどう貢献したかをセットで伝えます。「〇〇の実装でページ表示速度を2秒→0.8秒に改善し、コンバージョン率が8%向上」のように、技術的な成果をビジネス成果に翻訳するのがコツです。
⑤資格・学歴：IT系資格は積極的に記載する
基本情報技術者試験、応用情報技術者試験、AWS認定資格（SAA/SAP等）、Oracle認定資格などのIT系資格は、スキルの客観的な証明として採用担当者に評価されます。現在取得に向けて勉強中の資格があれば「取得予定：〇〇年〇月予定」として記載することも可能です。
採用担当者が「思わず通過させたくなる」プロジェクト経歴の書き方
競合との差がつくのがプロジェクト経歴の書き方です。多くのエンジニアが「何をやったか」だけを書く中、採用担当者の目を引くのは「どんな状況で・何を判断して・何を変えたか」が伝わる書き方です。
「課題→技術選択→実績」の3点セットで書く
採用担当者が最も知りたいのは「再現性」です。「この人が入社したら、うちの課題も解決してくれそうか」というイメージを持たせることが目標です。課題→どう対処したか→何が変わったか、の流れで記述します。
NG例：「何をやったか」だけの書き方
ECサイトのバックエンド開発を担当しました。Java（Spring Boot）を使用し、商品検索APIの実装を行いました。「担当しました」「行いました」だけでは規模も貢献度も伝わらない
良い例：課題→対処→実績の流れで書く
ECサイトの商品検索レスポンスが平均4秒超と遅く、直帰率の高騰が課題でした。ElasticsearchへのDB移行を提案・主導し、Java（Spring Boot）でAPIを再設計。リリース後3週間でレスポンスを平均0.9秒に短縮し、検索経由のコンバージョン率が1.3倍に改善しました。
チームでの役割を「立場」と「規模」で明示する
「メンバーとして開発に参加」という記述は採用担当者に何も伝わりません。「7名チームのリードエンジニアとして設計・コードレビュー担当」のように、チームの規模と自分のポジションをセットで書きます。
- メンバー担当：「〇名チームの実装担当。△△機能を一人で設計・実装」
- リード担当：「〇名チームのリードとして設計・タスク管理・コードレビューを担当」
- PM兼任：「〇名チームのPM兼エンジニアとして、顧客折衝から実装まで一貫して担当」
古い経歴はどこまで書くべきか
職務経歴書は原則「直近から遡る」形式（逆年代順）で書きます。技術の進化が速いIT業界では、5年以上前のプロジェクトは1〜2行程度の概要にとどめるのが一般的です。現在のスキルや役割に関連する場合は記載しますが、現在は使っていない古い技術を前面に出すのは避けましょう。
職務経歴書の作成が負担に感じる場合は、AIを活用した職務経歴書の自動作成ツールを活用するのも一つの方法です。
職種・経験年数別 職務経歴書の例文集
「ITエンジニア」の職種は多様です。代表的な3パターンで職務要約の例文を紹介します。自分の状況に近いものをベースにカスタマイズして使用してください。
バックエンドエンジニア（経験3〜5年）の例文
職務要約 例文
Javaを主軸としたバックエンド開発を4年経験。社内向けBtoB SaaSおよびECプラットフォームのAPI設計・実装に従事しました。直近2年はリードエンジニアとして3〜5名のチームを担当し、コードレビューと設計レビューを通じてチームの品質底上げに貢献しています。スケーラブルなAPI設計とCI/CD整備に強みがあります。
インフラ・クラウドエンジニアの例文
職務要約 例文
AWSを中心としたクラウドインフラの構築・運用を5年経験。オンプレミス環境のAWS移行プロジェクトを3案件リード（総額約2億円規模）し、インフラコスト平均30%削減を実現しました。直近はKubernetesを用いたコンテナ運用基盤の整備と、SRE観点での可用性改善（月間稼働率99.95%維持）を担当しています。
経験3年未満・第二新卒ITエンジニアの例文
経験が浅い場合は、実績の大きさより「学習の速さ」「チームへの貢献姿勢」「これからの方向性」を前面に出します。
職務要約 例文（経験2年）
Webアプリケーション開発を2年経験。フロントエンド（React）とバックエンド（Node.js / Express）を担当し、社内業務効率化ツールの新規開発から保守・運用まで幅広く関わりました。現在はデータベース設計とクラウド（AWS）の知識を深めており、フルスタックでの開発業務を担えるエンジニアを目指しています。
ITエンジニアがやりがちなNG例と採用担当者の本音
書類選考で落とされるITエンジニアの職務経歴書には、共通したパターンがあります。3つのNG例と改善策を紹介します。
NG例①：使用技術の羅列だけで終わっている
NG例
【スキル】Java / Python / AWS / Docker / Kubernetes / MySQL / PostgreSQL / React / Vue.js
習熟度・経験年数・「何のために使ったか」がゼロ。採用担当者には何も伝わらない
改善策：カテゴリ別×習熟度の表形式に変更し、主要スキルには「〇年（〇〇に活用）」と補足します。単なる名前の羅列ではなく、自分がそのスキルで何をできるかが伝わる構成にします。
NG例②：役割が「メンバー」としか書いていない
NG例
【役割】メンバー
チームの何人中の一人か、どんな業務を担ったかが不明。「存在しただけ」と同じ印象
改善策：「8名チームの実装担当。決済モジュールの設計・実装を一人で完結させた」のように、規模・担当業務・具体的な貢献を明記します。
NG例③：成果が「〜に貢献しました」で終わる
NG例
パフォーマンス改善に貢献しました。チームのレベルアップに貢献しました。
「貢献した」は証明にならない。何をどれだけ改善したかの数字がなければ評価できない
改善策：「ページ読み込み速度を4秒→0.9秒に改善（Lighthouse スコア +35点）」のように、改善前後の数値をセットで記載します。数値化が難しい場合は「〇〇件のコードレビューを毎週実施し、バグ混入率を前期比30%削減」のように活動量や改善率で補います。
書き方の改善が難しい場合は、専門家の視点を借りるのも選択肢です。職務経歴書の有料添削サービスでは採用担当者目線でのフィードバックを受けられます。
まとめ
- 採用担当者は30秒で書類を判断する。冒頭の職務要約で「何者か」を明確に伝える
- 技術スキルはカテゴリ別×習熟度で整理し、「何に使えるか」まで書く
- プロジェクト経歴は「課題→技術選択→実績」の3点セットで再現性を伝える
- チームでの役割は「規模×ポジション×具体的な担当業務」で明示する
- 成果は数値で示す。数値化が難しい場合は活動量や改善率で代替する
職務経歴書は「何を書くか」より「採用担当者に何が伝わるか」で評価が決まります。技術力があっても書き方次第で選考結果が変わる以上、時間をかけて作りこむ価値があります。
ITエンジニアの職務経歴書に関するよくある質問
- ITエンジニアの職務経歴書は何ページが適切ですか？
-
経験年数によって目安が異なります。3年未満であればA4で2ページ、3〜8年程度であれば2〜3ページ、それ以上の経験がある場合は3〜4ページが目安です。ページ数より中身の質が重要で、最新の経歴・スキルが読みやすく整理されていることが優先されます。
- 副業・個人開発の経験は職務経歴書に書いてもいいですか？
-
記載して問題ありません。ただし副業・個人開発は「職務経歴」とは別のセクション（「その他の活動」「自己研鑽」など）に分けて記載するのが一般的です。GitHubのリポジトリURLや成果物のリンクを添付できると、技術力の客観的な証明になります。現職でできない技術に触れている場合は積極的にアピールしましょう。
- スキルシートと職務経歴書は何が違うのですか？
-
スキルシートは主にSES（システムエンジニアリングサービス）業界で使われる独自のフォーマットで、技術スキルやプロジェクト経歴を一覧化した書類です。職務経歴書は転職市場全般で使われる汎用的な応募書類で、スキル以外に職務要約・自己PR・資格なども含みます。転職活動では職務経歴書が標準ですが、SES案件の応募ではスキルシートを求められることもあります。
コメント