目次

第1章　ソフトウェア開発の困難にスクラムで立ち向かう

1.1　ソフトウェア開発の困難

• ソフトウェア開発は難しい
• 『人月の神話』に立ち返る
  • 本質的な困難、偶有的な困難
  • 本質的な困難の4つの性質
• 本質的な困難の構造
  • 本質的な困難は解決不可能
  • 不可視性がさらなる困難をもたらす

1.2　不可視性によるさらなる困難

• ソフトウェアは目に見えない
  • ソフトウェアの表面性
  • ソフトウェアの汎用性
• コミュニケーションは目に見えない
  • 小さな組織、大きな組織
  • コミュニケーションパスの増大
  • ビジョンへの時間の影響

1.3　ソフトウェアはどこにあるのか

• ソフトウェアは人々の心の中に
• ソフトウェアは人々のコミュニケーションの中に

1.4　ソフトウェア開発の困難に立ち向かう

• 問題を分解、整理する
  • 5W1Hによる問題の分解、整理
• 最高のソフトウェア？
  • 5W1Hでわかること
  • Whatとしてのソフトウェア
  • Howとしての開発プロセス

1.5　スクラムとは何か

• スクラムの定義
• スクラムの由来
  • スクラムは日本発？
  • 竹内・野中論文
  • スクラムの現在

1.6　スクラムで、複雑で変化の激しい問題に対応する

• 複雑で変化の激しい問題とは何か
  • 目的の不確実性、手段の不確実性
  • 入り組んだ問題、複雑な問題
• 問題に経験主義で対処する
• 反復的かつ漸進的な手法
  • スプリント ── 時間を一定に区切って反復する
  • WhatとHowにおける検査と適応
• 開発をリードする2つの役割
  • プロダクトオーナー ── Whatを担う
  • スクラムマスター ── Howを担う
  • リーダーシップの基本の2軸
  • スクラムにおけるリーダーシップの2軸

1.7　本章のまとめ

第2章　スクラムチーム

2.1　スクラムチームとは何か

• 自己組織化するチーム
  • 自己組織化とは何か
  • スクラムの文脈での自己組織化
• スクラムチームのロール
  • 3つのロール
  • ロールと役職の違い
  • ステークホルダー ── スクラムチーム以外の関係者

2.2　プロダクトオーナー ── プロダクトの最終責任者

• プロダクトオーナーとは何か
• プロダクトオーナーは1人
• 開発チームからの独立前付けに明記
• 組織からの承認
• 要件の決定
• 優先順位の管理

2.3　開発チーム ── プロダクトを作る専門家

• 開発チームとは何か
• 開発チームは3〜9人
• 機能横断的チーム
• みんなで開発
• リリース判断可能なプロダクトの開発

2.4　スクラムマスター ── スクラムの推進者

• スクラムマスターとは何か
• スクラムマスターは1人
• プロダクトオーナーへの支援
• 開発チームへの支援
• 組織全体への支援

2.5　本章のまとめ

第3章　スクラムイベント

3.1　スクラムイベントとは何か

• スクラムイベントを通して透明性を確保する
• 検査と適応で変化に対応する

3.2　スプリント ── ステップバイステップでプロダクトとスクラムチームを成長させる

• スプリントとは何か
• 通常のスプリント ── リリース判断可能なプロダクトを作り続けるスプリント
  • 仕事の進め方を工夫し続ける
• スプリントゼロ ── 開発を始めるための特別なスプリント
  • ビジネスモデルの仮説を立てる
  • プロダクトを作る理由と実現方法を明らかにする
  • チームづくりのワークショップを行う
  • 開発環境を準備する
  • プロダクトバックログを準備し、完成の定義を決める
• リリーススプリント ── リリースをやりきるための特別なスプリント
  • 残ったタスクを終わらせる
  • リリース後にスクラムチームやプロダクトを見つめなおす

3.3　スプリントプランニング ── スプリントの計画を作る

• スプリントプランニングとは何か
• リファインメント ── スプリントプランニングの準備
  • プロダクトバックログを更新する
  • プロダクトバックログアイテムの見積りを行う
  • プロダクトバックログアイテムの内容を具体化する
• ベロシティに基づくスプリントゴールの設定
• タスクの洗い出しとスプリントバックログの作成
• スプリントゴールの合意

3.4　デイリースクラム ── 日々の進捗、予定、問題を共有する

