委托开发的规格说明书，还要继续用 Excel 吗 ── 作为交付物的格式选择方法

「收到了修改后的规格说明书，却搞不清楚哪里改了，就这样盖章验收了」

「想委托做改造时才发现，交付的 Excel 规格说明书和现在的界面完全对不上」

「开发公司交来了方格纸状的 Excel 规格说明书，这样正常吗」

把系统开发委托给外部公司时，规格说明书・设计文档会和程序一起交付。在日本的委托开发中，这类文档非常多地用 Excel 制作，并且常常采用被称为「Excel 方格纸」的写法——把单元格切得很细，当作稿纸一样使用。

网上对 Excel 方格纸的批评并不少见，但大多数讨论的是它作为开发团队内部文档时有多难用。本文换一个角度，把焦点收窄到委托开发中交付给客户的规格说明书，用验收、规格变更、维护这些合同实务的语言，梳理问题究竟出在哪里、又该选择怎样的格式。希望内容对发包方和交付方的开发公司都有帮助。

1. 先说结论

先把要点汇总一下。

• 交付的规格说明书应该以什么格式来选，不应看「开发过程中是否好写」，而应看「客户能否评审」「能否经得起验收」「能否共享规格变更的差异」「几年后维护时是否还能用」
• 结论不是「放弃 Excel」，而是「放弃方格纸，把各种格式放回它本该发挥作用的位置」。文字说明用 Word，表格用 Excel 原本意义上的表，图示用作图工具，合意的记录用 PDF
• 在讨论格式之前，应先在合同中（个别合同对交付物的明确约定）确定哪些文档属于成果物、是否能拿到可编辑的原本

把按文档性质划分的推荐格式整理成判断表，如下所示。

下面依次说明为什么会得出这样的结论。

2. 作为交付物的 Excel 方格纸规格说明书，问题出在哪里

首先要说明一点，问题并不在于 Excel 这款软件本身。作为电子表格、一览表的工具，Excel 非常优秀，正如后文所述，在项目定义文档等场景中，Excel 正是正确答案。问题在于，把文字、图示、表格这些性质各不相同的东西，全都塞进了「方格纸」里。

如果只是公司内部文档，这不过是「写的人自己觉得麻烦」的问题。但一旦成为交付物，情况就不同了。因为规格说明书是客户支付对价换取的成果物，是验收的对象，也是此后要使用多年的资产。从交付物的角度来看，Excel 方格纸存在以下问题。

2.1 验收阶段无法充分评审

Excel 方格纸没有像 Word 修订记录那样实用的差异显示机制。准确地说，Microsoft 365 的协同编辑环境中确实有单元格更改历史（「显示更改内容」及版本历史），也存在 Spreadsheet Compare 这类用于比较工作簿的工具。但能追踪的主要是单元格的数值与公式，方格纸文档大量使用的图形・文本框中的文字并不在追踪范围内，而且在通过邮件附件来回传递文件的交付场景中，协同编辑的历史功能原本就无法发挥作用。

结果就是，当客户收到反映了评审意见的修改版时，只能靠肉眼去找「哪里变了」。每次都把几十个工作表的文档从头读一遍并不现实，实际情况往往变成凭「大概已经改好了吧」这种感觉盖章验收。

这就是验收的形骸化。验收本是「确认交付物是否符合已达成合意的内容并加以接受」的程序，一旦这个环节流于形式，日后一旦发现问题，就会演变成「不是已经验收通过了吗」「不对，交付的形式根本没法确认」这种毫无意义的争论。

2.2 规格变更的合意记录无法留存

开发过程中规格必然会发生变化。这时如果文档是 Excel 方格纸，变更的往来沟通就容易变成「一堆文件副本」。相信很多人都对 规格说明书_v2_最终_修改(2).xlsx 这样的文件名不陌生。

问题在于，事后无法确定哪一个版本才是「双方合意的版本」。当就追加费用或交期产生分歧时，作为依据的正是那份合意文档。如果连是哪一份文档都说不清楚，就会变成各说各话。

