アジャイル・スクラム開発の「スプリント」とは？意味とその特徴を解説

スプリントとは、アジャイル開発の代表的なフレームワークである「スクラム」における開発サイクルの単位で、1週間〜1ヶ月以内の固定された期間（タイムボックス）を指します。チームはスプリントごとに計画・開発・検査・改善を繰り返し、動作するプロダクトを段階的に完成へ近づけていきます。

項目	内容
スプリントとは	アジャイル開発（スクラム）において、計画・開発・検査・改善を繰り返す固定期間の開発サイクルの単位
期間の目安	1週間〜1ヶ月（スクラムガイドでは1ヶ月以内と定義。実務では1〜2週間で運用するチームが多い）
スプリント内のイベント	スプリントプランニング／デイリースクラム／スプリントレビュー／スプリントレトロスペクティブ
得られる効果	プロダクトゴールへ向けた方向修正のしやすさ、作業の複雑性の緩和、チームの継続的な改善

システム開発の手法のひとつであるアジャイル開発・スクラム開発においては、「スプリント」という単位で開発を繰り返します。
スプリントという言葉自体は聞いたことがあるものの、スプリント期間において具体的にどのような作業を行うのかについては知らない方も多いのではないでしょうか。
この記事では、アジャイル・スクラム開発におけるスプリントの意味や特徴、スプリント内で行われる各スクラムイベントと進め方についてご紹介します。

スプリントとは？アジャイル開発（スクラム）における開発サイクルの単位

アジャイル開発（新しいタブで開きます）の代表的なフレームワークであるスクラム開発（新しいタブで開きます）においては、1週間～1ヶ月程度の期間で繰り返し開発を進めていく「スプリント」と呼ばれる手法が採用されます。
スプリントは大きく、計画・実施・振り返りの3つのフェーズに分かれます。

まずスプリントを始める前に、開発したい内容を整理したプロダクトバックログから、優先度に応じて今回のスプリント中に開発する機能を選択します。これをスプリントにおける計画の段階、スプリントプランニングと呼びます。

スプリントプランニングを実施した後は、実施のフェーズです。スプリント期間内に実装・テストまでを実施し、スプリントの終了時点で動作するプロダクト（スクラム開発においては「インクリメント」と呼びます）となるように開発を行います。

スプリントの完了後には、振り返りです。スプリントレビューおよびスプリントレトロスペクティブを実施し、スプリントについての振り返りを行います。
振り返った内容や改善案は次回以降のスプリントに反映していきます。
この一連のスプリントの流れを繰り返すことで、段階的に開発を進めていくのがスクラム開発の大まかな流れです。

スクラムガイドにおけるスプリントの定義

スクラムの公式ガイドである「スクラムガイド（2020年版）」において、スプリントは1ヶ月以内の決まった長さの期間（タイムボックス）と定義されており、ひとつのスプリントが終了すると、すぐに次のスプリントが始まります。スクラムガイドではスプリントを「スクラムの心臓」と位置づけており、後述するスプリントプランニングやスプリントレビューといったすべてのスクラムイベントは、このスプリントの中で実施されます。

また、スプリント期間中は以下の原則を守ることとされています。

スプリントゴールの達成が危うくなるような変更を加えない
品質を低下させない
学習が進むにつれて、必要に応じてプロダクトオーナーとスコープを明確化し交渉し直す

なお、スプリントゴールが完全に意味をなさなくなった場合に限り、プロダクトオーナーの判断でスプリントを中止できます。ただしスプリントの中止はあくまで例外的な措置であり、通常は期間の途中で延長や短縮を行うことはありません。

スプリント期間（タイムボックス）の目安

スプリントの期間は、プロダクトの特性やチームの状況に応じて1週間〜1ヶ月の範囲で設定し、一度決めたら毎回同じ長さに固定して運用するのが基本です。

期間が短いほどフィードバックを得られるサイクルが速くなり、想定と異なる方向に進んでしまった場合のリスクを小さく抑えられます。一方で、スプリントが長いほど1回のスプリントで扱える作業量は増えるものの、方向修正の機会が減り、計画の不確実性も高まります。

