SESで開発経験が積めない？現場変更・社内異動・転職の選び方

※本サイトはアフィリエイト広告（Amazonアソシエイト含む）を掲載しています。

「開発がしたくて入ったのに、今日もテスト結果のスクリーンショットを貼っている」

SESで働いていて、そんな気分になることはありませんか。

テストも運用も必要な仕事です。ただ、自分はコードを書きたい。なのに来月の予定を見ても担当は変わらない。営業に相談すると「次の案件では考えます」と言われる。

その「次」、いつ来るんでしょうね……。

正直なところ、今の現場で開発経験が積めないからといって、すぐ退職する必要はありません。 でも、何が変わるのか分からないまま待ち続けるのも、ちょっと違うと思います。

わたしなら、まず次の4つを並べます。

今の現場で担当を広げる
同じ会社に在籍したまま、別の現場へ移る
自社の開発部門などへ社内異動する
開発を担当できる会社へ転職する

比べる軸は、半年後に、職務経歴書へどんな仕事を一つ書き足せそうか。

この記事では「半年」「2週間」「1か月」といった期間も例として使いますが、全員に共通する期限ではありません。今の案件や会社の状況に合わせて、何をいつ確認するかを決めるための目安として考えてください。

まず「開発経験がない」の中身を確認する

最初に、今の仕事を少し分解してみてください。

「運用保守」と呼ばれていても、既存プログラムを修正してテストまで担当しているなら、その改修は説明できる経験です。一方、開発プロジェクトに所属していても、担当が手順どおりのテスト実施だけなら、実装を担当したとは書けません。

案件名と、自分がやった仕事。ここは分けておきたいです。

今の担当	すでに説明できること	次に相談する仕事の例
手順どおりのテスト実施	動作確認、不具合の再現・報告	不具合の原因調査、許可された範囲での修正と再テスト
テスト設計	仕様の読み取り、確認項目の設計	自動テストの実装、修正内容に合わせたテスト追加
監視・定型運用	異常の検知、手順に沿った対応	ログ調査、運用スクリプトの改修
問い合わせ対応	状況整理、再現条件の確認	原因箇所の調査、軽微な不具合修正
軽微な改修	既存コードの読解、修正、動作確認	影響範囲の調査、設計、レビューへの参加

右の列は例で、現場や権限、支援できる人がいるかによって任せてもらえる範囲は変わります。

また、自動テストや運用スクリプトを書いた経験と、Webサービスの機能開発経験も同じではありません。何のコードを、どこまで自分で書いたかを説明できるようにしておく必要があります。

今の経験を整理してみて、「開発だけでなく、利用者対応や改善も続けたいかも」と思うこともあります。進みたい方向がまだ曖昧なら、社内SEと自社開発、SES経験者はどっちが向いてる？で仕事内容や働き方の違いも整理しています。

今の現場に残る？環境を変える？判断フロー

ここでは、開発を担当したい気持ちがある前提で考えます。

Q1. 今の現場に、自分が参加できる改修・実装の仕事がある？

ある → Q2へ
ない／自分の担当範囲では参加できない → Q3へ

Q2. 何を・いつから・誰の支援で担当するか相談できている？

具体的に相談できている → 今の現場に残り、担当開始の見込みを確認
「そのうち」までしか決まっていない → Q3の選択肢も並行して確認

Q3. 自社に、開発を担当できそうな別案件や部署がある？

別の客先案件がある → 現場変更を相談
自社の開発部門や受託チームがある → 社内異動の条件を確認
どちらもない／具体的な候補が出ない → 転職先の情報収集を始める

Q4. 候補先で、自分に任せる仕事と支援体制を確認できた？

確認できた → 今の環境と仕事内容・待遇・開始時期を比較
確認できない → 「開発案件」という名前だけで決めず、追加で聞く

現場変更と転職活動は並行しても構いません。社内の返事を待つ間に求人を見るだけでも、比較する材料は増えます。

4つの選択肢を「半年後に増える経験」で比べる

選択肢	選びやすい状況	半年後に増やしたい経験の例
今の現場に残る	小規模改修などに参加する見込みがある	既存コードの修正からテストまで
現場変更	自社が持つ別案件に開発の仕事がある	チーム内での実装とレビュー対応
社内異動	自社に開発部門があり、受け入れ余地がある	自社サービスや受託案件の実装
転職	社内で実現する見込みが薄い	応募先で合意した開発業務

