SESの職務経歴書の書き方｜客先常駐の案件経験を役割・工程・成果へ整理する方法

「スキルシートなら何度も出してきた。なのに職務経歴書となると、何をどこまで書けばいいのか分からない」——転職の準備を始めたSESエンジニアが、最初につまずきやすいのがこの書類です。

案件の数だけは多い。使った技術も並べられる。それでも手が止まるのは、書く材料が足りないからではありません。スキルシートと職務経歴書では、読む人も、読む目的もまったく違うからです。

この記事では、SESで積み重ねてきた案件の経験を、転職先の採用担当者が読んで分かる形へ書き換える手順を、具体例を交えて説明していきます。

スキルシートと職務経歴書は「読む人」が違う

まず押さえておきたいのは、この2つの書類が誰に向けたものか、という点です。

スキルシートは、案件に参画できるかどうかを判断する人のための資料です。読むのは主にSES企業の営業担当や、受け入れ側の客先。知りたいのは「この案件に必要な技術と工程の経験があるか」なので、言語・OS・担当工程・期間が一覧で並んでいれば用が足ります。呼び方や書式は会社によってさまざまですが、役割はおおむね共通しているでしょう。

職務経歴書を読むのは、採用担当者や配属先の責任者です。こちらが知りたいのは「この人は、うちに来て何ができそうか」。技術名が並んでいても、それをどんな場面で、どこまで自分の判断で使ってきたのかが見えなければ、判断のしようがありません。

ハローワークの資料でも、職務経歴書は自由様式で、A4縦1〜2枚程度に職務の内容を詳しく書く書類とされています（出典：ハローワークインターネットサービス「職務経歴書の作り方」）。決まった枠を埋める書類ではないぶん、何を選んでどう見せるかが、そのまま書き手の力量として読まれます。

つまり、スキルシートを職務経歴書へ写すのではなく、読む人に合わせて訳し直す。この作業だと考えておくと、書き方の迷いがかなり減るはずです。

最初に「全体の形」を決めておく

いきなり案件の説明を書き始めると、途中で「これ、どこに何を書くんだっけ」となりがちです。先に骨組みだけ決めてしまいましょう。

なお、応募先から書式の指定がある場合は、そちらに合わせるのが先です。ここから先は、指定がないときの組み立て方として読んでください。

軸にするのは所属会社。客先は案件として中に入れる

SESの経歴でいちばん混乱しやすいのが、所属会社と客先の関係です。

職務経歴書では、雇用されていた会社を職歴の単位にします。客先は、その会社に在籍していた期間に担当した「案件」として、内側に並べる形です。

株式会社〇〇テクノロジー（2022年4月〜現在）
  正社員／システムエンジニア

  ■ 物流会社向け 倉庫管理システムの保守・改修（2024年5月〜現在）
  ■ 保険会社向け 契約管理システムの結合テスト（2023年1月〜2024年4月）
  ■ 通信会社向け 社内ポータルの運用サポート（2022年6月〜2022年12月）

こうしておけば、どこに雇われていたのかと、どこで何をしてきたのかが一目で分かれます。客先の社名を自分の勤務先として書いてしまう、という取り違えも防げるでしょう。

案件が多いなら「キャリア式」という選択肢もある

職務経歴の並べ方には、大きく3つの形があります（出典：ハローワークインターネットサービス「職務経歴書の作り方」）。

編年体式：古い経歴から順に書く。迷ったときの基本形
逆編年体式：新しい経歴から順に書く。直近の経験を目立たせたいとき
キャリア式：職務内容の種類ごとにまとめる。経歴が多い場合など

短い案件をいくつも渡り歩いてきたSESの経歴は、時系列に並べると似た内容が続き、読み手が途中で疲れてしまうことがあります。そんなときは、「開発・改修」「テスト」「運用・保守」のように種類ごとにまとめるキャリア式が向いているかもしれません。

ただしキャリア式は、いつ何をしていたかが見えにくくなります。種類ごとにまとめた場合でも、在籍期間と案件の時期が分かる略歴は添えておくと安心です。

文は短く、体言止めを基本に

職務経歴の欄は、長い文章で書くより「〜を担当」「〜の改修」のように体言止めで短くまとめるのが一般的とされています。ハローワークの資料でも、自己PRや志望動機を除き、原則として体言止めにする書き方が紹介されています。

報告書のように文章で書き込むより、箇条書きと体言止めで区切ったほうが、採用担当者が短い時間で要点を拾えます。

1つの案件を、実際に書き起こしてみる

骨組みができたら、中身に入ります。