• デイリースクラムとは何か
• スプリントの状況確認
  • 明るく元気な声で挨拶する
  • 昨日したこと、今日やること、困っていることを話す
• スプリントゴールが達成できそうかの確認
  • 時間内に終わらなければ二次会を開催する
  • 達成が難しい場合はプロダクトオーナーに相談する

3.5　スプリントレビュー ── スプリントの成果を確認する

• スプリントレビューとは何か
• スプリントで達成できたことの報告
  • 動くソフトウェアでデモをする
• インクリメントの受け入れ確認
• インクリメントに対するフィードバックの取得
• 今後のスプリントで作るものの議論

3.6　スプリントレトロスペクティブ ── 仕事の進め方を改善する

• スプリントレトロスペクティブとは何か
• 仕事の進め方の見なおし
• 仕事の進め方の合意

3.7　本章のまとめ

第4章　スクラムの作成物

4.1　スクラムの作成物とは何か

• 透明性の高い作成物を作る
• 作成物を誰もがいつでも触れられる場所に置く

4.2　プロダクトバックログ ── 何を実現するかの一覧

• プロダクトバックログとは何か
• 意思決定可能なプロダクトバックログの作り方
  • プロダクトバックログアイテムの内容を簡潔に表現する
  • プロダクトバックログアイテムの見積りを記載する
  • プロダクトバックログアイテムを1列に並べる
  • プロダクトバックログの内容を見なおす

4.3　スプリントバックログ ── 今、何を行うかの一覧

• スプリントバックログとは何か
• 実現可能なスプリントバックログの作り方
  • プロダクトバックログアイテムを実現するためのタスクを洗い出す
  • タスクの進捗を可視化する
  • スプリントバックログの内容を見なおす

4.4　インクリメント ── スプリントで作ったもの

• インクリメントとは何か
• リリース判断可能なインクリメントの作り方
  • 常に動く状態を保つ
  • 完成の定義を守る

4.5　本章のまとめ

第5章　スクラムを支えるプラクティス

5.1　プラクティスをパターンで解説する

• パターンとは何か
• パターンの由来と発展
  • 建築の設計におけるパターン
  • ソフトウェアのデザインパターン
  • パターンの広がり
  • パターン化するスクラム
• パターンのフォーマット
  • 状況
  • 問題
  • 空気
  • 解決
• 本章で解説するプラクティス

5.2　インセプションデッキ ── 10の課題でプロジェクトを導く

• 状況
• 問題
• 空気
• 解決

5.3　リーンキャンバス ── プロダクトを1枚で定義する

• 状況
• 問題
• 空気
• 解決

5.4　ユーザストーリー ── ユーザ視点で要求を簡潔に記述する

• 状況
• 問題
• 空気
• 解決

5.5　ユーザストーリーマッピング ── ユーザ体験を時間軸で整理する

• 状況
• 問題
• 空気
• 解決

5.6　プランニングポーカー ── 開発チーム全員で見積りをする

• 状況
• 問題
• 空気
• 解決

5.7　スパイク ── 技術的不確実性を取り除く

• 状況
• 問題
• 空気
• 解決

5.8　バーンダウンチャート ── プロジェクトの進捗を見える化する

• 状況
• 問題
• 空気
• 解決

5.9　パーキングロット ── アイデアを一時退避する

• 状況
• 問題
• 空気
• 解決

5.10　KPT ── レトロスペクティブを効果的に実施する

• 状況
• 問題
• 空気
• 解決

5.11　技術的負債の返済 ── 開発スピードを保ち続ける

• 状況
• 問題
• 空気
• 解決

5.12　継続的インテグレーション ── スプリントを安定的に運用する

• 状況
• 問題
• 空気
• 解決

5.13　本章のまとめ

第6章　GMOペパボの事例 ── どのように導入したか

6.1　スクラム導入の経緯

• 導入前に抱えていた問題
  • 作業の属人化
  • スケジュール管理、優先順位付けが難しい
• さまざまな問題を解決するためのスクラム導入

6.2　どのようにスクラムを導入したか

• プロダクトバックログの作成
  • 洗い出せた現状の問題点
• スプリントバックログの作成
  • 1週間でできる仕事量の可視化
  • わかりやすくなった進捗状況
• 毎朝15分間のデイリースクラム
  • 全員参加の一体感がとても効果的
  • デイリースクラムで収まらなかったら二次会
