この記事では、SE(システムエンジニア)の職務経歴書テンプレートの構成と、採用担当者が書類をスクリーニングする際に見ている3つのポイントを解説します。プロジェクト経歴・テクニカルスキル・自己PRの項目別の書き方と、NG例・改善例を例文つきで紹介します。
SEの職務経歴書テンプレート:5つの基本構成
SEの職務経歴書は、一般職種とは構成が異なります。「どんなシステムを作ったか」だけでなく、どんな技術を使い、どのフェーズを担当し、どんな規模のプロジェクトに関わったかを採用担当者が一目で把握できる構成にする必要があります。
| 項目 | 目的・内容 | 目安文字数 |
|---|---|---|
| ① 職務要約 | 経歴全体を5行以内で圧縮する。応募先に合わせて調整する | 200〜250字 |
| ② 職務経歴詳細 | プロジェクト別に担当フェーズ・開発環境・規模を記載 | プロジェクト1件あたり100〜200字 |
| ③ テクニカルスキル | OS・言語・DB・ツールを分類し、使用期間と習熟度を記載 | 分類ごとに3〜8項目程度 |
| ④ 得意分野・業務知識 | 業界知識・ドメイン知識を記載(金融・製造・医療など) | 50〜100字 |
| ⑤ 自己PR | 「何ができる人か」をスキルだけでなく姿勢・成果で伝える | 200〜300字 |
① 職務要約
職務要約は採用担当者が最初に読む箇所です。「〇〇システムの開発を主に担当してきたSEです」という漠然とした書き方では読み進んでもらえません。応募先の業務内容に合わせて、得意な業種・フェーズ・役割を5行以内で書くのが基本です。
② 職務経歴詳細(プロジェクト経歴)
SEの職務経歴書の中核となる部分です。経験したプロジェクトを新しいものから逆順に記載します。直近のプロジェクトが採用担当者にとって最も重要な情報のため、古い順に書くと評価が下がりやすいです。各プロジェクトに記載すべき情報は次のとおりです。
- プロジェクト概要:どんなシステムを、どの業界のクライアントに対して開発したか
- 担当フェーズ:要件定義・基本設計・詳細設計・製造・テスト・運用保守のうちどこを担当したか
- チーム規模と役割:何人のチームで、自分はどのポジション(リーダー・メンバー等)だったか
- 開発環境:言語・フレームワーク・DB・OS・ツール
- 成果・貢献:納期・品質・コスト面での具体的な成果(可能な範囲で数字を使う)
③ テクニカルスキル
テクニカルスキルは、OS・プログラミング言語・データベース・フレームワーク・ツールを分類して記載します。単にツール名を並べるだけでなく、使用期間と習熟度(業務で単独使用可能・サポートあり等)を添えることが重要です。採用担当者はここで「即戦力かどうか」を最初に判断します。
④ 得意分野・業務知識
金融・製造・流通・医療など、これまで携わってきた業界のドメイン知識を記載します。同じ業界のシステム開発経験があれば、採用担当者に「業務知識の学習コストが低い」と評価されます。経験業種が複数ある場合は、応募先の業界に最も近いものを先頭に記載してください。
⑤ 自己PR
テクニカルスキルや経歴を補完する形で、「なぜ自分なのか」を伝える箇所です。「〇〇に精通しています」という能力の羅列は避け、具体的なエピソードと、それがどう成果につながったかを200〜300字でまとめます。
採用担当者が30秒で判断する3つのポイント
IT系の採用担当者は、1件あたり数十〜数百通の職務経歴書を確認します。最初のスクリーニングは30秒前後で行われ、ここを通過できなければ詳細を読んでもらえません。
採用担当者はここを見ている
- 担当フェーズは「上流か下流か」:要件定義・設計まで担当できるかどうかで即戦力の判断をする
- 直近プロジェクトの技術スタック:求人票の技術要件と職務経歴書の開発環境を30秒で照合する
- 役割の明確さ:チームの一員として動いていただけなのか、リードする立場だったのかを確認する
この3点が職務経歴書の冒頭(職務要約〜直近プロジェクト)で確認できない書類は、詳細を読まれる前に落とされます。「経験はあるはずなのに書類が通らない」場合、多くはここが原因です。
採用担当者がスキルシートで最初に確認するのは「テクニカルスキル一覧」ではなく「直近プロジェクトの担当フェーズと役割」です。職務要約と直近1〜2件のプロジェクトに、この3点が明記されているかどうかが通過の分岐点になります。
【項目別】SEの職務経歴書の書き方と例文
職務要約の書き方:5行で経歴を圧縮する
職務要約は「採用担当者への自己紹介文」です。業種・得意フェーズ・経験年数・直近の役割を5行以内で伝えます。応募するポジションによって最前面に出す経験を変えることで、書類通過率が大きく変わります。
職務要約に盛り込む4要素は次のとおりです。
- 経験年数と主な業種:「SE歴8年。金融・製造業向けのシステム開発を中心に」
- 担当フェーズの範囲:「要件定義からテストまで一貫して担当」「開発・テスト工程を主担当」
- 直近の役割:「直近3年間はチームリーダーとして3〜5名のメンバーをとりまとめ」
- 応募先への貢献イメージ:「Javaを用いたバックエンド開発のご支援が可能です」
良い例文
SE歴8年。金融・保険業界向けの基幹システム開発を中心に、要件定義から運用保守まで一貫して担当してきました。直近3年間はチームリーダーとして4〜6名をとりまとめています。JavaおよびSpring Bootを用いたバックエンド開発が主な専門領域です。
NG例
システムエンジニアとして様々なプロジェクトに携わってきました。チームワークを大切にし、常に品質向上を意識して業務に取り組んできました。「何の業種・技術・フェーズを担当したか」が一切書かれていないため、採用担当者は次の文章を読まない可能性が高いです。
プロジェクト経歴の書き方:採用担当者が読みたい記載要素
プロジェクト経歴は、SEの職務経歴書で最もボリュームを割くべき箇所です。採用担当者が最も時間をかけて読む部分でもあります。1件のプロジェクトに必要な記載要素を整理すると、次のようになります。
| 記載要素 | 書き方のポイント | 例 |
|---|---|---|
| プロジェクト名・概要 | 業界とシステムの種類を明記 | 「保険会社向け契約管理システムの新規開発」 |
| 期間・規模 | 開始〜終了年月とチーム人数を記載 | 「2023年4月〜2024年3月(12か月)、チーム8名」 |
| 担当フェーズ | 工程を明確に記載。曖昧な「開発全般」は避ける | 「要件定義・基本設計・詳細設計・製造・単体テスト」 |
| 役割 | リーダー/サブリーダー/メンバー+具体的な責任範囲 | 「サブリーダー。バックエンド開発チーム3名のマネジメント」 |
| 開発環境 | 言語・FW・DB・OSを記載 | 「Java 17 / Spring Boot 3.x / Oracle DB / Linux」 |
| 成果・貢献 | 数字で示せる場合は必ず数字を使う | 「テスト自動化により品質確認工数を40%削減」 |
採用担当者はここを見ている
- 「担当フェーズ」に要件定義・設計が含まれているかどうか(上流工程の経験の有無)
- 直近プロジェクトの言語・フレームワークが求人票の技術要件と一致しているかどうか
- 「リーダー」「サブリーダー」の記載があり、マネジメント経験が確認できるかどうか
テクニカルスキルの書き方:「知っている」と「使える」の差
テクニカルスキルで最も多い失敗は「ツール名を並べるだけ」の書き方です。採用担当者が確認したいのは「このスキルを業務で即戦力として使えるか」です。そのためには、スキル名・使用期間・習熟度の3点をセットで記載する必要があります。
| 分類 | 具体例 | 使用期間 | 習熟度 |
|---|---|---|---|
| 言語 | Java | 6年 | 業務で単独対応可 |
| 言語 | Python | 2年 | スクリプト作成・データ加工 |
| FW | Spring Boot | 4年 | 業務で単独対応可 |
| DB | Oracle | 5年 | クエリ作成・チューニング経験あり |
| OS | Linux(RHEL) | 5年 | 構築・運用経験あり |
習熟度の表現で迷う場合は、「業務で単独対応可」「指示があれば対応可」「コードリーディング程度」の3段階で整理するとわかりやすいです。古いバージョンしか使っていないスキルは、バージョンを明記するか記載を省略する判断が必要です。
自己PRの書き方:SEが差をつける3つの切り口
自己PRで差がつくのは、「スキル一覧の繰り返し」ではなく「なぜその人を採用したいか」が読み取れる内容です。SEの自己PRで採用担当者の目に止まりやすい切り口は次の3つです。
- 問題解決のプロセス:「開発中に発生した課題をどう特定し、どう解決したか」の具体的なエピソード
- チームへの貢献:「コードレビューの仕組みを整備して品質課題を解消した」など、組織への貢献が見えるもの
- 技術習得の姿勢:「新技術への学習スピード」「個人開発の経験」など、継続的に技術を磨いていることを示す
良い例文
金融系システムの開発において、リリース後の障害件数を継続的に減らすことを目標に取り組んできました。コードレビュー基準を整備し、チーム内でのレビュー文化を定着させた結果、リリース後の致命的バグが前年比60%減少しています。今後は上流工程への関与を深め、設計段階から品質を担保できるSEとして貢献したいと考えています。
職務経歴書の作成に時間がかかる場合は、職務経歴書の自動作成ツールを活用する方法もあります。AI搭載のツールを使えば、入力した情報から職務要約・テクニカルスキル欄を自動生成できます。