その前に一度だけ、これまでの案件を期間と概要だけでよいので、すべて書き出しておきましょう。手元のスキルシートや作業記録を見返しながら並べると、抜けや期間の重なりに気づけます。ハローワークの資料でも、職務経歴をすべて網羅したマスターシートを作っておき、応募先ごとに必要な内容を選ぶ方法が紹介されています。

そのうえで、最初はいちばん最近の案件を1つだけ選んで、詳しく書き起こしてみてください。全部を一度に詳しく書こうとすると、どれも中途半端になりがちです。

ここでは例として、物流会社の倉庫管理システムの保守・改修案件を書き起こしていきます（架空の例です）。

どんなシステムだったか

最初に書くのは、案件の概要です。客先名は伏せても構いません。業界と、そのシステムが何に使われていたかが分かれば十分伝わります。

物流会社向け倉庫管理システム（入出荷・在庫管理）の保守・改修

「社内システムの保守」だけだと、どんな業務を支えていたのかが読み手に見えません。用途をひと言添えるだけで、印象はずいぶん変わります。

チームのどこにいたか

次に、体制と自分の立ち位置です。人数は分かる範囲で構いません。

体制：保守チーム6名（うち自社3名）役割：メンバー。問い合わせの一次調査と、小規模な改修を担当

チームの人数だけを書いても、自分の役割は伝わりません。「その中で自分は何を任されていたか」まで書いて、はじめて意味を持ちます。

どの工程を担当したか

ここで気をつけたいのが、チーム全体の工程と、自分の担当工程を混ぜないことです。

プロジェクトとしては要件定義から運用まで回っていても、自分が関わったのが改修の実装とテストだけなら、書くのはその2つ。書類の上で工程を広げても、面接で具体的に聞かれたときに答えに詰まってしまいます。

担当工程：詳細設計（改修部分のみ）、実装、単体テスト、結合テスト、本番リリース後の確認

何を、どんな場面で使ったか

技術は、名前を並べるだけでなく、何に使ったかを添えると一気に伝わりやすくなります。

Java：出荷指示画面の入力チェック改修

Oracle Database：在庫データの不整合調査（SQLでの抽出・照合）

Linux：アプリケーションログの確認による障害の一次切り分け

Redmine：問い合わせ・不具合チケットの起票と進捗更新

「触ったことがある」程度の技術と、自分の作業で実際に使った技術は分けておきましょう。前者を同じ並びに入れてしまうと、面接で深掘りされたときに話がかみ合わなくなります。

自分が判断したこと、工夫したこと

最後の項目が、スキルシートにはまず書かれない部分です。そして、職務経歴書で最も読まれる部分でもあります。

在庫数の不整合に関する問い合わせが続いたため、原因の傾向を調べて一次切り分け用の確認表を作成。チーム内で共有し、調査の初動をそろえた

改修時に既存のテスト項目の漏れに気づき、境界値のケースを追加

大きな成果である必要はありません。「言われたことを、言われたとおりにやった」の一歩外側で、自分が気づいて動いたことを拾ってください。

Before / After｜スキルシートの一行は、こう変わる

ここまでの手順を、1つの案件でまとめて比べてみます。

Before（スキルシート）

期間：2024/05〜現在
案件：倉庫管理システム保守
言語：Java、SQL
工程：設計、製造、テスト、保守

After（職務経歴書）

■ 物流会社向け 倉庫管理システム（入出荷・在庫管理）の保守・改修
  期間：2024年5月〜現在
  体制：保守チーム6名／メンバー

  【担当業務】
  ・問い合わせの一次調査（ログ確認、SQLによる在庫データの照合）
  ・出荷指示画面の入力チェック改修（詳細設計〜結合テスト）
  ・本番リリース後の動作確認

  【工夫・取り組み】
  ・在庫不整合の問い合わせ傾向を調べ、一次切り分け用の確認表を作成・共有
  ・既存テスト項目に境界値ケースを追加

  【使用技術】Java／Oracle Database／Linux／Redmine

変わったのは、大きく3つです。何のシステムかが分かるようになったこと。チームの中の立ち位置が書かれたこと。そして、自分が気づいて動いたことが2つ加わったこと。

事実は一つも増やしていません。スキルシートに書かれていなかった「中身」を、言葉にしただけです。

SESの経歴で引っかかりやすい場面

書き進めていくと、SESならではの壁にいくつか当たります。よく出てくるものを挙げておきます。

客先名や案件名を書いていいか分からない

ここは、自己判断で書き切らないほうがよいところです。客先名や製品名、システムの詳細をどこまで書けるかは、所属会社のルールや客先との契約によって変わります。迷ったら、所属会社に確認するのがいちばん確実でしょう。

