发掘团队成员的主动性！从技术领导部门经理口中了解研发组织成长的关键之处！

本文介绍了Works Human Intelligence公司的“Develop fun!”在线日历活动的第二十四天。
我们公司有两个在线日历活动，请一定也来看看第一个日历活动！

因为今天是圣诞节前夜，所以为了这个特别的日子（特别是对于公司内部而言），我将送上一篇特别的文章！

在第一個聖誕夜，我們公司的SRE團隊由兩位成員負責寫這篇文章。
擔任聖誕夜的是加藤（@FumiakiKato），他是我們公司的AWS工程師，也在我們公司的note文章中被介紹過，他於2020年獲得了APN AWS Top Engineers的獎項。
而負責聖誕節的是新村（@Hokuto-Niimura），他是SRE團隊的負責人，最近也積極參與一些對外宣傳活動，例如在DebSummit上的演講。
在向很多人請求祈禱並奉獻祈禱後，我們得到了另外兩位代表Works HI公司的成員，來一同編寫這篇文章！希望他們能夠帶給大家一個和第一篇一樣精彩的聖誕節！

其中之一是金子，他负责领导我们的技术领导团队。
金子在2002年加入了Works Applications，之前是Works HI的前身，他在该公司从事产品开发数年后，参与了研究技术和利用先进技术开发工具等研发组织的建立，并作为领导者将该组织扩大。在分社化之后，他在Works HI再次从零开始创建了技术领导团队，并目前担任负责6个小组和31名员工的技术领导部门的主管。

金子说，经理的工作在于如何激发每个成员的主动性。本文将根据这一信念，介绍金子过去是如何建立研发组织的，并且还将提供他未来如何改革技术领导组织的访谈情况。

从零开始建立并大力培养

金子先生是什么时候首次加入技术团队的？

我在2000年加入公司，那个时候并不存在专注于技术的团队。
当时的CEO提出希望组建技术部门的想法，于是我们决定创建一个新的组织。这个组织由大约20人组成，负责共同的基础架构，并旨在全公司范围内追求技术发展。
这个组织被称为技术基础开发团队，它成为了现今技术团队的起源。

在技术基础设施开发团队中，他们做了哪些事情呢？

作为团队使命的一部分，我们主要关注跨产品进行必要的技术研究和技术追求，但在成立初几年，我们专注于稳定新版本的产品。

在安定化工作告一段落之后，技术基础开发组开始重新审视其本来的任务。我们认为，如果只拥有产品的共同基础，就无法一直集中精力进行技术追求，因此决定将其分离出来。

通过这次分离，新的组织负责新的技术领域应运而生。其中包括产品评估组和负责技术问题解决和技术研究的组。我成为了后者的负责人。

起初，我们只有六个人的团队，但随后逐渐增加，成长为大约四十人的组织。虽然有些人是由于调动而增加的，但专门聘用具备技术背景的新毕业生和有经验的人才也起到了重要作用。

在该组织中，他们是从零开始自己创造工作机会的，还是有一项由上级委托的使命任务？

虽然我们也接到了人们请求我们帮忙完成的工作，但大部分的工作我们都是自己去寻找的。我们致力于创建新入职工程师的教育内容，为公司的升级制作工具，以及在AWS刚开始推出时就迅速将公司运行在EC2实例上。当时使用AWS控制台的方式也很困难，因此我们自己制作了一个可以进行AWS实例操作和管理的Web应用。这项努力后来发展成了一个独立的CCMS服务，并在不同部门中展开。

当回头看时，我觉得我从零开始的工作是通过首先尝试许多小的挑战，然后在其中找出似乎成功的部分，并集中精力在那里，以这种方式创造出来的。

我认为您在改进公司提供的服务方面做出了很多努力，但是您是否也在进行技术研究呢？

关于先前提到的措施，我意识到的包括尝试引入新技术、新语言以及新框架。先进的框架等不仅能提供新的价值，但同时框架本身可能仍然不稳定，存在缺陷，而且在网络和书籍上积累的经验知识可能较少。因此，直接在主要产品中采用可能带来风险。

在此，我们不仅仅进行技术研究，还实际制作公司内部使用的工具和Web应用程序，并在制作过程中尝试使用新技术。通过这种方式，我们不仅可以为工具和Web应用程序提供价值，还可以积累对新技术的专业知识。我们还会将这些经验进行文档化，并设置问题解答服务窗口，以便在产品需要使用新技术时能够进行知识共享。

能够迅速实现创造性价值创造的组织

組織作为一个整体，大部分的产出都源自于我们自己寻找到的工作。但是在决定将这项工作作为组织的目标时，我们是如何进行决策的呢？

处理的主题大多是基于成员的提议。最初独立时的六名成员主要是在产品开发工作中拥有技术意愿和问题意识的成员，因此并不缺乏创意的想法。

