問36
頻出度★★★
合意済みのシステム要件に対し, 機能追加となる変更依頼を顧客から受けた。このときの受託側の対応として, 適切なものはどれか。
平成22年度 春期 ITパスポート試験 問36
マネジメント系プロジェクトマネジメント › プロジェクトマネジメント
这道题的解析和你的作答记录。
解説
問 36
错误ア
运维设计负责人是从系统上线运行后如何运维这一视角出发的专家，作为评估变更对运维影响的角色固然重要，但并不具备决定需求变更是否可行的权限。能够承担开发工时、费用、交付期、合同范围等对项目整体影响的，是拥有决定权的会议或负责人；如果由某一个领域的负责人单独判断，就会在其他领域受到的影响被遗漏的情况下让变更混入进来。
- イ
正解 正确答案是「イ 由拥有决定权的会议或负责人判断是否进行变更。」。一旦与客户达成一致的系统需求，就成为此后设计、开发、测试的基础（基线）。如果在其中加入追加功能这样的变更，开发工时、费用、交付期、对其他功能的影响乃至合同范围都会随之变动，因此变更是否可行并不是可以交由某个具体负责人自行判断的事情。为此，项目中要制定变更管理（变更管理委员会等拥有决定权的会议，或被授予权限的负责人）的流程：正式受理变更请求书并进行影响分析，正式决定批准还是驳回，只有获批的变更才更新需求、计划和估算并通知相关方。选项イ 描述的正是这一正式的变更管理流程，所以是恰当的。
错误ウ
销售人员作为与客户对接的窗口，确实承担接收变更请求的角色，但他容易站在希望满足客户诉求的立场上，未必能正确评估变更对开发的技术影响和工时增加。如果窗口人员擅自答应「我们做」，就会在估算和合同都没有更新的情况下只增加工作量，招致所谓的范围蔓延（scope creep，无管理的需求膨胀）。正确做法是把受理和批准分开，是否进行变更要通过变更管理流程来决定。
错误エ
负责变更相关软件的开发人员承担评估可实现性和所需工时的角色，但并不处于牵头决定是否进行变更的位置。如果开发人员按自己的判断把变更纳入进来，就会在变更内容未被记录、未被批准的情况下推进实现，导致与其他模块的一致性、对交付期和费用的影响以及交付物的版本管理都出现混乱。必须遵守这样的职责分工：把技术评估信息提供给变更管理会议，由拥有权限的一方作出决定。
ここがポイント
- 对已达成一致（已基线化）的需求提出的变更请求，要按照变更管理流程处理。步骤是：正式受理变更请求；分析对成本、交付期、质量、其他功能的影响；由拥有决定权的会议（变更管理委员会等）或负责人决定批准还是驳回；只有获批的变更才反映到需求规格说明书、计划、估算和合同中并通知相关方。要点在于把受理的人和批准的人分开。
- 从项目范围管理的角度看，防止无管理的需求追加（范围蔓延）很重要。如果凭负责人的好意或口头约定不断添加功能，就会导致工时超支、交付期延误，以及日后围绕责任归属的纠纷。变更必须形成文档，经过拥有权限的决策者批准之后才纳入范围。
用語