チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s

依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ

[shunkeen]

“パスの数は、人数に対して指数関数的に増えます”／ₙ𝐶₂は高々二乗であり、多項式ではあっても指数関数的ではないという重箱の隅が気になる。それはともかく、チームトポロジーみたいな話だ。

[otihateten3510]

大作だね。ここら辺自分でも考えてるけど、操作する権限を持ってないのと、結構理屈通り進まないから自分には荷が重く忌避してる。ソフトウェアの設計に似てるけどちょっと違う。

[Guro]

“フルリモートで活動するチームであれば、オフィスで活動するチームより人数を少なくする方が良いのではないかという実感もあります。リモートの方がコミュニケーション効率が悪い印象があるからです。”

[jiro68]

疎結合にしておいた方が同期処理は少なくて済むので処理は進むが、次の同期に失敗すると大きめのロールバックが発生するのでその頻度次第。組織の性格によって向き不向きがありそう。

[acealpha]

プロダクト開発組織編成論としてはそんな違和感はない PMかスクラムマスターかで立場の違いはあれどコミュニケーションパスの明確化とボトルネックの解消をやってると大体この結論になると思うなあ

[alchemy-k]

すごく「開発者」目線 結局は、人と人の信頼関係だとおもってる古いタイプの人間なので。人は、ソフトウェアみたいに指示した通りには動かないよ…

[mng_dog]

前半部分の感想としては、社内外注化するということなのかな。企画者のAさんとYチームの軋轢が深まり、そのツケがプロダクトに回りそうに思う。スケジュールと効率だけを追うなら良さそう。

[chiroruxx]

あとでよむ

[s_ryuuki]

改善とは、知識と経験の積み重ねによる学びによって得られるものです