「社内SEに転職したけど、なんか思っていたのと違う」「これから社内SEを目指してるけど、後悔してる人の本音を読んでおきたい」――そんな気持ちでこの記事にたどり着いた人が多いんじゃないかと思います。
私自身、前職がSIer（クライアント先のシステム開発を請け負う会社）、前々職が社内SEで、現在は再び中小企業の社内SEとして働いています。社内SE経験は通算で約4年というところです。結論から言うと、今回の転職そのものは悪くなかったと思っていますが、入社前のイメージと現実の間にギャップがいくつもあって、後悔と呼べるレベルの「想定外」もありました。
この記事では、現役の社内SEとして実際に感じている後悔ポイントを5つに絞って書いていきます。検索でよく見る「後悔する理由6選」みたいな一般論ではなく、自分の現場で起きていることを土台にした話です。読み終わる頃には、あなた自身が後悔しやすいタイプかどうか、ある程度判断できるようになっているはずです。
「やめとけ」ではなく「後悔」の話に絞ります
ネット上には「社内SE やめとけ」系の記事もたくさんあります。あれは入社前に向き不向きを判断する話なので、まだ転職していない人向けです。
一方この記事で書く「後悔」は、入社後に発覚するギャップの話です。求人票や転職メディアの説明では見えにくくて、実際に働いてみて初めて「あ、聞いてた話と違う」と気づくタイプの違和感を扱います。
なので、もしあなたがまだ転職を決めていない段階なら、この記事は「入社後に何が見えてくるのか」を先回りして知るための材料として使ってもらえれば。すでに転職した後で「思ってたのと違う」と感じている人なら、自分のもやもやの正体を整理する材料になるはずです。
最初に断っておくと、私は中小企業の社内SEです。企業規模や業界によって社内SEの仕事は本当に大きく変わるので、ここからの話はあくまで「中小企業の一例」として読んでください。
私が実際に後悔した5つのギャップ
ここからが本題です。
ギャップ1：自社開発の比率は高いのに、スキルは伸びにくかった
これが個人的には一番大きな想定外でした。
私はもともと、社内SEは「ベンダーに開発を依頼しつつ、自分は要件定義や進捗管理が中心。ツール類くらいなら多少自分でも作る」みたいなイメージを持っていました。基本は発注者側の立場で動ける、という想定だったんですよね。
ところが実際に入社してみると、ほぼ完全に自社開発でした。販売管理システムの刷新のような大きな案件はベンダーに依頼しますが、日々の機能開発はほとんど社内です。私自身がコードを書く立場で動いています。
ここまでなら「想定と違ったね」で済む話なんですが、もう一段深いギャップがあります。
それは、自社開発と言っても新規開発をバンバンやっているわけではないということです。私の現場では、EDI（取引先との電子データ交換）処理の既存コードをコピーして取引先ごとに微調整する、みたいな仕事が中心になります。仕様の8〜9割は既存処理の流用で、新規で頭から設計する場面は多くありません。
世間ではよく「社内SEはスキルアップしづらい」と言われますが、その理由は多くの場合「開発を外注しているからコードを書く機会が少ない」という文脈です。一方で私のように自社開発比率が高い現場でも、結局は「コピー改修中心でスキルが伸びにくい」という同じ着地点に行きがち、というのが体感です。
「ベンダー管理寄りで動きたかったのに自分で書いてる」と「書いてはいるけど中身はコピー改修ばかり」のダブルパンチで、ここは入社前に一番見えていなかった部分でした。
ギャップ2：問い合わせと割り込みで、集中時間がほとんど取れない
社内SEの仕事は基本的に、開発タスクと社内からの問い合わせ対応の二本立てです。
問題は、その配分が日によって全然違うことです。問い合わせがほぼゼロで開発に集中できる日もあれば、半日以上が問い合わせ対応で潰れる日もあります。事前に予測できない。
そして私のように1つのタスクに集中したいタイプにとって、これは想像以上にしんどいです。せっかく頭の中で組み立てた処理の論理が、問い合わせ1つで吹き飛んで、また組み立て直すところからやり直し、みたいなことが普通に起きます。
「ちょっとこのデータ見てもらえる？」「このツール起動しないんだけど」みたいな相談が日中ぱらぱら入ってきて、それを処理しながら自分のタスクも進める。これがマルチタスクの常態化として効いてきます。
SIerの頃のように「納期は厳しいけど比較的目の前のタスクだけに集中できる」働き方とは、まったく違う頭の使い方が求められると思っておいた方がいいです。
ギャップ3：技術スタックがレガシー寄りで、モダン技術にほぼ触れない
私の現場で日常的に使う技術は、SQLとバッチ処理が中心です。ツール類の開発ではVB.NETやExcel VBAを使っています。クラウド・コンテナ・生成AIや、アジャイル開発のようなモダンな技術や開発手法は、業務の中ではほぼ触れません。最新技術に触れたければ、個人で勉強する必要があります。
ここで気になって少し調べてみたんですが、「中小企業はレガシー寄り」という肌感覚は概ね世間の傾向とも合っているようでした。中堅中小企業ではオフコンや古いプログラミング言語が運用継続されていて、人手不足でモダン化が進みにくい、という指摘が業界レポートでも見られます。
ただ、ここで注意してほしいのが、「じゃあ大企業の社内SEならモダン技術が触れるんでしょ？」と単純に決めつけられないことです。
調べてみた感じだと、大企業だからといって必ずしもモダン技術中心、というわけでもないようです。大企業は数十年前から基幹システムを整備してきた歴史があるので、古い基幹システムを保守している部署も普通に存在しているようでした。
つまり「大企業＝モダン、中小＝レガシー」と単純に振り分けられるわけではなく、同じ会社の中でもモダン化を進めている部署とレガシー基幹を保守している部署が混ざっている、というのが現実に近そうです。
なので、もしあなたがモダン技術を仕事で扱いたいタイプなら、企業規模で判断するのは危険です。面接で「どの部署でどんな技術を使うのか」を、できるだけピンポイントで確認してください。求人票の「クラウド推進中」みたいな全社スローガンより、配属部署の実態のほうが100倍大事です。
ギャップ4：業務知識の汎用性は、思ったほど高くなかった
社内SE推し記事でよく語られる利点に「自社の業務知識が身につく」「ITと業務の両方がわかるようになる」というのがあります。これ自体は嘘ではないんですが、私の体感だと、ちょっと美化されているかなと感じます。
私の場合、物流まわりの業務知識については、これから身についていきそうな手応えはあります。出荷・入荷・在庫の流れや、物流現場で起きやすいトラブルのパターンが、対応するたびに少しずつ頭に入っていく感じです。長くいれば他社でも部分的に通用するレベルにはなりそうだな、とは感じています。
ただ、経理はそこまで身についていません。私の現場での経理との関わりは、「販売管理システムから経理システム向けにデータを出力する」という既存の連携処理が走っている、というレベルです。私自身がその仕組みを作ったわけでもなく、業務として深く触っているわけでもありません。仕訳の考え方や決算の流れまで踏み込んでいるわけじゃないので、「経理がわかる社内SEです」とは胸を張って言えません。
そして一番大きいのが、社内SEで身につく業務知識の多くは、その会社特有の業務フローに依存しているという点です。「うちでは出荷データをこういう順番で処理する」「この商品マスタのこのコードはこういう例外を持っている」みたいな知識は、外に持ち出した瞬間にほぼゼロになります。
なので、業務知識を市場価値の核にして転職しようと考えていると、思ったほど通用しないことに後悔する可能性があります。
ただし、これは社内SEの中でも自社開発で新規開発をガンガンやっているタイプの人なら、話は変わってきます。設計・実装の経験そのものが市場価値になるので、業務知識の汎用性が低くてもキャリア面では困りにくい。
裏を返すと、私のように「コピー改修中心の自社開発」＋「特殊な業務フロー知識」の組み合わせだと、市場価値の積み上げ方をかなり意識的に考えないと、後で苦労するなと感じています。
ギャップ5：残業は少ないが、休日出勤や繁忙期はある
社内SEの代表的なイメージに「残業が少なくてホワイト」というのがあります。これは半分本当で、半分注意が必要です。
通常の月だと、私の残業は月10時間以内に収まっています。これはイメージ通りで、外部からの納期プレッシャーが少ない分、深夜まで残業に追われることは基本的にありません。
ただし、これで「常にホワイト」と言い切れるかというと、そう簡単ではありません。
業務の都合で休日出勤がある場面は普通にあります。システムの入れ替えや、サーバー・クライアントPCの入れ替えなど、平日の業務時間中にはできない作業を行う必要がある場合に、休日や夜間で対応します。完全に土日休みでカレンダー通り、というわけにはいきません。
それから、システム入れ替えのタイミングなどでは、一時的に忙しくなる期間があります。月次・年次の定例作業（棚卸対応など）も発生しますが、こちらは「忙しい」というより「いつもと違う業務をする日」というニュアンスに近いです。とはいえ、常にいつもと同じペースが続くわけではない、というのは正直なところです。
「社内SEは残業少ない＝常にホワイト」という思い込みのまま入ると、稼働の柔軟性を求められる場面でメンタル的にガッカリしやすいです。
後悔しやすい人・しにくい人
ここまでの5つのギャップを踏まえて、後悔しやすい・しにくい傾向を整理します。
後悔しやすい人：
- 1つのタスクに集中したい集中型の人
- コーディングや新規開発の手応えで成長したい人
- モダン技術を仕事で扱いたい人
- 評価を数字で見たい人
特に「コーディング機会」については補足が要ります。世間一般の社内SEは、開発を外注している会社が多く、自分でコードを書く機会はそもそも少ない傾向があります。一方で私のように自社開発比率が高い現場でも、中身はコピー改修が中心になりがちです。どちらに転んでも、「コードを書いて開発の手応えで成長したい」というモチベーションで入ると、肩透かしを食らいやすい職種ではあります。
後悔しにくい人：
- マルチタスクが平気で、頭を切り替えるのが苦じゃない人
- レガシー寄りの技術でも気にならない人
- 既存改修中心の開発でも淡々と進められる人
- 安定した環境を重視する人
特に「集中型」と「マルチタスク許容型」のどちらに自分が寄っているかは、入社後の体感を大きく左右します。性格の相性なので、後から矯正するのが難しい部分です。
入社前に後悔を減らすためのチェック観点
求人票や面接で、私だったら以下のあたりを確認します。
- 自社開発とベンダー依頼の比率
- 自社開発の中身（新規開発と既存改修・コピー改修の比率）
- 開発タスクと問い合わせ対応の比率
- 技術スタック（部署単位で具体的に。全社スローガンではなく自分が配属される部署の話を聞く）
- 休日出勤・当番制の有無
- 残業時間の実態
- ヘルプデスク業務の有無（PCトラブル・パスワードリセットなど）
特に「自社開発の中身」と「配属部署の技術スタック」は、求人票だけでは絶対に見えない部分なので、面接で踏み込んで聞いてください。「自社開発が中心です」だけだと、コピー改修ばかりなのか新規開発バリバリなのかは判断できません。
聞きづらい質問もあるかもしれませんが、入社後の数年間の働き方が決まる話なので、ここで遠慮しても誰も得しないです。
まとめ｜後悔ゼロは難しい、でも予測できるギャップは潰せる
社内SEへの転職で後悔ゼロというのは、たぶん無理です。実際に働いてみないと見えない部分はどうしても残るし、自分自身の好みも入ってみてから気づくこともあります。
ただ、ここで紹介した5つのギャップは、面接で踏み込めばかなりの精度で事前察知できるものばかりです。
- 自社開発の比率と中身
- 問い合わせ対応の量
- 技術スタックの実態
- 業務知識の汎用性
- 休日出勤・繁忙期の有無
これらを「ラベル」ではなく「現場感」で確認できれば、入社後に「聞いてた話と違う」と感じる量はかなり減らせます。
社内SEは条件と相性が合えば悪くない選択肢ですが、ラベルだけ見て飛び込むと痛い目を見る職種でもあります。この記事が、あなたの判断材料の1つになれば嬉しいです。
社内SEの仕事内容の全体像は、こちらの記事にまとめています。
コメント