実務では1〜2週間のスプリントで運用するチームが多く見られます。スクラムに慣れていないチームは、まず短めの期間から始めて改善サイクルの回数を増やし、レトロスペクティブの中でスプリント期間そのものの妥当性も見直していくと良いでしょう。

スプリント単位で開発を行う理由とは？

なぜスクラム開発においてはスプリントという考え方が採用されているのでしょうか。その理由は大きく以下の3つだと考えられます。

プロダクトゴールへ向けて取り組みの方向性を修正しやすくするため
作業の複雑性を緩和するため
チームの改善サイクルを回しやすくするため

順番に見ていきましょう。

プロダクトゴールへ向けて取り組みの方向性を修正しやすくするため

ひとつは、プロダクトゴールに向けて、開発の取り組みを修正しやすくするためです。
アジャイル開発においては、プロダクトゴールとして開発するプロダクトの目標を設定しますが、その目標に至るまでの道筋は必ずしも一つではありません。
一定期間開発を進めたところで、当初目指していた方法ではプロダクトは十分に価値を発揮できないことに気づく可能性もありますし、実際に開発された機能を確認したところ、当初想定していなかったものの、より優先度を上げて開発した方がいい機能が見えてくるケースもあります。
スプリント単位で開発・検証を行うことで、スプリント毎に方針を検討・修正し、プロダクトゴールに向けてより良い選択ができるようになります。
このような柔軟性の確保は、アジャイル開発・スクラム開発の大きなメリットです。

作業の複雑性を緩和するため

一般的に、複雑性が高い機能を開発する難易度は高く、複雑であればあるほど作業の遅延や品質の低下などのリスクが高まります。
これは大規模なウォーターフォール型開発（あらかじめシステム全体で必要な機能全てを事前に定義し、システムの全体を要件定義・実装・テスト・リリースのフェーズで一気に開発していく開発手法）でよく課題となるものであり、複雑性や規模が大きいシステムの開発は、その規模に比例して工数が必要となる傾向にあります。

そのような複雑性が高い機能も、スプリント単位で開発できるサイズに分割して開発を行うことにより、遅延や品質低下といったリスクを軽減させることができます。
スプリントという単位で開発しきるボリューム感に機能を分割することで、作業の複雑性を緩和し生産性や品質を向上させることができるのです。

チームの改善サイクルを回しやすくするため

スクラム開発のフレームワークにおいては、スプリント完了時点でスプリントレトロスペクティブとしてスプリントにおけるプロジェクト推進プロセスを振り返ります。
一定期間ごとにこのような振り返り作業を行うことで、チーム内で発生している課題や開発の進め方に関する問題などを改善しやすくなります。

上流から下流に段階的に開発を行うウォーターフォール型の開発においては、なかなか立ち止まって振り返りを行うというプロセスを入れるのは難しいといえます。開発途中でメンバーがプロジェクトの課題に気づいたとしても、それをフィードバックして進め方を改善するのは簡単ではありません。
一方で、アジャイル開発・スクラム開発においてはスプリント単位でチームの改善サイクルを回すことができるため、今回よりも次回のスプリント、次回よりもさらにその次のスプリントといったように、発展的にチームを高めていくことができるというメリットがあります。

スプリントの流れと4つのスクラムイベント

以下では、スプリントの流れについて詳細に紹介します。
スプリントの中では、スクラムガイドで定義された4つのスクラムイベント（スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブ）が実施されます。まずは、各イベントの目的とタイムボックスの目安を一覧で整理します。

イベント名	目的	タイムボックス目安※	詳細記事
スプリントプランニング	スプリントゴールと作業計画（スプリントバックログ）を決める	最大8時間	スクラムイベント全体の解説
デイリースクラム	進捗を検査し、その日の作業計画を調整する	毎日15分	スクラムイベント全体の解説
スプリントレビュー	インクリメントを検査し、ステークホルダーとフィードバックを交わす	最大4時間	スプリントレビューの解説
スプリントレトロスペクティブ	仕事の進め方を振り返り、次のスプリントでの改善策を決める	最大3時間	レトロスペクティブの解説
（参考）バックログリファインメント	プロダクトバックログの詳細化・見積・並べ替えを行う	随時（スプリント内で継続的に実施）	バックログリファインメントの解説

