スプリントとは？スクラム開発の進め方やイベントを初心者向けにわかりやすく解説【図解付き】スプリントとは

はじめに

スクラムについて学んでいると、必ず登場するのがスプリントという言葉です。

スプリントは、スクラムにおける仕事の基本的な周期です。

しかし、初めて学ぶ方にとっては、

• スプリントは単なる短期間の開発作業なのか
• 何週間で実施するのか
• スプリント中に計画を変更してよいのか
• 予定した作業が終わらなかったら失敗なのか
• スプリントのたびにリリースする必要があるのか
• イテレーションとは何が違うのか
• スプリントレビューと振り返りは何が違うのか

といった点が分かりにくいのではないでしょうか。

スプリントを一言で表すと、

「短い期間で価値のある成果を作り、確認と改善を行うスクラムの基本サイクル」

です。

スプリントは、プログラムを開発する時間だけを指すものではありません。

スプリントプランニング、デイリースクラム、開発作業、スプリントレビュー、スプリントレトロスペクティブを含む、スクラムの一連のサイクル全体を指します。

この記事では、スプリントの意味や期間、基本的な流れ、スプリントゴール、途中変更の考え方、イテレーションとの違いについて、会話を中心に初心者向けにわかりやすく解説します。

スプリントとは？

スプリントは、スクラムで価値のあることかを作るために設ける一定の短い期間だよ。

短期間でプログラムを開発すること？

開発だけではないよ。計画、開発、日々の確認、成果の確認、仕事の進め方の改善までを含む一つのサイクルなんだ。

スプリントは、スクラムにおけるすべての活動をまとめる入れ物のようなものです。

一つのスプリントには、次のイベントが含まれます。

• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

さらに、プログラミング、設計、テスト、調査など、成果を作るために必要な活動もスプリントの中で行います。

スプリント開始
    ↓
スプリントプランニング
    ↓
開発・設計・テスト
    ↓
デイリースクラムで日々調整
    ↓
スプリントレビュー
    ↓
スプリントレトロスペクティブ
    ↓
次のスプリントへ

スプリントは、作業期間ではなく、計画から改善までを含む一つの周期なんだね。

その理解が大切だよ。

スプリントを料理の試作で例えてみよう

レストランで新しいカレーを開発する場合を考えてみよう。

完成まで半年かけて、一度も試食せずに新しいカレーを作ったとします。

半年後に客へ提供したところ、

• 辛すぎる
• 量が多すぎる
• 提供に時間がかかる
• 想定した客層に合わない

と分かったら、大きな手直しが必要です。

そこで、1週間ごとに試作品を作ります。

1回目の試作

基本となる味を作り、試食してもらいます。

2回目の試作

辛さを調整し、調理時間を短くします。

3回目の試作

盛り付けや量を改善します。

4回目の試作

実際の客へ提供できる品質へ仕上げます。

この1週間ごとの試作期間が、スプリントのイメージです。

短い期間で実際に作り、反応を次の試作へ生かすんだね。

そう。遠い未来を予想するだけでなく、実際の成果から学ぶのがポイントだよ。

スプリントの期間はどのくらい？

スプリントの期間は、1か月以内です。

実際の開発現場では、次のような期間が使われます。

• 1週間
• 2週間
• 3週間
• 4週間

特に、1週間または2週間のスプリントを採用するチームがよく見られます。

ただし、短ければ短いほど必ずよいわけではありません。

なぜ1か月以内なの？

期間が長すぎると、目標が合っているか確認するまでに時間がかかるからだよ。

スプリントが長いほど、次のようなリスクが大きくなります。

• 要件や市場が変化する
• 作業量の予測が外れる
• 間違った方向へ進み続ける
• 問題の発見が遅れる
• スプリントゴールが曖昧になる

短い期間で定期的に検査することで、こうしたリスクを抑えます。

スプリントの期間は毎回変えてよい？

