開発エンジニアから社内SEへ転職｜コードは書き続けられる？違い・後悔しない求人の選び方

社内SEの求人を眺めていて引っかかっているのは、働き方の話よりも、開発から離れてしまうことのほうではないでしょうか。

先に答えを言うと、社内SEになってもコードを書き続けることはできます。ただ、書けるかどうかは会社の規模や知名度ではなく、配属されるポジションでほぼ決まります。同じ社内SEの求人でも、業務アプリを自社で作り続ける仕事があれば、実装はすべて外注で自分は要件をまとめて見積もりを確認するだけ、という仕事もあるのです。この違いを確かめずに入社すると、想像していた働き方とのずれに入社後すぐ気づくことになります。

この記事では、開発エンジニアから社内SEへの転職を考えている人に向けて、開発職との違い、コードを書ける社内SEポジションの見分け方、開発出身者が後悔するパターン、面接で必ず聞かれる質問への考え方、転職後のキャリアまでを、開発と採用面接の両方に関わってきたエンジニアの視点で解説します。社内SEへの転職難易度や選考全体の進め方については、社内SEへの転職は難しい？転職難易度が高い理由と受かるための対策で詳しくまとめています。

結論｜開発経験を活かしたいなら、求人の開発比率を確かめてから応募しよう

開発エンジニアが社内SEの求人を選ぶとき、最優先で確かめるべきなのは、入社後に自分がどれくらいコードを書くのかという開発比率です。年収や企業の知名度は、その次で構いません。

厄介なのは、この開発比率が求人票からはほとんど読み取れないことです。内製開発と書いてあっても、社内でやっているのは要件定義と受入テストだけで、実装は外部の開発会社に任せている会社は普通にあります。面接で確かめる方法は後ほど詳しく紹介しますが、応募する前の段階で見極めたいなら、企業の内情を把握している転職エージェントに確認してもらうのが一番早い方法です。

相談するときは、社内SEを希望しているとだけ伝えて終わらせないでください。業務の何割くらいはコードを書いていたいのか、これまでの言語や担当工程をどの程度活かしたいのかまで伝えておくと、紹介される求人の精度がはっきり変わります。

開発経験を活かせる社内SE求人に強い転職エージェント3選

レバテックキャリア

IT・Web領域に特化した転職エージェントです。技術に詳しいアドバイザーが、使ってきた言語や担当工程まで踏み込んでヒアリングしてくれるので、自分の開発経験がどの社内SE求人で評価されるのかを具体的に相談できます。

無料相談OK！ → 公式サイトはこちら

ギークリー（Geekly）

IT/Web/ゲーム業界の転職に特化したエージェントで、社内SEのほか自社開発やコーポレートエンジニアの求人も扱っています。社内SEに絞るか、開発職も含めて比べるか、まだ決めきれていない段階でも相談しやすいサービスです。

無料相談OK！ → 公式サイトはこちら

テックゴー

ITエンジニア専門のエージェントで、事業会社への転職を目指す人の利用が多いサービスです。模擬面接を回数の制限なく受けられるため、開発出身者が必ず聞かれる、なぜ開発職を離れるのかという質問への答えを納得いくまで練習できます。

無料相談OK！ → 公式サイトはこちら

開発エンジニアと社内SEの違い

開発職と社内SEの違いは、働き方や残業時間の面から語られることが多いのですが、開発エンジニアが転職後に戸惑うのは、もっと日々の仕事の手触りに近い部分です。ここでは開発者の目線で4つの違いを整理します。社内SEの仕事内容の全体像は社内SEの仕事内容とは？向いている人や必要なスキル・資格などを現役の社内SEが徹底解説！で、受託開発との働き方の比較は社内SEと受託開発の比較記事で解説しています。

①仕事のゴールが納品から使われ続けることに変わる

受託開発やSESの開発現場では、リリースが大きな区切りです。保守フェーズに入ったとしても、契約が終われば自分が作ったシステムから離れていきます。

社内SEにはこの区切りがありません。リリースした翌日から利用部門の問い合わせを受け、使いにくいと言われた画面を直し、数年後には自分が作ったシステムのリプレイスを検討する立場になります。作ったものを最後まで自分で引き受ける仕事だと考えてください。

