SESから転職するのは何年目？1年目・2年目・3年以上の判断表

年数は入口の目安。転職時期は「責任の差分」で決める

経験年数は採用側が最初に見る目安の一つですが、年数だけでは任せられる範囲が分かりません。案件ごとに、何を調べ、どこまで判断し、誰と合意し、どの状態まで責任を持ったかを出してください。実装1年でも影響調査とテスト設計を持っている場合と、実装3年でも指示された差分だけを直している場合では、次に狙える役割が変わります。

厚生労働省job tagの受託開発SEは、顧客ヒアリング、要件定義、基本・詳細設計、実装の工程確認、各種テスト、運用後の問題解決などを職務として示しています。これは全工程の経験を応募条件にするものではありません。自分がその流れのどこを担当し、前後の工程へどんな情報を渡したかを特定するために使います。

IPAのデジタルスキル標準も、ソフトウェアエンジニアを技術名だけでなく、顧客・利用者への価値や他の関係者との連携を含む役割として整理しています。そこで「Javaを2年」だけでなく、「誰のどんな問題を、何を判断して、どの品質まで届けたか」を一文にします。AIツールの利用経験も、許可、入力制限、人による検証、採用判断まで説明できなければ責任の証拠にはしません。

判断表には「今できること」「次に持ちたい責任」「現職で持てる期限」「期限までに確認する証拠」の四列を作ります。現職で設計レビューへ参加できる具体的な予定があるなら待つ価値があります。時期も担当機能も決まらず「そのうち上流へ」と言われるだけなら、外の求人を確認する理由になります。

転職活動を始めることと、退職を決めることは別です。求人票と面談を使って現在地を確認し、現職へ残る条件も更新できます。応募数ではなく、今の経験がどの責任として評価されるかを知ることが最初の目的です。

• 案件の目的と利用者を一文で説明できる
• 担当工程の入口・自分の判断・出口を分けた
• 説明できる改善・品質上の工夫がある
• 次に増やしたい責任を一つに絞れている
• 現職で変わらない場合に市場確認する日を決めた

1年未満は、短期離職より「同じ問題を選ばない準備」を優先する

1年未満でも、心身の安全が損なわれている、説明された雇用条件と実態が大きく違う、IT経験として説明しにくい業務へ長期間固定されている場合は、年数を稼ぐことより安全と環境変更を優先します。無理に在籍期間を延ばすこと自体を目的にしないでください。

問題を「客先だけ」「所属会社の制度」「仕事内容」「心身・安全」へ分けます。客先だけなら現場変更で解決する可能性があります。所属会社が配属説明や労働条件を守らず、相談後も是正期限を示さないなら会社変更を比較します。体調や安全に関わる時は、転職サービスより医療・公的相談・身近な支援を先に使い、証拠づくりのために無理を続けないでください。

緊急性がない場合は、次の職場で同じ配属を避けるための材料を作ります。担当した業務、学んだ技術、質問して解決したこと、手順を改善したことを週単位で残します。「何もさせてもらえなかった」だけでは次の採用側が判断できないため、制約の中で試した行動と、その結果も書きます。

相談先によっては実務経験の下限が設けられています。比較中のサービスにも実務経験2年以上を主対象とするものがあるため、条件外へ無理に登録させません。第二新卒枠、研修と配属の透明性がある企業、現在の経験を継続できる職種を確認し、90日後に増やす証拠を決める方が選択肢を作りやすくなります。

短期離職の説明は会社批判で終わらせず、「入社前に確認した条件」「実際の配属」「会社へ相談した行動」「残った制約」「次の求人で確認する項目」の順にします。顧客名や非公開資料を持ち出さず、自分が経験した事実だけを残してください。

• 安全や雇用条件に関わる問題は年数より先に対応する
• 現場変更で解決する問題と会社変更が必要な問題を分ける
• 顧客資料を持ち出さず、自分の行動だけを記録する
• 次の求人で配属・研修・担当工程の決め方を質問する
• 対象条件外のサービスへ申込まない

1〜2年目は、一つの工程を「入口・判断・出口」で説明する

1〜2年目は、技術を広く並べるより、一つの工程を最初から最後まで説明できる方が強みになります。テストなら、仕様の読み方、観点の作り方、不具合を切り分けたログ、再発防止まで。運用なら、監視通知の意味、一次切り分け、エスカレーション、手順改善までをつなげます。

「開発をしていないから転職できない」と決めつける必要はありません。品質、影響範囲、利用者対応、障害対応は開発先でも必要です。ただし、作業件数だけでは再現性が伝わらないため、自分が判断した境界と、判断できなかった時に誰へ何を確認したかを残します。

