下林明正のブログ

個人的かつ雑多なブログです。

ソフトウェア開発チームの分割について考えてみる

必要にかられているので考えてみる。 個人の記憶・憶測で構成されているのでデタラメかも知れません。

なぜ、チームを分割する必要があるのか

なぜ人員を増やしていくのかというと、同時並行してやりたいことが増えているから。 そもそも、やりたいことを絞れていれば人員を増やす必要もないはずだし、その方が望ましいと思われる。が、現実には人員は増えていく。

しかし、人員が増えれば増えるほどコミュニケーションパスは指数関数的に増えていくので、コミュニケーションコストが増大していきどこかで人員が増えることによるリソースよりもコミュニケーションコストで消費されるリソースの方が大きくなり、スケールしなくなる。

なので、コミュニケーションコストを下げるためにどこかでチームを分割する必要がある。 関心を分離するためにチームを分割する必要がある、という言い方もできるかも知れない。 別にこれはソフトウェア開発チームに限った話では無いと思う。

このあたりの話はエンジニアリング組織論への招待に書いてあったような覚えがある。

コミュニケーションコストは小さい方が良い

ということは、例えばスタートレックのボーグのようにコミュニケーションコストが0に近いとすると、1チームあたりの人数はかなり多くても問題にならないと思われる。

デモグラフィー型のダイバーシティは生産性が低いといった話があったと思うけど、コミュニケーションコストが高いからという一面もあるのかも知れない。

そういう意味ではモノカルチャーの方がコミュニケーションコストは低くできそうだが、別の面では脆弱かも知れない。

どこまで分割する必要があるのか

2枚のピザルールというものがあるので、それを参考にすると良さそうに思う。具体的に何人までなのかは良く分からないけど、上限は大体8~10人程度とされているように見える。

また、スクラムガイドを見ると3~8人が推奨されているようだ。

ということから、多くても両手で数えられるほどの規模感が望ましいと思われる。 ただ、これらの数値は経験的なものなので、今後何らかの要因によってコミュニケーションコストが劇的に削減されるとまた変わってくる可能性は高そうだ(人類がボーグに取り込まれるとか)。

どうやって分割するのか

多分ここが一番むずかしい。

逆コンウェイ戦略

こういうときに意識するべきキーワードとして、逆コンウェイ戦略がある。

内容はググってくれという感じなんだけど、望ましいアーキテクチャの境界で分けようという話だと理解している。 ここで望ましくない境界で分けられていると、外部との取引コストよりも内部での取引コストが低いので本来外部にあるべきものが内部に引き込まれたりして、おかしなアーキテクチャに変形していく(ということがコンウェイの法則だと理解している)。

なので、ここは実はアーキテクトの仕事でもあると思う。もちろん実際はそれだけでチームを決められないので、いろんな職種のメンバーで考えることになるはずだけど。

どこかで見た表現では、SaaSのような関係性が望ましい、というのがあった気がする。たしかに、コミュニケーションコストを削減するという目的ではしっくりくる印象。 ただ、SaaSのような関係性ってなんだよって感じはあって、完全にドライな関係から積極的にフィードバックやPRを送り合うような比較的ウェットな関係まで色々グラデーションはありそう。だけど、完全にドライな関係だとしたら本当にSaaSとしてお互い独立したら良いはずなので、ここでは比較的ウェットな関係が丁度いい落とし所なのではないかと思われる。

フィーチャーチーム

ただ、この考え方はもう一つの意識するべきキーワードであるところのフィーチャーチームと若干衝突するように感じる。 ある機能を実装する際に境界の向こうにも改修が必要となったときに(例えば継続課金をしたくなったが課金システムにそうした機能がない場合とか?)、それがフィーチャーチームとして成立していると言えるのかいまいちピンとこない。 ただ、それを言い始めると専用ハードウェアの開発が必要になったらどうするのかとか、結局全人類が一つのチームなんや!とかそういう感じになりそうな気もしてくる。

フィーチャーチームの目的もコミュニケーションコストを削減することで高い成果を出すことだったような気がするので、結局、望ましいアーキテクチャを実現するにあたってどことどこのコミュニケーションコストを最小化するべきなのか、というまとめ方がいいのかも知れない。 アーキテクチャ自体も自明なものではなく経験主義的に発展させていくものであるはずなので、チームの境界もそうであっていいはず。

「境界」というとなにかベルリンの壁のような絶対に超えてはいけないものといった印象を受けてしまうけど、ここでいう「境界」はどちらかといえば(DevOpsハンドブックにあったような)ブイを設置するイメージで捉えたほうが良さそうだ。つまり、必要があればブイは超えることができるし、動かすこともできる。

別解: 大規模スクラム

実はアーキテクチャの境界で分けない方法もあって、それがLeSSとかScrum@Scaleといった大規模スクラムだと理解している(大規模スクラムといっても色々あるし、きちんと実践したことがあるわけでもないので、もしかしたら間違っているかも知れない)。

このあたりの使い分けは正直良くわかってない。何事も程度問題なので、アーキテクチャの境界でうまく分けられそうだったらそうしたらいいし、そうでなかったら別の切り口で考えたら良いということかも知れない。

参考になりそうな情報

diamond.jp

ma2k8.hateblo.jp

qiita.com

zenn.dev

まあチームトポロジーせっかく和訳されたんだし読めよという感じがしてきた。読めてないです。