【敏捷FAQ 第3回】如何应对升级项目中的“现有功能保证”？

 感谢您阅读本文。我是隶属于敏捷小组的藤井智弘。

 决策的不断积累终将成为习惯。一旦成为习惯，就无人再提出质疑。这就是沿袭先例，是“思维停止”的极致。接下来三篇文章将探讨其中一项议题：升级项目中的“现有功能保证”。要应对这一议题，需要从三个视角出发，我们将其作为子主题，分三次进行探讨。

• 第3篇（本文）: 审视“现有”的实质
• 第4篇: 构建可达成一致的“整体概貌”
• 第5篇: 验证、制定预算并分配

 这三篇文章的目标是“在读者所在的工作场所掀起波澜”。“升级项目就该这样”“敏捷就应该那样”——各种既定说辞正在让我们的思考停滞。是时候对它们投去怀疑的目光，“真的做不到吗？我们来好好想一次吧”。
 此外，回到现实，你会发现能够渗透到审批或合同环节的敏捷推进方式，或让公司流程容许敏捷——这样的现场恐怕非常罕见。希望你将这三篇文章视为在此背景下，重新设计流程的一例示范。

 我们部门的工作主要是现有系统的升级项目。最近一项项目定下了“使用敏捷方式推进”的方针，但坦率地说，我并不明白这样做的好处在哪里。
 发包方理所当然地将“现有功能保证”作为前提推进讨论。但并没有把握现有系统全功能的手段。依赖的文档也无法保证齐全，即便齐全也无法保证与实际系统一致。即使在瀑布式开发中都很吃力，敏捷开发本应是“不在一开始就确定所有功能”的推进方式。要求确定全部功能的发包方与不事先确定全部功能的敏捷开发——两者根本契合不了，那种强烈的违和感难以消除。
 在“要你保证，但目标全貌却不知道”的情况下，应该如何以敏捷方式应对呢？

 不错，这种“违和感”正是关键。首先，请好好珍视这种不适和疑问。

 即便在JUAS的「企業IT動向調査2026」中，IT预算增长的原因也被列为“现有系统·基础设施的刷新、更新与增强”——该提问的背景正是业界的真实写照。
 在此类项目中，“现有功能保证”成为了一句“魔法咒语”，在对目标全貌一无所知的情况下，却承诺全功能的保证。然而，其实质不过是“需求未知”的另一种表达。配合合同不合格责任（以前的“瑕疵担保”），发包方便能将风险转嫁给承包方。

…有点过于刺激了吗？

 麻烦在于，这种模糊的措辞被用作判定标准。对于在“不清楚什么算与现状一致”的情况下做出全功能保证的承诺，只要不改变承诺的内容，无论合同形式如何巧妙安排，实际上都无从履行。一边坚称“做不到就麻烦了”，一边为了拿到合同而装作“可以做到”，泥潭难以避免。

 坦诚地承认“做不到的就是做不到”，才是解决的起点。

 回到“我看不到好处”这一问题……我认为，不仅有好处，升级项目恰恰是敏捷的理想场景。关键在于，将模糊不清的事物转化为可管理的形式。

 那么，“现有”究竟指的是什么呢？我们就从这里开始。

 首先，“与现有一致”究竟指的是什么？
 根本问题在于，所谓“现有规范”实际上是三种完全不同要素的混合体。

1. 写在纸上的内容（成文的规范）
    指在设计文档、规范文档中在“某一时点”记录下来的内容。在某一时点可能与实际系统一致，但无法保证与最新版本相符。拥有这些纸质文档的通常是发包方以及承包方的估算负责人。
2. 代码的实际行为（已实现的行为）
    指代码真实运行时的行为。与规范文档的差异——漏洞修复、现场应对的改造、本未被文档化的功能——也包括在内。拥有这些信息（或能阅读代码）的人，正是负责维护的开发者。
3. 人们的实际操作（现场的使用方式）
    指用户如何使用该系统以开展业务。包括手册之外的操作流程、为避开已知缺陷而在现场采用的运行技巧。上次升级时未纳入系统、需要人工补充的业务流程也属于此范畴，但既不会留在代码中，也不会记录在规范文档里。知晓这些内容的只有现场使用者，对他们而言这并非“规范”，而只是日常操作，因此不主动提及，除非有人询问。

 提到“现有功能保证”时，发包方真正想要维护的是第3项“人们的实际操作”。然而，合同和验收所依据的是第1项“纸上内容”，而实际迁移工作的对接对象则是第2项“代码行为”。这三者在发布当天大体一致，而随着时间推移产生偏差。

• 在故障应对的紧急改造中，只有代码发生变更
• 在法律修订或组织调整中，在系统改造预算到位前，现场运维先行应对
• 纸质文档则被搁置到“下一次重大改造时一起修订”

 上述做法在当时都是合理选择。不断累积后，随着时间推移，三者便逐渐分离。这并非责任人疏忽或努力不够，而是理所当然的结果。正是这种偏差，导致升级项目中“明明所有测试都通过，却在发布后业务中断”的事故频繁发生，这是结构层面的原因。

 三者并未一致。然而，在估算和合同环节被摆在桌面上的只有纸质文档。发包方没有掌握全貌的手段，承包方高层没有足够信息，而掌握信息的最末端人员却无从发声。