書けない場合でも、業界・用途・規模に言い換えれば、案件の性質は十分に伝わります。「大手保険会社」「数百名が利用する社内システム」くらいの粒度なら、読み手は状況を想像できるはずです。

伏せるのは固有名詞だけで、担当した工程や使った技術、自分の役割まで消す必要はありません。

テストばかりで、書くことがない気がする

「テストしかしていない」と感じている人ほど、テストの中身を分けてみてください。

用意された項目を実施していたのか。項目そのものを作っていたのか。不具合を見つけたとき、再現条件まで調べて開発側に渡していたのか。同じ「テスト担当」でも、ここで経験の厚みがまるで違って見えます。

一方で、設計していないテストを「テスト設計」と書くのは避けましょう。やったことを正確に書いたほうが、結局は面接でも強く出られます。

運用・保守で、作ったものがない

運用・保守は「新しく何かを作った」話になりにくい分、アピールしにくいと感じやすい仕事です。

ただ、採用する側から見れば、障害のときにどこまで自分で切り分けられるか、定型作業の手順を整えられるか、利用者からの問い合わせに的確に答えられるか、は十分に評価の材料になります。監視アラートへの対応、ログやSQLを使った調査、エスカレーションの判断。こうした一つひとつを、どこまで自分で担っていたかで書き分けるのがコツです。

成果を数字で示せない

「〇〇%削減」のような数字がないと書けない、と思い込んでいる人は少なくありません。けれど、測っていないものを無理に数字にする必要はありませんし、推測で盛るのはむしろ危険です。

数字がないときは、前と後で何が変わったかを書けば足ります。「問い合わせ対応の手順がそろい、担当者が変わっても同じ初動が取れるようになった」。これで十分、行動と結果が伝わります。

案件が多すぎて、1〜2枚に収まらない

SESを数年続けていると、案件が10件を超えることも珍しくないでしょう。全部を同じ分量で書くと、大事な経験が埋もれてしまいます。

応募先に関係の深い案件と直近の案件は厚めに、それ以外は1〜2行の概要にとどめる。それでも収まらない場合は、プロジェクトの一覧を別紙として付ける方法もあります。ハローワークの資料でも、「開発担当プロジェクト一覧」などを別紙で添える形が紹介されています。

短い案件をまとめて書く場合も、在籍期間や案件の期間そのものは、実際と違う形に変えないようにしてください。

「書けることがない」と感じたら、自分に聞いてみる

ここまで読んでも、まだ手元に書けそうな材料が見つからない。そんなときは、案件を一つ思い浮かべて、次の質問に答えてみてください。

その現場で、自分が休んだら誰が一番困っただろうか
よく人から聞かれて、答えていたことは何だったか
入ったばかりの頃と比べて、任される範囲は変わったか
自分が作ったり直したりした手順書やメモはあるか
後から入ってきた人に、何を教えたか

どれか一つにでも答えがあれば、それはもう職務経歴書に書ける経験です。「人に聞かれていたこと」は専門性の表れですし、「後から来た人に教えたこと」は、その現場を理解していた証拠になります。

それでも同じ作業しか思い浮かばず、この先も任される範囲が広がりそうにないなら、それは書き方ではなく環境の問題かもしれません。停滞の原因については、SESでスキルが伸びない原因と次の選択肢で扱っています。転職するかどうか自体をまだ決めかねている場合は、SESを辞めたいときの判断軸を先に読むほうが順番としては自然です。

出す前に、ここだけは見直す

書き上がったら、提出前に次の点を見ておきましょう。

所属会社と客先を取り違えていないか
チーム全体の工程を、自分の担当として書いていないか
測っていない数字や、やっていない業務が入っていないか
客先名などの固有名詞が、書いてよい範囲に収まっているか
年月に抜けや重なりがないか。誤字や表記のゆれはないか
応募先から書式や提出方法の指定がある場合、それに合っているか
スキルシートと期間や技術が食い違っていないか

最後の点は意外と見落とされがちです。職務経歴書とスキルシートは用途こそ違いますが、元になる事実は同じもの。応募先がどちらかを目にする可能性もあるので、期間や技術の記載はそろえておくと安心です。

まとめ

SESの職務経歴書は、スキルシートを書き写す書類ではありません。案件に入るための資料を、採用担当者が読める経歴へ訳し直す作業です。

まずは所属会社を軸に全体の形を決め、いちばん最近の案件を一つだけ、システムの概要・自分の立ち位置・担当工程・使った場面・自分の工夫の順に書き起こしてみてください。一つ書き上がれば、ほかの案件も同じ型で進められるはずです。

※職務経歴書に記載できる情報の範囲は、所属会社のルールや客先との契約によって異なります。判断に迷う場合は、所属会社へ確認してください。