アジャイル スプリントとは？2週間が標準の理由と進め方｜期間・4イベント・IPA試験対策まで図解

アジャイル開発における スプリントとは、1〜4週間（最も一般的なのは2週間）の固定タイムボックスで「動くソフトウェア」を必ず1つ完成させる反復サイクル です。スクラムが定める唯一の「コンテナ」イベントであり、4つのスクラムイベントと日々の開発作業すべてがこの中に収まります（出典: Scrum Guide 2020 日本語版 PDF p.7）。

この記事で分かること:

• スプリントとイテレーションの違い、スクラムにおける位置づけ
• スプリント期間は「2週間」が標準とされる3つの理由と1週間派の現場根拠
• スプリントプランニング・デイリースクラム・レビュー・レトロスペクティブを正しく回す進め方
• IPA 基本情報技術者試験で問われる「スプリントのルール」の出題ポイント
• 現場で頻発する失敗4パターンと、明日から実行できる7つの実践ポイント

アジャイル スプリントとは｜1〜4週間で動くソフトを作る反復サイクル

アジャイル開発のスプリントは、スクラムガイドで「 1か月以内の決まった長さのイベントで、アイデアを価値に変換するためにスクラムで行われる作業はすべてスプリントで行われる 」と定義されています（Scrum Guide 2020 日本語版 PDF p.7「スプリント」）。

国内大手の解説でも同様で、株式会社モンスターラボは「スプリント期間は1週間、あるいは2週間で設定されることが多く、長くても1カ月以内におさめるのが基本」と整理しています。Atlassian も「最も一般的なスプリント期間は2週間」と公式ドキュメントで明言しています。

スプリントとイテレーション・スプリント開発の違い

混同されがちな3用語は次のように使い分けます。

用語	範囲	文脈
イテレーション	反復一般を指す広い用語	XP・FDD などスクラム以外のアジャイル手法でも使う
スプリント	スクラム固有の反復単位	スクラムを採用するチームはこの呼称に統一する
スプリント開発	「スプリントで進める開発」の俗称	SI 業界などで「アジャイル ≒ スプリント開発」と呼ばれることが多い

スクラムを採用するならスプリントと呼ぶのが Scrum Guide の流儀です。アジャイルとスクラムそのものの関係は アジャイル開発とスクラムの違いとは？図解でわかる導入成功5つのポイント で詳しく解説しています。

インクリメント・スプリントゴール・完成の定義（DoD）

スプリントを支える3つの中核概念は Scrum Guide 2020 で次のように整理されています。

• インクリメント: そのスプリントで作られた「動くプロダクト」。出荷可能な品質を満たす必要があり、過去のすべてのインクリメントに上乗せされる累積成果物です。
• スプリントゴール: スプリントバックログに対するコミットメント。「なぜこのスプリントに価値があるのか」を示す一文で、スクラムチームが計画作成時に定義します。
• 完成の定義（Definition of Done, DoD）: インクリメントに対するコミットメント。テスト完了・コードレビュー済・ステージング反映済など、満たすべき品質基準を成文化しておきます。

ここで生まれる最小限の価値ある機能は、新規事業の MVP の考え方と地続きです。詳しくは MVPとはなんの略？ビジネスでの意味と最小限の開発で成功する3ステップ を参照してください。

アジャイル スプリント期間の決め方｜2週間が標準とされる3つの理由

スクラムガイドが定める期間の上限は1か月、最も多く採用されるのが2週間です。なぜ2週間なのか、3つの理由が国内外の現場で共通して挙げられます。

理由1: 軌道修正の頻度とコストのバランスが最適

スプリント期間が長いほど計画通りに進めやすい一方、市場や顧客の変化を取り込む頻度が落ちます。Asana の解説では「1〜2週間という短いスプリント期間を採用しており、その最大の理由は軌道修正を迅速に行うため」と指摘されています。

理由2: スプリントゴール達成にちょうど良い作業量

1週間は計画とレビューのオーバーヘッド比率が高く開発時間が圧迫されやすい、3〜4週間はゴール達成までの軌道修正が遅れがち。2週間は「 有意義な作業を完成させつつ、フィードバックループを短く保つ 」最も収まりの良い長さです。

理由3: 4イベントの実施時間が現実的

スクラムガイドはイベントのタイムボックスを「1か月スプリント時の最大値」として定めています。2週間ならその半分が目安となり、開発者の負担と意思決定の質を両立できます。