作って納めた瞬間の達成感こそが開発の醍醐味だと感じている人には、ここが一番の違和感になります。反対に、自分の作った仕組みで隣の部署の残業が減ったことを、その部署の担当者から直接聞ける手応えは、社内SEでしか味わえないものです。

②評価されるのはコードの質より業務への効き目

開発職では、保守しやすい設計やテストの厚さ、コードレビューでの指摘の質が、そのまま評価につながります。社内SEで見られるのは、業務がどれだけ楽になったか、ミスがどれだけ減ったかのほうです。

たとえば月次の集計バッチを作り直し、処理が速くなったうえにコードも読みやすくなったとします。開発チームなら設計の改善として評価される仕事です。ところが社内SEとして評価されるのは、その結果として経理の締め作業が1日早く終わったという事実のほうで、リファクタリングそのものの価値は、説明しなければ社内の誰にも伝わりません。技術的な工夫を業務の言葉に置き換えて報告する手間が、毎回かかると思っておいたほうがいいでしょう。

③技術選定に事業会社ならではの制約がかかる

新しい言語やフレームワークを入れたいと考えたとき、社内SEが越えなければならない条件は技術的な優劣だけではありません。既存の基幹システムとつながるか、情報セキュリティ規程に合うか、予算の稟議が通るか。そして最後に必ず問われるのが、あなたが異動や退職をした後に誰が保守するのか、という点です。

技術的に正しい提案でも、この最後の問いに答えられなければ通りません。会社にとってシステムは何年も使い続ける資産で、特定の個人しか直せない状態はそれ自体がリスクだからです。技術選定の裁量が大きい開発組織から来た人ほど、この感覚の差に慣れるまで時間がかかります。

④一緒に働く相手が開発チームから非IT部門に変わる

開発チームの中では、技術用語がそのまま共通言語として通じます。社内SEが日常的にやり取りするのは営業や経理、人事、製造現場の担当者で、APIもデータベースも説明なしには通じません。

APIの仕様上できません、と答えても相手には何も伝わらないのです。今のシステム同士は自動ではつながらないので完全な連携には数か月かかる、ただ毎朝のCSV取り込みを1回挟めば手入力はなくせる、というところまで噛み砕き、代わりの手を示して初めて話が前に進みます。この翻訳作業を面倒と感じるか、相手の業務を知る面白さと感じるかで、社内SEへの適性ははっきり分かれます。

社内SEになっても開発はできる？コードを書く比率はポジションで決まる

社内SEになっても開発はできます。ただし、どれだけ書けるかは会社ではなく、配属されるポジションで決まります。社内SEの求人は、次の5つの型に分けて考えると開発比率の見当がつけやすくなります。

実際の求人は、この型が2つ3つ組み合わさっているのが普通です。業務改善を担当しながらSaaSの導入も任される、といった形ですね。見るべきなのは、どの型が含まれているかより、どの型の比重が一番大きいかです。

内製開発チーム型｜開発職に一番近いが求人は限られる

自社で使う業務システムや社内向けのWebアプリを、設計から実装、運用まで社内のエンジニアで作っているポジションです。新しい機能を継続的に作っている環境であれば、開発エンジニアとほとんど変わらない働き方ができます。

ただ、内製に本腰を入れて投資している企業はまだ限られていて、この型の求人は社内SE全体から見ると多くありません。求人名も社内SEではなく、社内システムエンジニア、業務アプリケーションエンジニア、DX推進エンジニアといった名前で出ていることがあるため、社内SEという言葉だけで検索していると見落とします。

注意したいのは、内製と書かれていても、実態は社員2人で小さな改修を回しているだけというケースです。チームの人数と、直近で何を作ったのかは必ず確認してください。

業務改善・自動化型｜小さく書き続けられる現実的なポジション

各部署に残っている手作業を、スクリプトやツールで自動化していくポジションです。Google Workspaceを使っている会社ならGoogle Apps Script、Microsoft 365の会社ならPower AutomateやExcel VBA、Pythonが主な道具になります。

作るものは数百行規模の小さなツールが中心です。それでも、現場で困りごとを聞き、仕様をまとめ、作って渡し、使われ方を見て直すという開発の一周を、短い期間で何度も回せます。大きなシステムは作れなくても書く仕事は手放したくない、という開発出身者にとって、一番現実的な落としどころがこの型です。情報システム部門にはコードを書ける人がいない会社も多いので、開発経験者がほかの候補者と差をつけやすいポジションでもあります。

