readあけましておめでとうございます。Technologiesサーバーサイドエンジニアのエンジニアリングマネージャー(※以下EMと表記)をやっているつよぽそです。年末にEM陣で振り返りをしようっていうことで何を書くか悩んだのですが、僕は2019年5月入社なので、EMとして中途採用された人間が7ヶ月間どういうチームを作ってきたのかを書いてみようと思います。入社時ですが、最初はマネージャーとしてではなくプレイヤーとして現場にアサインされました。実は入社前から、最初は現場に慣れるところから始めてはどうかと提案していただいたのですが、自分としてもありがたいものでした。1–1.入社当初に意識したこと実際は何かを意識したということはなくて、普段通りの仕事をしたとしか言えないのですが、普段何を意識しているかというと、自分の役割を越境することを躊躇しないことです。今回の場合、プレイヤーとしてアサインされていますが、実装だけで満足するのではなく、チームが上手く回るためには自分が出来そうな事は何でもやりました。・チームの雰囲気作り・開発プロセスの改善とにかく足りない、問題点があると思った部分には積極的に自らノーガードで飛び込んでいきました。初期段階で存在感を出し認めてもらうことで後々の仕事がやりやすくなりました。1–2.入社後プレイヤーとしてアサインされて良かったことEMとして働くからにはマネジメントするだけではだめで、しっかりその会社のシステムを理解していることは必要不可欠だと思っていたのですが、最初に現場で一つのプロジェクトの開発をメンバーとして一緒にできたのはとても貴重な体験になりました。実務でシステムだけでなく、現場のメンバーとのやり取りを通して会社の文化だったり問題点みたいなところも見えてくるので、この期間がなかったらと思うと少しゾッとします。個人的には最初は一プレイヤーとして体験することをお勧めします。入社時の感想として、この辺りのサポートはマネージャー陣が手厚くしていただいたので助かりました。入社して2ヶ月が経ち、最初に担当したプロジェクトも無事リリースする事が出来たので正式にEMに就任しました。サーバーメンバーのマネジメントと平行してFiNCアプリ内で新しいチームを作る事になりゼロからのチーム作りを行いました。2–1.大きな開発チームからのスタート2–1–1.個人的に感じた問題点は?まず、入社してから感じた事はFiNCの特徴は・人数に対してやりたいことが多過ぎる・プロジェクトに対して都度人をアサインしようとしすぎて管理が複雑になる・プロジェクト毎の知見がメンバーで共有しにくい状態になっていて属人性が高い・確固たる開発プロセスが存在せず、個人の能力によるアドリブによるところが大きいあくまで個人的な感想ですが全体的にFiNCのアプリチームは規模が大きい割にはそれに対して個人主義が強くチームという概念が弱い印象でした。2–1–2.問題点の解決策それに対する解決策がスクラムの導入と開発チームを多く作る事でした。・共通した開発プロセスを導入することでチーム毎の開発を安定させる・しっかりとベロシティーをとれるようにすることでリリース計画を安定させる・プロジェクト毎に人をアサインする志向を変えチームにアサインするように変えることで調整の煩雑さを無くしたい・長期的な開発チームを育てる事でチームメンバーで知見を共有し属人性を排除する2–1–3.大きな開発チームの結成さて、いざチームを作るとなった時、問題が発生しました。アサインされているメンバーが1チームでやるには多いが、複数チームを作るほど多くない状態だったことです。※弊社は品質を大切にしているので各チームにQAが多数配属しています。素晴らしい!!自分でも20名近いチームでスクラムをやろうとするのは初めての経験ですが、まずはチームの一体感を作るためにも一つのチームで始める事は正解だとも感じていました。2–1–4.大きなチーム運営していくうえでのメリット・デメリット実際20名近いスクラムチームを運営していったなかでのメリット・デメリットを紹介します。・一つのバックログで進める事ができるデメリット・デイリースクラム等で密度の濃いコミュニケーションが出来ない・人が多すぎるが故にどうしても受け身にまわりがちなメンバーが出てしまう・やろうとしていることの意図の説明が難しい2–2.開発チームの分割ここでは書ききれないので割愛しますが様々な困難があったなか幸運にもメンバーも増え、スクラムも少しずつ浸透していきました。人数が増えた事によりデメリットのほうが目立つ状態になってきました。そこで開発チームを分割する決断をします。2–2–1.分割前の仕込みチームを結成した際、最初からチームを分割していくこと前提で運用してました。そこで少しだけ進め方を工夫していました。人数がある程度増えた事と発展途上とはいえスクラムの進め方が浸透してきた事で開発チームを3つに分割する決断をしました。2つにしておくか悩みましたが今後の事業も考えると3つのチームに分割していく事が望ましいと考えたからです。分割することでグループ全体の一体感が失われる事も懸念していたのでなるべく一体感を失わないチーム分割を心がけました。チームの運用方法は以下です。他にも色々ありますが大きいチームで開発していた時と比べると遥かに運営が簡単になりました。一つのチームから分割したが、バックログや見積もりをグループ全体でやっているため、今の所は目立ったデメリットは出ていないと感じています。・他のチームが何をしているのかある程度把握している・バックログが一つのため、特定の施策に集中したい場合は複数チームが同じ施策のストーリーチケットを消化することができ優先度が高いものからスピード感をもって対応することが可能といった状態にすることが出来ています。※完全ではないがLeSSに近い開発体制になっています。現在は更に開発チームが一つ増え、4つの開発チームに増えています。2–2–5.もしまたゼロからチームをスケールさせていくとしたら?状況が許さなかったとはいえ、最初から大きなスクラムチームを作る事はお勧めしないです。今の自分なら出来ることなら下記の2つを選ぶかと思います。・小さいスクラムチームで始め大きくなったら分割を繰り返す・最初から複数の小さなスクラムチームを作る※スクラムマスターやPOを出来るメンバーがいればだけど3.まとめ入社してから7ヶ月、色々やってきてはいたのですが、今回はEMとしてのオンボーディングとチームビルディングに絞って書かせていただきました。他の話しはまた別の機会で。現在、僕は担当グループの4チーム中3チームのスクラムマスターをしています。余裕のない日々が続いてキャパオーバーだったことも自覚しています。そこで今後は以下の事をやっていきたいと思っています。hiring!!弊社はまだまだ、やりたい事が沢山あります。それに対してエンジニア・EM共に圧倒的に足りない状態です。そんな課題を一緒に解決していってくれる仲間を募集しています。応募してくださいませ。Technologies現在、エンジニア組織が60名以上の規模に拡大しており、マネジメントの力でチームやプロジェクトの成果を大きく向上させることができるフェイズを迎えています。Technologiesは、「すべての人にパーソナルAIを」をミッションに掲げる予防×ヘルスケア×テクノロジーに特化したベンチャー企業です。Technologiesは、「すべての人にパーソナルAIを」をミッションに掲げる予防×ヘルスケア×テクノロジーに特化したベンチャー企業です。UpgradeAboutHelpLegal。