期間別の使い分け早見表

期間	適したケース	注意点
1週間	SaaS の新規事業立ち上げ・要件変動が大きい・スクラム導入初期	計画とレビューに使う時間の比率が大きく、開発時間が圧迫されやすい
2週間	SaaS の標準・チームが安定稼働している・継続改善フェーズ	仕様変更が頻発するとゴール達成が崩れやすい
3〜4週間	大規模リファクタリングや基盤系の作業が中心	フィードバックループが遅く、軌道修正が間に合わないリスク

近年はアジャイルコーチの吉羽龍太郎氏も「1週間スプリント」を推奨しており、理由として「振り返り頻度が増えるので改善が速い」「計画精度が高まる」「失敗しても損失が1週間で済む」を挙げています。一方で1週間から2週間に変更して改善した実例もあり、 正解はチームの成熟度と扱う作業の粒度で決まる のが実態です。

スプリント期間を途中で変えてはいけない理由

スクラムガイドは「 スプリントの長さは一貫性を保つ 」ことを明記しています。期間が固定であることで、チームは「この期間内にどれだけ完了できるか（ベロシティ）」を計測でき、将来のリリース予測や見積もりの精度が高まります。年末年始や大型連休があるからといって1回だけ3週間にする運用は ベロシティを汚染するため推奨されません （Ryuzee.com「なぜスプリント期間は一定なんですか？」）。

技術選定の段階から運用を見据える場合は 【2026年版】SaaS開発で失敗しない言語・環境の選び方 も参考にしてください。

スプリントの進め方｜4つのスクラムイベント完全ガイド

スクラムガイドが規定する4つのイベントを順番に解説します。タイムボックスは「1か月スプリントの場合の最大値」で、2週間スプリントなら半分が目安です。

1. スプリントプランニング｜最大8時間（1か月）／4時間（2週間）

スプリントの開始イベント。Scrum Guide 2020 では次の3つのトピックを扱うと整理されました。

• Why（なぜ価値があるか）: スプリントゴールを定義する。
• What（何を扱うか）: プロダクトバックログから取り組むアイテムを選ぶ。
• How（どう実現するか）: 選んだアイテムを完成させるための具体的な計画を立てる。

2週間スプリントなら最大4時間が目安。SaaS の現場では「午前中にゴールと What を決め、午後に How を詰める」運用が多く見られます。

2. デイリースクラム｜毎日15分以内

開発者がスプリントゴールへの進捗を点検し、必要に応じて計画を適応する15分の同期イベント。2020年改訂で「3つの質問形式（昨日・今日・障害）」の明記が削除され、 形式はチームに委ねる ことが明確化されました（Scrum.org: What You Need to Know about the 2020 Scrum Guide）。

重要なのはスプリントゴールへの焦点であり、進捗報告会にしないことです。なお IPA 基本情報技術者試験では「毎日決まった時間に決まった場所で行い、開発チームの全員が前回からの進捗状況や今後の作業計画を共有するもの」をデイリースクラムとして問う問題が出題されています。

3. スプリントレビュー｜最大4時間（1か月）／2時間（2週間）

スプリント終了直前のイベント。ステークホルダーを招き、 実際に動くインクリメントを提示 して次に何をすべきかを検査・適応します。

スプリントレビューの進め方（実施手順）

1. 開発者が完成した機能をライブデモする（スライドのみの「進捗報告」はアンチパターン）
2. プロダクトオーナーが受け入れの可否を判断
3. ステークホルダーの質問・要望を受け、プロダクトバックログに新規アイテム or 優先度更新を反映
4. リリース時期や次スプリントの方向性を確認

「スプリントレビュー 進め方」で検索する人が最も知りたいのは、 スライド報告で済ませず動くものを見せて議論する場に変える具体策 です。録画して欠席者に共有する運用も有効です（アプレボ: スプリントレビューとは？やり方、参加者、レトロスペクティブとの違い）。

4. スプリントレトロスペクティブ｜最大3時間（1か月）／1.5時間（2週間）

スプリントの最後に行う「プロセスの振り返り」。スクラムガイドは目的を「 品質と効果を高める方法を計画する 」と定義しています。

代表的なフレームワークが KPT（Keep / Problem / Try）。

• Keep: 続けるべきうまくいったこと
• Problem: 障害となった事象
• Try: 次のスプリントで試す改善アクション

