「就是啊，Bug这种东西是抓不完的。不过电波或距离之类的问题还不用测试没关系。那个一个人应该做不来。」
「喔，这样啊。」
把两台掌机隔开几公尺试玩，的确不是一件容易的事。
「那就这样了。你试试看吧。」
「好的，我明白了。」
岸岭独自留下来，立刻拿起了两台掌机。
他试著按按看主端掌机的按钮。按下十字键的上方向，客端的游标也会跟著往上跑；按住下方向就会往下跑。
无论操作几次都一样。同步十分完美。
（实在不觉得这会出现落差耶。）
两台掌机之间以无线通讯进行连线。如果无线电波本身发生错误，自然会造成程式错误。但志野冢告诉他这次不用测试电波问题，更何况他也不知道如何才能让电波发生错误。
这么一来也只能不断乱按掌机按钮了，然而不管重复同样的操作多少次，同步都没有出问题。
（不对，等等……）
他曾经听社团的其他成员说过。
拿格斗游戏的网路对战来说好了。他们说在分秒之间展开激烈攻防的格斗游戏网路对战当中，同步处理技巧的重要性不言而喻。特别是在对战者常常相隔几百公里都不稀奇的网路对战当中，延迟是避免不了的问题。
只是从理论上来说，还是有解决之道。如同动画按照每秒二十四格来运作，游戏大多是以每秒六十格来运作。因此，只要能够以六十分之一秒为单位──这个似乎称为一影格──正确传送并接收控制器输入的资讯，似乎就能达成没有延迟的网路对战。
只是真要说起来，这在物理层面是办不到的。讲得极端点，之间只要相隔日本与美国这么远的距离，就算是光速也无法在六十分之一秒内收到资讯。因此据说如何解决这个通讯延迟的问题，已经让游戏程式设计师头痛多年。
解决方法之一就是一次将几影格，也就是六十分之几秒的手把输入资讯传送给对方。如此一来，即使通讯时多少产生一点延迟，也能够依据前后资讯进行修正。特别是一次能够传输的数据量──也就是在讨论手机等问题时同样会提到的封包每一个的数据量相当不小，据说可以一次传送不少资讯。
岸岭不了解掌机的无线通讯原理，但基本上应该差不多。换言之，就是持续传送控制器输入的资讯──每个按钮按下或放开的资讯。只要输入资讯的传送与接收上出现某些错误，同步应该就会乱掉。
（既然这样……）
岸岭上下连按主端掌机的十字键。这么一来，主端与客端两边画面上的游标当然也跟著激烈上下乱跑。他猜想像这样连续传送资讯，也许会让输入资讯产生混乱。
然而，不愧是职业程式设计师建立的系统。客端的同步完全没有出现落差。
（这样也不行吗？那我就……！）
为了让输入资讯更加混乱，他使出另一种手段。首先他按下决定钮以外的所有按钮。举凡LR、开始钮与选择钮等模式选择画面本来用不到的按钮，能按多少尽量按。
并且在这种状态下，迅速乱按十字键的上下方向。
「啊！」
游标终于错开了。
主端这边选的是「双人合作」模式，客端这边却选了「挑战」模式。
他在这个状态下按按看决定钮。
（当机了……）
这种英文称为Freeze，名符其实地像是结冻般无法进行任何操作的现象，在游玩制品版游戏的时候偶尔也会发生，是最糟糕的状态。这正是标准的程式错误。
他关掉电源，重新开机，进入双人模式后重复相同的动作。
同样的现象随即发生。
「志野冢先生，同步错开了。」
岸岭立刻去向在背后坐办公桌的志野冢报告，而且难掩小小的骄傲心情。
「咦？出现Bug了？果然找找就会有呢。」
岸岭立刻实际示范给志野冢看。他按住所有按钮不放，同时连按上下键。轻轻松松就能让同步错开。
「哦，这样你也找得到，真厉害。那正好，你就用这个状况练习写一下错误报告吧。」
志野冢把一张纸交给了岸岭。
「错误报告？就是报告用的表单吗？」
「对对对。我们会请你们每次找到Bug时将正确的状况写下来。我是觉得应该改用EXCEL来管理，但好像是有某种传统做法，一直都是用纸本。好，首先在这里填上日期、时间，以及报告者的名字。」
的确可能需要这类联络方式，才能有效管理程式错误。
「呃──岸岭健吾……写好了。这个『等级』指的是……？」
「我们会替Bug粗略分类。像是画面冻结、存档消失等等会对游戏进行造成严重影响的Bug是S，画面整个乱掉或是一看就知道是Bug的是A，其他Bug是B，难以分辨是Bug还是游戏特性的就是『？』。」
「我懂了。那这次是S吗？因为会影响游戏进行。」
「不，先空著就好，反正这个必须直接通报。我偷偷告诉你，如果动不动就报告成S的话会惹到程式设计师。但随便把S级Bug分