先に要点
IT業界を調べ始めると、かなり早い段階で出てくる疑問です。
どちらもシステムに関わる仕事なので似て見えますが、実務での立ち位置はけっこう違います。
ざっくり言うと、社内SE は 自社のために働くIT担当、SIer は 顧客のシステムを作る・支える外部支援側 です。
ただ、この一文だけだと少し雑なので、この記事では働き方、向いている人、実務で見えやすい違いまで整理します。
なお、ここでは職種名や会社の種類をかなり単純化して説明します。
実際には、社内SEでも開発中心の会社がありますし、SIerでも運用・保守・コンサル寄りの仕事があります。
まずは全体像をつかむための地図として読んでもらうのが近いです。
まず何が違うのか
一番大きい違いは、誰の課題を解く仕事か です。
| 観点 | 社内SE | SIer |
|---|---|---|
| 向き合う相手 | 自社の社員、現場部門、経営層 | 顧客企業、発注元、協力会社 |
| 主な目的 | 自社の業務を安定して回し、改善する | 顧客の要件に合わせてシステムを作る・導入する |
| 成果物 | 業務改善、運用安定、社内調整、IT統制 | 設計書、システム、テスト結果、導入支援 |
| 評価されやすいこと | 止めない、現場を困らせない、改善を進める | 納期・品質・予算を守り、顧客要望を形にする |
どちらが上という話ではありません。
見ている対象が違うので、必要な動き方も変わります。
社内SEの仕事は何をするのか
社内SE は、自社のITまわりを中から支える仕事です。
会社によって担当範囲はかなり違いますが、よくあるのは次のような業務です。
- 社内システムの運用・改善
- 業務部門からの要望整理
- ベンダーとの調整
- PC、アカウント、ネットワーク、SaaS の管理
- セキュリティ対策や監査対応
- 新しいシステム導入時の要件整理
開発だけをするというより、会社の業務が止まらないようにする 役割が強くなりやすいです。
そのため、技術だけでなく、現場との会話、優先順位づけ、社内調整もかなり大事になります。
たとえば、営業部門から 見積書をもっと早く作りたい と相談されたとします。
社内SEは、すぐにコードを書くというより、まず現行業務、使っているツール、承認フロー、既存システムとの連携を見ます。
実務では、ここで 新システムを作るべきか 既存ツールの設定変更で足りるか 外注するならどこまで依頼するか を整理することが多いです。
SIerの仕事は何をするのか
SIer は、顧客企業のシステム開発や導入を支援する会社や、その領域で働く人を指して使われることが多い言葉です。
よくある仕事は次のようなものです。
- 顧客へのヒアリング
- 要件定義、設計、開発、テスト
- パッケージやクラウドサービスの導入支援
- 既存システムの改修
- 移行作業、リリース支援
- 運用保守、障害対応
SIerは、顧客から依頼を受けて仕事を進めるので、契約、納期、成果物がかなり重要になります。
何を作るか だけでなく、いつまでに、どこまで、いくらで、誰が責任を持つか が仕事の中心に入ってきます。
開発経験を積みやすい一方で、案件や会社によっては調整やドキュメント作成が多くなることもあります。
このあたりは、「SIerだから全部同じ」ではなく、所属する会社、担当工程、案件の種類でかなり変わります。
働き方の違い
働き方で見ると、社内SEは 自社の中に深く入る、SIerは 複数の顧客や案件に関わる という違いが出やすいです。
社内SEは業務理解が効く
同じ会社の中で長く見るため、業務の背景や人の動きまで理解しやすいです。改善提案も、現場の事情に合わせやすくなります。
SIerは案件経験が広がりやすい
業界やシステム規模が違う案件に関われるため、設計、開発、テスト、移行などの経験を積みやすいです。
社内SEは急な相談が来やすい
社内の困りごとが直接届くので、障害対応、問い合わせ、部門調整が割り込みやすいです。
SIerは納期と契約が効きやすい
顧客案件なので、スケジュール、見積、契約範囲、成果物の合意が仕事の重さに直結します。
社内SEの方が楽、SIerの方が大変、という単純な話ではありません。
社内SEは調整範囲が広くなりやすいですし、SIerは案件次第で技術的にもスケジュール的にも濃くなります。
向いている人の違い
かなりざっくり分けるなら、次のように考えると分かりやすいです。
社内SEに向いている人
- ひとつの会社の業務を深く理解したい
- 現場の困りごとをITで少しずつ改善したい
- 技術だけでなく、調整や運用も苦になりにくい
- 長期的にシステムを育てる感覚が好き
作って終わりより使われ続ける状態を見たい
社内SEは、派手な新規開発ばかりではありません。
むしろ、日々の運用、権限整理、問い合わせ対応、既存システム改善の積み重ねが大事です。
そこに面白さを感じられる人は相性がよいです。
SIerに向いている人
- いろいろな案件や業界を見たい
- 開発工程やプロジェクト進行を経験したい
- 顧客要望を整理して形にするのが好き
- 納期や成果物がある仕事の方が動きやすい
- 設計、開発、テスト、移行などの経験を積みたい
SIerは、案件ごとに学ぶことが変わります。
そのぶん、最初のうちは覚えることも多いですが、経験の幅を広げたい人には合いやすいです。
実務でよくあるすれ違い
社内SEとSIerは協力することも多いですが、立場が違うので、すれ違いも起きやすいです。
| 場面 | 社内SE側の見え方 | SIer側の見え方 |
|---|---|---|
| 要望変更 | 現場から追加要望が出たので何とかしたい | 契約範囲・納期・見積への影響を確認したい |
| 障害対応 | 社内業務が止まるので早く復旧したい | 原因、責任範囲、暫定対応、恒久対応を整理したい |
| 仕様確認 | 現場の言い方が曖昧でも汲み取りたい | 合意済みの仕様として明文化したい |
ここで大事なのは、どちらかが悪いわけではないことです。
社内SEは社内業務の継続に責任を持ち、SIerは契約した成果物とプロジェクト進行に責任を持ちます。
だからこそ、要件定義や設計合意の段階で、言葉をそろえておくのがかなり重要です。
そのあたりは 設計合意書とは？ もつながります。
キャリアとしてどちらを選ぶべきか
初心者が選ぶなら、まず 自分がどの種類の経験を積みたいか で考えるのが現実的です。
自社の業務改善や運用に腰を据えたいなら社内SE、開発案件やプロジェクト経験を広く積みたいなら SIer が合いやすいです。ただし会社差が大きいので、求人票では「担当工程」と「何に責任を持つか」まで見るのがおすすめです。
求人を見るときは、職種名だけで判断しない方がいいです。
社内SEでも、実態はヘルプデスク中心の場合もあれば、内製開発をかなりやる会社もあります。
SIerでも、上流工程中心、開発中心、運用保守中心、特定パッケージ導入中心などで経験はかなり違います。
見るべきなのは、たとえば次です。
- 自分で開発するのか、ベンダー管理が中心なのか
- 要件定義から関われるのか
- 運用保守が中心なのか
- 顧客折衝や社内調整がどれくらいあるのか
- 扱うシステムの規模や技術スタックは何か
ここを見ないと、社内SEだと思ったら問い合わせ対応が中心だった、SIerで開発できると思ったら調整ばかりだった となりやすいです。
まとめ
社内SE と SIer の違いは、技術力の上下ではなく、立ち位置の違いです。
社内SEは、自社の業務を内側から見て、安定運用と改善を進める仕事です。
SIerは、顧客のシステムを外部から支援し、要件を成果物として形にする仕事です。
どちらにも面白さがあります。
大事なのは、名前だけで選ばず、誰の課題を解くのか どこまで作るのか 何に責任を持つのか を見て、自分に合う働き方を選ぶことです。
関連して、社内システムや業務改善の見方まで広げたい場合は、社内の業務システムに必要なセキュリティ対策は？どこまでやるべきかを整理 も近いテーマです。
参考情報
- 厚生労働省 職業情報提供サイト job tag: 職業情報提供サイト（日本版O-NET）