情報子会社エンジニアの転職、自社開発で評価されにくい理由

「これまでどんなクライアントを担当されてきましたか」——カジュアル面談での定番の質問に、Sさんは一瞬言葉に詰まりました。9年間、担当してきた相手は親会社ただ1社だったからです。

私はIT・Web業界を中心に800名以上の転職支援を担当していますが、情報子会社出身の方から「書類選考がまったく通らない」という相談を受ける機会は、ここ数年でむしろ増えている実感があります。今回は、情報子会社という業態特有の評価されにくさがどこから来るのか、その構造と、求人票の文言を職務経歴書に落とし込む具体的な翻訳の仕方を、実際の相談を交えてお伝えします。

目次

1. 情報子会社エンジニアが自社開発企業の転職で評価されにくい瞬間
2. なぜ情報子会社は親会社1社だけの経験になりやすいのか
3. 求人票の「複数プロジェクト経験」が本当に測っているもの
4. 情報子会社の経験を複数プロジェクトに分解する3つの視点
5. Before/After、職務経歴書の書き方
6. 職務経歴書と面接、書き直した後にSさんが得たもの
7. 面接で聞かれやすい質問と、答え方の型
8. 転職に動くべきタイミング、何年目が目安か
9. 情報子会社・社内SE・情シス、混同されやすい呼び方の違い
10. 転職前にチェックしておきたいこと
11. よくある質問に答えます
12. まとめ、情報子会社出身者の武器は経験を分解する力

情報子会社エンジニアが自社開発企業の転職で評価されにくい瞬間

情報子会社に勤めるエンジニアから受ける転職相談には、共通する違和感があります。実務経験は申し分ないのに、書類選考の通過率だけが極端に低いという違和感です。

Sさん(33歳・経験9年)もその一人でした。大手生命保険会社の情報子会社で、契約管理システムの開発・保守を一貫して担当してきたエンジニアです。転籍社員として入社し、9年間ずっと同じ親会社のシステムに向き合ってきました。要件定義から本番リリースまで一通り経験しており、技術力に不安があったわけではありません。ところが自社開発のHR系SaaS企業に的を絞って応募したところ、7社中7社が書類選考で見送りになりました。

面接どころか、書類の時点で弾かれる。何が悪いのか分からないまま相談に来られたとき、職務経歴書を見て理由がすぐに分かりました。「担当システム:保険契約管理システム(親会社)」という一行に、9年分の経験がまるごと収まっていたのです。7社のうち珍しく見送り理由を書き添えてくれた1社からは、「経験の幅が見えにくく、弊社のプロダクトでどう活かせるか判断がつかなかった」というフィードバックが届いていました。

これは特殊なケースではありません。情報子会社に長く在籍してきたエンジニアの多くは、技術力そのものよりも経歴の見せ方でつまずいています。面接官の立場に立ってみると、同じ職種・同じ年数の候補者が並んだとき、片方は3社の受託案件を渡り歩き、もう片方は1社のシステムだけを見てきたという構図になりがちです。悪気なく「経験の幅が違うな」という印象を持たれてしまうのは、情報子会社という業態そのものの宿命に近いところがあります。

なぜ情報子会社は親会社1社だけの経験になりやすいのか

情報子会社とは、企業が自社の情報システム部門を切り出して子会社化した組織を指します。親会社(グループ)向けのシステム開発・運用を一手に引き受ける代わりに、外部の複数クライアントとは基本的に取引をしません。Wikipediaの「情報子会社問題」の項目では、連結売上高5000億円以上の企業の約7割がIT子会社を保有しているという調査結果が紹介されており、決して珍しい業態ではないことがうかがえます(出典:情報子会社問題(Wikipedia))。

この構造自体は、日本のIT人材の偏在とも無関係ではありません。内閣府が作成した資料では、日本のITエンジニアの72.3%がIT企業側に所属し、非IT産業側(ユーザー企業側)に所属するのはわずか27.7%にとどまります。米国は64.5%、ドイツは61.4%が非IT産業側に所属しており、日本は際立ってIT企業側に偏った構造になっています(出典:ITエンジニアの偏在、日本はIT企業側に72.3%(日経クロステック))。ユーザー企業がシステムを内製化するのではなく、子会社化という形でIT人材を抱え込んできた歴史が、情報子会社という業態を各業界に量産してきたと私は見ています。

