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

書籍の概要

この本の概要

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

こんな方におすすめ

  • 規模の大きな組織にスクラムを取り入れたいと考えているマネージャーや経営者
  • ソフトウェア開発の組織設計に関わるマネージャーや経営者
  • 大規模スクラムの実践例を知りたいスクラム実践者

この書籍に関連する記事があります!

はじめに

本書のサンプル

本書の一部ページを,PDFで確認することができます。

本書の紙面イメージは次のとおりです。画像をクリックすることで拡大して確認することができます。

サンプル画像1

サンプル画像2

サンプル画像3

サンプル画像4

サンプル画像5

目次

  • はじめに
  • 目次

第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のコンポーネントの自己採点と変革バックログ

まとめ

  • 参考文献
  • 索引

著者プロフィール

粕谷大輔(かすやだいすけ)

Chatwork株式会社 エンジニアリングマネージャー

SIer,ソーシャルゲーム開発でのエンジニア業務,サーバー監視ツール開発のディレクターを経て,2021年より現職。Scrum@Scaleを実践しながら開発組織の整備,会社全体のアジャイル化を推進している。