社内SEと自社開発、SES経験者はどっちが向いてる？仕事内容・働き方・向き不向きを比較

SESから転職しようとすると、候補に出やすいのが
社内SEと自社開発です。

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

SESから転職しようとすると、候補に出やすいのが

社内SE
と
自社開発

です。

どっちも「客先常駐から離れられそう」に見える。

ただ、実際の仕事はかなり違います。

ざっくり言えば、

社内SEは自社の業務やIT環境を支える仕事
自社開発は自社のサービスやプロダクトを作る仕事

という違いがあります。

もちろん会社によって境界は曖昧です。

社内SEでも内製開発する会社はあるし、自社開発でも運用や顧客対応はあります。

なので今回は、

「どっちが上か」

ではなく、

SES経験者が次に行くなら、どっちのほうが自分に合いやすいか

という目線で比較します。

まずは社内SEと自社開発の違いをざっくり比較

ざっくり表にするとこんな感じです。

項目社内SE自社開発
主な相手社内ユーザー自社サービスの利用者・事業部
主な仕事運用、企画、改善、社内調整設計、開発、改善、運用
開発比率会社によってかなり違う比較的高め
調整業務多めチーム・事業部との調整あり
技術の深掘り環境次第しやすい傾向
ユーザーとの距離かなり近いサービスによる
客先常駐基本なし基本なし

これだけ見ると、

「コードを書きたいなら自社開発」

で終わりそうですが、実際はもう少し複雑です。

社内SEは「自社の業務を支える」仕事

社内SEは、自社の社員が使うシステムやIT環境を支える仕事です。

たとえば、

  • 社内システムの導入
  • 運用保守
  • SaaS導入
  • PC・アカウント管理
  • セキュリティ
  • ベンダー管理
  • 問い合わせ対応
  • 業務改善

など。

特徴としては、

技術だけでは完結しない

ことが多いです。

人事。

経理。

営業。

総務。

現場部門。

いろんな部署と話します。

「このシステム入れれば解決です」

で終わらず、

「でも現場が使わない」

とか、

「予算が出ない」

とか、

「今のやり方を変えたくない」

みたいな話も普通にあります。

人間系バグ、強いです……。

社内SEの仕事内容や、SESから移ったときに何が変わるかは、こちらで詳しく整理しています。
→「SESから社内SEへ転職すると何が変わる？仕事内容・年収・働き方を比較」

自社開発は「自社プロダクトを育てる」仕事

自社開発では、自社で持つWebサービスやアプリ、業務プロダクトなどを開発します。

たとえば、

  • 要件整理
  • 設計
  • 実装
  • テスト
  • リリース
  • 運用
  • 機能改善

など。

SESと比べると、

自分たちで作ったものを継続して改善する

という感覚が強いです。

案件が終わったら次の現場へ移る、ではなく、

同じプロダクトを長く育てる。

ここに魅力を感じる人は多いと思います。

一方で、

開発スピード
売上
KPI
ユーザー数
リリース期限

など、事業側のプレッシャーもあります。

「自社開発ならのんびりコード書ける」

みたいな世界ではありません。

そんな楽園があるなら教えてほしいです……。

SES経験が活きやすいのはどっち？

これは経験の中身によります。

運用保守・顧客調整が多かった人

社内SEと相性がいい可能性があります。

たとえば、

  • 利用者問い合わせ
  • 障害一次切り分け
  • 顧客との定例
  • ベンダー調整
  • 手順書作成
  • 運用改善

この辺はかなりそのまま使えます。

特に、

相手の話を聞いて整理する
担当部署へ繋ぐ
障害時に状況を整理する

みたいな経験は社内SEでも使いやすいです。

開発経験が多かった人

自社開発のほうが繋げやすい場合があります。

  • Java
  • PHP
  • Python
  • JavaScript
  • React
  • Spring
  • AWS

など、開発経験や技術スタックがあるなら、比較的そのまま評価されやすいです。

ただし、

「開発経験あり」

だけでは足りません。

どの工程までやったか。

設計したか。

レビューしたか。

運用改善したか。

この辺も見られます。

「客先常駐をやめたい」だけなら、どっちでもいい？

これだけが理由なら、どちらも候補です。

ただ、

客先常駐をやめたい
の次に、

何を続けたいのか
を考えたほうがいいです。

技術を続けたい

→ 自社開発寄り

社内ユーザーに近い仕事がしたい

→ 社内SE寄り

調整や業務改善もやりたい

→ 社内SE寄り

プロダクトを長く育てたい

→ 自社開発寄り

運用・インフラも含めて幅広くやりたい

→ 社内SE寄り

こんな感じ。

社内SEが向いている人

個人的には、こんな人は社内SEと相性がいいと思います。

調整がそこまで苦じゃない

社内SEは人とのやり取りが多いです。

技術だけ見ていたい人には、少ししんどいかもしれません。

運用や改善が好き

「作って終わり」より、

「使われ方を見て直す」

のが好きな人。

利用者の近くで働きたい

ユーザーの声が直接飛んできます。

良い意味でも悪い意味でも近いです。

技術を広く触りたい

小〜中規模の会社だと、

開発
インフラ
SaaS
セキュリティ
PC管理

