SESで「大した経験がない」と感じる人へ｜客先常駐の経験を転職で伝わる実績に変える方法
対象：SES・客先常駐で、「詳細設計とテストだけ」「障害対応ばかり」など、経験をうまく説明できないと感じている方
公開 2026年8月16日 更新 2026年10月25日 読了 約12分
SES・客先常駐で働いていると、自分の経験をうまく説明できないことがあります。
- 詳細設計とテストを担当しただけ
- 障害対応ばかりだった
- 現場が変わるたびに違う仕事をしてきた
- 資格は取ったけれど、開発経験に自信がない
しかし、SES経験そのものが評価されないわけではありません。
転職時に伝わりにくい原因は、経験を「SES」「常駐」「運用」といった働き方や職種名だけで説明していることにあります。
この記事では、客先常駐で経験した業務を、転職先が判断できる言葉へ整理する方法を解説します。
この記事の要点
- SESという働き方だけで、市場価値は判断できない
- 担当範囲・改善・関係者との調整を分けて整理する
- 経験の中心によって、比較できるキャリアは変わる
- 職務経歴書には、実際に担当した範囲だけを書く
SES経験が伝わりにくい理由
SESでは、プロジェクト全体ではなく、一部の工程や機能を担当することが少なくありません。
自分の仕事がプロジェクト全体へどう影響したのか見えにくいため、職務経歴書も次のような表現になりがちです。
- 客先で開発を担当
- 運用保守に従事
- 障害対応を担当
- 詳細設計からテストまで担当
- 複数の現場を経験
これらは間違いではありません。ただし、採用側から見ると「具体的に何ができる人なのか」を判断できません。
必要なのは、仕事を大きく見せることではなく、実際に担当した範囲を分解することです。
職種名・働き方だけ
- SES
- 客先常駐
- 運用保守
判断できる言葉へ分解
- どこまで担当したか
- 何を改善したか
- 誰と何を調整したか
経験を整理する3つの軸
1
担当範囲
どこまでやったか
2
改善
以前より何が良くなったか
3
調整
誰と何を確認したか
1．どこまで担当したか
まず、担当工程と役割を整理します。例えば「開発を担当」だけではなく、次のように分けます。
- 基本設計書をもとに詳細設計を作成した
- Javaで実装した
- 単体テスト仕様書を作成した
- 結合テストで発生した不具合を調査した
- リリース後の問い合わせに対応した
同じ開発経験でも、設計・実装・テスト・運用のどこまで関わったかによって、比較できる求人は変わります。
2．何を改善したか
大きな成果でなくても構いません。日常業務の中で「以前より良くしたこと」があれば、改善経験として整理できます。
- 手順書を更新した
- よくある問い合わせをFAQにまとめた
- テスト観点を追加した
- チェック作業を自動化した
- 引き継ぎ方法を標準化した
- 障害の再発防止策を整理した
ただし、工数や件数などの数値は、事実として確認できる場合だけ使用します。
3．誰と何を調整したか
SESでは、顧客担当者や他チームとの調整も重要な経験です。
- 仕様の不明点を顧客担当者へ確認した
- 障害発生時に関係部署へ影響範囲を共有した
- 開発チームへ調査結果を連携した
- ベンダーへ対応状況を確認した
- リーダーへ進捗や課題を報告した
こうした経験は、上流SE、PL、PMO、社内SEなどを比較するときの判断材料になります。
伝え方のBefore／After
常駐という働き方ではなく、案件内で任された範囲と残した変化が伝わる形へ直した例です。
障害対応
Before
障害対応を担当しました。
After
業務システムの障害発生時に、ログ確認による一次切り分け、影響範囲の特定、関係部署への状況共有を担当。復旧後は対応手順と確認項目を更新した。
開発
Before
客先でJava開発を担当しました。
After
Javaを使用した業務システム開発で、詳細設計、実装、単体テストを担当。仕様の不明点を整理し、リーダーへ確認しながら手戻りの防止に取り組んだ。
テスト
Before
結合テストを担当しました。
After
結合テストの実施、不具合の再現確認、原因箇所の切り分けを担当。調査結果を開発担当者へ共有し、修正後の確認まで行った。
運用・問い合わせ対応
Before
システムの運用保守を担当しました。
After
社内利用者からの問い合わせについて、操作ミス・権限・システム不具合を切り分け、必要に応じて開発部門へ連携。頻出する問い合わせは手順書へ反映した。
これらはあくまで整理例です。実際に担当していない工程や成果を追加してはいけません。
経験の中心から比較できるキャリア
SESからの次を「自社開発だけ」に絞る必要はありません。現在の経験が実装中心なのか、改善中心なのか、関係者との調整中心なのかによって、比較すべき方向は変わります。
社内の利用者支援や運用改善を続けたいなら社内SE・情シス、顧客のシステム導入や説明へ広げたいならITコンサルの条件を比べます。仕様を確認した経験と、課題を整理して提案した経験は分けてください。
実装・レビュー
開発・技術特化
技術と品質の担当範囲を先に書く
障害対応・運用
社内SE・運用改善
切り分けと再発防止を軸にする
顧客との仕様確認
上流SE・PL
要件との接点を工程名より先に書く
伝わりにくい例
客先でJava開発および運用保守を担当しました。
判断できる例
業務システムの詳細設計・実装・単体テストを担当。仕様の不明点をリーダーへ確認し、結合テストで出た不具合の切り分けを開発へ戻した。
- 担当工程が詳細設計〜テストか、要件確認を含むか
- 顧客折衝が「あり」のとき、誰と何を決める役割か
- 運用・障害対応が主業務か、開発の一部か
- 常駐前提か、自社開発・社内SEか
- 必須スキルが技術名だけか、切り分け・改善の記述があるか
| 経験の中心 | 整理するポイント | 比較しやすい方向 |
|---|---|---|
| 実装・レビュー | 技術、品質、担当工程 | 開発・技術特化 |
| 障害対応 | 切り分け、復旧、再発防止 | 社内SE・運用改善 |
| 顧客との仕様確認 | 要件整理、説明、調整 | 上流SE・PL |
| 複数チームの調整 | 課題管理、進捗、連携 | PMO・PL |
| 自動化・手順改善 | 改善対象、自分の判断、導入後の確認 | 社内SE・運用改善 |
| 開発・導入と顧客説明 | 技術案の比較、説明、合意後に担当した範囲 | IT導入・業務改善コンサル |
SES経験を「次の職種」に接続する判断材料
利用者支援や運用改善を続けたいなら社内IT、開発・導入と顧客説明を広げたいならITコンサルの条件も比較します。どちらかへ必ず進む必要はありません。技術実装や上流工程を深める選択肢も残し、自分が担当した仕事を先に整理します。
求人要件との対応
| 求人要件 | 現在確認できる経験 | 証拠 | 不足・未確認 | 次の行動 |
|---|---|---|---|---|
| 要件・仕様との接点 | 詳細設計や実装で不明点を整理し、リーダーや顧客側へ確認した経験 | 質問票、課題票、仕様変更履歴 | 要求を直接整理した範囲と最終判断者は未確認 | 案件ごとに確認内容・相手・反映先を一行で対応させる |
| 障害対応・運用改善 | ログ確認、一次切り分け、影響共有、手順更新 | 障害記録、更新前後の手順、共有履歴 | 恒久対策の設計・承認範囲は未確認 | 復旧作業と再発防止を分け、自分が完了させた範囲だけを書く |
| レビュー・品質判断 | テスト、不具合再現、コードや設計のレビュー補助 | 指摘内容、修正確認、テスト観点 | レビュー基準を決めた経験は未確認 | 件数ではなく、何を見てどこへ戻したかを残す |
次の職種へ進む前に不足しやすい条件
上流へ進むなら
業務要件を直接決めた経験がなくても、要件の曖昧点を誰に確認し、設計へどう反映したかを1件は示せる状態にします。
社内SEへ進むなら
障害を直した事実だけでなく、利用者影響・優先順位・ベンダー依頼の境界を説明できる必要があります。
ITコンサルへ進むなら
顧客が困っていたこと、比較した案、説明した相手、合意後に担当した範囲を確認します。資料作成や会議参加を、提案・要件定義の主担当経験へ読み替えません。
技術特化へ進むなら
技術名の列挙では足りません。難しかった制約、比較した案、選んだ理由、確認方法を残します。
今は進まない方がよいケース
- 「常駐を離れたい」だけで応募先を決め、次の職場で担いたい役割が決まっていない場合
- 顧客折衝や要件定義を、実際に担当していないのに応募要件へ合わせて足そうとしている場合
- 複数案件の経験を一つに混ぜないと、担当範囲を説明できない場合。先に案件単位で事実を分けます
90日で作れる実績
-
1〜30日
案件を1件選び、担当工程・確認先・判断した範囲・残した成果物を1枚に整理する
残す証拠：案件事実シートと、職務経歴書のBefore／After1組
-
31〜60日
現場で繰り返す不具合・問い合わせ・手戻りを1つ選び、確認順や手順を更新する
残す証拠：更新前後の手順、レビュー記録、関係者へ共有した内容
-
61〜90日
社内SE・情シスとITコンサルのうち、続けたい仕事に近い求人を読み、担当経験を照合する。技術・上流を深めたい場合はその求人も比べる
残す証拠：必須要件／担当経験／証拠／不足・要確認／次の行動の対応表
診断で表示される求人方向の読み分け
- 上流SE／PL・PM候補
- 顧客確認や設計へ戻した事実を先頭に置く。工程名だけなら、要件との接点を90日で作る。
- PMO
- PMOなら課題・期限・依存関係、ITコンサルなら顧客課題・比較案・説明・導入の範囲を確認する。自分の担当と、上司や顧客が判断したことを分ける。
- 社内SE／DX・IT企画
- 問い合わせ件数より、利用部門・ベンダー間の判断と再発防止を示す。
- アプリ・インフラ・クラウド
- 実装・レビュー・品質判断の深さを証拠にする。常駐形態は主論点にしない。
- 現職で実績づくり
- 転職を急がず、担当範囲を広げた証拠を1件作ってから求人比較をやり直す。
自分の経験を確認するチェックリスト
案件名や常駐期間ではなく、自分が任された範囲として答えられるか確認します。空欄になった項目は、案件記録を見直すか、次の現場で証拠を残す対象です。
- 担当工程を具体的に説明できる
- 自分が判断した範囲と、上司へ確認した範囲を分けられる
- 障害や不具合に対して、どこまで対応したか説明できる
- 手順化・自動化・品質改善の経験がある
- 顧客や他チームと調整した内容を説明できる
- 使用技術だけでなく、その技術で何を担当したか説明できる
- 次の職場でも再現できる経験を1つ以上挙げられる
まずは、次の選択肢を比較できる状態にする
SESを離れることだけを結論にせず、実装・障害対応・顧客調整のどこに再現できる証拠があるかで、比較する求人方向を決めます。
- 社内SE・情シス
- IT導入・業務改善コンサル
- 上流SE
- PL・PMO
- 開発・技術特化
- インフラ・運用改善
ITキャリア診断では、3ステップで現在地・担当範囲・希望を確認し、10の求人方向を比較します。結果はキャリアの決定ではなく比較の入口であり、個別案件の事実や求人ごとの条件は別に確認が必要です。
関連記事
この記事は経験の伝え方の整理です。転職成功や年収アップを保証するものではありません。診断結果はキャリアを決定するものではなく、比較候補を並べるための仮説です。数値は、事実として確認できる場合のみ使ってください。