「受託で積んだ経験は、そのまま通用するのかな?」
「経験が足りないと言われても、次に何をすればいいのか」
そんな手詰まりを感じている、受託や常駐で年数を重ねてきたあなたへ。
結論から言えば、
難しさの多くは経歴の中身ではなく、書き出す欄の側にありました
同じ案件でも、工程で書くか決定で書くかで読まれ方が変わります。
この記事では、要件定義の議事録と権限申請のワークフローに沿って、そのまま通る経験と、翻訳が要る経験をやさしく仕分けます。
結論 — 難しさの多くは、経歴の中身ではなく翻訳の側にある
受託や常駐で積んだ経験が、社内SEの選考で通用しないわけではありません。通用しない形のまま出しているだけ、という状態が多くありました。
受託側の職務経歴書は、工程と技術で書きます。担当工程、言語、規模、期間。読み手が同じ受託側であれば、これで力量が伝わります。
社内側の読み手が見たいのは、その手前にあります。誰と決めたか、決めた後どう動かし続けたか。同じプロジェクトの話でも、書き出す欄が違います。
ですから最初にやることは、経験を増やすことではありません。手持ちの案件を、決定と運用の側から書き直せるかを確かめることになります。
この記事で扱うのは「どうすれば受かるか」ではありません。あなたの経験のどこがそのまま持ち込めて、どこが翻訳を要するのかを分けるための分解になります。
「難しい」が指している対象を3つに分ける
難しさの中身を並べると、次の3つに割れました。手前から効いてくる順ではなく、対処のしやすい順に並べています。
この順番にしたのは、上から順に着手すると、下の壁に手を出す前に判断がつくからです。逆から入ると、動かないものを最初に見ることになります。
- 壁1 見せ方：経歴の書き方と、選考で出す材料。今日から変えられる範囲がここに集まっています
- 壁2 実務の中身：求められる仕事が受託側と別の軸で組まれています。現職で一部だけ埋められます
- 壁3 席の構造：そもそも枠の数と空き方が違います。個人の努力では動きません
「難しい」と語られるとき、多くは壁3の話として語られます。ですが手を入れられるのは1と2で、しかも1は着手から反映までが最も速い場所です。
壁3（席の構造）だけ先に片づけておく
枠の数の差は、公的な統計で確かめられます。厚生労働省の job tag（職業情報提供サイト）は、開発を受託する側と、社内のシステムを運用・管理する側を、別の職業として立てています。
就業者数は、システムエンジニア（受託開発）が 389,760人、運用・管理（IT）が 207,400人（いずれも令和2年（2020年）国勢調査の結果を job tag が加工した値。2026年8月13日 取得）。
平均年齢は前者が 37.1歳、後者が 42.2歳（令和7年賃金構造基本統計調査の結果を job tag が加工した値。同日取得）。
この2つの数字が示しているのは、移動先の母数が小さく、在籍者の入れ替わりも起きにくい方向への移動だ、ということです。競争率が高いと語られる状態には、構造の裏づけがあります。
ここから先、壁3には触れません。動かせないものに時間を使わないためです。
求められる実務を、受託側の経験から分解する
壁2は、職種名が同じでも担う位置が入れ替わる部分にあたります。実務の単位で切ると4つになり、受託・常駐の側にあった役割との差はそれぞれ違います。
1. 要件を「受ける」側から「出す」側に回る
受託側で要件定義に入っていたとしても、座っていた席は要件を受け取る側でした。持ち帰って実現方法を設計し、できる・できないを返します。
社内側は、その反対側に座ります。業務部門の担当者から「今の運用が回らない」という状態の話を聞き、それを要件の形に変換するところからが仕事になります。
残る書類も変わります。要件定義の議事録の決定欄、RFP、ベンダー選定の評価表。実現方法ではなく、選んだ理由が残ります。
受託側の経験がここで効かないわけではありません。むしろ「その要件は実装すると何が起きるか」を知っている側は強い場所でした。
ただし、その強さは職務経歴書の工程欄には出てきません。個人の経験に基づく記述であり、同じ結果を保証するものではありません。
2. 作って終わりではなく、動かし続ける前提で設計する
受託の契約は、検収で一区切りが入ります。保守は別契約で、範囲も金額も切り分けられています。
社内側にはその線がありません。導入したものは、そのまま自分たちが動かし続ける対象になります。
ここが効くのは選考より後です。移った後、あなたが入れた仕組みの当番表に、あなたの名前が載ります。設計時の判断が、そのまま自分の当番の重さになって返ってきます。
この観点を持っている受託側の人は多くありません。持っている場合でも、それが経歴書に書けていないことが多くあります。運用側からの差し戻しを受けた経験は、書けば1行になります。
3. 費用の説明が仕事の一部になる
構成が固まっても、それだけでは物は動きません。稟議、見積の比較表、年度予算の枠、費用対効果の説明資料が後ろに控えています。
受託側では、この部分は営業と管理職の仕事として分離されていることが多いです。社内側では、担当者が自分で書く場面が出てきます。
面倒なのは、決裁の単位が技術の単位と一致しないことです。年度をまたぐと枠が変わり、同じ構成でも通る時期と通らない時期があります。
受託側にいても、見積の根拠を作った経験や、他社構成と比べた資料を書いた経験があれば材料になります。営業が持っていった資料の中身を書いたのがあなたなら、それはあなたの経験として書けます。
4. 独立した仕事としての、守りの実務
アカウントの棚卸し表、権限申請のワークフロー、資産管理台帳、監査への証跡提出。受託側から見えにくいのがこの領域です。
作る仕事でも止めない仕事でもなく、説明できる状態を維持する仕事として独立しています。期末や監査の時期に稼働が寄る性質もあります。
ここは経験の有無がはっきり分かれます。無い場合、選考で埋めることはできません。現職で触れる範囲があるなら、そこを触っておく価値があります。
自分の経歴のどこが読み替えられるかを判定する
受託・常駐の経験のうち、翻訳すればそのまま通るものと、経験そのものが無いものを分けます。次の観点で切れます。
- 要件定義で、顧客側の担当者と直接やり取りした場面があるか（あるなら1は翻訳で通ります）
- 自分が書いた設計に対して、運用側から差し戻しを受けた経験があるか（あるなら2の入口に立っています）
- ベンダーや外注の選定に、評価する側として関わったことがあるか（あるなら3の材料になります）
- 権限申請・アカウント管理・監査対応に触れた範囲があるか（無い場合、4は現職で埋めるしかありません）
- あなたが直近で書いた資料のうち、社外の人が読んでも意味が通るものはどれか（社内用語だけの資料しか無い場合、見せ方の問題が残っています）
4つ目だけが「経験の有無」を聞いています。残りは「経験の書き方」を聞いています。
難しいと感じている理由が上の1〜3に集まっているなら、それは翻訳の問題で、着手から反映までが速い場所です。
観点に当てはめる材料がそもそも出てこない場合は、翻訳より手前が空いています。何を並べれば外から読める形になるのかを、棚卸しの単位から扱っています。手が止まっている方には、そちらの記事が入口になります。
個人の努力では動かせないのは、どこまでか
変えられないのは2つです。席の数と入れ替わりの少なさは統計に表れている構造で、個人では動きません。もう1つは守りの実務の経験が今この瞬間に無いという事実で、選考の場では作れません。
変えられない側に理由が集まっているなら、社内SE以外も含めて選択肢を並べ直す話になります。守りの実務の経験は、面談の場で作り出せるものではありません。
変わりうる側に集まっているなら、動く前にやることが残っています。順番を逆にすると、材料が揃わないまま面談に入ることになります。
この2つは同時に進めるものでもありません。経歴書の書き直しは数日で終わりますが、現職で経験を足すほうは期の区切りに依存します。先に終わるほうから片づけたほうが、判断が早く出ます。
2と4は、いまの案件の中で埋まる
上の4つのうち、この2つは現職で一部を埋められます。手前のものから並べます。
- 担当している案件の運用設計書と監視項目の一覧を、自分の手で1本書く。既にある場合は差分の更新を引き受ける
- 設計レビューで運用側から出た指摘を、自分の名前で議事録に残す。口頭で終わらせない
- 職務経歴書を、工程と技術の欄ではなく「決めたこと・動かし続けたこと」の欄で1枚書き直す
- 権限申請とアカウント棚卸しの作業に、期の途中で1度入れてもらう。範囲は小さくてよい
- 保守の問い合わせ窓口に、期間を区切って入る。受ける側の書き方が分かると、渡す側の書き方も変わる
- ベンダーの見積を読む側に回れるか聞く。金額の根拠を並べた資料が、決定の記録として残る
書き直しても埋まらないなら、壁2にあたる実務の経験そのものが足りていません。この場合は、現職で埋める期間を先に取るほうが早く進みます。
移れるかどうかの見通しが立ったとして、次に来るのは報酬の側の問いになります。移動で入れ替わるのは給与のどの行かを、支給の名目ごとに特定しています。金額の内訳まで踏み込んだ1本ですので、そのまま読み進めてみてください。
相談の前に読むのは、対象と面談までの流れ
翻訳の作業には終わりがあります。書き直した1枚が手元に出た時点で、次は相手側の公表内容を読む段になります。
読む順は流れが先で構いません。希望条件を書く工程が申し込みと同じ日に来るのか、後から来るのかで、手元に置いておくものが変わるからです。
その次が対象です。ここは交渉の余地がある欄ではないので、外れていれば話は最初で止まります。扱う地域を限る記述は、両社の公式サイトには見当たりませんでした。
その2欄だけを並べます。
| 項目 | 社内SE転職ナビ | レバテックキャリア |
|---|---|---|
| 面談までの流れ | 無料登録 → 求人検索・応募またはスカウト受信 → 面接・面談 | Webで申し込み → 希望条件の入力 → 面談・求人紹介 |
| 対象 | 自社の中で働きたいITエンジニア（社内SE・情報システム職） | ITエンジニアとデザイナー（IT・Web業界に特化） |
表に入れたのは公式サイトの記載そのもので、当サイトが確かめた結果ではありません。
対象の欄にある職種の内側で、どこまでの経歴が読み替えの対象になるかは公表されていません。そこは面談で確かめる部分になります。
どちらも相談の窓口ではなく、面談へ進む人を前提に置かれています。
当サイトの評価軸に基づく整理であり、客観的な優劣を示すものではありません。評価軸は広告掲載方針に記載しています。
向いている人／向いていない人
筆者は本サービスの利用者ではありません。以下は各社の公表情報と、SE・社内SE としての実務経験からの整理です。
翻訳が一度通った後なら、社内SE転職ナビと話がかみ合います。対象として掲げられているのは社内SE・情報システム職です。そこを外した方向まで一緒に見たい人には窓が狭くなります。
翻訳が終わっていない段階で当たると、経歴の材料を出せないまま話だけが進みます。
レバテックキャリアは、社内側に絞りきらず開発側の枝も残したい場合に向きます。経験の前提がエンジニア・クリエイターに置かれているため、書き直した1枚が無いと中身が伝わりにくくなります。
席に着いてから決めることと、着く前に決めておくことがあります。翻訳で片づくのか、経験の側が薄いのか——この一つは手前で片がつきます。片をつけて座った人は最初の数分を求人の話に使い、つけずに座った人は同じ数分を経歴の読み上げに使います。
持っていくものは1つ、書き直した経歴書で足ります。それが外の読み方でどう受け取られるかは、読み手のいる場所でしか分かりません。
希望条件の入力は、申し込みの次の工程として置かれています。書き直した1枚を手元に開いたまま進めたほうが、写す手間が一度で済みます。
まとめ — 「難しい」を実力不足と読み替えると、手が止まる
ここまで分けてきた3つのうち、最も取り違えやすいのは入口のところです。
「社内SEへの転職は難しい」と聞くと、あなたはたいてい自分の実力を疑うほうへ向かいます。
ですが上で分けたとおり、難しさの中身は見せ方・実務の中身・席の構造の3つに分かれていました。実力という一語で束ねられるものは、このうちどれでもありません。
見せ方は書き方の問題で、数日で動きます。実務の中身は経験の問題で、現職で期間を取れば埋まる部分が残っています。席の構造は個人では動きません。
3つは片づく速さが違うので、束ねた瞬間にどれから手を付ければよいか分からなくなります。
実力不足と読み替えると、次にやることが「勉強する」に寄っていきます。ですが上の3つのうち、その一語で動くものは含まれていません。