#概要
LeSSにおける開発チームの望ましい形として「フィーチャーチーム」が挙げられております。
ではそのフィーチャーチームとは？
従来のコンポーネントチームとの違いとは？
これらの内容について本記事で解説させていただきます。
#コンポーネントチームモデルとは？
フィーチャーチームを説明する上で、まずはコンポーネントチームも合わせて説明しなければならないでしょう。
コンポーネントチームとはアーキテクチャを中心に構成されています。
例えばフロントエンドとバックエンド、JavaとPHP、あるいはモジュール・サブシステム別等、システムまたは技術の一部を専門とするチームを指します。
関連・・・コンウェイの法則
例えばシステムA,B,Cに顧客価値のある機能（ドメイン・サブドメイン）X,Yがあった場合、それぞれのシステムに合わせたA開発チーム,B開発チーム,C開発チームが存在するようなイメージです。
仮に顧客（及びプロダクトオーナー）がシステムA,B,C全てに変更が入る機能Xのバージョンアップ開発を要求した際には、A,B,C開発チームの開発範囲を取りまとめつつ、それぞれの開発スケジュールを合わせる等の調整を行う必要が出てきます。
すでにお気づきかと思いますが、従来の開発チームの多くがこのチーム体制をとなっていることでしょう。
#フィーチャーチームモデルとは？
フィーチャーチームとは顧客価値を中心に構成されており、各チームは、顧客ドメインの1種類以上の機能を専門としています。
例えば顧客管理（機能）、アイテム検索（機能）、スケジュール調整（機能）等、1つあるいは複数の顧客価値のある機能別に構成されています。
例えばシステムA,B,Cに顧客価値のある機能（ドメイン・サブドメイン）X,Yがあった場合、それぞれの顧客価値に合わせたX開発チーム,Y開発チームが存在するようなイメージです。
仮に顧客（及びプロダクトオーナー）がシステムA,B,C全てに変更が入る機能Xのバージョンアップ開発を要求した際には、X開発チームへ当該要求を提示することでX開発チームのみでA,B,Cシステムへの改修を完結させることが可能となります。
#コンポーネントチーム vs フィーチャーチーム
ではここからはそれぞれのチーム形式の対になっている特徴をピックアップし比較してみましょう。
| No. | コンポーネントチーム | フィーチャーチーム |
|---|---|---|
| ① | 明確な「コードと設計」の所有権 | 明確な「機能」の所有権 |
| ② | コンポーネントへの深い専門性 | 顧客価値への深い専門性 |
| ③ | 不均衡で非同期な依存関係 | 依存関係がない |
| ④ | 顧客価値 ＜ アウトプット量 | 顧客価値 ＞ アウトプット量 |
| ⑤ | ウォーターフォールにつながりやすい | アジャイル開発につながりやすい |
| ⑥ | 開発が容易 | 開発が困難 |
| ##コンポーネントチームの特徴 |
コンポーネントチームでは、特定のコンポーネントのみが改修範囲となるため所有権（責任）は当該コンポーネントの「コードと設計」となり顧客価値の一部にのみ所有権を持つことになります。（No.①）
各チーム間は非同期となっているため、それぞれの成果物の統合には各チーム毎の或いはチーム全体の管理者による調整が必要となってきます。（No.③）
これを解決するために複数コンポーネントチームでプロジェクトチームを立ち上げて定例の進捗確認会議による管理等の策を講じ、結果的にシーケンシャルな工程と長いリリースサイクルにつながりやすくなります。（No.⑤）
また特定コンポーネントで用いられている技術や仕様への専門性が高いため、このコンポーネント内での開発における速度や品質は高くなり多くのソースコードのアウトプットが望め、かつ使用技術が固定されることから人事的な調整も容易となる反面、各チーム毎では顧客価値の一部しか実現することができません。（No.②,④,⑥）
##フィーチャーチームの特徴
フィーチャーチームでは、顧客価値に合わせた改修範囲となるため所有権（責任）は顧客価値を実現したもの（機能）となります。（No.①）
フィーチャーチームでは実現したい顧客価値に合わせた所有権を持っているためPOとしては開発チームへ依頼するのみで良くなります。（No.①）
複数チームでこれの実現が必要となる場合は、各チームでクロスチームプランニングを行う等の調整で済みます。（No.②,③）
また複数コンポーネントでの開発が必要となるため（コンポーネントチームに比べて）多くの技術的知識・仕様を把握する必要があり、これにより開発速度及び設計・ソースコードの品質低下に繋がる可能性があり、人事的な調整も困難となるため、これの克服をする必要があります。
結論
上記よりコンポーネントチームとフィーチャーチームのどちらが良いの？と言われれば、顧客中心の観点ではフィーチャーチームとなることが良く、アーキテクチャ中心の観点ではコンポーネントチームとなることが良いと言えるでしょう。
上記の特徴から我々はフィーチャーチームを目指すべきと感じた場合、実際コンポーネント別で違う環境、言語（他進捗管理方法等）であることも多いため、この移行についてはいくつかの課題を解決しなければなりません。
では、これを実現するにはどうすれば良いのでしょうか？
以下の記事で詳しく解説していきます。
[WIP]フィーチャーチームへの移行と調整についての記事作成