厚生労働省のマイジョブ・カードは、在職者にも職務経歴、能力、学習歴、今後のキャリアプランを順に整理する方法を案内しています。案件ごとに「期間・目的・体制・工程・技術」だけでなく、「任された条件・調べた情報・自分の判断・確認者・結果・次の改善」を一行ずつ足します。資格や学習は、実務でどの判断へ使ったかを分けて書きます。

現職へ残るなら、次の90日で増やす責任を一つだけ合意します。たとえば詳細設計の一部、レビュー前のセルフチェック、障害原因の仮説作成です。「いつか」ではなく対象機能、開始日、確認者、完了と見なす成果物を決めます。90日後も担当範囲が変わらず、変更予定も具体化しない場合は、市場確認へ進む判断材料になります。

• 入口: 仕様・ログ・データのどれを受け取ったか
• 判断: 自分で決めたことと、確認を依頼したこと
• 出口: 成果物・テスト・本番確認をどこまで持ったか
• 改善: 品質や手戻りを減らすために追加した観点
• 期限: 次の90日で持つ工程・成果物・確認者

2〜3年目は、同じ経歴を渡して市場の見方を比較する

2〜3年目になると、単純なポテンシャルだけでなく、実務で任せられる範囲を説明しやすくなります。この段階で重要なのは、最初に提示された求人へすぐ応募することではなく、同じ経歴を複数の相談先へ渡し、どの経験が評価され、どこが不足と見られるかを比較することです。

職務経歴は「Java2年」のような技術と年数だけで終わらせません。「既存仕様とログから影響範囲を整理し、改修・異常系テスト・本番確認まで担当」のように、責任の流れを一文にします。次は基本設計、レビュー、リリース後の改善など、増やしたい責任を一つ続けます。

相談先には「今紹介できる求人名」より先に、現在のどの経験を評価したか、足りない責任は何か、求人の配属と担当工程を何で確認したかを聞きます。同じ経歴へ違う評価が返れば理由を比較できます。一社の担当者が言う市場価値や年収例を、確定した採用条件として扱わないでください。

転職支援には、年齢・実務経験・勤務地の主な対象条件があります。条件へ合う場合だけ候補を確認し、職務要約と質問を同じにして比較してください。対象条件へ合わない場合は登録数を増やさず、職務経歴書と次の経験づくりへ戻します。相談は応募への同意ではなく、応募先は求人ごとに自分で決めます。

• 同じ職務要約と希望条件を複数の相談先へ渡す
• 評価された経験と不足する責任を一社ずつ記録する
• 対象年齢・実務経験・勤務地を申込前に確認する
• 紹介理由を自分の経験と結びつけて聞く
• 応募前に配属・担当工程・レビュー責任を確認する

3年以上は「長くいたこと」より責任が増えた履歴を示す

3年以上在籍していても、毎年同じ定型作業を繰り返しているなら、年数と市場価値が同じ速度で増えるとは限りません。1年目にできなかった判断が2年目に何へ変わり、3年目に誰を支援できるようになったかを並べます。責任の変化が出ない場合は、次の案件や会社で何を変えるかを先に決めます。

後輩支援や顧客調整も、回数だけでなく仕組みとして説明します。質問を分類して資料へ戻した、レビュー観点を共有した、仕様差分を関係者へ確認して決定ログを残した、といった行動は設計・品質・チーム貢献へつながります。管理職志向でなくても、周囲が再利用できる形を作った経験は評価材料になります。

年収を上げたい場合も、希望額だけを先に置かず、次の会社が高く評価する責任を確認します。給与提示には会社、地域、職種、技術、役割など複数の要因が関わるため、一例の年収アップ額を自分へそのまま当てはめないでください。基本給、賞与、固定残業、手当、評価日と昇給条件を分けて比べます。

3年を過ぎたら自動的に転職するのでも、長期在籍を失敗と考えるのでもありません。現職で責任・処遇・働き方のどれがいつ変わるかを確認し、外の求人より良いなら残る選択もあります。比較表に現職を必ず一列入れ、口頭の期待ではなく担当者・日付・成果物・評価条件がある約束だけを材料にします。

• 年ごとに増えた判断・責任・支援範囲を並べた
• 定型作業を仕組み化した証拠がある
• 希望年収と、その根拠になる役割を分けて説明できる
• 現職・案件変更・転職を同じ条件で比べた
• 現職に残る場合も次の担当変更日・評価日を決めた

