メーカー系IT子会社から外に出たい。親会社の仕事しか知らなくても大丈夫？

たとえば、電子部品メーカーの情報システム子会社に勤めて 10 年、親会社の生産管理システムの保守と改修を担当してきた人がいるとします（架空の例です）。依頼はほぼすべて親会社から来ていて、ほかの会社のシステムに関わったことはありません。このまま親会社のことしか知らない状態でいいのか、転職して通用するのかと不安になっています。

結論から言うと、親会社向けの経験だけでも転職はできます。 求人の応募資格は、「IT子会社にいたかどうか」をほとんど問いません。問うのは、要件定義、運用保守、パッケージ導入、製造業の業務知識といった仕事の中身で、親会社向けに積んだ経験もこの言葉で書けます。当サイト PREVIO の掲載求人（2026 年 11 月 4 日時点、応募資格の欄、会社単位）では、IT 子会社を名指す会社は社内SE・ITコンサル・SE や開発のどの職種でも 1% 未満でした。

転職先で問われやすいのは、むしろ別の経験です。SIer や自社開発など IT 業界の会社の SE・開発なら、自分でコードを書いた経験。ITコンサルなら、社外の顧客に提案や折衝をした経験です。この 2 つのどちらを自分が持っているかで、狙いやすい転職先が変わります。

求人は「IT子会社出身か」をほとんど問わない

当サイトの掲載求人のうち、2026 年 11 月 4 日に掲載中だった求人の応募資格を、転職先の職種ごとに会社単位で数えました（その会社の求人のどれか 1 件にでも語があれば 1 社と数え、割合は 5% 単位に丸めています）。「IT子会社」「情報システム子会社」「ユーザー系」を応募資格で名指す会社は、他社の社内SE、ITコンサル、IT 業界の会社の SE・開発、IT 以外の会社の SE・開発の、どの職種でも 1% 未満です。

名指している少数の求人では、IT 子会社は SIer や IT ベンダーと同じ並びに置かれています。たとえば ITコンサルの求人に「大手企業グループIT子会社でのSE/PM/PMO経験」と書くものがあり、これは SIer での SE・PM 経験や、事業会社のシステム部門での経験と並んで、どれか 1 つを満たせばよい条件の 1 つです。名指している求人をすべて読むと、多くが IT 子会社を SIer や IT ベンダーと同じ行に並べ、システムを作る側の経験の 1 つとして挙げています。名指す求人は金融・保険の業界が中心で、製造業の IT 子会社を名指す求人は見当たりませんでした。

「社内システムの開発・保守・運用経験のみは不可」「自社内プロジェクトの経験のみは不可」のように、社内向けの経験だけでは応募できないと書く求人もありますが、どの転職先でも 1% 未満の会社です。親会社向けの仕事がこの「社内向け」に当たるかは、求人の文面からは決まりません。同じようにはっきりしないのが、社内SE の求人にある、事業会社の情報システム部門での経験という条件です。親会社とは別会社である IT 子会社の経験がこれに含まれるかは、求人の文面からは分かりません。気になる求人では、面接で直接確かめるのが確実です。

転職先ごとに、生かせる経験と不足しやすい経験

転職先を 4 つの職種に分けると、親会社向けの経験の生かし方の違いが見えてきます。下の表の数字は、当サイトの掲載求人で、その語を応募資格に書く会社の割合です（2026 年 11 月 4 日、会社単位、5% 単位）。

転職先	応募資格によく出る経験	生かせる経験	不足しやすい経験
他社の社内SE	事業会社・情シス・社内SE での経験約 45%	親会社の基幹システムや生産管理システムの開発・保守	PC の管理やアカウント管理が中心の求人では、業務システムの経験が使いにくい
ITコンサル	顧客折衝・提案・営業経験約 45%	要件定義、パッケージ導入、製造業の業務知識	社外の顧客への提案・折衝
IT 業界の会社の SE・開発（SIer・自社開発など）	言語・実装・プログラミング約 70%	自分で設計・実装してきた経験	親会社で使っていなかった技術
IT 以外の会社の SE・開発（メーカーの事業部など）	言語・実装・プログラミング約 60%	実装の経験と製造業の業務知識	実装の経験が無い場合は、IT 業界の会社と同じく不足になる

