この記事では、ITエンジニア・SE向けの職務経歴書の書き方を解説します。採用担当者が判断する5項目の記載方法、スキルシートとの違い、職種別の例文まで、転職活動に即使える情報をまとめています。
ITの職務経歴書とスキルシートは何が違うか
SES(システムエンジニアリングサービス)やフリーランス案件の獲得で使う「スキルシート」を、そのままIT転職の職務経歴書として提出するエンジニアは少なくありません。採用担当者はこの使い回しを一目で判断します。スキルシートと職務経歴書は、目的も受け手も根本的に異なる書類です。
| 書類 | 誰に見せるか | 何を伝えるか |
|---|---|---|
| スキルシート | 客先の技術担当者 | 使える技術スタックの一覧 |
| 職務経歴書 | 採用企業の採用担当者 | 技術力+成果+入社後の再現性 |
スキルシートをそのまま使い回してはいけない理由
スキルシートは「何の技術が使えるか」を箇条書きで列挙するフォーマットです。転職先の採用担当者が職務経歴書で知りたいのは「入社後にどのような貢献ができるか」であり、技術の羅列だけではこの問いに答えられません。
SESの現場では客先企業名を「A社(非公開)」と伏せた記載が一般的ですが、この表記のまま転職書類として提出すると、採用担当者はプロジェクトの規模や業界背景を把握できず、書類選考の判断材料にできません。
採用担当者はここを見ている
- プロジェクト規模と自分の役割:チーム何人中のリーダーだったか、設計・実装の何割を主担当したか
- 担当フェーズ:要件定義から運用保守まで、どのフェーズに強みがあるか
- 成果の定量化:「処理速度30%改善」「不具合件数を月5件→0件に削減」など数値での実績
転職を決意したタイミングで、職務経歴書はスキルシートとは別に「ゼロから書く」という前提で準備を始めてください。
ITの職務経歴書に必要な5つの項目と書き方
IT転職の書類選考で採用担当者が確認するのは、大きく5つの項目に集約されます。それぞれの項目で何を・どのように書けば選考通過率が上がるかを解説します。
①職務要約(冒頭3〜4行で勝負が決まる)
職務要約はA4で3〜5行(200〜300文字)程度のセクションです。採用担当者はここを読んで「続きを読む価値があるか」を判断します。「誰が・何を・どんな成果で」の3要素を1段落で完結させることが基本構造です。
職種と経験年数から始め、使用技術と担当領域を示し、定量的な実績または強みで締めるのが定石です。
良い例文
Webアプリケーション開発のバックエンドエンジニアとして5年の経験を持ちます。主にPHP/Laravelを用いたAPIサーバ開発を担当し、直近のプロジェクトでは月間100万リクエストを処理するシステムの設計・開発をリードしました。CI/CDパイプラインの整備によりリリースサイクルを3週間から1週間に短縮した実績があります。
NG例
バックエンドエンジニアです。PHPやLaravelが得意です。Webサービスの開発経験があります。チームで協力して仕事をすることができます。スキルと性格の羅列だけで成果がない典型例。採用担当者はこの書類から入社後のイメージを描けません。
②技術スキル一覧(習熟度を客観的に示す)
技術スキルは採用担当者が「即戦力か・育成が必要か」を判断する項目です。スキル名を列挙するだけでなく、経験年数と習熟度の目安を表形式で示すことが重要です。
| 技術・ツール | 経験年数 | 習熟度の目安 |
|---|---|---|
| PHP / Laravel | 5年 | 単独設計・実装・レビューが可能 |
| MySQL | 5年 | クエリ最適化・インデックス設計が可能 |
| Docker / Docker Compose | 3年 | 環境構築・運用が可能 |
| AWS(EC2・RDS・S3) | 2年 | 構築・運用が可能 |
| TypeScript / React | 1年 | 仕様を読みながら実装可能 |
「なんとなく触ったことある」というレベルのスキルを「経験あり」として並べると、面接で深掘りされたときに答えられず評価を下げます。習熟度は正直に書くことが、長期的に見てプラスに働きます。
③プロジェクト経歴(担当フェーズと成果を数値で語る)
IT転職の職務経歴書で最もボリュームを割くべきセクションです。採用担当者はここを読んで「この人がうちのチームに加わったときのイメージ」を描きます。プロジェクト経歴は直近3〜5件を記載し、古い経験ほど簡潔にまとめるのが基本です。
プロジェクト経歴に必須の記載項目
- プロジェクト概要:何のためのシステムか(業界・目的・月間規模など)
- チーム規模と期間:チーム〇人・期間〇ヶ月
- 担当フェーズ:要件定義/基本設計/詳細設計/実装/テスト/運用保守
- 使用技術:言語・フレームワーク・DB・インフラ・ツール(バージョンも記載)
- 自分の役割:リーダー/メンバー/主担当(全体実装の何%を担当したか)
- 成果・貢献:定量的な数値(パフォーマンス改善率・工数削減・不具合削減等)
成果を数値化しにくい業務の場合は、「〇〇機能を主担当として設計・実装し、リリース後の不具合件数ゼロを達成」のように結果の品質で語ることもできます。「数値が出せない」と判断する前に、チームへの貢献・コードレビュー件数・改善提案の採用件数など、別の切り口を探してみてください。
④自己PR(技術選定の理由とビジネス貢献を言語化する)
自己PRでエンジニアが陥りがちな失敗は、「コードを書くのが好きです」「常に新しい技術を学んでいます」といった抽象的な表現で終わらせることです。
採用担当者が自己PRで見たいのは、「なぜその技術を選んだか」「その判断がビジネスにどう貢献したか」という因果関係です。技術的な意思決定をビジネス課題の解決に結びつけて語れるエンジニアは、どのフェーズの企業でも重宝されます。
良い例文
既存のモノリシックなアーキテクチャのボトルネックを特定し、負荷の高い処理をマイクロサービスとして切り出す提案を行いました。チームへの技術的な説明と段階的な移行計画の立案を担当し、最終的にAPIレスポンスタイムを平均1.2秒から0.3秒に短縮しました。技術的な判断を常にビジネス課題の解決という観点から検討することを心がけています。
⑤ポートフォリオ・GitHubリンク(活動実態のあるものだけ掲載する)
GitHubやポートフォリオサイトのリンクを記載する場合は、活動実態のあるリポジトリだけを掲載することが鉄則です。コミット履歴が空のリポジトリや、チュートリアルをコピーしただけのコードは逆効果になります。
掲載するリポジトリには、READMEで「何を作ったか・なぜ作ったか・技術選定の理由」を簡潔に書いておくと、書類選考の印象が大きく変わります。特に転職先のエンジニアが面接官を担当する場合、GitHubの品質は細部まで確認されます。
職種・状況別の書き方のコツ
IT職務経歴書の書き方は職種や転職の状況によって強調すべきポイントが変わります。自分に当てはまるケースを確認してください。
SE・バックエンドエンジニアの場合
SE・バックエンドエンジニアが職務経歴書で差をつけるポイントは、開発工程のどのフェーズを担当できるかを明示することです。実装のみの経験者と、要件定義から関わった経験者では採用担当者の評価が大きく変わります。
- プロジェクト経歴に担当フェーズ(要件定義〜運用保守)を必ず明記する
- チームリーダー経験がある場合は、チーム規模・期間・成果をセットで記述する
- 採用担当者が面接で深掘りしやすい「設計判断の理由」を自己PRに1〜2箇所盛り込む
インフラ・クラウドエンジニアの場合
インフラエンジニアの職務経歴書は、クラウドサービス(AWS・GCP・Azure)の具体的な利用経験を技術スキル表に詳しく記載するのが基本です。コスト削減・可用性向上・障害対応などのインフラ改善実績を数値で示すことが評価につながります。
| 記載項目 | 記載例 |
|---|---|
| AWSサービス | EC2, ECS, RDS(Aurora), S3, CloudFront, Lambda |
| IaC | Terraform(3年)/ CloudFormation(1年) |
| モニタリング | Datadog, CloudWatch, PagerDuty |
| 実績(必須) | インスタンス最適化により月次コストを25万円削減(約40%削減) |
IT未経験から転職する場合
IT業界への未経験転職で「職務経歴書に書くことがない」と手が止まる方は多いですが、採用担当者が未経験者の書類で見るのは経験年数ではありません。
採用担当者はここを見ている
- 学習の目的と進捗が具体的か:「Pythonを独学中」ではなく「Pythonで家計管理ツールをGitHubに公開済み(〇月〜継続中)」と書く
- 前職の経験とIT業務の接続ができているか:営業経験→顧客ニーズのヒアリング力、事務経験→業務フローの把握と自動化への関心として言語化する
- 自走できる人材か:エラーの解決プロセスや学習継続の仕組みを自己PRに含める
書類を効率的に作成したい場合は、職務経歴書の自動作成ツールを活用することで、入力項目に沿って構成が整った書類を作れます。

