SIerから社内SEへ転職する前に｜発注側に回った僕が見た評価される経験

SIerから社内SEへ転職するなら、SIerで身につけた「作る側の知識」を発注側でどう使えるかを、言葉にしておくのが一番の準備です。社内SEの仕事では、社内のユーザーとベンダーの間に立って、双方の話を相手に伝わる形に翻訳する場面が多いからです。社内SEに移れば楽になるとは限らない点も、先に知っておくと入ってからの戸惑いが減ります。

書いている僕は、2009年に新卒でSIerに入り、2016年にフリーランスのエンジニアとして独立しました。.NETを中心に、業務系のシステムを作ってきました。2025年4月からは、ある現場で情シス（情報システム部門）の立場に入っています。担当は要件定義からベンダーコントロール・受入テスト・リリースまでです。

ただし、僕は社員として社内SEに転職したわけではありません。転職はしておらず、フリーランスのまま業務委託で発注側の立場に入っています。 だからこの記事で書けるのは「社内SEに転職した体験」ではありません。「発注側に立ってみて、SIerの経験がどこで活きたか」です。転職活動の一般的な進め方は、公的な資料と各社の公式情報をもとに整理します。

社内SEの求人を探すエージェントは、SIerの転職エージェントの選び方で行き先別に比べています。

発注側で評価されるのは「作る側の知識で翻訳できる」こと

SIerから社内SEに移ったとき、発注側で評価されやすいのは、作る側の知識を使ってユーザーとベンダーの間を翻訳できることです。社内SEは、自分ですべてを作るよりも、社内の要望をまとめてベンダーに頼み、できあがったものを確かめる場面が多い仕事だからです。

2025年4月から情シスの立場で働いている

僕は2025年4月から、フリーランスとして情シスの立場で働いています。大きなシステムは開発をベンダーに任せています。僕が担当しているのは、その要件定義からベンダーコントロール、受入テスト〜リリースまでです。関連するサブシステムは、内製で開発することもあります。

2025年4月にいまの現場へ移ったのは、上流工程の経験を増やしたかったからです。その前の2024年から入っていた現場も、上流工程やリーダーの経験をしたくて選びました。

念のため書いておくと、社員として雇われているわけではありません。仕事で関わる人から「うちの会社入っちゃえばいいのに」と言われたことはありますが、社員になることは考えていません。社員の社内SEと業務委託で情シスに入る働き方の違いは、社内SEの仕事をフリーランスで受ける働き方で詳しく書きました。

ユーザーとベンダーの間を翻訳する

発注側に回ってみて大切だと感じているのは、ユーザーとベンダーの間をただ横流しせず、仕事がしやすいように翻訳することです。立ち位置は、ユーザーとベンダーの中間管理職のようなものです。

翻訳は、どちら向きにもあります。ユーザーの要望をベンダーへ渡すときは、ベンダーが作れる形にして渡します。ベンダーの説明をユーザーへ返すときは、業務の言葉に置き換えて伝えます。ただ横流しすると、昔つらかった伝言ゲームの一段に自分がなってしまう。そんな感覚があります。

ここでSIerの経験が活きます。僕はキャリアの初めがベンダー側だったので、発注側と受注側のどちらの目線にも立てるのは良かったと感じています。

翻訳の中身を具体的にすると、一般的には次のような仕事です。

• ユーザーの要望から、決めなければいけない仕様を洗い出す
• 「なぜそれが必要か」という業務上の理由を添えて、ベンダーに伝える
• ベンダーが挙げた制約やリスクを、業務への影響に置き換えてユーザーに説明する
• 決まったことと決まっていないことを、双方が同じ認識で持てるように残す

どれも、システムを作る流れを知っている人ほど進めやすい仕事です。SIerで顧客の要望を聞いて仕様にまとめてきた人なら、その経験がそのまま発注側の翻訳に使えます。

見積もりと仕様の妥当性が分かる

SIerで見積もりや設計をしてきた経験は、発注側ではベンダーの見積もりや仕様が妥当かを判断する力として評価されやすい経験です。

発注側には、ベンダーから見積もりや設計書、修正の提案が届きます。作った経験がないと、工数が多いのか少ないのか、仕様に抜けがないのかを判断しにくいものです。SIerで見積もりや設計に関わってきた人なら、「この機能でこの工数は妥当か」「この設計だと業務で困る場面はないか」と当たりを付けられます。