忙しいときは3週間、作業が少ないときは1週間にしてもいい？

基本的には、同じ長さを継続して使う方がよいよ。

スプリントの長さを一定にすると、チームに一定のリズムが生まれます。

また、過去の実績と比較しやすくなり、今後の作業量も予測しやすくなります。

例えば、2週間スプリントを続けていれば、

• 過去の平均的な完成量
• スプリントごとの問題
• チームの改善傾向
• ベロシティの変化

などを確認しやすくなります。

状況に応じてスプリント期間そのものを見直すことはできますが、毎回の作業量に合わせて伸ばしたり縮めたりするものではありません。

スプリントの目的

スプリントの目的は、単に決められた作業を消化することではありません。

スプリントでは、プロダクトゴールへ近づく価値のあるインクリメントを作ることを目指します。

重要なのは、次の3点です。

1. 短期間で利用可能な成果を作る
2. 成果や進捗を検査する
3. 確認した結果に合わせて適応する

作業一覧をすべて終わらせることが目的ではないの？

作業を終わらせることは大切だけれど、最も重要なのはスプリントゴールへ近づき、価値のある成果を作ることだよ。

スプリントゴールとは？

スプリントゴールとは、そのスプリントで達成したい一つの目的です。

例えば、ECサイトを開発している場合、次のようなスプリントゴールが考えられます。

• 利用者が商品名から商品を検索できるようにする
• 会員が過去の注文履歴を確認できるようにする
• スマートフォンで商品を購入しやすくする
• 決済処理のエラーを減らす
• 商品画面の表示速度を改善する

「検索画面を作る」「テストをする」ではだめなの？

それらは作業内容だね。スプリントゴールは、作業によってどのような価値や状態を実現したいのかを表すんだ。

作業を並べただけの例

• 検索画面を作る
• 検索用APIを作る
• テストをする

スプリントゴールの例

「利用者が商品名から目的の商品を見つけられるようにする」

作業内容が途中で変化しても、スプリントゴールが明確であれば、別の方法を検討できます。

スプリントゴールが必要な理由

スプリントゴールには、次の役割があります。

• チームが同じ目的へ集中できる
• 作業の優先順位を判断できる
• 途中で問題が起きたときに計画を調整できる
• 個別作業ではなく成果の価値を意識できる
• スプリントが成功したかを確認しやすくなる

例えば、検索機能の一部に想定以上の時間がかかった場合でも、ゴールが「商品を見つけられるようにする」であれば、実現方法を簡略化するなどの判断ができます。

スプリントプランニングとは？

スプリントプランニングは、スプリントの開始時に行う計画です。

スクラムチーム全体で、主に次の3点を話し合います。

1. なぜ今回のスプリントに価値があるのか
2. 今回のスプリントで何を完成させるのか
3. 選んだ項目をどのように完成させるのか

なぜ価値があるのかを考える

まず、今回のスプリントで達成したいスプリントゴールを決めます。

単に作業を選ぶのではなく、その作業が利用者やプロダクトへどのような価値をもたらすかを確認します。

何を完成させるのかを選ぶ

プロダクトバックログから、今回のスプリントで取り組む項目を選びます。

選ぶときは、次の情報を考慮します。

• 優先順位
• 過去の実績
• チームの人数
• 休暇や会議の予定
• 技術的な難しさ
• 完成の定義
• スプリントの期間

どのように完成させるかを考える

開発者は、選んだプロダクトバックログ項目を完成させるための計画を考えます。

例えば、次のように作業を分けます。

• 画面を設計する
• データベースを変更する
• APIを作成する
• 自動テストを追加する
• セキュリティを確認する
• 利用手順を更新する

この計画は、スプリント中に新しいことが分かれば調整できます。

スプリントバックログとは？

スプリントバックログは、スプリントで行う仕事の計画です。

次の3つで構成されます。

• スプリントゴール
• 今回選んだプロダクトバックログ項目
• それらを完成させるための計画