採用担当者が落とすSEの職務経歴書NG例3パターン
「経験は十分なのに書類が通らない」というSEに多く見られるNG書き方は、大きく3パターンに分類できます。自分の職務経歴書に当てはまっていないか確認してください。
NG1:プロジェクトが羅列になっていて役割が見えない
NG例
2020年〜2021年:〇〇社向け販売管理システム開発(Java/Oracle)
2021年〜2022年:△△社向け在庫管理システム改修(Java/MySQL)
2022年〜2023年:□□社向け勤怠管理システム開発(PHP/PostgreSQL)
プロジェクト名と期間・言語しか書かれておらず、担当フェーズ・役割・成果がまったくわからない書き方です。
このような書き方では「何人のチームのどんなポジションだったのか」「要件定義からできるのか製造のみなのか」が判断できません。採用担当者は30秒のスクリーニングでこの書類を保留にします。
改善策は、各プロジェクトに「担当フェーズ」「チーム規模と役割」「開発環境の詳細」「成果」の4点を追加することです。たとえプロジェクト数が多くなっても、この4点を省略する書き方は避けてください。
NG2:テクニカルスキルが名前だけのリスト
NG例
【言語】Java、Python、C++、PHP、JavaScript、TypeScript、Go、Ruby
【DB】Oracle、MySQL、PostgreSQL、MongoDB、Redis
【ツール】Git、Jenkins、Docker、Kubernetes、Ansible、Terraform
使用期間も習熟度も不明なまま大量のツール名が羅列されているパターンです。
このリストを見た採用担当者は「本当に使えるのか疑わしい」と判断します。スキルリストに使用期間・習熟度を添えることで、「このスキルは即戦力として期待できる」という信頼感が生まれます。
記載できる技術が多い場合は、「業務経験あり」と「個人学習レベル」を分けて記載するのが有効です。業務経験があるものを優先的に詳しく書き、学習レベルのものは補足情報として別記してください。
NG3:成果がなく業務内容しか書かれていない
NG例
【業務内容】
・要件定義書・基本設計書の作成
・詳細設計・プログラミング
・単体テスト・結合テストの実施
・チームメンバーへの技術指導
何をしたかは書いてあるが、その結果どうなったかが一切ない書き方です。
業務内容の記載は必要ですが、それだけでは「こなした」記録に過ぎません。採用担当者は「この人が入社したらどんな成果が出るか」を職務経歴書から判断しようとしています。成果を書く際、「数字がない業務」と感じることも多いですが、次のような数値化の切り口があります。
- 規模感:プロジェクト期間・チーム人数・画面数・テーブル数など
- 効率化:自動化による工数削減割合、バグ件数の削減率
- 改善:処理速度の改善(〇〇秒→〇〇秒)、レスポンスタイムの短縮率
提出前のセルフチェックリスト
作成が完了したSEの職務経歴書を提出する前に、次のチェックリストで確認してください。採用担当者が最初の30秒で判断するポイントが網羅されているかを確かめます。
| チェック項目 |
|---|
| 職務要約に経験年数・得意業種・担当フェーズ・役割が含まれているか |
| プロジェクト経歴が新しい順(逆順)に記載されているか |
| 各プロジェクトに担当フェーズ・役割・開発環境が記載されているか |
| 少なくとも1件のプロジェクトに数字を使った成果が記載されているか |
| テクニカルスキルに使用期間または習熟度が記載されているか |
| 自己PRが「スキル一覧の繰り返し」になっていないか |
| A4用紙2枚以内に収まっているか(長すぎる場合はプロジェクトを厳選) |
自分では判断しにくい箇所がある場合は、職務経歴書の添削サービスを利用する方法もあります。プロによる客観的なフィードバックが、書類通過率を改善することがあります。

