日本のIT業界地図：SIer、SES、Web系、自社開発は何が違うのか

日本でIT企業を調べ始めてから、求人サイトで比較されている言葉の多くが、同じ分類軸にないことに気づくまで少し時間がかかった。

SIer、SES、受託開発、SaaS、Web系、自社開発、情シス、ITコンサル。一見すると8つの進路に見えるが、実際には重なっている。SIerが自社SaaSを運営することもあれば、メーカーが大きな社内開発組織を持つこともある。自社プロダクト企業でも、開発の一部を外部へ委託する。

日本のIT業界が最初に分かりにくい理由はここにある。会社がどう売上を得るかを表す言葉もあれば、ソフトウェアの所有者、プロジェクトへの参加方法、採用や開発の文化を表す言葉もある。会社のラベルを覚えるだけでは、入社後の仕事までは分からない。

この記事では、それらをいったん別々に整理する。会社の順位付けはしないし、すべての企業を排他的な箱に入れるつもりもない。それぞれの言葉が何を説明し、個別の求人では何を追加で確認すべきかを見る。

まず分類軸を分ける#

日本標準産業分類には、「Web系」や「自社開発」という区分はない。

2023年改定の分類では、ソフトウェア業を受託開発ソフトウェア業、組込みソフトウェア業、パッケージソフトウェア業、ゲームソフトウェア業に分けている。インターネット関連事業は別の分類にあり、アプリケーション・サービス・コンテンツ・プロバイダにはASP、SaaS、コンテンツ配信プラットフォームなどが含まれる。

公的統計は、事業所が主にどの事業を営むかで分類する。一方、就活では契約、組織構造、開発文化まで同時に語られるため、両者はきれいに対応しない。

求人を見るときは、少なくとも次の4点を分けると理解しやすい。

売上はどこから来るか：プロジェクト契約、ソフトウェア販売、サブスクリプション、広告、取引手数料、社内予算のどれか。
ソフトウェアは誰のものか：顧客、自社、または同じグループの別法人か。
要件とロードマップを誰が決めるか：顧客、プロダクトチーム、事業部門、本社の情報システム部門か。
エンジニアはどこで働き、誰が管理するか：自社チーム、顧客先、共同プロジェクト、労働者派遣のどれか。

よく見る言葉をこの4軸に戻すと、おおよそ次のようになる。

言葉	主に説明するもの	それだけでは分からないこと
SIer	顧客向けにシステムを企画、構築、統合する事業	エンジニアが実装するか、商流のどこにいるか
受託開発	特定顧客から依頼を受けたソフトウェア開発	プロジェクト規模、顧客先常駐の有無
SES	顧客プロジェクトへ技術力を提供する事業上の呼び方	法的な契約、指揮命令、チーム構成
SaaS	ネットワーク経由で継続提供するプロダクトの形態	完全内製か、開発文化がどうか
Web系	インターネット企業と開発文化をまとめた就活上の呼び方	統一された公的定義はない
自社開発	自社が所有または運営するソフトウェアの開発	一部を外注するか、プロダクトが事業の中心か
情シス	事業会社内の情報システム機能	ヘルプデスク、ベンダー管理、プロダクト開発のどれか
ITコンサル	経営、業務、技術課題に対する提案と実行支援	実装、導入、長期運用まで担当するか
メーカー	主な事業が製造業である雇用主	組込み、モバイル、クラウド、社内ITのどれか

このあとの業界地図は、ほぼこの4つの問いから展開できる。

日本でSIerの存在感が大きい理由#

SIerはSystem Integratorの和製略称である。銀行、保険、製造、鉄道、通信、行政などの顧客に対し、業務要件を実際に動く情報システムへ落とし込む。

ここでいうSystem Integrationは、プログラムを書くことだけではない。大規模プロジェクトなら、企画と要件定義から始まり、アーキテクチャ、ソフトウェア開発、ハードウェアとネットワークの調達、テスト、データ移行、ベンダー調整、リリース後の運用まで含まれる。

