仕事・転職

ITエンジニアの職務経歴書の書き方【2026年】｜必須6項目と、スカウト型で変わる3原則

最終更新日：2026年9月10日 　／　著者：Direct type編集部 　／　監修：中嶋 千博（キャリアアドバイザー）

もしあなたがITエンジニアの経験者で書類通過ができない場合、その原因は経験不足なのではなく、職務経歴書に原因があるかもしれません。 その職務経歴書は、単にスキルの羅列になっていないでしょうか。使える言語とフレームワークを並べただけの書類からは、「この人に何を任せられるのか」が読み取れません。

また、意外と知られていないのが、応募型かスカウト型かによって「書類通過する職務経歴書」の正解がまったく変わってくるということです。

1. ITエンジニアの職務経歴書に必要な6項目

ITエンジニアの職務経歴書は、職務要約・活かせる経験とスキル・技術スキル一覧・職務経歴・保有資格・自己PRの6項目で構成します。全体でA4 2枚が目安です。3枚を超えると読まれにくくなります。

採用担当者が見ている4つの軸

このうち「担当フェーズ」と「役割」が最も重視されます。技術スタックについては、要件と多少違っていても入社後にキャッチアップできると考えて採用に至るケースは少なくありませんが、担当フェーズや役割については経験の有無がそのまま評価を左右します。

2. 職務経歴書とスキルシート・履歴書の違い

職務経歴書は「何をして、どんな成果を出したか」、スキルシートは「今どんな技術が使えるか」を伝える書類です。ITエンジニアの中途採用では職務経歴書が基本で、スキルシートは主にフリーランスの案件営業や客先常駐で使われます。履歴書は基本情報を伝える書類で、様式が定められています。

中途採用の選考でどちらか一方を作るなら、職務経歴書を選んでください。スキルシートは技術の一覧に特化しているため、「どんな課題をどう解いたか」が伝わりません。すでにスキルシートを作成済みであれば、プロジェクト単位の記載をそのまま職務経歴に転用できます。

3. ITエンジニアの職務経歴書：項目別の書き方

6項目のうち最も重要なのは冒頭の職務要約です。ここで「続きを読む価値がある」と判断されなければ、下にどれだけ詳細な実績を書いても読まれません。職務経歴は詳細に書くのを1〜3件に絞るのが原則です。

職務要約：「誰が・何を・どんな成果で」の3点セット

冒頭3〜4行に、実務年数・得意領域・最大の実績を圧縮します。

違いは具体性と数字です。悪い例は誰にでも当てはまり、良い例はその人にしか書けません。

活かせる経験・スキル：キーワードの受け皿にする

採用担当者は、条件に合う候補者を検索して探します。読ませる文章というより、検索キーワードに引っかかるよう、自身のスキルや経験を漏れなく記載することが重要です。

• ・担当フェーズ（要件定義／基本設計／詳細設計／実装／テスト／運用保守）
• ・開発手法（アジャイル／スクラム／ウォーターフォール）
• ・役割（テックリード／PL／PM／メンター）
• ・業界ドメイン（金融／EC／SaaS／医療 など）

技術スキル一覧：習熟度まで書く

言語名を並べるだけでは、実務で使えるのか触ったことがあるだけなのかが判別できません。経験年数と習熟レベルをセットにします。

職務経歴：詳細に書くのは1〜3件だけ

経験プロジェクトが多い人ほど、全件を同じ密度で書いてしまう失敗をします。読み手はすべてを読みません。

• ・アピールしたい1〜3件：課題・自分の担当・工夫・成果まで詳しく
• ・それ以外：期間・システム概要・使用技術・役割を1〜3行で要約

各案件で必ず書くのは、1 プロジェクト概要、2 規模（チーム人数・期間）、3 担当フェーズと役割、4 使用技術、5 成果（数字で）の5点です。

保有資格：失効したものも書く

一度取得した事実自体が評価対象になります。失効している場合は「◯年失効」と添えれば問題ありません。勉強中の資格も、キャッチアップ姿勢の証明として1行書く価値があります。

自己PR：技術ではなく「志向」を書く

技術は前述の項目で伝わっています。自己PRで書くべき内容は、どんなこだわりを持って開発に携わってきたのか、これからどんなことに携わっていきたいのか、です。特に自社サービス企業やベンチャーなどカルチャーマッチを重視する企業は、こうした内容をマッチングの判断とすることが多いです。

4. 実績を「数字」に変換する方法

「定量化できる成果がない」と感じる方は多いですが、ほぼすべての業務は数字に変換できます。売上や利益に直結していなくても構いません。工数・時間・件数・率のいずれかで表現できれば、貢献度は伝わります。

削減した工数は、そのまま人件費の削減として説明できます。売上に直結する仕事でなくても、貢献は数字にできます。

5. 職務経歴書で評価を下げてしまう5つの共通点

