IT転職の選考プロセスで最初の壁となるのが「書類選考」です。どれだけ高いスキルを持っていても、職務経歴書がうまく書けていなければ面接の機会すら得られません。一方で、職務経歴書の書き方を少し工夫するだけで、書類選考の通過率が劇的に変わることも珍しくありません。
筆者は以前、転職エージェントとして3年間で500名以上のエンジニアの転職を支援した経験があります。その中で「スキルは十分なのに書類でつまずく人」を何人も見てきました。この記事では、そうした経験をもとに、IT転職で書類選考を突破するための職務経歴書の書き方を、テンプレートとともに詳しく解説します。
IT転職の職務経歴書が一般職と異なる理由
IT・エンジニア職の職務経歴書は、一般的な事務職や営業職の書き方とは根本的に異なります。採用担当者や現場エンジニアが見ているポイントが違うからです。
一般職の職務経歴書では「どんな業務をしたか」「どんな成果を出したか」が中心ですが、エンジニアの場合はそれに加えて「どんな技術を使ったか」「どのくらいの規模・複雑さのプロジェクトに関わったか」「チームの中でどんな役割を担ったか」という技術的な文脈が非常に重要になります。
また、IT業界は職種の幅が広く、フロントエンドエンジニア・バックエンドエンジニア・インフラエンジニア・データエンジニアなど、求めるスキルセットが職種によって大きく異なります。そのため、応募先の職種に合わせて職務経歴書の内容を調整する「カスタマイズ」が、他の業界以上に重要になります。
採用担当者が職務経歴書を見るときの視点
IT企業の採用フローでは、職務経歴書を「人事担当者」と「現場エンジニア（技術レビュー）」の2段階でチェックするケースが多いです。それぞれ見ているポイントが異なります。
| レビュアー | 主に見るポイント | 重視する表現 |
|---|---|---|
| 人事担当者 | 全体の読みやすさ、転職理由の一貫性、職歴の空白 | 数字・成果、端的な説明 |
| 現場エンジニア | 使用技術の深さ、プロジェクト規模、担当フェーズ | 技術スタックの具体性、役割の明確さ |
| CTO・技術責任者 | 設計力・課題解決力、チームへの貢献 | 技術選定の理由、改善の実績 |
この2つの視点を満たすために、「わかりやすい文章」と「技術的な具体性」を両立させることが、IT転職の職務経歴書で最も難しく、かつ最も重要なポイントです。
職務経歴書の基本構成テンプレート
IT転職に特化した職務経歴書の推奨構成は以下の通りです。A4用紙2〜3枚に収めることを目安にしてください。
1. 職務要約（3〜5行）
職務経歴書の冒頭に置く「自己PR的なサマリー」です。採用担当者がここを読んで、続きを読みたいと思ってもらえるかどうかが決まります。以下の要素を盛り込みましょう。
- 総経験年数
- 主な担当領域・技術スタック
- 最も得意とすること・強み
- 今後やりたいこと（応募先に合わせて調整）
【記載例】Webアプリケーション開発に5年従事。主にPython（Django/FastAPI）を使ったバックエンド開発を担当し、直近ではマイクロサービスアーキテクチャへの移行プロジェクトをリード。チーム規模は最大8名。AWSを用いたインフラ構築経験もあり、フルサイクルでの開発が可能。今後はプロダクト開発全体を俯瞰できるバックエンドリードポジションを希望しています。
2. スキルシート（技術スタック一覧）
採用担当者が「自社の求めるスキルと合致しているか」を素早く判断できるよう、使用技術を一覧化します。単に羅列するのではなく、習熟度や経験年数を添えると効果的です。
| カテゴリ | 技術・ツール | 経験年数 | 習熟度 |
|---|---|---|---|
| 言語 | Python, JavaScript, TypeScript | 5年 / 4年 / 2年 | 実務で主力利用 / 実務利用 / 実務利用 |
| フレームワーク | Django, FastAPI, React | 4年 / 2年 / 3年 | 実務で主力利用 / 実務利用 / 実務利用 |
| DB | PostgreSQL, MySQL, Redis | 5年 / 3年 / 2年 | 実務で主力利用 / 実務利用 / 実務利用 |
| クラウド | AWS（EC2, RDS, S3, Lambda） | 3年 | 実務利用 |
| その他 | Docker, GitHub Actions, Terraform | 3年 / 2年 / 1年 | 実務利用 / 実務利用 / 学習中 |
3. 職務経歴詳細（プロジェクトごとに記載）
職務経歴書の中核となる部分です。プロジェクトごとに区切り、以下の項目を記載します。
- 在籍期間: 20XX年X月〜20XX年X月
- 会社名・事業内容: 業種と事業の概要
- プロジェクト概要: 何を開発したか、どんな目的のシステムか
- 担当フェーズ: 要件定義・設計・実装・テスト・運用保守のどこを担当したか
- 使用技術: 言語、FW、DB、インフラ等
- チーム規模・役割: 何名のチームで、自分の役割は何か
- 成果・工夫点: 定量的な成果、課題解決の工夫
プロジェクト経験の書き方：具体的な記載例
多くのエンジニアが苦手とするのが「プロジェクト経験の書き方」です。「何をやったか」は書けても、「どれだけ価値があったか」「どんな難しさを乗り越えたか」を伝えるのが難しいと感じる方が多いです。
NG例とOK例の比較
【NG例】ECサイトの開発を担当しました。PHPとMySQLを使って実装し、テストも行いました。
【OK例】月間30万UVのECサイトにおいて、商品検索機能のリニューアルをバックエンドリードとして主導。既存のMySQLフルテキスト検索をElasticsearchに移行し、検索レスポンス速度を平均1.2秒から0.15秒へ改善（87.5%短縮）。Symfony 4 + DoctrineのORM層にもカスタムリポジトリパターンを導入し、その後の機能拡張の工数を約30%削減する基盤を整備。チーム4名（BE2名、FE1名、QA1名）でスプリント管理しながら3ヶ月で本番リリースを達成。
OK例のポイントは以下の3点です。
- 規模感の提示: 「月間30万UV」という数字でプロジェクトの重要性が伝わる
- 具体的な技術選定の背景: なぜElasticsearchに移行したかが読み取れる
- 定量的な成果: 「87.5%短縮」「30%削減」という数字が説得力を生む
定量化できないときの書き方
「自分の業務は数字で表しにくい」という声もよく聞きます。しかし、実際に使ってみると「処理時間を何秒短縮した」「対応件数を月何件こなした」など、多くの業務は数字で表現できます。
- バグ修正件数・改善した不具合数
- 担当した機能数・ページ数
- コードレビューを行った件数・チームへの技術共有の回数
- テストカバレッジの改善率
- CI/CDの導入によるデプロイ時間の短縮
どうしても数字が出せない場合は、「チームの〇〇課題を解決するために〇〇を実施した」という課題→行動→結果の構造で記述すると、インパクトが伝わりやすくなります。
未経験・経験の浅いエンジニアの職務経歴書の書き方
「実務経験が1年未満」「スクール出身で転職を目指している」という方向けのアドバイスも補足します。経験が少ない場合でも、工夫次第で書類選考を突破することは十分可能です。
ポートフォリオとの連携を意識する
実務経験が少ない場合は、個人開発のポートフォリオがそのまま「実績」になります。職務経歴書にGitHubのURLや制作物のURLを記載し、採用担当者がすぐに確認できるようにしましょう。
ポートフォリオには以下を含めると評価されやすいです。
- 技術スタックと選んだ理由
- 工夫した点・苦労した点
- 今後追加したい機能
- READMEが整備されているか
学習経歴・資格の活用
スクール受講歴・オンラインコースの修了・IT系資格（基本情報技術者・AWS認定等）は、学習の本気度を示す材料として有効です。「資格欄」ではなく「スキル・資格」の項目として、スキルシートと合わせて記載するのがおすすめです。
未経験からのIT転職全体の流れについては、未経験からIT転職する方法の記事も参考にしてください。
転職エージェントによる添削を活用する
職務経歴書は「書いて終わり」ではなく、第三者のフィードバックを受けることで大きく改善できます。特に、IT専門の転職エージェントの添削は非常に効果的です。エージェントは毎日多数の職務経歴書を見ており、「何が通過しやすいか」「採用担当者はどこに注目するか」という実績データを持っています。
転職エージェントは無料で利用でき、書類添削・面接対策・求人紹介まで一気通貫でサポートしてくれます。IT転職エージェントの比較についてはIT転職エージェント比較の記事が参考になります。
職務経歴書作成で避けるべきNG行動
| NG行動 | なぜNGか | 改善策 |
|---|---|---|
| 全社共通のテンプレートをそのまま使う | 応募先の業務内容と合致しない記述が残る | 応募ごとに職務要約と強調スキルを調整する |
| 技術用語を羅列するだけ | 使いこなせているかが伝わらない | どのプロジェクトでどう使ったかをセットで記載 |
| 5年分の業務をすべて書く | 読む気がなくなる・重要な情報が埋もれる | 直近3〜5年・応募職種に関係の深い経験を厚く書く |
| 成果を主観的に書く | 「大幅改善」「多数の実績」は信ぴょう性が低い | 数字・割合・規模感を必ず入れる |
| 誤字脱字をそのままにする | 細部への注意力がないと判断される | 提出前にチェックツールと音読でダブルチェック |
職務経歴書提出後のフォロー
書類を提出したら、選考状況を記録しておくことをおすすめします。どの企業にどのバージョンの職務経歴書を送ったか、書類通過したか否かを管理することで、改善のPDCAを回しやすくなります。
書類が通らない場合、原因はいくつか考えられます。まず「スキルが応募要件を満たしていない」可能性。次に「職務経歴書の書き方が伝わっていない」可能性。前者は求人の難易度を下げるか並行して学習を続ける対応が必要ですが、後者は書き方の改善で対処できます。
書類選考の通過率が10%を下回る場合は、書き方に何らかの問題があるサインです。エージェントや転職仲間に見てもらい、率直なフィードバックを求めましょう。
IT転職の職務経歴書で重要なのは、「人事担当者にも現場エンジニアにも伝わる」書類を作ることです。職務要約・スキルシート・プロジェクト詳細の3構成を基本にし、数字で成果を示し、使用技術の具体性を高めることが書類通過への近道です。自分一人で行き詰まったら、IT専門の転職エージェントに添削を依頼することを強くおすすめします。正しい方向で努力すれば、書類選考の壁は必ず突破できます。