JISAの『2024年版情報サービス産業基本統計調査』では、SI Serviceをハードウェア、企画、コンサルティング、要件定義などを含めてシステム構築を一括提供するサービスと定義している。JISA会員企業の回答サンプルでは、SI Serviceが情報サービス売上高の51.0%を占めた。日本のIT市場全体のシェアを示す数字ではないが、情報サービス産業におけるSIの大きさは分かる。

この構造は、日本の大企業が長年採用してきたIT調達の方法と関係している。顧客企業が業務知識を持ち、システム構築を外部のITベンダーへ依頼する。ベンダーは規模や専門分野に応じて複数のパートナー企業と一緒に納品する。よくある構造は次のようになる。

1
顧客企業
2
   ↓
3
プロジェクト全体を担当するプライムSIer
4
   ↓
5
個別システムやモジュールを担当するパートナー企業
6
   ↓
7
さらに専門的、または下流のサプライヤー

すべての案件が3層、4層になるわけではないが、再委託は存在する。中小企業庁の『2020年版中小企業白書』にあるSCSKの事例では、ITプロジェクトを自社社員とパートナー企業で共同遂行し、さらに人手が足りなければ再委託、再々委託が生まれることに触れている。

日本の大手SIerを、単純に低単価の外注会社と同じものとして扱えない理由もここにある。プライムSIerは顧客と直接向き合い、大きな予算、要件、アーキテクチャ、納品、長期運用を担当することがある。銀行の勘定系、鉄道の発券、行政システムは、短期のWeb制作とも性質が違う。

ただし、同じSIプロジェクトでも、商流上の位置によって仕事内容は大きく変わる。

プライム側のエンジニアは、業務理解、システム設計、サプライヤー調整、プロジェクト管理に多くの時間を使うかもしれない。実装は社内で行う場合も、パートナーへ委託する場合もある。下流企業は実装やテストに近くなる一方、顧客の背景、アーキテクチャの決定、長期運用にどこまで触れられるかは契約次第になる。

したがって、「この会社はSIerか」だけでは情報が足りない。求人では次も確認したい。

普段はプライム、二次請け、さらに下流のどこにいるか。
新卒エンジニアが実装に使う時間。
要件定義、アーキテクチャ、テスト、運用を誰が担当するか。
自社社員とパートナー企業の分担。
業界、顧客、技術のどれを基準に配属するか。
プロジェクト終了後に次の案件へどう移るか。

NTT DATA、NRI、Fujitsu、NECなどは広い意味でSIerに入るが、どの会社も一種類の事業だけをしているわけではない。NTT DATAの説明はコンサルティングからシステム構築、運用までを含む。NRIもコンサルティング、System Integration、金融機関向けの長期プラットフォームを組み合わせている。会社分類は入口として使い、最後は部門と職種を見る必要がある。

受託開発は大規模SIより広い#

受託開発の範囲はSIより広い。

日本標準産業分類では、顧客から委託を受けてプログラムを開発し、関連する調査、分析、助言、一括サービスを提供する事業を受託開発ソフトウェア業としている。System Integrationもその一例だが、受託案件には次のようなものもある。

一社向けのWebサイトやモバイルアプリを作る。
大規模システムの一モジュールを担当する。
ハードウェアベンダー向けの関連ソフトウェアを開発する。
既存のデザインと要件に沿って実装する。
稼働中の顧客システムを保守、拡張する。

30人の開発会社も大手プライムSIerも受託案件を持てるが、案件規模、顧客との距離、エンジニアの責任範囲はまったく同じではない。

受託案件には、特定の顧客と納品範囲がある。短期間で複数の業務や技術に触れやすい一方、いつ案件が終わるか、その後の保守を誰が行うか、要件や技術案をチームがどこまで決められるかは契約に左右される。