採用担当者が即座に落とすNG例と改善策
IT業界の採用担当者が書類選考でNGと判断する書類には共通のパターンがあります。提出前に以下の3点を必ず確認してください。
NG①:技術名の羅列だけで成果がない
NG例
【使用技術】Java, Spring Boot, MySQL, Docker, Jenkins, AWS
【業務内容】ECサイトのバックエンド開発を担当しました。プロジェクト規模も担当フェーズも成果も一切ない。採用担当者はこの書類から「入社後のイメージ」を描けません。
改善例
【プロジェクト】アパレル向けECサイト(月間100万PV)のバックエンド開発
【規模】チーム8名(うちバックエンド3名)・期間12ヶ月
【担当】詳細設計・実装・コードレビュー(全バックエンド実装の約40%を主担当)
【技術】Java 17 / Spring Boot 3.x / MySQL 8.0 / Docker / AWS(EC2・RDS・S3)
【成果】カート処理の非同期化によりレスポンスタイムを1.5秒→0.4秒に改善
NG②:SESのスキルシートをそのまま転用
SESで使うスキルシートは、技術担当者が「この案件に合うか」を素早く判断するためのフォーマットです。転職先の採用担当者への職務経歴書とは、フォーマットの目的が根本的に異なります。
- 客先企業名が「A社(非公開)」等の表記のまま転用されており、業界・規模の背景が不明
- プロジェクト経歴が単語の箇条書きのみで、担当内容が文章として書かれていない
- 自己PRや志望動機欄がない・空白のまま提出されている
SES経験者はスキルシートを「素材」として扱い、職務経歴書は別途ゼロから構成を組み直す意識が必要です。
NG③:技術用語の表記揺れ・誤字脱字
IT系の採用担当者(エンジニア出身者が面接官を担当するケースも多い)は、技術用語の誤字・表記揺れを即座に察知します。これは「業務でも細部に注意できない人材」という印象を与えます。
| NG表記 | 正しい表記 |
|---|---|
| Javascript | JavaScript |
| Github | GitHub |
| Postgresql | PostgreSQL |
| AWS lambda / Lambda | AWS Lambda(書類内で統一) |
| react.js / React.JS | React |
提出前に公式ドキュメントや公式サイトで正式な表記を確認することを習慣にしてください。スペルチェックツールでは検出できない表記揺れは手動での確認が必要です。
IT職務経歴書の提出前チェックリスト
書き終えた職務経歴書は、以下のチェックリストで最終確認をしてください。
- 職務要約に「誰が・何を・どんな成果で」の3要素が含まれているか
- 技術スキル表に経験年数と習熟度の目安が記載されているか
- プロジェクト経歴に担当フェーズ・チーム規模・成果が記載されているか
- 自己PRに「技術選定の理由」または「ビジネス貢献」が含まれているか
- GitHubリンクを記載する場合、READMEとコミット履歴が整備されているか
- 技術用語の表記揺れ・誤字脱字がないか(公式表記を確認)
- SESスキルシートの書式・言い回しが混入していないか
- A4で2〜4ページ(経験3年未満は2ページ以内)に収まっているか
書類の完成度に不安がある場合は、転職エージェントや添削サービスに第三者視点の確認を依頼することが書類選考通過への近道です。職務経歴書の添削サービスを使えば、採用担当者目線の客観的なフィードバックを得られます。

