#Book
## 4章
### [[🗃️Scrum@Scale]]の特徴
> [[🗃️スクラムマスターサイクル]]」がHowを調整し、「[[🗃️プロダクトオーナーサイクル]]」がWhatを調整します。 「スクラムマスターサイクル」という名前が付けられているので、これらはスクラムマスターの活動を定義しているように感じますがそうではありません。「スクラムマスターサイクル」は、開発者による活動全般を表しています。 ^ref-43628
### スクラムマスターサイクル
#### スクラムチームとSoS
##### [[🗃️スクラムオブスクラムマスター]]
> [[🗃️スクラムオブスクラムマスター]]の役割は主に次のようなものです。
> ● SoSとして開催するイベント全般の開催支援・ファシリテート
> ● SoSとして以下に関する話し合いが確実に行われるようにする
> ● SoS全体として仕事の妨害になるもの（障害物）の共有や除去
> ● SoS全体としてのプロセスの改善
> ● チーム横断的な依存関係の調整
> ● チーフプロダクトオーナーと緊密に連携し、SoSとして統合されたインクリメントを届けることに責任を持つ
> ● SoSそのものの継続的な改善に責任を持つ ^ref-35332
> [[🗃️Scrum@Scale]]の公式ガイドでは、[[🗃️SoS]]を構成する最適なチーム数は4または5チームと定義しています。 ^ref-46606
##### [[🗃️SoS]]は共通の関心事どうしで作る
> 仮に5つの[[🗃️スクラムチーム]]があるとして、この5チームが常に同期を取り続ける必要があるのか──そのような観点で[[🗃️SoS]]を構成します。 ^ref-8372
##### [[🗃️コンウェイの法則]]と[[🗃️逆コンウェイ]]作戦
> [[🗃️SoS]]の1つに対してアーキテクチャを構成する1つのモジュール、という関係性として扱うことができます。SoSを構成する各チームの役割分担も、同様に[[🗃️コンウェイの法則]]を意識するとよいでしょう。 ^ref-30634
#### Scrum@Scaleと『[[🗃️チームトポロジー]]』
> [[🗃️Scrum@Scale]]での組織編成を検討する際の手がかりとして、『[[🗃️チームトポロジー]]』 注5 という書籍が良い手がかりになります。 ^ref-50077
#### [[🗃️SoS]]のイベント
##### [[🗃️SDS]]
> 最初に紹介するのは[[🗃️SDS]]（スケールドデイリースクラム）です。第3章では、チームのデイリースクラムの直後に開催していました。 これは、通常の単一スクラムチームによる活動の中に登場する[[🗃️デイリースクラム]]とよく似ています。 ^ref-21301
> 毎日開催していると、参加するメンバーが固定化してしまうことがよくあります。なるべく多様な人が集まることで、議論の場にさまざまな視点がもたらされます。そのため各チームのスクラムマスターは、チームの[[🗃️デイリースクラム]]などでいつもと違う人が[[🗃️SDS]]へ参加するように呼びかけるとよいでしょう。 ^ref-42956
💭これ意外だった。色んな人が参加できるように意図した方がいいのね。
##### [[🗃️スケールドレトロスペクティブ]]
[[🗃️スケールドレトロスペクティブ]]では、SoSの活動全体に焦点が当たるため、参加者が異なります。スケールドレトロスペクティブの参加者は、主に各チームの[[🗃️スクラムマスター]]です。改善活動に興味を持つ開発者が参加してもかまいません。 ^ref-33874
#### [[🗃️EAT|🗃️Executive Action Team]]（EAT）
> 一般的にこのような階層化された官僚的な構造は、大きくなった組織が効率的にコミュニケーションするためによく見られます。Scrum@Scaleでは、こうした官僚機構をなるべく小さく保つように工夫されています。これを「[[🗃️実用最小限の官僚機構]]」と呼びます。 ^ref-38461
> [[🗃️Scrum@Scale]]では、この「[[🗃️実用最小限の官僚機構]]」の中核として2つのリーダーシップグループを定義しています。1つはスケールされたスクラムによって何を生み出すべきかに焦点を当てる「[[🗃️Executive MetaScrum]]」（EMS）。もう1つはスケールされたスクラムをどのように運用するかに焦点を当てる「[[🗃️EAT|🗃️Executive Action Team]]」（EAT）です。[[🗃️Executive MetaScrum|🗃️EMS]]は[[🗃️プロダクトオーナーサイクル]]の中心を担い、[[🗃️EAT]]は[[🗃️スクラムマスターサイクル]]の中心を担います。 ^ref-20537
##### [[🗃️EAT]]の役割
> Executive Action Teamの略称である「EAT」は障害物を最後に食べてしまう（eat）という意味を込めて「イー・エー・ティー」ではなく「イート」と発音します。 ^ref-29787
💭これ面白かったので、思わずメモってしまった
> [[🗃️EAT]]は、[[🗃️Scrum@Scale]]の内側で生じる課題のすべてを解決できる機関でなくてはなりません。そのため、問題を解決するために必要なすべての権限を持ち、組織内の非アジャイルな部分とのインタフェースとしての機能も持ちます。 ^ref-10198
> [[🗃️EAT]]は組織全体のプロセス改善に責任を持ち、改善の継続的な取り組みをEAT自身が扱うべきバックログとして管理します。これを[[🗃️変革バックログ]]と呼びます。[[🗃️変革バックログ]]では組織やプロセスの改善、チーム全体に対する標準の作成といったものが扱われます。 ^ref-61157
##### [[🗃️EAT]]に誰が参加するか
> [[🗃️SoS]]や[[🗃️EAT]]で最終的にすべての障害物を取り除ける状態が、最も仕事を早く終わらせられる状態です。課題が[[🗃️Scrum@Scale]]の外側に出ていってしまうと、そこが最大のボトルネックになってしまいます。 ^ref-49082
> [[🗃️EAT]]に参加するメンバーはかなり強い権限を持った人物であることが求められます。どのような人がふさわしいかは扱うプロダクトや会社全体の組織構造によって異なりますが、例としては次のような人です。
> ● 承認を求めずにプロダクトの方針を決定できるリーダー（CEO、CTO）
> ● 予算を握っている人（CFO、財務担当VP）
> ● 組織構造や人員配置に関する決定権を持っている人
> ● セキュリティの専門家や法務
> ● スクラムのプラクティスに関する意思決定ができるアジャイルコーチ（EATのスクラムマスター） ^ref-65255
💭[[🗃️EAT]]は結構強い権限を持った人が集まってくるんだな〜リーダークラスでいいとイメージしていた。
##### [Column]アジャイルプラクティス
> 組織を変革するビジョンの実施や組織内におけるスクラムの品質を維持するため、「[[🗃️アジャイルプラクティス]]」という機関を設けてそこへEATから権限を委譲するアイデアを提唱しています。
> [[🗃️アジャイルプラクティス]]は、EATや組織全体に対する[[🗃️スクラムマスター]]としての役割を担います。スクラムマスターたちの報告先として、スクラムマスターの評価者である上司から独立した立場でスクラムマスターたちのマネジメントを担います。 ^ref-38647
> スクラムマスターの上司であるマネージャーは、必ずしもスクラム実践者として熟達しているわけではありません。このようなマネージャーがスクラムマスターの報告先になると、それによって組織のスクラムが破壊されてしまう恐れがあります。それを防ぐには、経験豊富なスクラムの実践者による独立したレポートラインが必要なのです。 ^ref-52997
💭[[🗃️スクラムマスター]]の報告先。
##### [[🗃️EAT]]のメンバーは外部の[[🗃️ステークホルダー]]のようにならない
> [[🗃️EAT]]が単純な報告の場ではなく、1つの[[🗃️スクラムチーム]]として機能するためには、EAT自体の活動のレトロスペクティブを行うのが効果的です。[[🗃️レトロスペクティブ]]の場で[[🗃️チームビルディング]]のようなことをしてみるのもよいでしょう。こうして各メンバーの関わり方を整えます。そしてレトロスペクティブを通じて、チームとしてのEAT自体の活動や、意思決定のプロセスの継続的な改善活動を行います。 ^ref-52360
##### [[🗃️EAT]]だけで人の配置を決定できるようにする
> 人の異動はただでさえコストのかかる仕事です。それを毎回Scrum@Scaleの外側にいる、人事権を持っている人に依頼をしなければならないとしたら、相当骨が折れてしまいます。EATは、Scrum@Scaleの組織にとって必要な仕事がすべてその内側で完結するために存在する機関なのです。 ^ref-54625
### [[🗃️プロダクトオーナーサイクル]]
#### なぜプロダクトオーナーは開発チームから独立してスケールするのか
> 開発者が日々インクリメントを作る作業をしている間、[[🗃️プロダクトオーナー]]はプロダクトの価値を高めるための活動に注力しています。 ステークホルダーと会話をしたり、スプリントレビューで得られたフィードバックを分析したりします。時にはユーザーインタビューや、プロダクトが取り巻く市場の調査など、チームの外側に目を向ける仕事も多いです。これは、プロダクトオーナーの日々の活動が開発者やスクラムマスターとはまったく異なった動きをしていることを意味します。 ^ref-10868
> プロダクトオーナーには開発者やスクラムマスターとは異なった形でのスケーリングが必要です。 これが、Scrum@Scaleがスクラムマスターサイクルとプロダクトオーナーサイクルを2つに分けて定義している理由です。 ^ref-54429
#### チーフプロダクトオーナーとメタスクラム
> このチームで、組織全体で一貫性を持ったプロダクトバックログを作ります。そしてチームごとにプロダクトバックログをブレークダウンして供給します。そうすることで、チームが個別のプロダクトバックログを持ちながら、組織全体においても方針がバラバラにならず、一貫した方向性を示し続けることができます。このようなプロダクトオーナーによるチームを「[[🗃️メタスクラム]]」と呼びます。 ^ref-37296
> [[🗃️メタスクラム]]は、プロダクトに関する方向性を決定する場となります。したがって複数の方針決定者が横並びで決定権を持った状態で活動することはあまり好ましい状態ではありません。意見が割れた場合などに、最終的な決定権を持った人が必要です。このメタスクラムには、チーフプロダクトオーナーという最終的な意思決定者を置きます。 ^ref-1996
> 優れた[[🗃️メタスクラム]]は、プロダクト間のすべての意思決定の場となります。プロダクトの意思決定に発言権を持つ人は全員、この会議に招待されるべきです。メタスクラムは定期的に開催され、どこで、どのようなプロダクトに関する決定を行うかを全員が知ることができます。 ^ref-7445