ベンダーコントロールでは、次のような点を確かめるのが一般的です。

• 見積もりの前提（作る範囲・工数・体制）が要件と合っているか
• 仕様書に、業務で起きるパターンが漏れていないか
• テストの範囲と、完了とみなす基準が決まっているか
• 進み具合と課題が、定期的に共有されているか

工程ごとの中身と、受注側から見たときとの違いはベンダーコントロールとはにまとめています。

社内SEの面接では、こうした見積もりの査定や仕様のレビューに関わった経験は、具体的な場面として話しやすい材料になります。SIer側で見積もりを作った経験も、裏返せば「査定する目」として伝えられます。

ベンダーの事情が分かる

ベンダー側の事情が分かることも、SIer出身者が発注側で活かしやすい強みです。納期の前に何が起きやすいか、仕様変更が後から入ると何が大変か。SIerにいた人は、それを身をもって知っています。

事情が分かっていれば、仕様変更はできるだけ早く伝える、優先順位をはっきりさせて渡す、といった配慮ができます。ベンダーが動きやすくなれば、結果として自社のシステムの品質や納期も守りやすくなります。

人とのやりとりの面でも、受注側の経験は役に立ちます。僕は以前、いつもすごく怒っているユーザーとやりとりしたこともありました。その経験もあって、受注側・発注側のどちらの立場でも、感情的にならずに仕事をしようと思っています。

一方で、ベンダーの事情に寄りすぎると、社内の要望を通せなくなることもあると言われます。どちらの事情も分かったうえで、自社に必要なことははっきり伝える。発注側には、そのバランスが求められます。

SIerと社内SEの違い

SIerと社内SEの一番の違いは、SIerがシステムを「作る側（受注側）」で、社内SEが「頼む側（発注側）」だということです。働き方や年収、キャリアパスの違いも、この立場の違いから生まれます。

表は一般的な傾向です。実際の仕事の範囲は、会社の規模や情シスの体制によって変わります。

作る側と頼む側

SIerは、顧客から開発を請け負い、設計・開発・テストを担う作る側です。プロジェクトが終われば、次の顧客や次の案件へ移るのが一般的です。

社内SEは、自社のシステムを企画し、必要に応じてベンダーに開発を頼む側です。作ったあとの運用まで、同じシステムと長く付き合います。会社によっては、社内のヘルプデスクやPC・アカウントの管理、セキュリティ対策まで仕事に含まれます。

社内SEになると、コードを書く機会がまったくなくなるとは限りません。僕のいまの立場でも、関連するサブシステムは内製で開発することがあります。どこまで自分で作るかは会社によって違うので、求人票と面接で確かめておきたいところです。

働き方と残業

働き方では、社内SEは客先常駐が無く、納期も社内で調整しやすいぶん、働き方が安定しやすいと言われます。一方で、システムの入れ替えや障害が起きたとき、決算などの繁忙期には忙しくなることもあります。

残業の多さは、SIerか社内SEかだけで決まるものではありません。会社や案件、本人の働き方でも変わります。僕はSIerにいたころ、仕事終わりや土日の時間を大切にしたかったので、他の人より早く帰っていました。

社内SEへの転職で働き方を良くしたいなら、次の点を求人票と面接で確かめておくのがおすすめです。

• 月の平均残業時間と、繁忙期の時期
• システム障害が起きたときの対応（夜間・休日の当番があるか）
• 情シスの人数と、外部のベンダーに任せている範囲
• リモートで働けるか、出社が前提か

年収とキャリアパス

社内SEの年収は、移る先の会社の給与水準で決まります。SIerより上がるか下がるかは、業界や会社の規模によって変わるので一概には言えません。気になる求人の年収は、求人票とエージェントへの相談で、同じ業界・同じ規模の会社と比べて確かめるのが確実です。

キャリアパスは、情シスの中で管理職を目指す道や、IT企画・DX推進のように事業に近い仕事へ広げる道が一般的です。社内SEで業務知識を深めたあと、その業界に強いITコンサルへ進む人もいます。

一方で、技術の幅は広く浅くなりやすいとも言われます。手を動かす開発を続けたい人は、社内で内製をしている会社かどうかを見ておくと、入ってからのずれが小さくなります。