スプリントバックログは、プロダクトオーナーが作るの？

開発者が自分たちの作業計画として管理するよ。

プロダクトオーナーは、プロダクトバックログの優先順位や価値について説明します。

しかし、どのように成果を完成させるかは、専門知識を持つ開発者が計画します。

スプリント中に行うこと

スプリント中には、インクリメントを作るために必要なさまざまな活動を行います。

例えば、システム開発では次の活動が含まれます。

• 要件の詳細確認
• 設計
• プログラミング
• コードレビュー
• テスト
• 不具合修正
• セキュリティ確認
• ドキュメント更新
• リリース準備

設計スプリント、開発スプリント、テストスプリントのように分けるの？

基本的には、一つのスプリント内で利用可能な成果を完成させるために必要な活動を行うよ。

例えば、

• 1回目のスプリントは設計だけ
• 2回目はプログラミングだけ
• 3回目はテストだけ

と分けると、利用可能な成果を確認できるまでに長い時間がかかります。

スクラムでは、機能を小さく分け、各スプリントの中で設計からテストまで行うことが基本です。

デイリースクラムとは？

デイリースクラムは、開発者がスプリントゴールへ向けた進捗を確認し、今後の作業計画を調整するイベントです。

毎日、15分で実施します。

主な目的は次のとおりです。

• スプリントゴールへ近づいているか確認する
• 作業上の問題を共有する
• 今日から次回までの計画を調整する
• 協力が必要な作業を確認する

上司へ進捗を報告する会議？

違うよ。開発者が自分たちの計画を調整するためのイベントだよ。

デイリースクラムで問題を詳しく解決する必要はありません。

15分で状況を確認し、詳しい相談が必要なメンバーだけが終了後に話し合うこともできます。

スプリント中に計画を変更してよい？

スプリントが始まったら、最初の計画を絶対に変えてはいけないの？

計画は変更できるよ。ただし、スプリントゴールを危険にさらしてはいけないんだ。

スプリント中に新しい情報が分かることは珍しくありません。

例えば、

• 想定していた技術が利用できない
• 利用者の要望を誤解していた
• 重大な不具合が見つかった
• 作業量が予想より多かった
• より簡単な実現方法が見つかった

といったことがあります。

その場合、開発者はスプリントバックログの作業計画を変更できます。

また、プロダクトオーナーと相談し、選択したプロダクトバックログ項目の範囲を調整することもあります。

計画を守ることより、ゴールを達成するために計画を調整することが大切なんだね。

そう。計画は目的ではなく、ゴールへ進むための手段だよ。

スプリント中に作業を追加してよい？

急な依頼や不具合が発生し、スプリント中に新しい作業を追加したくなる場合があります。

追加自体が完全に禁止されているわけではありません。

ただし、無計画に作業を追加すると、スプリントゴールに集中できなくなります。

新しい作業が発生したときは、次の点を確認します。

• スプリントゴールと関係があるか
• 今すぐ対応する必要があるか
• 現在の作業と入れ替えるべきか
• 次のスプリントへ回せないか
• チームの作業量を超えていないか

追加された分だけ、残業して全部終わらせるの？

それでは持続可能な働き方にならないよ。追加するなら、優先順位の低い作業を外すなどの調整も必要だね。

スプリント中にしてはいけないこと

スプリント中は、次の原則を守ります。

• スプリントゴールを危険にさらす変更をしない
• 品質を低下させない
• 新しく分かったことに応じて計画を調整する
• 必要に応じてプロダクトオーナーと作業範囲を再交渉する

特に注意したいのが、期限に間に合わせるために品質基準を下げることです。

例えば、

• テストを省略する
• コードレビューを行わない
• セキュリティ確認を飛ばす
• 未完成なのに完成として扱う

といった対応は避けなければなりません。

完成の定義を満たしていない成果は、インクリメントとして扱えません。

インクリメントとは？

インクリメントとは、スプリントによって作られた、利用可能な成果の積み重ねです。

