以前我在下面这篇文章中整理了新冠病毒自肃请求期间实施的事情，这篇是后续文章。与其说想向谁分享信息，不如说是作为自己的记录留下来。

写完后也觉得，这里并没有特别作为教训的总结。另一方面，作为团队如何运作的记录，似乎有价值。

为课程线上应对而实施的事情 _在上述状况下，仍有很多课题，但在许多学校相关人士推进线上转移的过程中，我想尽可能分享一些经验。_medium.com

上一篇文章写了，在必须紧急线上应对的情况下，如何高速转动 PDCA cycle，以及即使在紧急时也认真进行用户调查的重要性。本文是续篇，时间线稍微重叠，但讲的是之后的事情。上一篇大约是 2020/3 到 2020/5，这篇是 2020/4 到 2020/6 左右的事情。

另外，上一篇文章的内容即使公司内部没有开发团队也能做，而这次的内容则是因为公司内部有开发团队才做得到的事情。

时间稍微往回。2020/3，新冠病毒信息开始扩散，考虑到这个病毒的性质，我认为长期化是必然的。另一方面，补习班这种 business model 是按月收费，停课会成为生死问题。因此，从最初就有这样的想法：必须并行推进紧急时应对，以及以长期化为前提的线上化动作。

所以，2020/3 到 2020/4 左右，第一优先是紧急应对；从 2020/4 开始，则想进行长期视角的工作。lesson capacity 问题从 2020/3 的措施开始运转时就已经试算并把握了。即便如此，作为生死问题，而且等到能向所有人实施后再行动并不合理，所以即使从一部分开始也必须推进。

因此，我有意识地把这次紧急应对从长期视角看作 prototyping，并并行积累知识。具体来说，进行了细小的 lesson A/B test、NPS 汇总等，调查哪些 lesson 适合线上，哪些不适合。这些动作没有卷入开发团队，而是和 business side 成员推进。是适材适所的想法。

另一方面，business side 成员不需要一直强烈意识到长期测试。理所当然，在紧急事态中，首先应该 focus 在跨越眼前问题上。能够跨越线上 lesson 应对，business side 的努力很大。

在这段期间，一边赞赏贡献，一边把如何转向长期视角，也就是点燃第二引擎，作为一个课题来意识。

此外，这里也有个人看法，但我想也有成员认为新冠病毒可以通过 lockdown 完全封锁，或者会变成类似 influenza 的东西。我个人则（现在也）持有会长期化的立场。因此判断需要点燃第二引擎。不过，关于这一点现在也还没有答案。

那么，这段时间工程师团队在做什么？作为团队，我传达了要持有长期视角。在此基础上，首先是制作与停课相关的系统处理脚本。因为我们知道，与通常运营不同的 business flow 会产生大量需要运营补上的工作。

这可以用手动应对跨过去，但正如前面写的，如果站在长期化前提上，这里希望自动化。不过，如果说要做功能改修，也没有那样的工时余裕，business side 也很紧，恐怕也没有形成共识的时间。

于是，虽然只是脚本，但我们认真执行 review process，制作稳定的自动处理脚本。

这在东京自肃请求、福冈地区自肃动向、紧急事态宣言等状况不断变化中发挥了很大效果。到这里是 2020/4 左右的动作。

自动化脚本完成后，工程师开发手就空了很多。（原定开发计划在停课应对时全面停止。）于是开始为了线上化而内制视频通话功能。

这个时期，和 business side 拼命使用 Google Meet 转动线上 lesson 的 PDCA cycle 重叠。准确说，在内部进行了大约 2 天 Google Meet trial lesson，并试算 lesson capacity 后，我个人判断需要内制化。

从这里开始，我稍微像 CTO 那样行动。首先，SaaS API 由我大致预先调查。写了 Twilio 等各种文章，也是这次调查的副产物。

另外，周末我用 Twilio API 做了一个简单 prototype app。意图是 shortcut 技术选型步骤。平时的话，大概会把调查也交给团队成员。

整理这些信息后，我向开发团队成员传达：之后需要第二引擎，开发期间希望想办法控制在 1 个月。

从这里开始，我们开发团队更有意思的地方出现了：大家开始讨论这个需求真的够不够。结果，虽然最初 chat 也打算用 SaaS 实现，但结论变成：用 WebSocket（ActionCable）自前实现为另一个功能更好，因为 chat 会成为用户体验的阻碍因素。

能得出这样的结论，我认为也是自走团队、并行进行的 PDCA 知见、discussion culture 的成果。

实际 schedule 如何呢？到开发团队可以 review 的阶段用了 1 个月，debug 作业和 business side review 又追加了不到 1 个月。（也就是说，1 个月内没能 release。）另一方面，business side 也很理解，所以双方基于信任互相 cover。

经过这样的过程，在线上应对差不多达到 lesson capacity 上限时，新功能完成了。看到能动的东西，也会理解很多事。

business side 给过这样的 comment：一直在脑海角落里的 lesson capacity 问题，因为这个功能变得可见，从而成为希望之光。

这样一来，曾经大活跃的 Google Meet 完成了它的角色，课程被替换为自社开发的视频通话系统，lesson capacity 问题也大致得到解决。

现在已经更进一步了，虽然我想说所有问题都解决了，但一个课题解决后，又会发现新的课题。自社开发的视频通话系统解决的问题，还只有 6 到 7 成左右。

还有一点很有意思：并不是做出功能就能解决问题。功能到来之后，还必须再整合进 business side 的动作。这次没能把这里写完。

另外，至今为止基本是防守动作，但之后也想推进面向攻势的动作。一想到攻势，新课题又堆积如山。

也就是说，课题特盛，还能无限续杯，但持续解决课题就是 PM 的工作。对于这些课题，我打算积极并享受地投入。（实际上，2020/3 以后虽然很辛苦，但也很有充实感。）关于这些动作，有机会时还想再整理。