「職能横断チーム」の実践におけるアンチパターンと対策 - yigarashiのブログ

近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも

[yigarashi]

自分のチームや周囲で目にしたアンチパターンについてまとめました

[sh19910711]

"サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態 / ソフトウェアで言えばmain関数に全ての処理を書いている状態"

[udzura]

“リモート化によって会が有効に機能する人数の上限が下がっている印象”

[yoppe9509]

“リモート化によって会が有効に機能する人数の上限が下がっている印象があり、このアンチパターンの被害は拡大していると感じます。僕の同僚も「雪見だいふく2袋ルール」（つまり4人）というのを提唱していて”

[haneuma0628]

これじゃん

[mizdra]

チームが大きくなった時に「いつも全員一緒」というアンチパターンから抜け出すために意識するべきことについて。極端であることを認識する、大本の目的に立ち戻って考えるの大事ですよね。良い記事。

[juve534]

"「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態" あるある。極端に振りすぎないようにしないといけない。

[sonots]

悪化するまで放置するとどうなるのか参考になる

[koogawa]

“「いつも全員一緒」はソフトウェアで言えばmain関数に全ての処理を書いている状態で、もっとチームやコミュニケーションの構造を掘り下げる余地があると思います”