SaaS導入・連携型｜書く量は減るがAPIの知識が効く

業務に使うSaaSを選び、導入し、既存のシステムとつなぐポジションです。ゼロからアプリを作る機会は減りますが、SaaS同士のデータ連携では、APIの仕様を読み、認証方式を理解し、連携が失敗したときの再送をどう設計するかを決める場面が必ず出てきます。ここで開発経験がそのまま効きます。

ただし、仕事の中身が管理画面の設定とアカウント発行で終わる求人もあります。連携部分を自分たちで作っているのか、連携までベンダーに任せているのかで、同じ型でも書く量は大きく変わります。

データ活用型｜SQLとデータ設計の経験がそのまま武器になる

社内のあちこちに散らばったデータを集め、経営や現場の判断に使える形に整えるポジションです。SQLで抽出し、データウェアハウスに集約し、BIツールでダッシュボードにする、といった仕事が中心になります。

テーブル設計やクエリのチューニングをやってきた開発者は、この型では最初から戦力になれます。求められるのはクエリを書く速さより、この数字を誰が何の判断に使うのかを利用部門と詰める力のほうです。そこさえ押さえれば、開発経験の転用先としてかなり相性のよい領域です。

IT企画・ベンダー管理型｜開発経験は判断材料として使う

システム化の構想を立て、予算を確保し、要件をまとめてベンダーに発注し、進捗を管理するポジションです。自分でコードを書く機会はほぼありません。

ここでの開発経験は、書くためではなく判断するために使います。どんな場面で効くのかは次の章で説明します。業務の具体的な中身はベンダーコントロールとは？情シス・社内SEの仕事内容と、やめておくべき求人の見分け方で解説しています。書く仕事を続けたい人は、この型の比重が大きい求人は避けてください。

求人票と面接でコードを書く比率を見極める方法

求人票で最初に見てほしいのは、仕事内容の欄より必須要件の欄です。特定の言語での開発経験が必須になっていれば、入社後に書く前提のポジションと考えてまず間違いありません。反対に、言語の指定がなく、要件定義やベンダー管理の経験が必須に並んでいる求人は、開発経験が歓迎要件に入っていても書く仕事は少なめです。

そのうえで、面接やエージェント経由で次の点を確かめてください。

答えが曖昧なままだと感じたら、最近作ったものの話を具体的に聞かせてください、と一歩踏み込むのが効果的です。本当に内製している会社なら、ここで話が止まることはありません。求人票の読み方全般については社内SEの求人票の見方｜情シスの「やめておくべき求人」を見分ける確認ポイントで詳しく解説しています。

開発エンジニアの経験が社内SEで活きる場面

開発経験が役に立つのは、コードを書くポジションだけではありません。実装をしない社内SEの仕事にも、開発をやってきた人にしかできない判断がいくつもあります。

ベンダーの成果物や見積もりの中身を技術的に判断できる

画面の項目を1つ追加する改修に20人日の見積もりが出てきたとき、それが妥当かどうかを判断できる発注者は多くありません。開発経験があれば、影響を受けるテーブルや帳票、必要なテストの範囲を頭の中で数え、どこに工数が乗っているのかを具体的に質問できます。

設計レビューで、この作りだと将来の項目追加のたびに改修費がかかる、と指摘できるのも書いてきた人ならではです。発注者側が技術を分かっていると、ベンダーの提案の質そのものが上がっていきます。

ブラックボックス化した既存システムを読み解ける

長く使われている社内システムには、作った人がすでに社内におらず仕様書も残っていない、というものが必ず混ざっています。前任者が残したスクリプトが毎晩何かを処理しているのに、何をしているのかは誰も知らない。事業会社ではよくある話です。

ソースコードや設定ファイル、ログ、テーブル定義をたどって実際の動きを解き明かせるのは、開発経験者の大きな強みです。リプレイスを提案する前に、今の仕組みのどこを触ると危ないのかを示せる人は、レガシーなシステムを抱える会社でかなり頼りにされます。

障害の切り分けでログとデータを追える

利用部門からの障害連絡は、画面が固まった、急にエラーが出た、といった症状だけで届きます。開発経験があれば、再現する条件を聞き取り、ログでエラーの発生箇所を確かめ、アプリケーションの問題なのか、データの不整合なのか、連携先の障害なのかを切り分けたうえでベンダーに渡せます。