評価されづらい職務経歴書で特に多いのが、「スキルの羅列になっていること」と「成果が具体的に数値化されていないこと」です。単に扱える技術ワードを書き連ねるだけでは、十分なアピールにはつながりません。

「2 成果が数値化されていない」原因は、実績を数字で表現できないからではなく、普段から自分の仕事を数値化してとらえていないことにあります。「実績を「数字」に変換する方法」を参考に、ご自身の成果を数値化してみてください。

6. スカウト型転職で成功するための職務経歴書の書き方

自ら検索して応募するスタイルの転職サイトと、受け取ったスカウトから面談を進めていくスタイルのスカウト型転職では、職務経歴書の最適解が異なります。応募型は応募先企業1社に向けて送る書類ですが、スカウト型は不特定多数の企業が検索して見つけるための「公開プロフィール」だからです。

原則1：企業ごとの最適化をやめ、網羅性を優先する

応募型では志望企業に合わせて内容を絞り込みますが、スカウト型では記載内容を絞り込むほど検索に引っかからなくなるため、スカウトが受け取りづらくなります。経験した技術・フェーズ・ドメインは、些細に思えるものも含めて記載してください。自分では「大したことない」と思っている経験が、検索条件に一致することは頻繁にあります。

原則2：市場で通じる一般名称で書く

社内での呼称ではなく、市場で使われている名称に置き換えてください。社内用語のままでは検索に引っかかりません。

• ・「基盤チーム」→ インフラエンジニア／SRE
• ・「自社パッケージのカスタマイズ」→ 業務システム開発（要件定義〜実装）
• ・「クラウド移行PJ」→ AWSへのリフト＆シフト、Terraformによる環境構築

原則3：冒頭に「今後やりたいこと」を明示する

応募型では志望動機で伝える内容ですが、スカウト型では企業側があなたに合うポジションを判断する材料になります。ここが空白だと、現職と同じ職種のスカウトばかりが届きます。逆に書いておくと、キャリアチェンジを含めた提案が来やすくなります。Direct typeでは希望職種が記載されている場合には、基本的に希望職種に沿ったスカウトが送られます。

7. 提示年収の高い求人で評価される記述

Direct typeの調査では、同じ職種名でも求人提示年収に2倍以上の開きがあります。この差を生むのは技術スタックではなく「解決できる課題の難易度」です。職務経歴書でも、実装内容よりどんな課題をどう解いたかが評価対象になります。

出典：Direct type独自調査「2026年上半期 ITエンジニア職種別 求人提示年収」（typeブランドが保有するITエンジニア求人データ数万件規模を独自集計／2026年6月調べ）

「大したことない」と思っている経験が、実は評価対象です

次のような経験に心当たりはないでしょうか。いずれも上限レンジで求められる要件に該当します。

• ・仕様書の不備に気づき、ビジネスサイドに提案して開発を進めた
• ・メンバーのコードレビューを引き受け、チームのバグを未然に防いだ
• ・誰もやりたがらなかったリファクタリングを少しずつ進めた
• ・障害の原因を追い、再発しない仕組みまで作った
• ・新しいツールを導入して、チーム内の手作業を自動化した

やっていないのではなく、職務経歴書に書けていないだけというケースは少なくありません。

8. 書き始める前の棚卸し

いきなり書き始めると、直近の業務しか思い出せず内容が薄くなります。先に棚卸しをしてから書いてください。この工程に最も時間がかかりますが、ここを飛ばした職務経歴書はほぼ確実に薄くなります。

1. 1これまでの所属先とプロジェクトを時系列で列挙する
2. 2各プロジェクトについて「課題・自分の行動・結果」を書き出す
3. 3結果を数字に変換する（変換の方法は「実績を「数字」に変換する方法」を参照）
4. 4その中からアピールしたい1〜3件を選ぶ
5. 5選んだものを詳細に、それ以外を要約して配置する

棚卸しで手が止まる場合は、次の5つに自分で答えてみてください。

• ・そのプロジェクトで、最初に困っていたことは何でしたか
• ・あなたが自分で判断して決めたことは何ですか（指示されたことではなく）
• ・その結果、何がどう変わりましたか
• ・変化を工数・時間・件数・率のいずれかで表せますか
• ・同じ状況の人にアドバイスするとしたら何と言いますか

最後の質問が特に有効です。人に教えられる内容は、そのまま強みの言語化になります。

9. 提出前チェックリスト

提出前に次の7点を確認してください。特に社内用語が残っていないかは見落とされがちです。社外の人には伝わらない前提知識が混ざっていることがあります。

• ☐職務要約に数字が入っているか
• ☐A4 2枚以内に収まっているか
• ☐詳細に書いた案件が1〜3件に絞られているか
• ☐技術スキルに経験年数と習熟度が併記されているか
• ☐「〜に従事しました」で終わっている文がないか
• ☐一般名称で書かれているか（社内用語が残っていないか）
• ☐誤字脱字・表記ゆれがないか

ITエンジニアの職務経歴書に関するよくある質問