まで幅広く見ることがあります。

自社開発が向いている人

コードを書く時間を確保したい

これはかなり大きいです。

もちろん会議もありますが、社内SEより実装比率が高いケースは多いです。

コードを書く仕事をしたいけれど、今のSES現場では実装を任されないなら、まず経験を増やせる環境を探すところからでもいいと思います。開発経験が積めないときの選択肢と判断フローで、今の会社に残る場合も含めて整理しています。

技術を深めたい

特定の言語やフレームワーク、クラウド環境などを深掘りしたい人。

プロダクト志向がある

「機能を作る」
ではなく、

「このサービスを良くしたい」

と思える人。

事業成果にも興味がある

自社開発では、

売上
継続率
ユーザー数
CV

など、サービス指標を見る機会もあります。

技術だけではなく、事業にも興味がある人は相性がいいです。

逆に、社内SEが合わないかもしれない人

  • とにかく実装だけしたい
  • 問い合わせ対応がかなり苦手
  • 社内調整が嫌い
  • ベンダー管理に興味がない
  • 古いシステムに触りたくない

この辺。

特に「社内SE＝開発職」と思っていると危ないです。-

社内SE求人は、同じ職種名でも中身がかなり違います。求人票で確認したいポイントはこちらでまとめています。
→「社内SEの求人票で見るべきポイント7つ｜入社後に『思ってたのと違う』を減らす」

逆に、自社開発が合わないかもしれない人

  • 開発スピードが速い環境が苦手
  • 技術キャッチアップがしんどい
  • プロダクト責任を負いたくない
  • 仕様変更が多い環境が苦手
  • 事業側との調整が嫌い

自社開発は、

「自分たちで決められる」

反面、

「自分たちで結果を出す」

必要があります。

自由度と責任はだいたいセットです。

年収だけで選ぶのはちょっと危ない

社内SEでも高年収求人はあります。

自社開発でも高年収求人はあります。

逆もあります。

なので、

社内SEだから低い
自社開発だから高い

とは限りません。

見るべきなのは、

  • 基本給
  • 賞与
  • 残業代
  • 固定残業
  • 手当
  • 退職金
  • リモート可否
  • 年間休日
  • 夜間対応

あたり。

年収50万円上がっても、

夜間対応が増えたり、
残業が増えたり、
通勤時間が倍になったり。

そうなると、なんか話が違ってきます。

SES経験者向けの簡易判断フロー

ざっくり分けるなら、こんな感じです。

Q1. これからもコードを書きたい？

YES
→ 自社開発寄り

NO / どちらでも
→ Q2へ

Q2. 利用者や社内部門と話すのは苦じゃない？

YES
→ 社内SE寄り

NO
→ 自社開発寄り

Q3. 運用・改善・調整もやりたい？

YES
→ 社内SE寄り

NO
→ 自社開発寄り

Q4. 特定技術を深掘りしたい？

YES
→ 自社開発寄り

Q5. IT全体を広く見たい？

YES
→ 社内SE寄り

もちろんこれは万能診断ではありません。

でも、自分が何を重視しているか整理する材料にはなります。

面接でも「自分が何をしたいか」を確認する

どっちに行くとしても、

面接で実際の仕事内容は確認したほうがいいです。

たとえば社内SEなら、

  • 開発比率
  • 問い合わせ量
  • 夜間対応
  • ベンダー管理
  • 体制

自社開発なら、

  • 開発チーム人数
  • 技術スタック
  • レビュー体制
  • リリース頻度
  • 技術負債
  • プロダクト方針

この辺。

社内SE面接で確認したい逆質問は、こちらにまとめています。
→「SESから社内SEへ転職する面接で聞かれること・逆質問10例」

職務経歴書も応募先に合わせて見せ方を変える

社内SEと自社開発では、同じSES経験でも見せたい部分が違います。

社内SE向け

  • 顧客調整
  • 障害対応
  • 運用保守
  • 問い合わせ
  • ベンダー連携
  • 改善経験

自社開発向け

  • 実装経験
  • 設計
  • テスト設計
  • コードレビュー
  • CI/CD
  • クラウド
  • パフォーマンス改善

など。

同じ職務経歴書を全部に投げるより、

応募先に合わせて強調部分を変えたほうがいいです。

SES経験を社内SE向けにどう書き換えるかは、こちらで具体例を出しています。
→「SES経験は社内SEの職務経歴書でどう書く？業務別の言い換え例」

社内SEや自社開発への転職だけでなく、今のSES経験を使って独立する選択肢もあります。SESからフリーランスになる前に確認したいことでは、単価・税金・案件切れまで含めて整理しています。

まとめ：どっちが正解かではなく「何を続けたいか」

社内SEと自社開発。

どちらも、SESからの転職先としてはかなり有力です。

ただ、

客先常駐をやめたい

だけでは決めきれません。

その次に、

技術を深めたいのか
利用者に近い仕事がしたいのか
業務改善をしたいのか
プロダクトを育てたいのか

まで考える。

そこが見えれば、かなり選びやすくなります。

個人的には、

「何から逃げたいか」より「次でも何を続けたいか」

で考えるほうが、転職後のズレは少なくなると思っています。

関連投稿