トップ › 職種別ガイド › ITエンジニア（SE・プログラマー）

ITエンジニアの職務経歴書の書き方｜職務要約・自己PRの例文つき

ITエンジニアの職務経歴書では、担当した工程・システムの規模・技術スタック・チーム内での役割の4点が最初に確認されます。

こんな人向け: 開発経験はあるが、プロジェクトをどう書き分ければよいか迷っている人／SESや受託で案件数が多く、経歴書が長くなりがちな人／自社開発やテックリードなど、一段上のポジションを狙っている人

ITエンジニア（SE・プログラマー）の職務経歴書で見られるポイント

工程・規模・役割をプロジェクトごとに書く

採用担当がまず探すのは「要件定義から入ったのか、詳細設計以降なのか」「何人規模の案件で、自分は何を任されていたか」です。プロジェクト名だけ並べても判断できません。各案件に期間・業務内容・担当工程・チーム人数・自分のポジション（メンバー／サブリーダー等）を一行ずつ添えると、読み手が面接前に経験値を見積もれます。

技術スタックは別枠で一覧にする

言語・フレームワーク・DB・クラウド・ツールは、本文中に散らばせるより「テクニカルスキル」の欄にまとめて書くほうが見つけやすいです。それぞれに経験年数と、「業務で設計から担当」「保守で触った程度」といった習熟の目安を添えてください。求人票の必須スキルと照合される箇所なので、名称は正式表記で揃えます。

担当した成果を工夫と数値で示す

「開発を担当」だけでは評価が難しいので、何を考えてどう実装したかを一つ添えましょう。例えば「バッチ処理をSQLの見直しで短縮」「レビュー指摘の傾向を共有して手戻りを減らした」など、小さくても自分が判断したことを書きます。数値は正確に覚えているものだけ使い、不確かなら「約」をつけるか、仕組みの変化で表現します。

案件数が多いときは代表案件を厚く書く

SESや受託で短期案件が10件以上ある場合、全件を同じ粒度で書くと3枚を超えて読まれにくくなります。応募先に近い案件を2〜3件選んで詳しく書き、残りは期間と概要の一行にまとめる書き方が読みやすいです。古い案件や保守のみの案件は、使用技術の一覧に含めれば省略しても問題ありません。

例文: 職務要約

情報系の専門学校を卒業後、株式会社◯◯にSEとして入社し、約6年間にわたり業務系Webシステムの開発に携わってきました。入社後3年間は受託開発案件で詳細設計・実装・テストを担当し、4年目以降は自社サービスの開発チームに移り、要件定義や基本設計から参画しています。直近2年はメンバー4名のサブリーダーとして、タスク管理やコードレビュー、若手の育成も担っています。主にJava・Spring Bootを用いたバックエンド開発を軸に、AWS上での環境構築やCI/CDの整備も経験しました。業務知識と技術の両面から改善提案を行い、安定したリリースを続けてきたことが強みです。

例文: 職務経歴

期間	2020年4月〜現在
会社	株式会社◯◯（事業内容: 業務系システムの受託開発・自社SaaSの開発運営／従業員数: 約150名）
所属・役職	システム開発部開発2課サブリーダー（2024年4月〜）
業務内容	販売管理SaaSの新機能開発（要件定義〜リリース）。Java／Spring Boot、PostgreSQL、AWS 受託案件（流通業向け在庫管理システム）の詳細設計・実装・単体〜結合テストチーム4名のタスク管理、コードレビュー、新人2名のOJT担当 GitHub ActionsによるCI/CDパイプラインの整備と、テスト自動化の推進
実績・取り組み	夜間バッチのSQLとインデックスを見直し、処理時間を約3時間から約1時間に短縮レビュー観点をチェックリスト化し、結合テストでの不具合件数を前年比で約3割削減

活かせる経験・スキルの書き方例

