SESから自社開発に転職できない本当の理由。足りないのは経験年数ではなく判断の記録
「SES 自社開発 転職」で出てくるのは転職エージェントの「難しい理由10選」ばかりで、常駐で3年やってきた人が次に何をすればいいのかは書いてありません。自社開発企業の選考が実際に見ているものと、常駐先の仕事ではそれが職歴に残らない構造を整理しました。
目次
「SES 自社開発 転職」で検索すると、同じ構成の記事が並びます。難しい理由が5つか10個挙がっていて、最後に「まずは複数のエージェントに登録しましょう」で終わる。書いているのが転職エージェントなので、そうなります。
困るのは、挙がっている理由が自分では動かせないものばかりだという点です。「自社開発は即戦力を求めている」「上流の経験が積めない案件が多い」——どれも事実ですが、常駐先の案件を自分で選べない立場の人が読んでも、明日やることが1つも増えません。
この記事は、常駐や受託で実務経験はあるのに自社開発企業の選考で止まる人に向けて、落ちている原因がどこにあるのかだけを書きます。スキル不足で片付けると、だいたい対策を間違えます。
「技術力不足で落ちた」と思っているケースの大半は、説明材料の不足
選考に落ちた理由は、ほぼ教えてもらえません。そこで人は「技術力が足りなかった」と解釈して、新しい言語やフレームワークの学習を始めます。これが一番多い遠回りです。
自社開発企業が中途採用で確かめたいことは、実のところ2つしかありません。入社後に自分で決められるかと、決めたことを説明できるかです。
担当した範囲と、使った技術名
- 「大手通信会社の基幹システム開発に従事」
- 「Java / Spring / Oracle を使用」
- 「詳細設計から結合テストまでを担当」
- 経験年数は十分に見える
その現場で何を自分が決めたのか
- どの選択肢があり、どれを捨てたのか
- なぜその判断にしたのか
- 判断が間違っていたとき何をしたのか
- 決めた経験が1つも読み取れない
左側は正しく書けているのに、右側が空白になっている。これが書類で止まる最大の理由です。技術名を増やしても右側は埋まりません。
逆に言えば、右側に1つでも具体的な話が入っていれば、言語が違っても選考は進みます。自社開発企業の多くは「うちのスタックの経験」よりも「決めてきた人かどうか」を優先します。入社後に教えられるのは前者だけだからです。
常駐の仕事は、判断が職歴に残らない構造になっている
ここが本題です。本人の怠慢ではなく、仕事の形がそうなっています。
- 要件はすでに決まった状態で降りてくる。何を作るかの議論には入れない
- 技術選定は常駐先が済ませている。「なぜReactなのか」を考える場面が来ない
- 設計書のフォーマットが決まっている。判断の余地があるのは実装の細部だけ
- コードは常駐先の資産なので、外には出せない
- リリース後にどう使われたかが共有されない。自分の判断の正解・不正解が分からない
5つ目が一番きついところです。判断の質は「決めた結果どうなったか」を見て初めて上がるのに、常駐の立場ではその情報が返ってきません。年数は増えるが、判断の経験値だけが増えないという状態になります。
この構造に長くいると、面接で「主体性がない」と評価されます。本人は指示通り正確に動いてきたのに、評価の軸が違うところに置かれている。市場での評価が何で決まるのかを先に整理したい人は、エンジニアの市場価値を上げる方法のほうが順番として先かもしれません。
書類で落ちるときと、面接で落ちるときは原因が違う
対策を打つ前に、自分がどちらで止まっているかを分けてください。混ぜて考えると打ち手がぼやけます。
| 止まる場所 | 読まれているもの | 効く対策 |
|---|---|---|
| 書類 | 判断した跡が1行もあるか | 職務経歴書の書き直し。担当範囲ではなく決めたことを書く |
| 一次面接 | 現場の話を自分の言葉で話せるか | 常駐先の案件を「自分の判断」の単位で分解して準備する |
| 技術面接・コードテスト | 要件から構成を決められるか | 自分で要件を決めて作ったものが1つ必要 |
| 最終 | 入社後に何をしたいか | 志望動機の問題。技術の話ではない |
書類で落ちているなら、新しい技術の学習は後回しでいいです。同じ現場の経験でも、書き方を変えるだけで通過率は変わります。「詳細設計から結合テストまでを担当」を「レスポンスが落ちていた一覧画面について、キャッシュを足す案とクエリを分割する案を比べ、運用の手間が増えない後者で改修した」に直す。同じ仕事の話です。
技術面接で止まっているなら、ここは書き方では埋まりません。要件を自分で決めた経験が実際に必要になります。
自社開発の選考で材料になるものは、4つしかない
常駐先のコードを出せない中で、判断を示せるものは限られます。使えるのは次の4つです。
判断を見せる手段
- 01常駐先の案件のうち、自分が選択をした箇所を言語化したもの（コードを出さなくても話せる）
- 02自分で要件を決めて作ったサービス。規模は小さくてよく、判断の記録が残っていることが条件
- 03外部の人からレビューを受けた経験。社内の慣習ではなく一般的な基準で見られた実績
- 04技術的な判断について書いた記事。読み手がいる場所に出していれば、それ自体が検証になる
1つ目は今日からできます。直近1年の案件を振り返って、「自分が選んだ」と言える箇所を3つ書き出す。変数名の付け方でも、テストの分け方でも構いません。選択肢が2つ以上あって、理由があって選んだものならすべて材料になります。
2つ目については、注意点があります。経験者の個人開発は未経験者のポートフォリオとは別の読まれ方をするので、機能を増やしても評価になりません。詳しくは個人開発は転職で評価されるのかに書きました。
3つ目が、常駐や受託の人にとって一番手に入りにくいものです。常駐先のレビューは「その現場のルールに合っているか」を見るもので、外でも通用する基準とは別物のことがあります。設計そのものが苦手だと感じている場合は、原因の切り分けから入ったほうが早いです（実装はできるのに設計ができない原因）。
今の現場でできること、できないこと
やみくもに動く前に、現状で届く範囲を確かめたほうが早いです。
できること：
- 担当範囲の中で、自分の裁量がある箇所を探して意識的に決める
- 決めた理由を、その場でメモに残す（後からは思い出せません）
- レビュー依頼のときに「A案とB案で迷い、こう考えてAにした」と添える
- 常駐先の技術選定の理由を、分かる人に聞く。自分で決めていなくても、理由を理解していれば面接で話せます
できないこと：
- 要件を決める経験を、常駐の立場で得る
- 自分の判断が中長期でどう効いたかを知る
- 外の基準でのレビューを受ける
後者の3つは、現場を変えるか、現場の外に場を作るかしないと埋まりません。ここを「頑張れば今の現場で何とかなる」と考えて数年を使ってしまうのが、一番もったいないパターンです。「自走できるエンジニア」とは何かで分解した4つの力のうち、常駐で伸びるものと伸びないものが分かれるのはこの理由です。
正直なところ：自社開発に行けば解決する話ではない
ここは曖昧にしないほうがいいので書きます。自社開発企業に入っても、判断をさせてもらえないことはあります。
- 人数が多い会社では、決める人と実装する人が分かれている
- 立ち上がったばかりのプロダクトでなければ、技術選定はすでに終わっている
- 「自社開発」という言葉は、受託と自社サービスを両方やっている会社でも使われます
つまり、自社開発かどうかは手段で、目的は「自分で決める仕事に変えること」です。求人票を見るときは、雇用形態ではなく「入社後に自分が何を決めるのか」を聞いてください。ここを面接で具体的に答えられる会社は、実際にそうなっていることが多いです。
逆に、常駐のままでも裁量の大きい案件に当たることはあります。SESを抜けること自体が答えではありません。
まとめ
| よくある前提 | 実際 |
|---|---|
| 技術力が足りないから落ちる | 判断した跡が読み取れないから落ちる |
| 新しい言語を覚えれば通る | 同じ経験の書き方を変えるほうが先 |
| 経験年数が増えれば有利になる | 判断の経験が増えないと年数は効かない |
| 自社開発に移れば解決する | 「自分で決める仕事か」が本体。形態ではない |
やることの順番は、①今の現場で自分が決めた箇所を3つ書き出す、②職務経歴書をその単位で書き直す、③それでも技術面接で止まるなら、自分で要件を決めたものを1つ作る——この3つです。①と②は今週できます。
JISOUは実務経験者のためのスクールで、受講生は自分のアイデアでサービスを1つ作り、提出したコードに現役エンジニアのレビューが入ります。学んだこととつまずいた点を記事として出すことも前提に入っているので、「自分で決めて、外の基準で見られて、記録が残る」という常駐先では揃いにくい3つが同時に埋まります。スクールが必要かどうかの判断材料としては、経験者向けプログラミングスクールの選び方も合わせて見てください。