日本 IT 行业地图：SIer、SES、Web 系和自社开发到底在分什么

先把几条轴分开#

日本标准产业分类里，并没有“Web 系”或者“自社开发”这样的正式行业。

2023 年修订的分类把软件业分成受托开发软件业、嵌入式软件业、软件产品业和游戏软件业。互联网相关业务又放在另一组分类中，例如应用服务与内容提供商就包括 ASP、SaaS 和内容分发平台。

官方统计关心一家事业所主要经营什么。求职讨论还会混入合同、组织和开发文化，因此两套说法不可能一一对应。

读招聘信息时，我觉得至少要分开看下面四件事：

1. 收入从哪里来：项目合同、软件销售、订阅、广告、交易抽成，还是公司内部预算；
2. 软件由谁拥有：客户、公司自己，还是集团内的其他法人；
3. 谁决定需求和 Roadmap：客户、产品团队、业务部门，还是总部的信息系统部门；
4. 工程师在哪里工作、由谁管理：自社团队、客户现场、共同项目组，或者劳动者派遣关系。

把常见词放回这些维度，大致可以得到下面这张表：

后面的所有区别，基本都可以从这四条轴展开。

SIer 为什么在日本这么常见#

SIer 是 System Integrator 的日式简称。它面向银行、保险、制造、铁路、通信、政府等客户，负责把业务需求变成可以运行的信息系统。

这里的“系统集成”通常不只包括写程序。一个大型项目可能从企划和需求定义开始，继续覆盖架构、软件开发、硬件和网络采购、测试、数据迁移、供应商协调，再到上线后的运维。

JISA 在《2024 年版信息服务产业基本统计调查》中，把 SI Service 定义为一揽子提供系统构建的服务，其中可以包含硬件、企划、咨询和需求定义。在这份面向 JISA 会员企业的调查样本里，SI Service 占受访企业信息服务销售额的 51.0%。这个数字不能直接当作整个日本 IT 市场的份额，不过已经足够说明 SI 在日本信息服务产业里的存在感。

这种结构和日本大型企业长期以来的 IT 采购方式有关。客户企业掌握业务，把系统建设交给外部 IT Vendor；Vendor 再根据规模和专业领域，与多家 Partner 企业共同交付。常见结构类似这样：

1
客户企业
2
   ↓
3
负责总体项目的 Prime SIer
4
   ↓
5
负责具体系统或模块的 Partner 企业
6
   ↓
7
更下游的供应商

项目不一定都有三四层，但再委托确实存在。日本中小企业厅在《2020 年版中小企业白皮书》介绍 SCSK 的案例时提到，IT 项目经常由自社人员和 Partner 企业共同完成；人力不足时继续外包，会出现再委托和再再委托。

这也解释了为什么不能把日本的大型 SIer 直接翻译成中国语境里的“外包公司”。Prime SIer 往往直接面对客户，负责大型预算、需求定义、架构、交付和长期运维。金融核心系统、铁路票务或者政府基础设施的复杂度，也和做一个短期网站项目不是一回事。

问题在于，同一个 SI 项目里的不同位置，工作内容可以差得非常远。

Prime 一侧的工程师可能花较多时间理解业务、设计系统、协调供应商和管理项目；具体实现可能由内部团队完成，也可能交给 Partner。下游企业更接近编码和测试，但能接触多少客户背景、架构决策和后续运维，又取决于合同范围。

所以“这家公司是不是 SIer”只解决了第一个问题。继续看岗位时，还需要确认：

• 公司通常是 Prime、二次承包，还是更下游的参与者；
• 新卒工程师实际编码的比例；
• 需求定义、架构、测试和运维分别由谁负责；
• 自社员工与 Partner 如何分工；
• 配属按行业、客户还是技术栈决定；
• 一个项目结束以后，工程师怎样进入下一个项目。

NTT DATA、NRI、Fujitsu、NEC 这类大型企业都可能被放进 SIer 的范围，但它们的业务早已不只是一种。以 NTT DATA 的官方说明为例，其业务从咨询延伸到系统建设和运维；NRI 也同时经营咨询、系统集成和面向金融机构的平台服务。公司标签只能提供入口，最后还是要落到部门和职种。

受托开发不一定是大型 SI#

受託開発的范围比 SIer 更宽。

按照日本标准产业分类，受托开发软件业是根据客户委托开发程序，并提供相关调查、分析、建议或一揽子服务。系统集成属于其中的例子，但受托开发也可能只是：

• 为一家企业开发网站或移动 App；
• 承担大型系统里的某个模块；
• 给硬件厂商开发配套软件；
• 根据现有设计稿完成实现；
• 维护客户已经上线的系统。

一家几十人的开发公司和大型 Prime SIer 都可能有受托业务，但项目规模、客户关系和工程师的责任范围完全不同。

