SE（システムエンジニア）の職務経歴書の書き方｜採用担当に伝わる記入例と無料テンプレート

SE（システムエンジニア）の職務経歴書で評価されるのは、使える言語やツールの数ではありません。「どんなシステムで、どの工程を担い、何を良くしたか」がプロジェクトごとに伝わるかどうかです。技術名を並べただけでは、採用担当は自社の開発に合う人かを判断できません。

2026年の今は、コードの下書きやテストの作成を生成AIに手伝ってもらう開発が広がっています。書く速さだけなら、AIで誰でも上げられます。だからこそ採用担当が知りたいのは、速さより、そのコードの正しさをどう確かめたかです。

この記事では、SIer（システムの受託開発会社）から自社開発の会社への転職を考えるバックエンドエンジニアの記入例をもとに、項目ごとの書き方を解説します。働き方・担当領域別の書き分け方と、AIを使った開発経験の書き方も紹介します。

SEの職務経歴書の記入例

まずは完成イメージです。独立系SIerに新卒で入社し、金融・流通・物流・製造業向けのシステム開発を9年半経験した人を想定しています。応募先は、自社サービスを開発するWeb系の会社です。画像をタップすると拡大できます。

この記入例と同じ形式のテンプレートを無料で用意しています。Word・Excel・PDFの3形式で、それぞれ空欄テンプレートと記入見本の2点セットです。

データで見る：SEの転職市場と、企業が足りないと感じている人材

書き方の前に、SE・開発職の採用の状況をデータで確認しておきましょう。求人倍率は、どの集計を見るかで大きく変わります。公的な統計と転職サービスの集計を、範囲を注記しながら見ていきます。

ハローワークでは1.48倍。全体より高いが、求職者は前年より増えている

厚生労働省の「一般職業紹介状況」によると、2026年8月の「情報処理・通信技術者」の有効求人倍率は1.48倍でした（常用・パートを除く）。職業計の1.17倍を上回り、求職者1人に対して求人が約1.5件ある状態です。この区分には、SEやプログラマーなどが含まれます。

出典：一般職業紹介状況（令和8年8月分）参考統計表（厚生労働省）（2026年10月2日公表）

一方で、同じ区分の有効求職者は前年同月より5.8%増え、求人倍率は0.10ポイント下がりました。ハローワーク経由の数字で、転職サービスの求人は含みません。それでも、IT職を目指す求職者は増えていることがわかります。

転職サービスでは、ITエンジニアの求人倍率は1年を通じて10倍超

転職サービスdodaの集計では、「エンジニア（IT・通信）」の転職求人倍率は2026年8月に12.04倍でした。2025年8月から2026年8月まで、一度も10倍を下回っていません。同じ期間の全体の倍率は2.38〜2.96倍で、ITエンジニアは常にその4倍以上です。

出典：doda「転職求人倍率レポート」データ（パーソルキャリア）（2026年9月17日発表・2026年8月分）

ハローワークとの差が大きいのは、IT企業の多くが転職サービスを中心に採用しているためと考えられます。ただし、求人の多くは「〇〇の経験3年以上」のように条件がはっきりしています。求人が多い分、自分の経験が条件に合うことを書類ですぐ示せるかが重要になります。

DXを推進する人材は「量」より「質」が足りない

情報処理推進機構（IPA）の「DX動向2026」では、DXに取り組む企業にDXを推進する人材の確保状況を聞いています。人材の「質」が不足と答えた企業は88.8%で、「量」の不足（85.5%）を上回りました。

出典：DX動向2026（情報処理推進機構）（図表4-1・4-3）

「量」で「大幅に不足」と答えた企業は、2023年度の62.1%から2025年度は50.1%に減りました。一方で「質」の不足の合計は、2024年度の86.1%から88.8%にやや増えています。人数はそろい始めても、求める水準のスキルを持つ人はまだ足りない、と読み取れます。なお、この「DXを推進する人材」には、SE・開発者のほか企画やデータ活用の人材も含まれます。

採用担当がSEの職務経歴書で見ている3つのこと

