スクラム
Scrum ・ スクラム
固定長のスプリントで検査と適応を繰り返す、アジャイル開発の代表的なフレームワーク。経験主義が土台。
✦ 30秒で試す — 航海定義書はたった十数ページ。それで世界中のチームが動くスクラムでは、この要望をどう扱う？予想してみる概要
スクラムは、アジャイル開発の価値観を実際のチーム運営に落とし込むための、最も広く使われているフレームワークです。「スプリント」と呼ばれる1〜4週間の固定長の反復を繰り返し、スプリントごとに動くソフトウェアの増分（インクリメント）を作り上げます。名前はラグビーのスクラムに由来し、工程ごとにバトンを渡すリレーではなく、チーム全員が一丸で押し進むイメージを表しています。
スクラムの全体像は驚くほどコンパクトで、公式の定義書「スクラムガイド」は十数ページしかありません。定義されているのは3つの責任（ロール）、5つのイベント、3つの作成物だけで、設計手法やテストの書き方などの技術プラクティスは一切含まれません。「何を作るか」「どう作るか」はチームが経験から学んで決める — その学習のリズムと場を提供するのがスクラムの役割です。
軽量である代わりに、スクラムは「意図的に不完全」です。枠組みだけを与えて中身を埋めさせることで、チームが自分たちの問題を直視せざるを得なくする — スクラムがしばしば「問題を解決するのではなく、問題を見えるようにするフレームワーク」と呼ばれるのはこのためです。
なぜ生まれたか
名前と発想の源流は、ソフトウェアではなく製造業の研究にあります。1986年、竹内弘高と野中郁次郎は Harvard Business Review に論文「The New New Product Development Game（新しい新製品開発ゲーム）」を発表しました。富士ゼロックス、キヤノン、ホンダといった企業の製品開発を調べ、工程ごとに担当が入れ替わってバトンを渡す「リレー型」ではなく、多様な専門を持つ少人数のチームが最初から最後まで一緒に走り、工程を重ね合わせながら進める「ラグビー型」の開発が速く柔軟であることを示したのです。論文はこのやり方を、ボールを皆で押し進めるラグビーの「スクラム」になぞらえました。
ジェフ・サザーランドはこの論文に着想を得て、1993年に米 Easel 社のソフトウェア開発で最初のスクラムを実践し、ケン・シュエイバーとともに1995年の OOPSLA（オブジェクト指向の国際会議）で発表しました。二人が据えた土台が「経験主義（empiricism）」です。化学プラントのプロセス制御には、反応が完全に予測できるので手順を最初に定義できる「定義済みプロセス」と、予測できないので観察と調整を繰り返すしかない「経験的プロセス」の区別があります。ソフトウェア開発は後者なのに、前者のやり方（詳細な事前計画と工程管理）で管理されてきたことが失敗の根本原因だ — これが二人の診断でした。二人はともに2001年のアジャイル開発宣言の署名者でもあり、スクラムはその後最も普及したアジャイルの実装になります。定義書「スクラムガイド」は2010年に初めて公開され、現在は2020年版が最新です。
経験的プロセスを回すには3本の柱が要ります。現状が正しく見えること（透明性）、それを定期的に点検すること（検査）、点検結果に基づいて変えること（適応）です。スクラムの構成要素はすべてこの3本柱の装置として説明できます。作成物は透明性のため、イベントは検査と適応のため、ロールはそれらが機能する責任の所在をはっきりさせるためにあります。逆に言えば、形だけイベントをこなしても検査と適応が起きていなければ、スクラムをやっていることにはなりません。
詳細
3つのロール・5つのイベント・3つの作成物
スクラムチームは3つの責任で構成されます。「プロダクトオーナー」はプロダクトの価値の最大化に責任を持ち、何をどの順で作るかの一覧（プロダクトバックログ）を管理します。「開発者」は毎スプリントで実際にインクリメントを作ります。「スクラムマスター」はスクラムそのものが機能することに責任を持ち、チームの障害を取り除き、組織にスクラムを根づかせる役割です。進捗を管理する上司ではなく、プロセスの世話役である点が重要です。
作成物は3つ。プロダクト全体のやることリストである「プロダクトバックログ」、今スプリントでやると決めた分とその計画である「スプリントバックログ」、スプリントの成果である動く「インクリメント」です。それぞれに「何のためにあるか」を示す約束（プロダクトゴール、スプリントゴール、完成の定義）が紐づきます。特に「完成の定義」— 何をもって完成とみなすかの共通基準、たとえばテストが通りコードレビューを経てデプロイ可能であること — は、インクリメントの透明性を支える要です。
スプリントの流れ
イベントはすべて「スプリント」という固定長の器の中で回ります。スプリントの長さは1か月以内で固定し、期間中はスプリントゴールを危うくする変更を持ち込みません。この「固定」が重要で、締め切りが毎回同じリズムで来るからこそ、見積もりの精度やチームが1スプリントでこなせる量が経験的に測れるようになります（多くのチームが使う「ベロシティ」はこの実績値で、スクラムガイド自体には定義されていません）。
スプリントは「スプリントプランニング」で始まります。プロダクトバックログの上位項目から、今回のスプリントで何を達成するか（スプリントゴール）と、どの項目をどう実現するかを決めます。期間中は毎日15分の「デイリースクラム」で、ゴールへの進捗を検査し、その日の計画を調整します。上司への報告会ではなく、開発者自身のための再計画の場です。スプリント末には2つの検査が続きます。「スプリントレビュー」ではステークホルダーに動くインクリメントを見せ、プロダクトの方向性を検査してバックログに反映します。「スプリントレトロスペクティブ」ではプロダクトではなくプロセス — 人・関係・ツール・完成の定義 — を検査し、次のスプリントで試す改善を決めます。上の図のとおり、プロダクトへのフィードバックループ（レビュー → バックログ）とプロセスへのフィードバックループ（ふりかえり → 次のプランニング）が、毎スプリント必ず1回ずつ回る構造です。前者だけを回すと作るものは直っても働き方の問題が温存され、後者だけを回すと気持ちよく働けても的外れなものを作り続けます。
なお、スプリントごとに「リリース可能な」インクリメントを作るには技術的な裏付けが不可欠で、実務ではCI/CDによる自動ビルド・自動テスト・自動デプロイが事実上の前提になります。手作業のリリースに数日かかるチームでは、2週間スプリントは回りません。
カンバンとの違い、実務の落とし穴
スクラムとよく比較されるのがカンバンです。カンバンにはスプリントがなく、作業は一件ずつ流れ、代わりに「仕掛かり中の作業数（WIP）の上限」を設けて流れを最適化します。リズムを固定して学習するスクラム、流れを連続させて滞留を減らすカンバン、と性格が異なり、インシデント対応や問い合わせのような、予定外の割り込みが仕事の中心になるチームにはカンバンが、まとまった機能開発にはスクラムが向くとされます。両者を組み合わせる運用も一般的です。
落とし穴として最も多いのは、イベントだけを輸入した「形だけスクラム」です。デイリーが進捗報告会になっている、レビューに本物のステークホルダーが来ない、レトロスペクティブの決定事項が実行されない、スプリント中に割り込みが常態化している — いずれも検査と適応が死んでいるサインです。またスクラムマスターを「議事進行係」や「開発者との兼任」で薄めると、組織側の障害（採用、権限、他部署との調整）に手がつかず、チームの改善が頭打ちになります。スクラムはフレームワークの導入自体は簡単ですが、それが暴き出した問題に組織が向き合えるかどうかで成否が分かれます。
試問
スクラムでは、2週間ほどのスプリントの終わりに2つの場を持ちます。「スプリントレビュー」は、できた動くものを関係者に見せて、何を作るか（プロダクトの方向）を見直す場。「レトロスペクティブ（ふりかえり）」は、チーム自身の働き方（どう作るか）を見直す場です。スプリントの終わりに出てきた8つの気づきを、どちらの場で扱うかで分けます。
スプリントの終わりに出た8つの気づきを、レビュー（何を作るか）で扱うものと、ふりかえり（どう作るか）で扱うものに仕分けよ
項目を選んでから、入れる箱を選びます