例えば、ECサイトで商品検索機能を開発する場合、次の状態を満たす必要があります。

• 検索画面が利用できる
• 検索結果が正しく表示される
• 必要なテストが完了している
• 重大な不具合がない
• 既存機能を壊していない
• 完成の定義を満たしている

プログラムを書き終えればインクリメントになる？

書き終えただけでは不十分だよ。実際に利用できる品質であることが大切なんだ。

インクリメントは、過去のスプリントで作った成果へ追加されます。

第1スプリント：商品を表示できる
        ＋
第2スプリント：商品を検索できる
        ＋
第3スプリント：商品をカートへ入れられる
        ＋
第4スプリント：商品を購入できる

このように、スプリントを繰り返しながら、利用できるプロダクトを少しずつ成長させます。

完成の定義とは？

完成の定義とは、インクリメントが必要な品質を満たしているか判断するための共通基準です。

英語では、Definition of Doneと呼ばれます。

例えば、次のような基準があります。

• プログラムの実装が完了している
• コードレビューが完了している
• 自動テストに合格している
• 必要な動作確認が終わっている
• セキュリティ基準を満たしている
• 重大な不具合が残っていない
• ドキュメントが更新されている
• 本番環境へ公開できる状態になっている

完成の定義がなければ、人によって「完成」の意味が変わってしまいます。

完成の定義によって、チーム内で共通の品質基準を持てます。

スプリントレビューとは？

スプリントレビューは、スプリントで作った成果を関係者と確認し、今後の方向性を検討するイベントです。

主に次のことを行います。

• 完成したインクリメントを確認する
• スプリントゴールの達成状況を確認する
• 利用者や関係者から意見を得る
• 市場や業務環境の変化を確認する
• 次に優先すべきことを検討する
• プロダクトバックログを調整する

開発者が作ったものを発表する会議？

単なる発表会ではないよ。成果を材料に、今後どうするかを関係者と一緒に考える場なんだ。

例えば、商品検索機能を確認した利用者から、

• カテゴリでも検索したい
• 検索結果を価格順に並べたい
• 入力ミスを補正してほしい

といった意見が出るかもしれません。

これらをプロダクトバックログへ反映し、優先順位を検討します。

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

スプリントレトロスペクティブは、チームの仕事の進め方を振り返り、改善策を考えるイベントです。

日本語では、スプリント振り返りと呼ばれることもあります。

主に次の点を確認します。

• うまくいったこと
• 問題になったこと
• コミュニケーション
• 作業方法
• 使用したツール
• 品質
• 完成の定義
• 次のスプリントで改善すること

例えば、

• レビューを早めに行う
• 大きな作業を小さく分ける
• テストを自動化する
• デイリースクラムを簡潔にする
• 不明点を早い段階で確認する

といった改善策を決めます。

スプリントレビューとレトロスペクティブの違い

レビューも振り返りも、スプリントの最後に行うんだよね。何が違うの？

確認する対象が違うよ。

レビューは成果、レトロスペクティブは進め方なんだね。

スプリントはいつ終わる？

スプリントは、決められた期間が終了したときに終わります。

最初に選んだ作業がすべて終わったから、予定より早くスプリントを終了するというものではありません。

反対に、作業が終わらなかったからスプリント期間を延長することもありません。

作業が終わらなかったら、数日延長して完成させればいいのでは？

それをすると、一定の周期で検査するというスプリントの意味が弱くなるよ。

スプリント期間を延長せず、終了時点の事実を確認します。

• 何が完成したか
• なぜ完成しなかったか
• スプリントゴールは達成できたか
• 次に何を改善するか

未完成の項目は、自動的に次のスプリントへ入るわけではありません。

プロダクトバックログへ戻し、プロダクトオーナーがほかの項目と改めて優先順位を検討します。

予定した作業が終わらなければスプリントは失敗？

予定した項目が一つでも終わらなければ、スプリントは失敗なの？

