4.1.5 ガイド：LeSS の組織構造
LeSS の組織と、従来の組織との異なる点
チームを中心に仕事が構成されること
スキルの不一致が既存のチーム内の学習と調整をもたらすため、構造が安定していること
典型的な LeSS の組織図に「ない」組織
https://scrapbox.io/files/649b83dace6444001b3a78f2.png
機能別組織はありません
LeSS では機能別組織を廃止し、かわりにクロスファンクショナルなライン組織をつくることによって、忠誠心の競合を回避する
e.g. プログラミングスキルをもつメンバーが開発マネージャーに報告し、テストのスキルをもつメンバーが QA マネージャーに報告する組織
QA の担当者が実際に作業を行うチームと QA マネージャーの双方に対して同等の忠誠心を持つことが難しい
プロジェクト/プログラムの組織やプロジェクト/プログラムマネジメントオフィス（PMO）を避ける
これらの従来の管理組織は、責任をフィーチャーチームとプロダクトオーナーで分散して受け持つため、 LeSS の組織には存在しない
従来の管理組織を維持しようとすると、混乱と責任の対立が起きる
構成管理、継続的インテグレーション支援、「品質とプロセス」などの支援グループはありません
LeSS の組織では、専門化したグループによる複雑な組織をつくるより、既存のチームに任せるように責任を拡大することを優先する
専門化した支援グループは自分の領域を守るようになりがちで、ボトルネックに繋がる
典型的な LeSS の組織に「ある」もの
https://scrapbox.io/files/649b83dace6444001b3a78f2.png
プロダクトグループ長
プロダクトグループ長 = すべてのチームのラインマネージャーのこと（組織によってかなり異なる用語が使われている）
現地現物 でチームをサポートし、障害を取り除き、改善するのを助ける人
LeSS の組織にマトリックス構造はなく、直属の上司以外のマネージャーは存在しません（参考: 5 マネジメント） フィーチャーチーム
開発作業が行われるチームのこと
各チームにはスクラムマスターがおり、クロスファンクショナルで自己管理している
チームは、プロダクトの期間中（そして時にはより長く）一緒にいる永続的な単位である
全てのメンバーは、直属のマネージャーとしてプロダクトグループ長をもつことが好ましい
筆者はほとんどの管理がチームに引き継がれ、直属のマネージャーが全て同一人物である 150 人の組織を観測している
一部の大規模な LeSS 組織にはラインマネージャーのチームが作られたりするが、可能であれば組織の複雑さは回避したほうが良い
プロダクトオーナー（チーム）
プロダクトマネジメントをする人
1 人でも構わないが、より大きな LESS 組織ではプロダクトオーナーが他のプロダクトマネージャーによってサポートされる場合もある
重要なポイント: チームとプロダクトオーナーが対等であり、階層関係がないこと
チームとプロダクトオーナーは可能な限り最良のプロダクトを構築するために協力的で対等な関係をもつべき（参考: 8 プロダクトオーナー） 対等な構造がこれをサポートしている
プロダクトオーナーが異なる組織（ビジネス側）に属しており、プロダクトグループ長の権限下に属していないことがある
推奨されることではある
Undone 部門
理想的には、この部門は存在しないほうがよい
チームがまだスプリントごとに本当に出荷可能なインクリメントを作成できないことがある
「出荷可能」と「Done の定義」が不一致であるため
これらの差分は Undone ワーク と呼ばれる
一般的な「解決策」は「Undone ワーク」の対応をする別のグループをつくること。このグループが Undone 部門
小さな Less フレームワークのグループではテスト、 QA 、アーキテクチャ、ビジネス分析グループなどの Undone 部門は、最初からチームに統合されているべき
LeSS 導入の目標は Undone 部門をなくすこと