エンジニアリングマネージャーとして中途採用された人間の7ヶ月 -2019振り返りチームビルディング編-

小林毅志
FiNC Tech Blog
Published in
10 min readJan 14, 2020

あけましておめでとうございます。FiNC Technologiesサーバーサイドエンジニアのエンジニアリングマネージャー(※以下EMと表記)をやっているつよぽそです。年末にEM陣で振り返りをしようっていうことで何を書くか悩んだのですが、僕は2019年5月入社なので、EMとして中途採用された人間が7ヶ月間どういうチームを作ってきたのかを書いてみようと思います。
※ちなみに僕はブログ経由でFiNCに声をかけていただいたのですが、そのきっかけになったブログはこちら

1.入社

入社時ですが、最初はマネージャーとしてではなくプレイヤーとして現場にアサインされました。実は入社前から、最初は現場に慣れるところから始めてはどうかと提案していただいたのですが、自分としてもありがたいものでした。

1–1.入社当初に意識したこと

実際は何かを意識したということはなくて、普段通りの仕事をしたとしか言えないのですが、普段何を意識しているかというと、自分の役割を越境することを躊躇しないことです。今回の場合、プレイヤーとしてアサインされていますが、実装だけで満足するのではなく、チームが上手く回るためには自分が出来そうな事は何でもやりました。
タスクの整理
・スケジュール調整
・チームの雰囲気作り
・開発プロセスの改善

とにかく足りない、問題点があると思った部分には積極的に自らノーガードで飛び込んでいきました。初期段階で存在感を出し認めてもらうことで後々の仕事がやりやすくなりました。

1–2.入社後プレイヤーとしてアサインされて良かったこと

EMとして働くからにはマネジメントするだけではだめで、しっかりその会社のシステムを理解していることは必要不可欠だと思っていたのですが、最初に現場で一つのプロジェクトの開発をメンバーとして一緒にできたのはとても貴重な体験になりました。実務でシステムだけでなく、現場のメンバーとのやり取りを通して会社の文化だったり問題点みたいなところも見えてくるので、この期間がなかったらと思うと少しゾッとします。個人的には最初は一プレイヤーとして体験することをお勧めします。入社時の感想として、この辺りのサポートはマネージャー陣が手厚くしていただいたので助かりました。

2.EM就任

入社して2ヶ月が経ち、最初に担当したプロジェクトも無事リリースする事が出来たので正式にEMに就任しました。
サーバーメンバーのマネジメントと平行してFiNCアプリ内で新しいチームを作る事になりゼロからのチーム作りを行いました。

2–1.大きな開発チームからのスタート

2–1–1.個人的に感じた問題点は?

まず、入社してから感じた事はFiNCの特徴は
・人数に対してやりたいことが多過ぎる
・プロジェクトに対して都度人をアサインしようとしすぎて管理が複雑になる
・プロジェクト毎の知見がメンバーで共有しにくい状態になっていて属人性が高い
・確固たる開発プロセスが存在せず、個人の能力によるアドリブによるところが大きい

あくまで個人的な感想ですが全体的にFiNCのアプリチームは規模が大きい割にはそれに対して個人主義が強くチームという概念が弱い印象でした。

2–1–2.問題点の解決策

それに対する解決策がスクラムの導入と開発チームを多く作る事でした。
理由は下記です。
・共通した開発プロセスを導入することでチーム毎の開発を安定させる
・しっかりとベロシティーをとれるようにすることでリリース計画を安定させる
・プロジェクト毎に人をアサインする志向を変えチームにアサインするように変えることで調整の煩雑さを無くしたい
・長期的な開発チームを育てる事でチームメンバーで知見を共有し属人性を排除する

2–1–3.大きな開発チームの結成

さて、いざチームを作るとなった時、問題が発生しました。アサインされているメンバーが1チームでやるには多いが、複数チームを作るほど多くない状態だったことです。
・PO1名
・企画3名(なんと1名は後日エンジニアにキャリアチェンジ!!)
・運用メンバー2名
・serverエンジニア3名(自分含め)
・iOSエンジニア3名(うち新人1名)
・androidエンジニア2名
・QA6名

※弊社は品質を大切にしているので各チームにQAが多数配属しています。素晴らしい!!
自分でも20名近いチームでスクラムをやろうとするのは初めての経験ですが、まずはチームの一体感を作るためにも一つのチームで始める事は正解だとも感じていました。

2–1–4.大きなチーム運営していくうえでのメリット・デメリット

実際20名近いスクラムチームを運営していったなかでのメリット・デメリットを紹介します。
メリット
・チームとしての一体感を作る事ができる
・チーム全員で何を作っているのかの共通認識ができる
・チームが一つなのでコミュニケーションが早い
・チームが一つなのでスクラムマスターが不足している状況で何とか運用していくことが可能
・一つのバックログで進める事ができる

デメリット
・デイリースクラム等で密度の濃いコミュニケーションが出来ない
・人が多すぎるが故にどうしても受け身にまわりがちなメンバーが出てしまう
・やろうとしていることの意図の説明が難しい