製造業の業務知識をもっとも具体的に求めるのは ITコンサルです。当サイトの掲載求人では、ITコンサルの会社の約 20% が製造業・生産管理・SCM などの語を、約 30% がパッケージ・ERP・SAP の語を、約 40% が「要件定義」の語を応募資格に書いています（2026 年 11 月 4 日、会社単位）。「製造業での情報システム部門に在籍された経験のある方」「製造業向けシステム導入経験5年以上」のように、製造業での経験を条件にはっきり書く求人もあります。製造業の語を書く会社は、IT 業界の会社の SE・開発では約 10%、IT 以外の会社の SE・開発では約 15% でした。

社内SE の求人は、業務システム中心とコーポレートIT 中心に分かれる

他社の社内SE を狙う場合、いちばん差が出るのは、その求人が業務システムの仕事か、社内の PC やアカウントを管理する仕事かです。当サイトの掲載求人の社内SE では、応募資格に基幹システム・ERP・生産管理・販売管理・要件定義・パッケージといった業務システムの語を書く会社が約 30%、キッティング・ヘルプデスク・Microsoft 365・SaaS の管理・アカウント管理といったコーポレートIT の語だけを書く会社も約 30% ありました（2026 年 11 月 4 日、応募資格の欄、会社単位）。

親会社の基幹システムや生産管理システムを作ってきた人なら、業務システム中心の求人で経験をそのまま生かせます。コーポレートIT 中心の求人では、子会社で親会社の PC やアカウントの管理まで担当していた場合を除き、これまでの仕事の中心とは違う仕事になります。どちらも職種名は同じ「社内SE」なので、応募資格と仕事内容にどんな語が並んでいるかで見分けます。応募資格にどちらの語も無い会社も約 40% あり、その場合は仕事内容の欄を読むか、面接で担当するシステムを聞くことになります。

職務経歴書は、担当したシステムと工程を具体的に書けば伝わる

親会社向けの経験をどう書けば伝わるかは、仕事の中身で変わります。大きな分かれ目は、自分で設計・実装してきたか、開発はベンダーに任せて要件定義と管理をしてきたかです。IT 子会社の SE がどちらの仕事をするかは会社によって違い、1 人の経歴に両方が混ざっていることもあります。

自分で設計・実装してきた人は、開発経験の条件を満たしやすい

SIer・自社開発など IT 業界の会社の SE・開発では、当サイトの掲載求人の約 70% の会社が、言語名・プログラミング・実装の経験を応募資格に書いています（2026 年 11 月 4 日、会社単位）。親会社のシステムを自分で書き、直してきた経験は、この条件を満たします。この割合は IT 業界の会社の SE・開発全体を、必須と歓迎を同じ欄として数えたもので、自社サービスの会社の必須の欄だけを数えた SIer から自社開発に移る時の記事の割合とは数えた範囲が違います。自社開発に移る時の応募資格の読み方は、そちらで詳しく扱っています。

保守だけの経験を外すと書く求人もあります。「※保守のみは不可」のような注記で、IT 業界の会社の SE・開発と IT 以外の会社の SE・開発にあり、どちらも 1% 未満の会社です（社内SE の求人では見当たりませんでした）。保守と改修を担当してきた人は、改修で自分が設計・実装した部分を、やった中身のまま書いておきます。改修が開発の経験として数えられるかは求人の文面からは決まらず、新規開発の経験を求めて機能改修だけの経験を外す求人もあります。

ただし、開発経験の条件を満たすのは応募の前提にすぎません。ほかの応募者より評価されるかどうかは、経歴書の書き方と、どの求人を選ぶかで変わります。AWS や Go のような個別の技術を必須にしているか、歓迎にとどめているかも求人ごとに違います。必須の条件に「実務経験○年」と年数まで書いてあれば、個人で触った経験では足りないと考えておいた方が安全です。業務で使った技術と個人で学んだ技術を分けて書けば、経験を盛ったことにはなりません。