受托项目通常有清楚的客户和交付边界。它的优势是能接触不同业务和技术，也容易在短时间内积累多个项目。相应地，项目什么时候结束、后续维护归谁、需求和技术方案能否由团队共同决定，会受到合同影响。

看这类岗位时，我会特别确认公司是否直接面对最终客户，工程师能不能参加需求和设计，以及项目之间如何切换。比起“受托开发”四个字，这些信息更接近日常工作。

SES 到底是什么#

SES 通常展开为 System Engineering Service。企业使用这个词时，多半是指向客户项目提供工程能力，工程师会在客户项目或客户现场工作。

它是商业上的常用称呼，不对应唯一一种法律合同。实际项目可能采用劳动者派遣、準委任、承揽（請負）等形式，一家公司也可能同时经营 SES、受托开发和自社产品。

厚生劳动省对劳动者派遣的定义是：工程师和派遣元存在雇佣关系，在派遣先的指挥命令下工作。承揽则由承接公司自己管理员工，并独立完成约定业务。两者最关键的差别之一，就是客户是否直接对工程师发出工作指令。

合同标题也不是最终依据。厚生劳动省明确说明，派遣与承揽要根据实际工作状态判断。名义上签的是請負，实际上却由发包方直接管理承接公司的员工，就可能构成偽装請負。

对求职者而言，合规只是底线。影响几年工作体验的还有很多更具体的问题：

• 劳动合同和哪家公司签；
• 日常任务由自社上司还是客户分配；
• 以个人身份进入现场，还是有完整的自社团队；
• 项目、技术和工作地点有多少选择权；
• 没有项目时工资和培训怎样安排；
• 绩效、晋升和职业指导由谁负责；
• 更换客户以后，技术方向能否连续积累。

不同 SES 公司的差异很大。有的公司能提供稳定团队、培训和相对清楚的项目选择，也有的主要依赖把个人派往不同现场。只凭“SES”给所有岗位下结论，会漏掉这些差别；完全忽略合同和指挥关系，同样会承担不必要的风险。

SaaS、Web 系和自社开发为什么总被放在一起#

这三个词经常共同出现在 Product Tech 求职中，不过它们描述的是三件事。

情シス，以及正在增加的内制团队#

除了 IT 公司，银行、制造、零售、铁路、商社等事业公司本身也会招聘 IT 人才。岗位可能属于传统的信息系统部门，也可能放在 Digital、DX、数据平台或某个产品团队里。

情シス常见的职责包括：

• 内部账号、设备、网络和 Help Desk；
• ERP、财务、人事等企业系统；
• 安全、合规与 IT 治理；
• 供应商选择、采购和项目管理；
• 数据平台和业务数字化；
• 内部工具或面向客户的数字服务。

这份清单跨度很大。有的岗位以采购、需求整理和 Vendor 管理为主，代码主要由外部 SIer 完成；有的事业公司已经建立内部工程组织，拥有代码库、技术职级和产品 Roadmap。公司属于金融或制造业，无法直接判断工程师到底写不写代码。

IPA 的《DX 动向 2025》比较了日本、美国和德国企业的系统开发来源。在核心业务与竞争领域，日本企业选择最多的是外部委托开发，比例接近四成；美国企业选择最多的是内部自研，接近五成。

同一调查中，日本只有 16.7% 的企业回答所需部分已经完成内制化，不到美国和德国的一半。日本企业选择今后继续使用外部开发、不推进内制化的比例也更高。另一方面，推动内制的企业普遍遇到人才获取和培养问题。

这些数据和日本 SIer 的规模是互相对应的：大量事业公司过去把系统建设交给外部 Vendor，现在其中一部分又希望把关键领域的开发能力收回内部。于是招聘市场上会同时看到传统情シス、DX 推进岗位和更接近互联网公司的产品工程团队。

“内制”本身也有程度差异。企业可能只保留企划和架构，也可能从产品经理到工程、SRE 和数据团队全部自建。招聘材料里写着内製化推進时，最好继续确认现在已经有哪些内部团队，而不只是未来计划。

IT 咨询和 SIer 的边界越来越模糊#

IT 咨询通常从经营战略、业务流程、数据、云、安全或系统架构切入，帮助客户定义问题、选择方案并推动变革。SIer 则更常从系统建设和交付的角度被理解。

实际项目不会总在 PPT 和代码之间画出一条清楚的线。咨询公司可以继续参与系统导入、数据迁移和变革管理，大型 SIer 也不断往企划和咨询延伸。NTT DATA对自身业务的说明就覆盖咨询、系统建设和运维；NRI同时经营咨询、IT Solution 和面向金融机构的长期平台。

因此，看一家“咨询公司”或者“SIer”的招聘，还是要落到具体职种：

