プロダクト成長に伴うチーム体制の進化について
みなさん、こんにちは、Webアプリグループの出渕です。
現在の弊社開発部の体制は職能別組織と、機能別チームの二軸で活動をしています。また、職能別組織はグループ分けされており、プロダクト(※)、デザイン、Nativeアプリ、Webアプリという構成になっています。
※プロダクトマネジメント業務全般、品質管理、UXデザイン等
このグループの中でも一番人数が多い(10人程)Webアプリグループ内を更にチームとして分割した時の変化について紹介させていただきます。
背景
以前にも紹介しましたUIリニューアルでは2年越し10数名が関わる大プロジェクトで、この時の課題感を整理し、今後の施策を推し進めるべく、弊社初のスクラム開発を導入することになりました。
開発メンバーの中には、スクラム開発経験者もいましたが詳細を語れる人はおらず、唯一の経験者2019年1月就任のCTO佐橘が先導して推し進めることになりました。（その時の様子をこちらの記事にまとめています）
スクラム開発では、チームの人数は少な過ぎず、多すぎずの３〜９名が最適で、ジェフ・べゾスの「ピザ2枚の法則」で提唱されているとおり、全員が積極的にプロセスに貢献でき、意思決定に参加できるようなチームが理想と言われています。
目的別にチーム分け
チーム分け当初、開発部の取り組みとして「MRR(※)上げる」、「Churn Rate下げる」という軸での施策を立て、各メンバーの経験値とチームバランスを考慮し、目的別に2チームの体制を組むことになりました。
※ MRR… Monthly Recurring Revenue
チーム分けしてコミュニケーション取りやすくなった等、良い点もありましたが、メンバーから不満の声があがり課題も出てきました。
課題１：チームの目的が不明確
各チームのバックログアイテムを整理していると「MRR上げ」「Churn Rate下げ」どっちに影響？など棲み分けすることが難しい、要はこの目的軸でのチーム分けが難しいことに気が付きました。
課題２：案件規模と人数のバランスが合わない
案件を推し進めてるとA案件は2人で十分なので、残りの3人はB案件に着手しようということがありました。
これでも1〜2週間など短期間で完了する内容なら問題ないのですが、長期に渡る案件もあり、案件毎に担当メンバーが割り振られチーム内でも関わりがない案件が出てくるようになりました。
その影響で無駄な打ち合わせが多い等、効率悪いという事態に。
チーム体制の見直し
まず大きく変更したのがチーム分けの考え方です。
施策を軸として分けてましたが、これを「大規模案件・小規模案件」というように案件規模を軸にするという考え方に変更しました。
大規模案件チームは、新機能開発など長い期間(1ヶ月以上)かかる案件、小規模案件チームは小さなUI改善、不具合改善など、1日〜1ヶ月規模の短い期間で完結する案件を実施します。
さらに大規模案件チームは、案件内容によって人数が多い問題が生じていたので更に案件毎のチーム構成に変更しました。
見直した結果
小規模案件チームは小回りを利かせながら、小さく早くユーザーへ価値をお届けする、大規模案件チームは長期戦に集中し新機能など新たな価値を創出することを目的としたチーム体制となりました。
余談ですが
弊社ではこの各チームに愛着が湧くようにチーム名をつけています。
大規模案件チーム：Ant、小規模案件チーム：Losingo
今回のブログでは、このチーム名の由来は割愛します…
まとめ
最初のチーム分けとなった「MRR上げる、Churn Rate下げる」という軸ではサービス運営側の視点が大きく、そこが良くなかったと感じています。
ユーザーへの価値を最大限高めることが一番の目的であって、そこに向けてどのような課題があり、それを解決するにはどのようなチーム体制が良いかを考えていくことが重要だということを学びました。
現在もこの体制の延長上にいますが、他の課題も見えてきているので、全員一丸となって更に良い体制を構築していきたいと思います。
最後に
現在スタディストでは一緒にマニュアル作成・共有プラットフォーム Teachme Biz を作っていく仲間を絶賛募集しています！
こんな変化し続けるチームで一緒に開発したい方、ご興味を持っていただいた方は是非 ↓ をご覧ください！