症状だけを丸投げした場合と比べて、ベンダーとのやり取りの往復が何回も減り、復旧までの時間が目に見えて短くなります。

要望を聞いた時点で改修の重さを見積もれる

利用部門から、画面にこの項目を足してほしいと頼まれたとします。開発経験者なら、既存のテーブルに列を足せば済む話なのか、基幹データの設計まで変わる話なのかを、その場でおおよそ判断できます。

今週中にできますと言えるのか、3か月の検討が必要ですと伝えるべきなのか。その見当がすぐにつくだけで、利用部門との会話のスピードがまるで変わります。できるかどうか持ち帰って確認します、を繰り返す社内SEとの差は、半年もすれば社内の信頼の差になって表れます。

開発エンジニアが社内SEへ転職して後悔するパターン

社内SEはつまらない、という声を開発出身者から聞くことがあります。ただ、話をよく聞いてみると、仕事そのものが退屈だったというより、入社前に想像していた働き方と実態がずれていたケースがほとんどです。ここでは開発出身者に特有の後悔を5つ挙げます。

①入社してみたらコードを書く時間がほぼなかった

一番多い後悔です。開発もできると聞いて入社したのに、実際の毎日はアカウント発行とPCのセットアップ、問い合わせ対応、ベンダーへの連絡で埋まっていく。面接で聞いた開発業務は、年に数回ある小さな改修のことだった、というパターンです。

原因はほぼ一つで、開発があるかどうかしか確認していないことにあります。前の章で紹介した質問で、誰がどの工程をどれくらい担当しているのかまで聞いていれば防げた後悔です。

②技術スタックが古く、変える権限もない

10年以上前に作られた基幹システムを、つぎはぎしながら守ることが仕事の中心になる職場もあります。古い技術を扱うこと自体は問題ではありません。つらいのは、問題点が見えているのに、予算がない、現場が変えたがらないといった理由で、改善の提案がいつまでも通らない状態です。

面接では、使っている技術を聞くだけで終わらせず、システム刷新の計画があるのか、最近出た改善提案がどう扱われたのかまで聞いておいてください。その会社で自分の提案が通る余地があるのかを判断できます。

③技術の話が通じる相手が社内にいない

情報システム部門が数人しかいない会社では、コードレビューの相手も、設計を相談する相手もいません。実装方針に迷っても、自分で決めて自分で責任を負うしかない状態が続きます。

開発出身者の成長が止まる原因は、扱う技術の古さよりも、この相談相手のいなさのほうが大きいのです。間違いを指摘してくれる人がいない環境では、自分の判断の癖に気づくきっかけがなくなります。技術的に伸び続けたいなら、開発に関わるメンバーの人数とレビューの有無は、年収と同じくらいの重さで確認してください。

④開発の成果が評価制度に乗らない

情報システム部門を管理部門として扱う会社では、新しいツールを作ったことより、トラブルなく1年を終えたことやコストを下げたことが評価の中心になります。業務を大きく効率化するツールを作っても、目標設定のシートに開発の成果を書く欄がない、ということも起こります。

内製の成果がどう評価されるのかは、面接の終盤やオファー面談で遠慮なく聞いて構いません。具体的に説明できない会社は、まだ社内で内製をきちんと位置づけていないと判断できます。

⑤開発以外の業務が想像以上に多い

アカウント管理や問い合わせ対応といった運用業務は、どのポジション型を選んでもゼロにはなりません。ある程度は社内SEの仕事として受け入れる必要があります。

問題になるのは比率です。気づけば実質的なヘルプデスク担当になっていた、という事態だけは避けたいところでしょう。ヘルプデスク業務が社内SEの仕事にどう入り込んでくるのかは、SIerから社内SEへ転職する方法｜経験を活かして成功するコツのデメリットの章で具体的に解説しています。

社内SEに移っても技術力を落とさないための具体策

どのポジション型を選んでも、開発職にいたときより業務で書く量は減ります。技術力を保つには、業務の中に書く機会を作ることと、業務の外に書く場所を確保することの両方が必要です。

自分の業務を自動化の題材にする

最初に手をつけやすいのは、社内SE自身の定型作業です。入退社に伴うアカウントの発行と削除、ライセンス数の棚卸し、問い合わせ件数の集計など、どの会社の情報システム部門にも手作業で回している仕事が残っています。

