「現場は何社も経験したのに、職務経歴書へ書こうとすると単なる作業一覧になってしまう」と手が止まっている人へ。客先常駐の職務経歴書は、常駐先の名前ではなく、各現場で担った役割・工程・工夫・成果をプロジェクト単位で整理することが重要です。
「テストを担当」「Javaで開発」と作業だけを並べるのではなく、何を任され、どう考えて行動し、現場に何を残したのかまで書くことで、客先常駐の経験は転職先にも伝わりやすくなります。
客先常駐の職務経歴書はどう書けばいい？
結論からいえば、客先常駐の職務経歴書は「所属会社」と「常駐先で経験したプロジェクト」を分け、職務要約、スキル、案件実績、自己PRの順で整理すると伝わりやすくなります。
客先常駐では勤務場所が何度も変わることがありますが、そのたびに転職したわけではありません。職歴として記載するのは、原則として自分と雇用契約を結んでいた所属会社です。
その所属会社の在籍期間の中に、実際に参画したプロジェクトを案件単位で並べます。
基本的には、次の情報を整理するとよいでしょう。
- SES・客先常駐としての経験年数
- 参画した業界やプロジェクトの概要
- プロジェクト期間
- 担当工程
- 自分の役割
- チーム規模
- 使用した言語・フレームワーク・DB・ツール
- 実際に行った業務
- 工夫したこと
- 成果や現場への貢献
- 保有資格
- 自己PR
2025年6月13日に最終更新されたレバテックキャリアのSES職務経歴書に関する解説でも、「職務要約」「経歴詳細」「自己PR」「所持資格やスキル」という構成が示されています。
また、2025年11月21日更新のGeeklyの記事でも、職務経歴要約、プロジェクトや実績の詳細、資格・スキル、自己PRを整理し、応募企業との関連性が高い経験を優先する考え方が紹介されています。
複数の転職支援サービスが共通して重視しているのは、案件数の多さそのものではありません。
採用担当者が「この人は入社後に何ができるのか」を判断できる情報になっているかがポイントです。
客先常駐では勤務場所や案件が変わるため、経歴が断片的に見えやすいという難しさがあります。
だからこそ、案件をただ時系列で羅列するのではなく、「自分のキャリアとして何が積み上がったのか」という軸を見せる必要があります。
会社名の知名度より先に確認したいのは、「どの工程まで経験し、どの程度自律的に仕事を進められるのか」です。
私は、ここが読み取れる職務経歴書なら、客先常駐という働き方そのものを必要以上に弱点として扱う必要はないと考えます。
客先常駐の職務要約には何を書く？
職務要約では、これまでのキャリア全体を数行で把握できる状態を目指します。
書くべき中心要素は、経験年数、担当領域、得意技術、経験した工程、顧客やチームとの関わりです。
たとえば、次のような情報を一つの流れにまとめます。
「SES企業で5年間、製造業・金融業向け業務システムの開発と運用保守に従事。Javaを中心に詳細設計、実装、テストを経験し、直近では仕様確認や顧客問い合わせ対応、新人メンバーのフォローも担当」
このように書けば、「5年経験している」という事実だけでなく、技術領域と担当範囲まで一度に伝えられます。
反対に、「さまざまな現場を経験しました」「多くのシステム開発に携わりました」といった抽象表現だけでは、採用側が実力を判断できません。
ムービンの客先常駐経験に関する解説でも、職務要約は経験年数、担当領域、得意技術、上流工程や顧客対応の経験などを3〜5行程度でまとめる形が示されています。
重要なのは、案件数よりもキャリアの軸です。
たとえば10案件経験していても、すべてを同じ密度で書けば要点がぼやけます。
応募先が社内SEなら、利用部門との調整、運用改善、障害対応、ベンダーとの連携などを優先します。
開発企業なら、設計、実装、レビュー、性能改善などを前に出す。PM・PMO系を目指すなら、進捗管理、課題管理、顧客折衝、メンバー支援などを目立たせるという考え方です。
同じ職歴でも、応募先によって価値の見せ方は変わります。
これは経歴を盛るという意味ではありません。事実の中から、応募先が判断したい情報を優先して配置するということです。
職務要約を書く前に、求人票の「仕事内容」「必須条件」「歓迎条件」を確認し、自分の経験との接点を探しておくと整理しやすくなります。
たとえば求人票に「利用部門との調整」が書かれているなら、単に「運用保守3年」とするより、「利用部門からの問い合わせ対応や仕様確認を担当」とした方が接点が明確です。
客先常駐のプロジェクト経験はどう伝える？
客先常駐の職務経歴書で最も重要なのが、プロジェクト経歴です。
各案件について、「いつ」「何のプロジェクトで」「どんな立場で」「何を担当し」「どう貢献したか」を同じ形式で整理します。
たとえば、以下のような形です。
プロジェクト概要
期間：2023年4月〜2024年8月
業界：製造業
概要：社内受発注システムの改修・運用保守
担当工程：詳細設計、実装、単体テスト、結合テスト、運用保守
技術環境：Java、SQL、Oracle、Linux
役割：開発メンバー
チーム規模：プロジェクト全体20名、所属チーム5名
担当業務：
- 既存機能の仕様調査
- 改修設計
- Javaによる実装
- テストケース作成
- 不具合調査
- 利用部門からの問い合わせ対応
実績・工夫：
既存仕様と改修依頼に食い違いがある場合は、影響範囲を整理してリーダーへ確認し、後工程での手戻り防止に努めた。問い合わせ対応では回答内容を整理し、チーム内で再利用できるよう手順書の更新も行った。
この例で重要なのは、「Javaを使った」という情報だけではありません。
既存仕様を調査したこと、影響範囲を確認したこと、リーダーと連携したこと、手順を共有可能な状態にしたことまで書かれています。
ここまであれば、採用担当者は技術だけでなく、仕事の進め方も推測できます。
数値化できる成果があるなら、より分かりやすくなります。
チーム人数、担当件数、処理時間、削減工数、問い合わせ件数など、事実として確認できるものは数字で示すと効果的です。
Geeklyの記事でも、経験年数、プロジェクト人数、リーダーとして担当した人数、削減率、短縮率など、定量化できる実績は数字で伝える考え方が示されています。
ただし、数字を作る必要はありません。
「業務時間を30％削減」などと正確に測定していない成果を後から推測で書くと、面接で根拠を問われたときに説明できなくなります。
数値がなければ、「問い合わせ手順を標準化した」「レビュー観点を整理した」「認識齟齬を防いだ」「障害原因の切り分けを行った」など、変化が分かる表現で十分です。
私は、職務経歴書を派手な成功事例を競う資料にする必要はないと思っています。
何を担当し、どこまで自分で考えて動けたのかを事実ベースで示す方が、採用後の再現性まで伝えやすいからです。
案件が多い場合はすべて同じ長さで書かない
客先常駐では、数年の間に複数の案件を経験している人も珍しくありません。
その場合、10年前の短期案件と直近の主力案件を同じ分量で書く必要はありません。応募先との関連性が高い案件ほど詳しくし、古い案件や補助的な案件は簡潔にまとめた方が、読み手が重要な経験を把握しやすくなります。
一方で、期間を省略しすぎると職歴に空白があるように見える可能性があります。
案件自体は時系列で追えるように残しながら、説明の密度に差をつけるのが現実的です。
今の市場価値を確認するなら：
客先常駐エンジニアにおすすめの転職エージェント5選
開発・運用保守・テスト経験はどう書き換える？
客先常駐経験者が自分の経歴を過小評価しやすいのが、開発、運用保守、テストといった実務です。
「テストしかしていない」「保守ばかりだった」と感じる人もいますが、採用で評価される材料は担当工程の名前だけではありません。
開発経験は「何を作ったか」だけで終わらせない
「Javaで画面機能を開発」とだけ書くと、採用担当者には担当範囲しか分かりません。
そこに「既存処理への影響を調査した」「仕様上の不明点を確認した」「レビュー指摘を受けて共通処理化した」などを加えれば、技術の使い方が見えてきます。
開発経験で伝えたいのは、プログラミング言語の名前だけではありません。
仕様理解、問題分析、設計判断、周囲との調整まで含めて、実務能力として示すことが重要です。
運用保守は「安定稼働への貢献」として考える
運用保守も、「問い合わせ対応」「障害対応」だけでは仕事内容の価値が見えにくくなります。
たとえば、問い合わせの原因を分類した、障害発生時にログから影響範囲を確認した、再発防止のため手順書を更新した、といった行動まで分解します。
運用保守では利用者に近い場所で仕事をするため、業務理解や関係者調整の経験を得やすい面があります。
社内SEなどを目指す場合、この経験はむしろ接続しやすい部分です。
システムを作る能力だけでなく、「運用された後に何が起こるのか」を理解していることは、事業会社側でも意味を持つからです。
テスト経験は「仕様理解と品質確保」で考える
テストについても同様です。
「テストケースを実行した」だけなら、作業としてしか見えません。
一方で、「仕様書からテストケースを作成した」「業務フローを踏まえて不足観点を追加した」「発見した不具合の類似箇所を確認した」まで書けば、仕様理解と品質意識が伝わります。
ムービンの記事でも、テスト経験は仕様理解力、業務理解力、品質に対する意識、関係者への確認・調整力として表現できると整理されています。
私はこの考え方には合理性があると思います。
工程名だけで人材価値を判断すると、その人が現場で実際に考えていたことが抜け落ちるからです。
問題は「テスト経験しかないこと」ではなく、そのテスト業務から何を理解し、どこまで自分で判断していたのか説明できないことです。
常駐先の会社名や案件名は職務経歴書に書いてもいい？
客先常駐の職務経歴書では、常駐先の実名を安易に記載しない方が安全です。
常駐先企業との契約や秘密保持義務によっては、企業名、サービス名、製品名、システム名などが機密情報に該当する可能性があります。
レバテックキャリアの記事でも、常駐先や製品名など、相手を特定できる情報が含まれていないか確認することが注意点として挙げられています。
Geeklyも、SES経験者について、常駐先との秘密保持契約がある場合は常駐先企業名を記載できない点を説明しています。
判断できない場合は、「大手通信会社向け顧客管理システム」「国内金融機関向け基幹システム」「製造業向け受発注管理システム」「小売業向け社内業務システム」のように抽象化すれば仕事内容は伝えられます。
この程度でも、業界やシステムの性質は把握できます。
実名を書くことより、どの業界のどのような業務に関わったかを説明できる方が採用側には有益です。
また、一次請け、二次請け、三次請けといった商流を必ず記載する必要もありません。
もちろん、エンドユーザーとの直接調整を担当していたことを説明するために商流が必要なら補足して構いません。
しかし採用担当者が知りたいのは、「三次請けだった」というラベルそのものではなく、その環境で誰と関わり、何を任されていたかです。
商流が深い環境でも、仕様確認、課題管理、進捗共有、後輩フォローなどを担っていたのであれば、その経験を書いた方が人物像は明確になります。
案件終了についても、「契約満了」「プロジェクト終了」「体制変更」など、必要なら簡潔に書けば足ります。
職務経歴書の中心を退場理由にする必要はありません。
守秘義務の範囲が判断できない場合は、所属会社のルールや契約上の取り扱いを確認してください。職務経歴書を詳しく見せることより、守るべき情報を守ることが優先です。
採用担当者は客先常駐経験のどこを見る？
客先常駐の職務経歴書で見られるのは、技術力だけではありません。
複数の参考記事で共通して挙げられているのが、具体性、主体性、読みやすさ、企業との適合性、成長意欲です。
レバテックキャリアでは、採用担当者が見るポイントとして、企業が求める人材との一致、具体的な経歴、成長意欲、主体的な取り組みなどを挙げています。
Geeklyでも、職務経歴が読みやすいか、募集要項と経験に大きな乖離がないか、定性情報だけでなく定量情報があるか、案件に当事者意識を持っていたかなどが重要とされています。
とくに注意したいのが「指示された仕事をこなしました」で終わる書き方です。
客先常駐ではプロジェクト側から業務を割り振られる場面が多いため、本人の主体性が書類上で見えにくくなることがあります。
そこで、「曖昧な仕様について事前に確認した」「繰り返し発生する問い合わせを整理した」「手作業だった確認作業を効率化した」「新人向けに手順を整理した」「レビューで見落としやすい観点を共有した」「障害発生時の確認項目を標準化した」といった小さな行動まで棚卸しします。
必ずしも会社全体を変えるような改善である必要はありません。
自分の担当範囲の中で、問題を認識して行動した事実があれば、それは主体性を説明する材料になります。
もう一つ重要なのが、顧客や関係者との接点です。
正式な顧客折衝を担当していなくても、仕様確認、定例会参加、問い合わせ対応、進捗報告、議事録作成なども関係者とのコミュニケーション経験です。
「顧客折衝経験なし」と一括りにする前に、自分が誰と何を調整していたかを確認した方がよいでしょう。
年齢やキャリア段階によって、見せるべきポイントも変わります。
20代など経験が浅い段階なら、技術習得力、コミュニケーション、主体的な学習なども評価材料になります。
経験を重ねるにつれて、専門領域、設計経験、顧客との調整、リーダー経験、後輩育成、プロジェクト推進など、より広い役割を説明できることが重要になってきます。
ただし、「30代だから必ずマネジメント経験が必要」と単純化するのも適切ではありません。
高度な技術専門性など別の軸で価値を示せる場合もあるため、自分が何を強みにするかを明確にする必要があります。
スキルシートと職務経歴書は同じ内容でいい？
同じプロジェクト情報を使うことはできますが、役割は異なります。
スキルシートでは期間、担当工程、言語、OS、DB、ツールなど、「何を経験したか」を確認しやすい形式が中心になります。
一方、職務経歴書では、その経験を通じて何ができる人なのか、応募企業でどの能力を再現できるのかまで伝える必要があります。
そのため、SES企業で使っていたスキルシートをそのまま提出するだけでは、担当技術は分かっても「強み」が伝わらない場合があります。
職務経歴書では、案件ごとの技術情報に加えて、役割、判断、工夫、成果を補うのがポイントです。
客先常駐の職務経歴書で避けたい書き方は？
最も避けたいのは、案件名、担当工程、技術だけを一覧にした職務経歴書です。
たとえば、「金融システム開発」「Java」「詳細設計〜テスト」だけでは、採用担当者は本人の実力をほとんど判断できません。
少なくとも、「担当した機能」「自分の役割」「工夫」「周囲との関わり」のいずれかを加える必要があります。
また、専門用語を詰め込みすぎるのも注意が必要です。
最初に職務経歴書を読む人が、必ずしもエンジニアとは限りません。人事担当者でも理解できる程度の言葉に置き換え、必要な技術用語だけを使う方が読みやすくなります。
誤字脱字も軽視できません。
レバテックキャリアの記事では、プログラミングなど正確性を求められる仕事であることから、職務経歴書の誤字脱字が注意力への印象にも影響し得ると説明されています。
少なくとも、年月、技術名、会社名、資格名、担当期間などの誤記は提出前に確認した方がよいでしょう。
とくに客先常駐では、案件期間が連続していることが多いため、「2023年4月〜2024年8月」と「次案件が2024年7月開始」のような期間の重複や、所属会社の在籍期間との矛盾にも注意が必要です。
情報量にも注意が必要です。
同記事では、職務経歴書全体について1,000〜1,500文字程度、A4用紙1枚程度を一般的な目安として示しつつ、書くべき内容があれば文字数自体に過度に縛られる必要はないとしています。
実務経験が長い人まで無理に1枚に押し込む必要はありません。
重要なのはページ数を減らすことではなく、応募先との関連性が低い古い案件を簡略化し、重要な経験を読みやすくすることです。
そして、SESや常駐先への不満を職務経歴書の中心にするのも避けたいところです。
「商流が深かった」「給料が上がらなかった」「希望案件に入れなかった」という事情が実際にあったとしても、それだけでは次の会社で何をしたいのかが見えてきません。
「これまで開発と運用を経験したため、今後は利用部門との要件整理から携わりたい」「複数現場で培った運用経験を活かし、社内側でシステム改善に関わりたい」といった形で、これまでの経験と次のキャリアを接続する方が合理的です。
客先常駐経験を「作業」ではなく「能力」に変換する
ここからは私見です。
客先常駐の職務経歴書で本質的に難しいのは、経験が弱いことではなく、プロジェクトごとに分断された経験を、自分の能力として再構成することだと考えています。
SESでは、「A社ではJava開発」「B社ではテスト」「C社では運用保守」というように、案件ごとに仕事が切り替わることがあります。
そのまま職務経歴書に転記すると、キャリアもバラバラに見えます。
しかし、少し抽象度を上げると別の見え方になります。
A社では仕様を理解して実装した。B社では仕様から品質リスクを探した。C社では利用者の問い合わせから運用課題を見つけた。
この3つは、「業務や仕様を理解し、問題を発見して対応する」という一本の能力として整理できます。
ここが、スキルシートと職務経歴書の大きな違いだと私は見ています。
スキルシートは、プロジェクト期間、担当工程、言語、OS、DBなど、「何を経験したか」を技術中心に整理する資料です。
一方の職務経歴書は、その経験から「どのような人材なのか」を採用企業へ伝える役割があります。
そのため、スキルシートをそのまま職務経歴書に貼り付けても十分ではありません。
経験を列挙した後に、「複数の現場でも短期間で仕様を理解できる」「利用者と開発側の認識を整理できる」「運用課題を改善につなげられる」「品質上のリスクを事前に確認できる」といった再現可能な能力へ変換する必要があります。
ここは、客先常駐経験者が職務経歴書を作るうえで、とくに注目すべき点です。
勤務先が変わらないまま複数の現場を経験してきた人ほど、「どこで働いたか」ではなく「現場が変わっても繰り返し発揮した能力」を探すべきでしょう。
生成AIによって、コード生成、テストケース案の作成、定型文書の整備などが効率化されていく可能性もあります。
その環境では、使用技術の一覧だけで差をつけることはさらに難しくなると考えられます。
一方、曖昧な要望を整理する、既存仕様との矛盾を発見する、利用者と開発者の認識を合わせる、障害の原因を切り分けるといった仕事は、現場理解と判断を伴います。
だからこそ、職務経歴書にも「何を使ったか」だけではなく「何を考え、どう判断したか」を残しておく価値があります。
SESから社内SE、自社開発、SIer、ITコンサルなどへ移る場合も、この整理が転職理由との一貫性につながります。
客先常駐という業態そのものを否定する必要はありません。
どの環境で働いてきたかと、そこで何を身につけたかは別の話です。
SESからの脱却を考える場合も、気合やイメージではなく、自分の経験が次の職種のどの業務へ接続するのかを構造的に整理する方が判断しやすくなります。
転職するか決めてから職務経歴書を作るのではなく、職務経歴書を作って自分の市場価値を可視化してから、転職するか判断すればいい。
今の市場価値を確認するなら：
客先常駐エンジニアにおすすめの転職エージェント5選
職務経歴書を作ったからといって、必ず転職する必要はありません。むしろ案件名や技術名の裏側にある自分の能力を棚卸しするだけでも、現職に残る場合を含めた判断材料になります。
まとめ
客先常駐の職務経歴書では、所属会社と常駐先プロジェクトを分け、案件ごとに期間、概要、担当工程、役割、技術、業務内容、工夫、成果を整理することが基本です。
とくに重要なのは、「Javaで開発した」「テストを担当した」といった作業の記録だけで終わらせないことです。
開発なら課題解決、運用保守なら安定稼働や改善、テストなら仕様理解と品質確保というように、自分の行動が現場へどのような価値を与えたかまで言語化すると、経験の意味が伝わりやすくなります。
常駐先企業名やサービス名などは、守秘義務を優先し、必要に応じて「大手通信会社」「金融機関向けシステム」などへ抽象化します。
また、数値化できる成果は具体的に書きつつ、確認できない数字を無理に作る必要はありません。
職務経歴書で採用担当者が確認したいのは、「有名な案件にいたか」ではなく、そこで何を任され、どう仕事を進め、次の会社でも何を再現できるのかです。
客先常駐の経験が長い人ほど、案件一覧を作って終わらせず、複数現場に共通する自分の強みまで整理することが、次のキャリアを説明するうえで重要です。
よくある質問
客先常駐の会社名は職務経歴書に書いてもいい？
契約や秘密保持義務を確認できない場合は、実名を避ける方が安全です。
「大手製造業」「国内金融機関」「通信会社向けシステム」など、仕事内容を理解できる範囲で抽象化すれば、企業名を出さなくてもプロジェクト経験は説明できます。
客先常駐の現場が多いと転職回数が多く見えない？
雇用契約を結んでいる所属会社と、参画したプロジェクトを明確に分けて書けば、通常は常駐先の変更を転職として記載する必要はありません。
所属会社の在籍期間の下に、案件単位でプロジェクト経歴を整理すると分かりやすくなります。
テストや運用保守しか経験がなくても職務経歴書でアピールできる？
可能です。
テストなら仕様理解、テスト設計、不具合分析、品質改善、運用保守なら障害対応、問い合わせ分析、手順改善、利用部門との調整など、自分が考えて行動した部分まで整理してください。
工程名そのものより、そこで何を理解し、どのような役割を果たしたかを説明できることが重要です。
あわせて読みたい
執筆：新海 智也
SESや客先常駐から抜け出したい人に向けて、退職・転職の仕組みと、各サービスの中身を調べてまとめています。