そしてこの成り立ちこそが、転職市場での評価のされにくさに直結しています。SIerや受託開発会社であれば案件ごとにクライアントが変わりますが、情報子会社は顧客が変わりません。何年在籍しても「担当したクライアント数」は1のままで、職務経歴書にどれだけ丁寧に書いても、複数クライアントを渡り歩いてきた候補者と並べられた瞬間に見劣りしてしまいます。

多くの情報子会社は、1980年代から90年代にかけて、親会社の情報システム部門を切り出す形で設立されてきました。当時の主な目的は人件費の圧縮やグループ内でのコスト管理で、外部との取引を前提にしない組織設計が最初から組み込まれていたケースがほとんどです。生まれたときから顧客が親会社1社に固定されている組織で、そこに所属してきた個人だけが「視野が狭い」と評価されるのは、正直なところ酷な話だと私は感じています。

情報子会社をめぐっては、親会社側のITガバナンスが弱まるという「情報子会社問題」も以前から指摘されてきました。親会社の意思決定から距離のある組織で長く働くほど、技術選定や開発プロセスの裁量が限られ、結果として経歴に書ける「自分で決めた」という経験が薄くなりやすいという副作用もあります。転職市場で問われる主体性や裁量が、情報子会社という構造そのものによって奪われやすいという事実は、出身者本人の努力不足とは切り離して理解しておく必要があります。

求人票の「複数プロジェクト経験」が本当に測っているもの

自社開発企業の求人票には「複数プロジェクトの経験」「多様な技術スタックでの開発経験」といった文言がよく並びます。これは字面通り案件の本数を数えているわけではなく、採用側が知りたいのは別のことだと私は考えています。

一つは、環境が変わったときに立ち上がりが早いかどうか。もう一つは、技術や仕様の前提が変わったときに、自分の頭で判断し直せるかどうかです。複数クライアントを経験した候補者は、否応なくこの2つを繰り返し試されてきています。だから求人票の文言は「経験の数」ではなく「環境変化への耐性」を測る代理指標になっていると考えた方が実態に近いはずです。

情報子会社出身者がここで損をするのは、経験の絶対量が少ないからではありません。9年という年数は決して短くない。損をするのは、9年分の経験を面接や書類で使える形に翻訳できていないからです。実際には情報子会社の中にも環境の変化はいくつもあったはずなのに、職務経歴書がそれを拾い上げていないケースがほとんどです。

実際の求人票を見ると、「複数のクライアントに対する要件定義・提案経験」「toB/toC問わず幅広いプロダクト開発経験」といった書き方がよく登場します。字面だけを読むと情報子会社出身者は最初から対象外に見えますが、採用担当者と話していると、クライアントの数そのものを人事考課のように数えている企業はほとんどないことが分かります。むしろ見られているのは、初めて会う相手に対してゼロから信頼関係を作り、要求を整理し直す経験があるかどうかです。それが社内の一部署であっても、成立していれば評価対象になります。

例えば「多様な技術スタックでの開発経験」という文言を、フロントエンドからインフラまで何もかも経験していないと満たせない条件だと捉えてしまう情報子会社出身者は少なくありません。実際には、1つのプロダクトの中で技術が入れ替わった経験があれば十分に該当します。技術の幅を横の広がりだけで測る必要はなく、時間軸での入れ替わりも立派な多様性です。

情報子会社出身者の書類通過率だけを見ると、同年代・同年数のSIer出身者と比べて2〜3割ほど低くなる傾向が、私が担当してきた実績の中でも見えています。ただしこの差は、職務経歴書を書き直しただけで大きく縮まることも同時に分かっています。数字の差は実力の差ではなく、翻訳の差として表れているというのが、現場で見てきた実感です。

情報子会社の経験を複数プロジェクトに分解する3つの視点