注意点は 個人を責めない こと。心理的安全性が損なわれると本質的な課題が出てこなくなります。導入時のよくある失敗パターンは アジャイル開発のメリット・デメリットとは？失敗事例に学ぶ成功への5ステップ も参考にしてください。

IPA 基本情報技術者試験｜スプリントのルールで問われるポイント

「アジャイル開発のスクラムにおけるスプリントのルールのうち適切なものはどれか」は IPA 基本情報技術者試験で頻出の出題形式です。受験生向けに、Scrum Guide 2020 を根拠とした「適切な記述」と「不適切な記述」の代表パターンを整理します。

適切とされる記述例

• スプリントは1か月以内の固定の長さで実施する
• スプリント期間中、スプリントゴールを脅かす変更は加えない
• スプリント終了時に動くインクリメントを完成させる
• デイリースクラムは毎日同じ時間・場所で15分行う
• スプリントレビューでステークホルダーへの提示と次回計画への反映を行う

不適切とされる記述例

• スプリント期間中に PO の判断で自由にスコープを追加できる（→ 例外は致命的バグ修正等のみ）
• スプリントの長さはチームの状況に応じて毎回変える（→ 一貫性が原則）
• デイリースクラムは管理者への進捗報告会である（→ 開発者同士の同期が目的）
• スプリントゴールを達成できなかった場合は強制的に次スプリントへ繰越す（→ プロダクトバックログに戻して優先度を再判断する）

出題傾向としては、 「変えない・固定する・コミットメントを守る」系が正解、「柔軟に変えられる・任意に決められる」系が誤り のパターンが多いです。試験対策として Scrum Guide 2020 日本語版 PDF（全13ページ）の通読が最短ルートです（Scrum Guide 2020 日本語版 PDF）。

体系的に学びたい場合は 【2026年版】アジャイル開発の本おすすめ7選｜初心者・スクラムマスター必読 も併せて参考にしてください。

スプリントを成功させる7つの実践ポイント

ここからは現場でスプリントを「形だけ」で終わらせないための7つの実践ポイントを整理します。

ポイント1: スプリントゴールを1文で言語化する

「○○の機能を作る」ではなく「 ユーザーが××できる状態にする 」とアウトカム（顧客価値）で書く。Scrum Guide 2020 が強調する「Why」の明確化に直結します。

ポイント2: 完成の定義（DoD）を全員で合意する

「テスト完了」「コードレビュー済」「ステージング反映済」など、 何を満たせば完成と呼ぶか の基準を成文化し、スプリントプランニング前に全員が同意していること。DoD が曖昧だとレビューで「動くと思っていたのに動かない」が頻発します。

ポイント3: バーンダウンチャートで進捗を毎日可視化する

残作業量を毎日記録し、理想線との乖離をデイリースクラムでチェック。乖離が大きいときは「スコープを縮める」か「ゴール自体を見直す」決断をプロダクトオーナーと早期に行います。

ポイント4: スプリント中の割り込みはプロダクトオーナーが防波堤になる

営業や経営層からの直接依頼が開発者に届く構造を作らない。プロダクトオーナーが優先順位を一元管理し、緊急でないものは次回スプリントのバックログに積む運用を徹底します。

ポイント5: キャパシティの10〜20%をバッファとして空ける

緊急バグ・技術的負債・突発調査などに備え、計画段階で意図的に余白を持たせる。100% 計画通りに埋めると、想定外の1件で全体が崩壊します。

ポイント6: 1スプリントで取り組むゴールは1つに絞る

複数ゴールを並列に立てると、レビュー時の意思決定が分散し、何も完成しないリスクが高まります。「複数の小ゴール」ではなく「1つのストーリーに紐づく一連の作業」として再編成するのが鉄則です。

ポイント7: レトロスペクティブで決めた Try を必ず次スプリントで実行する

振り返りで Try を出しても次回計画に組み込まれなければ意味がありません。 Try は必ずスプリントバックログに1アイテムとして登録 し、誰が・いつまでに実行するかを明示します。

要件定義の進め方については アジャイル開発の要件定義は不要？失敗を防ぐ設計書とドキュメント作成の3ステップ も参考になります。

スプリント運用でよくある失敗4パターンと対策

失敗1: スプリント中に仕様追加を受け入れてしまう

