速度を出すIT与保留IT的区别

はじめに

在许多企业中，IT长期以来被视为“一种默认应尽可能长期使用、一旦建成便需维护、在不破坏的前提下不断堆叠”的存在。然而，回顾成长期业务IT的发展历程，这一前提本身已引发诸多混乱。本文将以“追求速度的IT”与“用于保留的IT”在设计思想上本就不同为起点，梳理为何混淆两者会导致失败。

追求速度的IT目的明确：快速验证市场假设、及早获取客户反馈、发现成功模式。对于这类IT，能快速构建、快速变更、快速舍弃最为重要，其价值在于学习速度，而非质量或一致性。

另一方面，用于保留的IT作用恰恰相反。它旨在使决策可重现，固定业务与数据的含义，确保即使组织变动也能做出相同判断。对于这类IT，稳定性、可读性、含义一致性最为优先，其价值恰恰在于不频繁变动本身。

追求速度的IT与用于保留的IT虽常被统称为“IT”，但其优化指标截然相反。追求速度的IT“变更成本越低越好”，而用于保留的IT则“变更成本越高越好”。易于变更在探索学习阶段是利器，但在运营阶段却会成为风险。

许多企业出现问题，往往始于将原本为追求速度而构建的IT，直接作为基础平台持续使用。用于假设验证的设计、依赖人力的判断、临时规则，不知不觉中被固定为“正式机制”。

追求速度的IT本身并非问题。问题在于，“何时舍弃”、“保留什么”、“从何处重构”这些关键点，从未作为经营层面的共识被共享。没有共享舍弃前提的IT，必然会残留下来，最终成为沉重负担。

反向混淆也频繁发生：对核心系统（用于保留的IT）提出业务速度要求的时刻。此时，例外处理增加，临时方案介入，稳定性遭到损害。结果，本应保留的IT反而无法保留。

为区分追求速度的IT与用于保留的IT，经营层应把握的核心问题很简单：“这是为了学习什么而建的IT？”“这是为了固定什么而建的IT？”若不回答这些问题就推进，就会产生“既要一切快速，又要一切稳定，还要一切保留”的矛盾要求。

若不区分两者，将陷入以下状态：

这不是技术问题，而是未定义其角色的经营决策所导致的后果。

区分追求速度的IT与用于保留的IT，并非技术设计层面的讨论，而是关于“将哪部分视为实验”、“从何处开始作为基础平台”的业务阶段经营判断。下篇文章将探讨“应由谁来叫停业务推进型IT”，梳理这一切换判断应由谁、在何时做出。