「超」 自律性を追求してプロダクトチームを分割した話
アルプの共同創業者で開発を担当している竹尾（@showmant_）です。
アルプではサブスクリプションビジネスを行う企業向けに、今まで手作業や自社開発がスタンダードだった契約や請求の管理を SaaS として提供する Scalebase というプロダクトを開発しています。
2021年11月時点で全社員30人のうち、プロダクトチームが20人という規模になりました。全員でScalebase という1つのプロダクトを阿吽の呼吸で進めることは、かなり困難になってきました。そこで1チームだったプロダクトチームを3つのチームに分けることにしました。
この記事では、チームを分けるに至った経緯や期待していること、今後の課題などについてお話いたします。
1プロダクト20人のプロダクトチーム
チームを分ける前は、プロダクトマネージャー（以下、PdM）やビジネスメンバー（以下、Biz）によって新機能や機能改善などを要件定義され、その機能を実装する段階でエンジニアをアサインしていました。
プロジェクトマネージャー（以下、PjM）がハブとなり、PdMと機能を実装するエンジニア、それぞれと進捗コミュニケーションをしていました。大枠で説明すると以下のような図です。
1チームでうまくいったところ
以下のような点に関しては、明確にうまくいっていました。
・プロジェクトの進行が順調なのかなどの納期に関するコミュニケーションが PjM に集約され、並列度が高くても大事故が発生しなかった
・ある機能実装の進捗が悪いときに、他のメンバーをアサインするなど、チームの柔軟性が高かった
・こぼれそうなボールを拾ったり、割り込みタスクを整理したりなど、うまく PjM がコントロールしてくれた
PjM のスキルの高さもあり、エンジニアはアサインされた機能の実装にフォーカスすることができました。
1チームで課題になったところ
PdM をチームに内包できなかったので、素早くコミュニケーションを取って仕様を決めることに対しては、ベストなアプローチではなかったです。
また、Biz とエンジニアのコミュニケーションパスが遠くなり、多少隔たりができてしまいました。
要件定義をしている Biz のメンバーは、期日に間に合うかの不安がありました。一方で、実装しているエンジニアも宣言した見積もりをやりきるために多少なりともプレッシャーを感じながら開発していました。
ロードマップ開発の期日がタイトであることも重なり、もっと速く開発するにはどうしたら良いのかなどの開発を改善するための時間が作れず、期日に追われて自由が効かない状態でした。
できればチームは分けたくはない
できればチームは分けずに、常に全体で情報が密に共有されていることが望ましいです。全員が全領域について理解があり、フルスタックエンジニアの集団で、どこのドメインでもすぐ実装できるのが最強だと思っています。
そうできるのであれば1チームで突き進むのは OK だと思っています。しかし、少なくともアルプでは、全員が一丸となって進めることに限界を迎えています。全員が阿吽の呼吸で頑張っていける環境ではなくなっていました。
パフォーマンスを改善するためにどういうチームにすべきか
上述のような課題があり、またメンバーが増えてチームを分割できる体制になったこともありチームを分割しました。
プロダクト開発組織は、事業が目指すビジネスの方向に対して、最速で目的を達成できるような体制を作るべきです。
ただ、機械的に人を配置してはダメです。人はずっと同じ動きをするわけではなく、やることに対して相性があったり、一人ひとりに好不調の波があります。人間がチームを形成し、チームがプロダクトを作ることを前提に、個々のパフォーマンスを上げるためのチームを作ることが大切です。
エモいことでもなんでもないのですが、楽しく開発しないと続かないと思っています。売れるプロダクトを作るために楽しく開発したほうが良いと考えています。
どういうチーム分けにしたか
現時点ではチームをオブジェクティブ（目的）ごとの3つに分けてみようと考えています。
領域開発チーム
横の網羅性を担保するチーム。Scalebase をより多くのお客様に使ってもらうために、現状、アプローチできていない領域のお客様に対しての機能開発をしていく。
強化開発チーム
縦の網羅性を担保するチーム。今ご利用いただいているお客様を含めて、現在 Scalebase を提供している領域に対してどんどん機能開発していく。
体験改善チーム
なめらかなオペレーションを担保するチーム。Scalebase は機能追加に伴い、徐々に複雑になっています。新規のお客様にとってはわかりやすく、既存のお客様にとっては日々のオペレーションを円滑にするために改善していく。
現在、プロダクトチームは領域開発・強化開発の2チームですが、今後入社予定のメンバーを中心に体験改善チームを作る予定です。
チームを分けて達成したいこと
価値を一気通貫で届けられる超自律チーム
それぞれのチームがクロスファンクショナルなスキルを持って、他のチームを待たずに自律して開発を進められる力を持つことが大事です。
PdMやデザイナー、フロントエンド、バックエンドなどが各チームにいるという話ではなく、全員で必要な職能をカバーし合えることが重要です。フロントエンドのメンバーがデザインを担当しても良いし、必要に応じて職種を超えた動きをしてもらいたいと考えています。
最速で意思を決定するチーム
コミュニケーションパスを絞って、チーム内の必要な人と密に関わってほしいと思っています。そのために朝会をチーム単位にするなど、とにかくチームのコミュニケーションの機会を増やしています。
アルプでは、行動指針として「オーバーコミュニケーション」というバリューがあります。社内全体に向けたこの「オーバーコミュニケーション」の向き先や頻度をチームに変えるイメージです。
基本的には、チーム内では高帯域で、チーム外では低帯域で会話して欲しいと思っています。必要に応じてチーム同士で頻度高く会話することは重要ですが、以下のような形でコミュニケーションを変えて行くのが大事だと考えます。
出典: Team Topologies Part1 Chapter2 より
トライと成果をチーム間で共有する
チーム同士で会話することも重要で、「こんなことやって良かった」というトライと成果は他のチームに共有すべきです。チームを分けることで、より多くのイノベーションを生む確率はあがりますし、伝搬して欲しいです。
チームを分けたことで待ち受けるであろう困難
チーム外でのコミュニケーションの増加
当然ですが、本当に正しいチーム分けは存在しないし、チーム外とのコミュニケーションも、だんだん増えていくと思います。
増えてはダメという話ではなく、そういうものだと思っています。例えば、ドメインでチームを分けたとしたら、実は別のドメインと密に結合していて、そのドメインでチームを分けてはいけなかったなどです。
そういうことを感じたときは、新しいチーム構成を考えるシグナルだと思っていて、注意深く見ていくつもりです。
複雑な領域のコードオーナーシップの希薄化
複数のチームが、それぞれ複雑なモジュール開発をしたときにコードオーナーシップの低下が起こると懸念しています。例えば契約や請求などのドメインは複雑ですし、外部連携サービス一つ取っても同様です。
不具合が起こったときに、別のチームが実装したところだし、自分たちが解決しなくても良いだろうというマインドになる傾向も想定できます。
これを解決するために、複雑性を低減するような技術的なアプローチを考えていきたいですし、コードオーナーの制定や複雑なサブシステムについては、別チームを設けるなどが考えられます。例えばAIの領域などは、誰でも開発できるものではないので、部分的に別チームに分けるなどがわかりやすい例です。
最後に
チームには自律性を追求してもらいたいです。それが開発としてのやりやすさやパワーの出しやすさにつながります。
上からの指示や業務をこなしていくのではなく、チームが一体となって探索しながらプロダクトを作っていくことが結果的に一番スピードを出してくれます。
まだチームを分けてから1ヶ月足らずなので、運用して良かった点や課題などあれば今後、記事にする予定です。
アルプではエンジニア含め、積極的にメンバーを募集しています。今回の記事を見てご興味を持ちましたら、ぜひ私と Meety でカジュアルにお話しましょう！
この記事が気に入ったらサポートをしてみませんか？