情シスエンジニア vs 非情シスエンジニア 仕事・年収・本音を公開の声で比べる

情シスのエンジニアと、SIer・Web系・SaaS企業の開発者。同じ「エンジニア」と呼ばれても、仕事の景色はかなり違います。

この特集では、ブログやnote、Zennに公開されている声と、公開されている調査の数字を並べました。どちらが上かを決める記事ではありません。お互いの事情を知ると、組むときの摩擦が減るはずです。

公開されている声8件を読んで整理しました(編集部)。個人の体験なので、すべての会社に当てはまるわけではありません。

同じエンジニアでも、お客さんが違う

違いの根っこは、成果を渡す相手です。情シスは、同じ会社で働く社員が相手です。SIerの開発者は、契約した顧客企業が相手です。Web系やSaaS企業の開発者は、プロダクトを使うユーザーが相手です。

noteで11年の社内SE経験を書いているイルカ先生は、SIerとの違いをこうまとめています。SIerはプロジェクトの成功が目的で、社内SEは会社全体の生産性が目的、という整理です。

相手が違うと、急ぐ理由も変わります。納期が契約で決まる世界と、全社員が止まらず使える状態を守る世界では、優先順位の付け方が別になります。

仕事の中身を並べて比べる

公開されている声をもとに、編集部が違いを表にまとめました。会社によって当てはまらない行もあります。

情シスの欄に「雑務」と書きましたが、軽い仕事という意味ではありません。アカウント管理や権限変更、台帳の更新は、事故を防ぐ土台です。

noteに社内SEからSIerへ移った経験を書いたウィッチゃんさんは、運用の地味な作業の意味が、移ってから効いてきたと振り返っています。

評価のされ方はどう違うか

公開されている体験談を読むと、評価の話は「見えやすさ」に集まります。

イルカ先生は、社内SEの悪かった点として「評価制度が曖昧」「ITの成果は見えにくい」を挙げています。トラブルが起きないことが成功なので、成功が目立たないのです。

反対側の声もあります。アラサンさんは、SIerのSEは事業部門側(営業利益を上げる側)になるため、社内で大事にされやすいと書いています。同じ人が、社内SEの立ち位置をこう書いています。

社内SEは間接部門として見られ、肩身が狭いケースが多い印象です。ビジネス部門に対して力関係が下になりがち。

2023年の個人の感想です。いまの会社に当てはまるとは限りません。ただ、情シスが「コストを使う側」と見られやすい構造は、他の声にも出てきます。

Web系や自社サービスの企業については、イルカ先生が、プロダクトが主役で技術力が重視される文化だと書いています。成果が利用者の数や速度で語りやすいぶん、評価の軸も分かりやすいという見方です。

年収とキャリア:公開データで見る

国の賃金統計に、情シスだけを切り出した数字は、編集部が調べた範囲では見つかりませんでした。そこで、公開されている転職サービスの集計を使います。

doda(パーソルキャリア)の職種図鑑では、社内SEの平均年収は450.8万円です。IT/通信系エンジニア系12職種の平均は455.1万円で、社内SEは12職種中7番目です(2023年9月〜2024年8月の登録者データ)。

同じdodaの平均年収ランキング(2024年9月〜2025年8月、正社員の約60万件)では、職種ごとの数字が並びます。社内SEの行はありませんが、近い職種を見ると幅が分かります。

集計の期間が違うので、上の2つの表をそのまま引き算しないでください。読み取れるのは、情シス寄りの職種でも「企画」に近いほど高く、「問い合わせ対応」に近いほど低いという傾向です。

ネットには「社内SEのほうが年収が高い」という記事も、「低い」という記事もあります。集計元と職種の区切りが違うからです。平均より、自分の会社の規模と役割を見るほうが現実的です。

キャリアの声では、転職の方向が2つに分かれます。SIerの長時間労働から社内SEへ移り、年収が140万円上がったと書く人がいます(えんじこーむさん、2026年。記事には転職サービスの紹介を含みます)。逆に、社内SEから技術を深めたくてSIerへ移った人もいます。

社内SE時代は開発が外注中心だったため、要件の取りまとめや社内の調整がメインでしたが、一つだけでも深掘りして技術を求めていればより市場価値が出せたと感じます。

ウィッチゃんさんは、社内SEの経験はSIerでも使える力だったとも書いています。利用者の困りごとを聞き、社内の事情を踏まえて調整する力です。

2019年のnoteでコーポレートITを解説したヒガシさんは、コーポレートITの担当は元開発者が多いと書いています。行き来は、思われているより普通のことです。

お互いにどう見えているか

公開されている声は、情シス側から書かれたものが多めです。開発者が情シスをどう見ているかは、元の立場の人が語る形でしか見えませんでした。その前提で読み取れることを整理します。

情シスから開発者への見え方では、ベンダーや開発チームの事情が見えていなかったという反省が目立ちます。

社内SE側から見ると「早くやってほしい」と思うことでも、ベンダー側では契約、体制、影響範囲、品質、別案件との兼ね合いがあります。

開発者から情シスへの見え方では、「ルールが多くて遅い」という印象が語られがちです。一方で、スタートアップでインフラエンジニアが情シスを兼任したruchikaさんは、現場側の事情も分かる立場からこう書いています。