※タイムボックスは、スクラムガイドが示すスプリント期間が1ヶ月の場合の上限です。スプリント期間が短い場合は、通常これよりも短い時間で実施します（デイリースクラムはスプリント期間によらず15分です）。なお、バックログリファインメントはスクラムイベントではなく、スプリント内で継続的に行う活動として位置づけられています。

以下の内容はスクラム開発に関しての基本的な情報を前提に説明します。
スクラム開発についての情報をまずは確認したい場合は、以下の記事を参照してください。
参考その①：アジャイル開発におけるスクラム開発とは？メリットやプロジェクトの進め方を解説（新しいタブで開きます）
参考その②：スクラム開発の流れとスクラムイベントについて丁寧に解説（新しいタブで開きます）

スプリントプランニング

スプリントを開始するために、当該スプリントの計画を立てる「スプリントプランニング」を行います。
まず、プロダクトオーナー（新しいタブで開きます）はプロダクトバックログアイテムのうち重要度が高いものについて、プロダクトゴールに向かうためになぜその機能が必要であるのかを開発チームに共有します。
スクラムチームの意識を統一したうえで、スクラムチーム全体が協力して今回のスプリントではどのプロダクトバックログを実現するのか目標を明確化し、スプリントゴールとして定義します。

次に、選択したプロダクトバックログの実現に必要な開発タスクを詳細化し、定められたスプリント期間中に対応できる量であるか見積を行います。
プロダクトバックログのアイテムを 1日以内の小さな作業アイテムに分解していきます。今回のスプリントで対応すると決めたプロダクトバックログと、その実現のためのタスクをリスト化したセットを「スプリントバックログ」と呼びます。

スクラム開発のスプリントでどこまで開発するのかの見積は、過去のスプリントでチームがどの程度のタスクを消化できたかを基準に相対的に行う「相対見積」方式がとられる場合が多いです。
タスクの最小サイズは 1日で完了できるレベルにして、各タスクにサイズ（難易度や作業量）に応じたポイントを割り振ります。
たとえば前回のスプリントで合計 15ポイントのタスクが消化できているのであれば、今回も最大でタスクの合計が 15ポイントになる範囲までは対応ができそうだとわかります。
この時点で実績よりも大幅にポイントが超えてしまうようであればプロダクトバックログの項目を外したり、作業計画を見直したりすることでタスク量を調節します。

スプリントが 1ヶ月の場合、スプリントプランニングは最大で 8時間程度の時間をかけて実施します。
スプリント期間が短くなれば、この期間も短縮されます。

なお、スプリントプランニングを限られた時間で効果的に進めるには、事前にプロダクトバックログアイテムの内容を詳細化し、見積や優先順位を整理しておく「バックログリファインメント」が重要です。リファインメントの目的や進め方については、以下の記事で詳しく解説しています。

スプリントの実施（デイリースクラム）

スプリント期間中、開発チームはスプリントプランニングで定義したスプリントバックログの内容に基づき、作業を行います。
開発やテストなど実際にプロダクトの開発を進めていきます。

スプリント期間中は、「デイリースクラム」として、毎日 15分程度の時間でミーティングを行います。
デイリースクラムでは、スプリントゴール向けた進捗に問題がないか、問題があるとするとそれがどのようなものであり、どのように改善できるかについて確認します。
デイリースクラムに限らず、開発者は作業内容について問題がある場合は、都度スクラムチーム内で共有し、スプリントの計画について見直しを行うことも重要です。

スプリントレビュー

スプリント期間が完了したら、スプリントの成果を検査し今後の方針を決定するためにスプリントレビューを実施します。
スプリントレビューでは、スクラムチームからステークホルダーに対して作業の結果を示し、プロダクトゴールに向けた進捗状況について報告します。

スクラム開発では、スプリントの完了時には成果物（インクリメント）として操作やデモが可能なプロダクトやプロトタイプが出来上がっていることを重視します。
実際に動くものを見て、操作することでプロダクトゴールの妥当性や、開発中のプロダクトはユーザーの課題を本当に解決できるのかが判断しやすくなるためです。

