在教育企业中建立开发部门的五年实践

发布于 # 工作与组织 # 教育

长期以来,为了把教育企业变成教育 x 互联网创业公司,我们一边摸索一边推进在公司内部建立开发部门的实践。通过这五年的实践积累了一些经验,所以决定整理一下。

先说明一下,这些实践并不是我一个人推进的,而是整个公司团队一起推进的。希望读者能注意这一点。

文章会有点长,先整理一下大纲。

  1. 业务委托
  2. 学生工程师培养课程
  3. 外国员工工程师培养
  4. 就任 CTO 与工程师招聘
  5. 组织体系变更
  6. 引入 1 on 1
  7. HackDay 的实践
  8. 招聘第三位工程师
  9. 走向组织化的实践

1. 业务委托

大约五年前的 2012 年,我从社长那里听到了他想做的东西。当时我刚开始做自由职业工程师,很快就接了下来,设计并开发了一个用于改善日常课程提供机制的系统。

公司过去并不是有系统发包经验的组织。虽然网站制作和营销会与合作企业一起做,但需求定义等无法做得很严格。不过,我运用了自己原本做 director 的经验,以及作为自由职业者逐渐培养起来的访谈技巧,系统最终顺利发布。

同时,我培养了不只是做系统,还包括准备硬件、充电、整备公司内部网络等复合问题解决能力。我有意识地不说“做不到”。而是用“可以做,不过需要这些东西”的形式推进。

过去做互联网服务开发时,常常经历发布后毫无反应的情况。但这次发布瞬间就开始在眼前被使用,我记得那非常令人兴奋。直到现在,我也认为能够获得这种体验,是“某领域 x 互联网”这类混合型企业的妙处。

回想起来,这个时期是社长作为核心引擎推动组织,而我一个人在开发上奋战的时期。虽然有人给过建议,但无论什么事,发布都是最高优先级。

2. 工程师培养课程

我继续一个人做维护和改善,但开始听社长说起把工程师组织化的构想。正好我在另一份工作中做过编程学校,于是有人提出不如试着培养工程师,我们也实际开始行动。

这项实践现在还在做,今年已经是第五期。主要面向兼职学生免费开展编程课程。这个课程也持续改善,现在已经相当好了。

另一方面,即使说培养工程师,也没有那么简单。成长为独当一面的人需要时间。一边开发一边开课程,在兼顾上很辛苦;但后面也会写到,没有放弃并持续推进这项长期实践,我觉得是好事。

为了能持续做下去,我有意识地做的一点是,充分形成共识:工程师培养课程的成果需要时间。

3. 外国员工工程师培养

这同样是社长提出的、看起来可能见效较快的实践。公司内部还有另一个事业部,那里有一位外国老师。他原本就有一定背景,所以也许可以培养。当然,他本人也希望从教师转成工程师。

组织当时也正处在从 CakePHP 迁移到 Ruby on Rails 的时期,于是推进 Rails 的新开发,包括以学习为目的的原型开发。困难包括语言问题、地理问题(办公室位置不同,不能每天见面)等,但最终顺利走到了发布。

面对这些课题,我持续做的一件事是不断传达自己对所做系统的热情。虽然现在也不知道这是否正确,但我觉得自己理解业务委托时代一个人做系统的孤独感,这一点是有帮助的。

遗憾的是(也有一半是高兴),他在掌握工程师能力后希望挑战自由职业;组织上也为了集中业务进行了组织变更,所以现在没有一起工作。

现在组织以日语为中心,但如果将来要建立全球团队,我还想再联系他。和长期一起做事的成员分开,果然还是很难受。

重要的学习是管理的困难,以及业务成长的重要性。当时开发任务用 Redmine 做成 ticket,但我觉得动机管理没有做好。没有一种理想中的自我激励机制。如果这一点能做到,也许就不会分开。

而比这更重要的是业务在成长。如果业务没有成长,就无法持续。这成为了一次切身体会到严酷现实的经验。

4. 就任 CTO 与工程师招聘

这和上面的事情有一些并行,但大约四年前的 2013 年 4 月,我收到成为董事的提议。同时,工程师招聘也已经确定。于是,一边继续开发,一边正式建立开发组织,就成了我的使命。

就我的情况来说,在推进上述事情的过程中,我逐渐感到有趣,同时也越来越没有时间,几乎已经全力投入。因此,停止自由职业并全力投入,并没有什么抵触。

一个人能做的事有限,团队协作有动态感,已经存在真实业务有优势,对加入公司的 mission 和 vision 有共鸣,等等。加入团队的理由举不完。

(关于自由职业还是在组织里工作,归根到底很大程度上取决于个人价值观和风格,但我觉得组织更适合我。)

当时,组织建设被明确设定为使命,但老实说,我没有经验,也不知道应该做什么。另一方面,通过此前的经验,我学到即使是没经验的事,试着做也会向前推进。所以我重视的是不要害怕失败和摩擦,先试着做。

5. 组织体系变更

于是最开始着手的,是变更组织体制,让工程师尽量专注于开发。现在组织也还没有那么大,而且了解各种业务本身也有好处,所以工程师也会经历很多业务。但我们做了组织变更,让日常稳定承担的业务集中在开发业务上。

