アジャイルにおけるクロスファンクショナルvs自己組織化vs機能vsコンポーネントチーム

従来、プロジェクトは コンポーネントチーム （UX、開発、ビジネス、テスターなど）を中心に編成されており、さまざまなコンポーネントの専門知識を必要とするリリースには、複数のコンポーネントチームが関与する必要があります。通常、チームごとに優先順位のセットが異なるため、必然的に製品リリースサイクルのボトルネックが発生します。

ウィキペディアによると、部門の枠を超えたチームとは、共通の目標に向かって取り組むさまざまな機能の専門知識を持つ人々のグループです。チームの品質を向上させるための最良の方法の1つは、チームを部門の枠を超えて機能させることです。部門の枠を超えたチームには、アイデアを実用的な製品に変えるために必要なすべてのスキルがあります。

「クロスファンクショナルチームには、チームに属していない他の  チームに依存することなく、作業を遂行するために必要なすべての能力があります」—スクラムガイド

コンポーネントチームのアプローチとは対照的に、 部門の枠を超えたチーム は、会社のさまざまな機能分野の人々で構成されるグループです。—技術スペシャリスト（バックエンド、フロントエンド開発者、QAエンジニアなど）だけでなく、ビジネスアナリスト、マーケティング、UXスペシャリスト、またはプロジェクトに積極的に参加している他のメンバーで構成する必要があります。

自己組織化チーム とは、チーム外の他の人から指示されるのではなく、自分の仕事を遂行するための最善の方法を選択する自律性を備えたチームです。 従来の管理原則とは異なり、自己組織化された権限を与えられたチームは、上から指示および制御されません。むしろ、スクラムのすべてのプラクティスとイベントに積極的かつ集合的に参加しているチームメンバーから進化しています。

従来のチームとアジャイルチーム

「 自己組織化チーム は、労働者が自分自身を管理しなければならない知識のグループで構成されています。彼らは自律性を持たなければなりません」— ピータードラッカー。

スクラムガイドには、「スクラムチームは、プロダクトオーナー、開発チーム、およびスクラムマスターで構成されています。彼らです：

「スクラムチーム は 自己組織化され、部門の枠 を 超えています」— スクラムガイド：

コンポーネントチームと機能チーム

従来のアプローチは、製品を多かれ少なかれ論理的かつ意味のある形でコンポーネントに分解し、コンポーネントチームをそれらに割り当てることです。ただし、これらのコンポーネントは、お客様の視点とはまったく関係がありません。

機能チームアプローチは、テクノロジースタックチームとは対照的に、チームを編成するためのほぼ普遍的に受け入れられている方法です。特に、継続的デリバリーアプローチでは、通常は加速できるユーザーのニーズを解決する機能（つまり、システムの垂直スライス）を強調します。機能や動作するソフトウェアの価値を提供し、実際のユーザーからのフィードバックループを短縮します。機能チームには、仕事を遂行するために必要なタスクレベルの作業を実行するためのすべてのスキルがあります。特に、3層アーキテクチャを想定すると、チームメンバーは、このストーリーのGUI、中間層、およびデータベース部分に関連するタスクに取り組みます。

コンポーネント編成の大きな欠点は明らかです。それは価値の流れを遅くします。システム機能の大部分は、構築、展開、および最終的にリリースするためにコンポーネントチーム間の協力を必要とする依存関係を作成します。チームは、エンドユーザーの価値を提供するのではなく、チーム間の依存関係について話し合い、コンポーネント間の動作をテストすることに多くの時間を費やしています。