自分の業務であれば、利用部門の承認を待たずに改善を始められますし、うまくいかなくても影響は部内で収まります。Microsoft 365の会社ならMicrosoft Graph API、Google Workspaceの会社ならAdmin SDKを使うと、アカウント管理の作業の多くはスクリプトで自動化できます。管理系のAPIを触った経験はそのままSaaS連携の仕事にも転用できるので、技術の幅を広げる題材としても優秀です。

小さなツールで実績を作り、内製の範囲を広げる

開発の機会が少ないポジションでも、内製の範囲は自分で広げられます。ただし、いきなり大きなシステムの内製を提案しても予算は下りません。

現実的なのは、各部署で手作業になっているExcel集計などを見つけ、数日で作れる小さなツールで解決してみせることです。その際、作業時間がどれだけ減ったかを記録しておくと、次の提案の根拠として使えます。小さな成功を2つ3つ積み上げると、次の改修は外注せずに社内でやろう、という判断が自然と出てくるようになります。

クラウドとセキュリティを学ぶ領域に選ぶ

業務外で学ぶ領域を選ぶなら、クラウドと情報セキュリティを優先してください。社内SEは、SaaSの導入やクラウドへの移行のたびに、アカウントと権限の設計、ログの取得、データの暗号化といった判断を求められます。開発職にいた頃はインフラ担当に任せていた部分ですが、社内SEでは自分で判断する場面が増えるので、学んだことがすぐ業務で使えます。

入口としては、AWSを使っている会社ならAWS公式の学習サイトであるAWS Skill Builder、AzureやMicrosoft 365を使っている会社ならMicrosoft Learnが使えます。どちらも無料で始められる公式教材なので、自社で使っているサービスに絞って学べるのが利点です。資格をどう選ぶかについては、SIerから社内SEへ転職する方法の中で整理しています。

業務の外に書く場所を持つ

社内で書く機会が少ない時期に備えて、業務の外にも書く場所を持っておくと安心です。個人開発でもOSSへのコントリビュートでも構いません。大事なのは規模より継続で、GitHubに数か月おきでも更新が残っていれば、それだけで書き続けている証明になります。

この記録は、将来もう一度開発職に移りたくなったときの材料にもなります。戻るときの考え方はキャリアパスの章で詳しく触れます。

開発エンジニアで社内SEに向いている人・向いていない人

向き不向きを分けるのは、開発経験の長さではありません。技術を仕事の中のどこに置いているかです。

向いている人

技術を、業務の困りごとを解決するための道具と捉えている人は社内SEに向いています。書いたコードの難しさより、自分の作った仕組みで誰かの手作業が消えたことに満足できるタイプです。

開発職にいた頃、渡された仕様をそのまま作ることに物足りなさを感じていた人も向いています。社内SEは、なぜそれを作るのか、そもそも作る必要があるのかを決める段階から関われる仕事だからです。

向いていない人

新しい言語やフレームワークを触り続けること自体が一番のモチベーションになっている人は、社内SEには向きません。技術選定の制約と運用業務の比重を考えると、その欲求を満たし続けるのは難しいからです。この場合は、Web系の自社開発企業などで技術を追う道を選んだほうが満足度は高くなります。

ただし例外が一つあります。内製開発チーム型のポジションに絞れば、開発職とほぼ変わらない環境で働ける会社もあります。社内SEという職種名で一律に判断せず、ポジション単位で見てください。

自分がどちらなのか判断がつかないときは、直近1年の仕事で手応えを感じた場面を3つ書き出してみてください。3つとも実装に没頭していた時間なら、開発職に残るほうが合っています。作ったものが使われて感謝された場面や、要件を整理して現場が回り出した場面が1つでも入っているなら、社内SEとの相性は悪くありません。

開発出身者が社内SEの面接で必ず聞かれること

開発出身の候補者に対して、面接官が確かめたいことはほぼ決まっています。技術力の高さより、この人は開発を離れて本当に定着してくれるのか、という一点です。採用する側から見ると、次の4つの質問はどれもこの不安を確かめるためのものです。

なぜ開発職を離れるのですか？

この質問で面接官が警戒しているのは、開発がつらくて逃げてきたのではないか、という点です。逃げてきた人は、社内SEになっても障害調査や技術的に面倒な仕事から逃げるのではないか、と見られてしまいます。