まとめ
- SEの職務経歴書は職務要約・プロジェクト経歴・テクニカルスキル・得意分野・自己PRの5構成が基本
- 採用担当者は30秒のスクリーニングで「担当フェーズ・使用技術・役割の明確さ」を確認する
- プロジェクト経歴は新しいものから逆順に記載し、各件に担当フェーズ・役割・成果を添える
- テクニカルスキルは「スキル名+使用期間+習熟度」の3点セットで記載する
- 自己PRは「スキル一覧の繰り返し」を避け、エピソードと成果を具体的に書く
書類を作成したら提出前にセルフチェックリストで確認し、採用担当者のスクリーニングを通過できる内容になっているかを確かめてください。
SEの職務経歴書テンプレートに関するよくある質問
- SEの職務経歴書はA4何枚が適切ですか?
-
経験年数にもよりますが、A4用紙2枚以内が基本です。3年未満なら1〜2枚、5年以上なら2枚にまとめることを目標にしてください。プロジェクト数が多い場合は、直近3〜5件を詳しく書き、古いプロジェクトは簡略化または省略します。
- SEの職務経歴書テンプレートはWordファイルで無料ダウンロードできますか?
-
doda・リクルートエージェント・JAC Recruitmentなど主要な転職サービスが、SE向けのWordテンプレートを無料で配布しています。ただし、テンプレートはあくまで「構成の型」です。そのまま使うのではなく、担当フェーズ・成果・習熟度の記載を自分の言葉で書き加えることが重要です。
- 転職回数が多いSEの職務経歴書はどう書けばいいですか?
-
転職回数より「各プロジェクトで技術スキルがどう深まったか」の一貫性を示すことが重要です。職務要約で「〇〇領域のスペシャリストを目指して経験を積んできた」という軸を明確にし、プロジェクト経歴でそのストーリーを裏付ける構成にします。技術習得に積極的なエンジニアとして見てもらえる書き方が有効です。
- 社内SEの職務経歴書の書き方は一般SEと違いますか?
-
社内SEの場合、ベンダーとの折衝・要件整理・ユーザー対応など「業務知識と調整力」が評価される点が一般SEと異なります。開発技術の記載に加え、社内業務の効率化・システム選定・ベンダーコントロールの経験を明記してください。IT導入によるコスト削減額や業務効率化の数値があれば積極的に記載します。


コメント