「SES やめとけ」が検索の上位を埋めているけれど、本当にダメなのか、自分の場合はどう判断すれば、迷っていませんか。実際、ラッコキーワードの実測(2026 年 5 月時点)でも「SES やめとけ」は月 930 人以上が検索しており、私自身も営業 7 年 → 未経験 SES 2 年半 → 自社開発 3 年強 → 現役の生成AIエンジニアという 3 段階を歩いてきた当事者です。
結論から言うと、「SES やめとけ」は半分本当・半分言い過ぎで、戦略のない未経験で飛び込めば地雷を踏みやすい一方、2-3 年で次に移る設計図を持って入れば IT 業界への現実的な入口になるのが筋です。本記事では、SES の定義、やめとけ理由 7 つの現役視点での仕分け、2.5 年で学べたこと・きつかったこと、面接前 4 項目、2026 年の 3 つの出口(自社開発/社内 SE/生成AIエンジニア)まで、業務で日々 ChatGPT・Claude・Cursor・Claude Code を叩いている現役の生成AIエンジニア視点で整理します。
結論:「SES やめとけ」は半分本当で、半分は言い過ぎです
「SES やめとけ」は半分本当で、半分は言い過ぎです。戦略のない未経験で飛び込めば地雷を踏みやすいのは事実ですが、2-3年で次のキャリアに移る設計図を最初から持って入れば、SES は IT 業界に入る現実的な入口になり得ます。本記事は、私自身が営業7年 → 未経験 SES 2年半 → 自社開発 3年強 → 現役生成AIエンジニアという 3段階を歩いた一次体験を起点に、入口の判断軸・地雷の見分け方・2026年の出口戦略(生成AIエンジニア含む)まで、正直に並べた地図です。
本記事の射程は9セクション。SES の定義/「やめとけ理由 7つ」の現役視点での仕分け/2.5年いて本当にきつかったこと・本当に学べたこと/向き・不向き/面接前に確認しておきたかった4項目/2-3年で使い倒す設計図/3つの出口(自社開発・社内SE・生成AIエンジニア)/営業や事務職から入る人へのコツ/今週やる3つのこと——を、業務で日々 ChatGPT・Claude・Cursor・Claude Code を叩いている現役の生成AIエンジニア視点でまとめています。
そもそも SES とは何か——「やめとけ」を語る前の前提整理
📖 この章で使う用語
- SES(エス・イー・エス):System Engineering Service の略。エンジニアを取引先の現場に常駐させて働かせる契約形態。営業時代の「客先常駐の保守要員」に近い構図。
- 自社開発:自分の会社が自社の製品を作る形態。商社で言えば「自社製品の物販」と同じ立ち位置。
- 請負:成果物(完成したシステム)を納める契約。営業の物販で言えば「在庫を持って売る」イメージ。
- 派遣:労働力を提供し、指揮命令は派遣先にある契約形態。SES との違いは「指揮命令系統がどこにあるか」。
「やめとけ」の議論に入る前に、SES が何ものなのかを、未経験のあなた向けに一段噛み砕いておきます。
SES は System Engineering Service の略で、自分の所属する会社(SES 企業)が、取引先の現場にエンジニアを送り込んで働かせる契約形態のことです。営業時代の私の感覚で言い直すと、「客先常駐の保守要員を、自社が雇って取引先に派遣しているような形」が一番近い。ただし契約上は派遣とは別物で、指揮命令は所属している SES 企業に残っているのがポイントです。
派遣・請負・自社開発との違いを4列で並べると、こうなります。
| 形態 | 指揮命令 | 成果物の責任 | あなたの雇い主 | 例え |
|---|---|---|---|---|
| SES(準委任) | SES 企業 | 労働時間に対する責任 | SES 企業 | 客先に常駐する自社の保守要員 |
| 派遣 | 派遣先 | 労働時間に対する責任 | 派遣会社 | 派遣先が「今日はこれやって」と直接指示 |
| 請負 | 受注側 | 成果物(完成品)に責任 | 受注側 | 在庫を持って完成品を売る物販 |
| 自社開発 | 自社 | 自社プロダクトの全責任 | 自社 | 自社製品を自社で作って自社で売る |
未経験で IT 転職を考えるとき、SES が候補に挙がりやすい理由はシンプルです。求人の母数が圧倒的に多いこと、そして未経験を受け入れる間口が広いこと。これは IT 業界の構造そのものに起因しています。詳しい全体地図は未経験エンジニア転職の地図。
私自身、営業 7年から未経験で IT に入るとき、最初の入口として選んだのが SES でした。約2年半在籍して、Ruby による業務改善や、人とモノを「線でつなぐ」graphDB を使った基幹システムの開発に携わりました。その経験は今の自社開発でも、生成AI 関連の実装でも、土台として効いています。SES を全否定するつもりは、私には一切ありません。
「SES やめとけ」と言われる 7つの理由——どれが本当で、どれが言い過ぎか
📖 この章で使う用語
- 多重下請け:1次受け(プライム)→ 2次→ 3次… と再委託が連鎖する構造。商社の「メーカー → 商社 → 二次代理店 → 末端」の構図と同じ。
- 待機:プロジェクトとプロジェクトの間、案件が決まらず社内待機している状態。営業時代の「次の商談に入る前の社内事務」のような期間。
- プライム案件:最終クライアントから直接受けている案件。マージンが抜かれる層が少なく、給与・経験ともに有利になりやすい。
検索結果の上位には「SES やめとけの理由 7つ」のような網羅型記事が並びます。同じ7つを、現役視点で「本当 / 半分本当 / 言い過ぎ」に仕分けしてみます。私自身の SES 2年半の体感だけを根拠に書きますので、「私の場合は」という限定の話としてお読みください。
| # | 言われる理由 | 私の仕分け | コメント |
|---|---|---|---|
| 1 | 給料が上がりにくい | 本当 | 出口の設計次第で挽回可能 |
| 2 | スキルが身につかない(偏る) | 本当 | 案件に依存、私自身も実感 |
| 3 | 案件選択権がない | 自分は当てはまらなかった | 体感としては想像より自由度があった |
| 4 | 帰属意識を持ちにくい | 言い過ぎ | 営業時代の客先常駐と似ていて、慣れた |
| 5 | 多重請負構造で割を食う | 自分は当てはまらなかった | 直接の影響を強く感じる場面は少なかった |
| 6 | 評価されにくい | 自分は当てはまらなかった | プロパー上司との距離はあったが、致命的ではなかった |
| 7 | 年齢を重ねるとつらい | 自分は当てはまらなかった | 私自身が30代でのスタートだったが、入れた |
整理するとこうです。7つのうち、本当に同意できるのは2つ(給料・スキル偏り)/言い過ぎなのが1つ(帰属意識)/自分は当てはまらなかったのが4つ。だから「SES = 全否定」という二項対立はミスリードだと、私は感じています。
給料が上がりにくい(→ 本当、ただし出口次第)
これは率直に本当だと感じます。SES の最初の年は前職の営業時代とほぼ横並びで、SES に居続けた期間で大きく跳ねた、という感覚はありません。
ただし、これは「SES だから永遠に上がらない」という話ではなく、SES で土台を作って次に移った先で初めて明確に上向く、というのが私の実感に近い順序です。具体的な金額は本記事では伏せますが、営業時代と比べると年収は上がっている方向にあります(金額の具体は、年収単独の専門記事で改めて整理します)。
スキルが身につかない(→ 半分本当、現場による)
これも半分本当、つまり案件によって本当に変わる、というのが私の答えです。
私自身は運の要素も大きかったと感じていますが、SES 時代に Ruby による業務改善と、graphDB を使った人・モノを紐付ける基幹システム開発に携われたのは、技術的にはかなり恵まれた配属でした。その経験は今の自社開発でも、生成AI 関連の実装でも、明確に土台として効いています。
逆に、毎月同じ作業の繰り返しで新しいものに触れられない期間が続くと、技術成長が止まる感覚が出てきやすくなります。これは私自身も後半に少しずつ感じていたところで、後の章で正直に書きます。
案件選択権がない・多重請負・評価されにくい・年齢の壁(→ 私は当てはまらなかった)
この4つは、SERP 上位の記事ではよく強く書かれているのに、私の体験では強く感じなかった項目です。営業時代に「お客様の事情に振り回される」のが日常だった私の基準だと、SES の現場のほうがむしろ予測しやすかった、というのが正直なところ。
ただ、これは私が当てた現場が運良くそうだっただけ、という可能性も十分あります。同じ SES でも、現場・所属企業によって体験は全く違うはず。後の H2「面接前に確認しておきたかった4項目」で、入る前にチェックできるポイントを整理します。
帰属意識を持ちにくい(→ 言い過ぎ、というのが私の体感)
7つの中で唯一、私の実体験では誇張気味だったと感じるのがこの項目です。
営業時代の私は、商社の社員でありながら、毎日のように取引先のオフィスや工場を回って、相手の現場の空気を吸って働いていました。SES の常駐先での働き方は、それととてもよく似た構造でした。「自分はどっちの会社の人間か」という戸惑いは、営業時代に一度通過していたぶん、私にとっては想像より小さな違和感でした。
もちろん、初めて常駐先に出る方には大きな戸惑いがあるはずで、人によって体験は大きく違うと思います。私の場合は「言い過ぎ」だった、という個人の体感としてお読みください。
私が SES に 2.5年いて、本当にきつかったこと・本当に学べたこと——一次体験のリアル
📖 この章で使う用語
- graphDB(グラフ型データベース):人や物を「線でつなぐ」発想で情報を保存するデータベース。家系図や組織図のような関係性を素早く辿れる。
- プロパー社員:所属企業の社員のうち、現場に出ず本社で働く人。SES では「常駐側 vs プロパー」の区別がよく出てきます。
- 評価面談:給与・等級を決めるために行う、所属企業の上司との面談。SES の場合、常駐先での働きぶりが直接見えにくい構造的な課題があります。
ここは、私が SES に約2年半いて、現役視点から振り返って一番正直に書ける一章です。
きつかったこと——「成長の壁」と「周囲への引け目」の2軸
SES 後半に、私の中で少しずつ膨らんでいた感覚を2つに分けて書きます。
1つ目は、技術成長が止まる感覚です。 毎月、似たような作業の繰り返し。新しい技術に触れる機会が現場の中だけだと出てこない。勉強する時間を業務外に作ろうとしても、平日の終わりにはなかなか手が動かない——という、地味に効いてくる種類のつらさでした。営業時代の「同じトークで同じ商品を売り続ける感覚」と、構造がよく似ていたと、いま振り返って感じます。
2つ目は、自分の知識不足が、チームや案件の足を引っ張っているのではないか、という引け目です。 周りの先輩エンジニアが当たり前のように使っている技術概念を、自分は調べないと使えない。質問するのも申し訳ない、けれど黙って手が止まっているともっと迷惑、という板挟みの感覚。これは新人時代の営業で「商品知識が浅いまま客先に出てしまった」感覚に近かった。
このふたつが重なってくると、ぼんやりと「もっと色々な技術に触れてみたい」という気持ちが、自分の中に育ってきました。
学べたこと——Ruby・graphDB・「複数の組織を見られた」こと
ネガティブな面ばかり書くと不正確になるので、学べたことも同じ温度で書きます。
技術面では、Rubyで業務改善のコードを書く経験と、graphDBで人・モノを線でつなぐ基幹システムの開発に触れた経験が、いちばん大きな資産でした。これは、私が運良く当てた現場の特性が大きいと自覚しています。それでも、いま自社開発スタートアップで Scala / Python も含めて自社言語スタックから生成AI の API を呼ぶ実装ができているのは、SES 時代に「動いているシステムを読む筋肉」を鍛えられたからだと感じます。
技術以外で大きかったのは、所属企業 × 常駐先 × 自分のチームという3つの組織を同時に見られたことです。営業時代の私は、商社の中の自分と、取引先の現場の人たちと、自社の上司と、3者のあいだで動いていました。SES もちょうど同じ三角形で、ある意味で営業時代の延長線でした。この三角形を捌く対人耐性は、いまの自社開発の中でも、社内の営業・経営層・エンジニアの三角形でとても役に立っています。
次に向かう動機——「いろんな技術に触れたくて」転職した
ここはSERPの競合記事と一番違う、正直に書きたい一節です。
私が次の環境に移ったのは、「SES → 自社開発に移ろう」という意識ではありませんでした。動機としてはっきり覚えているのは、「いろんな技術に触れてみたかった」、ただそれだけです。「SES を脱出する」「やめる」という決別の気持ちは、自分の中ではほとんど主役ではなかったと振り返って感じます。
結果として向かった先がたまたま自社開発のスタートアップで、結果として Scala / Python / 生成AI API という新しい技術スタックに触れられました。脱出主導ではなく、好奇心(curiosity)主導。これが私の場合の事実順序です。
この順序の違いは、後の H2「2-3年で使い倒す設計図」と、最後の「今週やる3つ」にも繋がります。「やめる場所」ではなく、「次に何に触れたいか」を起点に動くと、SES の2-3年は意外なほど豊かな入口になり得ます。
SES に向いている人・向いていない人——営業/事務職から未経験で入る場合の判断軸
📖 この章で使う用語
- 腰掛け(こしかけ):長く居続けず、次のステップへの通過点として捉える働き方。営業時代の「最初の3年で型を覚える」感覚と同じ。
向き不向きを、SERP テンプレの一般論ではなく、営業/事務職からの未経験転職という視点で整理します。
向いている人
- 短期で IT に入る入口が欲しい人:2-3年の腰掛けと割り切れる人。「いったん入って、そこから動く」ことに抵抗がない方は、SES の入口の広さがとても有利に働きます。
- 多様な現場を見て、自分の専門を絞りたい人:1社の中だけだと見えない景色を、SES の複数現場で短期間に味わえる。営業時代の「複数業界の取引先を回って商機を見つける」と同じ動き方が好きな方は相性が良いです。
- 営業/接客出身で対人耐性が高い人:常駐先の社員・自社の営業・同僚エンジニアの三角形で揉まれる構造に、営業時代の対人スキルがそのまま生きます。私自身、これがいちばん効いた強みでした。
向いていない人
- 1社で長く・深く技術を伸ばしたい人:これは正直に書きます。最初から自社開発を目指せる学習・ポートフォリオがある方は、SES を経由しないルートのほうが結果的に近道です。
- 評価とキャリアの主導権を自分で握りたい人:SES は構造上、常駐先での働きぶりが評価面談に直接は届きにくい。「自分で書いた評価コメントを上司に渡す」くらいの自走力が求められます。
- 「優良 SES を引き当てる」ガチャに精神的に耐えられない人:これは現実問題として、現場ガチャの要素は確かにあります。ガチャを引く前提を受け入れられないなら、別の入口を検討するほうが向いていると感じます。
営業/事務職出身者への補足——前職の対人スキルは SES の現場でこそ生きる
ひとつ反転視点を置いておきます。営業や事務職で培った対人スキルは、SES の常駐先でこそ強い武器になります。
エンジニアの仕事は、画面と向き合うイメージが強いと思いますが、実際には要件ヒアリング・上司や顧客とのすり合わせ・議事録の整備・レビュー時の伝え方など、対人作業が想像以上に多い。営業時代に「相手の質問の半歩先を予測する癖」がついていると、要件定義の場面で「言われた通り作ったが、実は違う物だった」という事故が劇的に減ります。
商品知識がゼロからスタートした新人営業時代を経験している方は、未経験エンジニアとして現場に入る時の心理的なきつさを、一度通過したルートとして取り扱える強みもあります。「わからない状態に耐える筋肉」は、SES の最初の半年でいちばん効きます。
面接前に確認しておきたかった 4項目——営業時代の「相手の意図を引き出す」聞き方で踏み込む
📖 この章で使う用語
- プライム:H2「7つの理由」で説明済み。最終クライアントから直接受けている案件のこと。
- 2次受け/3次受け:プライム企業から下に再委託される段階。下に行くほどマージンが抜かれる。
- OJT(オン・ザ・ジョブ・トレーニング):実務をしながら教えてもらう研修形式。「習うより慣れろ」を制度化したもの。
これから SES に入る方、または SES から動きたい方に向けて、私自身が振り返って「面接前に確認しておきたかった」と感じる4項目を共有します。
「実際に面接で聞いた」「聞いておけばよかった」が混在しているので、過去の私が次の自分にバトンを渡すなら、最低限ここは確認しておきたいという温度で書きます。
1. 自社に戻る機会はあるか(社内研修・帰社日・自社プロダクト)
常駐先での働き方が中心になる SES では、所属企業との接点をどう保てるかが、後の評価・キャリア相談・技術相談の質を左右します。
確認したい具体は3つ:
- 社内研修の頻度と内容:月1回程度の勉強会や社内研修があるか、それは業務時間内か業務外か
- 帰社日の有無:週/月単位で所属企業に戻る日があるか
- 自社プロダクト・社内プロジェクトの有無:常駐案件の合間に自社で動かしているものに触れる機会があるか
営業時代の聞き方で言えば、「御社の社員さんが、所属する一体感をどう保たれているか、よろしければ最近の事例で教えていただけますか」——というふうに、相手の固有名詞で答えてもらうと、形だけの制度か実際に機能しているかが見えてきます。
2. 使用技術スタックの選択肢——言語固定か、案件次第か
ここを最初に聞いておかないと、後で「Java の現場以外には行けません」のような構造に巻き込まれることがあります。
具体的に聞きたいのは:
- 入社後に触れる可能性のある言語・技術領域を、領域名でいいので教えてもらえるか
- 言語固定の方針か、案件次第で複数言語を経験できる方針か
- 入社時の希望と異なる現場に配属される頻度
これは私自身が「いろんな技術に触れたい」という curiosity 主導で動く人間だったので、後から振り返って一番大事だったポイントです。
3. 教育体制・OJT の実態——「行ってみてのお楽しみ」を避けるための踏み込み
未経験で SES に入る場合、最初の数ヶ月の OJT が口頭で出てこない企業は要警戒です。
聞き方の例:
- 「入社後の最初の1〜3ヶ月、具体的にはどのような研修やフォローを受けられますか」
- 「OJT で実務に入る段階で、自社のメンターや先輩エンジニアに相談できる経路はありますか」
- 「未経験で入った直近3名の方が、最初の半年でどんな案件にアサインされたか、可能な範囲で教えていただけますか」
営業時代の感覚で言うと、「直近の事例を3つ教えてください」が一番強い質問です。制度の説明はカタログでも書けますが、直近3名の具体は、嘘がつけません。「行ってみてのお楽しみ」と濁す返答が出た時点で、辞退候補に下げて構わないと感じます。
4. 案件の交代頻度——どのくらいの周期で現場が変わるのか
意外と聞き漏らしやすいのが、案件の交代頻度です。
- 1案件あたりの平均的な在籍期間
- 案件の終わりが見えてきたとき、次の案件決定までの待機期間の目安
- 待機期間中の給与の出方(満額/一部/無給)
短いサイクルで多くの現場を見られるのが SES の強みでもありますが、極端に短い周期での交代が続くと、技術的に深堀りできないという別のつらさが出てきます。逆に1現場に5年居続けだと、SES の流動性メリットが失われ、自社開発に近いリスク(評価が遠い)だけが残る、という両極があります。
聞き方は、営業時代の癖で「ちなみに、御社の現場の交代頻度って、平均でどのくらいでしょうか」と、軽く・短く・固有数字を求める形にすると、相手も具体で返してくれやすいです。
SES を 2-3年で「使い倒す」設計図——入った後の最短ロードマップ
📖 この章で使う用語
- 出口戦略(でぐちせんりゃく):入る前から「次にどこへ移るか」の見取り図を持っておくこと。営業時代の「3年後にどの役職を狙うか逆算する」感覚と同じ。
- 技術スタック:使う言語・フレームワーク・ツールの組み合わせ。料理で言えば「メイン食材+調味料+調理器具」のセット構成。
SES に入ると決めたら、最初から 2-3 年の出口戦略を持って入る——私の場合は、これが結果的にいちばんラクでした。「SES がダメだから早く出る」ではなく、「この入口を最大限使い切るために、最初から地図を描く」という意味合いです。
月次・四半期の自己レビュー——「最小の一手」を書き残す
私の場合、振り返って効いたと感じるのは、月に1回だけでも、自分の技術成長を1行で書き残す習慣です。営業時代の「商談メモを翌朝までに残す」癖と同じ要領で、Markdown のメモに「今月触れた新しい技術/詰まったポイント/次の一手」を3行ずつ書く。
これだけで、半年後に振り返ったときに「この半年、自分は何に触れてきたか」が可視化されます。次の環境に動く時の自己 PR の素材としても、そのまま使えます。
業務外で AI スキルを積む——2026 年版の追加 TODO
2026年に SES で働き始める方には、業務時間外に生成AI ツールを触っておくと、私の場合は次の出口の解像度が一段上がりました。SES の現場で扱う技術は配属に依存する一方、業務外の AI 学習だけは自分で完全にコントロールできる領域だからです。
- ChatGPT を最初に触る:ChatGPT を最初に触る人向けに、こちらにまとめています。10分で動かす手順だけまずクリアしておくと、後の AI 学習のハードルが大きく下がります
- Claude Code を 30 分触る:Claude Code 使い方。SES の業務効率化(議事録整理・調査タスク)に直接効きます
- コーディング不要のAIエージェントを触る:Claude Cowork 使い方。事務寄りの SES 業務にも活路があります
これらはいきなり全部やる必要は全くありません。私の場合は、まず ChatGPT を仕事の調べ物に1回使ってみる、というところから始まりました。
「最初の2年で何を学べるか」で案件を選ぶ視点
SES の中で案件を選ぶ場面が訪れたら、**「年収」より「最初の2年で何を学べるか」**を判断軸に置くことを、私自身は強くおすすめします。
これは別記事の未経験エンジニア転職の地図と同じ思想ですが、SES の場合は特に当てはまります。入口の SES で年収を最大化しても、次の環境に移るときに評価される材料が薄いと、結果的に伸びにくい。逆に、技術スタックの広さ・実装経験の深さを 2年で蓄積できれば、次の環境(自社開発・社内SE・生成AIエンジニア)で年収も自然と上向きやすい、というのが私の実感です。
SES の出口は 3 方向——自社開発・社内 SE・生成AIエンジニア
📖 この章で使う用語
- 社内 SE:自社の業務システムを内製・保守するエンジニア。営業時代の「社内システム担当」と同じ立ち位置。
- 生成AIエンジニア:ChatGPT・Claude・Gemini などの API を使って、業務システムに AI 機能を組み込むエンジニア。
- RAG(検索拡張生成):AI が回答する前に、自社の資料を検索してから答えさせる仕組み。「カンペを持って商談に行く」イメージ。
- AIエージェント:人間が「ここまで」と頼むと、自分で道具を選んで作業してくれる AI。新人営業に「あとは任せた」と言うのと似ています。
SES の出口は、ざっくり3方向に整理できます。自社開発・社内SE・生成AIエンジニア——この3つを順番に。
| 出口 | 学習コスト | 年収レンジの方向感 | 私の体感 |
|---|---|---|---|
| 自社開発 | やや高い | 上向き方向 | 私が結果的に選んだルート |
| 社内 SE | 中程度 | 安定方向 | 営業/事務出身者と相性が良い |
| 生成AIエンジニア | 上乗せ型 | 2026年は上向き | 私が今いるレイヤー |
📌 YMYL 配慮の注記 上記の年収レンジは「方向感」のみを記しています。具体的な数値・パーセンテージは、業界・地域・経験年数で大きく変動するため、本記事では出していません。具体的な数字は厚生労働省や doda の公式調査で、地域・職種別の最新値を事前にご確認ください。
自社開発——1社の中で深く伸ばしたい人、私が選んだルート
私自身が SES の次に選んだのは、自社開発スタートアップでした。冒頭でも書いた通り、これは「自社開発に移ろう」という強い意志があったのではなく、「いろんな技術に触れたくて」動いたら、結果として向かった先が自社開発だった、という事実順序です。
自社開発の魅力は、自社プロダクトの全工程に近い距離で関われること。要件定義から実装、運用、改善のループに、1人のエンジニアとして名前で関われる構造になります。SES で複数現場を見てきた経験は、自社開発で1つのプロダクトを深掘りするときに、「他社ではこういう作り方をしていた」という比較軸として、想像より強く効きます。
社内 SE——業務知識を活かして安定したい人、営業/事務出身者には親和性高い
社内 SE は、自社の業務システムを内製・保守する立場です。営業や事務職の出身者が、業務知識を武器に戻ってくる出口として、相性がとても良いポジションです。
「社内便利屋」と揶揄されがちですが、2026年に入って社内の AI 活用推進を担うポジションとして、社内SE の評価は明確に上向いてきています。営業時代に「業務のどこが詰まっているか」を肌感覚で知っている方が、社内 SE として AI を組み込む側に回るのは、実は強力なキャリアパスだと感じます。
⭐ 生成AIエンジニア(2026年の新しい出口)——SES 経験がここで効く
3つ目は、私自身が今いる出口です。生成AIエンジニア——ChatGPT・Claude・Gemini などの API を業務システムに組み込み、RAG や AIエージェントを設計・実装する仕事。
SES 経験がこのレイヤーで効く理由は、いくつかあります。
1. 既存システム(負債を抱えたコード)に触れる経験。 SES で複数の現場の既存システムを見てきた経験は、「綺麗な環境」だけ知っているエンジニアには出せない強さになります。生成AI を業務システムに組み込む案件は、既に動いている古いコードベースに後から組み込むものが多く、ここで SES 経験が直接効きます。
2. 「動かないシステム」と向き合う耐性。 本番障害・運用の現実に SES 時代に何度も触れた経験は、AI の予期しない振る舞い(ハルシネーション・API のレートリミット・コスト爆発)に対峙するときの、心理的耐性そのものになります。
3. 調整力・コミュニケーション力。 常駐先の社員・自社の営業・同僚エンジニアの三角形で揉まれた経験は、生成AI の実装フェーズで頻発する「この業務、AI で本当に置き換えていいんですか」というステークホルダー間の議論で、想像以上に役に立ちます。
4. 複数の業界・現場を短期間に見られた経験。 1社にいるだけでは見えない景色を SES で取り込めたぶん、業務理解の引き出しが広い。生成AI を「実業務にどう組み込むか」を考える場面では、業務理解の幅がそのまま実装提案の幅になります。
具体的に何を学ぶかは、別記事を順番に読んでいただくのが解像度が上がりやすいです。
私の3段階キャリア(営業 → SES → 自社開発 → 生成AIエンジニア)は、振り返ってみるとどの段階も次の段階の準備期間になっていた、という整理ができます。SES の2-3年は、捨て駒ではなく、次の出口の燃料——というのが私の正直な感覚です。
営業/事務職から未経験で IT に入る人へ——SES を「使い倒す」 3 つのコツ
📖 この章で使う用語
- 要件ヒアリング:システムを作る前に「お客様(依頼者)が何を望んでいるか」を引き出す対話。営業時代の「商談での課題ヒアリング」と全く同じ作業。
- 議事録:会議の記録。「誰が」「何を」「いつまでに」決めたかを残す書類。
ここは、いま営業・事務職・銀行員などで働いていて、SES を入口として検討中の方に向けた、前職別の翻訳ガイドです。bon-bon-tools の主たる読者層に合わせて、私が一次体験から責任を持って書ける範囲だけで並べます。
営業出身の方——顧客折衝の経験を「要件ヒアリング」に翻訳する
これは私自身の体験そのものなので、確信を持って書けます。
営業時代の私は、お客様の口から出てくる「こうしてほしい」の言葉の裏にある「本当に困っているのは何か」を読み取る訓練を、毎日約60件の訪問で積んでいました。SES の現場でこの癖が直接効いたのは、graphDB を使った基幹システムの要件ヒアリングの場面でした。
業務担当の方が「この画面にボタンを追加してほしい」と仰ったとき、営業時代の癖で「そのボタンを押した後、最終的にどの帳票に反映されるのが理想ですか」と一段奥を聞く。すると、本当に困っていたのは別の場所だった、というのがよくありました。営業時代の「相手の質問の半歩先を予測する」癖は、要件定義の場面で事故の確率を劇的に下げる武器になります。
事務職の方——ドキュメント整備の経験を「議事録・仕様書」に翻訳する
事務職で培われている書類整備の正確さは、SES の現場で議事録・仕様書の質に直結します。
エンジニアの議事録は、「誰が」「何を」「いつまでに」決めたかが後から1ヶ月後に読み返しても辿れる精度が要求されます。事務職で日常的にこの精度の書類を扱ってきた方は、入社初日からチームに貢献できる領域を最初から持っている、ということになります。これは未経験エンジニアにとって、想像以上に大きな強みです。
私は事務職の経験そのものはないので、これ以上の具体は書きません。ドキュメントの整備力が、要件定義・仕様書・議事録という形でそのまま市場価値になる、という方向感だけ、お伝えしておきたい。
銀行員の方——金融ドメイン知識は「金融系 SES → フィンテック」の最短ルート
銀行員出身の方には、金融ドメインの知識という強力な武器があります。金融系の SES 案件は、業界知識を持っている方の希少価値が高い領域で、業界知識のある未経験は、純粋未経験よりはるかに通りやすい構造があります。
私自身は金融業界の経験はないので、深いところまでは書けません。ただ、金融系 SES で 2-3年の業務を経たあと、フィンテック企業の自社開発に移るのは、近年明確に増えているパスです。詳しい全体地図は未経験エンジニア転職の地図。
3つのコツ(前職共通)
最後に、前職に関わらず使える3つのコツを置いておきます。
- 前職の強みを言語化する:「営業で◯◯ができる」「事務で◯◯ができる」を1行ずつ書き出す。これが SES 入社後、現場で自分の居場所を作る材料になります。
- 2 年の卒業期限を自分に課す:入る前から「2-3 年で次に動く」を、自分の内側で約束しておく。「いつまでも居続けない」前提は、毎月の学習の濃度を上げます。
- 業務外で AI を触る:これは前章でも書いた通り、SES 時代の唯一の「自分で完全にコントロールできる学習領域」です。ChatGPT・Claude Code のどちらかを、まず 30 分触ってみるところから。
次の一手——今週やる 3 つのこと
📖 この章で使う用語
- 最小の一手:完璧な計画より、まず今日できる小さな一歩。営業時代の「お客様にまずアポを1件入れる」のと同じ感覚。
最後に、本記事を読んでくださった方が、今週中に動ける具体3つを置いておきます。押し付けるつもりはなく、私の場合はこのくらいの粒度で動いて結果的にラクでした、という温度で書きます。
1. 自分が SES に入るなら、何年で何を学んで卒業するかを1ページ書き出す
A4 1枚で構いません。「何年で」「何の技術を」「どの次の出口に向けて」学ぶか、いまの自分の言葉で書き出してみてください。
完成度は要りません。1ヶ月後に書き直していい。書き出すという行為そのものが、SES の現場に入った後の毎日の判断軸を、半歩鋭くしてくれます。
2. 関連記事でロードマップを確認する
未経験エンジニア転職の地図で、SES を含む5職種の全体像、学習ロードマップ(スクール型・独学型)、ポートフォリオ、2026年版の AI 時代の差別化軸まで、一次体験を交えて並べています。本記事と合わせて読むと、「SES だけで判断するのではなく、IT 全体の地図の中で SES を位置付ける」視点が補強できます。
3. ChatGPT または Claude Code を 30 分触ってみる
これが、SES に入る前でも、入った後でも、明日からの解像度を一段上げてくれる最小の一手です。
「SES のあと、生成AIエンジニアという出口が本当にあるのか」を、自分の手で触って確かめてみる——これが、本記事の最後にお伝えしたい、いちばん大事な一手です。
よくある質問
Q1: SES に未経験で入っても本当に大丈夫ですか?
A. 「戦略のない未経験」で入ると地雷を踏む確率は高めです。逆に 2-3 年で何を学んで次にどこに移るかを最初から設計して入れば、IT 業界の現実的な入口になり得ます。私自身、営業 7年から未経験で SES に入り、2 年半で次の環境に移りました。
Q2: SES と派遣・自社開発の違いは何ですか?
A. SES は「準委任契約」で、指揮命令は SES 所属企業にあります。派遣は派遣先に指揮命令があり、自社開発は自社の社員が自社のプロダクトを作ります。一番大きいのは 誰があなたの仕事を評価するかの違いです。
Q3: SES でもスキルは身につきますか?
A. 現場による、というのが正直な答えです。私の場合、Ruby と graphDB を使った業務改善・基幹システム開発に携わり、その経験は今の自社開発でも生きています。逆に、毎月同じ作業の繰り返しで新しいものに触れられない期間が続くと、技術成長が止まる感覚が出てきます。
Q4: SES からどうやって抜け出せばいいですか?
A. 王道は 自社開発か社内 SE への転職です。2026 年は新しい選択肢として 生成AIエンジニアも出口になります。私は「いろんな技術に触れたくて」次の環境に転職し、結果として向かった先がたまたま自社開発でした。そこから現職で生成 AI 関連の実務(API 利用/RAG/AIエージェント/コーディングアシスタント)まで広がりました。
Q5: 営業出身でも SES でやっていけますか?
A. 営業 7年から SES に入った私の体感では、前職の対人スキルはむしろ強みになります。要件ヒアリング・上司や顧客とのすり合わせ・議事録の整備など、エンジニアの仕事は対人作業が想像以上に多いです。営業時代に「相手の意図を一歩先読みする」癖がついていると、レビューや要件定義の場面でとても役に立ちました。
関連記事
- エンジニア 転職 未経験——3 段階のキャリアパス整理
- ChatGPT 始め方——10 分で動かせる最短ルート
- Claude Code 始め方——初回 30 分のステップ
- LLM とは何か——日常のたとえで整理
- AIエージェントとは何か——日常のたとえで丸ごと整理しました
- Claude 使い方——3 兄弟整理を丸ごと
- RAG とは何か——日常のたとえで整理
- Cursor 使い方——非エンジニアでも触れる 30 分
- Claude Code 使い方——最初の 30 分から解説
- AI 業務効率化 ツール——7 種を目的×職種で整理しました
- AI 業務効率化 事例——5 領域×5 職種で整理しました
- AI コーディングとは何か——3 つのレイヤーで読み解く実務ガイド
- Claude Opus とは何か——4.5 / 4.6 / 4.7 とモデル使い分け整理
- AWS Bedrock とは何か——直 API との料金比較・Claude Code 連携・AgentCore まで整理
- AI コードレビューとは何か——プロンプト 5 型・主要 7 ツール・ローカル LLM まで丸ごと整理
- Claude Code Action とは——GitHub Actions に Claude Code を組み込む公式ハーネス
- Claude Opus と Sonnet の違い——3 モデル使い分けと 5 軸比較整理
- Dify 使い方——4 アプリタイプ俯瞰・初心者 5 ステップ・RAG 構築まで
- 生成AI 入門——5 ペルソナ別 30 日学習プランで通貫整理
- Claude Sonnet 4.6 とは——直 API / Bedrock / GitHub 統合の 3 経路と Opus / Codex 系比較を整理
- LLM ローカル——Apple Silicon Mac で Ollama を動かす個人検証視点の整理
- Claude Skills とは何か——SKILL.md / 自作 3 系統 / Slash commands・MCP・Tools との違いを整理
- Azure OpenAI Service とは何か——GPT/Codex モデル一覧・料金・直 API/AWS Bedrock 3 経路使い分け・「Azure に Claude はない」誤解まで整理
- AIエージェント × MCP——標準仕様の手と目を増やす設計(自作 MCP サーバー本番運用者が整理)
- Claude Skills を自作する——SKILL.md の書き方から業務 3 系統・チーム配布まで「作る側」を実演
- Vibe coding とは——感覚で AI に書かせ、人間はレビューと方向づけに回る新スタイルを業務実践視点で整理
- Codex CLI とは——OpenAI 系の Claude Code 相当を、両方触った現役の生成AIエンジニアが比較しながら整理しました
- Vertex AI とは——Google Cloud の AI 基盤。Gemini と Claude on Vertex の二本柱・料金・3 基盤比較を業務試用視点で整理
- MCP サーバー 作り方——Python/TypeScript SDK で自作し本番運用まで「作る側」の完全マニュアル
- Gemini CLI 使い方——Google のターミナル型 AI コーディングを 3 ツール比較で整理
- Gemini API 使い方——コードから Gemini を呼ぶ最小サンプルを Python・GAS で
出典
- 厚生労働省 — 賃金構造基本統計調査(e-Stat 政府統計の総合窓口)(取得:2026-05-15)
- doda — 平均年収ランキング(取得:2026-05-15)
- 厚生労働省 — 職業情報提供サイト(job tag)(取得:2026-05-15)
- STUDYing — 「SES やめとけ」と言われる理由(参考:SERP 上位の代表的言説の整理に利用)(取得:2026-05-15)
- MASTER key Media — SES で働くことを勧めない理由(参考:SERP 上位の代表的言説の整理に利用)(取得:2026-05-15)
本記事は筆者個人の業務経験と公的・業界データをもとに書いています。年収・転職率・市場動向などのデータは時点により変動するため、最新情報は各出典の公式サイトで事前にご確認ください。本記事は特定の転職成果を保証するものではなく、個人の体験を一般化したものでもありません。誤りや出典の補足のご指摘は send@bon-bon-tools.com までご連絡ください。
訂正履歴
- 2026-05-15:初版執筆(draft)