特に気をつけたいのは、案件全体では開発していても、自分の担当がテストだけというズレです。

プロジェクトにコードがあることと、自分がコードを書くことは別です。

今の現場に残るなら、小さく任せてもらえる仕事を探す

今のシステムに詳しく、相談できる開発者もいるなら、その環境を使って担当を広げる方法があります。

たとえば、不具合の再現を担当したあとに、原因調査や小さな修正まで参加できないか相談する。運用中の処理に詳しいなら、スクリプトの改修を提案してみる。

最初から新機能を丸ごと任せてもらう必要はありません。ただし、コードや本番環境を勝手に変更するのは別の話なので、担当範囲・作業時間・確認してくれる人は先にすり合わせます。

残る根拠になるのは「今の仕事に慣れている」ことより、次に任せてもらえる仕事が具体的に見えていることです。

現場変更なら、案件名より自分の担当工程を聞く

会社そのものに大きな不満がなく、別案件なら開発できそうな場合は、まず現場変更を相談する方法があります。

ここで「Javaの案件に行きたいです」だけだと、希望がまだ広いです。Javaを使うシステムのテスト担当も、その説明に入ってしまうかもしれません。

「Javaの既存コードを修正し、レビューを受けながら実装と単体テストを担当したい」まで伝えると、営業側も候補を確認しやすくなります。

そして候補が出たら、案件側が求めている経験や担当工程も営業に確認します。

自分がまだ持っていない経験が必須なら、その差を先に把握しておく。逆に、今の経験でも参画できて実装へ広げられる案件なら、現場変更という選択がかなり具体的になります。

社内異動なら、制度と受け入れ先を別々に確認する

自社に受託開発チームやサービス開発部門があるなら、社内異動も候補です。

ただ、「異動制度があります」と「今、受け入れる部署があります」は別なので、募集枠の有無は直接確認します。

さらに、配属先の部署名だけ確認して終わらず、実際の日々の担当まで聞いておきたいです。

自社に戻っても、問い合わせ対応や調整が中心なら、実装したいという希望とは合わないかもしれません。

転職なら、同じ悩みを持ち越さない質問をする

社内に開発案件がない。異動先もない。相談を重ねても具体的な候補が出ない。

そういう場合は、転職先を調べながら比較するほうが話を進めやすいです。

ただ、「開発経験を積める会社ですか？」だけでは回答もふわっとしがちなので、面接ではもう少し具体的に聞きます。

入社後、最初に担当する仕事は何を想定していますか？
テストや運用から始める場合、実装を担当するための条件は何ですか？
わたしと近い経験で入社した人は、その後どんな業務を担当していますか？
コードレビューは誰が担当し、詰まったときは誰に相談できますか？
想定する開発案件がなくなった場合、配属はどうなりますか？

似た経歴の人が開発へ移った実績があっても、今回の自分の配属まで決まるわけではありません。その事例と、今回の募集で任せたい仕事がつながっているかを確認します。

仕事内容以外にも、給与・通勤・残業・勤務時間外の対応は比べておきたいです。開発へ移れても、別の部分で無理が出るなら、転職前に知っておいたほうが楽です。

そもそも変えたいのが仕事内容なのか、会社なのか、客先常駐そのものなのか迷うなら、SESを辞めたいけど転職すべき？まず整理したい3つのことから考えると、応募先も絞りやすくなります。

会社の外を見るなら、転職だけでなくフリーランスという選択肢もあります。SESからフリーランスになる前に確認したいことで、案件・税金・社会保険まで一度並べてみてください。

営業への相談は「希望・根拠・確認日」をセットにする

「開発がしたいです」と伝えたあと、何も進まない。

そんなときは、相談内容をもう少し具体的にしてみます。

たとえば、テスト中心の担当から開発へ移りたい場合なら、こんな伝え方ができます。自分の実際の経験に置き換えて使ってください。

今はテスト実施と不具合報告が中心ですが、今後は既存コードの修正から、実装と単体テストを担当したいと考えています。

現案件では、仕様を確認しながら不具合を再現するところまで担当しています。実装経験はまだないので、レビューや相談ができる体制のある案件を希望しています。

現場内で担当を広げる方法と、別案件へ移る方法の両方について、候補や必要な準備を教えてもらえますか。まず2週間後を目安に、確認状況を相談したいです。

