常駐先を転々とするのはもう避けたい。自社で腰を据えて働きたい。そう考えて求人を見ると、社内SEと自社開発エンジニアが並んで出てきます。

どちらも「自社」と書かれているので、近いものに見える。けれど入社後の仕事の中身は、同じ社内という言葉でくくれないほど離れていることがあります。

違いは技術スタックではなく、その部門が会社の中でどういう扱いを受けているかにあります。

「自社」が二つある

【1】呼び名で仕事内容が違う

社内SEは、自社の業務で使うシステムを担当する職種です。基幹システム、勤怠、経費精算、社内ネットワーク、情報端末。利用者は自社の社員になります。

自社開発エンジニアは、自社が外部に提供している製品やサービスを作る職種です。利用者は顧客で、その製品の売上が会社の収益になります。

どちらも雇用主の社内で働きますが、作っている物の行き先が違う。この行き先の違いが、後で述べる評価のされ方まで一本につながっています。

【2】求人票では同じ言葉で書かれる

問題は、両方が「自社サービス」「自社システム」という似た表記で募集されることです。「客先常駐なし」「自社勤務」という条件も共通します。

そのため、常駐からの移り先を探している段階では、この二つが同じ選択肢の中に並びます。応募してから、想定していた仕事と違うと気づくことがある。

【3】会社の主業で立場が入れ替わる

ただし、この表は固定ではありません。ソフトウェアを売っている会社では、開発部門が主業の中心にあります。一方、製造業や小売業では、開発部門そのものが存在せず、情報システム部門が社内の技術部門のすべてになります。

同じ「社内SE」でも、IT企業の情シスと、非IT企業の情シスでは、社内での位置づけも予算の規模も変わる。職種名だけでは判断できません。

部門の位置づけが違う

ここからは、構造の話です。位置づけの違いは、予算の付き方として現れます。

【1】間接部門は削減の対象になりやすい

情報システム部門は、多くの会社で間接部門に分類されます。間接部門は、売上を直接作らず、会社全体のコストとして計上される部門です。

コストとして計上されるものは、業績が悪化したときに削減の検討対象に入ります。システムの更改が先送りされる、要員の補充が止まる、外部委託の枠が縮む。

技術的な判断とは別の理由で、計画が動くことがあります。

【2】事業部門は成長と縮小の両方が早い

一方、製品を作る部門は、売上に直結しているため投資の対象になります。伸びている製品には人が増え、開発の裁量も広がる。

ただしこれは逆方向にも働きます。製品が想定に届かなければ、部門ごと縮小や撤退の判断が入る。間接部門は削られにくい代わりに増えにくく、事業部門は増えやすい代わりに減りやすい。

どちらが安定かは、会社の状態によって入れ替わります。

【3】人の増やし方も変わる

間接部門の人員は、会社全体の管理費の枠内で決まります。担当するシステムが増えても、枠が広がらなければ要員は増えません。

事業部門の人員は、その製品の見通しに連動します。伸びる見込みがあれば採用が動き、そうでなければ止まる。人が増える理由が、片方は業務量、もう片方は事業の見通しにある。

この違いは、入社後に一人あたりが抱える範囲に直結します。

評価のされ方が違う

位置づけが違えば、何をもって成果とするかも変わります。ここは転職の場面にまで影響します。

【1】減点を防ぐ指標と加点を積む指標

社内SEに求められるのは、業務が止まらないこと、問い合わせが滞留しないこと、費用が計画の範囲に収まること。

自社開発で求められるのは、機能が出ること、利用が伸びること、不具合が事業に影響しないこと。

前者は減点を防ぐ形の指標が多く、後者は加点を積む形の指標が多くなります。

【2】「何も起きなかった」は説明しにくい

この差は、成果を説明する言葉にまで及びます。社内SEの成果は「障害が起きなかった」「移行が問題なく終わった」という形をとることが多く、そのままでは数字になりません。

安定して回っている状態は、外から見ると何もしていない状態と区別がつきにくい。成果が見えないのは働きが足りないからではなく、指標が減点を防ぐ形をしているためです。

【3】転職市場での読まれ方

この構造は、次の転職の場面でも効いてきます。導入した製品の名前、管理していた委託先の数、対応した問い合わせの件数。これらは並べても、スキルや実績が伝わりません。

社内SEの経験を書くときは、選定の場面で何を基準にしたか、業務側の要望と費用の制約をどう折り合わせたかを残すほうが読まれます。

自社開発側も同じで、実装した機能名より、何を優先して何を落としたかのほうが情報になります。

作る比率が違う