• 週に一度のスプリントレビュー
  • できたもので進捗を可視化
  • レビューの準備が重要
• KPTを用いたスプリントレトロスペクティブ
  • プロセスの良かったこと、悪かったことの発表
  • 見えてきた予定外のタスク

6.3　スクラムを導入して良かったこと、気づいたこと

• 見える化は偉大
• コミュニケーションツールとしてのスクラム
• みんなで考える
• 属人化は「日直日誌」で解消していく
• 割り込みタスクをある程度は許容する
• 仕事のしかたを全社で共有する

6.4　本章のまとめ

第7章　mixiの事例 ── 導入失敗からの立てなおし

7.1　スクラム導入の経緯

• 導入前に抱えていた問題
  • 作業の属人化
  • コミュニケーション不全による信頼低下
• とりあえずで始めるスクラム

7.2　初めてのスプリント

• 難航したスプリントプランニング
  • 困難な協働見積り
  • 計画を変更できないルールへの不安
• 終わらないスプリント
• 収束しないスプリントレトロスペクティブ
• 初めてのスプリントを終えて

7.3　課題を抱えたまま継続するスプリント

• 目的がないことによるマンネリ化
• ほかの開発チームへの波及効果
• スクラムの本質を学ぶ必要性

7.4　あらためて始めるスクラム

• スクラムを採用する目的の設定
• 再始動のための準備
• 正しいプロダクトバックログが起こした変化
  • コミュニケーションの質の改善
  • 属人化排除への取り組み
  • モチベーションの向上

7.5　現在の開発フロー

• 基本的にはスクラムがベース
• 専任のスクラムマスターは不在
• スクラムチームどうしのコミュニケーション

7.6　本章のまとめ

第8章　DeNAの事例 ── 大規模開発、業務委託への適用

8.1　スクラム導入の経緯

• スクラム導入前の開発プロセス
  • 規模による開発プロセスの違い
  • 運用フェーズの待ち時間の使い方
• 導入前に抱えていた問題
  • ミドルマネジメントの問題
  • 現場の問題
• 偶然訪れたスクラムとの接点
  • 初めてのスクラム
  • スクラムに対する印象

8.2　スクラムの導入

• 導入当初のスクラム
  • 崩壊しかけたスクラム
• スクラムの修復
  • スクラムの再学習
  • スクラムマスターの専任化
  • 技術的負債への対策
  • 環境改善スクラムチーム
• スクラム導入のふりかえり

8.3　大規模スクラムの導入

• 大規模スクラム導入の背景
  • プロダクトバックログの分割
  • スクラムチームの分割
• 大規模スクラムのスプリントゼロ
  • 完成の定義と働き方のルールの作成
  • リリース計画の作成
  • スクラムイベントの設計
• 大規模スクラムのスプリント
  • 効率性の見なおし
  • 期間と粒度の見なおし
• 大規模スクラム導入のまとめ

8.4　業務委託スクラムの導入

• 業務委託の制約
• 業務委託スクラムのスプリントゼロ
  • スクラムを可能にする契約
• 業務委託スクラムのスクラムイベント
  • スクラムイベントを代替する定例会議

8.5　本章のまとめ

第9章　スクラム導入時によくある問題と解決策

9.1　スクラムチームの組成

• 寄せ集めのメンバーで構成されている
  • チームのビジョンを描く
  • 開発チームの強み、弱みを可視化する
  • 開発チームのスキルの底上げを行う
• スクラムの理解が不足している
  • スクラム勉強会を開催する
  • お試し期間の設定と感想の共有を行う
• スクラムを使う理由が不明
  • 目的を整理する
  • スクラム導入のきっかけ探し
  • 意欲がわかない理由を明らかにする
  • スクラムチームから外れてもらう

9.2　スクラムイベントの設計

• 最適なスプリント期間がわからない
  • 最短の1週間で始める
  • 仕事の特性に合わせて変更する
• スクラムイベントの参加者と日時が決められない
  • イベントの目的に沿って参加者を決める
  • 参加者が十分に参加できる日時を決める
• 大規模過ぎてスクラムができない
  • スクラムチームをサブチームに分割する

9.3　本章のまとめ

第10章　スクラムチームでよくある問題と解決策

10.1　プロダクトオーナー

• 意思決定が覆される
  • 権限を委譲してもらう
  • ステークホルダーを巻き込む