まとめ
- スキルシートは技術の一覧、職務経歴書は「入社後の再現性」を伝える書類。目的が違うため使い回しは逆効果
- 職務要約・技術スキル表・プロジェクト経歴・自己PR・GitHubリンクの5項目が基本構造
- プロジェクト経歴は「規模・担当フェーズ・成果(定量)」の3点セットで記載する
- 自己PRは「技術選定の理由とビジネス貢献」を書くことで他の候補者との差がつく
- 技術用語の表記揺れは、エンジニア出身の採用担当者が即座に確認する注意ポイント
IT転職の書類選考で手が止まっているなら、転職エージェントへの相談が最も効率的な解決策です。無料で職務経歴書の添削や書き方アドバイスを受けられます。
ITの職務経歴書に関するよくある質問
- IT職務経歴書の枚数は何ページが適切ですか?
-
経験年数が3年未満の場合はA4で2ページ以内、5年以上の場合は3〜4ページが目安です。記載量よりも「プロジェクト経歴の具体性」が評価に影響するため、内容の薄い項目で枚数を水増しすることは避けてください。
- IT転職でポートフォリオは必須ですか?
-
必須ではありませんが、経験年数が浅い場合や転職回数が少ない場合は、GitHubやポートフォリオサイトへのリンクが書類選考の補強材料になります。ただし、コミット履歴が空のリポジトリや更新が止まっているサイトは掲載しないほうが無難です。
- IT未経験転職でも職務経歴書は必要ですか?
-
必要です。IT未経験転職では、前職の経験とIT転職への動機、学習の進捗と成果(GitHubへのポートフォリオ公開など)を具体的に書くことが重要です。採用担当者は経験の有無より「自走できる人材かどうか」を職務経歴書から判断します。
- SES経験しかない場合、職務経歴書はどう書けばいいですか?
-
SESのスキルシートをそのまま転用することは避けてください。「客先(非公開)」の表記はそのままでも問題ありませんが、プロジェクトの概要・チーム規模・担当フェーズ・成果を文章で丁寧に記載することが重要です。複数の短期案件がある場合は直近3〜5件に絞り、各プロジェクトの具体的な貢献を書きましょう。


コメント