聞いたあとは、候補や追加で必要な経験をメモしておきます。

返事が「まだ未定」でも、何を確認中なのか分かれば次の話ができます。逆に、毎回同じ説明で候補も出てこないなら、それも判断材料です。

「検討します」だけでは、職務経歴書の行は増えないんですよね……。

半年後に増える経験を、1行で書いてみる

選択肢を調べたら、それぞれについて次の空欄を埋めてみてください。

半年後には、【対象のシステムや機能】について、【使う技術】で、【自分が担当する工程】を経験し、【確認・レビューの方法】まで説明できるようになりたい。

たとえば、

社内申請システムの入力チェックをJavaで修正し、単体テストを追加して、先輩のレビューを受けながら修正理由を説明できるようになりたい。

こんな形です。

確認項目	書き込む内容	空欄だったら聞くこと
対象	何のシステム・機能に触るか	最初に担当しそうな仕事は？
工程	調査、設計、実装、テストなど	自分が手を動かす範囲は？
技術	実際に使う言語・DB・ツール	自分の担当で使う技術は？
支援	レビュー担当、相談先	誰がコードや進め方を確認する？
時期	開始見込み	何が決まれば担当できる？
説明材料	変更理由、自分の判断、確認した結果	経験をどう振り返れる？

個人的には、期待で埋めた欄と、相手に確認して埋めた欄を混ぜないほうがいいと思っています。

「たぶん任せてもらえる」は未確認として残しておく。この区別をしておくと、あとで選択肢を見返したときにも判断しやすいです。

待つ期間は「次に何を確認するか」で区切る

「あと何か月いたら転職すべきですか？」

ここは、全員共通の数字を出しにくいところです。今の経験、案件の区切り、社内の受け入れ状況が違います。

代わりに、行動の区切りを決めます。

今週： 現在の担当と、増やしたい経験を1行で書く
相談時： 現場内の担当変更・別案件・社内異動の候補を聞く
次の確認日： 候補と開始見込みが出たか確認。出ていなければ求人比較も進める
担当開始後： 実際に任された仕事が希望と合っているか振り返る

たとえば1か月後に振り返るとしても、「まだ異動できていない」という一点だけで判断する必要はありません。具体的な候補や受け入れ条件が見えてきたかを確認します。

体調や生活に支障が出ている場合は、こうしたスケジュールとは別に、まず負担を減らす相談を優先してください。

また、転職活動を始めることと退職を決めることも別です。働きながら候補を比較し、仕事内容や条件を確認してから判断する進め方もあります。

個人開発をするなら、次の仕事に近いものを一つ作る

現場の調整を待つ間に、コードを書く材料を作る方法もあります。

個人開発は、求人にある「実務経験○年」をそのまま置き換えるものではありません。ただ、自分でコードを書き、なぜその作りにしたのか説明する材料にはできます。

たとえば、入力した情報を保存・表示・更新できる小さなアプリを一つ作る。入力ミスへの処理を入れ、テストを書き、Gitで変更を記録する。READMEには動かし方と設計理由を書く。

ここでは機能を増やし続けるより、一つ動くところまで完成させるほうを優先します。

自社開発への転職を具体的に考えているなら、SESから自社開発へ転職するには？経験別の準備ロードマップで、今の経験から何を補うかも整理しています。

フリーランスも候補に入れるなら、今の経験でどんな案件を選べそうかも先に見ておくと判断しやすいです。
フリーランス案件の選び方｜単価だけで決めないために見るポイント

まずは「次に担当したい仕事」を一つ決める

SESで開発経験が積めないとき、いきなり「残るか辞めるか」の二択にする必要はありません。

今の現場で小さく担当を広げられるのか。別案件や社内の部署に希望する仕事があるのか。それとも、会社の外まで見たほうが早いのか。

まずは、半年後に職務経歴書へ追加したい仕事を一つ決めて、その仕事をいつから、どの範囲で、誰の支援を受けながら担当できそうか確認してみてください。

候補が具体的なら、今の環境に残る材料になります。何度確認しても見通しが出ないなら、外の求人を調べる材料になります。

わたしなら、「既存コードを修正して、レビューを受ける」くらいまで小さくして相談します。

「なんとなく開発がしたい」より、次に欲しい経験が一つ見えているほうが、営業にも転職先にも話しやすくなると思います。