チュートリアルのエンジニアチームのここがスゴイ！ その1 ユニット制度

　某大学のコマーシャルのような見出しで失礼します。
　弊社のエンジニアチームの制度や風土は、良い意味で非常に独特です。今回はその独特な制度の1つである「ユニット制度」についてお話します。

　ちなみに弊社は在宅勤務のメンバーが多く、ちょうどいい写真が撮影できなかったため、ヘッダの画像はフリー素材を使用しています。

　弊社には、2020年7月末現在で11人(代表の福田も含めると12人)のエンジニアが在籍しています。その全てのメンバーが、3つの「ユニット」という小チームに分かれて日々の開発を行っています。

　この「ユニット」は1人のリーダーと2人〜3人のメンバーで構成されています。役割は主に「スプリントの運用」「開発上または勤務上の小さな悩みごとに対するサポート」で、スプリントの運用の一環としてデイリースタンドアップ(朝会)やスプリントミーティングもユニットごとに行っています。

　ユニットは数ヶ月単位、どんなに長くても1年以内に構成が変更になります。その際、基本的にはほぼ全員がフルスクラッチで入れ替わります。
　それは配置を固定化しすぎて属人化に繋げないようにする目的もありますが、エンジニア各人のその時点でのスキルややりたいことの変化に適宜合わせるという目的のほうが主です。配置転換によるオーバヘッドはもちろんゼロではありませんが、開発内容のマンネリ化や不満を溜めることで起こるモチベーション低下を考えると、決して高くはないコストです。
　ちなみに、この8月からまた新しいユニット体制での開発がスタートします。非常に楽しみです。

　ユニットリーダーはリーダーと名乗っていますが、決してオレオレな存在ではありません。スクラムマスターや相談窓口にはなりますが、スプリントプランニングは必ず各メンバーが参画して行います。
　弊社のエンジニアチームは合理性に裏打ちされた納得感を特に重視しています。従って、スプリントプランニングにおいても、合理的な説明を行った上での合意無しで「次はこれやってね」といったようなアサイン方法は取りません。各メンバーが合理性に裏打ちされた納得感をもって全てのスプリントを遂行し、開発を行っています。

　ところで、あくまでこのユニットという概念は、部署ではないという扱いにしています。なぜならば、RPAの機能拡張やアーキテクチャの改善等、複数人で対応する必要のある課題に対して、ユニットを跨いで協力し合うこともしばしばあるためです。部署化してしまうと柔軟性が損なわれる可能性があるため、開発速度やモチベーションの低下に繋がり、また会社の掲げている「自分らしい生き方をクリエイトする」という言葉とも矛盾しかねません。

　いくつかの会社を渡り歩いてきた僕が弊社に入社してから今までを振り返ってすごいなと思っているのは、エンジニアの離職率の低さです。入社してもうすぐ10ヶ月目ですが、その間エンジニアは1人も退職していません。メンバーは常に増え続けています。
　これはユニット制度も含め、ここしばらくの弊社のエンジニアチームの制度や風土が比較的良く働いているためではないかと自負しています。

　とはいえ、弊社のエンジニアチームはまだまだ成長途上、しかもその黎明に差し掛かった程度に過ぎません。人数が増えて成長していくチームに合わせて、制度もどんどん変えていきたいと思います。

　そんな急成長とともに変わっていくチームで一緒に働いてくれるメンバーも、随時募集しています。カジュアルな面談も随時お受けしていますので、ぜひよろしくお願いいたします！