イメージ 【2026年最新】IT転職の職務経歴書の書き方|開発系・非開発系で変わる実績の見せ方とテンプレート
※本記事にはアフィリエイト広告(PR)が含まれています。 掲載サービスは編集部独自の比較軸で紹介しており、報酬の多寡で内容を変えていません。書類選考の結果・可否は個人のスキル・経験・企業ごとの選考基準により異なります。
「エージェントには登録した。求人も紹介された。でも職務経歴書に何を書けばいいか、手が止まっている」
「社内SEやIT営業は、開発の実績みたいに数字で語れない気がする」
「エンジニア向けの職務経歴書の記事はよく見るけど、自分(非開発系)には当てはまらない気がする」
結論から言うと、職務経歴書はA4用紙2〜3枚を目安に、開発系か非開発系かで書き方を変えます。IT業界の求人サイトや転職エージェントのサイトでは、職務経歴書のサンプルが職種ごとに単独で紹介されがちです。「社内SEの書き方」「IT営業の書き方」のようにそれぞれ別々に扱われ、開発系・非開発系という軸では整理されていません。
実際の応募では、まず自分が開発系か非開発系かを整理すると動きやすくなります。整理したうえで、それぞれ何が評価されやすいかを知っておくと迷いが減ります。
本記事では、IT転職の職務経歴書を「開発系」と「非開発系」に分けて整理します。開発系はプログラマー・SE・インフラエンジニアです。非開発系は社内SE・IT営業・ITサポート・Webディレクターを指します。まだ自分がどの職種を目指すか固まっていない方は、先にIT転職はエンジニアだけじゃない|職種一覧とキャリアの選び方を確認してください。職種の全体像をつかんでおくと、本記事の内容がより当てはめやすくなります。
結論|IT転職の職務経歴書は「開発系」か「非開発系」かで書き方が変わる
※イメージ 3行でわかる結論
- 開発系(プログラマー・SE・インフラエンジニア)は、成果を数値化する書き方が基本です。プロジェクト単位で「使用技術・役割・成果」をセットにして書きます。実績が少ない未経験・第二新卒でも、学習量や制作物の規模を数字に置き換えられます。
- 非開発系(社内SE・IT営業・ITサポート・Webディレクター)は、業務を定量化しにくい傾向があります。 数値を無理に作るのではなく、「何を・誰に・どう」担当したかを具体的に書くことが評価のポイントです。
- どちらのタイプでも、職務経歴書とスキルシートは役割が違います。 職務経歴書は経歴のストーリー、スキルシートは技術・経験の一覧です。非開発系でも、対応システムやツールの棚卸しという形でスキルシートに近い書類が求められる場合があります。
本記事のテンプレート・例文はあくまで「型」です。そのまま提出用にコピーするのではなく、自分自身の実際の経験・数字に置き換えて仕上げることをおすすめします。汎用的な文言をそのまま出すと、面接で経験の詳細を深掘りされた際に答えに詰まりやすくなります。
職務経歴書とスキルシートの違い(IT転職特有の使い分け)
IT転職では、履歴書に加えて「職務経歴書」と「スキルシート」の2種類の書類を求められるケースがあります。名称が似ているため混同されがちですが、採用担当が見ているポイントは違います。
| 書類 | 主な役割 | 採用担当が見ているポイント |
|---|---|---|
| 職務経歴書 | これまでの経歴をストーリーとして伝える | どんな職場で、どんな役割・立場を担い、何を成し遂げたか |
| スキルシート | 技術・対応範囲を一覧・棚卸しで伝える | 使用できる言語・ツール・システムと、それぞれの経験年数・習熟度 |
スキルシートという呼び方自体は、開発系(エンジニア)の求人でより一般的に使われる傾向があります。非開発系の場合、名称は「経験・スキル一覧」等に変わることもあります。ただし「担当してきた業務・システム・ツールを一覧化して伝える」という考え方自体は同じように使えます。応募先企業やエージェントによって求められる書類の組み合わせは異なります。事前に指定フォーマットの有無を確認しておくと安心です。
開発系(プログラマー・SE・インフラエンジニア)の職務経歴書の書き方
開発系の職務経歴書は、プロジェクト単位で経験を区切り、それぞれに「使用技術・役割・成果」をセットで書く構成が基本です。
プロジェクト単位で「使用技術・役割・成果」を書く
在籍企業ごと、またはプロジェクトごとに、以下の4点をセットで書きます。
- プロジェクト概要|何のためのシステム・サービスか(例:「消費者向けECサイトの新規開発」)
- 使用技術|言語・フレームワーク・インフラ(例:「Ruby on Rails、MySQL、AWS」)
- 担当役割・工程|要件定義〜運用保守のどこを、どんな立場で担当したか(例:「4名チームのバックエンド担当としてAPI設計・実装を担当」)
- 成果|数値・具体的な変化(次の項目で詳しく扱います)
技術用語を並べるだけで終わらせないことが重要です。「その技術を使って何を達成したか」までをセットで書くと、開発系の職務経歴書で重視されやすくなります。
実績を数値化する書き方(具体例文付き)
開発系の職務経歴書の中でも、通過率に影響しやすいのが「成果をどう書くか」の部分です。実務経験がある場合は、担当した業務の「対応前→対応後」を数値で示すのが基本の型です。
例文:「既存バッチ処理の実行時間が長く運用上の課題となっていたため、処理ロジックの見直しとインデックス設計の改善を主導。実行時間を平均40分から12分に短縮し、夜間バッチの完了時刻を早めることで翌朝の業務開始への影響を解消した。」
「担当した」で終わらせないことがポイントです。「何が課題で、何を判断し、結果どう変わったか」までをセットで書くと、単なる作業履歴でなく成果として伝わります。
未経験・第二新卒パターン(実績が少ない場合)
実務経験がまだない場合、成果の数値化は難しく感じられます。それでも「学習量」「制作物の規模」「かけた期間」を数字に置き換える余地はあります。
例文:「独学でプログラミング学習を開始し、6ヶ月間で個人開発のタスク管理アプリ(React、Firebase使用)を1本リリース。学習期間中、学習サービスで累計200時間以上の学習時間を確保し、学んだ内容を技術ブログに12本投稿した。」
未経験からのIT転職では、「継続して学習・開発を積み重ねてきた事実」を数字で示すことが重要です。期間・回数・時間という具体的な数字は、実務経験の代わりとして機能しやすい傾向にあります。
SES常駐からの脱却を狙うパターン(裁量・上流工程の経験の書き方)
SES(客先常駐で技術者を派遣する契約形態)出身の場合、常駐先ごとの実績が書類上で見えにくくなりがちです。案件単位で区切り、担当工程を明示することが対策になります。
例文:「A社常駐案件(1年6ヶ月):金融系Webシステムの保守開発に従事。要件ヒアリングから設計書作成、実装、単体・結合テストまでを一人称で担当。B社常駐案件(8ヶ月):ECサイトリニューアルで、フロントエンドの実装リーダーとして2名のメンバーをレビュー。」
複数現場を経験してきたこと自体は「環境変化への対応力」として強みに転換できます。常駐先の名称が出せない場合も、特定を避けつつ具体性を持たせる書き方で対応可能です。「業界(金融・EC等)」「規模(利用者数・チーム人数等)」といった形で示します。
開発系の職務経歴書・スキルシートをさらに詳しく知りたい方は、エンジニア転職の職務経歴書・スキルシートの書き方をご覧ください。例文やテンプレート込みで、より深く扱っています。
非開発系(社内SE・IT営業・ITサポート・Webディレクター)の職務経歴書の書き方
※イメージ 非開発系の職種には、開発系のような「使用技術」軸の整理がそのまま当てはまらない場合があります。ここでは職種ごとに、評価されやすい書き方の傾向を整理します。
社内SE|保守・調整・改善という「裏方業務」の見せ方
社内SEの業務は、成果が数字として表に出にくい「裏方業務」が中心になりやすい傾向があります。社内システムの保守・運用、部署間の調整、ヘルプデスク対応などがこれにあたります。この場合、担当していた業務範囲を具体的に書くことが重要とされています。
例文:「社内で利用する勤怠管理システム・会計システムの運用保守を担当。月次の不具合対応(平均〇件/月)に加え、利用部署からの改善要望をヒアリングし、ベンダーとの調整を経てシステム改修を主導した。改修後、利用部署からの問い合わせ件数が減少した。」
「対応した件数」「関わった部署数」「調整したベンダー数」など、業務量が伝わる数字があれば無理のない範囲で添えます。数字が出しにくい業務については、「どんな課題に対して、どう動いたか」というプロセスを具体的に書きます。それだけで裏方業務であっても評価される材料になり得ます。
IT営業|「何を・誰に・どう売ったか」の書き方
IT営業は、扱っていた製品・サービスの技術的な概要と、誰にどう売ったかの両方を書くことが重要とされています。営業経験そのものは他業界の営業職とも共通します。IT営業ならではの視点として「技術的な提案内容」を伝えられるかどうかが差別化のポイントになりやすいです。
例文:「クラウド型の勤怠管理システムの法人営業を担当。従業員数50〜300名規模の中小企業を中心に新規開拓を行い、導入検討段階では情報システム部門・人事部門双方への技術的な提案(既存システムとのデータ連携方法等)を担当した。」
営業成績(受注件数・売上額等)を書ける場合はそのまま数値化します。書けない場合も「どの規模の企業に、何を、どういう切り口で提案したか」を具体的に書きます。単なる「営業をしていました」という記述より、具体性が伝わりやすくなります。
ITサポート・ヘルプデスク|定量化しにくい業務をどう書くか
ITサポート・ヘルプデスクは、対応件数以外の実績が数値化しにくい職種の代表格です。無理に成果を作ろうとせず、対応範囲・対応方法の工夫を具体的に書く方向で整理します。
例文:「社内外からの問い合わせ対応(電話・チャット、月平均〇件)を担当。よくある問い合わせをFAQとして整理し、社内Wikiにまとめたことで、同種の問い合わせにかかる対応時間の短縮につながった。」
「対応した」だけで終わらせないことがポイントです。「対応する中で気づいた課題に、自分がどう動いたか」という一歩踏み込んだエピソードを添えます。受け身の作業ではなく、主体的な取り組みとして伝わりやすくなります。
Webディレクター|プロジェクトマネジメント経験の書き方
Webディレクターは、開発系とビジネス側の中間に立つ職種です。担当したプロジェクトの規模・関わったメンバー数・進行管理の工夫を書くと、マネジメント経験として評価されやすくなります。
例文:「企業のコーポレートサイトリニューアル案件(制作期間4ヶ月、デザイナー2名・エンジニア3名の体制)のディレクションを担当。クライアントとの要件すり合わせから、社内制作チームへのスケジュール管理・進行管理までを一貫して担当した。」
「何人規模の、どんな体制のプロジェクトを、どこからどこまで担当したか」を明示します。それによって、開発の詳細を語れなくても、マネジメント能力として伝えられる書き方になります。
開発系と非開発系で共通して気をつけるべきNG例
職務経歴書で評価を下げやすいパターンには、職種を問わない共通点があります。
- 業務内容の羅列だけで終わる|「〇〇を担当しました」の連続で終わり、その業務の中でどう考え、どう動いたかが書かれていないケース
- 転職回数が多い・在籍期間が短い場合に、経緯を書かず並べるだけ|事実を隠す必要はありません。各社での担当業務・習得したスキルを具体的に書くと、「何を積み上げてきたか」に焦点を当てられます
- 副業・個人開発・資格を過大に書く|副業・個人開発の実績や取得した資格を記載すること自体は問題ありません。ただし実態以上に成果を誇張した書き方は、面接で深掘りされた際に信頼を損ないやすくなります。事実の範囲で具体的に書くことが基本です
- 主観的な自己評価に終始する|「コミュニケーション能力が高い」「向上心がある」など、根拠となるエピソード・数値を伴わない自己評価だけで終わるケース
- 誤字脱字・フォーマットの乱れ|業務における確認作業の丁寧さが疑われやすい部分です。提出前に一度時間を置いてから見直すことをおすすめします
職務経歴書のテンプレート構成(そのまま使える項目リスト)
ここまでの内容を踏まえた、開発系・非開発系どちらにも応用できる汎用フォーマットの構成例です。使い慣れたツール(Word・Googleドキュメント等)に、この見出し構成をそのまま書き写して使ってください。
■ 職務要約
(3〜5行で経験年数・担当領域・転職で実現したいことを要約)
■ 職務経歴
【株式会社〇〇】(在籍期間:20XX年X月〜20XX年X月)
・担当業務・プロジェクト名:
・業務概要:
・使用技術/対応システム・ツール(該当する場合):
・担当役割・工程:
・成果・工夫した点:
■ 活かせる経験・スキル
・(横断的な強みを箇条書きで)
■ スキルシート/経験・スキル一覧
(開発系:言語・フレームワーク・インフラ・データベース・開発ツール等)
(非開発系:対応システム・ツール・扱った商材・対応規模等)このフォーマットは編集部独自に一般化した構成であり、特定企業・特定サービスの様式をそのまま転用したものではありません。応募先企業や利用するエージェントから指定のフォーマットを渡される場合は、そちらを優先してください。
一人で仕上げるのが不安な場合の選択肢
ここまでの内容を自分で整理するだけでも書類作成は可能です。ただし「第三者の目でチェックしてほしい」「業界の書き方の相場が分からない」という場合もあるでしょう。その場合は、転職エージェントの書類添削サービスを利用する選択肢もあります。
開発系(実務経験がある方)の場合
20〜30代でエンジニアの実務経験がある方は、開発職特化のエージェントを添削の相談先に加える選択肢があります。明光キャリアパートナーズは、20〜30代のエンジニア経験者を対象としたエンジニア特化のサービスです。無料面談から書類添削の相談を始められます。対象条件・支援内容は公式サイトの最新情報をご確認ください。
非開発系(社内SE・IT営業・ITサポート・Webディレクター等)の場合
非開発系の職種は、開発職特化型よりもIT業界全体対応型・総合型のエージェントのほうが相談しやすい傾向があります。求人・書類添削の両面で頼りやすいためです。窓口のタイプ別の選び方は、IT転職エージェント比較|開発職だけじゃない「非開発系も対応できる窓口」の選び方で整理しています。開発職特化型・IT業界全体対応型・総合型の3タイプです。自分の職種にあったタイプの窓口を確認したうえで、書類添削の相談先を選ぶ進め方をおすすめします。
よくある質問(FAQ)
Q. 職務経歴書は何ページが適切?
A. A4用紙で2〜3枚程度に収める候補者が多い傾向にあります。経験年数が長い場合も、直近の経験を厚く・それ以前を簡潔にまとめます。枚数を抑えつつ要点を伝えやすくなります。
Q. 未経験だと職務経歴書に書くことがない場合はどうする?
A. 開発系であれば、学習量・制作物の規模・かけた期間を数字に置き換える方法があります。非開発系(未経験からの社内SE・IT営業等)であれば、前職での経験を言い換えて書く方法が一般的です。「調整業務」「顧客対応」「数値目標の管理」など、志望職種に近い要素を拾い出して書きます。ゼロから作文するのではなく、これまでの経験の中から近い要素を拾い出す作業として捉えると進めやすくなります。
Q. 開発職の応募でも非開発系の経験は書いていい?
A. 職務経歴として事実であれば記載して問題ありません。ただし、応募先が見たいのは志望職種に関連する経験です。非開発系の経験を書く場合も、「その経験がどう志望職種に活きるか」を一言添えます。単なる経歴の羅列で終わらずに伝わりやすくなります。
Q. 写真は必要?
A. 職務経歴書に写真を貼付する慣習は一般的ではありません。写真は履歴書側に貼付するのが通例ですが、応募先やエージェントの指定フォーマットに従ってください。
Q. テンプレートをそのまま使っても大丈夫?
A. 見出し構成・フォーマットとしての利用は問題ありません。ただし例文の文言をそのまま流用すると、面接で経験の詳細を聞かれた際に答えに詰まりやすくなります。必ず自分自身の経験・数字に置き換えて仕上げてください。
まとめ|自分のタイプを見極めてから実績の見せ方を決める
IT転職の職務経歴書は、開発系か非開発系かで評価されやすい書き方が異なります。
まずやるべきことは3つです。
- 自分が開発系か非開発系かを整理する(開発系:プログラマー・SE・インフラエンジニア/非開発系:社内SE・IT営業・ITサポート・Webディレクター)
- 開発系はプロジェクト単位で「使用技術・役割・成果」をセットにし、成果はできる限り数値化する。非開発系は無理に数値化を煽らず、「何を・誰に・どう」担当したかを具体的に書く
- 職種を問わない共通NGパターン(業務内容の羅列だけ・過大な誇張・主観的評価のみ)を避ける
一人で仕上げるのが不安な場合は、自分の職種に合ったタイプの転職エージェントを検討してください。書類添削サービスを活用する選択肢もあります。
関連記事
- IT転職はエンジニアだけじゃない|未経験でも狙える職種一覧とキャリアの選び方 — そもそも自分がどの職種を目指すか迷っている方はこちら
- IT転職エージェント比較|開発職だけじゃない「非開発系も対応できる窓口」の選び方 — 職務経歴書の添削も含めて窓口を探すならこちら
- IT転職は「やめとけ」と言われる理由と見極め方 — 転職活動を始める前にリスクを確認したい方はこちら
- エンジニア転職の職務経歴書・スキルシートの書き方 — 開発職として、より技術的な実績の書き方を深く知りたい方はこちら
- 「キャリア・転職」の記事一覧 — 同じカテゴリの他の記事も見る
免責・注記
- 本記事は2026年9月時点の一般的な傾向を整理したものです。書類選考の基準・重視されるポイントは企業・職種によって異なり、本記事の内容を保証するものではありません
- 例文はあくまで「型・方向性の例」であり、この通りに書けば選考を通過できることを保証するものではありません。自分自身の実際の経験・数字に置き換えて作成することをおすすめします
- 選考結果は個人のスキル・経験・企業ごとの選考基準により異なります
- 配布したテンプレート(フォーマット例)は編集部独自の一般化した構成です。特定企業・特定サービスの様式を転用したものではありません
- 本記事にはプロモーション(広告)が含まれますが、編集部の評価は報酬の多寡で変えていません