もう一つ、この二つの間には、実務の時間配分に大きな違いがあります。

【1】社内SEの中心は調整であることが多い

社内SEというと開発に集中できるイメージがありますが、実際に多いのは、既存製品を選んで導入し、業務に合わせて調整する仕事です。

勤怠も経費精算も、市販のサービスを使うほうが安く早い。そのため業務は、要件の整理、製品の比較、委託先の管理、導入後の運用に寄ります。

自分でコードを書く時間は、想定より少ないことがあります。

「開発に集中したくて社内SEに移ったが、実際はベンダーとの調整が中心だった」という食い違いは、この構造から起きます。

【2】自社開発は一つの製品を長く触る

自社開発は、担当する製品が基本的に一つです。同じコードベースに長く関わるため、設計の意図や過去の経緯まで踏み込めます。

一方で、扱う技術の幅は狭くなる方向に働きます。製品で使っている言語とフレームワークが、そのまま数年分の経験になる。

複数の現場で幅を広げてきた人にとっては、狭く感じることがあります。

【3】対象システムの数が逆になる

社内SEは、担当するシステムの数が多くなりがちです。基幹、会計、勤怠、端末管理、ネットワーク。一つひとつは深くなくても、広く把握しておく必要がある。

自社開発は、対象が少ない代わりに深さが要求されます。

広く浅くと、狭く深く。

どちらが自分に合うかは、技術の好みより、仕事の進め方の好みで決まる部分が大きいです。

求人票での見分け方

言葉が似ている以上、応募前に区別する手段が要ります。

【1】利用者が誰かを確認する

× 「自社サービスの開発」とだけ書かれている求人に、開発比率を想像して応募する。

○ 面談で「そのシステムの利用者は社員ですか、社外の顧客ですか」「売上はどこから立っていますか」を確認してから判断する。

利用者が社員なら社内SE、社外の顧客なら自社開発です。この一問で大半は分かれます。

【2】内製と外部委託の比率を聞く

次に、実装を自分たちで行っているか、委託しているかを確認します。「直近1年で、社内のメンバーが書いたコードと外部委託の比率はどのくらいですか」という聞き方ができます。

委託が中心であれば、担当する仕事は要件整理と進行管理が主になります。これは良し悪しではなく、仕事の中身の話です。

【3】所属する部署名を確認する

情報システム部、社内IT推進室といった名称なら間接部門に属している可能性が高く、開発本部、プロダクト部といった名称なら事業部門に属している可能性が高い。

ただし名称の付け方は会社ごとに違うため、名称だけで断定はできません。予算の決裁が事業側から出るのか管理側から出るのかまで確認できると、位置づけが分かります。

あなたには、どちらが向くのか

最後に、選ぶ側の基準を整理します。

【1】社内SEが合いやすい場合

業務そのものへの関心が強い人、利用者の顔が見える距離で改善したい人、扱う範囲を広く持ちたい人には、社内SEの働き方が合いやすい。

勤務時間の変動が製品のリリース状況に左右されにくい点も、条件として挙がります。ただし障害対応や繁忙期の対応は発生します。

【2】自社開発が合いやすい場合

一つの製品に長く関わりたい人、技術的な判断に関与したい人、利用の伸びを成果として説明したい人には、自社開発が合いやすい。

その代わり、製品の状況が働き方に直結します。事業フェーズによって求められるものが変わる点は、移る前に確認しておく価値があります。

【3】どちらも合わない場合がある

二つを比べる前提には、「客先常駐の働き方が合わない」という判断があります。ただ、常駐の働き方自体が条件に合っている人もいます。

複数の現場を短い期間で見られること、特定の製品や社内政治に縛られないこと、勤務地や参画期間に融通が利くこと。

移る理由が「常駐が嫌だから」だけの場合、移った先で別の不一致が出ることがあります。 何が合わなかったのかを、現場の数なのか、工程なのか、決定権の無さなのかまで分けてから選ぶほうが、選択肢の絞り方が変わります。

まとめ

・社内SEと自社開発は、どちらも自社勤務だが、作った物の行き先が社内か社外かで分かれる

・情報システム部門は間接部門としてコスト計上されやすく、事業部門は投資対象になりやすい。安定の向きが逆になる

・社内SEの評価は「止めないこと」、自社開発の評価は「伸ばすこと」に寄る。成果の説明の仕方まで変わる

・社内SEは製品選定・委託先管理の比重が高く、開発に集中できるとは限らない。自社開発は対象が少ない代わりに深さが要る

・求人票では区別しにくい。利用者が誰か、内製と委託の比率、所属部署の位置づけの3点を面談で確認する