为了让新分配的员工了解COMPANY产品本身以及产品开发部门的问题，最初我们要求他们与产品开发人员合作。例如，技术基础团队正在开发一个能够使用多线程处理批处理的框架。我们让新分配的员工将产品处理代码改写成使用这个框架的形式。我们还要求他们解决在用户现场环境中出现的性能问题、中间件问题和网络问题等。

我认为通过参与产品开发部门，我们可以让公司自身思考并提出关于组织开发、开发流程和开发工具的问题以及解决方案，从而创建一个让大家亲自思考和提出建议的过程。

我觉得随着组织人数的增加和承担的主题的增加，管理的难度也会增加……

随着涉及的主题增加，团队虽然分裂，但在最初阶段虽然人数众多，但通过进行每周一次的会议等措施，使整个团队拥有一个平等的意识。
在会议上，无论是经理、成员还是其他角色都可以自由地交换意见。在进行新的挑战时，我们会超越组织图中的团队界限，创建项目，让有兴趣参与的人加入。
如果组织结构非常严格，向团队外部提问的成本可能会很高。作为Works HI，我们一直推崇扁平化的沟通方式，但作为技术领导部门，文化塑造和文化传播尤其受到重视。

回顾过去，作为技术领导部门我们面临了许多挑战，然而成功的关键只有一个。那就是我们进行了更多的挑战和PDCA循环，没有其他原因可言。

原来如此。能够快速运转PDCA的原因之一就是拥有有扁平的组织结构和关系，对吗？

在以上意下达为核心的组织中，当然有优点，但对于在从零开始创建一项事物，判断零能否变为一的情况则完全不适用。在创业中经常提到的是，要想达到100个想法最终成功的一个想法，需要大力尝试出来。

我认为，在进行新的尝试或者为此调动人力和预算的情况下，有必要向上层管理层定量地提供成本效益，但在那个时候并不是那么令人意外。特别是在追求可以同时追求多个好处的情况下，通常会接受具有定性好处定义的挑战。从根本上说，创造性挑战中，“不试试不知道”的情况很多，CEO也理解这一点。

以扁平化组织为基础，不断完善公司。

作为技术主管，您今后打算在哪些方面集中精力呢？

实际上，我们已经开始进行类似研发的工作了。例如，在ChatBot团队中，我们已经开始研究利用GCP和Azure提供的机器学习功能。作为技术负责人，我希望能够推进这样的研发工作，但另一方面，我也希望在产品开发中推进一些通用的功能和基础设施建设。这些通用的功能可以包括身份验证等普遍存在的内容，也可以是与我们产品的核心员工相关的信息，以及各种条件设置。而不是让各个产品和子系统在开发时需要从头设计或协作，而是提供一个可以直接使用的框架。

只是，在开发这些产品时，我们希望不仅仅从基础设施的角度进行开发，还意识到产品开发方面的可用性，并朝着更加方便使用的方向进行推进。

在过去的新产品开发中，我们试图建立一种体制，即基础设施团队全权负责开发每个产品共享的模块，使产品开发团队可以专注于开发能带来更大价值的功能。虽然这个概念很好，但这个项目最终并没有成功。虽然失败的原因有很多，但我认为最大的原因是分别独立开发带来的负面影响。

尽管我们尝试考虑到使用者的所有需求，或者使用者对被使用的一方有各种期望，但如果将这两者分开开发，就会产生各种矛盾，使双方之间的鸿沟愈发加深。

为了防止这类失败，应尽量缩小组织和人员之间的距离，使其处于平等的状态。我认为最好是让双方一起合作开发。实际上可能有难度，但最终我希望能够建立起产品开发团队各自承担某些业务功能和基础功能开发的体制。

能否请您给公司内外的工程师们发表一封讯息？

当决定自己的行动时，我认为我们只需要判断它对自己是否有利即可。然而，判断选择是否最终真正改善了自己的状况却是相当困难的。因此，我选择根据我的选择对于我的公司或者对社会是否有益来判断。

只要所属的公司和社会变得更好，整个社群的质量也会提高，反过来对个人也是有利的。我相信这个理念，并且根据这个判断标准，我大致上得到了对自己有益的结果。

为了世界而奉献并不仅仅是一种美好的说辞，从这个角度出发，把注意力放在这些方面对自己的处境也是有益的，这一点是毫无疑问的。

或许有些难以理解，但在我心中，我有些模糊地觉得应该是这样的。

最后

感谢您阅读至最后！

在未来变化更加剧烈的时代中，为了从零开始建立和扩大组织，可能需要意识到”在高速PDCA的过程中，不断验证大量的假设”并”培养那些看起来有希望的假设。为此，需要一个扁平的组织””当组织规模达到一定程度时，团队是必要的，但整个组织需要保持扁平的关系”。