この種の求人では、最終顧客と直接話すか、エンジニアが要件とデザインに参加できるか、案件間をどう移動するかを確認したい。「受託開発」という4文字より、こちらの方が日常業務に近い。

SESとは何か#

SESは一般にSystem Engineering Serviceの略とされる。企業がこの言葉を使う場合、顧客プロジェクトへエンジニアリング能力を提供し、エンジニアが顧客案件や顧客先で働く事業を指すことが多い。

ただし、SESは法律上の単一契約ではない。実際には労働者派遣、準委任、請負などがあり、一社がSES、受託開発、自社プロダクトを並行して運営する場合もある。

厚生労働省による労働者派遣の定義では、エンジニアは派遣元と雇用関係を結び、派遣先の指揮命令を受けて働く。請負では、請負会社が自社の労働者を管理し、約束した業務を独立して完成させる。顧客がエンジニアへ直接指示するかは、重要な違いの一つになる。

契約書の名前だけでも決まらない。厚生労働省は、派遣と請負を実際の就業状態に基づいて判断するとしている。契約上は請負でも、発注者が請負会社の社員を直接管理していれば、偽装請負に該当する可能性がある。

就活では、法令を守っていることが最低条件になる。そのうえで、数年間の働き方を左右する質問がある。

雇用契約をどの会社と結ぶか。
日々のタスクを自社上司と顧客のどちらが割り当てるか。
一人で現場へ入るか、自社チームとして参加するか。
案件、技術、勤務地をどこまで選べるか。
案件がない期間の給与と研修をどう扱うか。
評価、昇進、キャリア支援を誰が担当するか。
顧客が変わったあとも技術方向を継続できるか。

SES企業の差は大きい。安定したチーム、研修、案件選択を用意する会社もあれば、個人を複数の顧客先へ順番に配置することを主な事業とする会社もある。SESという言葉だけで一括評価すると違いを見落とすが、契約と指揮命令を確認しないのも危険になる。

SaaS、Web系、自社開発が一緒に語られる理由#

この3つはProduct Techの就活でまとめて出てくるが、説明している対象は違う。

SaaSは提供方法と課金モデル#

SaaSはネットワーク経由でアプリケーションを継続提供し、顧客はサブスクリプション、アカウント数、使用量などに応じて支払う。B2BにもB2Cにもなり得る。日本標準産業分類ではASPとSaaSをアプリケーション・サービス・コンテンツ・プロバイダに含めている。

一度納品して終わる案件と違い、SaaSチームは同じサービスを継続して担当する。機能改善、信頼性、セキュリティ、カスタマーサポート、データ移行、クラウドコストがプロダクト組織へ戻ってくる。B2B SaaSなら、導入、権限、監査、外部システム連携、顧客固有のワークフローも重要になる。

とはいえ、SaaSが説明するのはサービス形態までである。成熟した開発文化や完全内製を保証しない。標準化されたプロダクトもあれば、顧客ごとの導入とカスタマイズ対応が多い事業もある。

Web系は就活市場の呼び方#

Web系には統一された公的定義がない。日本の就活では、インターネット経由でプロダクトを提供し、Web開発と継続運営を中心に置く会社を指すことが多い。

検索、コンテンツ、SNS、EC、マーケットプレイス、広告、ゲームなどが含まれる。LINEヤフーも検索、ポータル、メッセージング、広告、ECを同時に運営しており、一つのプロダクト分類では説明できない。

この言葉には、職種別採用、エンジニアのプロダクト改善への参加、継続的デリバリー、技術ブログ、中途採用市場の活発さ、といった文化的な印象も含まれる。ただし必須条件ではなく、同じ会社でも事業部によって差がある。

自社開発はソフトウェアの所有者を表す#

自社開発は通常、自社が所有、運営、販売するソフトウェアを開発することを指す。納品で仕事が終わらず、障害、ユーザーからのフィードバック、性能、次のリリースにも同じ組織が向き合う。

