• はじめに
• 目次

第1章：スクラムのスケーリングと大規模の難しさ

スクラムをスケールするとはどういうことか

• 1つのスクラムチームから増やしていく場合
  • チームを増やしたくなる動機
  • 人が増えることでコストは大きくなる
  • スクラムをスケールしない方法を考える
  • 疎結合なスケールを検討する
• 大規模な組織に新しくスクラムを適用する場合
  • 大規模組織であっても最初は小さく始める
• スクラムのスケールは安易に選択すべきではない

さまざまなスケーリングスクラムのやり方

• LeSS──1人のプロダクトオーナーと1つのプロダクトバックログ
• Nexus──統合チームが統合の責任を持つ
• SAFe──エンタープライズ向けビジネスフレームワーク
• Scrum@Scale──プロダクトオーナーをスケールする

大規模スクラムの導入と組織文化

• 大規模スクラムの導入は組織的な支援が必要
• 大規模スクラムを成功させる「動機付け」

まとめ

第2章：スクラムのおさらい

スクラムとは

• 経験主義の三本柱
  • 透明性
  • 検査
  • 適応
• スクラムの価値基準
• 3つの作成物，スクラムチーム，5つのイベント

スクラムにおける3つの作成物

• プロダクトバックログ
• プロダクトバックログリファインメント
• スプリントバックログ
• インクリメント

スクラムチーム

• 開発者
• プロダクトオーナー
• スクラムマスター
• スクラムチームの人数

スクラムにおける5つのイベント

• スプリント
• スプリントプランニング
  • このスプリントはなぜ価値があるのか？
  • このスプリントで何ができるのか？
  • 選択した作業をどのように成し遂げるのか？
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

まとめ

第3章：とあるチームのScrum@Scaleでの1スプリント

チームの紹介

とあるチームのデイリースクラム

さまざまなデイリースクラム

• • [Column]モブワーク／モブプログラミング
• SDS
• EATのデイリースクラム
• 毎日45分で問題が解決する

プロダクトオーナーの活動

• 複数のプロダクトオーナーとその仕事
• チーフプロダクトオーナーの活動とメタスクラム
• メタスクラムでの議論
• スケールされたプロダクトバックログリファインメント
• スケールされたスプリントレビュー

まとめ

第4章：スクラムマスターサイクルとプロダクトオーナーサイクル

Scrum@Scaleの特徴

スクラムマスターサイクル

• スクラムチームとSoS
  • スクラムオブスクラムマスター
  • SoSのサイズとスケール
  • SoSは共通の関心事どうしで作る
  • 関心事をどのように分離するか
  • コンウェイの法則と逆コンウェイ作戦
• Scrum@Scaleと『チームトポロジー』
  • チームタイプ
  • インタラクションモード
• SoSのイベント
  • SDS
  • スケールドレトロスペクティブ
  • SoSのスプリント
• Executive Action Team（EAT）
  • EATの役割
  • EATに誰が参加するか
  • [Column]アジャイルプラクティス
  • EATも1つのスクラムチームになる
  • EATのメンバーは外部のステークホルダーのようにならない
• 組織構造の継続的な改善
  • 人が異動することによるコスト
  • 人ではなくチームの組み合わせを変えていく
  • どのように組織を変更するか
  • EATだけで人の配置を決定できるようにする

プロダクトオーナーサイクル

• なぜプロダクトオーナーは開発チームから独立してスケールするのか
• チーフプロダクトオーナーとメタスクラム
• EMS
  • EMSの役割
  • EMSに誰が参加するか
• プロダクトオーナーの活動を支援するイベント
  • プロダクトバックログリファインメント
  • スケールされたスプリントレビューとスケールされたスプリントプランニング

まとめ

第5章：Scrum@Scaleを形成する12のコンポーネント

習熟度を確認するために12のコンポーネントを使う

最初に行うコンポーネント

• チームプロセス──2つのサイクルの交差点
  • [Column]守破離
  • Scrum@Scaleでの守破離の「破」

スクラムマスターサイクルのコンポーネント

• 継続的改善と障害の除去──開発の障害を迅速に取り除く
• チーム横断の調整──コラボレーションの合理化
  • [Column]レベル2のスクラムマスター
• デリバリ──完成したプロダクトを届ける

プロダクトオーナーサイクルのコンポーネント

• 戦略的ビジョン──組織全体の方向性を作る
  • [Column]EBM
• バックログの優先順位付け──価値の提供の最適化
• バックログの分割とリファインメント──チームの理解を深める
• リリースプランニング──長期的な計画を作る
  • すべての機能がそろう時期の範囲を伝える
  • ある時期までに完成する機能の量の範囲を伝える
  • 期限に確実に終わらせるためにやることを減らす

共通のコンポーネント

• プロダクトリリースとフィードバック──プロダクトバックログの更新
• メトリクスと透明性──検査・適応のための手段
  • チームのパフォーマンス
  • SLI（サービスレベル指標）／SLO（サービスレベル目標）
  • ビジネスを測る指標
  • メトリクスは単独では意味がない

まとめ

第6章：現場へどのように導入していくか

ステップ0：機能しているスクラムチームを作る

• スクラムチームが機能しているとはどういう状態か
  • [Column]スクラムチームの成熟度

ステップ1：SoSを立ち上げる

• 単一のチームを複数に拡張する
• チーム分割の落とし穴
  • 人がチームを横断する
  • 分割後の依存関係
• SoSのスクラムイベントをスタートする
• SoSの作成物
• EATを立ち上げ，エグゼクティブメンバーを巻き込む

ステップ2：メタスクラムを立ち上げる

• チーフプロダクトオーナーを選出する
• メタスクラムとしてのイベントを立ち上げる
• EMSを立ち上げ，エグゼクティブメンバーを巻き込む

ステップ3：改善サイクルを回す

• 12のコンポーネントと変革バックログ
  • [Column]EATを一番初めに導入するパターン

まとめ

第7章：Scrum@Scaleで運用される現場 ──チャットサービスの開発現場の場合

なぜScrum@Scaleを選択したのか

• 逆コンウェイ作戦
• プロダクトオーナーチームの利点

Scrum@Scaleの組織構造とイベントの運用

• 3つのスクラムチーム
• SoSとEAT
• メタスクラム
• アジャイルプラクティス

Scrum@Scaleのイベント

• スクラムマスターサイクルとしてのイベント
  • SDS
  • スケールドレトロスペクティブ
  • EATとしてのイベント
  • [Column]むきなおり
• プロダクトオーナーサイクルとしてのイベント
  • メタスクラムのデイリースクラム
  • メタスクラムのプロダクトバックログリファインメント
• 1週間のカレンダーまとめ

組織構造の変遷

• 初期状態
  • 2チームで開始したアーキテクチャ上の理由
  • CQRS
  • チームをコマンドとクエリに分離
• 4ヵ月目──認証・認可基盤チームが立ち上がり3チーム体制へ
• 6ヵ月目──開発スコープの変更によるチーム再編
• 8ヵ月目から現在──SoSの再編とEAT
  • SoSの再編
  • EMSからEATへ

12のコンポーネントの自己採点と変革バックログ

まとめ

• 参考文献
• 索引