答えを組み立てるときは、開発を離れる理由ではなく、開発の経験を通して関心がどこに移ったのかを話してください。たとえば、自分が作った機能が現場ではほとんど使われず、結局Excelで業務が回っていたと後から知った。それ以来、作る前の段階で業務を理解する立場に回りたいと考えるようになった、という流れです。開発を辞めたいのではなく、開発の経験を別の使い方で活かしたいのだと伝わる形になっていれば十分です。

ポイントは、そう感じた具体的な一場面を必ず入れることです。抽象的な志望理由はどの応募者も似た言葉になりますが、自分の現場で起きた出来事は本人にしか話せません。

コードを書く機会が減っても問題ありませんか？

ここで本心に反して、まったく問題ありませんと答えるのはやめてください。その答えで採用されれば、会社はあなたを書かない前提のポジションに置きます。入社後にずれが表面化し、早期離職につながる典型的な流れです。

どのくらい書いていたいのかは、正直に伝えて構いません。毎日実装したいわけではないけれど、業務の自動化や小規模な改修では手を動かし続けたい、というように関わり方の希望を具体的に言えば十分です。それで見送られるなら、その会社とは開発比率がそもそも合っていなかったということです。面接は、相手が自分を選ぶ場であると同時に、こちらが開発比率を確かめる場でもあります。

開発以外の業務にはどう向き合いますか？

問い合わせ対応やアカウント管理を自分の仕事ではないと考える人は、社内SEの選考では通りません。かといって、何でもやりますと答えるだけでは、開発出身者を採る理由が面接官に伝わりません。

評価されるのは、運用業務を開発者の目で改善していく姿勢です。同じ問い合わせが何度も来るなら原因を分類して手順書や画面の改修で元から減らす、手作業の多い運用はスクリプトで置き換える。こうした具体的な動き方を話せると、開発経験が運用でも活きる人材だと伝わります。

当社のシステムで何ができそうですか？

この質問には、応募先のシステム環境について自分なりの仮説を持って臨むのが理想です。とはいえ、外から社内システムの中身は見えません。開発出身者なら、次の3つの手がかりから技術環境をかなりの精度で推測できます。

1つ目は求人票の技術要件です。必須や歓迎に並んでいる言語、クラウド、SaaSの名前から、今の環境と、これから強化したい領域が読み取れます。2つ目は、SaaS各社が公開している導入事例です。応募先の社名で検索すると、どの業務にどのSaaSを入れたのかが、担当者のインタビューつきで載っていることがあります。3つ目は企業のテックブログや勉強会の登壇資料で、内製開発をしている会社なら、使っている技術や抱えている課題を自ら発信している場合もあります。

これらを踏まえ、会計と販売管理に別々のSaaSを使われているようなので、その間のデータ連携に手作業が残っていないか気になっています、というくらいまで具体的に言えれば十分です。外から見た仮説なので外れていても問題ありません。仮説を立てて質問できる人だと伝わること自体に意味があります。

社内SEの面接全般の対策は社内SEへの転職は難しい？転職難易度が高い理由と受かるための対策で、面接の最後に聞く逆質問の組み立て方は面接官に「刺さる」逆質問まとめ。「質問ありますか？」に臆せず内定を勝ち取る！で解説しています。

出身によって変わる注意点

同じ開発エンジニアでも、どんな会社で開発してきたかによって、社内SEへ移ったときに戸惑うポイントは変わります。

SIer・受託開発出身の場合

最大の変化は、立場が受注側から発注側に変わることです。仕様を受け取る側から、仕様を決めて予算を通す側に回るため、社内の合意形成に使う時間が一気に増えます。設計書を書いてきた経験やベンダー側の事情が分かることは大きな武器になりますが、それをどう伝えれば評価されるのかは出身業界ならではのコツがあります。詳しくはSIerから社内SEへ転職する方法｜経験を活かして成功するコツを参考にしてください。

Web系自社開発出身の場合

技術環境と意思決定のスピードの差に、最も戸惑うのがこの層です。クラウド上の構成で週に何度もデプロイしていた環境から、オンプレミスの基幹システムと、稟議を通さないと何も始まらない世界に移ることになります。変更を一つ入れるのに、利用部門の合意とセキュリティ部門の承認、場合によっては監査への対応まで必要になる職場もあります。