正好组织也开始变大,所以不仅工程师,其他团队也从“全员棒球”转向角色分工,改变了规则。结果上仍然有很多不足,也需要持续改善,但组织体系本身变得更像样了。

在 IT 企业里这或许理所当然,但我们考虑工程师这一职种的特性,推进了不容易被打断工作的环境建设。

这里也有反省。一是速度感不够。另一点是制度先行。关于速度感,因为是在一边做包含新服务启动在内的开发,一边做这件事,所以我把它当作子项目。但对当事人来说,这是每天业务中都能实际感受到的事。我觉得这里存在温度差。

另外,在这个过渡期,有人指出希望不是制度先行,而是文化先行。不是突然建立制度,而是先让那种文化渗透进去,然后再建立制度。先制造既成事实。这样往往更顺利。由于不知道这一点,我们制造了无谓的摩擦。

6. 引入 1 on 1

在反省这些事情时,我引入的是设置倾听机会的 1 on 1。当我因为上面的事情烦恼不已时,1 on 1 正好开始在互联网圈子里成为话题,于是我像抓住救命稻草一样决定实施。

同时,把工程师水平从中级提高到高级,也是我个人想做的事。结果上,我感觉相当有效。如果有人正在犹豫是否实施,我推荐试试看。不合适的话停掉就好,我觉得几乎没有负面影响。

另外,对我个人有帮助的是,在不断做 1 on 1 的过程中,学习了如何倾听。最重要的是,我切实理解到“答案在对方心里”。也因为这一点,我觉得自己在会议引导等方面也比以前更有效率了。

反省点是,我觉得应该同时推进最后要写的组织化实践。

7. HackDay 的实践

在组织化之前,先说 1 on 1 的一个产物:HackDay。在做 1 on 1 的过程中,有人提出了这个建议。工程师重视日常业务,但没有做盘点的机会。

附带地,我也觉得这可以瞄准个人认为有课题的工程师水平提升。于是,我们开始每月一次,拿出大约八小时,所有人从头脑风暴开始,做盘点业务的 Hackathon。

这项实践一直持续到现在,也变成了和 1 on 1 联动的形式。

8. 招聘第三位工程师

再插入另一个话题。来自工程师培养课程的招聘在 2016 年 7 月结出了果实。也许花了太久时间,但因为之前长期一起做,成员之间已经建立了信任关系,所以成为了最好的招聘。

这个时候,我强烈意识到招聘是自己的工作。在被托付去做产品的过程中,决定想和什么样的人一起工作,并为此准备必要环境,当然也是使命。

现在我们正在招募第四位及之后的成员。首先会由我来听你聊,如果有兴趣,请不要客气,从下面联系。

日本の英語教育を変える✨サービスを作れるエンジニア募集! by 株式会社キャタル _Career at 株式会社キャタル. キャタルでは日本の英語教育の問題を解決したいエンジニアを募集しています。 エンジニアチームは現在3人ですので、機動的に動くことが求められます。企画や要件定義もエンジニアの業務範囲に入ります。チ…_www.wantedly.com

インターネット❌教育サービスのプロダクトマネージャー募集! by 株式会社キャタル _Career at 株式会社キャタル. 教育❌インターネットサービスのプロダクトマネージャー募集! PM職の方にはどのような問題を解決するの定義すること、またその改善を指数化して計測可能にすることが求めれれます。また、実際に物を作る…_www.wantedly.com

プロトタイプ制作からUI/UXデザインまで幅広く活躍するデザイナー募集! by 株式会社キャタル _Career at 株式会社キャタル. プロトタイプかUIデザインまで幅広く活躍するデザイナー募集! エンジニアと一体となってサービスの改善を行っていただきます。また、新しく機能を開発する際のプロタイプの製作なども行っていただきたい…_www.wantedly.com

9. 走向组织化的实践

我们这样建立了团队,但我每天都在为组织烦恼。(产品和战略也每天都在烦恼。)问题是:团队是否集中在应该做的事上?是否最大化了绩效?

因为有 1 on 1 的成功经验,我学习并实践了团队如何运转、心理安全性、Motivation 3.0 等内容。虽然很努力,但始终没有自信说事情真的进展顺利。

不过最近我意识到,在做这些之前,其实还有应该先做的事。那就是建立能够清楚掌握各类项目进展的机制,以及定义期待的角色和其中期待的产出。

(重要的不是掌握项目,而是建立能够掌握项目的机制。)

归根到底,面向产品才是重要的,但我们没能从人的问题中走出来,也没有做好理所当然应该做的事。

举一个由此产生的问题例子:当新成员加入时,话题不是“要把什么交给他”,而是“把他放进哪个团队”。放进哪个团队当然重要,但他要做什么应该更重要。

之所以不会进入那个话题,是因为没有期待角色和产出的定义。如果有定义,加入哪个团队自然会决定,也应该能够直接进入要做什么的讨论。

应该更早注意到啊。是的。

……所以,最近我就在摸索这些事。也许现在运转顺利的事情,之后也可能变得不顺利。

每天都这样四苦八苦,但我们正在招募愿意一起建设机制、一起做服务的成员。与其寻找适合自己的环境,也许自己做出来更快。最重要的是,这很有趣。如果有兴趣,拜托一定联系!

关键词

  • # 开发组织
  • # 工程师培养
  • # 教育企业
  • # 1on1
  • # 招聘