この記事はReviCo Advent Calendar 2025 の1日目の記事です。
はじめに
この記事では、ReviCoが初の試みである2チーム体制でのスクラム開発をはじめた動機、得られたメリット、難しかったポイントについて解説します。
なぜチームを分けたのか？
ReviCoは開発初期からスクラム開発を採用しており、エンジニアの数も増減はあったものの8~10人ほどで安定していたため、基本一つのチームで開発していました。ただ安定しているとはいえメンバーが増えていくなかでコミュニケーションコストが増えていったことと、人数に対して開発スピードが上がっていないのではという経営層からの疑問があり、今年の7月から2チームで開発体制をとることになりました。
どのように分けたのか？
どのようにチームを分けるのかというのは会社によって様々かと思いますが、多くは製品の機能でチームを分ける方法が多いと思います。
ただ今回ReviCoでは機能単位でチームを分けるのではなく、同じ製品でも主に新規開発を担当をするチーム、細かい機能改善を担当するチームという領域で分けました。
なぜこのような分け方になったのかというと、前述の「開発スピードがあがっていないのでは？」という話にもつながるのですが、直近のReviCoの開発自体は新機能開発に特化していたため、一つのチームの開発では中々細かい既存機能の改善に手が回っていなかったためです。
またスクラムイベントをはじめとした会議体も完全に分離するのではなく、各チームで担当するもの、合同で開催するものに分けました。
▼各チームで開催
・デイリースクラム
・プランニング
・リファインメント
・スプリントレビュー
▼合同で開催
・（OKR）チェックイン
・レトロスペクティブ
チーム名はメイン機能開発を担当するチームを「ルビーチーム」、細かい機能改善を担当するチームを「サファイアチーム」としてスタートして、私はサファイアチームのプロダクトオーナーとして開発が始まりました。
どのような効果があったのか
実際に2チーム体制でスクラム開発することで、始めてから半年で以下のような効果がありました。
リリースする機能が約2~3倍増えた
まず一つ目は、当初目的としたリリース量の増加です。これはもともと狙っていた事であったため、大きな効果です。
ReviCoでは2週間に1回定期リリースを行っているのですが、一つのチームで開発していたときには1リリースにつき機能が約4項目だったのところ、2チームを開始してから約12項目ほどに増えたため、およそ2~3倍もの機能をリリースすることができるようになりました。
コミュニケーションコストが下がった（効率化した）
これはやや主観も入るのですが、一つのチームあたりの人数が減ったことにより、リファインメントをはじめとした会議体でのコミュニケーションが円滑になりました。これにより、意志決定に掛かる時間や実装時の相談にかかる時間を効率化できています。
逆に何が辛くなったのか
嬉しいこともあれば辛くなることもありました。
ここでは大きく二つの辛みを共有します。
リリース作業が大変
良い効果の裏返しではありましたが、リリースされる量が増える分、その分に対してのリリース手順書の作成や実際のリリース作業にも時間がかかるようになりました。今後はリリース作業の効率化も考慮して、複数チームでの円滑にリリースできるような仕組みを考えていきたいです。
（場合によっては）同じ機能に関するモジュールに手を付けることになる
機能単位でチームを分けることはしていないため、チーム間で同じ機能に関する改修がバッティングしてしまうことがありました。頻度としてはそれほど高くなく、PO間での情報共有や別チームのリファインメントに参加することなどで極力防がれていました。ただしコミュニケーションコストはそれなりにあるため、理想としては機能単位でチームを分割していくのが良いかと感じました。
おわりに
ReviCoとしては初の2チームのスクラム開発でまだ数カ月ほどではありますが、大きな変化がありました。狙いとしていた開発量は増えたものの、リリース作業やモジュール競合などの辛み等の課題は出てきたため、これらの課題の解決に取り組みながら、より良いプロダクトを作っていきたいです。