スクラム

スクラムとは

スクラム (Scrum) は、スプリントと呼ばれる反復サイクルで開発を進める アジャイル のフレームワークである。Ken Schwaber と Jeff Sutherland が 1995 年の OOPSLA カンファレンスでスクラムを初めて共同発表し、そこで最初の公式な定義が公開された。以後の改訂も同じ 2 人が続けており、定義の正は「スクラムガイド」である。本項は現行版である 2020 年 11 月版に合わせている。

スプリントの長さは 1 か月以内の固定長と決められているだけで、2 週間にするか 1 週間にするかはチームが選ぶ。短くすれば計画のやり直しが早く効き、長くすれば 1 回で扱える塊が大きくなる。実務では 1〜2 週間が多い。

スクラムがこれだけ薄い定義で成り立つのは、経験主義に土台を置いているからである。作りかけの成果と進捗を隠さず見える状態にし、定期的に突き合わせ、ずれていたら計画かやり方を変える。この透明性・検査・適応の 3 点を回すための最小限の場としてイベントが定義されている。逆に成果が見えない運用や検査の場を飛ばす運用にすると、イベントの形だけが残って何も直らなくなる。

3 つのアカウンタビリティ

プロダクトオーナー (PO) はプロダクトバックログの並び順を決め、プロダクトの価値を最大化する責任を負う。スクラムマスター (SM) はスクラムの理解と実践を支え、進行を妨げているものを取り除く。開発者は、使える状態のインクリメントを毎スプリント作ることに責任を負う。

現行版のスクラムガイドは、この 3 つを役割ではなくアカウンタビリティと呼ぶ。肩書きや職位の割り当てではなく、成果に対して誰が責任を負うかの区分だという意図である。同じ改訂で「開発チーム」という呼称も廃され、スクラムチームの中にサブチームを作らない形になった。PO と SM も開発者と同じ 1 つのスクラムチームの一員で、規模の目安は PO と SM を含めたチーム全体で 10 人以下である。上限を開発者の人数だけに当てはめる古い数字が今も流通しているが、現行の目安は合計人数の話である。大きくなりすぎたら人を詰め込むのではなく、同じプロダクトゴールとプロダクトバックログ、同じ PO を共有する複数のスクラムチームに分ける。

5 つのイベント

スプリント自体が残りの 4 つを収める容器なので、イベントは 5 つと数える。表の上限は 1 か月スプリントを前提としたタイムボックスで、スプリントが短ければそれに応じて短くするのが通例である。

イベント	タイミング	目的	上限
スプリント	1 か月以内の固定長	開発の反復サイクル	-
スプリントプランニング	スプリント開始時	スプリントゴールを立て、着手する項目と計画を決める	8 時間
デイリースクラム	毎営業日・同じ時刻と場所	ゴールへの進捗を検査し、当日以降の計画を調整する	15 分
スプリントレビュー	スプリント終了前	インクリメントを関係者と検査し、次にやることを話す	4 時間
スプリントレトロスペクティブ	スプリントの最後	品質と効率を上げる手を決める	3 時間

デイリースクラムの進め方は開発者が自分たちで選んでよく、決まった質問形式はない。現行版では「昨日やったこと・今日やること・障害」の 3 問という書き方が外れている。形式を固定すると 1 人ずつ持ち回る報告会になりやすく、本来の目的はスプリントゴールに届くかを見て計画を直すことだからである。

スプリントレビューも発表会ではなく関係者を交えた作業の場で、デモはその材料に過ぎない。締めくくりのスプリントレトロスペクティブについては レトロスペクティブ で詳しく扱う。

3 つの作成物と確約

プロダクトバックログはプロダクトに必要なものを並べた一覧で、並び順の責任は PO が持つ。スプリントバックログは今スプリントで着手する項目とその計画で、学びに応じてスプリント中も更新される。インクリメントは検証を終えた使える成果であり、1 スプリントに複数生まれることもある。

現行版では、この 3 つそれぞれに確約が結び付けられた。プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義である。確約は作成物を測る基準を与える仕組みで、たとえば完成の定義を満たさない作業はインクリメントに含められない。スプリントゴールがあるおかげで、項目の消化数ではなく目的の達成度で進捗を検査できる。

スプリントの流れ

スプリントは前のスプリントが終わった直後に始まり、間に準備期間を挟まない。プランニングでスプリントゴールと着手項目を決め、デイリースクラムで毎日ゴールまでの距離を測り直す。スプリント終了前のレビューでインクリメントを関係者と検査し、最後のスプリントレトロスペクティブで進め方を直してスプリントを締める。

スプリントプランニング
  → スプリントゴールを決める
  → バックログから項目を選び計画に落とす

デイリースクラム (毎営業日 15 分)
  → ゴールまでの距離を確認
  → 妨げになっているものを挙げる
  → 当日以降の計画を調整

スプリントレビュー
  → 完成の定義を満たしたインクリメントを検査
  → 関係者と次にやることを話す

スプリントレトロスペクティブ
  → 良かったこと / 改善すべきこと
  → 次スプリントで実行する改善を 1〜2 件決める

カンバンとの使い分け

どちらもアジャイルの実践だが、違いは計画の刻み方にある。カンバン は流れを止めずに 1 件ずつ流し、スクラムは固定長のスプリントで区切って検査する。優劣ではなく、割り込みの読めなさで選び分けるのが実務的である。

観点	スクラム	カンバン
向く状況	ゴールを決めて数週間集中できる	着手順が日々変わり計画が読めない
計画	スプリント単位	継続的
着手中の変更	ゴールを危うくする変更は入れない	いつでも追加可能
よく使う指標	ベロシティ	リードタイム

「スプリントが始まったら一切変更できない」という理解は行き過ぎである。現行版が禁じるのはスプリントゴールを危険にさらす変更と品質の引き下げで、範囲そのものは学びに応じて PO と再交渉してよい。守るのはゴールであって、当初の項目一覧ではない。なお表に挙げた指標はどちらもスクラムガイドの定義ではなく実務の慣習で、スクラムが検査を求めているのはゴールへの進捗である。

よくある失敗

• スプリントレビューを飛ばす → 作ったものが妥当だったかを確かめずに次のスプリントへ入り、ずれに気づくのが数スプリント後になる
• 改善策を挙げるだけで実行しない → 振り返りが感想戦で終わる。次スプリントのスプリントバックログに 1 件でも載せて実行を担保する
• PO が並び順を決めない → 開発者が価値判断を代行することになり、着手順が声の大きさで決まる
• デイリースクラムが進捗の報告会になる → 15 分でゴールとの差を測って計画を直す場に戻し、個別の問題の掘り下げは会の後に回す
• スプリントゴールを立てず項目だけ積む → 途中で状況が変わったときに、何を守り何を落とすかの判断根拠がなくなる

スプリントプランニングの例

見積もりと受け入れ基準をどこまで詰めるかを、やり取りの形で示す。

PO: 「注文機能のバリデーション追加 (5pt)」
チーム: 「受け入れ基準は？」
PO: 「金額が 0 以下の注文を拒否、エラーメッセージを表示」
チーム: 「5pt で合意。今スプリントに入れます」
→ スプリントバックログに追加

基礎から学ぶなら関連書籍が手がかりになる。