必ずしもそうではないよ。まずスプリントゴールを達成できたかを考えよう。

スプリントプランニングで選んだ作業は、スプリント開始時点の予測です。

複雑な開発では、実際に作業を始めてから新しいことが分かります。

そのため、選んだすべての項目を完成できなかったとしても、スプリントゴールを達成し、価値のあるインクリメントを作れた場合があります。

一方、作業一覧をすべて完了していても、利用できる成果がなく、スプリントゴールも達成できていなければ、よいスプリントとは言いにくいでしょう。

未完成の作業はどうなる？

完成の定義を満たしていない作業は、完成したインクリメントとして扱えません。

未完成の項目はプロダクトバックログへ戻します。

その後、プロダクトオーナーが価値や必要性を見直します。

• 次のスプリントで再び選ぶ
• 内容を小さく分割する
• 優先順位を下げる
• 不要なら削除する
• 別の方法で実現する

次のスプリントへ自動的に持ち越すわけではないの？

そう。ほかの項目と同じように、改めて優先順位を判断するよ。

スプリントは中止できる？

スプリントは、途中で中止される場合があります。

ただし、簡単に中止するものではありません。

スプリントを中止できるのは、基本的にスプリントゴールが無効になった場合です。

例えば、次のような状況です。

• 法律の変更によって作る機能が不要になった
• 経営方針が大きく変わった
• 対象サービスの終了が決まった
• 競合や市場の変化でゴールの価値が失われた
• 技術的な前提が完全に崩れた

スプリントを中止する権限を持つのは、プロダクトオーナーです。

ただし、関係者やスクラムチームからの情報を踏まえて判断します。

作業が難しくて予定どおり進まない場合も中止するの？

単に難しい、遅れているという理由だけで中止するものではないよ。計画を調整しながらゴールを目指すんだ。

スプリントごとにリリースする必要はある？

スプリントが終わるたびに、本番環境へ公開しないといけないの？

必ずしも公開する必要はないよ。ただし、公開できる品質のインクリメントを作ることが大切なんだ。

スプリントの終了とリリースは別のものです。

完成したインクリメントは、スプリント終了を待たずにリリースすることもできます。

反対に、複数のスプリントで作った成果をまとめてリリースする場合もあります。

ただし、毎回未完成の状態しか作れず、長期間リリースできないのであれば、機能の分け方や完成の定義を見直す必要があります。

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

イテレーションとは、一般に反復や繰り返しを意味します。

アジャイル開発では、短い期間で計画・開発・確認を繰り返す周期をイテレーションと呼ぶことがあります。

スプリントも反復的な周期ですが、スクラムで定義された固有の用語です。

スプリントは、スクラムにおけるイテレーションのようなもの？

大まかなイメージは近いよ。ただし、スプリントにはスクラムで定められた目的やイベントがあるんだ。

スプリントとマイルストーンの違い

マイルストーンとは、プロジェクトにおける重要な節目や到達点です。

例えば、

• 要件定義完了
• 設計完了
• テスト開始
• 本番リリース
• 顧客承認

などがあります。

スプリントとフェーズの違い

ウォーターフォール開発では、要件定義、設計、実装、テストなどの工程をフェーズとして分けることがあります。

一方、スプリントでは、価値のある機能を完成させるために必要な活動を一つの期間内で行います。

スプリントとタイムボックスの関係

タイムボックスとは、作業やイベントに使える最大時間をあらかじめ決める考え方です。

スプリントもタイムボックスの一つです。

例えば、2週間のスプリントであれば、作業が終わらなくても2週間で終了します。

タイムボックスを設定することで、次の効果があります。

• 検査のタイミングが一定になる
• 作業を小さく分ける意識が生まれる
• 長時間かけすぎることを防ぐ
• 定期的に優先順位を見直せる
• チームに一定のリズムができる

終わるまで期間を延ばすのではなく、決めた時間の中で何を完成させるか考えるんだね。

