スクラムは「透明性・検査・適応」の3本柱で、複雑なプロダクト開発を進めるための軽量なフレームワークです。本ドキュメントでは、スクラムガイド（2020年版）を土台に、現場で効果が確認されている実践をまとめます。
目次
- スクラムの基本構造
- 役割（アカウンタビリティ）のベストプラクティス
- イベントのベストプラクティス
- 作成物（アーティファクト）のベストプラクティス
- 見積もりと計画
- 技術プラクティス
- チーム文化と価値基準
- よくあるアンチパターン
- スクラム導入・改善のチェックリスト
1. スクラムの基本構造
| 区分 | 要素 |
|---|
| 役割 | プロダクトオーナー（PO）、スクラムマスター（SM）、開発者 |
| イベント | スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ |
| 作成物 | プロダクトバックログ、スプリントバックログ、インクリメント |
| 確約（コミットメント） | プロダクトゴール、スプリントゴール、完成の定義（DoD） |
- スクラムチームは10人以下が目安。大きくなる場合は、同じプロダクトゴール・プロダクトバックログ・POを共有する複数チームに分割する。
- スクラムは「フレームワーク」であり、完全な方法論ではない。 足りない部分（技術プラクティス、見積もり手法など）はチームが補う。
2. 役割（アカウンタビリティ）のベストプラクティス
プロダクトオーナー（PO）
- POは1人の人間とし、委員会にしない。最終的な優先順位の決定権を持たせる。
- プロダクトゴールを明確に言語化し、チームとステークホルダーに繰り返し共有する。
- バックログの順序は「価値・リスク・依存関係・学習効果」で決める。
- 開発者と日常的に会話できる距離にいる（スプリントレビューだけ現れるPOは機能しない）。
- 「何を・なぜ」に責任を持ち、「どうやって」は開発者に任せる。
スクラムマスター（SM）
- サーバントリーダーとして、チームの障害を取り除き、自己管理を促す。
- 会議の議事進行役や単なるタスク管理者にならない。
- チームだけでなく、PO・組織全体へのコーチングも役割に含まれる。
- チームが成熟したら、ファシリテーションをメンバーに委ね、自身は組織的な障害の解消に注力する。
開発者
- クロスファンクショナル（設計・実装・テスト・リリースまでチーム内で完結できる）を目指す。
- 「自分の担当タスク」ではなく「チームのスプリントゴール」に責任を持つ。
- T字型スキル（専門性＋周辺領域の対応力）を育て、特定個人へのボトルネックを減らす。
3. イベントのベストプラクティス
すべてのイベントはタイムボックスを守ること。以下は1か月スプリントの場合の上限で、スプリントが短ければ比例して短くするのが一般的。
| イベント | タイムボックス（1か月スプリント時） | 目的 |
|---|
| スプリント | 1か月以内（多くは1〜2週間） | 価値あるインクリメントを作る |
| スプリントプランニング | 最大8時間 | 何を・どうやって作るかを決める |
| デイリースクラム | 15分 | スプリントゴールへの進捗を検査・適応 |
| スプリントレビュー | 最大4時間 | 成果を検査し、今後の方向を調整 |
| レトロスペクティブ | 最大3時間 | プロセス・関係性・ツールを改善 |
スプリント
- 期間は固定し、頻繁に変えない（リズムが予測可能性を生む）。
- 初めて導入するなら2週間から始めるのが無難。
- スプリント中にスプリントゴールを危うくする変更はしない。スコープの調整はPOと開発者の交渉で行う。
- スプリントゴールが意味を失った場合のみ、POがスプリントを中止できる（乱用しない）。
スプリントプランニング
3つの問いに答える：
- なぜこのスプリントに価値があるのか？ → スプリントゴールを決める
- 何を完成させるのか？ → バックログアイテムを選ぶ
- どうやって完成させるのか？ → タスクに分解する
- 事前にリファインメントを済ませ、上位のアイテムが「準備完了」状態であること。
- 過去の実績（ベロシティ）とキャパシティ（休暇・会議など）を踏まえて量を決める。
- スプリントゴールは1文で言える具体的な成果にする（例：「新規会員がメール認証まで完了できる」）。
デイリースクラム
- 開発者のための場であり、SMやPOへの報告会ではない。
- 「昨日やった/今日やる/障害」の3つの質問は必須ではない。スプリントゴールに近づいているかを軸に話す。
- ボード（カンバン）を見ながら、人ではなく作業の流れに注目する（「止まっているチケットはどれか？」）。
- 詳細な議論は、デイリー後に関係者だけで行う。
- 毎日同じ時間・同じ場所で開催する。
スプリントレビュー
- デモ会ではなく、ワーキングセッション。ステークホルダーからフィードバックをもらい、バックログを更新する。
- 動くソフトウェアを見せる（スライドだけの報告は避ける）。
- 完成の定義を満たしていないものは「完成」として見せない。
- 市場状況・予算・スケジュールなど、次の判断に必要な情報も共有する。
スプリントレトロスペクティブ
- 心理的安全性を最優先に。個人攻撃ではなく、仕組みやプロセスに焦点を当てる。
- KPT、Start/Stop/Continue、Mad/Sad/Glad、タイムラインなど、手法を時々変えてマンネリを防ぐ。
- 改善アクションは1〜3個に絞り、担当と期限を決める。
- 重要な改善アクションは次のスプリントバックログに入れて、確実に実行する。
- 前回のアクションの結果を必ず振り返る。
プロダクトバックログリファインメント（継続的活動）
- 正式なイベントではないが、スプリントの10%程度の時間を目安に継続的に行う。
- 上位アイテムを、1スプリントで完成できる大きさまで分割する。
- 受け入れ条件を明確にし、見積もりを付ける。
- 開発者・PO・必要に応じてステークホルダーが参加する。
4. 作成物（アーティファクト）のベストプラクティス
プロダクトバックログ
- 唯一の要求リストとして一元管理する（Excel、チケット管理、口頭の依頼が並存する状態を避ける）。
- 上位ほど詳細・小さく、下位ほど粗く大きい（DEEP：Detailed appropriately / Emergent / Estimated / Prioritized）。
- 古くなった・価値がなくなったアイテムは定期的に削除する。
良いバックログアイテムの条件（INVEST）
| 頭文字 | 意味 |
|---|
| Independent | 他のアイテムから独立している |
| Negotiable | 詳細は交渉可能 |
| Valuable | ユーザーや事業に価値がある |
| Estimable | 見積もりが可能 |
| Small | 1スプリントに収まる |
| Testable | テスト可能（受け入れ条件がある） |
ユーザーストーリーの書き方の例
【ストーリー】
会員として、パスワードを忘れたときにメールで再設定したい。
それは、サポートに問い合わせずにログインを再開できるからだ。
【受け入れ条件】
- 登録済みメールアドレスを入力すると、再設定リンクが送信される
- リンクの有効期限は30分
- 未登録のアドレスでも、同じメッセージを表示する（アカウント存在の推測を防ぐ）
- ストーリーは縦に分割する（UI・API・DBを横断して、薄くても動く単位）。レイヤーごとの横分割は避ける。
スプリントバックログ
- 開発者が所有し、スプリント中に自由に更新する。
- タスクは1日以内に終わる粒度が目安。
- 進捗はタスクボードやバーンダウンチャートで常に見える化する。
インクリメントと完成の定義（DoD）
- DoDはチーム全員が合意し、文書化して見える場所に置く。
- DoDを満たさないものはインクリメントに含めない。「ほぼ完成」は存在しない。
- チームの成熟に合わせてDoDを段階的に厳しくしていく。
DoDの例
準備完了の定義（DoR）※任意
スプリントに取り込む前の基準として使うチームもある。ただし厳しくしすぎると、着手の遅れや分業の壁を生むため注意。
5. 見積もりと計画
相対見積もり
- ストーリーポイント（フィボナッチ数列：1, 2, 3, 5, 8, 13…）で相対的な大きさを見積もる。
- 基準となるストーリーを決め、それと比較して見積もる。
- プランニングポーカーで全員が同時に提示し、差が大きい場合は理由を話し合う（認識のズレを発見するのが本当の目的）。
- 13以上の大きなアイテムは分割を検討する。
ベロシティの扱い方
- ベロシティはチーム内の計画ツールであり、評価指標ではない。
- チーム間で比較しない（ポイントの基準はチームごとに異なる）。
- 直近3〜5スプリントの平均を予測に使う。
- ベロシティ向上を目標にすると、見積もりが水増しされる（グッドハートの法則）。
リリース計画・ロードマップ
- 「いつまでに何ができるか」は、ベロシティの幅（最小〜最大）でレンジとして予測する。
- 固定すべきは「日付」か「スコープ」のどちらか一方。両方の固定は品質の犠牲につながる。
- ロードマップはゴール（成果）ベースで描き、機能リストの約束にしない。
6. 技術プラクティス
スクラムは技術プラクティスを規定しないが、短いサイクルで動くインクリメントを出し続けるには、以下がほぼ必須となる。
| プラクティス | 効果 |
|---|
| 継続的インテグレーション（CI） | 統合の問題を早期発見 |
| 継続的デリバリー（CD） | いつでもリリース可能な状態を維持 |
| テスト自動化 | 回帰テストのコストを下げ、変更を恐れなくなる |
| テスト駆動開発（TDD） | 設計品質の向上、テストの網羅 |
| リファクタリング | 技術的負債の蓄積を防ぐ |
| ペアプログラミング／モブプログラミング | 知識共有、品質向上、属人化の解消 |
| コードレビュー | 品質担保と学習 |
| トランクベース開発 | 長期ブランチによるマージ地獄を回避 |
| フィーチャーフラグ | 未完成機能を隠したままデプロイ可能に |
技術的負債の管理
- 負債をバックログアイテムとして見える化する。
- 各スプリントの一定割合（例：15〜20%）を改善に充てるルールを設けるのも有効。
- 「ボーイスカウトルール」：触ったコードは来たときより綺麗にして去る。
7. チーム文化と価値基準
スクラムの5つの価値基準
| 価値 | 実践例 |
|---|
| 確約（Commitment） | スプリントゴールの達成に全員でコミットする |
| 集中（Focus） | スプリント中は割り込みを減らし、WIP（仕掛り）を制限する |
| 公開（Openness） | 進捗も問題も隠さず共有する |
| 尊敬（Respect） | 互いの能力と独立性を尊重する |
| 勇気（Courage） | 正しいことをし、難しい問題に取り組む |
心理的安全性を高める工夫
- 失敗を責めず、学習の機会として扱う（ブレームレスな振り返り）。
- SMやリーダーが率先して「分からない」「間違えた」と言う。
- 全員が発言できるように、ファシリテーションを工夫する（付箋・ラウンドロビンなど）。
WIP（仕掛り）を制限する
- 「多くを始める」より「少なく終わらせる」。
- 1人が複数のアイテムを並行するより、チームで1つずつ終わらせる（スウォーミング）。
- ボード上で「レビュー待ち」「テスト待ち」が溜まっていないか監視する。
リモート・ハイブリッド環境
- カメラ・オンラインホワイトボード（Miro、FigJamなど）を活用し、視覚的な共有を保つ。
- 雑談・ペア作業の時間を意図的に設ける。
- 非同期コミュニケーションのルール（返信目安、チャンネルの使い分け）を明文化する。
- タイムゾーンが異なる場合、イベント時間をローテーションして負担を分散する。
8. よくあるアンチパターン
| アンチパターン | 問題 | 対策 |
|---|
| デイリーが進捗報告会になっている | 開発者の自己管理が育たない | ボードとゴールを中心に、開発者同士で話す |
| レトロでアクションが実行されない | 改善が起きず、形骸化する | アクションを絞り、スプリントバックログに入れる |
| POが不在・権限がない | 優先順位が決まらず、手戻りが増える | POに意思決定権を与え、チームの近くに置く |
| スプリント途中で要件がどんどん追加される | ゴールが崩れ、計画が無意味になる | 追加はバックログへ。緊急時はPOと交渉 |
| 「完成」の基準が曖昧 | 隠れた未完了作業が蓄積する | DoDを明文化し、厳守する |
| ベロシティでチームを評価 | 見積もりが水増しされる | ベロシティは計画用途のみに限定 |
| ミニウォーターフォール（設計→実装→テストをスプリント内で分業） | 最後にテストが溢れる | 縦分割・スウォーミング・テスト自動化 |
| スクラムマスターがプロジェクトマネージャー化 | チームが指示待ちになる | SMはコーチ・ファシリテーターに徹する |
| 「スクラムをやること」が目的化 | 形だけのイベントになる | 常に「価値を届けられているか」を問う |
| 技術的負債を無視し続ける | ベロシティが徐々に低下する | 改善のための時間を毎スプリント確保 |
9. スクラム導入・改善のチェックリスト
導入時
定期的な健康診断
参考資料