• Strategy、Business、Technology 和 Engineering 各自交付什么；
• 工作是否包括实现、上线和长期运维；
• 日常主要产出分析、文档、代码、架构还是项目管理；
• 是否按照职种招聘和晋升；
• 新卒入社后会不会统一配属。

同一家公司里的 Consultant、Application Engineer、Cloud Engineer 和 Project Manager，虽然服务同一个客户，几年后积累的能力并不相同。

メーカー不只有嵌入式#

制造业的软件岗位很容易被简化成嵌入式开发。汽车、相机、家电、机器人和工业设备里确实有大量嵌入式软件，但现在的メーカー同样需要移动 App、云端服务、数据、AI、安全和内部 IT。

例如一个联网设备可能同时涉及：

1
设备固件
2
   ↕
3
手机 App
4
   ↕
5
云端 API 与账号系统
6
   ↕
7
数据平台和运营后台

这些部分可以由制造商内部团队开发，也可以交给集团 IT 公司、SIer 或受托开发企业。即使招聘页面写的是同一个产品，不同岗位仍可能处在完全不同的法人和合同关系里。

制造业软件常常需要处理软硬件协作、更长的产品周期、设备测试、功能安全和严格的发布流程。它和互联网产品的节奏不同，但不代表技术工作简单或落后。对于想做 Robotics、Automotive、IoT 或 Apple 平台配套应用的人，这一块反而可能同时用到软件和具体领域知识。

通信、云和基础设施公司又是另一组。它们提供网络、数据中心、云平台、安全和托管服务，岗位可能涉及分布式系统、SRE、网络、平台开发和大规模运维。部分公司也会承接企业客户项目，因此仍可能和 SI 业务重叠。

同样叫 Engineer，实际可能是五份不同的工作#

假设五份招聘都写着要开发 iOS App，使用 Swift。只看技术栈，它们似乎属于同一类岗位：

1. 互联网产品公司：App 是公司的主要产品之一，团队持续看用户数据、线上事故和版本迭代；
2. B2B SaaS 公司：App 配合企业服务，重点可能是账号、权限、安全、离线能力和客户工作流；
3. SIer 或受托开发公司：为银行、零售或制造业客户交付 App，项目范围和技术选择受客户合同影响；
4. SES 公司：入社后被分配到某个客户的移动端项目，团队和工作地点随项目变化；
5. メーカー内部团队：App 是硬件产品的一部分，需要和设备、固件及较长的发布周期配合。

五份工作都可能写 Swift，也都可能产出质量很高的 App。区别主要在产品决策权、项目生命周期、用户反馈怎样回到团队，以及下一个版本是不是还由同一批人负责。

这也是为什么我现在看岗位时，不会只搜索“iOS エンジニア”。技术栈可以确认眼前写什么代码，组织和商业关系决定这段经验最后会长成什么样。

实际怎么读一份招聘信息#

把公司放进某个行业类别，只完成了粗筛。接下来可以按下面的顺序继续看。

这张地图怎么用#

日本 IT 行业很难画成一棵整齐的分类树。SIer、SES 和受托开发涉及业务与合同，SaaS 是产品提供方式，Web 系是求职市场称呼，自社开发描述软件归属，情シス则是组织位置。同一家公司同时落在几个区域里很常见。

这些标签适合用来快速理解一家公司的收入来源和项目位置，不能代替对岗位的调查。看到 SIer，不必立即理解成“不写代码”；看到自社开发，也不能默认一定有成熟的产品团队。部门、职种、合同和配属方式，通常比公司首页上的分类更具体。

对我自己来说，这张地图最后把求职范围收敛到了 Product Tech 和 Apple Platform。原因很简单：我希望持续维护同一套产品和代码库，也希望上线后的性能、体验和用户反馈还能回到自己的团队。这个偏好不构成行业排名，只是决定了我应该优先找什么环境。

如果以后考虑大型系统、行业数字化、客户变革或者基础设施，地图上的其他区域也各有对应路径。先搞清楚一份工作处于什么关系里，再比较公司名和待遇，至少不容易被几个相似的招聘词带偏。

参考资料#

• 日本标准产业分类：受托开发软件业
• 日本标准产业分类：嵌入式软件业
• 日本标准产业分类：软件产品业
• 日本标准产业分类：应用服务与内容提供商
• JISA《2024 年版信息服务产业基本统计调查》
• IPA《DX 动向 2025》
• 厚生劳动省：什么是劳动者派遣
• 厚生劳动省：劳动者派遣与承揽（請負）的区分
• 中小企业厅《2020 年版中小企业白皮书》：交易关系
• NTT DATA 企业信息
• NRI：咨询与 IT Solution 的结合
• LINEヤフー公司信息