_image_for_a_webpage_themed_around_Feature_Teams_in_Agile_project_management._The_image_should_include_symbo/w=3840,quality=90,fit=scale-down)
🤔 この用語について
Feature(機能)に責任を持つTeamsのこと。
コンポーネントチーム ではアーキテクチャ（バックエンドやフロントエンド、iOS、デザイン、データ分析など）ごとにチーム化していたのに比べると、Feature Teamsは、機能に責任を持つため機能に必要なコンポーネント全ての変更をチーム内で完結させる。そのためEngineerやDesignerはもちろん必要によってはAnalystなどもFeature Teamに所属している。
一つのFeature Teamが一つのプロダクトに責任を持つかというとそうではない。
プロダクトや組織が小さいうちは一つのTeamかもしれませんが、一つのTeamは7人前後が適正値となる。
そのためプロダクトをスケールさせていく中で人の増加に伴い、複数のFeature Teamを作ることになると思います。これに関しては、LeSS Framework に書かれている為省略
つまり通常のスクラムを拡張して一つのプロダクトバックログを複数のTeamで向き合っていく事となる
Atama+が2022年10月時点で公開したスライドで、LeSSに関して書かれています。
では一つのプロダクトでは、ずっと一つのプロダクトバックログで、それを増え続けるFeature Teamで向き合うかというとそうではない方法もあります。
上記PDFにはより詳しく書かれていますが、集中して解決し続けたい領域がある場合、その機能を独立していくことは可能。
例えば「本の売り買いサービス」があるとした場合、雑に考えると「本を売る」側の機能と、「本を買う」側の機能があると思います。ユーザ増加に伴い「本を売る」「本を買う」体験をそれぞれで目標をもって向き合いたいとなった場合は、それぞれでグループ化（PDF内ではエリア化）を行い、グループは専用のProduct Backlogを持ち、グループ内のFeature Teamsで向き合っていく形に変わっていくと書かれている。
PDFの中ではPerformaceとProtocolsでエリアを分けるという説明になっています。
これはプロダクトの特性によると思うので、どうしたいかを考える必要がありますが、ユーザが触る機能と、裏側でAI商品審査がなんかする機能みたいに、分けるのも一つですね。
ただ分ける際に大切なことは、機能開発を通して顧客の課題を解決する際に異なるTeamに依存せず解決出来ることが必要。AI商品審査とユーザが触る機能の両方に手を入れる必要がある場合などは、Teamの分け方としてはアンチかもしれない。あくまで審査は精度の話や、破壊的な変更をせず呼び出し元でversionを使い分けていけるとかならありかもしれないなど