SIerから社内SEへの転職が難しいと言われる理由

SIerから社内SEへの転職が難しいと言われるのは、求人の数に対して希望する人が多いことと、求められるスキルがSIerの開発経験とずれることがあるからです。

求人が少なく倍率が高い

日本では、IT人材の多くがIT企業に所属していて、事業会社のIT部門で働く人は相対的に少ない構造です。IPA（情報処理推進機構）の「DX白書2021」第3部では、日本で情報処理・通信に携わる人材のうちIT企業に所属する割合は72%で、日本以外の国ではIT企業以外に所属する割合が5割を超えているとしています。同じ資料の推計では、IT企業のIT人材が約101万人なのに対し、事業会社のIT人材は約34万人です。

事業会社の情シスは1社あたりの人数が少ないことが多く、求人は欠員の補充や増員のときに出るのが一般的です。そこに「働き方が安定していそう」というイメージで希望する人が集まるので、人気の求人ほど競争が激しくなりやすいとされています。

求人の少なさへの対策としては、次のような方法があります。

• 一度で決めようとせず、数か月かけて求人を見続ける
• 公開されていない求人を持つ転職エージェントにも相談する
• いままで関わってきた業界の事業会社から探す（業務知識がそのまま活きる）

求められるスキルのずれ

社内SEの求人が求めるのは、開発の深さよりも、業務の理解・社内の調整・ベンダー管理・インフラやセキュリティまでの幅広い知識であることが多いです。SIerでプログラミングや詳細設計が中心だった人は、ここで求人とのずれが出やすくなります。

ただ、開発中心の経験でも、言い換えれば発注側で使える経験は見つかります。たとえば次のような経験です。

• 顧客の要望を聞いて、仕様にまとめた
• 協力会社に作業を頼み、進み具合を管理した
• 障害が起きたとき、顧客に原因と影響を説明した
• テストのパターンを洗い出し、品質を確かめた

面談する側の視点も書いておきます。僕は業務委託のエンジニアを受け入れる面談に、面談する側として入ることがあります（正社員の採用面接には関わったことがありません）。スキルシートでは、まずスキルが現場に合っているかを見ます。合っていなくても、それでもいいと思える観点があれば大丈夫です。

これは業務委託の面談での話で、正社員の採用でも同じとは限りません。それでも、求人と合わない部分を別の経験で補えると示す材料として、上のような言い換えを用意しておくのは一つの手です。

社内SEに移って楽になるとは限らない

社内SEに移れば楽になる、とは限りません。僕自身、いまの立場に入る直前は、発注側はただ指示するだけで楽だと思っていました。実際は、思っていたより大変です。

指示するだけでは終わらない

発注側の仕事は、ベンダーに指示して終わりではありません。何を作るかを決める責任と、できあがったものが業務で使えるかを確かめる責任は、発注側に残ります。

僕の場合、ベンダーが出してきた修正の受入テストは、業務の観点でパターンをかなり洗い出してガッツリやっています。ユーザーの要望をまとめ、ベンダーと調整し、できあがったものを確かめる。そこまでが発注側の仕事です。

社内SEの仕事として一般的に挙げられるのは、ほかにも次のようなことです。

• 社内から上がる要望の優先順位をつける
• システムの予算を立て、費用の妥当性を説明する
• ベンダーとの契約や、保守の範囲を決める

「頼む側だから楽」と考えて社内SEを選ぶと、入ってから想像との差に戸惑うかもしれません。

何でも屋になりやすい職場もある

情シスの人数が少ない会社では、社内SEが「何でも屋」になりやすいと言われます。システムの企画や開発の管理だけでなく、PCの設定やアカウントの管理、社内からの問い合わせ対応、セキュリティ対策までを少人数で受け持つこともあります。

これを幅広い経験と取るか、開発から離れた雑務と取るかで、向き不向きが分かれます。入ってから困らないように、面接では次のような点を聞いておくと安心です。

• 情シスの人数と、それぞれの担当の分け方
• ヘルプデスクやPCの管理を誰がしているか（外部に任せているか）
• 入社後に最初に任される仕事は何か

SIerから社内SEに転職するための準備

SIerから社内SEに転職するための準備は、志望動機を組み立てること、職務経歴書で経験を伝えること、社内SEの求人に強いエージェントを使うことの3つです。

