GovOps：DevOps 与治理
本文由 AI（Claude）从日语机器翻译而成，可能存在错误。 阅读日语原文。
我在想，在今后的公共治理以及部分领域的治理中，或许可以设想出一种不同于 DevOps 的 GovOps。
随着数字厅的设立、行政机关的 DX、企业的 DX 等，数字技术终于要真正融入社会之中。有的论调只把 DX 停留在引进软件的层面，也有的论调谈论 DX 带来的服务和 UX 的改善，或是暗示 DX 将带来整个行业的变化，说法各种各样。
不过我个人认为，DX 的核心在于“机制”的转变，更具体地说，制度和系统等“互补性创新”（布林约尔松等人）才是关键。这方面请参阅我最近出版的《实现未来》，这次我想谈的是为什么是 GovOps。
Governance as Code
目前，数字技术不仅让 Ops (Operations) 变得更高效，法律和规则的 Dev (Development) 本身也在发生变化。
正如治理创新和敏捷治理等所指出的，数字技术不只是让规则的运行更高效，还能改变制定规则的方式本身。
例如，如果由国家来管理无人机平台，就可以实时改变无人机的可飞行区域。这样一来，也许就不再需要在法律中详细规定禁飞区域等内容了。另外，如果能把工厂和电梯等原本由人进行的检查，改为利用传感器的实时监测，那么由人进行的定期检查的间隔也有可能拉长一些。原本每年一次的检查，也许可以变成每三年一次左右。最近的 eKYC 就是一个例子，数字技术让与以往不同的身份确认方式成为可能。这些都是数字技术改变了运行方式，结果制定规则的方式也随之改变的例子。
运营通过代码变得高效，制作方式本身也随之改变。这与大约十年前在 IT 世界发生的 Infrastructure as Code / Operations as Code 的潮流很相似。它的意思是：基础设施和运营由代码来定义和运行，基础设施因此变得可编程，Dev 的形态也随之改变。
把这一点放到治理的语境中，是否也可以认为 Governance as Code 或 Governance by Code 正在发生呢？
GovOps
在 IT 世界，与 Infrastructure as Code / Operations as Code 的潮流并行、互相影响而发生的，是 Dev 与 Ops 的重新整合。这就是 DevOps。如果在治理的语境中思考，也许就会有 GovOps 这样的东西。
如果说官僚的某种产品就是“法律”，那么在加快其部署的同时保持稳定运行，这与 DevOps 的目标很相似。
实际上，敏捷治理等所提到的**“监管沙盒”可以看作是 DevOps 的分阶段发布**。考虑到确保敏捷性的机制很可能会趋于相似，我认为 DevOps 的做法可以成为思考公共治理和公司治理未来时的一个参考。
话虽如此，如果模仿 DevOps，搞什么“法律和条例每天部署 10 次”，会给社会带来太大的混乱，而且与 IT 系统不同，法律通常很难“回滚”，所以我认为最好避免原样照搬。不过，如果能借助数字技术优化从法案成立到运行、服务工作流程的整个过程，从而增加一年中可以提出的法案数量（并且能在国会中以高透明度、高效率地进行审议），那么也许就能实现对社会变化具有高度敏捷性的治理。
与此同时，诸如“为了提高法律的部署次数而引入 AI 来检查现有法案”之类，与官僚业务 DX 相关的各项举措的定位也会变得更加清晰。
GRE
另外，借鉴 SRE (site reliability engineer) 的思路，也可以设想类似的 GRE (governance reliability engineer)。
SRE 的思路中可以用到的是错误预算和 Toil。错误预算是预先确定错误的可容许范围，并在此范围内承担风险、谨慎地挑战新事物的机制。而 Toil 指的是频繁发生、可以自动化的手工劳动。
在 SRE 中，错误预算通常以正常运行时间为基础。对于行政机关，则需要确定合适的 KPI，而且当然也有不允许出错的领域，所以并不是能应用于所有方面。不过，作为为新的挑战创造余地的思路，我想在部分领域还是可以应用的。
另外，确定每年削减 Toil 的数量也是一种做法。Toil 可以说就是“不必由人来做的辛苦”。行政工作中似乎有很多 Toil，削减它们，就能把时间用在原本该做的居民服务和听取意见等事情上。这样的效率化想必原本就一直在做，但有了 Toil 这个名称之后，我想做起来会稍微容易一些。
迈向 GovOps
这样思考 GovOps 之后，我觉得迄今为止在 DevOps 领域积累起来的思路，在治理中也许在一定程度上可以派上用场。
例如，“DevOps 是文化，是实践，也是工具”这句话经常被反复提起，而治理的数字化也不应该只停留在工具的层面。
另外，在改进 GovOps 时，例如在 DevOps 中，也可以基于下面这“三项原则”来思考。
- 流动原则：让工作流程加速
- 反馈原则：实现反馈流程
- 持续学习与实验原则：孕育企业文化
把这些套用到现有的治理（姑且先说公共治理）上，就是通过价值流图等方式梳理工作流程，利用数字技术加快现有业务的工作流程；利用传感器和 Decidim 等实现反馈流程；进行持续的学习和实验，等等。
总结
直到现在，我自己对其中一些部分也还是没什么把握，心想“这样行不行呢”，不过因为敏捷治理的报告发布了，我想到说起敏捷就会想到 DevOps，于是配合着写了这篇文章。实际上，敏捷治理的报告中有如下的图，我觉得它与开头 DevOps (GovOps) 的图有相似之处。
其实，我以前写的 xOps 幻灯片中也放进了 GovOps。
我知道粗糙的类比很难如此顺利地行得通，但我仍然认为，DevOps 的思路会成为今后数字政府的讨论以及各企业 DX 中的一个有参考价值的概念。