SE(システムエンジニア)の職務経歴書の書き方|採用担当が見るポイントと例文
- 採用担当者がSEの職務経歴書で本当に見ているポイント
- プロジェクト規模・技術スタック・成果の「数字の出し方」
- 要件定義・基本設計・詳細設計・製造・テスト・保守など工程別の書き方
- 書類が通らないSEに共通する失敗パターン
- 経験年数別(若手・中堅・ベテラン)のアピールポイントの違い
- NG例・改善例つきで今日から使える書き方を解説
「たくさんのプロジェクトをこなしてきたのに、職務経歴書に何を書けばいいかわからない」「技術スタックを並べてもアピールになっているか自信がない」SEの転職活動でよく聞く悩みです。要件定義から本番稼働まで一貫して担当してきた経験は確かな実力なのに、それを採用担当者に伝わる書き方ができていない方がほとんどです。
書類が通らない原因の多くは、「何をしたか」は書けていても「どんな規模のプロジェクトを・どんな役割で・どんな成果を出したか」が伝わっていないことにあります。採用担当者はSEの職務経歴書を通じて「要件をシステム仕様に落とし込む力があるか」「品質を保ちながら開発を完遂できるか」を判断しています。
この記事では、SEが転職活動で使える職務経歴書の書き方を、具体的な例文・NG例・経験年数別のアドバイスとあわせて解説します。
採用担当は何を見ている?
SEの採用担当者が職務経歴書で確認しているのは、主に次の3点です。
| 観点 | 内容 |
| どんな規模・種類のシステム開発を担当してきたか | プロジェクト予算・チーム人数・期間・業種・システムの種類(基幹・Web・モバイル・組込みなど)を確認している |
| どの工程を担当してきたか | 要件定義・基本設計・詳細設計・製造・テスト・保守運用など、担当した工程の幅と深さを見ている |
| 技術スタックと使いこなした実績があるか | 言語・フレームワーク・DB・インフラ・ツールと「どのプロジェクトで・どう使ったか」の対応関係を確認している |
よくある失敗(書類が通らない人に共通する3つのパターン)
パターン①:プロジェクトの規模感が一切わからない
「在庫管理システムの開発に参加しました」という記述では、採用担当者には何も伝わりません。プロジェクトの予算規模・チーム人数・期間・システムの規模(ユーザー数・取扱データ量)が書かれて初めて、評価の材料になります。
パターン②:担当工程が「要件定義〜製造」のような曖昧な記述で終わっている
「要件定義から製造まで担当」という記述では、各工程での役割が見えません。「要件定義:顧客との週次ヒアリング(全8回)の主担当。基本設計:画面遷移図・ER図の作成を担当(全体設計書のうち自担当範囲は約40%)」のように、工程ごとの役割と担当範囲を具体的に書きましょう。
パターン③:技術スタックの羅列で「使える」かどうかが判断できない
「Java・Python・C#・MySQL・AWS・Docker…」と並べるだけでは、実務で使えるレベルかどうかが判断できません。「Java(Spring Boot)を使って○○システムのAPIを設計・実装(業務経験4年)」のように、技術とプロジェクトの対応を書くことが重要です。
書き方のポイント|SEならではの伝え方
ポイント①:プロジェクトを「概要・規模・役割・担当工程・成果」の5点で書く
各プロジェクトの記述には「システム概要(何のためのシステムか)」「規模(予算・チーム人数・期間・ユーザー数)」「自分の役割(SE・リードSE・サブリーダーなど)」「担当工程(要件定義・基本設計・詳細設計・製造・テスト)」「成果(納期・品質・パフォーマンス)」の5点をセットで書きましょう。
ポイント②:技術スタックはスキルシートで整理する
SEの職務経歴書はスキルシート(技術スタック一覧)と本文(プロジェクト経歴)を分けて書くのが効果的です。スキルシートでは「技術名・経験年数・習熟度(業務で独立対応可・補助的に使用・学習中)・使用したプロジェクト」の4点を整理しましょう。
ポイント③:上流工程(要件定義・設計)の経験を積極的にアピールする
SEの市場価値を高めるのは上流工程の経験です。「要件定義で顧客の業務課題をヒアリングし、機能要件・非機能要件として文書化した経験」「基本設計書・詳細設計書を主担当として作成した経験」は、積極的にアピールしましょう。担当したドキュメントの種類と分量も添えると具体性が増します。
SEならではの悩みに答える
「SESや客先常駐が長く、詳細を書けないプロジェクトが多い」
SESや客先常駐での就業経験がある方は、守秘義務を守りながら「業種・システム規模・担当工程・使用技術・自分の役割」で記述しましょう。「大手金融機関向けWebシステム(ユーザー数約1万名規模)の基本設計・詳細設計を担当(チーム12名中、画面設計の約30%を主担当)」のような形式で書けば十分伝わります。
「プログラミングよりも設計・コミュニケーションが多い場合、どうアピールする?」
上流工程(要件定義・設計・顧客折衝)に軸足を置くSEは「顧客の業務要件をシステム仕様に落とし込む力」「開発チームと顧客の橋渡し役」としてアピールできます。担当した要件定義の規模(ヒアリング回数・作成した要件定義書のページ数)を具体的に書きましょう。
例文
例①:SE・詳細設計〜テスト担当(経験3年・若手)
SIer(従業員数約500名)にて、流通業・製造業向けの業務系システム開発プロジェクトに参画。詳細設計・製造・テストを中心に担当。
【業務内容】
・詳細設計書の作成(画面設計・API設計・DB設計の補助)
・Java(Spring Boot)を使った業務ロジックの実装
・単体テスト・結合テストの設計・実施・エビデンス管理
・バグ管理・修正対応(Redmine使用)
・コードレビューの受領・フィードバックの反映
【担当プロジェクト】
・担当工程:詳細設計・製造・単体テスト・結合テスト
・詳細設計書:受注処理・在庫更新の画面・API設計を主担当として作成(全体の約25%)
・製造:Java(Spring Boot)でAPI約30本を実装
・結果:納期内・バグ件数ゼロでの本番稼働を達成
・担当工程:詳細設計・製造・テスト
・新機能3機能の詳細設計・実装・テストを主担当として完遂
【実績】
・2プロジェクト連続で納期内・品質目標達成を実現
・テスト設計の効率化を提案し、結合テスト工数を当初見積比約20%削減
・自動テストスクリプトを3本作成し、回帰テストの手動作業を削減
自己PRでのアピールポイント
詳細設計から製造・テストまでを一貫して担当してきた経験があり、コードの品質と納期の両立を意識して取り組んできた。上流工程(基本設計・要件定義)への参画を目指し、業務系システムのSEとしてさらにステップアップしたい。
例②:SE・リードSE(経験8年・中堅)
SIer(従業員数約2,000名)にて、金融・官公庁向けの大規模システム開発プロジェクトのSE・リードSEを担当。5年目からはリードSEとして後輩SEのレビュー・指導も担当。
【業務内容】
・要件定義(顧客ヒアリング・業務フロー分析・要件定義書の作成)
・基本設計・詳細設計の作成・レビュー
・製造・テストの品質管理・レビュー(リードSEとして担当メンバー5名分)
・顧客(業務部門・IT部門)との定例打合せ・課題管理
・設計書・手順書・マニュアルの作成統括
【担当プロジェクト(代表的な2件)】
・役割:リードSE(設計チーム8名を統括)
・担当工程:要件定義〜基本設計〜詳細設計のリード
・要件定義:業務部門担当者との週次ヒアリング(全12回)の主担当。機能要件180項目・非機能要件35項目を文書化
・結果:本番稼働後6ヶ月で重大障害ゼロ。ユーザー満足度調査で「使いやすい」回答が87%
・役割:SE(基本設計〜テストのリード担当)
・画面数:約80画面の基本設計・詳細設計を担当(全体の約60%)
【実績】
・担当した3プロジェクト連続で納期・予算・品質の三目標をすべて達成
・設計書のテンプレート整備を主導し、チームの設計書作成工数を平均25%削減
・後輩SE5名のレビューを担当し、設計書の品質向上に貢献(重大な設計ミスの指摘件数:年間約30件)
自己PRでのアピールポイント
要件定義から詳細設計まで上流工程の主担当経験と、リードSEとしてのチームマネジメント経験を持つ。顧客折衝・設計品質の管理・後輩育成まで担ってきた経験を次の職場でも活かしたい。
例③:アーキテクト・SE統括(経験15年・ベテラン)
事業会社(従業員数約3,000名)の情報システム部門にてSEチームリーダーとして勤務。社内システムのアーキテクチャ設計・ベンダーマネジメント・SEチーム10名のマネジメントを担当。
【業務内容】
・全社システムのアーキテクチャ設計・技術標準の策定
・SEチーム10名のマネジメント(目標設定・評価・育成)
・外部ベンダー(SIer3社)のマネジメント・品質管理・進捗管理
・新システム導入のRFP作成・ベンダー選定・契約交渉
・経営陣・業務部門への技術提案・コスト試算
【実績】
・マイクロサービス化・クラウド移行(AWS)を主導し、システム運用コストを3年間で年間約1億2,000万円から約7,000万円に削減
・老朽化基幹システムのリプレース(予算約5億円・ベンダー3社・期間2年)をベンダー側から発注側SEとして統括し、予算内・納期内で完遂
・SEチームの育成強化により、内製開発比率を30%から60%に向上(外部委託費を年間約8,000万円削減)
【主な取り組み】
クラウド移行はリフト&シフトから段階的なリアーキテクチャを組み合わせたアプローチを採用し、移行リスクと費用削減効果のバランスを設計した。基幹システムのリプレースでは発注側のSEとして要件定義・設計レビュー・テスト立会いを担い、ベンダーへの品質管理を主体的に行った。内製化の推進はSEチームのスキルマップを作成し、不足技術領域の計画的な育成プランを策定したことで実現した。
自己PRでのアピールポイント
SEの実務からアーキテクチャ設計・ベンダーマネジメント・SEチームのマネジメントまで幅広く担ってきた。「技術と経営をつなぐSEリーダー」として、次の職場でもシステム全体を見渡した貢献をしたい。
書き方ステップ
① これまでのプロジェクトをすべて書き出す(プロジェクト概要・予算・チーム人数・期間・担当工程・使用技術)
② 数字になるものを探す(予算規模・チーム人数・ユーザー数・バグ件数・パフォーマンス改善数値・工数削減率など)
③ スキルシートとプロジェクト経歴を対応させる(スキルシートに書いた技術が、どのプロジェクトで使ったかを確認する)
④ 担当工程ごとに「何を・どの範囲で・どんな役割で担ったか」を書く(「担当しました」ではなく、主担当の範囲と役割を明示する)
NG例 → 改善例|通らない書き方の直し方
失敗①:プロジェクトの規模感が書かれていない
失敗②:技術スタックの羅列で終わっている
失敗③:担当工程が曖昧
失敗④:成果が書かれていない
経験年数別アドバイス
経験3年未満(若手・担当者)
「担当したプロジェクトの規模・担当工程・使用技術」と「品質・納期への貢献」が評価のポイントです。上流工程の経験が少なくても「詳細設計を主担当した経験」「テスト設計を工夫した経験」など、自分が手を動かして主導した範囲を具体的に書きましょう。
経験3〜10年(中堅・専門担当)
「上流工程(要件定義・基本設計)への主担当経験」「リードSE・サブリーダーとしてのチームマネジメント」「顧客折衝の実績」が評価の軸になります。担当した設計書の規模(画面数・機能数・ページ数)と、チームでの役割を具体的に書きましょう。
経験10年以上(ベテラン・リーダー層)
アーキテクチャ設計・ベンダーマネジメント・SEチームのマネジメント・経営層との連携が最大のアピールポイントです。「チーム人数・担当プロジェクトの総予算・コスト削減額・内製化率の向上」など、組織全体のSE力を高めてきた実績を中心に書きましょう。
よくある質問
書き方次第で十分評価されます。複数の業種・システム・チームを経験してきた幅広さは強みになります。各プロジェクトを「業種・規模・担当工程・使用技術」でまとめ、経験の幅と深さを伝えましょう。
上流工程への関与はSEとしての高い市場価値の証明です。「要件定義で顧客の業務課題をシステム仕様に落とし込んだ経験」「顧客折衝での調整力」を積極的にアピールしましょう。
SEの職務経歴書はスキルシート込みで3〜4枚が目安です。プロジェクト数が多い場合は直近3〜5件を詳しく書き、それ以前は概要にとどめる構成が読みやすくなります。
「業務で主に使った言語」と「補助的に使った言語・学習中の言語」を分けてスキルシートに整理しましょう。「業務経験5年」の言語と「1ヶ月だけ使った」言語を同列に並べるのはNGです。
資格よりプロジェクト経験の内容が重視されます。ただし応用情報技術者・データベーススペシャリストなどは取得により差別化できます。取得を目指している場合は「取得予定」として記載しましょう。
まとめ
- 採用担当者は「プロジェクト規模・担当工程・役割・技術スタックと成果」をセットで見ている
- プロジェクトは「概要・規模・役割・担当工程・成果」の5点セットで書く
- 技術スタックは「使った技術・経験年数・習熟度・使用プロジェクト」で整理する
- 上流工程(要件定義・基本設計)の経験は積極的にアピールする
- 経験年数に応じて「担当工程と品質」「上流工程とリードSE」「アーキテクチャとマネジメント」を使い分ける
- NG例に共通するのは「規模感なし・技術の羅列・担当工程が曖昧・成果なし」の4パターン
SEの経験は正しく書けば必ず評価されます。まずはこれまでのプロジェクトの規模・担当工程・使用技術を書き出すところから始めてみてください。