スプリントとPDCAの違い

スプリントは、計画・実行・確認・改善を繰り返すため、PDCAサイクルと似ているように見えます。

両者には共通点がありますが、スプリントはスクラムの責任、イベント、作成物と結び付いた具体的な枠組みです。

スプリントとプロジェクトの違い

一つのスプリントが一つのプロジェクトなの？

通常は、一つのプロダクト開発で複数のスプリントを繰り返すよ。

プロジェクトは、特定の目的や期限を持つ活動全体を指します。

スプリントは、その中で繰り返される短い周期です。

プロジェクト・プロダクト開発
├─ スプリント1
├─ スプリント2
├─ スプリント3
├─ スプリント4
└─ スプリント5

ただし、スクラムは必ずしも一度限りのプロジェクトだけに使われるものではありません。

継続的に運営・改善するプロダクトでも、スプリントを繰り返します。

スプリントとバーンダウンチャートの関係

バーンダウンチャートは、スプリント中の残作業量がどのように減っているかを表すグラフです。

一般的には、次のように表します。

• 横軸：スプリントの経過日数
• 縦軸：残っている作業量

作業が完了すると、残作業量が減っていきます。

グラフが理想線より上なら、スプリントは失敗？

それだけでは判断できないよ。残作業量を確認する材料にはなるけれど、スプリントゴールや成果の品質も重要だよ。

バーンダウンチャートは、スプリントの状況を見えるようにする方法の一つです。

スクラムで必須の作成物ではありません。

スプリントとベロシティの関係

ベロシティとは、1回のスプリントで完成した作業量を表す指標です。

ストーリーポイントで見積もる場合は、完成したプロダクトバックログ項目のポイント合計をベロシティとすることがあります。

例えば、過去3回のベロシティが次のとおりだったとします。

平均的に22ポイント程度を完成できているため、次のスプリントで選ぶ作業量を考える参考になります。

ただし、ベロシティは次の目的には向いていません。

• 個人の人事評価
• チーム同士の能力比較
• 必ず達成すべきノルマ
• 数字を増やすための目標

チームごとにポイントの付け方が異なるため、単純比較はできません。

スプリントのメリット

早い段階で成果を確認できる

短い期間ごとに利用可能な成果を作るため、方向性が正しいか早く確認できます。

変化へ対応しやすい

一つのスプリントが終わるたびに、利用者の意見、市場の変化、新しく分かったことを次の計画へ反映できます。

問題を早く発見できる

デイリースクラムやスプリントレビューによって、問題が長期間放置される危険を減らせます。

大きな仕事を小さく考えられる

遠い将来の大きな計画だけでなく、次の短い期間に何を完成させるかへ集中できます。

優先順位を定期的に見直せる

スプリントごとに、次に価値の高い項目を選べます。

不要になった機能を作り続ける危険を減らせます。

継続的に仕事の進め方を改善できる

レトロスペクティブによって、成果だけでなくチームの働き方も改善できます。

スプリントのデメリット・注意点

計画やレビューの頻度が増える

短いスプリントでは、プランニング、レビュー、レトロスペクティブを頻繁に行います。

目的を理解せず形式的に実施すると、会議が増えただけに感じる可能性があります。

作業を小さく分ける技術が必要

大きな機能をそのままスプリントへ入れると、期間内に利用可能な成果を作れません。

利用者へ価値を提供できる単位へ小さく分ける必要があります。

急な作業追加でゴールを見失うことがある

スプリント中に次々と依頼を追加すると、チームがスプリントゴールへ集中できなくなります。

未完成作業の持越しが常態化する可能性がある

毎回多くの作業が終わらない場合、次のような問題が考えられます。

• 見積りが大きすぎる
• バックログ項目が大きすぎる
• 作業を選びすぎている
• 完成の定義が曖昧
• 割り込みが多い
• チーム外の承認待ちが多い

