日本的 IT 落后吗？

常有人说日本的 IT 落后。我的回答是：是，也不是。

不缺优秀的工程师

日本工程师对 IT 业界的贡献并不小。QR 码是 Denso Wave 的原昌宏主持开发、1994 年发布的；Ruby 是松本行弘在 1995 年发布的；软件开发里的 Lean 和看板，也源自丰田生产方式。日本从来不缺优秀的工程师。

当然，这些例子说明不了平均水平。我认为日本 IT 工程师的平均水平确实不如美国和中国，这和大学教育有很大关系：软件工程这门学科在日本的普及和重视都不够。但我觉得重点不在这里。美国也有不少工程师是从别的专业转行过来的，专业出身并没有挡住他们。

重点是公司的结构

真正的问题是，公司的结构没有跟上时代。

这一点从数据上也看得出来。根据 IPA（信息处理推进机构）的统计，2020 年日本的 IT 人才有 73.6% 在 IT 企业工作，在其他行业公司里的只有约四分之一；美国正好相反，2021 年在 IT 企业的只有 35.1%，大多数在使用 IT 的其他行业公司里。也就是说，很多日本公司自己没有工程团队，系统交给 SIer 去做，常常还要层层外包。做决定的人离写代码的人很远，工程师也很难影响产品本身。

2026 年 11 月 2 日，GMO 互联网集团就旗下「お名前.com デスクトップクラウド」的非法访问事件召开记者会。攻击者从客户使用的远程桌面服务器入手，盗取了管理员账号；集团旗下的安全公司早在 2024 年就指出过系统的问题。但让我印象最深的不是这个安全失误本身，而是会上的一幕：负责人开始向记者说明情况时，集团代表打断了他，指责他西装的扣子没有扣上：“在道歉的场合，怎么能开着扣子？”

很难想象 Satya Nadella 或者 Elon Musk 会因为扣子打断下属，无论是在公开场合还是私下。大多数人大概也会觉得这很荒唐，可当事人显然不觉得有什么问题。在我看来，这正是很多日本 IT 公司落后的原因：严格的、以权力为中心的层级，和软件工程需要的开放、平等的环境是不相容的。

我说的层级不是工作上的汇报关系。微软和 Amazon 当然也有层级和汇报线，但那是按工作内容的分工，不是命令的层级。在那里，很多项目是自下而上诞生的；在日本公司，这种自下而上的传导很少见。根本原因是否和日本的社会、文化有关，超出了这篇文章的范围，这里不展开。可以确定的是，在强权力层级的环境里，复杂的软件工程很难展开。

理性的讨论，以及通过讨论检验知识，都需要平等的环境。Google 的 Project Aristotle 研究了 180 个团队，发现在这些团队里，决定团队效能的五个因素中，最重要的是心理安全感：成员相信，在团队里承认错误、提出问题或者新想法，不会被嘲笑或惩罚。多样性同样重要：《哈佛商业评论》上的一篇文章总结过相关研究，多元的团队更关注事实，更常重新检查事实，犯的事实错误也更少。这些正是很多日本公司缺少的。

领导者懂不懂技术

另一个区别是团队的领导者是否熟悉技术。在日本的 IT 公司里，项目经理（PM）往往处在层级的上游。美国和中国的 IT 公司不一样。在微软，我看到很多 PM（program manager）想转成写代码的工程师，却很少有工程师想转成 PM；team manager 大多也是工程师出身。

怎样理解责任

还有一点是对责任的理解。在很多日本公司里，做决策时一个重要的考虑是：这样做能不能让组织免于担责。“如果我这样做了，出了问题就不用担责任。”这可以理解，但在美国的 IT 公司里，我很少感受到这样的决策因素。

日本擅长什么

反过来看日本的强项。文化产业里，个人的贡献影响很大；重工业，比如汽车，看重团队对规则的严谨执行。软件工程需要的却是第三种东西：平等的讨论和快速的迭代。

日本 IT 业也有个人和小团队的创新。比如 Preferred Networks 开发的深度学习框架 Chainer，2015 年提出了 define-by-run 的写法，这种思路后来被深度学习研究界广泛采用。但整体要进步，团队的观念需要更新。

日本 IT 企业应该怎么做

第一，向美国顶尖的科技公司学习，组建自己的工程师团队，减少外包。系统是公司的核心能力，不应该全部交给别人。工程师在公司内部，才能离业务和产品更近，也才能对结果负责。

第二，积极吸纳海外的高技术人才，而且要明白：花高薪请来的聪明人，不是为了告诉对方该怎么做，而是为了让对方告诉我们该怎么做。

第三，也是最重要的：拥抱开放、平等的职场环境，弱化以权力为中心的层级。在职场上只关注工作本身，而不是像 GMO 集团代表那样，在道歉的记者会上关注扣子这类无关紧要的事。

第四，让懂技术的人做技术决策。给工程师一条和管理岗平行的晋升路线，让资深工程师不必转去做管理，也能得到相应的职级和待遇；技术团队的负责人，最好也是工程师出身。

第五，出了问题，复盘时不追究个人。Google 的 SRE 实践里有一条叫 blameless postmortem：复盘只找导致事故的原因，不指责任何个人或团队，并且假设每个人都是出于好意、用当时掌握的信息做了正确的事。要修的是系统和流程，不是人。大家不再害怕担责，决策才会回到“怎样做最好”，而不是“怎样做最不会出错”。

我写这些不是为了指责，而是想指出可以改进的地方。