IT職務経歴書の書き方｜採用担当者が落とすNG例と通過する例文

この記事では、ITエンジニア・SE・PMの転職で提出する職務経歴書の書き方を、採用担当者が選考で実際に見ているポイントから逆算して解説します。スキルシートとの違い、職種別のNG例、採用担当者の目に止まる例文を紹介します。

IT職務経歴書で書類選考を通過できない3つの落とし穴

IT転職で書類選考が通らない原因の多くは、スキルや経験の不足ではなく、職務経歴書の「見せ方」の問題にあります。採用担当者が実際に選考で遭遇する典型的な失敗パターンを3つ確認します。

落とし穴①スキルを「列挙」するだけで「価値」が伝わらない

技術スキルの欄に「Java・Python・AWS・Docker・Git」と書いてある職務経歴書は珍しくありません。しかし採用担当者からすると、その羅列だけでは「この人を採用したら何を任せられるか」が見えません。

スキルは「使える道具の名前」ではなく、「その道具で何を実現したか」で書くことが選考通過のカギです。

落とし穴②プロジェクト経歴で担当フェーズと規模が不明

「開発業務を担当していました」の一文だけでは採用担当者に何も伝わりません。要件定義からテストまで一人でこなしたのか、5名チームの一員として実装だけを担当したのかでは、評価がまったく異なります。

採用担当者が職務経歴書を見て最初に確認するのは、「このエンジニアに何を任せられるか」という点です。担当フェーズ・チーム規模・自分の役割を明確に書くことで、その問いに答えられる職務経歴書になります。

落とし穴③採用担当者が読めない技術用語の多用

書類選考の最初の担当者が必ずしもエンジニアとは限りません。人事担当者や採用代行が一次スクリーニングを行うケースも多く、技術的な詳細だけが詰め込まれた職務経歴書は「読みにくい」と判断されることがあります。

技術的な内容は必要ですが、節目ごとに「何を目的とした作業か」を一言添えると、専門知識を持たない読み手にも伝わります。「Kubernetes上でマイクロサービスアーキテクチャを実装」と書く場合は、「複数のアプリケーションを分割・連携させる仕組みをKubernetesで構築」と補足を入れるだけで読みやすさが大きく変わります。

IT職務経歴書の基本構成と各項目の書き方

ITエンジニアの職務経歴書に必要な項目は5つです。スキルシートとは別に、採用担当者が読むことを前提とした「読ませる書類」として設計することが重要です。

項目	目安の分量	目的
職務要約	200〜250文字	キャリアを一行で定義し採用担当者の興味を引く
スキルシート	技術ごとに経験年数・用途を記載	即戦力としての技術力を証明する
プロジェクト経歴	案件ごとに7要素を記載	具体的な実績と担当範囲を伝える
自己PR	300〜400文字	人柄・仕事への姿勢・転職理由の一貫性を示す
資格・学歴	必要最小限	基礎条件の確認・補足

職務要約（冒頭3〜4行で自分を定義する）

職務要約は職務経歴書の冒頭に置く「自分の紹介文」です。採用担当者が最初に目を通す箇所であり、ここで「もっと読みたい」と思わせるかどうかが通過率に直結します。

「誰が・何を・どんな成果で・何年間」の4点を200文字程度でまとめるのが基本です。

スキルシートの書き方（習熟度付きで一覧化する）

スキルシートは言語・フレームワーク・データベース・インフラ・ツールの5カテゴリに分類して表形式で書くのが一般的です。SES（客先常駐）で使い回してきた書式をそのまま流用するのではなく、「採用担当者が読む書類」として再設計することが重要です。

スキルシートの記載例（一部抜粋）:

カテゴリ	技術	経験年数	レベル・用途
言語	Java	7年	業務レベル / バックエンドAPI設計・開発
言語	Python	2年	業務レベル / データ分析パイプライン構築
フレームワーク	Spring Boot	5年	業務レベル / REST API構築
DB	MySQL	7年	業務レベル / クエリ最適化・インデックス設計含む
インフラ	AWS（EC2・RDS・S3）	3年	業務レベル / 本番環境構築・運用
ツール	Git / GitHub	7年	業務レベル / チーム開発・コードレビュー担当

プロジェクト経歴の書き方（必ず書くべき7つの要素）

