スクラム

概要

スクラムは、アジャイル開発の価値観を実際のチーム運営に落とし込むための、最も広く使われているフレームワークです。「スプリント」と呼ばれる1〜4週間の固定長の反復を繰り返し、スプリントごとに動くソフトウェアの増分（インクリメント）を作り上げます。名前はラグビーのスクラムに由来し、工程ごとにバトンを渡すリレーではなく、チーム全員が一丸で押し進むイメージを表しています。

スクラムの全体像は驚くほどコンパクトで、公式の定義書「スクラムガイド」は十数ページしかありません。定義されているのは3つの責任（ロール）、5つのイベント、3つの作成物だけで、設計手法やテスト手法などの技術プラクティスは一切含まれません。「何を作るか」「どう作るか」はチームが経験から学んで決める — その学習のリズムと場を提供するのがスクラムの役割です。

軽量である代わりに、スクラムは「意図的に不完全」です。枠組みだけを与えて中身を埋めさせることで、チームが自分たちの問題を直視せざるを得なくする — スクラムがしばしば「問題を解決するのではなく、問題を見えるようにするフレームワーク」と呼ばれるのはこのためです。

なぜ生まれたか

スクラムの土台にあるのは「経験主義（empiricism）」という考え方です。化学プラントのプロセス制御には、反応が完全に予測できるので手順を最初に定義できる「定義済みプロセス」と、予測できないので観察と調整を繰り返すしかない「経験的プロセス」の区別があります。ソフトウェア開発は後者なのに、前者のやり方（詳細な事前計画と工程管理）で管理されてきたことが失敗の根本原因だ — これがスクラムの提唱者ジェフ・サザーランドとケン・シュエイバーの診断でした。1990年代前半に実践が始まり、1995年に発表されたスクラムは、2001年のアジャイル宣言にも合流し、その後最も普及した実装となります。

経験的プロセスを回すには3本の柱が要ります。現状が正しく見えること（透明性）、それを定期的に点検すること（検査）、点検結果に基づいて変えること（適応）です。スクラムの構成要素はすべてこの3本柱の装置として説明できます。作成物は透明性のため、イベントは検査と適応のため、ロールはそれらが機能する責任の所在をはっきりさせるためにあります。逆に言えば、形だけイベントをこなしても検査と適応が起きていなければ、スクラムをやっていることにはなりません。

詳細

3つのロール・5つのイベント・3つの作成物

スクラムチームは3つの責任で構成されます。「プロダクトオーナー」はプロダクトの価値の最大化に責任を持ち、何をどの順で作るかの一覧（プロダクトバックログ）を管理します。「開発者」は毎スプリントで実際にインクリメントを作ります。「スクラムマスター」はスクラムそのものが機能することに責任を持ち、チームの障害を取り除き、組織にスクラムを根づかせる役割です。進捗を管理する上司ではなく、プロセスの世話役である点が重要です。

作成物は3つ。プロダクト全体のやることリストである「プロダクトバックログ」、今スプリントでやると決めた分とその計画である「スプリントバックログ」、スプリントの成果である動く「インクリメント」です。それぞれに「何のためにあるか」を示す約束（プロダクトゴール、スプリントゴール、完成の定義）が紐づきます。特に「完成の定義」— 何をもって完成とみなすかの共通基準、たとえばテストが通りコードレビューを経てデプロイ可能であること — は、インクリメントの透明性を支える要です。

スプリントの流れ

イベントはすべて「スプリント」という固定長の器の中で回ります。スプリントの長さは1か月以内で固定し、期間中はスプリントゴールを危うくする変更を持ち込みません。この「固定」が重要で、締め切りが毎回同じリズムで来るからこそ、見積もりの精度やチームの実力（ベロシティ）が経験的に測れるようになります。

スプリントは「スプリントプランニング」で始まります。プロダクトバックログの上位項目から、今回のスプリントで何を達成するか（スプリントゴール）と、どの項目をどう実現するかを決めます。期間中は毎日15分の「デイリースクラム」で、ゴールへの進捗を検査し、その日の計画を調整します。上司への報告会ではなく、開発者自身のための再計画の場です。スプリント末には2つの検査が続きます。「スプリントレビュー」ではステークホルダーに動くインクリメントを見せ、プロダクトの方向性を検査してバックログに反映します。「スプリントレトロスペクティブ」ではプロダクトではなくプロセス — 人・関係・ツール・完成の定義 — を検査し、次のスプリントで試す改善を決めます。プロダクトへのフィードバックループとプロセスへのフィードバックループが、毎スプリント必ず1回ずつ回る構造です。

なお、スプリントごとに「リリース可能な」インクリメントを作るには技術的な裏付けが不可欠で、実務ではCI/CDによる自動ビルド・自動テスト・自動デプロイが事実上の前提になります。手作業のリリースに数日かかるチームでは、2週間スプリントは回りません。

カンバンとの違い、実務の落とし穴

スクラムとよく比較されるのがカンバンです。カンバンにはスプリントがなく、作業は一件ずつ流れ、代わりに「仕掛かり中の作業数（WIP）の上限」を設けて流れを最適化します。リズムを固定して学習するスクラム、流れを連続させて滞留を減らすカンバン、と性格が異なり、障害対応のような割り込み中心のチームにはカンバンが、まとまった機能開発にはスクラムが向くとされます。両者を組み合わせる運用も一般的です。

落とし穴として最も多いのは、イベントだけを輸入した「形だけスクラム」です。デイリーが進捗報告会になっている、レビューに本物のステークホルダーが来ない、レトロスペクティブの決定事項が実行されない、スプリント中に割り込みが常態化している — いずれも検査と適応が死んでいるサインです。またスクラムマスターを「議事進行係」や「開発者との兼任」で薄めると、組織側の障害（採用、権限、他部署との調整）に手がつかず、チームの改善が頭打ちになります。スクラムはフレームワークの導入自体は簡単ですが、それが暴き出した問題に組織が向き合えるかどうかで成否が分かれます。