転職先は会社の名前ではなく、次に持てる責任で比べる

自社開発、受託開発、SIer、社内SE、別のSES企業には、それぞれ役割の違う求人があります。「自社開発なら成長できる」「SESを出れば年収が上がる」と会社分類だけで判断すると、入社後に想定外の定型作業へ固定される可能性があります。

job tagでも受託開発SEは顧客業務の把握から設計・テスト・保守まで、Webサービス開発SEは利用者へ提供するサービスの企画・設計・開発・運用まで、仕事の流れが異なります。ただし同じ職業名でも会社・配属で範囲は変わります。職種名を見て決めず、その求人で自分が最初に担当する工程と成果物を確認します。

求人では、入社半年の担当工程、仕様を決める人、レビュー基準、障害時の責任分界、利用者の声を開発へ戻す方法を確認します。現在の経験から一段だけ責任が増える求人は説明しやすく、入社後の期待値も合わせやすくなります。いきなり職種を大きく変える場合は、不足経験と学習・支援体制を具体化してください。

募集時には、業務内容と就業場所に加え、それぞれの変更の範囲など明示が必要な項目があります。求人票の「開発業務」だけでなく、入社直後の業務、将来変更される可能性がある業務、就業場所、客先常駐・転勤・リモートの扱いを確認し、面談で変わった条件は書面で受け取ります。

面談で「何でも挑戦できます」と言われたら、直近に同じ経歴で入社した人が最初の90日で何を担当したかを聞きます。さらに厚生労働省のしょくばらぼで、企業が掲載している残業時間、有給休暇、平均勤続年数、採用状況などを確認します。未掲載や更新日の古い項目は推測で埋めず、企業へ質問してください。

• 入社90日・半年で持つ工程と成果物
• 仕様・設計・レビューを決める人
• 業務と就業場所の変更範囲
• 配属変更が起きる条件と希望の伝え方
• 研修後に担当する実務と支援者
• 残業・有休・勤続・採用状況の確認先
• リリース後の運用・改善への関与

30・60・90日で準備、市場確認、応募判断を分ける

最初の30日で、案件の目的、担当工程、受け取った情報、自分の判断、確認者、成果物、改善、次に持ちたい責任を一枚へまとめます。最初から完成した職務経歴書でなくて構いません。守秘義務と公開範囲を確認し、客先名・利用者情報・非公開の構成や数字を持ち出さず、自分の担当事実だけを一般化します。

31〜60日で、現職の上司・営業へ次の責任と期限を確認し、対象条件に合う場合だけ外部の求人・相談先も確認します。同じ職務要約、希望する責任、避けたい条件、給与内訳の質問を渡し、返答を比較表へ置きます。理由が説明されない大量応募、対象条件外の提案、希望と違う工程が続く場合は、その相談先を使わない判断も必要です。

61〜90日で「現職に残る」「現場を変える」「転職する」の三列を更新します。担当工程、レビュー責任、利用者との距離、勤務地、残業・当番、給与内訳、評価日、変更範囲を同じ順で比べます。転職先は内定の言葉だけでなく、求人票と交付された労働条件を読み、面談中の説明との差分を質問します。

応募、内定承諾、退職は一つのボタンではありません。求人を確認しても現職が良ければ残れます。応募しても労働条件が合わなければ断れます。退職日を先に決めて比較を急がず、生活費、引き継ぎ、入社可能日も含めて最終判断してください。90日を待てない安全上の問題は、この手順より公的相談と避難を優先します。

• 30日: 案件の目的・工程・判断・成果物を一枚にする
• 60日: 現職と外部へ同じ責任・条件を質問する
• 90日: 現職・現場変更・転職を同じ八項目で比較する
• 求人票と書面の労働条件の差分を確認する
• 応募しない条件・内定を断る条件も先に決める
• 退職は応募・相談と分け、生活と引き継ぎも確認する

職務経歴書の変換例

年数と技術名だけでなく、現在持てる責任、判断の証拠、再現できる改善、次に増やしたい責任、求人で確認する条件まで一続きにします。

行動前チェックリスト

• 経験年数ではなく工程の入口・判断・出口を説明できる
• 心身・安全、現場、所属会社、仕事内容の問題を分けた
• 現職で責任が増える対象・担当者・期限を決めた
• 顧客資料を持ち出さず実績を一般化した
• 次に持ちたい責任を一つに絞った
• 対象条件に合う相談先だけを確認する
• 業務と就業場所の変更範囲を確認した
• 職場情報と労働条件を求人ごとに確認した
• 応募・内定承諾・退職を別々に判断した