分解と言っても、経験を大げさに盛るという意味ではありません。すでに存在している事実を、採用側が理解できる単位に並べ替える作業です。Sさんの職務経歴書を一緒に見直したとき、私がまず聞いたのは「契約管理システムの中で、実際にやり取りしていた部署はいくつありましたか」という質問でした。答えは営業推進部、代理店管理部、コールセンター運営部の3つ。要件も優先順位もまったく別々に出てくるのに、Sさんの中ではずっと「同じシステムの仕事」として一つにまとまっていました。

ここに1つ目の分解の視点があります。情報子会社における「部署」は、外部から見れば実質的なクライアントと同じ役割です。発注元が社内か社外かの違いはあっても、要件をヒアリングし、優先順位を調整し、合意形成をして開発するという業務の型は変わりません。「親会社向けシステムの保守」という1行を、営業推進部向け・代理店管理部向け・コールセンター運営部向けという3つの案件に分解するだけで、職務経歴書の見え方は一変します。

2つ目の視点は技術スタックです。情報子会社は特に、レガシーとモダンが同居しているケースが多いという特徴があります。Sさんの場合も、メインフレーム連携のCOBOLバッチ処理と、3年前に始まったクラウド移行プロジェクトのJavaマイクロサービス化が併存していました。単一クライアントであることは弱みですが、同じ組織の中で技術の世代交代を経験しているのは、むしろキャッチアップ力を示す材料になります。

3つ目は成果の主語です。「保守を担当」ではなく、どの部署のどんな課題を、どう解決したかを書く。Sさんの場合、代理店管理部からの要望で照会画面のレスポンスタイムを4秒から0.8秒に短縮した実績がありましたが、職務経歴書には一言も書かれていませんでした。

Before/After、職務経歴書の書き方

書き直す前のSさんの職務経歴書は、こう書かれていました。「保険契約管理システムの開発・保守を担当。要件定義から設計、実装、テスト、リリースまで一貫して従事。運用フェーズでは障害対応や改善要望への対応も行った」。

3つの視点で分解した後は、「保険契約管理システムにおいて、社内の3部署(営業推進部・代理店管理部・コールセンター運営部)を発注元とする開発案件をそれぞれ担当。代理店管理部向けの照会画面については、レスポンスタイムを4秒から0.8秒へ短縮する改善提案を行い、要件のヒアリングから本番リリースまでを主導した」という書き方に変わりました。

同じ経験を書いているのに、後者は「発注元」「改善提案」「主導」という言葉が入るだけで、能動的に動いてきた人材だという印象に変わります。

求人票の文言は、次のように読み替えるとイメージがつかみやすくなります。

職務経歴書と面接、書き直した後にSさんが得たもの

Sさんはこの3つの視点で職務経歴書を丸ごと書き直しました。「保険契約管理システムの開発・保守」という1行を、営業推進部向け・代理店管理部向け・コールセンター運営部向けの3つのプロジェクトに分け、それぞれに使用技術と課題・成果を添えています。レスポンスタイム短縮の実績も、具体的な数字で書き加えました。

書き直した職務経歴書で改めて5社に応募したところ、3社で書類選考を通過し、2社が最終選考まで進みました。一次面接では、以前なら「親会社のシステムを担当していました」としか答えられなかった質問に対して、「社内に3つの発注元があり、それぞれ要件の温度感が違いました」とすぐに答えられるようになっていたのも大きな変化です。技術面接で「レガシーとモダンが混在する環境で、優先順位をどう決めていたか」と踏み込まれた場面でも、COBOLバッチとJavaマイクロサービスの併存期に自分がどう判断してきたかを、迷わず具体的に説明できていました。

最終的に、Sさんは自社開発SaaS企業のバックエンドエンジニアとして1社から内定を得ました。年収は現職からほぼ横ばいでしたが、Sさん自身が一番驚いていたのは金額ではなく、面接官から経験の幅を言語化できていると評価されたことでした。書類選考すら通らなかった数ヶ月前と経歴そのものは変わっていないのに、受け取られ方がまるで違ったのです。

この「経験の語り方」という観点は、受託開発から自社開発への転職理由、案件の多様性の語り方で扱った、逆に案件の多様性が多すぎて定着意欲を疑われるケースとも表裏の関係にあります。単一クライアントの深さも、複数クライアントの幅も、どちらもそのままでは強みになりません。翻訳して初めて評価の材料になります。

