スクラムの拡張による組織づくり―複数のスクラムチームをScrum@Scaleで運用する(WEB+DB PRESS plusシリーズ) [単行本]

スクラムの拡張による組織づくり―複数のスクラムチームをScrum@Scaleで運用する(WEB+DB PRESS plusシリーズ) の 商品概要

• 要旨（「BOOK」データベースより）

  スクラムは、今や数多くの現場で活用されています。しかし、スクラムは少人数での開発を想定しており、大規模開発で実践する際にさまざまな問題が発生します。そこで、大規模開発でスクラムを行うための手法がいくつか提唱されています。本書はその中の一つであるＳｃｒｕｍ＠Ｓｃａｌｅを解説します。Ｓｃｒｕｍ＠Ｓｃａｌｅは、スクラム提唱者の一人であるＪｅｆｆ　Ｓｕｔｈｅｒｌａｎｄ博士によって作られました。本書は、筆者が所属しているチームにＳｃｒｕｍ＠Ｓｃａｌｅを実際に導入した知見をもとにしています。Ｓｃｒｕｍ＠Ｓｃａｌｅをどのように日々の開発に取り入れるのか、導入事例を交えながら具体的に解説します。

• 目次

  ・見出し記号の意味は以下の通りです
  　　# 大見出し
  　　## 中見出し
  　　### 小見出し
  
  ----------------------------------------
  目次●スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する
  
  はじめに
  目次
  
  第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のコンポーネントの自己採点と変革バックログ
  # まとめ
  
  参考文献
  索引

• 内容紹介

  スクラムは、今や数多くの現場で活用されています。しかし、スクラムは少人数での開発を想定しており、大規模開発で実践する際にさまざまな問題が発生します。そこで、大規模開発でスクラムを行うための手法がいくつか提唱されています。本書はその中の一つであるScrum@Scaleを解説する書籍です。Scrum@Scaleは、スクラム提唱者の一人であるJeff Sutherland博士によって作られました。本書は、筆者が所属しているチームにScrum@Scaleを実際に導入した知見をもとにしています。Scrum@Scaleをどのように日々の開発に取り入れるのか、導入事例を交えながら具体的に解説します。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  粕谷 大輔(カスヤ ダイスケ)
  Ｃｈａｔｗｏｒｋ株式会社エンジニアリングマネージャー。ＳＩｅｒ、ソーシャルゲーム開発でのエンジニア業務、サーバー監視ツール開発のディレクターを経て、２０２１年より現職。Ｓｃｒｕｍ＠Ｓｃａｌｅを実践しながら開発組織の整備、会社全体のアジャイル化を推進している

• 著者について

  粕谷 大輔 (カスヤ ダイスケ)
  Chatwork株式会社 エンジニアリングマネージャーSIer、ソーシャルゲーム開発でのエンジニア業務、サーバー監視ツール開発のディレクターを経て、2021年より現職。Scrum@Scaleを実践しながら開発組織の整備、会社全体のアジャイル化を推進している。

スクラムの拡張による組織づくり―複数のスクラムチームをScrum@Scaleで運用する(WEB+DB PRESS plusシリーズ) の商品スペック