• 必要十分なプロダクトバックログを作れない
  • プラクティスを活用する
  • プロダクトオーナーを支援する
• 適切な優先順位を付けられない
  • ポイントを絞って決めていく
  • 投資対効果で優先順位を付ける
  • サポートチームをつける
• インクリメントをすべて受け入れてしまう
  • プロダクトオーナーにわかるように説明する
  • インクリメントの受け入れ条件を作る
• つかまらないプロダクトオーナー
  • 物理的な距離を近づける
  • プロダクトオーナーに合わせてスクラムイベントを計画する

10.2　開発チーム

• チームメンバーが途中で増える
  • チームビルディングをやりなおす
  • ペアで作業する
• チームメンバーが途中で減る
  • 引き継ぎスプリントを行う
• 外の関係者に依存する作業が完了できない
  • 外側のチームを巻き込む

10.3　スクラムマスター

• スクラムの奴隷
  • スクラムを導入する目的を整理する
  • コーチ役をつける
• ロールを兼任してしまう
  • スクラムマスターとプロダクトオーナーを兼任しない
  • スクラムマスターと開発チームを兼任しない
  • 複数チームのスクラムマスターを兼任する

10.4　本章のまとめ

第11章　スクラムイベントでよくある問題と解決策

11.1　スプリントプランニング

• タスクの表現が属人化してしまう
  • タスクの表現方法を統一する
• 見積りができない
  • 大雑把な見積りと正確な見積りを使い分ける
  • 見積りができるようになるまで見積もらない
• スプリントでこなせる作業量がわからない
  • 開発チームのベロシティを計測する
  • 開発チームの作業時間を計測する

11.2　デイリースクラム

• 終わらないデイリースクラム
  • タイマーを使う
  • 二次会を開催する
• 集まらないデイリースクラム
  • 開催する時間帯を変える
  • 集まれなくても進捗を伝える
• いつの間にかタスクが増えている
  • 個別の依頼は即答を避ける
  • 優先順位はプロダクトオーナーが決める
• 動かぬタスクボード
  • 最初はお手本を示す
  • タスクボードの管理人をやめる／やめてもらう
• 問題点が出てこない
  • 質問を工夫する
  • 問題は必ず拾う
  • 問題がないことを明示する

11.3　スプリントレビュー

• レビューではなく進捗共有会
  • 正しい参加者だけを招待する
  • レビューの準備をする
• 場の空気が悪い
  • 場を和ますアイテムを使う
• スプリントレビューまでリリースしてはいけないという誤解
  • 適切なタイミングでリリースする
  • スプリントレビューの目的の再確認する
• 完成しなかったプロダクトバックログアイテムの扱いがわからない
  • スプリントは延長しない
  • 残ったプロダクトバックログアイテムをいつどのように扱うか決める
  • 完成した要件のみベロシティとして計測する

11.4　スプリントレトロスペクティブ

• 反省会、批判報告会になってしまう
  • グラウンドルールを作る
  • スクラムチームの問題にする
• ふりかえるだけで実行に移されない
  • スクラムチームのルールにする
  • 改善案をタスクに落とし込み、責任者を決める
• 参加できない人がいる
  • 経緯を伝える
• 問題が出ない、問題が出過ぎる
  • 問題を紙に書いて整理する
  • すぐに解決したい問題にフォーカスする
• プロダクトオーナーやステークホルダーが主導権を握る
  • まずは開発チームでスプリントレトロスペクティブを開催する
• スプリントゴールが達成できなかったことに触れられない
  • 終わらなかった原因を明らかにする
  • バーンダウンチャートを活用する

11.5　本章のまとめ

第12章　スクラムの作成物によくある問題と解決策

12.1　プロダクトバックログ

• 夢見がちなプロダクトバックログ
  • ビジョンに基づいて整理する
  • 数と粒度を定期的に整理する
• 隠れたプロダクトバックログアイテム
  • プロダクトバックログを管理する媒体を変える
  • 突発的なプロダクトバックログアイテムの発生をある程度は許容する

12.2　スプリントバックログ

• 管理がうまくいかない
  • タスクボードを工夫する
  • デジタルツールと組み合わせて使う
• 進捗がわかりにくい
  • バーンダウンチャートでトラッキングする

12.3　インクリメント

• 完成したと思ったのに完成していなかった
  • 完成の定義を言語化する
  • 完成の定義を見なおす

12.4　本章のまとめ