単に次のスプリントへ持ち越すのではなく、原因を振り返る必要があります。

スプリントをうまく進めるポイント

明確なスプリントゴールを設定する

作業の一覧ではなく、今回実現したい価値や状態を一文で表します。

作業を詰め込みすぎない

スプリントプランニングでは、過去の実績やメンバーの予定を考慮して、現実的な作業量を選びます。

バックログ項目を小さくする

一つの項目がスプリント全体を使うほど大きい場合、完成までの状況が分かりにくくなります。

数日程度で確認できる大きさへ分割すると、問題を発見しやすくなります。

問題を早く共有する

予定より遅れていることや、技術的な問題を隠すと、調整できる時間がなくなります。

デイリースクラムなどを通じて早めに共有します。

同時に始める作業を増やしすぎない

全員が別々の作業を始めると、どれも完成しない状態になりやすくなります。

新しい作業を始める前に、進行中の作業をチームで完成させることも重要です。

完成の定義を守る

期限が迫っていても、テストや品質確認を省略して完成扱いにしないようにします。

レトロスペクティブの改善策を実行する

毎回同じ問題を話し合うだけでは改善になりません。

次のスプリントで実行できる、小さく具体的な改善策を決めます。

スプリントが形骸化する例

スプリントを導入しても、次のような状態では効果を得にくくなります。

• 2週間ごとに区切っているだけ
• スプリントゴールがない
• 作業を上司が一方的に割り当てる
• デイリースクラムが進捗報告会になっている
• 未完成作業を自動的に持ち越す
• レビューで完成した画面を見せるだけ
• レトロスペクティブの改善策を実行しない
• テストを後のスプリントへ回す
• スプリント中に依頼を無制限に追加する
• ベロシティをノルマとして扱う

期間を短く区切るだけでは、スプリントとはいえないんだね。

そう。短い期間で成果を作り、検査と適応を行うことが大切だよ。

スプリントが向いている仕事

スプリントによる進め方は、次のような仕事に向いています。

• 最初にすべての要件を決められない
• 利用者の反応を見ながら改善したい
• 技術的な不確実性が高い
• 市場や業務環境が変化しやすい
• 成果を小さく分けて提供できる
• チームで継続的に改善できる

ソフトウェア開発のほか、新規事業、マーケティング施策、サービス改善などにも応用されることがあります。

スプリントが向いていない可能性がある仕事

次のような場合は、スプリントをそのまま適用しにくいことがあります。

• 作業手順が完全に決まっている
• 同じ作業を繰り返すだけである
• 成果を小さく分割できない
• 関係者から定期的な意見を得られない
• チームが計画を調整する権限を持っていない
• 変更を一切許容しない契約になっている
• 緊急作業が大半を占め、計画を維持できない

ただし、仕事全体にスクラムを適用できなくても、一部の改善活動に短い検査周期の考え方を取り入れることはできます。

ITパスポート・基本情報・応用情報の試験対策

スプリントは、スクラムやアジャイル開発に関する重要用語です。

ITパスポート、基本情報技術者試験、応用情報技術者試験では、スクラムの役割、イベント、作成物との関係を整理しておきましょう。

試験別に押さえたい内容

試験で覚えたい重要用語

試験問題で注目する表現

スプリントの流れを試験向けに整理

スプリントプランニング
        ↓
スプリントゴールと作業計画を決定
        ↓
開発・デイリースクラム
        ↓
インクリメントを作成
        ↓
スプリントレビュー
        ↓
レトロスペクティブ
        ↓
次のスプリント

試験では、レビューとレトロスペクティブの違いに注意すればいいね。

そう。レビューはプロダクト、レトロスペクティブは仕事の進め方と覚えよう。

よくある誤解

スプリントは開発作業だけを行う期間である

スプリントには、開発作業だけでなく、プランニング、デイリースクラム、レビュー、レトロスペクティブも含まれます。

計画から成果確認、改善までを含む一つのサイクルです。