面接で聞かれやすい質問と、答え方の型

情報子会社出身者が面接でよく受ける質問には、いくつかの型があります。代表的なものを整理すると、聞かれている意図と答え方の芯が見えてきます。

特に2つ目の「なぜ長くとどまっていたのか」は、情報子会社出身者がもっとも答えに詰まりやすい質問です。Sさんも最初は「異動もなく、なんとなく在籍していました」としか答えられませんでした。しかし振り返ってみると、5年目にクラウド移行プロジェクトへの参加を自ら志望していた経緯があり、これは立派な能動的な選択です。在籍理由を「流されていた」ではなく「選び続けていた」という言葉に変えるだけで、面接官の受け取り方は大きく変わります。

転職に動くべきタイミング、何年目が目安か

情報子会社からの転職を考えるタイミングとして、私がよく助言するのは「技術の世代交代を1周経験したかどうか」です。情報子会社は技術移行のサイクルが親会社の投資判断に左右されるため、在籍1〜2年ではまだ保守フェーズしか経験できておらず、翻訳できる材料が乏しい状態での転職活動は苦戦しやすくなります。逆に、レガシーからモダンへの移行プロジェクトを1つでも主体的に経験していれば、翻訳の材料は十分にそろいます。年代でいえば、30代前半までに一度は移行プロジェクトを経験しておくと、その後の転職活動の選択肢が大きく広がるというのが実感です。

40代以降で転職を考える場合は、経験の幅よりもマネジメントや折衝の実績が問われる場面が増えます。情報子会社では発注元との折衝そのものが日常業務になっているケースも多いため、その経験をプロジェクトマネジメントの言葉に翻訳できれば、年齢を理由に不利になることはそれほど多くないというのが、これまで見てきた実感です。35歳前後は、この2つの評価軸がちょうど切り替わる境目に当たるため、技術の幅と折衝の実績のどちらを主軸に語るかを、応募前に一度整理しておくと選考が進みやすくなります。

情報子会社・社内SE・情シス、混同されやすい呼び方の違い

情報子会社という言葉は、社内SEや情シスと混同されがちですが、立ち位置は少し違います。社内SEは事業会社内の一部署としてシステムを担う立場で、情シスもほぼ同義で使われることが多い言葉です。一方、情報子会社(ユーザー系子会社と呼ばれることもあります)は、その機能を切り出して独立した法人にしたもので、給与テーブルや評価制度も親会社とは別に設計されているのが一般的です。

情報子会社での働き方には出向と転籍の2パターンがあります。出向は親会社に籍を置いたまま情報子会社で働く形態で、数年で親会社に戻る前提のケースが多く、転籍は情報子会社の社員として雇用契約を結び直す形態です。Sさんのように転籍で入社した場合、プロパー社員(生え抜きで入社した社員)との間で評価制度上の違いが生じることもあり、この点は転職理由としてもよく耳にする話です。

年収面では、情報子会社は親会社の給与水準に準じつつ一段低く設定されているケースが多く、これも転職を考える動機の一つになります。ただし今回のテーマである「評価されにくさ」とは別軸の問題なので、切り分けて考えておくと転職理由の整理もしやすくなります。

情報子会社と社内SEを分けて考えるべき理由はもう一つあります。社内SEの転職市場は「情報システム部門の経験者」という括りで求人が出ることが多く、情報子会社出身者もこの括りに含まれて評価されがちです。しかし社内SEの経験は事業会社の一部署としての経験であるのに対し、情報子会社は別法人としての契約関係の中で働いてきた経験です。この違いを面接官に伝えられるかどうかで、「受け身の情シス」なのか「発注元と折衝してきたベンダー的な立場」なのかという印象が変わります。

職務経歴書に会社形態を書く際も、この違いは効いてきます。「◯◯株式会社(◯◯グループの情報子会社)に所属し、親会社および国内グループ会社向けにシステム開発・運用を担当」のように、単なる部署異動の延長ではなく法人としての取引関係の中で働いてきたことを明記するだけで、採用担当者の最初の読み方が変わります。

転職前にチェックしておきたいこと