もう一つ確かめておきたいのが、自分がプロダクトのどこに惹かれていたのかです。ユーザー数や売上の指標を追いながらサービスを伸ばすことに面白さを感じていた人は、社内SEより、別の自社開発企業に移ったほうが満足度は高くなります。社内SEのユーザーは社員で、システムの成果は売上ではなく業務の効率で測られるからです。自社開発企業の求人とも比べたい人は、自社開発企業への転職に強いエージェント・サイト9選―未経験OKや社内SE向けも！を参考にしてください。

SES出身の場合

常駐先で情報システム部門と一緒に働いた経験は、社内SEの仕事を内側から見てきた経験として評価されます。ただし選考では、常駐先から指示された作業をこなしていたのか、自分で仕様や運用の改善を提案していたのかを細かく聞かれます。自分が判断した部分を切り分けて話せるように準備しておいてください。SESからの転職全般はSESは転職できないというのは本当？キャリアアップの道筋をSES経験者がお伝えする！で解説しています。

社内SEへ転職した後のキャリアパス

社内SEは技術の行き止まりではありません。開発経験を土台にすると、次のような道が開けます。

IT企画・情報システム部門の管理職へ進む

個別のシステム開発から、全社のIT予算や投資の優先順位、セキュリティ方針を決める立場へ進む道です。将来的にはCIO（最高情報責任者）のように、経営に近い役割も視野に入ります。開発経験のある管理職は、ベンダーの提案や部下の見積もりを技術的に評価できるので、意思決定の質で差をつけられます。

DX推進・業務改革の専門職になる

業務の流れそのものを見直し、デジタル化や自動化で会社全体の働き方を変えていく専門職です。業務改善・自動化型やデータ活用型のポジションで実績を積んだ人が進みやすい道で、技術力に加えて、現場を巻き込み、変化を定着させる力が求められます。

社内システムのプロダクトオーナーになる

社内システムを一つのプロダクトと捉え、要望の優先順位を決め、開発の計画を立てる役割です。内製開発チームを持つ会社で生まれやすいポジションで、実装の難しさを知っている人ほど現実的な計画を引けます。開発職にいた頃からプロダクトマネジメントに関心があった人にとって、社内SEを経由するのは遠回りではありません。

開発職へ戻る道は残るのか

戻れます。ただし、社内SE時代にどれだけ書いていたかで、戻るときの評価ははっきり分かれます。

内製開発チーム型や業務改善・自動化型で書き続けていた人は、開発経験に業務理解と要件定義の経験が上乗せされた人材として見られます。開発職の採用側から見ても、利用者と直接やり取りしてきたエンジニアは魅力的です。反対に、何年もまったく書かずにベンダー管理と運用だけをしていた場合、評価は社内SE経験者ではなく、開発にブランクのある人になります。

戻る可能性を残しておきたいなら、書く比率のあるポジションを選ぶことと、業務の外にも書く場所を持っておくこと。この2つを押さえておけば、社内SEを選んだことが開発職への道を閉ざすことにはなりません。

開発エンジニアから社内SEへ転職するときのよくある質問

社内SEに転職すると年収は下がりますか？

職種名だけで上がる下がるは決まりません。開発職の給与と比べるときに気をつけたいのは、給与の決まり方の違いです。IT企業にはエンジニア向けの給与テーブルがあることが多いのに対し、事業会社の社内SEは全社共通の等級制度で給与が決まるのが普通で、技術力の高さが給与に反映されにくい場合があります。

オファーを比べるときは、提示額だけでなく、等級制度の中での位置づけと昇給の仕組みまで確認しておきましょう。年収の目安となるデータはSIerから社内SEへ転職する方法で紹介しています。

プログラミング経験だけでも社内SEに応募できますか？

応募できます。内製開発チーム型と業務改善・自動化型の求人なら、実装経験がそのまま主な評価軸になります。インフラやネットワークの実務経験がないことだけで不利になることはありません。

ただし、規模の小さい情報システム部門では、一人でネットワークやPC管理まで見ることを前提にした求人もあります。必須要件にインフラ系の経験が入っていないかは必ず確認し、入っている場合はどこまで自分で学んでいるのかを説明できるようにしておきましょう。

ローコードやSaaS中心の社内SEで技術力は落ちませんか？