すべてのコードを正社員だけで書くという意味ではない。プロダクト企業もテスト、導入支援、社内システム、一部機能を外注できる。グループIT会社が親会社所有のソフトウェアを作ることもある。SIerも自社製品、業界プラットフォーム、SaaSを運営する。

自社開発という言葉から確認したいのは、会社がプロダクトの決定権を持つか、エンジニアがコードベース、本番環境での結果、ユーザーからのフィードバックへ継続して触れられるかである。環境の良し悪しは、プロダクトが事業で占める位置、チーム、個別職種によって変わる。

自分の就活では、Sansan、freee、SmartHRのようなB2B SaaSと、LINEヤフー、Mercari、DeNA、ZOZOなどのコンシューマー企業を、広い意味でProduct Techにまとめている。日本の公式分類ではない。ソフトウェアが事業の中心にあり、プロダクト、デザイン、エンジニアリング、データ、運用が長期で改善する会社を扱いやすくするための呼び方である。

情シスと増えつつある内製チーム#

銀行、メーカー、小売、鉄道、商社などの事業会社もIT人材を採用する。職種は従来の情報システム部門に置かれる場合も、デジタル、DX、データプラットフォーム、プロダクト組織に置かれる場合もある。

情シスの代表的な業務は次のとおり。

社内アカウント、デバイス、ネットワーク、ヘルプデスク。
ERP、会計、人事などの基幹システム。
セキュリティ、コンプライアンス、ITガバナンス。
ベンダー選定、調達、プロジェクト管理。
データプラットフォームと業務のデジタル化。
社内ツール、または顧客向けデジタルサービス。

かなり幅のある一覧である。調達、要件整理、ベンダー管理が中心で、コードの大部分を外部SIerが書く部門もある。リポジトリ、技術職のキャリアラダー、プロダクトのロードマップを持つ社内エンジニアリング組織を作った事業会社もある。雇用主が銀行やメーカーであることだけでは、エンジニアが実装するかは判断できない。

IPAの『DX動向2025』は、日本、米国、ドイツ企業のシステム開発方法を比較している。事業の中核領域と競争領域で、日本企業の回答が最も多かったのは外部委託開発で、4割弱だった。米国では内製が最も多く、5割弱だった。

同じ調査で、必要な領域をすでに内製化したと答えた日本企業は16.7%で、米国とドイツの半分未満だった。今後も外部開発を継続し、内製化を進めないとする日本企業も多い。内製を進める企業では、人材獲得と育成が大きな課題になっている。

これらの数字は、日本のSI産業の規模とも対応する。多くの事業会社は以前から外部ベンダーへシステム構築を依存してきたが、その一部が重要領域の開発力を社内へ戻そうとしている。そのため求人市場には、従来型情シス、DX推進職、インターネット企業に近いプロダクトエンジニアリングチームが同時に存在する。

内製にも段階がある。企画とアーキテクチャだけを社内に残す会社もあれば、プロダクトマネージャー、エンジニア、SRE、データチームまで自社で作る会社もある。求人に「内製化推進」と書かれている場合、将来計画だけでなく、現在どのチームが存在するかを確認したい。

ITコンサルとSIの境界は曖昧になっている#

ITコンサルは、経営戦略、業務プロセス、データ、クラウド、セキュリティ、システムアーキテクチャから入り、顧客が課題を定義し、方法を選び、変革を進めるのを支援する。SIerはシステム構築と納品から理解されることが多い。

実際の案件では、資料とコードの間に明確な線があるとは限らない。コンサルティングファームがシステム導入、データ移行、チェンジマネジメントまで続けることもある。大手SIerも企画とコンサルティングへ領域を広げている。NTT DATAはコンサルティング、システム構築、運用を一続きの事業として説明する。NRIもコンサルティング、ITソリューション、金融機関向け長期プラットフォームを組み合わせている。