プロジェクト経歴は職務経歴書の中で採用担当者が最も時間をかけて読むセクションです。案件ごとに以下の7要素を必ず記載してください。

• 期間：「2023年4月〜2024年3月」のように開始・終了月を明記
• 案件名・業種：「EC系SaaSプラットフォーム開発（小売業向け）」
• チーム規模：「8名（PM1名・SE3名・PG3名・テスト1名）」
• 担当フェーズ：「要件定義・基本設計・詳細設計・製造・結合テスト」
• 担当業務：具体的な作業内容を箇条書きで3〜5点
• 使用技術：「Java 17 / Spring Boot 3 / MySQL 8 / AWS（EC2・S3・RDS）/ Docker / GitLab CI」
• 成果・工夫点：「API応答速度を40%改善」「障害件数を月平均3件から0件に削減」など数値化できるものは数値で表記

プロジェクト経歴の整理方法が難しい場合は、エンジニアの職務経歴書の実践的な書き方も参考になります。

自己PRの書き方（ITエンジニアならではの3つの視点）

ITエンジニアの自己PRで採用担当者が確認したいのは「技術力の高さ」だけではありません。以下の3点を意識して書くことで、技術者としての人物像が伝わりやすくなります。

• 課題解決の姿勢：技術スキルを「どんな問題解決に活かしてきたか」を具体的に書く
• チームへの貢献：コードレビュー・技術的負債解消・メンバー育成など、個人プレー以外の実績
• 転職理由との一貫性：次の職場で何を実現したいかが、これまでの経歴と自然につながっているか

採用担当者がIT職務経歴書で必ず確認している4つの視点

採用担当者は1〜2分の時間で職務経歴書の可否を判断します。その短時間で必ずチェックされる4つの視点を理解しておくと、何を強調して書くべきかが明確になります。

視点①フェーズと役割の明確さ（上流か下流か）

採用担当者が特に気にするのは、「このエンジニアは何を”決める”立場だったか」です。要件定義・基本設計を担当していたのか、製造・テストがメインだったのかは、市場価値を大きく左右します。

担当フェーズを「要件定義・基本設計・詳細設計・製造・単体テスト・結合テスト・運用保守」の中から選んで明記するだけで、読み手の理解が格段に上がります。上流経験があるのに書いていない場合は、選考で大きな機会損失につながります。

視点②チーム規模と自分のポジション

「チーム開発を経験してきました」という記述は実質的に情報ゼロです。5名のチームで実装を担当したのと、50名のプロジェクトでリーダーを担当したのでは、まったく異なる評価になります。

採用担当者は採用ポジションの要件と、応募者のチームでの立ち位置を照合しています。「チーム8名中、バックエンド開発リード」のように数値と役割を合わせて記載するのが最も伝わりやすい形です。

視点③直近3〜5年のスキルの深まり

IT業界では技術の移り変わりが速く、採用担当者が重視するのは「今・これから使えるスキル」です。10年前の技術経験よりも、直近3〜5年の実績を中心に書くことを意識してください。

経歴が長いエンジニアほど古い案件を詳しく書きがちですが、採用担当者が確認したいのは直近の成長履歴です。A4の1〜2枚目に直近の経歴を濃く書き、それ以前は概要表にまとめる構成が効果的です。

視点④転職軸と職務経歴の整合性

「上流工程に携わりたいため転職します」と言いながら、職務経歴書の全案件が製造・テストのみでは、採用担当者に「実現可能か」という疑問が生まれます。

少しでも希望のフェーズや役割に関わった経験があれば、意識的に前面に書くことが重要です。「担当業務の一部として要件定義のヒアリングに同席していた」という経験でも、「上流工程への参加経験あり」として記載できます。

【IT職種別】書き方のポイントとNG・OK例文

IT職種によって採用担当者が重視するポイントは変わります。自分の職種に当てはまる項目を確認してください。

SE・システムエンジニアの場合

SEが職務経歴書で意識すべきは「業種×フェーズ×規模」の3点セットです。金融系SIerで上流から携わった経験と、スタートアップで全フェーズを担当した経験では、まったく異なる強みとして評価されます。

• 業種を明記する：金融・製造・医療・流通など、経験した業種は具体的に書く。業種によって求められる知識が変わるため、採用担当者が重視する項目のひとつ
• 担当フェーズを詳しく：上流工程（要件定義・基本設計）の経験は必ず強調する。製造のみの案件でもフェーズ参加の補助経験があれば記載する
• プロジェクト数が多い場合：直近3〜5件を詳細に記載し、それ以前は案件名・期間・使用技術のみの一覧表にまとめる