2.3 在维护阶段与实现脱节

方格纸文档的更新成本很高，因此在交付后的改造过程中会逐渐不再被更新。没人敢碰，怕一动布局就乱掉；图形中的文字又搜索不到，容易漏改——这些问题不断累积，几年后就会变成「规格说明书是有，但没人知道它是否还符合现状」的状态。

为这种状态买单的，是下一次改造的时候。如果文档靠不住，就只能从头调查实物（正在运行的系统与源代码），这部分工时会被加到报价里。文档得不到维护，最终会以未来改造费用上涨的形式反弹回来。

2.4 客户手头难以实际利用

以打印为前提设计的排版，在屏幕上很难读。而且由于内容分散在大量工作表和图形当中，全文搜索很难起作用，查找「那条规格到底写在哪里」要花不少时间。客户一方想追加运维备注、或挪用作公司内部说明资料等二次利用也很困难，好不容易付费换来的文档，往往变成「只是被保管着」而已。

3. 合同的视角 ── 规格说明书是一种「成果物」

在进入格式的讨论之前，先说一层更上位的话题。规格说明书・设计文档，只有在合同中被明确定为交付物，才会成为与程序同等的、合同意义上的成果物。反过来说，未在合同中明确的文档，并不理所当然地属于应当交付的范围。IPA 的《信息系统模型交易・合同》也是采用在个别合同中明确交付物、并约定验收方法与期限的结构。关于该模型合同的整体框架，在另一篇文章《委托开发・运维保养的合同该如何签订 ── 借鉴 IPA〈模型交易・合同〉学习准委托与承揽的选用》中有详细说明。

也就是说，Excel 还是 Word 这类格式上的讨论，只有在以下这些基础都已确定之后，才真正有意义。

• 哪些文档属于成果物：不是笼统的「一整套文档」，而是要具体列到文档名称这一级别
• 以什么形式接收：是否包含可编辑的原本（Word 或 Excel 文件）。只有 PDF 会在维护阶段造成困扰
• 验收的方法：确认哪些内容才算接受。修改版的差异该如何呈现
• 著作权・二次利用的处理：客户能否在公司内部复制、修改。将来把维护委托给另一家公司时，能否把文档转交出去

如果合同里没有确定这些，那么无论选择多么完善的格式，都会在「这份文档到底算不算交付对象」这个问题上产生纠纷。关于发包前应梳理的事项，也可以参考《委托开发 Windows 应用程序前该梳理的事项》。

4. 交付格式的选项 ── 以「能否成立为交付物」来比较

基础确定之后，就可以选择格式了。评价维度正如开头所说，共有 4 个：客户的可读性 / 评审与验收的便利性 / 规格变更的差异管理 / 维护阶段的可持续性。

下面分别补充说明。

4.1 Word ── 以文字说明为主的规格说明书的第一选择

像概要设计文档、业务流程说明这类「用文字来讲述」的文档，本来就应该用文字处理软件来写。Word 从一开始就配齐了交付文档所需的各种工具。

• 标题样式与自动目录：文档结构变得清晰，可以从目录直接跳转到目标位置
• 修订记录（审阅功能）：修改版哪里变了，会用红字显示出来。评审与验收的实际效果完全不在一个量级
• 批注功能：客户提出的意见及其答复会保留在文档上
• 文档比较：事后也能显示两个版本之间的差异

客户一方不需要特殊工具，也不需要额外学习，直接作为交付格式就能通过，这在实务上也是一大优点。

需要注意的是，如果不使用样式，只做出「表面看起来整齐」的文档，就会掉进同一个坑里，可以称之为 Word 方格纸。标题要用标题样式，排版要用格式设置而不是连续敲空格。另外，「到底哪个是最新版」的问题在 Word 上同样会发生，因此需要与后文提到的版本管理运维方式搭配使用。

4.2 让 Excel 回归「真正的表格」