報告方法はプロダクトの操作方法とその挙動のデモを実施したり、参加者が実際にプロダクトを操作したりなど様々です。
プロダクトの開発状況を踏まえ、参加者は今後の方針について話し合います。
スプリントレビューの結果を踏まえて、プロダクトバックログの調整を行い今後の開発内容や優先順位の見直しを行うことも検討します。
スプリントレビューの具体的なやり方や、形骸化させないためのポイントについては、以下の記事で詳しく解説しています。

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

スクラムチームは、スプリントレトロスペクティブとして今回のスプリントについて振り返りを行う機会を設けます。
レトロスペクティブの目的は、プロダクト開発において「品質と効果を向上させる⽅法を計画すること」です。
レトロスペクティブで整理された改善策を今後のスプリントに反映させていくことで、チームを発展的に高めていくことができます。

レトロスペクティブを通して、チームの非効率な作業やコミュニケーション不足、タスクの整理などを行うことで、開発効率の向上、ひいては開発するプロダクトの品質向上につながるでしょう。
スプリントレトロスペクティブについては以下の記事で詳細な解説を行っておりますので、併せてご覧ください。

スプリントを実施する上でのポイント

以下では、スプリントを実施する上でのポイントを3つ紹介します。

情報共有方法を検討する

アジャイル開発・スクラム開発の取り組みに限った話ではありませんが、チームとして作業を進めていく際に重要なのが情報共有方法の検討です。
スクラム開発においては、プロダクトバックログやスプリントバックログの共有に加え、開発者同士での作業の進捗状況確認やタスクリストの共有を密に行うことで、情報共有します。

チーム内でのコミュニケーション方法として、チャットツールやアジャイル開発向きのタスク管理・プロジェクト管理ツールの導入も有効な選択肢となるでしょう。
また、デイリースクラムの実施に加えて、それ以外の時間でもミーティング等のコミュニケーションを頻繁に行うことも重要です。

スクラム開発において、エンジニアはコーディングのみ、テストのみといった機能特化型の役割分担は行わず、「機能横断的になんでもやる」ことが求められます。
全員がなんでもできるメンバーでチームが組成できるのであれば何の問題もありませんが、現実的には開発者間でナレッジや習熟度に差があることがほとんどだと思いますので、モブプログラミング（複数人で同時に1つのプログラミングタスクを実施する）などで知見の共有や品質の維持をしていくことも必要になります。
当社でも、モブプログラミングやペアデザインなどの手法を取り入れて業務効率化やスキル・ナレッジの平準化につなげています。
参考記事：エンジニアとデザイナーによるペアデザインを用いたWeb開発とは。流れやメリットを大公開（新しいタブで開きます）

プラクティスを活用する

スプリントを実施する上では、いくつかのプラクティスが存在します。
たとえば、進捗確認方法として良く用いられるのが、バーンダウンチャートやバーンアップチャートです。
バーンダウンチャートは X軸に期間、Y軸に残工数を設定し、残工数を毎日プロットしていく方法です。
グラフの傾きが進捗の速さを、日々一定の進捗を達成した場合の理想線との差が進捗の進みや遅れの状況を表します。

バーンアップチャートは、同様のグラフを残工数ではなく完了工数により作成したものとなります。

また、スプリントプランニングの解説時にも触れましたが、見積時の考え方として「相対見積」というプラクティスも良く利用されます。
スプリントにおける見積を正確に実施することは難しいことから、大まかな見積を行うために相対見積を活用できます。
たとえば「プランニングポーカー」という相対見積の 1つの手法では、ある作業を行うためにかかる工数を基準として、各タスクがその作業の何倍の工数がかかるかを、メンバーで同時に言い合い、理由を会話することで見積を行います。
このように各々が同時に自分の意見を言うことで、他のメンバーの意見に関わらず、自分が思っていることを言い合えるというメリットがあります。
スプリントを進めていく上では先人たちが取り組みを行い、その有用性を確認しているこれらのプラクティスを活用することが有効となります。