COBOL やオンプレミスのような古い環境の経験も、隠さずに書いてかまいません。「生産管理システムの改修（主に Java、古い言語で書かれた部分の改修も含む）」のように、担当した仕事の中に使った言語の 1 つとして入れておけば自然です。書いておけば、面接で開発環境を聞かれた時にもそのまま話せます。古い環境の経験が選考でどう評価されるかは、今回は数えていません。

1 つの仕事も、分けて書くと伝わり方が変わります。「生産管理システムの保守・改修」なら、工場の担当者と仕様を詰めたのは要件定義、自分でプログラムを直したのは実装、チームをまとめたのはリーダーの経験です。それぞれについて、どんな相談を受け、自分が何をして、何が変わったかを 1 件ずつ書けば、どの条件を満たす経験なのかが読み手に伝わります。

要件定義とベンダー管理が中心の人は、社内SE と ITコンサルで経験を生かしやすい

コードはほとんど書かず、親会社の業務部門と要件を詰め、開発会社に発注して進捗と品質を管理し、受け入れテストをしてきた人は、業務システム中心の社内SE と ITコンサルで経験を生かしやすい人です。どちらの求人も、要件定義、パッケージ・ERP の導入、製造業の業務知識をはっきり条件に挙げるからです。職務経歴書は「調整と管理」とまとめず、「生産管理システムの更新で、工場の利用部門との要件定義、開発会社への発注と進捗・品質の管理、受け入れテストを担当」のように、システム・工程・相手を並べて書くと、求人の条件と同じ言葉になります。

当サイトの掲載求人では、ベンダー管理・ベンダーコントロールの語を応募資格に書く会社は、社内SE で約 15%、ITコンサルで約 10% でした（2026 年 11 月 4 日、会社単位）。一方で、「ベンダーコントロールのみの経験は不可」「ベンダーコントロールだけではなく、顧客折衝のご経験を重視」と書く求人もあります。数は少ないものの、ベンダー管理だけを並べた経歴書は、こうした求人では条件を満たさないと読まれます。

そこで伝えたいのは、ベンダー管理の中で自分が判断したことです。対応する範囲を決めた、優先度を決めた、受け入れテストで不具合を見つけてリリースを止めた、といったことです。たとえば、追加開発で「今回入れる機能」と「次の改修に回す機能」を分けたなら、要望をそのまま開発会社に渡したのではなく、自分で判断した仕事です。何を入れて何を外したか、なぜそう分けたか、誰に納得してもらったか。この 3 つを話せれば、「要望を取り次いでいただけ」とは受け取られません。

親会社の利用部門とのやりとりは「顧客折衝」と言い換えない

子会社から見れば、親会社の利用部門は顧客です。それでも職務経歴書では「顧客折衝」と言い換えず、「親会社の製造部門（利用部門）との要件調整、優先度と範囲の合意」のように、相手とやったことをそのまま書く方が安全です。

求人にある「顧客折衝」の条件に、親会社の利用部門とのやりとりが含まれるかどうかは、求人の文面からは分からず、判断するのは採用する側です。先に「顧客折衝」と書いてしまうと、面接で社外の顧客との場面を聞かれた時に答えに詰まります。事実のまま書いておけば、顧客折衝と認める会社にはそのまま伝わり、認めない会社にも経験を盛ったとは思われません。

それでも ITコンサルを狙うなら、社外の顧客に提案した経験が無いことは弱みとして残ります。当サイトの掲載求人では、ITコンサルの会社の約 45% が顧客折衝・提案・営業経験の語を応募資格に書いています。製造業やパッケージ導入の経験をはっきり条件にしている求人の方が、親会社向けの経験をそのまま生かせます。発注側の経験を持つ人が ITコンサルや PM・PMO に移る時の求人の書き方は、社内SEから転職する時の記事で詳しく比べています。そちらの記事の顧客折衝の割合は必須の欄だけを数えたもので、必須と歓迎を同じ欄として数えたこの記事の数字とは数えた範囲が違います。

年収は求人からは読めない。今の年収を下回るなら辞退すると先に決める

IT 子会社の給与が親会社に合わせて決まっているのか、転職すると上がるのか下がるのかは、確かめられる一次情報が見つからず、この記事では答えられません。求人に書かれているのは転職先が出す金額で、そこから今の会社の給与の決まり方は分からないからです。提示額が「450〜800万円」のように幅広い時、自分がその中のどこになるかも、求人の文面からは分かりません。