界面项目定义文档、代码一览表、权限矩阵这类文档，本质上就是表格。用 Word 来写反而不方便，Excel 才是正解。不过要用的不是方格纸，而是能当作数据来处理的规范表格。

• 一行对应一条记录，一列对应一个属性。一个工作表只放一张表
• 不用合并单元格来做排版。标题只占开头一行
• 不为了打印时的美观而破坏数据结构（打印用的样式应另想办法处理）

这样做出来的文档，在维护时就可以按机器可处理的方式来使用。像是把项目定义和实际的数据库定义进行核对、把一览表直接当作测试项目的基础等复用方式都能派上用场，「确认文档是否与实现脱节」这件事本身也会变得轻松。

4.3 PDF ── 用于冻结「已达成合意版本」的格式

PDF 不容易被随手编辑，这既是缺点，也是优点。作为规格说明书的原本，PDF 是不合格的，但作为通过验收的版本、规格变更中达成合意的版本的快照，它却很合适。由于不会被不小心改写，因此可以起到「在这个时间点我们是这样合意的」这种记录的作用。

不过严格来说，PDF 也是可以被重新制作的。它作为记录的效力，并非来自 PDF 这种格式本身，而是来自双方各自保管着同一份文件这个事实，因此请务必搭配相应的运维方式，比如通过邮件发送并连同发送记录一起留存、由双方各自在自己的环境中保管等。如果还需要在纠纷时具备证据效力，添加电子签名或时间戳也是可选项。

还有一条原则很简单：PDF 永远要和可编辑的原本配套交付。只交付 PDF，会压缩客户未来的选择空间（比如公司内部自行利用、或将维护委托给其他公司）。

4.4 以 Markdown + Git 作为原本，生成 Word / PDF 后交付

从开发公司管理的角度看，近年来越来越多地采用把规格说明书写成 Markdown，并与源代码放在同一个 Git 仓库中进行版本管理的方式。这样可以获得逐行级别的差异，能用和代码评审相同的机制来评审文档，变更的经过也会作为历史留存下来（作为开发实务的记录这已经足够，但如果还要求能作为审计或纠纷应对的证据，则需要另外配套禁止改写历史等运维措施）。

这种做法并不需要要求客户使用 Git。只要把原本用 Markdown 来管理，交付物则通过 Pandoc 等转换工具生成 Word 或 PDF，客户就仍然像以往一样只收到 Word/PDF 即可。这样能够同时兼顾开发方的管理效率与客户方的可读性。

需要注意的是，要在合同上明确「哪一方才是原本」。如果客户直接在生成出来的 Word 文件上修改，就会与原本产生分歧，因此需要事先约定好运维规则，比如修改请求通过批注提出，再由开发方反映到原本一侧。

4.5 Wiki・在线工具 ── 持续维护场景下的「活文档」

对于持续有维护合同、改造较为频繁的系统而言，用 Notion 或 Confluence 这类在线工具持续更新规格说明书，也是一种有力的方式。这种形式检索性强，变更历史会自动保留，比起「交付即结束」，更容易维持成一份「活文档」。

不过，从交付物的角度来看，需要一开始就确定好合同结束时会留下什么。比如导出格式（能否导出为 Word 或 PDF）、工作空间的所有权与费用承担方、查看账号的处理方式。如果把这些问题模糊处理，就会被特定工具锁定，存在合同一结束就同时失去文档访问权限的风险。

5. 如何推进规格变更的往来沟通

即便把格式整理好了，如果没有配套的运维方式，「到底哪个是最新版」的问题依然会重演。因为规格并不是交付完就结束了，无论是在开发中还是维护阶段，它都会持续变化。以下是推荐的基本做法。