インフラエンジニアの場合

インフラエンジニアの職務経歴書で採用担当者が特に確認するのは、「どの規模の環境を何の目的で構築・運用したか」です。技術名だけでなく、その技術で何を守り・何を実現したかを伝えることが重要です。

• 担当サービスと規模：AWS・GCP・Azure・オンプレの内訳と、サーバー台数・処理ユーザー数などの規模を数値で記載する
• IaC（コード化）経験：Terraform・Ansible・CloudFormationなどのIaCツール使用経験は積極的に書く。クラウド時代では重要度が高い
• 運用実績：SLAの達成率・障害件数の削減・平均復旧時間（MTTR）などの数値を使って実績を示す

PM・プロジェクトマネージャーの場合

PMは技術力よりも「組織・チームをどう動かしたか」の実績が評価の中心です。採用担当者が確認するのは、どんな規模のプロジェクトを、どんな成果で完了させたかです。

• プロジェクト規模：チーム人数・期間・取引先の規模など、プロジェクトの大きさがわかる情報を数値で書く
• 成果指標：「コスト削減15%」「リリース2ヶ月前倒し」「品質不具合率を50%削減」など、結果を数値化して記載する
• ステークホルダー管理：顧客折衝・外部ベンダー管理・上位組織への報告など、横断的なコミュニケーション経験も書く

IT転職が初めての場合（ポテンシャル採用・第二新卒）

業務経験のないIT未経験者や、経験1〜2年の第二新卒の場合は、職務経歴書の構成を工夫する必要があります。採用担当者が確認したいのは「この人は入社後に成長できるか」という視点です。

• 個人開発・副業経験：業務外で作ったサービス・アプリがあれば記載する。GitHubのURLを載せる場合はREADMEが整ったリポジトリのみに絞る
• 学習履歴のストーリー：「何を・なぜ学び・何ができるようになったか」を書く。資格取得・スクール受講・業務改善のための学習など、成長の証拠を示す
• 前職の強みの転用：IT以外の経験（営業・事務・医療・製造など）があれば、IT職種への転用可能性として記載できる。医療事務経験はヘルスケアIT向けの案件で強みになるケースがある

職務経歴書の作成自体に時間がかかる場合は、自動作成ツールの活用も一つの手段です。

参考：職務経歴書の自動作成ツールおすすめ7選

まとめ

• IT職務経歴書は「スキルの羅列」ではなく「そのスキルで何を実現したか」を伝える書類である
• プロジェクト経歴には担当フェーズ・チーム規模・成果の3点を必ず含める
• 採用担当者が最重視するのは「この人に何を任せられるか」が伝わること
• 職種（SE・インフラ・PM・未経験）によって強調すべきポイントが異なる
• 書き終えたら「採用担当者の視点」で読み直し、2分以内に自分の強みが伝わるかを確認する

書類選考が通らない場合は、プロによる添削を活用する方法もあります。

参考：職務経歴書の有料添削おすすめ5選

IT職務経歴書に関するよくある質問

IT職務経歴書の適切な文字数・ページ数は？

A4で2〜3枚が目安です。プロジェクト経歴が多い場合でも、直近3〜5年を中心に絞り、それ以前は概要一覧表にまとめることで読みやすさが保てます。採用担当者が最初に確認する時間は平均1〜2分程度のため、ポイントを絞った構成にすることが重要です。

職務経歴書にGitHubのURLを記載しても問題ないですか？

記載は有効ですが、リポジトリの中身が整っている場合のみにしてください。READMEが書かれていない・写経のみのリポジトリは、記載しないほうがよい場合もあります。「看板となる1〜3件」に絞り、GitHubのURLとともに何を作ったかを一言添えると効果的です。

転職回数が多いITエンジニアの職務経歴書はどう書けばいいですか？

転職回数が多い場合でも、各案件での習得スキルと直近の成長履歴を丁寧に書くことで評価は変わります。離職理由の説明より「その経験を今の転職にどう活かすか」の視点で書くのが効果的です。SES（客先常駐）エンジニアも同様に、案件ごとの成果と技術習得に焦点を当てて記載してください。