Java／Spring Bootでの業務系Web開発（6年）
AWS（EC2・RDS・S3・Lambda）での環境構築・運用
要件定義・基本設計からの一貫した参画経験
4名規模のチームリードとコードレビュー
CI/CD・テスト自動化の導入経験

例文: 自己PR

私の強みは、業務理解を起点にした設計と、チームの生産性を上げる仕組みづくりです。自社SaaSの開発では、営業担当やカスタマーサポートから届く要望をそのまま実装せず、利用データや問い合わせ内容を確認して本当に解決すべき課題を整理したうえで要件に落とし込んできました。その結果、リリース後の仕様変更が減り、開発工数の見積もり精度も上がりました。また、サブリーダーとしてはレビューの指摘が個人の経験に偏っていた状況を改善するため、頻出する指摘をチェックリスト化し、若手が自分で確認できる仕組みを作りました。技術面ではバックエンドを軸にしながら、インフラやCI/CDにも領域を広げており、サービス全体を見て改善点を提案できます。御社ではこの経験を活かし、プロダクトの成長と開発チームの底上げの両方に貢献したいと考えています。

この形で、そのまま作れます

職務経歴書を無料・登録不要で作成。AIが職務要約と自己PRの下書きを作ります。

職務経歴書を作る（無料）履歴書を作る

NG表現とOK表現

NG　各種システムの開発に幅広く携わり、多くのプロジェクトを経験しました。

OK　業務系Webシステム5件に参画し、うち2件は要件定義から、3件は詳細設計以降を担当しました。

「幅広く」「多く」は読み手が経験量を測れません。件数と担当工程を具体的に出すと評価軸に乗ります。

NG　Java、Python、PHP、Ruby、Go、JavaScriptなど多数の言語を扱えます。

OK　Java（業務6年・設計から担当）、JavaScript（業務3年）、Python（個人開発で学習中）

言語を羅列すると「どれも浅いのでは」と疑われます。年数と習熟度を添えて軸を明確にしましょう。

NG　最新技術のキャッチアップに日々努めており、常に自己成長を続けています。

OK　新規機能の開発にあたりコンテナ環境を提案し、検証環境の構築手順を社内ドキュメントにまとめました。

姿勢だけの表現は誰でも書けます。学んだことを業務で何に使ったかまで書くと信頼されます。

よくある質問

SESで案件が多い場合、全部書くべきですか？

全件を同じ粒度で書く必要はありません。応募先の業務に近い案件を2〜3件選んで工程・規模・役割を詳しく書き、他は期間と概要を一行で並べましょう。使用技術は一覧表にまとめれば漏れません。全体で2〜3枚に収まる量が目安です。

担当工程が実装・テストだけでも評価されますか？

されます。工程の広さより、その中で何を工夫したかが見られます。テストで見つけた不具合の傾向を設計側に戻した経験や、実装中に仕様の矛盾を見つけて確認した経験があれば書いてください。上流に関わりたい意向は自己PRで伝えると前向きに受け取られます。

GitHubや個人開発のURLは載せてもよいですか？

応募先に見せられる状態なら有効です。特に自社開発企業はコードの書き方を見たい傾向があります。載せる場合はREADMEを整え、業務で書いたコードは絶対に含めないようにしてください。載せるURLは一つか二つに絞ると読み手の負担になりません。

技術スタックはどこまで細かく書くべきですか？

言語・フレームワーク・DB・クラウド・開発ツールに分けて、業務で使ったものを中心に書きます。バージョンは必要なら主要なもののみで十分です。研修で触っただけのものは「学習中」と分けて書くと、面接で深掘りされたときに困りません。

リーダー経験がないと選考で不利になりますか？

20代ならほとんど問われません。代わりに、後輩への教え方や、チーム内で担った調整役（レビューの取りまとめ、ベンダーとの質疑対応など）を書くと、将来のリーダー候補として見てもらえます。30代以降はサブリーダー相当の経験があれば小さくても書きましょう。