確かめるには、応募する前に「今の年収を下回るなら辞退する」と決めておき、面接やオファー面談で提示額とその根拠を直接聞くことです。年収が下がると転職できない事情がある人ほど、求人の金額から推測するより、直接聞いた方が確かです。社内SE の年収の目安は、社内SEの年収の記事にまとめています。

よくある質問

大手企業の IT 子会社はやめとけと言われるのはなぜ？

この記事は、IT 子会社で働き続けるかどうかではなく、転職する時の話をしています。転職する側から言えるのは、親会社向けの仕事しかしていなくても、求人の応募資格は出身の会社ではなく仕事の中身を問うので、中身を具体的に書ければ不利にはなりにくいということです。不足しやすいのは、転職先によって、自分でコードを書いた経験か、社外の顧客への提案の経験です。

メーカー系とユーザー系の IT 子会社は何が違いますか？

呼び分けに決まった定義はなく、使う人によって指す会社が違います。目安になるのは、親会社やそのグループ向けの仕事が中心か、外の会社に売る仕事が中心かです。どちらの呼び名でも、求人の応募資格はこの呼び分けをほとんど書かないので、職務経歴書では呼び名より、担当したシステムと工程を書く方が伝わります。

メーカーの IT 部門と IT 子会社は、転職で同じ扱いになりますか？

求人の文面からは分かりません。社内SE の求人には、事業会社の情報システム部門での経験を条件に書くものがあり、当サイトの掲載求人の社内SE では約 20% の会社が「事業会社」の語を応募資格に書いています（2026 年 11 月 4 日、会社単位）。別会社である IT 子会社の経験がこれに含まれるかは、求人ごとに面接で確かめるのが確実です。「事業会社もしくは顧客先企業における情報システム部門」のように、常駐先での経験まで含める求人もあります。

在職中に、転職を考えていることを知られないようにするには？

一般的な注意として、会社の PC・メール・社内チャットで求人を見たり応募のやりとりをしたりしないこと、職務経歴書に親会社のシステムの社内での名前や取引の数字など、社外に出せない情報を書かないこと（「生産管理システム」「購買システム」のように種類で書けば伝わります）、内定が出て退職を決めるまで社内で話さないこと、が挙げられます。どこまで書いてよいか迷う情報は、今の会社の就業規則や秘密保持の決まりで確かめてください。

この記事で分からないこと

数字はすべて当サイトの掲載求人を 2026 年 11 月 4 日に数えたもので、市場全体の求人ではありません。数えたのは応募資格の欄だけ（必須と歓迎は同じ欄）で、仕事内容の欄は数えていません。会社単位は、その会社のその職種の求人のうち 1 件にでも語があれば 1 社と数える方法で、求人の多い会社ほど数に入りやすくなります。割合は 5% 単位に丸めています。1% に満たないものは「1% 未満」と書きました
転職先は、社内SE、ITコンサル、SE・開発・インフラ・PM のうち主な業種が IT の会社のもの（IT 業界の会社の SE・開発）、それ以外の会社のもの（IT 以外の会社の SE・開発）の 4 つに分けました。1 つの会社が複数の職種に入ることがあるので、割合は足し合わせられません。IT 業界の会社の SE・開発は SIer と自社開発をまとめて数えていて、自社開発だけの割合ではありません
語の数え方には幅があります。言語・実装の語には「Pythonでの開発経験は必須ではありません」のような否定の文で数えた会社が最大 3% ほど混ざります。「要件定義」は「要件定義～本番移行」のような工程の範囲の書き方も数えているので、要件定義そのものの経験を求める求人より広い数え方です
分かるのは、求人の応募資格にその語が書かれているかまでです。実際に書類や面接を通るか、語を書いていない求人が IT 子会社の経験をどう評価するか、古い言語やオンプレミスの経験がどう評価されるかは分かりません。AWS や Go などの個別の技術が必須か歓迎かの割合、地域ごとの求人の数、リモート勤務の有無も数えていません
年収が親会社に合わせて決まるか、転職して上がるか下がるかは、一次情報を確認できず扱っていません