ここまでのデータと、開発職の採用の現場でよく言われる傾向を踏まえると、採用担当は書類を読みながら次の3つを確認しています。どの項目を書くときも、このどれかが伝わるかを意識しましょう。

1. 自社の開発に合う経験か言語・フレームワーク・クラウドなどの環境と、システムの規模・業界が、応募先の開発と重なるか。採用担当や現場のエンジニアは、技術の一致を最初に確認します。
2. 任せられる範囲要件定義から運用まで、どの工程を自分で担当してきたか。チームの人数と役割があると、入社後にどこまで任せられるかを判断できます。
3. 品質に責任を持てるか作ったものの性能・品質・コストを数字で確かめ、改善してきたか。生成AIでコードを書く時間が短くなった今は、レビューやテストで正しさを確かめる力がより重く見られます。

項目別の書き方：OK例とNG例の違い

ここからは項目ごとに、NG例とOK例を並べて解説します。同じ経験でも、書き方ひとつで採用担当の受け取り方は大きく変わります。

職務要約：「どんなシステムを、どの技術で」を3〜5行で

職務要約は、採用担当が最初に読む部分です。経験年数・業界・得意な技術・担当工程・一番の成果を3〜5行にまとめます。技術の一致は真っ先に見られるため、主な言語やクラウドは要約にも書いておきましょう。

職務経歴：プロジェクトごとに「規模・役割・工程・環境・成果」を書く

SEの職務経歴は、所属部署ではなくプロジェクト単位で書くのが基本です。1つのプロジェクトは、規模・役割・工程・環境・成果の5点セットにします。下の画像の3つのポイントを押さえましょう。

プロジェクトが多い人は、応募先に近いものを詳しく、古いものや短いものは1〜2行にまとめます。特に差がつくのが、成果の書き方です。

活かせる経験・知識・スキル：応募先の課題に合わせて3つ選ぶ

経験したことを全部並べるのではなく、応募先の開発で使えるものを3つ程度に絞ります。技術名はテクニカルスキル欄に任せ、ここでは「技術を使って何ができるか」を書きます。

テクニカルスキル：分類ごとに「何を・何年」を書く

SEの職務経歴書では、PCスキル欄を「テクニカルスキル」として、言語・フレームワーク・DB・クラウドなどの分類ごとに整理するのが一般的です。技術名には経験年数と使い方を添えます。

自己PR：強みは2つまで。技術を「どう確かめたか」で示す

自己PRは「強み → それを発揮したエピソード → 結果の数字」の順に書きます。SEでは、品質や性能を数字で確かめる姿勢が強みとして伝わりやすいテーマです。AIでコードを書く時間が短くなった今、確かめる力はそのまま今の開発に通じる強みになります。

働き方・ポジション別：職務経歴書の書き分け方

同じSEでも、応募先の働き方や担当領域によって採用担当が見るポイントと、強調すべき経験は大きく変わります。まずは全体像を表で確認し、そのあと自分に近いタイプの解説を読んでください。

働き方・ポジション	採用担当が見るポイント	強調したい経験・数字
SIer・受託開発	顧客の業務を理解し、仕様と品質を守って納める力	業界・システム規模、担当工程、障害件数、納期
自社開発（Web系）	サービスを継続的に改善し、利用者に価値を届ける力	リリース頻度、性能指標、技術選定の理由
社内SE	社内の業務を理解し、システムで課題を解決する力	利用部署・利用者数、削減した作業時間、費用
フロントエンド	使いやすい画面を、品質を保って作る力	表示速度、利用者の行動の変化、対応端末
バックエンド	性能・安全性の高い仕組みを設計する力	応答時間、処理件数、データ量、障害の減少
インフラ・クラウド	止まらず、無駄のない基盤を運用する力	稼働率、費用削減、構築の自動化の範囲

SIer・受託開発に応募する

SIerや受託開発の会社では、顧客の業務を理解し、決められた納期と品質でシステムを納める力が見られます。「どの業界の、どんな規模のシステムを、どの工程で担ったか」を正確に書くことが評価の土台です。