スプリントは必ず2週間である

スクラムでは2週間に決まっているんだよね？

2週間はよく使われるけれど、必須ではないよ。

スプリントは1か月以内で設定します。

チームやプロダクトの状況に応じて、1週間、2週間、3週間、4週間などを選べます。

スプリント中は計画を変更してはいけない

スプリント中でも、新しく分かったことに応じて作業計画を変更できます。

重要なのは、スプリントゴールを守りながら計画を適応させることです。

最初に決めた作業はすべて完成させなければならない

選んだ作業は予測です。

すべての作業を終わらせることより、スプリントゴールを達成し、価値のあるインクリメントを作ることが重要です。

作業が終わらなければスプリントを延長する

スプリントはタイムボックスです。

作業が終わらなくても、決められた期間で終了します。

未完成の項目はプロダクトバックログへ戻し、優先順位を改めて判断します。

未完成の作業は自動的に次へ持ち越す

未完成の項目は、自動的に次のスプリントへ入るわけではありません。

必要性や優先順位を改めて確認します。

スプリントが終わるたびに必ずリリースする

各スプリントでは、リリース可能な品質のインクリメントを作ります。

ただし、スプリント終了時に必ず本番公開する必要はありません。

また、完成していればスプリント途中でリリースすることもできます。

スプリントレビューは成果発表会である

スプリントレビューは、完成したものを見せるだけの会議ではありません。

成果や市場の変化を確認し、ステークホルダーと今後の方向性を検討します。

レトロスペクティブは反省会である

レトロスペクティブは、失敗した人を探したり責任を追及したりする場ではありません。

チームの働き方を改善するためのイベントです。

スプリントゴールは作業一覧である

スプリントゴールは、タスクの一覧ではありません。

そのスプリントによって実現したい価値や状態を表します。

ベロシティを上げることがスプリントの目的である

ベロシティは、今後の作業量を予測するための参考情報です。

数字を上げること自体が目的ではありません。

ポイントを増やしても、利用者へ提供する価値が増えるとは限りません。

スプリントを短くすれば必ず開発が速くなる

短いスプリントは、早く確認する機会を増やします。

しかし、作業の分割ができていなかったり、イベントが非効率だったりすると、短くしただけでは成果が増えません。

スプリントの目的は、単純な速度向上ではなく、早く学習し適応することです。

まとめ

スプリントとは、短い期間で価値のある成果を作り、確認と改善を行うスクラムの基本サイクルです。

スプリントの期間は1か月以内で、1週間や2週間など、チームに合った一定の長さを設定します。

一つのスプリントには、次の活動が含まれます。

• スプリントプランニング
• デイリースクラム
• 成果を作るための開発活動
• スプリントレビュー
• スプリントレトロスペクティブ

スプリント開始時には、今回達成したい目的であるスプリントゴールを決めます。

スプリント中に新しいことが分かった場合は、スプリントゴールを守りながら作業計画を調整します。

最初に選んだ作業をすべて完了することだけが目的ではありません。

完成の定義を満たした利用可能なインクリメントを作り、実際の成果から学ぶことが重要です。

最後に要点を整理します。

スプリントは、短期間でプログラムを書くことだけではないんだね。

そう。計画、開発、日々の調整、成果の確認、仕事の改善までを含む一つのサイクルだよ。

最初にスプリントゴールを決めて、そのゴールを守りながら作業計画を調整するんだね。

そう。最初の計画を守り抜くことより、新しく分かったことに合わせて適応することが大切なんだ。

予定した作業が終わらなくても期間は延長せず、未完成の項目はバックログへ戻すんだね。

そう。そして、なぜ終わらなかったのかを振り返り、次のスプリントへ学びを生かすよ。

短く計画し、作って、見て、改善する。それを繰り返すのがスプリントなんだね。

バッチリ。その繰り返しによって、プロダクトとチームの両方を少しずつ成長させていくんだ。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。