无人拥有全貌，却人人承诺全貌
——这就是开头所说“无从履行”承诺的真相（为何会一直如此，我们将在最后探讨）。

 如果无法在每个行为的粒度上掌握全貌，那么在该粒度下只能“边发现边推进”。这正是敏捷核心的经验主义——试一试、观察，再调整下一步。

 在本系列的第2篇中，我们将项目分为“新开发类”“维护类”，第3类则是“升级类”。升级类具有以下特性。

• 无法指望文档的完整性，未知事项众多
• 有实物作为验证对象，可以进行对照检验
• 若一次性切换失败，业务将会中断

 这些特性均契合“小步验证、持续积累”的推进方式。人们常以“既然有现有系统，就能罗列出所有功能，所以瀑布式更安全”为理由，但实际上那只是“以为能罗列出来”的错觉。这一前提本身与升级类特性并不相容。

 如何解决“需要全览”和“不应事先确定全览”之间的对立？将模糊的“全览”转化为可管理的形式。

将“对全功能的默认保证”重构为“已验证列表＋剩余风险”
 将“全览”不再视为“最初就应掌握的最终整体”，而是重新定义为通过验证逐步扩充的列表。首要任务并非技术实施，而是就“保证范围”进行再定义的谈判。不妨将“现有功能保证”拆分为“已验证功能列表（保证范围）”与“未验证/未发现区域”进行管理；并将未验证/未发现区域视为风险公开，发现后立即应对。

 关键在于，将后续发现的规范视为“理所当然会发生”，而非“遗漏罗列的责任”。关于剩余风险最终由谁承担，必须在重构之初就明确（答案因组织而异）。随着每个迭代中已验证列表的增长和剩余风险的减少，进度即成为保证范围扩大的直观呈现。
 但仅靠这一重构，仍无法满足发包方所要求的“全览”。已验证列表会持续增长，但何时才算完成？——因为没有分母。上述重构所回应的是“全览”背后的真实诉求——“业务不中断”。只要优先验证对业务影响最大的功能，就能按业务重要性将关键环节纳入保证范围。然而，发包方仍会提出“想要看到整体进度到何种程度”这一合理诉求。这个分母——以何种粒度构建整体概貌——将是下篇的主题。

不要将估算明细直接套用到保证条款中
 “预算容器”（在审批流程中确定的总金额及期限）与“保证范围”（在合同中承诺的“与现有一致”对象）是两回事。预算固化本身并非问题，问题在于审批文件中的“现有功能保证”措辞被直接滑入合同保证条款。为制作预算容器，不需以每个行为的粒度罗列全功能（何种粒度可用于计数，将在第4篇讨论；预算容器的构建与分配，则在第5篇讨论）。估算明细仅作“参考”，不要将其纳入合同保证文案。能否划清此界限，将决定项目后半段的气氛。

与发包方负责人共享内部汇报词汇
 避免使用过于敏捷化的术语，改用“已验证列表”“剩余风险”“业务影响顺序”等，方便负责人向上级及利益相关者说明进度。若将提案书和例行报告以这些词汇编写，负责人即可直接带回公司汇报。在总包与分包之间亦同，所转抄的将不再是“现有功能保证”五个字，而是已验证列表和剩余风险。建议将本文提及的调研作为“与对方一同研读”的资料带入，而非纯粹的说服工具。

开发者今天能做的事——试着将事故分为三类
 无法参与合同或谈判环节的开发者——尤其是处于多重分包最底层、承担最重负荷的同学——也有可做之事。请将最近那次“本应与现有一致却出现差异”的事件，按纸、代码、人员三者的不一致进行分类。仅这个分类术语，就能让故障报告不再止步于“测试遗漏”，而变为“纸、代码、人员的偏差”，成为团队开启本文讨论的切入点。

 现场人士或多或少都意识到三者并不一致。然而，纸质文档依旧被当作唯一依据，这背后有其合理原因（见图3）。

 最初选择“现有功能保证”这一格式或措辞的判断，当时应是合理且保守的——从开放化与精简化浪潮算起，约在三十年前。问题在于，当时的灵活应对并不一定能以知识的形式传承。凭借全功能保证成功度过的项目，就会作为“此格式有效”的成功案例保留在审批前例中；而那些放宽保证范围反而获得成功的案例，则不会留在格式文本里。因此，每次选择都会逐步偏向保守，在无从审视的环境下，即便负责人更替，格式依然沿用。正因如此，承载着“目标不明全功能保证”的项目才得以跨代再生产。

 让思维停滞的词语在承包方也存在。提问者也曾说过“敏捷不会预先确定所有功能”。此外，双方共有的“确定”这一词本身，也值得质疑。

 瀑布式也并非真正将需求确定下来。需求是会变化的。只是，变化会影响估算金额，因此需要通过类似变更管理委员会的重决策流程（至少在PMBOK的理念中是如此）。这种流程的繁重促使人们倾向于“尽量不变更”，最终看起来就像需求被确定了一样。

 那么，真正的问题不在于“能否确定所有功能”，而是“在哪个范围内走重流程，在哪个范围内保留无流程可变更的余地”。要以何种粒度划定这条界线，才能与发包方就“整体概貌”达成共识？下篇将深入探讨“功能”这一词的粒度问题。

下篇预告：如何在不确定全部功能的情况下，为升级项目编制估算？