あらすじ
【チームの増加により発生するコミュニケーションコスト。その爆発的増大にいかに立ち向かうか】
スクラムは、今や数多くの現場で活用されています。しかし、スクラムは少人数での開発を想定しており、大規模開発で実践する際にさまざまな問題が発生します。そこで、大規模開発でスクラムを行うための手法がいくつか提唱されています。本書はその中の一つであるScrum@Scaleを解説する書籍です。Scrum@Scaleは、スクラム提唱者の一人であるJeff Sutherland博士によって作られました。
本書は、筆者が所属しているチームにScrum@Scaleを実際に導入した知見をもとにしています。Scrum@Scaleをどのように日々の開発に取り入れるのか、導入事例を交えながら具体的に解説します。
■こんな方におすすめ
・規模の大きな組織にスクラムを取り入れたいと考えているマネージャーや経営者
・ソフトウェア開発の組織設計に関わるマネージャーや経営者
・大規模スクラムの実践例を知りたいスクラム実践者
■目次
●第1章：スクラムのスケーリングと大規模の難しさ
スクラムをスケールするとはどういうことか
さまざまなスケーリングスクラムのやり方
大規模スクラムの導入と組織文化
まとめ
●第2章：スクラムのおさらい
スクラムとは
スクラムにおける3つの作成物
スクラムチーム
スクラムにおける5つのイベント
まとめ
●第3章：とあるチームのScrum@Scaleでの1スプリント
チームの紹介
とあるチームのデイリースクラム
さまざまなデイリースクラム
プロダクトオーナーの活動
まとめ
●第4章：スクラムマスターサイクルとプロダクトオーナーサイクル
Scrum@Scaleの特徴
スクラムマスターサイクル
プロダクトオーナーサイクル
まとめ
●第5章：Scrum@Scaleを形成する12のコンポーネント
習熟度を確認するために12のコンポーネントを使う
最初に行うコンポーネント
スクラムマスターサイクルのコンポーネント
プロダクトオーナーサイクルのコンポーネント
共通のコンポーネント
まとめ
●第6章：現場へどのように導入していくか
ステップ0：機能しているスクラムチームを作る
ステップ1：SoSを立ち上げる
ステップ2：メタスクラムを立ち上げる
ステップ3：改善サイクルを回す
まとめ
●第7章：Scrum@Scaleで運用される現場 ──チャットサービスの開発現場の場合
なぜScrum@Scaleを選択したのか
Scrum@Scaleの組織構造とイベントの運用
Scrum@Scaleのイベント
組織構造の変遷
12のコンポーネントの自己採点と変革バックログ
まとめ
■著者プロフィール
粕谷大輔(かすやだいすけ):Chatwork株式会社 エンジニアリングマネージャー。SIer、ソーシャルゲーム開発でのエンジニア業務、サーバー監視ツール開発のディレクターを経て、2021年より現職。Scrum@Scaleを実践しながら開発組織の整備、会社全体のアジャイル化を推進している。
感情タグBEST3
Posted by ブクログ
以前、スクラム開発を採用していたプロジェクトチームの規模（人数）が大きくなってきたとき、Scrum@Scale導入の話が上がってきました。その時に本書を購入。
Scrum@Scaleがどういうものかという説明は当然として、実際の導入事例が紹介されているので、Scrum@Scale導入時にとても参考になりそう。
前提としてスクラム開発のことを知っておく必要がありますが、第2章に「スクラムのおさらい」として簡潔にまとめられているので、問題はないと思います。スクラム開発を知っている人にとっても、この「おさらい」はチートシート的に役に立つのではないかと思います。
要所要所で図があったり、要点が箇条書きで簡潔にまとめられているところがあるなど、個人的にはかなり理想に近いテキストで、非常にわかりやすい内容だと感じました。
Posted by ブクログ
スクラムは実践している、けれども大規模アジャイルについてはよくわからないー。私自身がそうだが、そういった人がscrum@scaleについて概要をおさえるのにうってつけの一冊。
オーソドックスなスクラムを起点に各コンポーネントの解説がなされ、実際に著者が行っている実践例まで紹介されるため、かなりとっつきがよい。なんならちょっとやってみたくなる。
いわゆる大規模アジャイルについて疎い人間としては、scrum@scale以外の大規模アジャイルについても簡単に触れているのがありがたかった。
Posted by ブクログ
大規模スクラムの中でも、特にScrum@Scaleに主眼を置いた一冊。
その他の手法にも触れつつ、どういった部分に主眼を置いているのか、異なるのかといった部分が紹介されていてよかった。
著者が実際に組織に導入した例などにも触れつつ、構成する各コンポーネントの働きや協働する内容が説明されており、実際の現場に当てはめてイメージがしやすかった。
フラクタルな構造を維持するうえで、完全に官僚的な構造を排除することは難しく、必要最小限の官僚機構を導入するというのは納得感がある。
複数のチームが連動するスクラムチームの中に身を置いている中で感じていた課題を自分の中で整理するうえで、非常にいい本だった。
Posted by ブクログ
自社でやろうとしていることのヒントになるかも、という思いもあり手に取った。
具体的にはScrum@Scale そのものをやりたいわけでは無いのだけど「自律して動けるよくできたチーム」を単位として組織のパラダイムを変化させていこうと考えており、考慮すべき点の参考になった。
Posted by ブクログ
LeSS：プロダクトバックログは一つ、プロダクトオーナーも1人。スプリントバックログはチームの数だけ必要。
Scrum@Scale：開発現場のHowの部分を担うスクラムマスターサイクル＋Whatの部分を担うプロダクトオーナーサイクル
スクラムマスターサイクルは、開発チームが複数で連携するためのやり方を定義しています。プロダクトオーナーサイクルは、複数の開発チームが連携するために、それぞれのチームに所属するプロダクトオーナーたちの仕事のやり方を定義しています。
Scrum@Scaleの主な特徴は、普通のスクラムを「拡張」している点にあります。ただし、拡張することによって複数のチームによる相互のコミュニケーションが必要になるため、チーム間のコミュニケーションに関するルールを設けています。なぜなら、チームの数や関わる人数が増えて規模が大きくなるほどコミュニケーションの複雑さは増し、やがてそれは手に負えなくなってしまうからです。
…Scrum@Scaleとは、通常の単一スクラムチームの活動にチーム間の連携のしくみを追加したもの、と言い換えることができます。
▫️スクラムオブスクラムマスターの役割
・SoSとして開催するイベント全般の開催支援・ファシリテート
・SoSとして以下に関する話し合いが確実に行われるようにする
・SoS全体として仕事の妨害になるもの（障害物）の共有や除去
・SoS全体としてのプロセスの改善
・チーム横断的な依存関係の調整
・チーフプロダクトオーナーと緊密に連携し、SoSとして統合されたインクリメントを届けることに責任を持つ
・SoSそのものの継続的な改善に責任を持つ
各チームのプロダクトオーナーは、SoSやSoSoSといった構造でひと塊りになったチームどうしの結び付きの単位で、プロダクトオーナーどうしのチームを組みます。図4.13のようなイメージです。このチームで、組織全体で一貫性を持ったプロダクトバックログを作ります。そしてチームごとにプロダクトバックログをブレークダウンして供給します。そうすることで、チームが個別のプロダクトバックログを持ちながら、組織全体においても方針がバラバラにならず、一貫した方向性を示し続けることができます。このようなプロダクトオーナーによるチームを「メタスクラム」と呼びます。
メタスクラムは、プロダクトに関する方向性を決定する場となります。したがって複数の方針決定者が横並びで決定権を持った状態で活動することはあまり好ましい状態ではありません。意見が割れた場合などに、最終的な決定権を持った人が必要です。このメタスクラムには、チーフプロダクトオーナーという最終的な意思決定者を置きます。これは、専任でも、各チームのプロダクトオーナーの誰か1人が兼務してもかまいません。
スクラムマスターサイクルとプロダクトオーナーサイクルの最初の交差点は「チームプロセス」です。スクラムガイドが定義しているスクラムの活動を軸に、Scrum@Scaleとしての組織構造を定義しています。ここからいったんスクラムマスターサイクルと、プロダクトオーナーサイクルの活動は分岐します。
プロダクトオーナーサイクルでは、組織全体の一貫性を維持し、スケールされたすべての組織が足並みをそろえるために「戦略的ビジョン」を策定し、維持します。
次に、その「戦略的ビジョン」に基づいて作成したプロダクトバックログの優先順位付けを行います(「バックログの優先順位付け」)。
プロダクトバックログは、決められた優先順位に従って整え、必要に応 じて各チーム単位に分割します(「バックログの分割とリファインメント」)。
プロダクトバックログの準備が整えば、それをいつリリースするのか「リ リースプランニング」を行います。
これらの活動を「EMS」が中心となって繰り返します。
スクラムマスターサイクルでは、日々の開発をしながらプロセスの「継続 的改善と障害の除去」を行います。
スケール化された組織では、複数チームが連携して作業にあたることと なるため、「チーム横断の調整」も欠かせません。
やがて開発したプロダクトを「デリバリ」します。
これらの活動は「EAT」が中心となって繰り返します。
活動が分岐していたプロダクトオーナーサイクルとスクラムマスターサ イクルは、プロダクトをデリバリし、そのフィードバックを得る段階で再 び合流します。ここで、それぞれの活動の次のスプリントに必要な重要な 手がかりを得ます(「プロダクトリリースとフィードバック」)。
これらのフィードバックを正しく解釈するために「メトリクスと透明性」 が重要な要素となります。
これらの両輪の活動を繰り返しながら「プロダクトインクリメント」を生み出します。
これが、Scrum@Scaleの全貌です。
▫️12のコンポーネント
・スクラムマスターサイクル
・EAT
・継続的改善と障害の除去
・チーム横断の調整
・デリバリ
・プロダクトオーナーサイクル
・EMS
・戦略的ビジョン
・バックログの優先順位付け
・バックログの分割とリファインメント
・リリースプランニング
・両サイクル共通
・チームプロセス
・メトリクスと透明性
・プロダクトリリースとフィードバック
▫️企業変革の「８つのアクセラレータ」
・危機感を醸成する
・変革を推進するチームを築く
・戦略的ビジョンを作る
・ビジョンを伝え、熱意のあるメンバーが参加する
・障害を取り除き、成果をあげる
・短期な成功を生み出す
・変化を促進する
・変化を根付かせる
