昨年の12月、私たちの開発チームは20人でした。それが今では、およそ倍の39人に。まさに怒涛の1年。アドベントカレンダーを埋められるまでに成長しました。
この急成長の中で、私たちがどのように変化し、課題に向き合ってきたかをお話しします。
はじめに
こちらはe-dash Advent Calendar 2024の1日目です。
筆者はCO2排出量可視化サービスを提供するe-dashでPMをしているzcです。
チーム増加の変遷
2024年初頭、私たちは主に2つのチーム体制で開発を進めており、開発チーム全体の人数は24名でした。
2024年3月末にメインプロダクトのリニューアルを実施したことをきっかけに、チーム編成に大きな変化が訪れました。これまでは、1つの大規模なプロジェクトに多くのメンバーが集中する形でしたが、リニューアル後は目的（ミッション）別にチームを分ける体制へと移行しました。
新しい体制では、機能改善や拡張を目的とした5つの開発チームと、柔軟にタスクを処理する3つのタスク型チームの合計8つのチームが編成されました。この時点でチーム全体の人数は25名でしたが、一部のメンバーは複数のチームを兼任していました。
さらに、組織の変化を後押しする形で、新しいメンバーの採用も進みました。QAやSREといった新しい役割を担うメンバーが加わったことで、各チームの役割分担がミッションとして明確化され、効率的かつ柔軟な体制を目指せるようになりました。
QA,SREはそれぞれ横断的な別のチームとしており、開発の8チームと合わせて合計10チーム、メンバーは39人となりました。
(PM,Designerはそれぞれ別の組織ですが、開発チームのメンバーとして動いています）
チーム増加で生じた変化
チーム単位の会話が増加
以前は少人数だったため、開発全体で頻繁にミーティングを行っていましたが、現在では全体の集まりは月に1回のオンラインミーティングのみに限られています。代わりに、各チーム内での会話が中心となり、特にチーム横断的なプロジェクトでは意識的な連携が重要になりました。
レポートラインの分散化
以前は開発部長一人に依存していたレポートラインを、各チームにグループマネージャーを設置することで分散型の体制に移行しました。この変化により、チームごとの裁量が増えただけでなく、マネージャー同士での議論が活発化しました。
分散化の体制に移行したイメージ図
チームが増えたことで直面した課題
チーム数の増加に伴い、新たな課題も見えてきました。
突発的な運用タスクへの対応
現在、メインプロダクトであるe-dashのフィードバック対応やバグ対応といった突発的な運用タスクは、1つのチームが専任で担当しています。
以前は1チームの人数が多かったため、突発的な運用タスクが発生しても大きな問題とはなりませんでした。
しかし、チームが細分化された現在では、この運用チームへのタスク集中が課題となっています。
特にスクラム開発を採用している中で、運用チームは既存のバックログからスプリントの計画を立てますが、突発的なタスクの発生を予測して計画に組み込むことは困難です。
そのため、スプリント中に新たなタスクを差し込む形で対応しています。しかし、この方法では計画外のタスクが増加し、スプリント内での計画が完了しないことが起きています。結果として、チームの疲弊を招く一因となっています。
また、運用タスクが特定のチームに集中し続けるのは、長期的には健全ではないと考えています。
この課題への対応は、今後の重要なテーマとして開発チーム全体で考える必要があります。
（一つずつ解決策を試しているところです！）
組織としてのコミュニケーション
これまでも組織全体に情報を伝達するのは難しいという課題は存在していましたが、現在ではさらに開発チーム全体で集まる機会が少なくなり、どのチームが何を開発しているか、そしてそれが自チームの作業とどう関連しているのかが見えにくくなりました。
このため、他チームとの開発タスクと被らないかコミュニケーションが都度発生することが課題となっています。
また、リモート環境では文章によるコミュニケーションが主流になるため、やり取りがシンプルになりがちです。
これは効率的な一方で、対面で話すような自然な広がりや関連する話題への発展が生じにくい場面もあります。こうした側面を補うため、対面に近いコミュニケーションを意識的に取り入れることが有効だと感じています。
解決策としてのGoogle Meetとgatherの活用
これらの課題に対する解決策として、文章のやり取りが増えてコミュニケーションが滞りそうな場合は、Google Meetやgatherを活用し、気軽に集まって話すようにしています。
特にgatherは、バーチャルオフィス空間としての役割を果たしており、チームメンバーが「どこにいるか」「話せる状況か」を簡単に把握できます。例えば、gather内で他のチームが会議をしている場に気軽に混ざり、話を聞いたり質問をすることが可能です。これにより、関連する情報が自然と共有される機会が増える点がメリットです。
さらに、UIの親しみやすさもあり、チームメンバーが参加しやすい環境を提供しています。
e-dashで利用しているgatherのキャプチャ
ミッション型チームへの移行と学び
この1年の経験を通じて、私たちは組織が大きくなると、タスク型からミッション型への移行が必要になるということを実感しました。各チームが明確なミッションを持ち、そのミッションにメンバーが共感し、追従できる形を目指すことが重要です。
ただし、ミッションをメンバーに共有し、それを「語れる状態」にするのは簡単ではありません。
チームのミッションがどのようにプロダクトやビジネスに貢献するのかをメンバーが理解するためには、ドメイン知識を深める必要があります。
そのため、ミッションを語る機会を増やすと同時に、メンバーが自分の言葉でそれを説明できるような場を作る努力を続けています。
これから
チームがさらに増える可能性を見据えながら、私たちは「ミッション型チーム」を軸とした組織づくりを進めています。このプロセスはまだ道半ばですが、各チームが自立しながらも連携を深め、より大きな価値を生み出せる組織を目指していきたいと考えています。
e-dash Advent Calendar 20242〜4日目は頼れるSRE Engineerのkoheiによる大作をお届けします！
Discussion