この記事では、IT・エンジニア職の職務経歴書の書き方を採用担当者の視点から解説します。職務要約・プロジェクト経歴・技術スキル一覧・自己PRの書き方と、書類選考を通過するためのNG例・合格例文をまとめました。
IT職務経歴書の基本構成と採用担当者が確認する3つのポイント
IT職務経歴書を受け取った採用担当者が最初の確認に使う時間は、平均30秒程度とされています。この短い時間の中で「面接に呼ぶかどうか」の判断を下すため、何をどの順序で書くかが選考結果を左右します。
採用担当者がIT職務経歴書で最初に確認する3つの項目
採用担当者の視点で見ると、IT職務経歴書で最初に確認するのは次の3点です。
採用担当者が最初に確認する3つの項目
- 職務要約：どんな領域で何年経験があり、何が得意なのかが一目で分かるか
- プロジェクト経歴：関わったプロジェクトの規模・役割・使用技術が具体的に書かれているか
- 技術スキル：求める開発言語・フレームワーク・インフラ技術と合致しているか
逆に言えば、この3点が即座に読み取れない構成になっていると、それだけで選考が止まります。「スキルはあるのに書類で落ちる」という場合、多くはこの3点がページの読みやすい位置に配置されていないことが原因です。
IT職務経歴書の標準的な記載項目と順序
IT業界の職務経歴書に特有のフォーマットを下表に整理しました。
| 記載項目 | 概要 | 優先度 |
|---|---|---|
| 職務要約 | 経験年数・専門領域・強みを3〜5行で | 最重要 |
| 職務経歴（プロジェクト一覧） | 期間・案件名・規模・担当業務・開発環境・役割 | 最重要 |
| 技術スキル一覧 | 言語/DB/クラウド/ツール別にレベル明記 | 必須 |
| 資格・認定 | 取得年月・正式名称で記載 | あれば記載 |
| 自己PR | 強み・スタンス・志向をエンジニア視点で | 必須 |
記載順序は職務要約 → 職務経歴（プロジェクト一覧）→ 技術スキル → 自己PRが標準です。資格は技術スキルの後か、職務要約内で触れる形でも構いません。
職務要約の書き方｜採用担当者が最初に読む冒頭3〜5行
職務要約は職務経歴書の「顔」です。ここで採用担当者の興味を引けるかどうかで、残りのページを読んでもらえるかが決まります。多くのITエンジニアは職務要約を「経歴の箇条書き」にしてしまいますが、採用担当者が本当に読みたいのは「何が得意で、自社に入ったら何を解決できる人か」という一文です。
職務要約に必要な3つの要素
採用担当者の目に止まる職務要約には、次の3要素が含まれています。
- 専門領域と経験年数：「Webアプリ開発を中心に7年」「インフラ構築・運用を5年」など
- 扱ってきた技術スタック：主要言語・フレームワーク・クラウドを2〜3つに絞って明記
- 最大の強み（ひとこと）：「要件定義から保守まで一貫して担当」「大規模チームのTL経験あり」
これらを3〜5行の段落にまとめます。箇条書きにする必要はありません。読みやすい文章で書くほうが、採用担当者に「話が通じる人」という印象を与えられます。
職務要約のNG例と合格例文
同じ経歴でも、書き方で印象が大きく変わります。NG例と合格例文を比較してください。
NG例
Java、Spring Boot、MySQL、AWS（EC2/S3/RDS）、Docker、Git使用経験あり。スキルの羅列になっており、何を解決できる人かが全く伝わらない。採用担当者はこれを見てもその人の強みが把握できません。
合格例文
Javaを中心としたWebアプリ開発を7年担当してきました。バックエンドAPIの設計から実装・テストまでを一貫して担当し、直近3年はAWS（EC2/RDS/Lambda）を使ったクラウドネイティブな開発に携わっています。チームリーダーとして5名のメンバーをマネジメントした経験もあり、技術面だけでなく開発プロセスの改善にも取り組んできました。
合格例文のポイントは「言語→実務での役割→規模感→強み」という流れで書いていることです。採用担当者は読んだ瞬間に「7年のJavaエンジニアでTL経験あり、クラウドも使える」と理解できます。
プロジェクト経歴の書き方｜採用担当者が重視する4つの必須記載事項
プロジェクト経歴欄は、IT職務経歴書の中で最もボリュームを割くべきセクションです。採用担当者は「どのようなプロジェクトで、どんな役割を担ったか」を確認することで、自社の業務に活かせるかどうかを判断します。
4つの必須記載事項と書き方
プロジェクト経歴欄に必ず含める4項目を整理します。
| 項目 | 記載内容 | よくあるNG |
|---|---|---|
| プロジェクト概要 | 何のシステムを、誰のために開発したか（2〜3行） | システム名だけで内容が分からない |
| 担当業務 | 要件定義〜運用のどのフェーズを担当したか | 「開発全般」など抽象的な表現 |
| 開発環境 | OS・言語・DB・フレームワーク・クラウドを明記 | バージョンや利用規模が不明 |
| 規模・役割 | チーム人数と自分のポジション（開発・PL・PMなど） | 規模の記載がなく実力が測れない |
プロジェクト経歴のNG例と通過する書き方
NG例
【20XX年4月〜20XX年3月】ECサイト開発
担当：開発全般
環境：Java、MySQL
規模・役割・フレームワーク・クラウド環境が全て不明。採用担当者には「何ができる人か」が伝わりません。
合格例文
【20XX年4月〜20XX年3月】大手小売チェーン向けECサイトリニューアル
・概要：月間100万PVのECサイトをリニューアル。購買フローの改善とAPI連携の強化を担当
・役割：バックエンドエンジニア（チーム8名、うち開発4名）
・担当フェーズ：詳細設計・実装・単体テスト・結合テスト
・環境：Java17 / Spring Boot 3 / MySQL 8.0 / AWS（EC2/RDS/S3） / Docker / Git
プロジェクト数と記載ボリュームの目安
記載するプロジェクト数は、直近3〜5年分を詳しく、それ以前は簡潔にまとめるのが原則です。経験年数が長い場合、すべてのプロジェクトを細かく書くと10ページを超えてしまい、採用担当者が読む気をなくします。
- 直近3〜5年：詳細記載（1案件あたり5〜10行）
- それ以前：案件名・期間・技術スタックを1〜2行で簡潔に
- 合計ページ数：2〜3ページが標準（A4で4ページを超えると読まれにくい）
SES・客先常駐のプロジェクトはどう書くか
SESや客先常駐のエンジニアは「会社名が書けない」「守秘義務がある」という悩みを持つ方が多くいます。プロジェクト概要は業種・規模・目的を中心に書けば問題ありません。会社名を書く義務はなく、採用担当者も想定済みです。
SES・客先常駐の場合の書き方例
【20XX年6月〜20XX年3月】大手金融機関向け勘定系システム保守・改修
・概要：地方銀行の勘定系システムの保守・機能追加を担当
・役割：開発メンバー（チーム12名）
・担当フェーズ：詳細設計・実装・単体テスト
・環境：COBOL / IBM AS/400
技術スキル一覧の書き方｜ただの羅列では評価されない
技術スキル一覧は、採用担当者がスクリーニングに使う重要なセクションです。ここでの最大のミスは「とにかくたくさん書けばいい」という発想です。一度でも触ったことのある技術を全部列挙すると、自分の強みが埋もれてしまいます。
スキルシートの正しいフォーマットとレベル表記
技術スキルはカテゴリ別に整理し、それぞれにレベルを明示します。レベルの基準は「業務使用年数」または「習熟度（4段階）」が一般的です。
| カテゴリ | 技術名 | 経験年数 | レベル目安 |
|---|---|---|---|
| 言語 | Java | 7年 | 業務レベル（チームリード可） |
| 言語 | Python | 2年 | 業務レベル（独立して実装可） |
| フレームワーク | Spring Boot | 5年 | 業務レベル |
| クラウド | AWS（EC2/RDS/Lambda） | 3年 | 業務レベル（設計・構築経験あり） |
| DB | MySQL | 6年 | 業務レベル |
| ツール | Git / GitHub | 6年 | 業務レベル |
採用担当者が「使えるスキル」と判断する書き方の工夫
採用担当者が注目しているのは「スキルの量」より「スキルの深さと活用実績」です。以下の3点を意識すると、同じスキルでも採用担当者の評価が変わります。
採用担当者はここを見ている
- 業務使用か独習かの区別：「業務経験あり」と「個人学習」を明記する。業務使用のほうが評価が高い
- 使用規模の記載：「100万件以上のデータ処理に使用」「月間10万ユーザーのシステムで運用」など規模感を添える
- 主力スキルの明示：スキル一覧の冒頭に「主力：Java（7年）、AWS（3年）」と一行添えると採用担当者の目に止まりやすい
職務経歴書の作成が難しい場合は、職務経歴書の自動作成ツールを活用する方法もあります。
自己PRの書き方｜ITエンジニアとしての強みを採用担当者に伝える
自己PRは「自分の良いところを書く欄」ではなく、「この人を採ると何が得か」を採用担当者に答える欄です。ITエンジニアの自己PRで多いのは「責任感があります」「チームワークを大切にします」といった抽象的な記述ですが、これでは採用担当者に何も伝わりません。
IT転職で評価される自己PRの3要素
- 技術的な強みの具体化：「コードレビューで品質担保」→「バグ発生率を前比30%削減」のように数値で示す
- 技術外のスキル：コミュニケーション・課題発見・提案力など、エンジニアが伸びにくいスキルをアピール
- 志向・スタンス：どんなエンジニアになりたいか・どの領域を伸ばしたいかを端的に
状況別の自己PR例文
例文①：開発経験5〜7年、リーダー経験あり
バックエンド開発を軸に7年のキャリアを積み、直近3年はチームリーダーとして5〜8名のメンバーのマネジメントを担当しました。レビュープロセスの整備によりバグ件数を前比40%削減した実績があります。技術力とチームマネジメントの両立を強みとし、開発効率の改善とメンバーの成長支援に貢献できます。
例文②：開発経験3年程度、スペシャリスト志向
Pythonを使ったデータパイプライン構築を3年担当しており、特にAWS環境でのバッチ処理とAPI設計に強みがあります。個人でも機械学習の学習を継続しており、データエンジニアリングとML連携の領域をさらに深めていきたいと考えています。確実な実装と分かりやすいドキュメント作成を心がけており、チームの技術共有に積極的に貢献します。
書類選考で落ちるIT職務経歴書の5つの特徴
採用担当者の視点からまとめた、書類選考で落とされやすいIT職務経歴書の典型的なパターンを紹介します。自分の職務経歴書に当てはまるものがないか確認してください。
- 技術スタックの羅列だけで「何ができるか」が書かれていない：使用した技術の一覧はあるが、どのプロジェクトでどう使ったかが不明
- プロジェクトの規模・役割が不明瞭：チーム人数・担当フェーズ・自分のポジションが書かれておらず、力量が測れない
- すべてのプロジェクトを均等に書いている：古いプロジェクトも新しいプロジェクトも同じ分量で書いており、どれが主力かが分からない
- 成果・改善点が一切記載されていない：業務の説明はあるが「その結果どうなったか」「自分が何を改善したか」がない
- フォントサイズが小さく情報を詰め込みすぎている：A4に情報を詰め込んで文字が小さく、読む気をなくさせる。2〜3ページに収めるべき
自分では気づきにくい問題は、転職エージェントや添削サービスを使って第三者の視点で確認するのが有効です。書き上げた職務経歴書をプロに添削してもらうことで、見落としていた課題に気づけます。
まとめ
- 採用担当者が最初に確認するのは「職務要約・プロジェクト経歴・技術スキル」の3点
- 職務要約は「専門領域・技術スタック・最大の強み」を3〜5行でまとめる。スキル羅列はNG
- プロジェクト経歴には「概要・担当業務・開発環境・規模と役割」の4項目を必ず記載する
- 技術スキルはカテゴリ別に整理し、経験年数とレベルを明示する
- 自己PRは「採用側にとって何が得か」を具体的な数値・事例で示す
書類選考は「スキルの有無」ではなく「伝え方」で決まります。採用担当者が30秒で判断できる構成を意識して、職務経歴書を作り込んでください。
IT職務経歴書の書き方に関するよくある質問
- 職務経歴書はA4何枚が適切ですか？
-
2〜3枚が標準です。経験年数が長くても4枚を超えると採用担当者に負担をかけます。直近5年のプロジェクトを詳しく書き、それ以前は簡潔にまとめることで適切なボリュームに収められます。
- 業務で使っていない技術（独学）も書いていいですか？
-
書いても構いませんが、「業務経験あり」と「独学・学習中」を明確に区別して記載してください。業務経験として混同させると、面接で詰問されたときに困ることがあります。独学スキルは「その他（学習中）」として別枠にまとめると誠実な印象を与えられます。
- 職務経歴書に成果が書けない場合はどうすればいいですか？
-
成果が数値化できない場合でも「担当した機能の範囲」「改善した点」「担当フェーズとその比率」などで代替できます。「バグ修正対応を月平均10件担当」「コードレビューでチームの品質水準向上に貢献」のような形で、具体性を持たせた記述にしましょう。数値がないことより「何もアピールしていない」ことのほうが問題です。
- 未経験からIT転職する場合の職務経歴書の書き方は？
-
業務経験がない場合は、プログラミングスクールや個人開発の経験を「実績」として記載します。「開発したアプリの概要・使用技術・GitHubリンク」をプロジェクト経歴の形式に合わせて書くことで、スキルの具体性が伝わります。自己PRでは学習速度・自走力・向上心を具体的なエピソードとともに示しましょう。
コメント