新しいプロジェクトが立ち上がった際や、ちょっとしたグループ内に閉じたアイテムを保管したい場合など、ドライブの作成自体を閉じてしまう / 申請制にしてしまうとスピードが落ちてしまいます。

この方は、共有ドライブを誰でも作れる形にして、権限はグループ単位で渡す運用にしたと書いています。禁止するより、管理しやすい形で自由を残す考え方です。

もう一つ、情シスの仕事が難しくなったという見方もあります。クラウドインフラとコーポレートITを兼ねるフリーランスのthrさんは、10年前と今を比べています。

いまは、自分で要件定義して最低限Fit&Gapくらいはやって、SaaSだったら運用設計しながら設定して、既存システムと連携して自動化して。これらのことがあたりまえに求められる。

SaaSの選定、連携、自動化、セキュリティ。情シスの仕事が、開発の考え方に近づいているという指摘です。

すれ違いが起きる3つの場面

読んだ声を整理すると、すれ違いは次の3つに集まりました。

1. スピードとルール。開発側は「今日使いたい」、情シスは「全員が安全に使い続けられる形にしたい」。どちらも正しいので、ぶつかります。
2. 技術の深さと調整の広さ。開発者は一つの技術を深く掘り、情シスは広く調整します。互いの仕事を「浅い」「狭い」と見ると、感じが悪くなります。
3. 成果の見え方。機能のリリースは目に見えます。障害が起きなかった日は、誰にも気づかれません。

笑い話のようですが、原因はたいてい「理由と期限が最初に伝わっていないこと」です。次の章で、その直し方を書きます。

人手の現実:情シスは少人数で回している

情シスの側には、人手の事情もあります。ノークリサーチの調査(2025年5月、800社)では、年商500億円未満の中堅・中小企業で、情シスの担当が1人の会社は21.3%(2023年)から24.5%(2025年)に増えています。

年商5〜50億円の会社では、情シスの兼任が48.0%から61.1%に増え、専任は28.7%から16.7%に減りました。人数が同じでも、兼任が増えると負担は増えると、調査は指摘しています。

JUASの企業IT動向調査2026(2025年9月〜10月、ユーザー企業のIT部門長が対象)では、DXを進めるうえでの課題として「人材・スキルの不足」を1位に選んだ企業が38.5%でした(この設問の回答956社)。内製化の課題も、開発人材やプロジェクトマネジメント人材の不足だと報告しています。

つまり、情シスが「遅い」ように見えるとき、断っているのではなく、手が回っていない場合があります。同じ構造は、開発チームにも当てはまります。

クラスメソッドのブログには、開発側と情シスがうまく組んでいる例があります。

「定期監査がとてもラクになった」「本業に専念できる時間が増えた」など、事業部情シス(その2)の取り組みに対して感謝のフィードバックをたくさんいただいています。

この会社では、各事業部の窓口になる人を決め、アカウントの棚卸しなどの定型作業を、情シス側が引き取って自動化しています。開発者が本業に集中できるように、情シスが仕組みを作る形です(2023年の記事です)。

今日からできること

社内の開発チームと組むとき

1. 依頼は「理由・期限・困りごと」の3点で伝える。「このツールを入れてほしい」より、「来週のリリースで必要。使えないと検証が止まる」のほうが、情シスは優先順位を付けられます。
2. 「ダメ」の先に代案を聞く。断られたら、「どうすれば使えますか」と一歩踏み込みます。ruchikaさんのように、申請制ではなくグループ単位で任せる形が見つかることがあります。
3. 情シスは、断る理由を一言添える。「セキュリティ上NG」だけで終わらせず、何が危ないのかを短く伝えます。代案を1つ付けると、相談が早く来るようになります。

外部のエンジニア(ベンダー、SIer、フリーランス)と組むとき

1. 「早くしてほしい」の前に、相手の事情を一度聞く。契約、体制、影響範囲、品質、別案件との兼ね合いがある、とウィッチゃんさんは書いています。
2. 障害の報告は「なぜその原因と判断したか」まで聞く。ログのどこを見たか、暫定対応と恒久対応の違いは何か。聞くほど、自分の理解も深まります。
3. 窓口を一人にする。依頼がいろいろな人から飛んでくると、外部の人が優先順位を決められなくなります。

キャリアを考えるとき

1. 年収は職種名ではなく「役割」で見る。dodaの数字でも、企画に近い職種と問い合わせ対応に近い職種では250万円ほど開きます。
2. 一つ、深掘りする領域を決める。ネットワーク、クラウド、セキュリティのどれでもよいので、「ここは踏み込んで話せる」と言えるものを一つ持つ。ウィッチゃんさんが、やっておけばよかったことの一つに挙げています。
3. 経験を言葉にして残す。改善の実績を「課題、行動、成果」で書き留めておくと、情シスから開発へ、開発から情シスへと、どちら向きにも動きやすくなります。
4. 会社の規模と体制を確認する。イルカ先生は、IT部門が1〜2名で「何でも屋」になる求人に注意を促しています。人数と兼任の状況は、面接で聞けます。

どちらの仕事も、会社を動かす仕事です。作る人と、使い続けられる状態を守る人が、相手の事情を知って組めば、会社全体が楽になります。

開発チームや営業と要望をやり取りするときの進め方は、「このツール使いたい」にどう答える?営業・現場とのシャドーIT対策と要望の受け方にも書きました。