どちらの会社を見る場合も、職種まで下りて確認する必要がある。

Strategy、Business、Technology、Engineeringの各職種が何を納品するか。
実装、リリース、長期運用を含むか。
日々の成果物が分析、資料、コード、アーキテクチャ、プロジェクト管理のどれか。
職種別に採用、評価、昇進するか。
新卒が部門をまたいで配属される可能性があるか。

同じ会社のコンサルタント、アプリケーションエンジニア、クラウドエンジニア、プロジェクトマネージャーは、同じ顧客を担当しても異なる経験を積む。

メーカーは組込みだけではない#

メーカーのソフトウェア職は、組込み開発だけで説明されがちである。自動車、カメラ、家電、ロボット、産業機器に大量の組込みソフトウェアがあるのは確かだが、現在のメーカーにはモバイルアプリ、クラウドサービス、データ、AI、セキュリティ、社内ITも必要になる。

たとえばコネクテッドデバイスには、次のすべてが関係する。

1
デバイスのファームウェア
2
      ↕
3
モバイルアプリ
4
      ↕
5
クラウドAPIとアカウントシステム
6
      ↕
7
データプラットフォームと運用コンソール

これらは社内開発の場合も、グループIT会社、SIer、受託会社が担当する場合もある。同じプロダクトの求人でも、別の法人と契約関係に置かれている可能性がある。

メーカーのソフトウェアは、ハードウェアとの連携、長い製品サイクル、デバイステスト、機能安全、厳格なリリースプロセスを扱うことが多い。インターネットプロダクトとは速度が違うが、技術的に単純、または古いという意味ではない。ロボティクス、Automotive、IoT、Apple Platformのコンパニオンアプリに興味があれば、ソフトウェアとドメイン知識を同時に使える分野になる。

通信、クラウド、インフラ企業はまた別のグループになる。ネットワーク、データセンター、クラウドプラットフォーム、セキュリティ、マネージドサービスを提供し、分散システム、SRE、ネットワーク、プラットフォーム開発、大規模運用の職種がある。企業向けIntegration案件を持つ会社もあり、その場合はSIの地図と再び重なる。

同じエンジニアでも5つの異なる仕事になる#

SwiftでiOSアプリを開発する求人が5件あるとする。技術だけを見れば、すべて同じ職種に見える。

インターネットプロダクト企業：アプリは会社の主要プロダクトの一つで、チームは利用データ、障害、継続的なリリースを見る。
B2B SaaS企業：アプリは企業向けサービスの一部で、アカウント、権限、セキュリティ、オフライン、顧客のワークフローが重要になる。
SIerまたは受託会社：銀行、小売、メーカー向けアプリを納品し、範囲と技術選定は顧客契約の影響を受ける。
SES企業：入社後に顧客のモバイル案件へ配属され、チームや勤務地が案件ごとに変わり得る。
メーカーの社内チーム：アプリはハードウェア製品の一部で、デバイス、ファームウェア、長いリリースサイクルと連携する。

5つともSwiftを使い、品質の高いアプリを作れる。違うのはプロダクトの決定権、プロジェクトの期間、ユーザーからのフィードバックがチームへ戻る経路、次のバージョンも同じメンバーが担当するかである。

今はiOS Engineerだけで求人を探さないようにしている。技術スタックから現在書くコードは分かる。組織と商流からは、その経験が数年後にどう積み上がるかが見える。

求人情報をどう読むか#

会社を一つの分類へ置くのは、最初の絞り込みにすぎない。その後は次の順番で見ると分かりやすい。

1. ユーザーは誰で、誰が支払うか#

ユーザーは消費者、契約企業、プロジェクトの発注者、社内社員のどれか。売上はサブスクリプション、広告、取引、プロジェクト契約、社内予算のどこから来るか。