志望動機の組み立て方

社内SEの志望動機は、「SIerでしてきたこと → その経験が発注側でどう活きるか → 入社後にやりたいこと」の順で組み立てると伝わりやすくなります。

1. SIerでしてきたこと：担当した業界・工程・役割を、具体的に書く
2. 発注側で活きる点：その経験が、ユーザーとベンダーの間に立つ仕事でどう使えるかを書く
3. 入社後にやりたいこと：その会社の事業やシステムに、どう関わりたいかを書く

避けたいのは、「残業が少なそうだから」「客先常駐がないから」といった理由だけで終わる志望動機です。本音として持っているのは自然なことですが、それだけでは「その会社でなくてもいいのでは」と受け取られやすくなります。

例として、組み立て方に沿った志望動機を1つ挙げておきます（架空の例です）。

SIerで製造業向けの生産管理システムの開発に携わり、後半は要件定義と協力会社の進捗管理を担当してきました。顧客の要望を仕様にまとめるなかで、作る側の都合と使う側の業務の両方を見ることの大切さを学びました。今後は一つの事業に長く関わり、利用部門とベンダーの間に立って、業務に合ったシステムを企画する立場で力を発揮したいと考え、貴社を志望しました。

職務経歴書で伝える経験

職務経歴書では、発注側で使える経験が読み取れるように書くのがポイントです。社内SEの選考で見られやすいのは、次のような項目です。

• どの業界の、どんな業務のシステムに関わったか
• 担当した工程（要件定義・設計・開発・テスト・運用）
• 役割（メンバー・リーダー・顧客との窓口など）
• 顧客や協力会社との調整、見積もり、進捗管理の経験

僕が書いてきたのは、転職用の職務経歴書ではなく、業務委託の案件に応募するときの経歴書です。そこに、途中からその案件での「習得スキル」と「意識したこと」を書くようにしました。面談でも、ただ業務経歴を説明するだけでなく、自分が意識したことなどのプラスアルファを話すようになっています。

「何をしたか」に「どう考えたか」が添えてあると、発注側でどう動く人なのかが伝わりやすくなります。社内SEの職務経歴書でも、調整や判断をした場面に一言添えておくのがおすすめです。

社内SEの求人に強いエージェントを使う

社内SEの求人を探すなら、社内SEに特化したエージェントとIT業界を広く扱うエージェントを組み合わせて使うのが効率的です。

社内SEに特化しているのは、アイムファクトリー株式会社が運営する社内SE転職ナビです。社内SE・情シスの転職に特化したサービスで、カウンセリングから企業の紹介、入社が決まるまでのサービスはすべて無料です。

IT業界を広く扱うエージェントでは、レバテックキャリアがあります。公式サイトによると、カウンセリングは1〜1.5時間で、電話やオンラインでも受けられます。求人の紹介のあとは、書類の添削や企業ごとの面接対策、内定後の年収交渉・入社日の調整までサポートしてもらえます。転職をまだ検討している段階でも相談できます。

先に書いたとおり、僕は転職をしていないので、どちらのエージェントも使ったことはありません。行き先別の比べ方や、登録する社数の考え方はSIerの転職エージェントの選び方にまとめています。

まとめ：SIerの経験は発注側で「翻訳する力」になる

SIerから社内SEへの転職で評価されやすいのは、作る側の知識を使って、ユーザーとベンダーの間を翻訳できることです。見積もりや仕様の妥当性が分かること、ベンダーの事情が分かることも、発注側では強みになります。

一方で、社内SEに移れば楽になるとは限りません。求人は少なく、求められるスキルが開発とずれることもあります。発注側は指示するだけでは終わらず、職場によっては何でも屋になることもあります。

発注側に立ってみて、SIerで受注側を経験してきたことは良かったと僕は感じています。社内SEを目指すなら、その経験を「発注側でどう活きるか」まで言葉にしてから、志望動機と職務経歴書に落としてください。

SIerからの転職先を社内SE以外も含めて比べたい人はSIerからの転職先と進め方を、辞めるかどうかから迷っている人はSIerを辞めたいときの判断基準を参考にしてください。SIerにいた当時のことはSIerはやめとけと言われる理由にまとめています。転職と独立のどちらが合うか分からない人は、キャリア診断で方向を確かめてから比べるのもおすすめです。