4.1.4　ガイド：顧客ドメインでの専門化を優先

技術による専門化と顧客による専門化の最適なバランスとは、何でしょうか？難しい決断です。 LeSS を導入する場合、顧客ドメインでの専門化を優先します。

フィーチャーチームの背後にあるコンセプトの 1 つ「技術ドメインではなく、顧客ドメインを専門とする組織を作ること」

これは他の LeSS の組織構造を考える際にもガイドとなる

専門化は多面的である

フィーチャーチームに対するよくある誤解「専門化を完全に放棄することに繋がる」

1 つのコンポーネントに完全に特化するか、全く特化しないか、という誤った二分法から来る

専門化がコンポーネントに限定したものだという一次元的な考えにも起因する

専門化の側面

機能スキルやコンポーネント

技術（コンポーネント、 OS など）

顧客志向（市場、機能の種類など）

https://scrapbox.io/files/649a9469622adc001b16d9ff.jpg

フィーチャーチームは、顧客価値によって組織を構成する 1 つの方法であり、唯一の方法ではない

筆者は技術ではなく、顧客ドメインでの専門化を推奨する

実在のユーザーとのコラボレーションを高め、受け渡しのムダを取り除き、作業をより意味のあるものにするため

技術視点で専門化する例1: モバイルアプリを作成する場合、 iOS チームや Android チームなどのプラットフォームによって組織する

これらのチームはフィーチャーチームであり、技術面（プラットフォーム）に特化している

LeSS で推奨する組織はモバイル決済、アドミン、レポートなどの顧客ドメインによって組織する形

ただしその場合はチームは複数の異なる機能を 1 つのプラットフォームに実装するのではなく、同一の機能を複数のプラットフォームに実装することになる

技術視点で専門化する例2: グラフィックスカードを作る会社

(1) ハードウェアチーム, (2) Linux ドライバーチーム, (3) Windows ドライバーチーム に分かれているコンポーネントチームだった

この構成からフィーチャーチームへ移行するには、ハードウェア/ソフトウェアのクロスファンクショナルチームが必要となる

多くのハードウェア企業では文化的理由により移行が簡単ではない

この場合 LeSS で推奨する組織は (1) 2D グラフィックスチップチーム (2) 3D グラフィックチップチーム という分け方