これにより仕事の評価方法が変わる。消費者向けプロダクトなら継続率と体験、SaaSなら導入と契約更新、受託案件なら予算、仕様、検収条件が重要になる。

2. ロードマップと技術案を誰が決めるか#

エンジニアリングがプロダクト、デザインと一緒に次の機能を決められるか。すでに顧客と合意した要件を実装するか。技術選定はチームが持つか、顧客、グループ、本社の承認が必要か。

決定権には責任も伴う。プロダクトチームは方向を早く変えられる代わりに、指標と障害へ直接責任を持つ。大規模顧客案件は制約が多い代わりに、複雑な業務と大規模システムに触れられる。

3. リリース後に誰が責任を持つか#

検収後にチームは解散するか。性能、セキュリティ、障害、ユーザーからのフィードバック、その後の改善をどの組織が引き継ぐか。

一つのシステムを長期運用すれば、アーキテクチャの進化と技術的負債を扱う経験が増える。案件を移れば、より多くの業務と技術に触れられる。どちらが合うかは進みたい方向による。

4. エンジニアは毎日何をするか#

設計、実装、テスト、顧客対応、ドキュメント、ベンダー管理、プロジェクト管理の比率はどれくらいか。Engineer、SE、Consultantという職種名の意味は会社によって安定していない。

社員インタビュー、技術ブログ、インターンシップの内容、面接での具体的な回答が参考になる。「上流から下流まで担当」と書かれていても、新卒が最初にどこから始めるかは別に確認する必要がある。

5. チームと指揮命令はどうなっているか#

どこで働き、誰がタスクを割り当てるか。自社の完全なチーム、顧客先チーム、複数企業の合同プロジェクトのどれか。コードレビュー、評価、キャリア支援を誰が担当するか。

SESと受託職では特に重要だが、グループ会社や法人をまたぐプロジェクトでも同じである。

6. 新卒配属はどう決まるか#

iOS、バックエンド、SREへ直接応募できるか。技術職として一括採用したあとに部門を決めるか。本人希望、事業需要、研修結果、案件の空きがどの程度影響するか。社内異動は現実的か。

企業にモバイルチームがあっても、技術総合職で入社すれば必ず配属されるとは限らない。方向がすでに決まっている人にとって、配属制度は会社の事業と同じくらい重要になることがある。

7. 3年後に何が残るか#

最後に単純な質問をする。この仕事を3年続けたあと、履歴書で一番強い経験は何になるか。

大規模金融システム、顧客要件とプロジェクトの遂行、プロダクトエンジニアリング、モバイルアーキテクチャ、SRE、クラウドプラットフォーム、業界知識、組織管理などが考えられる。どの方向にもキャリア上の価値はある。次に進みたい道と接続するかが重要になる。

この地図をどう使うか#

日本のIT業界は、整った分類ツリーにはならない。SIer、SES、受託開発は事業と契約に関係し、SaaSは提供形態、Web系は就活用語、自社開発はソフトウェアの所有、情シスは組織上の位置を表す。一社が複数の領域に入るのは普通である。

これらのラベルは、売上の出所とプロジェクト上の位置を素早く理解するためには役立つ。ただし、個別職種の調査を代替できない。SIerだから実装しないとは限らず、自社開発だから成熟したプロダクトチームがあるとも限らない。部門、職種、契約、配属方法の方が、会社案内の分類より具体的である。

自分の場合、この地図を作ることで、就活範囲はProduct TechとApple Platformへ絞られてきた。同じプロダクトとコードベースを継続して保守し、性能、体験、ユーザーからのフィードバックがリリースしたチームへ戻る環境を求めているからだ。業界の順位付けではなく、自分が優先すべき環境を決めるための条件である。

大規模システム、業界のデジタル化、顧客変革、インフラに興味があれば、同じ地図の別の場所に対応する道がある。会社名と待遇を比較する前に、その仕事がどの関係に置かれているかを把握すれば、似た採用用語にも振り回されにくくなる。