IT・社内SE転職特化の転職サイト社内SE転職ナビでは、10,000件以上の求人をエリアや職種、スキル、報酬額などご希望に合わせて検索できます。社内SE転職ナビを運営するアイムファクトリーは、IT業界に精通したキャリアアドバイザーによる本質的なマッチングと、書類添削、面接対策など転職後まで伴走する徹底したサポート力が強みです。無料の転職サポートはこちら>>
エンジニアとして経験を積むほどに、マネジメントを期待される場面は増えていく。しかし中には、「技術に向き合い続けたい」と考える人も少なくない。今回は、マネジメントではなく『技術を深める道』を選び、社内SEとして新たなキャリアを築いた小林さん（34歳・仮名）に話を聞いた。スペシャリスト志向のエンジニアが選んだ『もう一つのキャリア』に迫る。
【転職者情報】
氏名：小林裕也
年齢：34歳
居住地：東京都
現職：社内SE（バックエンド・テックリード寄り）
前職：Web系企業／バックエンドエンジニア
エンジニア歴：11年
前職技術スタック：Java / Spring Boot、Kotlin、PostgreSQL、AWS
現職技術スタック：Go、TypeScript、GraphQL、AWS（ECS / Lambda / Aurora）
転職での変化：従業員300名・自社サービス企業（技術志向の文化あり）
◆ ① エンジニアとしてのキャリアのスタート
Q. エンジニアを目指したきっかけを教えてください
大学時代、プログラミングの授業で「コードを書いて動くものを作る」という体験に夢中になりました。もともと理系で数学が好きだったこともあり、ロジックを組み立てて問題を解くプロセスが自分に合っていると感じたんです。
最初の会社ではJavaを使ったバックエンド開発からスタートしました。最初は先輩のコードを読み解くだけで精一杯でしたが、徐々に自分で設計を考えられるようになって。そのころから「技術を深めることが自分の軸だ」という感覚が芽生えてきました。
◆ ② 前職：技術者としてのキャリアと評価
Q. 前職ではどのような業務を担当していましたか？
Web系企業でバックエンドエンジニアとして、主にAPIの設計・開発を担当していました。技術スタックはJava / Spring Boot、Kotlinが中心で、PostgreSQLとAWSを組み合わせたシステム構成でした。要件定義から実装、レビュー、本番リリースまで一気通貫で関わることが多く、技術的に幅広く経験を積めた環境でした。
Q. 技術者としてのやりがいはどこにありましたか？
やはり難易度の高い設計課題を解いたときの達成感ですね。たとえば、大量トランザクションを捌くためのパフォーマンスチューニングや、マイクロサービス間のデータ整合性をどう保つかという設計上の問いに向き合う時間が本当に好きでした。
コードレビューでも「この設計だと後からこういう問題が起きる」という観点を丁寧に伝えることで、チーム全体の技術品質を上げていける実感があって。技術で価値を出せていると感じる瞬間が、自分にとっての一番のモチベーションでした。
Q. 評価されるようになった一方で、変化はありましたか？
入社から数年が経ったころ、上長から「次のリーダー候補として育てたい」という話をもらうようになりました。チームの中でも技術的に頼られることが増え、それ自体はうれしかったのですが……同時に、少しずつコードを書く時間が減っていくのを感じていました。
Q. その中で感じた違和感は何でしたか？
週のうち、会議や調整に費やす時間がどんどん増えていって。「今週、ほとんどコード書けていないな」と気づいたとき、自分の中に焦りのような感覚が出てきました。
評価されることで、やりたいことから離れていく――そのジレンマが正直しんどくて。マネジメント自体が悪いわけじゃないし、チームを動かすことにも意義はある。でも、それが『自分のやりたいこと』かと問われると、素直にYESとは言えなかったんです。
「評価されるほど、やりたい仕事から離れる」――そのジレンマに気づいたとき、キャリアの問い直しが始まった。
◆ ③ 転機：「このまま管理側に進むのか」という問い
Q. キャリアを見直したきっかけは何ですか？
リーダー業務が本格化したタイミングです。プロジェクト管理、採用面接への同席、チームメンバーの育成計画……気づけば、コードよりもスプレッドシートと向き合っている時間の方が長くなっていました。
「このまま管理側に進んでいいのか？」という問いが、頭の中を離れなくなって。技術を極めたいという気持ちは昔と変わっていない。でも、このキャリアの方向性のままでは、どんどん遠ざかっていく。そのギャップが積み重なって、転職を本格的に考え始めました。
Q. 当時どのような選択肢を考えていましたか？
大きく三つ考えました。一つは今の会社でマネジメント寄りのキャリアを続ける選択。二つ目は技術職のまま別の開発会社に転職する選択。三つ目が、社内SEという選択肢でした。
最初は社内SEに対して「技術レベルが低いのでは」というイメージがあったんです。でも調べていくうちに、企業によってはかなり深い技術に携われることがわかってきて。むしろ、プロダクトに継続的に関わりながら設計・技術選定を担える環境として魅力に映るようになりました。
「マネジメントか、技術か」ではなく、「自分の軸で、どんな仕事をしたいか」を問い直す。
◆ ④ 社内SEという選択
Q. なぜ社内SEを選んだのですか？
一番の決め手は、技術に向き合い続けられる環境があると確信できたことです。今の会社は自社サービスを持っていて、バックエンドの設計から技術選定まで、エンジニアが主体的に関われる文化がある。面接を通じてそれを肌で感じました。
また、SaaS乱立の時代に、社内のシステム基盤を技術的に整えていくこと自体、専門性の発揮どころが大きいとも思っていました。外部のベンダーに丸投げするのではなく、内側から技術で課題を解く役割――それが自分のやりたいことと一致していました。
Q. 転職にあたって不安はありましたか？
ありました。特に「社内SEに転職したら技術的に後退するのでは？」という不安が一番大きかったです。Web系で鍛えてきたスキルが活かせるのか、新しい技術スタックにキャッチアップできるのか、という点も気になっていました。
あとは、社内SEというポジションがどこまでキャリアとして続くのか、という漠然とした不安も。「技術を深め続けられるか」という問いへの答えが見つかるまでは、踏み切れなかったと思います。
◆ ⑤ エージェントとの出会い
Q. エージェントを利用したきっかけは？
転職を意識し始めたとき、まず自分でいくつか転職サイトを見ていました。でも、「技術志向で社内SE」という軸で検索しても、なかなかしっくりくる情報が見つからなくて。そのとき、ちょうど社内SE転職ナビの記事をSNSで目にして、相談してみようと思ったんです。
Q. 初回面談の印象はいかがでしたか？
すごく驚いたのが、最初の面談から「マネジメントをやりたくない理由」を深掘りしてもらえたことです。普通の転職エージェントだと、年収や職種のマッチングの話が先に来るじゃないですか。でもここでは、「どういうときに技術に向き合えていると感じますか？」という問いから始まって。
「この人は自分のキャリアの軸を理解してくれている」という安心感が、最初の面談で生まれました。
Q. 印象に残っているサポートはありますか？
社内SEのリアルな技術レベルを丁寧に説明してもらえたことです。「どの企業も同じではなく、技術文化のある会社を選べば開発に深く関われる」という話は、私の思い込みを大きく変えてくれました。
また、一度も「マネジメントの方が将来性がある」とは言わなかった。自分の志向性を尊重して、技術に集中できる環境を一緒に探してくれた姿勢が、すごくありがたかったです。
「無理にマネジメントを勧めない」――価値観を尊重してくれる存在が、転職の不安を和らげてくれた。
◆ ⑥ 転職活動のプロセス
Q. 転職活動はどのように進みましたか？
エージェントから紹介された企業は4〜5社でした。いわゆる「数打てば当たる」の転職活動ではなく、私の技術志向と合う企業を厳選して提案してくれたので、一社一社に集中して臨めました。
面接の事前準備でも、「技術選定に関わった経験」「設計で工夫した点」など、技術力を伝えるための深掘り練習をしてもらって。これが実際の面接でかなり役立ちました。
Q. 転職先を決めた理由は？
技術スタックと開発文化が一番の決め手です。GoとTypeScriptを使ったバックエンド開発、GraphQL、AWSのECSやLambdaを活用したアーキテクチャ。モダンな構成で、且つ技術的な意思決定にエンジニアが直接関われる環境だと確信できました。
面接でCTOや現場のエンジニアと話したとき、「ここでは技術の話ができる」と素直に感じて。入社後のギャップを最小限にできそうだという直感もありました。
◆ ⑦ 社内SEとしての働き方（After）
Q. 現在の業務内容を教えてください
バックエンドAPIの設計と開発が中心です。GoでREST/GraphQL APIを構築しながら、インフラ側ではAWSのECSやLambdaを使ったサーバーレス構成の整備も担っています。データベースはAurora（PostgreSQL互換）で、パフォーマンスチューニングやスキーマ設計にもしっかり関われています。
テックリード的な立ち位置として、技術選定の提案や新機能の設計レビューにも携わっており、コードを書きながら設計に責任を持つ役割です。
Q. 働き方はどのように変わりましたか？
一番変わったのは、技術に向き合う時間の密度です。前職の後半は、会議や調整で1日の半分以上が埋まることもありましたが、今は開発に集中できる時間がしっかり確保されています。
裁量も大きくて、「この技術を使ってみたい」という提案が通りやすい。技術的判断を自分でできることで、仕事の納得感がまったく違います。
Q. 転職して感じた変化は？
「技術者として生きている」という実感が戻ってきました。コードを書きながら設計を考え、それがプロダクトに反映されていく――そのサイクルを日々感じられることが、一番大きな変化だと思います。
出世しているかどうかではなく、自分が納得できる仕事をできているかどうか。そこが充実感の源だと、転職してから改めて確認できました。
「出世」ではなく「納得感」を軸にした選択が、技術者としての充実を取り戻してくれた。
◆ ⑧ 社内SEのリアル（メリット・デメリット）
Q. 社内SEのメリットは？
プロダクトへの継続的な関与と、技術選定に主体的に関われることです。SIerや受託開発と違い、リリース後の運用や改善も自分ごととして追えるので、技術的な判断の積み重ねが見えやすい。
「自分が選んだ技術がプロダクトを支えている」という実感が持てるのは、社内SE特有のやりがいだと思います。裁量があるぶん、技術的な責任感も大きくなりますが、それが自分には合っていました。
Q. 一方で大変な点は？
技術選定の責任を自分で持つということは、外れたときのリカバリーも自分でやらなければならないということです。「なぜこの技術を選んだのか」を常に説明できる状態を保つ必要があるし、自己研鑽を怠ると陳腐化が怖い。
また、会社によっては技術的な議論の相手が限られることもあるので、社外コミュニティへの参加やインプットを自分で積極的に続けることも大切です。
◆ ⑨ 今後のキャリア
Q. 今後どのようなキャリアを考えていますか？
テックリードとして、技術的な意思決定と設計に責任を持つポジションをさらに深めたいと考えています。将来的にはアーキテクトとして、組織全体のシステム設計に関われるようになりたい。
マネジメントに「まったく興味がない」というわけではないですが、少なくとも今は技術を深めることに専念したい。それが自分にとって一番誠実な選択だと思っています。
◆ ⑩ 読者へのメッセージ
Q. 同じように悩んでいる方へ一言お願いします
「マネジメントに進まないと評価されない」「技術者としてのキャリアに限界がある」という思い込みは、一度外してみてほしいと思います。技術を続ける道は確かにあるし、そのための環境も存在します。
大事なのは、自分の軸をちゃんと持ってキャリアを選ぶことだと思います。周りの期待や「普通のキャリア」に引っ張られるのではなく、「自分が何をしているときに一番充実しているか」を問い続けてほしい。
技術が好きで、技術で価値を出したいなら、その気持ちに正直に選択してほしいと思います。
編集後記
小林さんのストーリーが示してくれるのは、「出世＝正解」という前提を疑うことの大切さだ。技術職のキャリアにおいて、マネジメントへの移行はいつしか『当然の流れ』として語られることが多い。しかし、小林さんのように技術を深めることに幸福感を見出すエンジニアにとって、その前提は必ずしも正解ではない。
社内SEという選択肢は、「技術を続ける道」として有力な選択肢の一つだ。企業の技術文化によっては、設計・技術選定・アーキテクチャまで深く関われる環境が確かに存在する。キャリアに悩む技術志向のエンジニアにとって、この記事が「もう一つの選択肢」を考えるきっかけになれば幸いだ。
社内SEへの転職を検討中の方へ社内SE転職ナビでは、働き方・技術環境・キャリアの3軸で企業をマッチングするサポートを行っています。転職を決意していない段階でも、無料でご相談いただけます。
＼無料キャリア相談はこちら／
※本記事は実際の転職者へのインタビューをもとに構成したものです。プライバシー保護のため、氏名・年齢・企業情報等は一部変更しています。
