チームを分割する指針として何が適切か

はじめに

現在、私は、とあるソフトウェアプロダクトを開発する数十名規模のチームに所属している。このチームに対して適切な組織と開発プロセスを適用したいと思い良いスタイルを探している。

今日は、そういった事を考えている内に出てきた1つのアイディアについて書き留めたいと思う。

先にどのようなアイディアなのか結論を書く。

数十名規模のチームにScrumを取り入れる方法として、Scrum of Scrumというスタイルがある。
Scrum of Scrumで重要になるのは、各チームをどのように分割するかだ。
『単独で「ユーザーに届けるべき価値」を作れる独立したまとまりになる事』を指針としてチームを分割するのが良さそうだ。
- この指針には、チーム内のコミュニケーションをシンプルで密にし自己組織化を促進する効果がありそうだ。

(うまくいけば)自己組織化が行われ、未知の状況に対する適応能力が高くなるのはScrumの良い点だ。

しかし多人数のチームにScrumを適用しようとすると色々問題も出てくる。

例えばデイリースタンドアップミーティングや、スプリント計画などを10名以上で行うにはかなりの困難だろう。

数十名規模のチームで、これを実践出来ているチームを見たこともあるが(驚異的だと思う)、そういう事が出来るチームを意図的に作り出す事は難しい事だし、長期的な取り組みが必要だ。

なにか、別の選択肢は無いだろうか。

この問題について、DeNAのComm開発チームが面白い取り組みをしている。

Scrumを行う小さなチームを複数用意して、それらのチームのPOで更にScrumを行うという方法によって、多人数のチームにScrumを適応しているのだ。（Scrum of Scrumと言うらしい）

確かに、この方法ならScrumのスタイルを維持したまま、大規模な開発が出来そうだ。

この"小さなチームの複合体"を実現するにあたっては、チームの分割方法が重要になると思う。
いや、今はScrum of Scrumについて書いたが、どのような開発プロセスであってもチームの分割は重要なテーマだと思う。

今のところ、たぶんこう言う事が重要になるのでは無いかと思っている。

「単独で「ユーザーに届けるべき価値」を作れる」そのために…
- 目的を持っている事
- 何をどういう順番で行うか決定する権限を持っている事
- 開発に必要な全ての機能を持っている事 (エンジニアだけ、とか企画だけ、では無い)

高凝集、疎結合であればコミュニケーションパスはシンプルで密になる。これは自己組織化を行うにあたって重要な点だと思う。

この本に『「創って、作って、売る」小さなチーム』というコンセプトが登場する。

職能別の縦割り組織を、プロダクト別の"横割り"組織に変え、各プロダクトのリーダーに強力な権限を与えて自走性を高める事で、赤字事業部を見事に黒字化させる話だ。

この本で語られているコンセプトを参考に、この指針を考えた。