Squad(開発体制)で開発した話

Last updated at 2023-12-13Posted at 2023-12-13

これはHubble Advent Calendar 2023の10日目¹の記事です。

はじめに

Hubbleで業務委託としてフロントエンドを担当している@beltway7です！

Hubbleでは、2022年からSquadを採用しており、実際にSquadを導入したことで、どんな開発をしているかの話をします。

元々Spotifyが採用していた組織体制で、チームを小さな分隊(Squad)に分けて開発することです。

HubbleのSquadについて詳しく知りたい方は、以下に詳細が記載されていますので、ご一読ください！

CTOとフロントエンジニア２人が爽やかな笑顔で映ってます。（ちなみにこの写真に私はいませんww）

そして、Squadを採用し、2つのチームが形成されました。

NPS、NewMRRどちらも下記の流れで開発しています！

少ない人数でSquadを組んでるので、私が開発を担当するときは、PM、バックエンドエンジニア、フロントエンジニア（私）、QAの４人が最小人数になります。

メンバーが少ないことで、仕様を詰める時や、会話する必要がある時は、パッと集まることができるし、コミュニケーションコストも非常に低いです。

何かあれば、すぐにhuddle(Hubbleじゃないよ)で会話できます！

人数が少ないので、不明点などあれば、気づいた人がすぐ対応or声がけする気がしてます。

不明点をそのままにしておくと、結果、QA期間で不具合発覚して、急いで修正するのは、エンジニア側の負担になります。

なので、それぞれがしっかりと仕様を検討し、QAの時に「そういえば、〇〇は議論してなかったな」ってことは、ほとんどありません。

私が所属してるNewMRRチームは「新規顧客獲得のための開発にフォーカス」を目的にしてます。

目的がハッキリしてるのでPMだけでなく、エンジニア、QAも同じ目的を持っていると、議論をする時に空中戦になることを防げます。

目的がハッキリしていないと、仕様の議論で揉めるケースが結構あります（経験談）

なし（今の所、思いつかないです）

Hubbleで初めて、Squadを体験しましたが、個人的には良いことばかりでした。

それに、Squadの記事にもあった通り、既存顧客のための開発にフォーカスと新規顧客獲得のための開発のように、別々の目的がある場合、Hubbleのようにチーム分けすると、それぞれ独立して開発できるため、議論しやすく、開発スピードも向上すると期待しています！！

明日は power3812 さんです！