LeSSでも以外でも使える話！！『スクラムの拡張による組織づくり #だいすくらむ本』を読んで
私は、一度LeSS でスクラムを拡張した経験があり、再び全体最適な開発を LeSS に求めて再導入を目論んでいる組織にいます（このあたりの詳細は、9/16にスクラムフェス三河でお話しさせていただきます【10/5加筆】発表資料のリンクを末尾に添付しておきます）。
「一度LeSS でスクラムを拡張した経験があり」までの経緯は👇こちらで
と、今まさに「スクラムの拡張」に向き合っているという背景もあって、『だいすくらむ本』に関心があり過ぎて、予約購入して拝読しました！
で、まず、だいくしーさんに御礼を述べさせていただきます。
この本を出していただいて、ホントありがとうございます！！
情報が少ない「スクラムの拡張」に関する最新情報をまとめていただけて、感激しています！しかも訳本じゃなく、タイムラグもなくて最高ですw
そんな歓びを全身で感じまがら読み進めたなかで、章ごとに「学び・共感」と「疑問」を書き残すことを試みました。
頭から読んでいく途中で浮かんだ疑問が、後の章で解消されたケースもありますが、敢えてそれらも消さず、書き留めています。
結構なボリュームになったので自分のためにも目次を置いておきます。
第1章 スクラムのスケーリングと大規模の難しさ
学び・共感
スクラムをスケールしない方法を考える
まずは1つのチームを維持したままうまくやる方法は本当にないのか、というのをギリギリまで考え抜いてください
👆この本のハイライトはこの一文じゃないか？とすら思える。
疎結合なスケールを考える
チームが複数あったとしても、それらが常に同期的にコミュニケーションをする必要がなければ、大きなコストにはなりません。LeSS / Nexus / SAFe / Scrum@Scale を横並びで比較してくれている日本の書籍は初では？シンプルにめちゃくちゃ有り難い！！
この中で Scrum@Scale のサブタイトルに『プロダクトオーナーをスケールする』と書いてあり、「そういう概念で捉えればいいんだー」と率直に思いました。以降を読み進めて理解したい。
Retty に LeSS を導入した常松さんからも1章への高評価が…
本書は書籍の最初の1章できちんと落とし穴を説明してくれています。最終的にScrum@Scaleを採用するかどうかに関わらず、スクラムのスケーリングを考えている方にはこの1章を読むだけで価値があります。
疑問（→後日、解消済み）
Nexus ガイドから「1つのプロダクトバックログ」で完結すると読み取れておらず、チーム毎にプロダクトバックログを持つものと考えていた。【10/5加筆】Nexus も「1つのプロダクトバックログ」でした。Nexusガイドに明記されているのを再確認👇。お騒がせしました！🙇
Nexus とすべてのスクラムチームに対して、プロダクトの改善に必要なリストを含むプロダクト バックログはただ 1 つだけ存在する。
第2章 スクラムのおさらい
学び・共感
不確実性コーンを使って「経験主義」を説明
アジャイルじゃない文化圏や、従来型のプロジェクトに当てはめがちな人への説明は、自分もこのような話をする。
スクラムチームの適正人数に関する変遷や出典
各所で言ってることが微妙に違うなとは思っていたが、原典を押さえての比較はできていなかったので、背景情報がとても有り難い！
第3章 とあるチームの Scrum@Scale での1スプリント
学び・共感
SoSは関心事の近いスクラムチームが集まる1つのスクラムチーム
SoS（Scrum of Scrums）をこう説明してもらったことで、なんかスッと入ってきて分かりやすかった。
フレームワークの類は構造の説明からが多くなりがちだが、目的や効能から理解を図っているところが素敵。
チーフプロダクトオーナーの活動とメタスクラム
全体を統括して見渡すのが「チーフプロダクトオーナー」で、どこかのチームのプロダクトオーナーが兼任でできるということ。
各チームのプロダクトオーナーなどが集まってプロダクト全体の意志決定をする「メタスクラム」、更にメタスクラムの代表者が集まる最上位の意志決定機関「EMS（Executive MetaScrum）」がある。
最上位のチーフプロダクトオーナーは CEO のような人がやる。
Scrum@Scale で扱われるメタスクラムは、メタスクラムパターンから派生した考え方です。【後で読む】
疑問
スクラムマスター（SM）は、1つの SoS に最低1人必要なのか？
DS → SDS → EAT の流れをみてそう感じた。
その後、第4章で「スクラムオブスクラムマスター」として定義が登場。必須の役割として認識合ってそう。
EAT や SDS で揉めたら、誰が裁定するんだろう？
DS → SDS → EAT の流れは開発者とSMが中心の営みのようだが、PO 不在で決められる問題ばかりに収まるものだろうか？
上位機関である EAT の判断が優先さるという理解でよいか？
EMS と EAT の二つのサイクルで矛盾した判断がされたりしないか？
後段を読むとかなり役割分担はされているようだが・・こちらも裁定方法が気になる。「EMSのほうが上位」とかあるのだろうか？？
メタスクラムの後に、関係するチーム間でのリファインメント（LeSS でいうところの「複数チームPBLリファインメント」）が必要そう。
そのへんは自律的に開催してくださいってこと？？
「スケールされたスプリントレビュー」も同様に、必要なときは臨機応変に開催する？ｌｌ
第4章 スクラムマスターサイクルとプロダクトオーナーサイクル
学び・共感
スクラムオブスクラムマスターは、障害物の除去を支援するために必要な知識を持つ人でなければなりません。たとえば、社内の政治的な構造を理解していたり、課題解決に必要な社内の権限を持つ人を知っていたりする必要があります。
（自分もそうで）EMや類する経験をしている人は向いていると思う。スクラムマスターの仕事を突き詰めていけば、次第に組織のより広範囲へのアプローチが必要になると考えられるので、頷ける。
SoSは共通の関心事どうしで作る
Scrum@Scaleと『チームトポロジー』
この二つは似たことを言っていて大いに賛同する。このあたりは三河で発表するメインテーマと合致するので、そちらで整理を試みたい。
図4.10 でチームトポロジーの名称に置き換えてくださっているのは、分かりやすくてよかった。
SDS - 参加するメンバーが固定化してしまうことがよくあります
LeSS の Overall Retrospective、Multi-Team PBL Refinement 、Sprint Planning 1 あたりでも起きがちな問題。激しくヘッドバンギング。
LeSS の Overall 系イベントはスプリントに1回以下の開催になるが、Scrum@Scale だと、毎日障害や依存関係を話す機会（SDS）があり、スピーディに問題解決できる仕組みになっていると感じた。
ゆのんさんのポストにヘッドバンギング【10/11追記】他方、LeSS は「ただ話す」などで随時調整を進めることを期待していて、むしろ SDS のようなイベントを「待ってしまう」ことを避けたいという思想に基づいている。これら2つの考え方の違いは、まさに「誰もが正しい・・・ただし部分的に」といったところ。いずれにせよ我々は、背景思想を理解して使うべきだろう。
図4.11 イベントカレンダーの例
水曜午後始まり〜水曜午前終わりのスプリントは、わかりみが深い。
EAT（Executive Action Team）、変革バックログ
障害物を最後に食べてしまうという意味を込めて「イート」と発音するとのこと。ほほぅ。
人ではなくチームの組み合わせを変えていく
チームをできるだけ長期安定させて、コミュニケーションの相手や濃淡を変化させるイメージで、かつ、コミュニケーション時は問題の当事者が代表者として参加するかたちをとる。
「人を直接動かさずに組織構造を変更」できるといいよね、という考え方に親しみを感じられた。
スクラムチームには、プロダクトバックログリファインメントという場があります。（中略）この場では、開発者はプロダクトオーナーが What を考える支援をしたり、プロダクトオーナーが開発者の考える How の話を聞いたりします。
POと開発者とが相互補完すべきと示しているところは LeSS も同様。
図4.15 仕事の流れ
参考になる。とても分かりやすい図で感謝。
疑問
開発者たちの活動を「スクラムマスターサイクル」と呼ぶ
スクラムマスターはプロダクトオーナーの支援者でもあるという前提で考えると、かなり違和感があった。
著者のだいくしーさんも直後に注釈を添えているが・・なぜこんな誤解を招く名前にしたんだろう？？（Scrum@Scaleのガイドを初めて見た時から変わらない違和感）
スクラムオブスクラムマスターの役割に「SoSとして統合されたインクリメントを届けることに責任を持つ」とあるのは too much ではないか？（かなり大きな違和感ポイント）
SoSを構成する最適なチーム数は、4または5チームと定義しています。
フラクタル構造で増殖するのが自己組織として良さそうなイメージは分かるが、チーム数を合わせに行く意識が働きそうで・・ここも誤解を招きそうに思った。
直後に「SoSは共通の関心事どうしで作る」「Scrum@Scaleとチームトポロジー」などを添えて火消しをしてくれているように見えるが・・
スケールドレトロスペクティブの参加者は、主にスクラムマスター
「スクラムマスターサイクル」の違和感がここにも現れる。チームの代表者としてスクラムマスターが役割を持つこと自体、かなりの悪手をやってしまっているように感じられ、自己管理に逆行しそうに思える（参考：おーのAさんの『ラスボスゾンビのチェックリスト』）。
図4.11 イベントカレンダーの例
（この例だと水曜午後の）「スケールされたスプリントレビュー」「スケールドレトロスペクティブ」「スケールされたスプリントプランニング」の間、参加しないチームメンバーが手待ちにならないか？
EATに参加するメンバーはかなり強い権限を持ったメンバーであることが求められます。（略）EATは、Scrum@Scale の組織にとって必要な仕事がすべてその内側で完結するために存在する機関なのです。
容易には運営が回らなそう。
EMS も同様。「できる限りスプリントごとに1回は開催しましょう」と書いてある時点で、難しさが滲み出ているように思われる。
▶ 7章でみると Chatwork では上手く回せてるっぽい！凄い。秘訣とかあるのだろうか？？
スケールされたスプリントレビューは、チーフプロダクトオーナーが率いるメタスクラムがファシリテートします。
開発者が参加して直接フィードバックを得たほうがよさそうだが？？
スケールされたスプリントプランニングは、メタスクラムとスクラムマスターが行います
おお、また急にスクラムマスターが登場した！？？？プランニングにスクラムマスターが介入するという点で大いなる違和感。
第5章 Scrum@Scaleを形成する12のコンポーネント
学び・共感
それぞれのスクラムチームが未成熟な状態でスケールしてしまうと、組織全体が未成熟なまま大きくなってしまいます。
同様のことを常松さんも書いてたし、ほんとそうだと思います。
チームプロセスのゴール
スクラムチームの成熟をみる指標の例として参考になる。しかしこれができてるチームって・・・
Scrum@Scaleでの守破離の「破」
あるチームはスクラムじゃなくても、ある SoS の中は LeSS のようでも・・ナルホド・・S@Sのガワを被せたハイブリッドシステムたしかにアリな気も・・ちゃんと本質をみて考えてみたい！
SoS などによって組み合わせたチーム編成は未来永劫同じ状態を保つわけではありません。
これかなり大事。“プロダクトの変化や開発フェーズの進展によってチーム間の依存関係は変化していく”前提で、コミュニケーションの密度を変化させていけるよう、先取りして考えておかないと！
組織全体で一貫したデリバリのプロセスを保つために、デリバリの責任はSoSが保つべき
自動化のしくみを個別のチーム毎に独自に用意してしまうと、組織を再編する場合のボトルネックになります。
中長期のサステナブルな観点を言語化してもらえた感。有り難し。
Scrum@Scale の組織全体の方向性を定める、単一のビジョンがある
Scrum@Scale を構成するそれぞれのスクラムチームは、上記ビジョンを共有する独自のプロダクトゴールを定めて、プロダクトバックログを管理する
メタスクラムが作るプロダクトバックログは、各チーム単位にブレークダウンし、チームが持つプロダクトバックログになります。
スクラムチーム毎にプロダクトゴール・プロダクトバックログを分割し、更新していく「プロダクトオーナーサイクル」を、 EMS が中心になって回していくということを理解した。
LeSS の思想と真逆と言ってよいだろうが、Scrum@Scale がそもそも階層構造を予定して自ら官僚機構と呼ぶ運用の仕組みを確立しているところは、複数の LeSS を並べて運用するかたちを模索している我々にとって貴重なリファレンスになる。
第6章
学び・共感
状況によっては Scrum@Scale よりも、複数のチームで1つのプロダクトバックログを共有する LeSS などが適切な場合もあります。
全面的に Scrum@Scale を担いだ本かと思っていたが、だいくしーさんフラットで柔軟で素敵だ。
そしてまた「ハイブリッドシステム」を模索するモチベが高まった w
必要最小限のコミュニケーションと官僚機構を実現
Scrum@Scale に限った考え方ではなく、最小限という観点では LeSS のほうがより小さいと言えそうだが、比較論はともかく、大切なポリシーだと思う。
また、依存関係をマッピングした図などを作成し、スケールドレトロスペクティブの場などを利用して、定期的にメンテナンスしていくのも有効です。依存関係を表現する図から、お互いの情報の行き来を表す線が少しずつ消え始めるのは、チームの自律性が高まっている証拠です。
LGTM。チームの依存関係を可視化して、定期的に最新化していくことで、関係者（特にマネジメント層）の目線を揃えることができるし、多くの示唆も得られることが想像できる。
CSP-SM研修で手ほどきを受けた systemic modeling (of organizations) が使えるイメージ。
12のコンポーネントと変革のバックログ - 自己採点のあとは、自分たちの組織にとってどのコンポーネントが重要であるかの優先順位を付けます。
DX Criteria を試したときに似た議論をしたなと思い出した。自分たちの組織にとって何が重要かを見極め、合意して使うことが超重要。
コラム - EAT を一番初めに導入するパターン
「すでにある程度大きな組織があり、その組織構造との衝突を抑えながらトップダウンに導入していく手順」👈書いた時点で素晴らしい！至るところであり得る！
疑問
5チーム以上ある場合は、最初から複数のSoSを立ち上げる必要があり、難度が高くなります。
全チームを一気に SoS に入れる以外の進め方もあるのでは？？
EATのメンバーは Scrum@Scale のチームに対するステークホルダーではなく、スクラムチームの一員であることを繰り返し確認します。
具体的にどうやって？？（簡単ではないと思うので気になる）
第7章
学び・共感
組織の継続的な改善が柔軟に行えるのが、Scrum@Scale を選ぶことになった理由の一つ
そもそも、だいくしーさんの組織ならフレームワークはなんでも良さそうにすら思えてきているが、ここまで読んで思い当たることは、スケールさせるための要素（コンポーネント）ひとつひとつが細かく定義されていることが、当てはめる側として感じるフレームワークの良さと言えるかもしれない。
1人のプロダクトオーナーが新システムと現行システムの両方を担当するのは、負担が大きすぎる ＋ 図7.1 本書執筆時点の組織構造
こういうリアル情報、ありがたいッス。
EAT には（中略）CTO。開発組織に対して責任を持っている人事担当者。チームが所属している事業部の本部長と副本部長。こうした、課題に対する意志決定を直接行える権限と役割を持った人が参加しています。
これだけの参加者を揃えられたら EAT として機能しそう。
アジャイルプラクティスと呼んでいる機関
“「アジャイルプラクティス」は会社全体に対して活動” 👈面白い！
いま自分がやっている役割と似てる・・。こんな感じで役割が明確だと、やりがいのテンションといい意味のプレッシャーが高まりそう。あーでも、役割を明示することで「依存される」リスクはあるな・・
SDS で具体的にどういう内容が話し合われたのかの例
スケールドレトロスペクティブで具体的に話し合われた内容の例
EAT のスプリントごとのミーティングで主に話し合われている内容
こういうリアル情報、ありがたいッス。（何度でも言います）
プロダクトオーナーサイクルとしてのイベント
プロダクトオーナーやプランナーのスキルアップが自然に図れそう。
1週間のカレンダーまとめ ＋ 図7.2 Scrum@Scale 組織全体のカレンダー
こういうリアル情報、ありがたいッス。（はい、何度でも言います）
SoS の再編
コミュニケーション頻度が SoS のレトロスペクティブの論点に上がって再編に至っている流れが、もはや自己管理な組織で、素晴らしい。
EMSからEATへ
EMS、EAT、それぞれの役割をふりかえって再編している点も良き。
各コンポーネントの役割定義が明瞭であることの好影響だろうか。
疑問
1人のプロダクトオーナーが新システムと現行システムの両方を担当するのは、負担が大きすぎる
頷ける気がするものの、リプレース後に退役する現行システムのプロダクトオーナーのモチベーションはどうなんだ？的なことが気になった（現地現物を見ずにはなんとも言えないが）。
複数のプロダクトオーナーが組織的に並び立つことができるのも Scrum@Scale の魅力
一瞬、LeSS や Nexus を複数並べるかたちでも実現できるのでは？？と疑義がよぎったが、ここで言いたいことは「複数のスケールドスクラムを束ねる構造をフレームワーク内に持っていて、フレームワーク内でやりきれる」ことの価値の高さかもしれない。
1週間のカレンダーまとめ（図7.2 Scrum@Scale 組織全体のカレンダー）
（ある時期のスナップショットとのことだが）見た感じ、複数チームのイベントが極力被らないように依頼してたりするのかな？？
全体を通して
「いまある開発組織のパフォーマンスをどう最適化していくか？」観点でスクラムのスケールを考え、整理し、共有してくださっていて、今まさに似たことを考えている私にとって貴重な参考情報が満載でした！
我々が計画している LeSS の段階的な導入と共に、周辺のチームや組織とどう連携するかのプラクティスとして、エッセンスを採り入れられるとよいかもしれないと考えています。
さいごに読まなきゃメモ。Scaling Done Right: How to Achieve Business Agility with Scrum@Scale and Make the Competition Irrelevant
そして、今回だいくしーさんが成し遂げられたように、自分もこれから実践したことをできるかぎり共有していければと思いました。
（9/16のスクラムフェス三河で途中経過をお伝えさせていただきます）
【10/5加筆】おかげさまで発表させていただきましたので、資料を添付させていただきます。そして、今後もちょくちょく経過の共有をイベントや note などでさせていただければと思ってます！
経過の共有をイベントや note などでさせていただければと思ってます！