1. 准备一份变更管理台账：用一览表记录变更编号・日期・内容・影响（费用/交期）・合意人，一行记录一项。这个台账本身用 Excel 的规范表格就足够了。让它与 IPA 模型合同的变更管理程序（参见前面提到的文章）相对应
2. 文档的修改要以能看到差异的形式往来：如果是 Word，就开启修订记录后发送修改版，客户主要核对红字部分。如果担心修订记录有遗漏，接收方可以用 Word 的「比较」功能把它和上一次的合意版进行核对，这样也能检测出遗漏。达成合意后，接受修订并确定该版本
3. 确定版本号规则：把通过验收的版本定为 v1.0，此后每达成一次变更合意就升级到 v1.1、v1.2。文件名中不要使用「最终」「修改」「(2)」这类字样
4. 把已达成合意的版本用 PDF 冻结，由双方各自保管：让任何人事后都能确认当初到底是就哪个版本达成的合意

不管用什么工具，只要这 4 点能够运转起来，「不知道哪里变了」「不知道哪个是合意版」这两大麻烦基本都能避免。反过来说，比起工具的选型，运维规则的合意才是真正的核心。

6. 发包方在签约前应确认的事项

面向发包方，把在报价・签约阶段应确认的事项整理成一份检查清单。

• 成果物清单中是否具体到文档名称这一级别列出了规格说明书・设计文档（是否只是笼统写着「一整套文档」）
• 是否能拿到可编辑的原本（Word/Excel 文件等）。是不是只有 PDF
• 收到修改版时，是否以能看清哪里变了的形式（修订记录・变更部分一览）来提供
• 维护合同的范围中是否包含改造时的文档更新。如果不包含，能否接受文档会逐渐与现状脱节这个前提
• 文档的著作权・二次利用如何处理。将来把维护委托给另一家公司时，能否把文档转交出去
• 规格变更的程序（变更管理台账・合意记录的留存方式）是否已经确定

从受托方的视角来看，这份清单同样可以直接用于整理报价。写哪份文档、写到什么详细程度，本身就是工时，也就是金额。如果在成果物范围模糊不清的情况下接单，临近交付时就容易出现「本以为这份文档理所当然也包含在内」这样的错位。事先就文档清单和格式达成合意，能同时保护双方。

7. 常见问题

Q1. 发包方指定了 Excel 方格纸模板，只能照做吗？

遵从对方指定的交付格式，本身确实是受托方的分内之事，但值得先确认一下指定这样做的目的。如果目的是满足公司内部的文档标准或应对审计，往往还有余地提出用 Word 的样式来满足同样的要求；而且模板只是从很久以前沿用至今的惯例这种情况也不少见。即便无法改变指定的格式，也可以通过一些运维上的巧思——比如在修改版中附上「变更部分一览」、把已合意的版本用 PDF 冻结——来缓解大部分因看不到差异而产生的问题。

Q2. 规格说明书只交付了 PDF，这样没问题吗？

在当下这个时间点因为还能读，看起来不算问题，但到了维护・改造阶段就会遇到麻烦。用专用工具编辑 PDF 并非不可能，但要像 Word 或 Excel 原本那样保持结构继续更新下去并不现实，每次规格变更都会让它与实现进一步脱节。将来如果要把维护委托给另一家公司，没有可编辑的原本，也会难以交接。稳妥的做法是在签约时就把「交付内容包含可编辑格式」明确写入成果物的条件中。如果已经只拿到了 PDF，不妨与开发公司商量，请对方提供原本。

Q3. 规格说明书应该请对方写到多详细？

并不是「越详细越好」。文档越详细，更新成本就越高，也越容易与实现脱节。大致的标准是：行为的界定要达到能作为验收基准使用的程度，并且保留维护・改造时会被参考的信息（界面项目、数据结构、外部联动、业务规则）。只要读代码就能明白的实现细节逐条说明，放在代码和注释里比放在文档里更不容易产生脱节。详细程度直接关系到工时与金额，因此这是签约前就应该协调好的事项。

Q4. 交付后规格说明书的更新，是谁的责任？

这取决于合同。如果维护合同的范围中包含「改造时更新设计文档」，那就是受托方的工作；如果不包含，则要么每次改造时单独下单委托文档更新，要么就要接受文档会逐渐脱节这个前提。最容易引发纠纷的，是双方都没有明确约定，却各自想当然地认为「文档理所当然会被更新」。建议在签订维护合同时，把哪些文档属于维护对象，具体到文档名称这一级别明确写下来。