落ちるかどうかを決めるのは、使う道具ではなく、技術的な判断を自分でしているかどうかです。設定画面をマニュアル通りに操作するだけの毎日なら、開発者としての力は確実に落ちます。反対に、SaaSを使いながらでもデータ連携の設計や権限の設計、障害時の切り分けを自分で担っているなら、システム全体を設計する力はむしろ伸びます。

ローコード中心の求人に応募するときは、連携や設計の部分を誰が担っているのかを面接で確かめてください。

社内SEからWeb系・自社開発企業へ戻ることはできますか？

戻れます。そのときに必要なのは、社内SE時代の開発経験を、開発職の採用担当に伝わる形で説明できることです。

社内SEの経歴は、開発職の面接官から見ると何をしていたのかが分かりにくいものです。職務経歴書では、社内SEという職種名より先に、作ったものと使った技術が目に入るように書いてください。作ったツールごとに、どんな課題があり、どんな技術構成で、自分はどこを担当し、業務にどんな変化があったのかを整理しておくと、面接でも話がぶれません。社内の情報で具体的な数字や社名を出せない場合は、規模感と構成、解決のアプローチに絞って話せば十分伝わります。

まとめ｜社内SEでも開発は続けられる。決め手は求人の開発比率

社内SEになっても開発は続けられます。ただ、どれだけ書けるかは会社ではなくポジションで決まり、その中身は求人票の職種名からはほとんど読み取れません。

書く仕事を軸に残したいなら、内製開発チーム型か業務改善・自動化型の比重が大きい求人を選ぶこと。開発経験を判断力として使う働き方に移りたいなら、SaaS導入やIT企画の比重が大きい求人を選ぶこと。これが基本の考え方です。どちらを選ぶにしても、面接では内製と外注の割合、直近の開発実績、チームの人数とレビューの有無を確かめ、自分が望む書く量と合っているかを見てから判断してください。

まだ迷っているなら、まずは業務の何割くらいコードを書いていたいのかを言葉にしてみましょう。それが決まれば、求人の比較も面接での答え方も、一本の軸で考えられるようになります。応募先の開発比率を事前に確かめたいときは、社内SEの求人事情に詳しい転職エージェントに相談するのが近道です。

もう一度「開発エンジニアから社内SEへ転職｜コードは書き続けられる？違い・後悔しない求人の選び方」を読む ↑

開発経験を活かせる社内SE求人に強い転職エージェント3選

レバテックキャリア

レバテックキャリアは、IT・Web領域のエンジニアに特化した転職エージェントです。アドバイザーが技術や業界の動向に詳しく、言語やフレームワーク、担当してきた工程の話をかみ砕かずにそのまま伝えられます。企業ごとの開発体制や内製の進み具合など、求人票に出てこない情報を持っていることが多いため、開発比率を確かめてから応募したい開発出身者にとって相談しやすい相手です。

職務経歴書の添削や推薦状の作成も受けられるので、開発経験を社内SEの選考向けに書き直したいときにも役立ちます。ただし対応エリアは首都圏・東海・関西・福岡が中心で、未経験向けの求人は多くありません。

ギークリー（Geekly）

ギークリーは、IT/Web/ゲーム業界の転職に特化したエージェントです。職種ごとに専門のコンサルタントがつくため、社内SEとコーポレートエンジニア、自社開発の求人を同じ担当者のもとで比べながら相談できます。

紹介先企業で過去に出た面接の質問を共有してもらえるのも、開発出身者には心強い点です。なぜ開発職を離れるのか、といった定番の質問にどう準備すればいいかを、企業ごとの傾向を踏まえて固められます。対応エリアは一都三県と関西に限られ、未経験向けの求人もほとんど扱っていないため、開発経験のある人が首都圏・関西で転職する場合に使いたいサービスです。

テックゴー

テックゴーは、ITエンジニア専門の転職エージェントです。利用者には事業会社や大手SIerへの転職を目指す人が多く、情報システム部門のような事業会社側のIT職の求人も扱っています。全国の求人に対応しているので、地方で社内SEを探している開発エンジニアも相談できます。

模擬面接を回数の制限なく受けられるため、開発を離れる理由や、書く機会が減ることへの考え方を、言葉として固まるまで練習できます。なお、IT業界での実務経験が浅い段階では、受けられる支援の幅が変わる点は知っておきましょう。

もっと多くの社内SEに強い転職サイト・エージェントを比較したいという方は、「社内SEへの転職におすすめな転職サイト19選【未経験OKも！】」という記事を参考にしてください。