自社開発（Web系）に応募する

自社サービスを開発する会社では、作って終わりではなく、リリース後も改善し続ける力が見られます。記入例の人物のように、SIerから自社開発に移る人が特に気をつけたいのがここです。受託の経験でも、利用者や運用に効いた改善を選んで書くと、自社開発でも活躍できる人だと伝わります。

社内SEに応募する

社内SE（事業会社の情報システム部門）では、社内の業務を理解し、システムで課題を解決する力が見られます。ベンダーへの発注や社内の問い合わせ対応も仕事に含まれることが多いポジションです。技術の深さより、「誰の、どんな困りごとを解決したか」が伝わる書き方が向いています。

担当領域（フロントエンド・バックエンド・インフラ）で書き分ける

開発の担当領域がはっきりしている求人では、領域ごとに「評価される数字」が違います。同じプロジェクトでも、応募するポジションに合わせて成果の書き方を選びましょう。

あわせて読みたい：社内SEの職務経歴書の書き方

2026年のSE・開発とAI：職務経歴書にどう書くか

最初にお伝えしたいのは、AIの使い方や、AIの経験を求める度合いは応募先によって大きく違うということです。IPAの「DX動向2026」では、AIを導入している企業は従業員1,001人以上で8割近くにのぼる一方、101人以下では16.6%でした。受託開発では、顧客との契約で生成AIの利用が禁止されている現場も少なくありません。

まずは求人票に「生成AI」「LLM」「AIツール」などの言葉があるかを確認しましょう。記載があれば、プロジェクトや取り組みとして詳しく書く価値があります。記載がなければ、テクニカルスキル欄に1行添える程度で十分です。

開発の現場では、AIの利用が広がっている

同じIPAの調査では、AIを導入・検討している企業に用途を聞いています。「プログラムコードやシステム開発支援」に使っている割合は、情報通信業で76.3%と、ほかの業種を大きく上回りました。開発の仕事は、AIの影響を最も受けやすい仕事の一つです。

パーソルキャリアの調査では、今後3年以内に中途採用が増える領域の最多が「データ・デジタル／IT企画系」でした。対象はAIを導入済みの従業員501人以上の企業の人事・採用担当者515人で、大企業に限った結果です。それでも、AIを前提にしたシステムを作れる開発者の需要は、今後も続くと考えられます。

2026年のSEで現実的なAIの使い方

2026年時点で、開発の現場でよく見られる使い方は次のとおりです。

• コードの補完・下書き：GitHub Copilotなどのコーディング支援AIで、定型的な処理の実装を速くする
• テストの作成：単体テストのコードや、境界値などのテストデータの案を出す
• 既存コードの読み解き：仕様書が古いシステムで、処理の流れや影響範囲を調べる
• レビューと文書化の補助：プルリクエストの要約、設計書やAPI仕様の下書き
• AIを組み込んだ機能の開発：社内文書を検索して回答するチャット（RAG）や、文章の分類・要約の機能

前の4つは、開発を速くする使い方です。ただし、AIが書いたコードには、もっともらしい誤りや、安全でない書き方が混ざることがあります。速くなった分、レビューとテストで正しさを確かめる工程の重みが増しています。最後の1つは、AIそのものを製品に組み込む仕事で、回答の正しさをどう測るかが腕の見せどころです。

書き方：速さより「正しさをどう確かめたか」

AIの経験は「AIを活用して効率化」と書くだけでは伝わりません。使った場面・確かめた方法・変わったことの3つをセットで書きます。

AIを組み込んだ機能を開発した人は

生成AIを製品やシステムに組み込んだ経験は、2026年時点ではまだ持つ人が少なく、求人票に記載があれば大きなアピールになります。ただし「生成AIの機能を開発」だけでは、APIを呼び出しただけなのか、業務で使える品質まで作り込んだのかがわかりません。記入例では、次の一文で品質の確かめ方を示しています。

このほか、次のような点にも触れられると、AIの機能を任せられる開発者だと伝わります。

