选，我们已经很清楚了。那么，接着要跟您确认设计及运用的方面。」
气氛骤然一变。
接下来的攻势犹如怒涛一般。就连微不足道，我方根本未曾意识到的矛盾点都被暴露出来。备援设计、可用度计算、网路定址。还有编制、流程、各种申请表单、报修至抵达的平均时间，这些都在次郎丸的攻击范围内。
一个活泼的女孩子，究竟在体内的何处沉睡着如此凶猛的一面？其无情的程度，几乎令自己背脊发寒。可怕的是，听在旁人的耳里，只会认为我们在进行很普通的问答罢了。业平的经理，或许根本不知道眼前正上演多么激烈的攻防战吧。他似乎将其当作一种客观的情报收集方式，整个人安安稳稳地持续做着笔记。
倘若事前没有做准备，大概一下子就会被击沉了吧。唔，就连现在这个时候，也回答得相当吃力。只要稍微出现语意嗳昧的地方，次郎丸就会紧抓住不断追问。她处处针对回答的整合性、精确度以及正确性。
工兵在文件和笔电之间来回调阅资料，拚命回答问题。在历经了彷佛一辈子的漫长互动后，次郎丸的语气出现了变化。
「换一个角度来问好了。」
相当不客气的一种说法。
戒备等级一口气升高。她盖住文件，不知究竟想抛出什么样的问题来。
「实际的运用和障碍隔离作业，贵公司究竟是如何进行的呢？并非规格上，而是具体的操作方面。」
「具体的——」
「比方说……这样子好了。当无法接收到DMZ伺服器的通信时，贵公司将会如何实施确认作业？」
…………！
是状况模拟……所谓的角色带入吗？对目前的自己来说，这是最不擅长的部分。和单纯列出一堆数字的规格说明不同，这将会暴露出自己经验尚浅的事实。更别说对方问的还是运用部分。自己根本没有接触过相关实务，自然也就不可能答得出来。
时间过了数秒。要是回答得再迟疑一些，客户或许就会开始心生疑窦吧。这家伙怎么回事？连具体的作业都无法说明清楚吗？光讲一些好听话，真的值得信赖吗？然而，也许是发现这边的窘境，一旁的室见开始行动了。那凛然的声音传遍整个室内：
「首先检查之前有无在防火墙等设备上实施过作业。确认是否增加或删除过关于该伺服器的policy。在此同时，察看交换埠上的错误，看有无发生冲突或封包遗失。」
「若发生了冲突和封包遗失呢？」
「就透过MRTG确认流量状况，是阻塞的话便通知客户。当客户确定通信量没有问题，且问题仍未改善的话，就考虑对连接埠做shutdown/no shutdown的动作和转换到其他的介面。之后根据后续状况，还有重新启动和清除MAC位址表的手段。」
不愧是室见，面对突如其来的问题仍能对答如流。在工程师的本职上，室见果然比自己还要高出许多阶。即便是专精领域之外的部分，也可以瞬间得出答案。
大致问完一遍后，次郎丸平静地开口：「和教科书上写的一模一样呢。」
「关于网路设备，我们已经很清楚贵公司有充足的处理能力。而且是忠实地执行需求定义书上面的运用规格。」
「…………」
「从技能组合方面来说，贵公司准备了充足的工程师，处理问题的经验也累积得很丰富……然而，倘若存在未实施的操作，究竟是基于什么样的理由呢？是技术问题？想必不是吧。恐怕是与服务规格的制定有关。」
「什么？」
这种兜圈子的说话方式，令工兵皱起眉头。怎么回事，到底想说什么？
次郎丸的手指抽出手边的一份资料，上面写有「运用需求定义书」字样。
「伺服器交换器的责任分界点……照目前的运用规格来看，是到交换连接埠为止。」
工兵和室见，两人不约而同地吸了一口气。
来了。选择在这里出招吗？一如事前预料的攻击方向。
次郎丸将资料举在自己面前：
「自交换埠以后，便是业平产业的管理范围。因此，业平总是在未能确认介面正常与否的情况下管理设定。这就是贵公司的运用规格吧。就结果来说，设定变更前的资讯收集和资料管理都是业平所要负责的。那么，过去的几个月里，究竟出现过多少次的变更呢？」
翻动纸张的声音响起。
「仅十一月就有十二件，十二月更有十八件。算起来大约是两天一件。」
「啊？有这么多吗？」
业平的经理瞪大了眼睛。次郎丸重重地点头：
「是的，将每次的申请作业预估为两小时，一个月就是三十个小时，足足四个人日的工时。对于人手本来就不多的资讯系统部门而言，这样的负担想必不小。」
现场开始鼓噪。经理这时向桥本投以责难的眼神：
「为什么会开出这种规格？全部都拜托骏河系统来处理不行吗？」
「主要是因为成本上的限制。」
桥本的声音相当平板。她极力按捺住情绪，用压抑的口吻回答：
「最终协议价格的时候，将重要性较低的运用事项剔除了。毕竟基本的运用窗口费用就只能处理一般的件数，但其他优先顺位更高的事件还有很多。另外，就是当时并未预估到，交换埠的管理会造成如此大的负担。」
&emsp