ここまでの内容を、実際に手を動かすための準備として整理しておきます。職務経歴書を書き始める前に、次の3点を棚卸ししておくと、翻訳の作業がスムーズに進みます。

ポイント: 情報子会社での経験は「1つの巨大な案件」ではなく「複数の小さな案件の集合体」だったはずです。棚卸しの作業は職務経歴書を書く前の1回で終わらせず、面接直前にも見返しておくと、突然のクライアント関連の質問にも慌てずに答えられます。

同じ翻訳の発想は、運用保守中心のキャリアにも応用できます。監視や障害対応が中心だった経験を自社開発向けに書き直す手順は、客先常駐5年目、運用保守から自社開発への転職に効く翻訳術でも詳しく取り上げているので、あわせて参考にしてください。

ここまでの棚卸しは、社内の発注元・技術スタック・数値化できる成果という3点を自分一人で洗い出す作業です。ただ実際に応募先を選ぶ段階になると、洗い出した内容がIT業界の採用基準に対してどこまで響くのか、一人では判断しづらい場面も出てきます。

こうした場面で、IT業界の知識・経験を持つコンサルタントが担当する運用を掲げている一例として、IT専門の転職エージェント「＠PRO人（アットプロジン）」を紹介します。

公式サイトの説明によると、＠PRO人はIT業界の知識・経験を持つコンサルタントが担当し、「50社に迫るような極端な求人提案はいたしません」として応募先を1〜10社程度に絞り込む方針を掲げています。扱う職種の例としてシステムエンジニアやWebサービスエンジニア、社内SEなどを挙げており、情報子会社出身者が目指す自社開発企業への転職とも接点がある職種です。これらはあくまで公式サイトに掲載されている方針であり、私自身が担当した相談実績として書いているわけではない点は明確にしておきます。

よくある質問に答えます

出向のままでも、グループ外の企業に転職できますか。 はい、出向・転籍のどちらであっても、実際に担当した業務内容で評価されます。ただし出向の場合は親会社に戻る前提で採用されている分、退職手続きや引き継ぎのスケジュールを早めに確認しておく必要があります。

情報子会社の経験は、SIerでの受託経験より不利になりますか。 一概には言えません。SIerは複数クライアントを経験できる分、案件ごとの引き継ぎで経験が浅く終わることもあります。情報子会社は逆に、1つのシステムを長く深く見てきた強みがあります。どちらも経験の語り方次第で評価は変わります。

情報子会社から情報子会社への転職なら評価されやすいですか。 同業態への転職であれば「視野の狭さ」を指摘される場面は減りますが、給与水準の低さという別の壁にぶつかることが多いです。グループ外を目指すなら、今回書いたような翻訳の作業は避けて通れません。

情報子会社からSIerへの転職の方がスムーズですか。 SIerであれば「基幹システムの開発経験」という括りで求人が出ることが多く、書類選考の通過率は自社開発企業への転職より高くなる傾向があります。ただし業務内容が保守・運用寄りになりやすく、将来的に自社開発企業を目指すなら、遠回りになる可能性がある点は踏まえておいた方がいいと考えています。

情報子会社であることを、面接で隠したり誤魔化したりする必要はありますか。 まったくありません。情報子会社という肩書きそのものが不利に働くわけではなく、経験の伝え方が整理されていないことが不利に働きます。正直に業態を伝えた上で翻訳した経験をセットで話せば、むしろ堅実な組織で長く実務を積んできた印象を与えられます。

まとめ、情報子会社出身者の武器は経験を分解する力

情報子会社出身のエンジニアが自社開発企業への転職で苦戦するのは、経験が浅いからでも、スキルが低いからでもありません。単一クライアントという構造上、経験が分解されないまま職務経歴書に載ってしまっていることがほとんどです。Sさんのように、社内の発注元を分解し、技術の幅を棚卸しし、数字で成果を語り直すだけで、書類選考の結果は大きく変わります。経験が狭いかどうかではなく、経験を分解して語れるかどうかで評価は決まるというのが、この記事で一番伝えたかったことです。情報子会社という肩書きに引け目を感じる前に、まずは自分のキャリアを、何個のプロジェクトに切り分けられるか棚卸ししてみてください。