总结

关于委托开发中交付的规格说明书，把本文的要点汇总如下。

• 交付的规格说明书应从验收、规格变更、维护的角度来选择格式，而不是只看「开发过程中是否好写」
• Excel 方格纸的本质问题在于：因为看不到差异而导致的验收形骸化、合意记录的丧失，以及因更新成本过高而导致的与实现脱节
• 结论不是「全面废弃 Excel」，而是回归到各得其所：文字用 Word（样式+修订记录），表格用 Excel 的规范表格，合意的记录用 PDF 冻结
• 用 Markdown+Git 管理开发方的原本，并生成 Word/PDF 作为交付物的方案，能够同时兼顾双方的优点
• 在讨论格式之前，先在合同中确定成果物清单、可编辑原本的交付、著作权的处理方式。比起工具，运维规则的合意才是核心

另外，关于用程序读写 Excel（报表输出）的话题，收录在《Excel 报表输出的实现方式 - COM/Open XML/模板》中；合同的构建方式，则收录在IPA 模型交易・合同的解说文章中。欢迎一并阅读。

致正在考虑委托开发・维护的您

合同会社小村软件（合同会社小村ソフト）在承接 Windows 业务应用的委托开发时，会按照本文介绍的思路，一开始就与发包方就成果物文档的范围・格式・更新的运维方式达成合意。此外，对于现有软件的改造，我们也承接从「虽然有规格说明书，但不知道是否符合现状」这种状态开始的调查工作。包括规格说明书的整理与交付格式的重新审视在内，欢迎随时咨询。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

发包方指定了 Excel 方格纸模板，只能照做吗？

遵从对方指定的交付格式，本身确实是受托方的分内之事，但值得先确认一下指定这样做的目的。如果目的是满足公司内部的文档标准或应对审计，往往还有余地提出用 Word 的样式来满足同样的要求；而且模板只是从很久以前沿用至今的惯例这种情况也不少见。即便无法改变指定的格式，也可以通过一些运维上的巧思——比如在修改版中附上「变更部分一览」、把已合意的版本用 PDF 冻结——来缓解大部分因看不到差异而产生的问题。

规格说明书只交付了 PDF，这样没问题吗？

在当下这个时间点因为还能读，看起来不算问题，但到了维护・改造阶段就会遇到麻烦。用专用工具编辑 PDF 并非不可能，但要像 Word 或 Excel 原本那样保持结构继续更新下去并不现实，每次规格变更都会让它与实现进一步脱节。而且将来如果要把维护委托给另一家公司，没有可编辑的原本，文档也很难顺利交接。稳妥的做法是在签约时就把「交付内容包含可编辑格式（Word 或 Excel 的原本）」明确写入成果物的条件中。如果已经只拿到了 PDF，不妨与开发公司商量，请对方提供原本。

规格说明书应该请对方写到多详细？

并不是「越详细越好」。文档越详细，更新成本就越高，在维护阶段也越容易与实现脱节。大致的标准是：行为的界定要达到能作为验收基准使用的程度，并且保留维护・改造时会被参考的信息（界面项目、数据结构、外部联动、业务规则）。反过来，只要读代码就能明白的实现细节逐条说明，放在代码和注释里比放在文档里更不容易产生脱节。写哪份文档、写到什么详细程度，直接关系到工时，也就是报价金额，因此这是签约前就应该协调好的事项。

交付后规格说明书的更新，是谁的责任？

这取决于合同。如果维护合同的范围中包含「改造时更新设计文档」，那就是受托方的工作；如果不包含，则要么每次改造时单独下单委托文档更新，要么就要接受文档会逐渐脱节这个前提。最容易引发纠纷的，是双方都没有明确约定这一点，却各自想当然地认为「文档理所当然会被更新」。建议在签订维护合同时，把哪些文档属于维护对象，具体到文档名称这一级别明确写下来。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。