• 誤った回答への備え：回答を人が確認してから使う流れ、回答できないときの表示など
• データの扱い：個人情報をAIに渡さない処理や、利用者の権限に応じた検索範囲
• 運用の数字：応答時間やAPIの利用料金の上限など、本番で使い続けるための工夫

AIの経験を書くときの注意点

• 機密コードや顧客情報を外部のAIに入れていないことがわかるように書く。「顧客承認済みの環境で」「社内で認められたツールで」と一言添えるだけで、情報管理の意識が伝わります。
• ライセンスとセキュリティの確認に触れる。生成コードに既存のコードと似た部分がないか、脆弱性がないかをレビューで確かめたことは、立派な経験です。
• 会社や顧客のルールに従って使ったことを前提に書く。ルールのない時期に、個人のアカウントで業務のコードを扱った経験は書かないほうが無難です。
• 盛らない。「AIで開発を自動化」と書いて実際は補完程度だった場合、技術面接で使い方を聞かれて答えに詰まります。

AIを使っていない・禁止の職場だった人は

顧客との契約やセキュリティの方針で、AIを使えない現場で働いてきた人も多いはずです。それだけで評価が下がると考える必要はありません。コードレビューやテストで品質を守ってきた経験は、AIの出力を確かめるための土台そのものだからです。

職務経歴書では、レビューの観点を整えた経験、テストを自動化した経験、静的解析ツールを導入した経験などを書きましょう。どれもAIを使う開発で必要になる力です。個人で学んでいる場合は、個人開発でAIのコーディング支援を試したことを「学習中」として書けます。業務のコードを個人のAIで試すのは避けてください。

実績の数字が書けないときの対処法

「受託開発では売上への効果が見えない」「保守ばかりで成果と言えるものがない」という人も、見る角度を変えれば書ける数字は必ずあります。

あわせて読みたい：アピールできる実績がない人の職務経歴書の書き方

提出前のチェックリスト

書き終えたら、提出前に次の項目を確認しましょう。

• 職務要約に、経験年数・業界・得意な技術・担当工程・一番の成果が入っている
• プロジェクトごとに「規模・役割・工程・環境・成果」が書かれている
• 成果に、改善の前後の数字や件数を添えている
• テクニカルスキルの経験年数が、職務経歴のプロジェクトの期間と一致している
• AIを使った開発は、使った場面と、レビュー・テストでの確かめ方をセットで書いている
• 顧客名・社内の案件名など、守秘義務に触れる情報を書いていない
• A4で2枚程度（多くても3枚以内）に収まり、誤字脱字がない

よくある質問

プロジェクトの数が多く、2枚に収まりません。

応募先の技術や業界に近いプロジェクトを詳しく書き、それ以外は「プロジェクト名・期間・環境」の1〜2行にまとめます。短期の支援や同じ顧客の保守は、まとめて1つに書いてもかまいません。

SES（客先常駐）で働いていた場合、何を書けばいいですか？

所属会社名と雇用形態は会社ごとに書き、その下に常駐先でのプロジェクトを並べます。常駐先の社名は出さず、「大手損害保険会社」のように業界と規模で表しましょう。

業務でAIを使ったことがなく、個人で試しているだけです。書いてもいいですか？

書いてかまいません。ただし業務の経験と分け、「個人開発でコーディング支援AIを使い、生成コードをテストで確認」のように、学習中の取り組みとして書きます。使ったツールの名前だけを並べるより、何を作り、どう確かめたかを書くほうが伝わります。

資格は書いたほうがいいですか？

基本情報技術者・応用情報技術者や、クラウドの認定資格などは、知識の裏付けとして書いておきましょう。ただし開発職の選考では、資格より実務の経験が重視されます。資格の欄を厚くするより、プロジェクトの成果を充実させるのが先です。

成果を少し大きめに書いても大丈夫ですか？

事実と異なる内容は書いてはいけません。開発職の選考では、技術面接で「どう計測したか」「なぜその設計にしたか」を細かく聞かれることがよくあります。チームの成果は、自分の担当範囲と分けて書きましょう。