2–2.開発チームの分割

ここでは書ききれないので割愛しますが様々な困難があったなか幸運にもメンバーも増え、スクラムも少しずつ浸透していきました。一方人数が増えた事によりデメリットのほうが目立つ状態になってきました。そこで開発チームを分割する決断をします。

2–2–1.分割前の仕込み

チームを結成した際、最初からチームを分割していくこと前提で運用してました。そこで少しだけ進め方を工夫していました。
・最初、タスクはできるだけ別け隔てなくメンバーにふっていく
・人数が増えてきたタイミングで徐々に同じストーリーを担当する人員を意図的に同じメンバーの組み合わせにしていく
・レトロスペクティブもなるべく特定の組み合わせでまとまって開催する

※メンバーには出来る限りどのタスク、誰と組んでも大丈夫だという心構えを持ってもらうために意図的にメンバーを寄せている事は言わなかった

2–2–2.開発チームを分割

人数がある程度増えた事と発展途上とはいえスクラムの進め方が浸透してきた事で開発チームを3つに分割する決断をしました。2つにしておくか悩みましたが今後の事業も考えると3つのチームに分割していく事が望ましいと考えたからです。一方分割することでグループ全体の一体感が失われる事も懸念していたのでなるべく一体感を失わないチーム分割を心がけました。
チームの運用方法は以下です。
・バックログは変わらず一つで運用する
・見積もりはエンジニアが全員集まりプランニングポーカーを行う
・スプリントプランニングは全チーム一緒にやる
・デイリースクラムはチーム毎に分かれておこなう
・レトロスペクティブは同じ時間、同じ場所でやるが開発チーム毎に行い、最後に全体で発表会を行う

2–2–3.分割したメリット

チームを分割してから結果がすぐ出ました
・デイリースクラムでの内容の密度が高くなり、しっかりと問題点を話し合えるようになる
・少人数であるため全員に当事者意識が芽生える
・人数が多かった時はデイリースクラムのファシリテーションをリーダー陣でやっていたが、各メンバーで担当を交代で出来るようになった
・各チームで工夫するようになったのでチームの特色が出てきた
・人数が減った事でチームへのコーチングが容易になった等

他にも色々ありますが大きいチームで開発していた時と比べると遥かに運営が簡単になりました。
一方、一つのチームから分割したが、バックログや見積もりをグループ全体でやっているため、今の所は目立ったデメリットは出ていないと感じています。
・他のチームが何をしているのかある程度把握している
・バックログが一つのため、特定の施策に集中したい場合は複数チームが
同じ施策のストーリーチケットを消化することができ優先度が高いものからスピード感をもって対応することが可能
といった状態にすることが出来ています。
※完全ではないがLeSSに近い開発体制になっています。
※独立したプロジェクトを担当しているチームもある

2–2–4.現在

現在は更に開発チームが一つ増え、4つの開発チームに増えています。

2–2–5.もしまたゼロからチームをスケールさせていくとしたら?

状況が許さなかったとはいえ、最初から大きなスクラムチームを作る事はお勧めしないです。今の自分なら出来ることなら下記の2つを選ぶかと思います。
・小さいスクラムチームで始め大きくなったら分割を繰り返す
・最初から複数の小さなスクラムチームを作る

※スクラムマスターやPOを出来るメンバーがいればだけど

3.まとめ

入社してから7ヶ月、色々やってきてはいたのですが、今回はEMとしてのオンボーディングとチームビルディングに絞って書かせていただきました。他の話しはまた別の機会で。

3–1.EMのオンボーディングまとめ

・最初はプレイヤーとして入った方が現場がわかるので良い
・一プレイヤーとして作業していたとしてもリーダーシップを発揮することは周りに認めてもらうためには重要
・なんだかんだ周りのマネージャー陣がフォローしてくれていたと感じたのでありがたかった

3–2.開発チームの立ち上げまとめ

・広く言われていることだが、大人数でスクラムチームを作ることはそれなりに辛いと実感
・一方チームの一体感を作ることはできた
・分割を見越してチーム運営を進めておくと比較的スムーズにチーム分割できる
・LeSSは出来ていないが一つのバックログで運用していくことのメリットは享受できた

3–3.今後の目標

現在、僕は担当グループの4チーム中3チームのスクラムマスターをしています。正直余裕のない日々が続いてキャパオーバーだったことも自覚しています。そこで今後は以下の事をやっていきたいと思っています。
・スクラムマスターを育て、自分はチームを持たないor新しいチームを育成することのみに集中する
・時間に余裕をもたせ、実装する時間を作る
・チームビルディングに比重を置きすぎたのでもっと技術的な課題と向き合う

3–4.We are hiring!!

弊社はまだまだ、やりたい事が沢山あります。それに対してエンジニア・EM共に圧倒的に足りない状態です。課題も沢山あります。そんな課題を一緒に解決していってくれる仲間を募集しています。
ぜひ応募してくださいませ。楽しく働きましょう!!

--

--