外部からの「ちょっとした追加」を受け入れ続けると、ゴール達成が崩壊します。Scrum Guide が定める原則は「 スプリント目標を脅かす変更は加えない 」。例外は致命的バグの修正など、ゴール達成に不可欠な微調整のみとし、プロダクトオーナーが判断します。

失敗2: デイリースクラムが報告会化する

開発者全員が PO/SM に向かって順番に話す「朝礼」状態は典型的なアンチパターン。 ゴール達成のために今日何をすべきかを開発者同士で同期する場 として運用し、ファシリテーターは状況に応じて切り替えます。

失敗3: レビューを社内クローズドで済ませる

実ユーザー・ステークホルダーを呼ばないレビューは「動くものを見せて検査する」という本来の目的を失います。デモは必ず録画して、参加できなかった関係者に共有するのも有効です。

失敗4: レトロスペクティブを省略する

「忙しいから今回は飛ばす」が継続的改善の最大の敵。短くてもよいので 必ず実施する こと。1週間スプリントで30分、2週間スプリントで45分など最低時間を決めておくと省略されにくくなります。

ウォーターフォールとの比較で導入可否を再検討したい場合は アジャイル開発・ウォーターフォール開発の違いを徹底比較！失敗しない選び方 を参照してください。

よくある質問

スプリントとイテレーションは違いますか？

「イテレーション」は反復一般を指す広い用語、「スプリント」はスクラム固有の用語です。XP や FDD などスクラム以外のアジャイル手法では「イテレーション」、スクラムを採用するなら「スプリント」と呼ぶのが Scrum Guide の流儀です。

スプリント期間中にメンバーが急に休んだ場合はどうすればいいですか？

属人化を防ぐためペアプログラミングやコードレビューで知識共有しておくことが前提です。進捗影響が出る場合はデイリースクラムで即共有し、プロダクトオーナーとスコープ再調整を行います。バッファ（ポイント5）を確保していれば吸収しやすくなります。

アジャイル開発のスプリントはどんなプロジェクトにも向いていますか？

不確実性が高く、市場フィードバックを受けながら要件を柔軟に変えていく SaaS や新規事業に最適です。一方、初めから全仕様が確定し変更が許されない基幹システムなどでは、ウォーターフォール開発の方が向いていることもあります。

スプリントゼロ（Sprint 0）は必要ですか？

Scrum Guide 2020 にはスプリントゼロという概念は存在しません。準備期間が必要な場合はプロジェクトの「ディスカバリーフェーズ」として別管理にするのが推奨されます。

1スプリントで完成しなかった作業はどうしますか？

未完成のアイテムはプロダクトバックログに戻し、再度優先度を判断します。「完成しなかったから次スプリントに自動繰越」ではなく、優先度が下がれば後回しにする柔軟性が重要です。

スプリントレビューとレトロスペクティブの違いは何ですか？

スプリントレビューは「 プロダクトの検査 」（何を作ったかをステークホルダーに見せて次に作るものを判断する場）、スプリントレトロスペクティブは「 プロセスの検査 」（どう作ったかをチーム内で振り返り改善する場）です。対象が「プロダクト」か「プロセス」かで明確に分かれます。

まとめ｜アジャイル スプリントは「動くものを2週間ごとに作る」反復サイクル

アジャイル開発のスプリントは、 1〜4週間（標準は2週間）の固定タイムボックスで動くインクリメントを必ず1つ完成させる反復サイクル であり、4つのスクラムイベントと日々の開発作業を内包する「コンテナ」です。

• スプリントの本質は固定期間内に動くインクリメントを完成させること
• 期間は2週間が標準、近年は1週間も推奨される。途中変更はベロシティを汚染するため避ける
• スプリントプランニング・デイリースクラム・レビュー・レトロスペクティブの4イベントを正しく回す
• IPA 基本情報技術者試験では「変えない・固定する」系の記述が正解パターン
• スプリントゴール1文化・DoD 合意・バッファ確保・Try の確実実行などの7ポイントが現場成功の鍵
• 仕様追加受け入れ・報告会化したデイリー・省略されたレトロは典型的な失敗パターン

公式ドキュメントは Scrum Guide 2020 日本語版 PDF で全文わずか13ページにまとまっています。チーム全員で1度は通読し、共通言語として認識を揃えるのが最短ルートです。より体系的に学びたい場合は 【2026年版】アジャイル開発の本おすすめ7選｜初心者・スクラムマスター必読 も併せてご活用ください。