スクラム開発の開発期間やスケジュール、納期は、スプリントごとの実績をもとに完了時期を予測しながら管理します。スプリントの設定、実績の計測、予測の更新を続けると、適切な運用で予測精度を高めながら完了時期を見通せます。
期間の決め方と納期の予測、ウォーターフォール型との違いと固定納期への対応は、発注側が押さえておきたい論点です。
▼全体ガイドの記事
・スクラム開発の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
スクラム開発における開発期間の考え方
スクラムでは、最初に全期間を逆算して固定する代わりに、実績をもとに完了時期を予測します。一方、ウォーターフォール型は、要件定義の段階で全工程の日程を決めます。
スクラムは開発全体を1〜4週間のスプリントに分け、動くもの（インクリメント）を完成させます。一定のリズムで価値を積み上げるため、その積み上げた実績が完了時期の予測の材料になります。
国内のアジャイル開発プロジェクトでは、約8割が8名以下の小規模チームで行われています。開発期間の半数は2〜4か月に収まり、中規模プロダクトの目安になります。ただし、2〜4か月は一つのプロダクトを立ち上げる初期開発の目安です。
スクラムは、リリース後も改善を続けるプロダクト運営にも向いています。そのため、初回リリースまでと、その後の改善サイクルを分けて考えます。初回は、MVP（Minimum Viable Product）までを短い期間で区切り、以降は四半期ごとにロードマップを見直します。
「固定期間の逆算」から「実績ベースの予測」への転換
期間の考え方は、スケジュール、スコープ（機能範囲）、コストのどれを固定するかで異なります。両方式は、固定するものが次のように異なります。
- ウォーターフォール型：機能範囲を固定して期間と費用を見積もる
- スクラム：チーム体制と期間を固定し、優先度の高い機能から作る
スクラムは、決めた期間とチームでどこまで価値を出せるかを高める考え方です。前提を共有せず納期を求めると、発注側と開発側の認識がずれます。
納期を固定することはできますが、その場合は納期に間に合う範囲へスコープを調整します。この交換条件は、最初に共有しておきます。
規模別に見た開発期間の目安
初回リリースまでの目安は、プロダクトの規模によって異なります。画面数や連携の複雑さを踏まえて、規模を判断します。
- 小規模：コア機能に絞ったMVP、画面数5〜10程度
- 中規模：業務システムや顧客向けWebアプリ、画面数20〜50程度
- 大規模：複数システム連携や複雑な業務ロジックを伴うもの
小規模は1〜2週間のスプリントを3〜6回ほど回し、1.5〜3か月が目安です。中規模は2週間スプリントを6〜10回程度回し、3〜5か月が現実的なラインです。
大規模では、初回リリースまで6か月以上かかることもあります。全機能を待たず、コア機能のMVPを先に出して、以降のスプリントで拡張できます。
この方法では、初回の価値提供までの期間をウォーターフォール型より大幅に短縮できます。期間は概算であり、最初の数スプリントでベロシティを測って確定します。
スプリントとタイムボックスによる期間設計
スクラムのスケジュールは、固定長の反復サイクルであるスプリントを基本単位に組み立てます。期間とイベントの時間配分は、開発のリズムや生産性を左右します。納期管理では、この二つが前提になります。
スプリント期間の設定（1〜4週間）
スプリントは「1か月以内」と決まった長さで、実務では1〜4週間が一般的です。行政分野のアジャイル導入事例でも、1週間か2週間が多く見られます。期間を短くするほど学習と改善のサイクルが速く回るので、期間ごとの特徴を比べて設定します。
- 1週間：毎週末にレビューと振り返りを行える
- 2週間：実務上バランスがよく、採用されやすい
- 3〜4週間：計画と実績のずれに気づくのが遅くなる傾向がある
3〜4週間では改善のリズムが生まれにくく、リスクが大きくなります。また、一度決めたスプリント長は、途中でむやみに変えないようにします。固定したリズムはベロシティを安定させ、納期予測の精度も高めます。
スクラムイベントのタイムボックス
各イベントには、会議が長引くのを防ぐ最大の制限時間「タイムボックス」があります。スプリント期間ごとの目安は、計画づくりの段階で組み込みます。
- デイリースクラム：スプリント長にかかわらず15分以内
- プランニング：1か月で最大8時間、2週間で最大4時間
- レビュー：1か月で最大4時間、2週間で最大2時間
- レトロスペクティブ：1か月で最大3時間、2週間で最大1.5時間
会議の時間も開発期間の一部です。会議を軽く見ると実装時間が圧迫され、計画した作業量を消化できなくなります。会議が長引いた場合は強制的に終わらせるなど、超過時のルールを決めておくことも推奨されます。
タスクは、1〜2日以内、おおむね4〜6時間程度で完了できる大きさに分けておきます。大きすぎるタスクは、最終日まで完了状況が見えない原因になります。
小さく分けておけば、デイリースクラムで進捗が明確になり、遅れの兆候も早く捉えられます。こうした分け方が、スプリント内の納期を守ることを支えます。
ベロシティとリリースプランニングによる納期予測
スクラムには、チームの実績データから完了時期を予測する仕組みがあります。ストーリーポイント、ベロシティ、リリースプランニングがその中心です。「スクラムは終わりが見えない」という見方は誤解で、実績を使えば完了時期を予測できます。
ストーリーポイントとベロシティの計測
スクラムでは、人日や人月で細かく見積もる代わりに、労力・複雑さ・不確実性を合わせたストーリーポイントで機能を相対評価します。
- 相対見積もり：機能同士の重さを比べて点数を付ける
- ベロシティ：1スプリントで消化したポイントの合計
たとえば、ログイン機能を3ポイント、商品検索機能を5ポイントと見積もります。「AよりBが2倍大変」といった相対比較は、正確な所要時間を当てるより、機能どうしの大まかな難しさを比べるほうが得意という性質を生かした方法です。
ベロシティの計測は、最初の2〜3スプリントを計測期間として行います。その後は、過去3スプリントの平均を次の計画量の基準にします。具体的には、平均が20ポイントなら、次のスプリントも20ポイント前後で計画します。
実績から次の作業量を決めることが、計画の精度を支えます。発注側は、最初の数スプリントでベロシティが安定するまで、全体の完了時期を断定的には約束できないと理解しておきます。
リリースプランニングによる完了予測
短期の計画だけでは全体の完了時期が見えず、要件が増え続けるスコープクリープの恐れもあります。そこで、リリース計画によってロードマップの全体像を示します。
- 残作業量：バックログに残る総ストーリーポイント
- 消化ペース：現在の平均ベロシティ
- 完了予測：残作業量を消化ペースで割って算出
たとえば、残ポイントが120、平均ベロシティが20なら、残りは約6スプリントです。2週間スプリントの場合、約12週間で完了する見込みです。
予測は、スプリントごとに更新します。そうすることで、進捗に応じた最新の完了の見通しを、関係者と共有し続けられます。
バーンダウンチャートは、縦軸に残作業量、横軸に時間（スプリント）を取り、作業がゼロへ向かう様子を示します。実績の線が理想線より上なら遅れ気味、下なら順調と判断できます。発注側も定例の場で見れば、専門用語に詳しくなくても進捗を把握できます。
ガントチャートが計画どおりかを確かめるのに対し、バーンダウンチャートは実績から完了を予測します。この違いに、スクラムの納期管理の特徴があります。
ウォーターフォール型との納期管理の違い
納期管理を理解するには、両方式を比べることが欠かせません。両方式は、リリース時期と変更への対応という二つの観点で考え方が異なります。その違いを知ることが、自社に合う手法を選ぶ材料になります。
一括リリースと継続的リリース
リリースの方法は、全工程の完了後にまとめて出す形と、スプリントごとに動くものを用意する形に分かれます。
- ウォーターフォール型：要件定義・設計・実装・テスト後に一括リリース
- スクラム：各スプリントで動くものを作り、いつでもリリースできる状態にする
ウォーターフォール型は全体像をつかみやすく、何がいつ完成するかを計画しやすい一方、最後まで動くものを得られません。途中で仕様の食い違いに気づくと、後戻りに大きなコストと遅延が伴います。これに対し、スクラムは変更を前提に、スプリントごとにインクリメントを完成させます。
スクラムなら、市場の状況などビジネスに合ったタイミングで機動的にリリースできます。たとえば、年末商戦に向けてコア機能だけを先に出すこともできます。
仕様変更への対応とスケジュールへの影響
仕様変更が納期に与える影響は、両方式で異なります。その違いは、変更の管理方法とスプリント中のルールに表れます。
- ウォーターフォール型：終盤の変更は設計のやり直しとなり、全体日程を遅らせる
- スクラム：新しい要求をバックログに加え、優先順位を付け直す
ウォーターフォール型では、要件確定後の変更を抑えるため、厳格な変更管理が必要です。スクラムでは、プロダクトオーナーが次のスプリントに入れるか、後回しにするかを判断します。
スクラムでも変更は何度でも自由に入れられるわけではなく、進行中のスプリントの作業内容は原則として変えず、次回以降に反映します。「進行中は固定、次回以降は柔軟」とすることで、変化への対応と短期的な集中を両立させます。ただし、変更を入れた分だけ別の機能の優先度が下がり、完了時期にも影響します。
固定納期との折り合いと遅延の防ぎ方
展示会、法改正対応、契約上の期限など、リリース日を動かせないケースは頻繁にあります。スクラムは変化を前提としますが、固定納期とも両立できます。
スコープ調整とトレードオフスライダー
固定納期では、期日に間に合わせるため、機能を削るか後回しにするかを決める必要があります。
- 固定する要素：品質・コスト・納期・スコープのうち優先するもの
- 調整する要素：優先順位を下げ、後のフェーズへ回す機能
- 納期後に行うこと：追加機能をスプリントで継続的に拡張する
たとえば、品質と納期を固定してスコープを柔軟にするなど、何を譲るかを関係者で合意しておきます。遅れそうなときも、優先度の低い機能を次のフェーズへ回せます。
スクラムでは、納期かスコープのどちらかを調整できる前提で計画します。開始時に優先順位をそろえておく方法が、トレードオフスライダーです。
納期を守る代わりにスコープを変えるという合意を、発注側と開発側で最初に共有しておきます。そのうえで、MVP（必須機能の最小セット）を定め、追加機能は納期後に拡張します。
遅延の兆候を早期に捉える仕組み
スクラムには、遅延の兆候を早期に捉える仕組みが標準で備わっています。レビューとチャートで、計画との差を確認できます。
- 実績を測る：最初の2〜3スプリントでのベロシティ計測
- 進捗を見えるようにする：タスクの1〜2日単位への分割
- リスクを早く減らす：不確実な技術要素の早期検証（スパイク）
- 障害を取り除く：デイリースクラムでの共有と、スクラムマスターによる対応
ウォーターフォール型では、遅れが終盤のテスト工程で表面化し、手遅れになることがあります。一方、スクラムでは、スプリントごとのレビューで動くものを確かめられます。
バーンダウンチャートでも、残作業の進み方を見て、計画との差を2週間ごとに確認できます。3スプリント連続で計画を下回れば、遅延の可能性を察知できます。
早い段階で気づければ、スコープ調整や体制増強などの対策を取れます。実績に基づく予測と確認を続けることが、納期を見通す力につながります。
まとめ
期間と納期の管理では、スプリントとタイムボックス、ベロシティとリリース計画を押さえました。さらに、方式の違い、固定納期と遅延への対策も見てきました。
国内のアジャイル案件では、開発期間の半数が2〜4か月というデータが目安になります。ただし、正確な期間は、最初の数スプリントでベロシティを測ってから定めます。
固定納期の場合は、納期を守る代わりにスコープを調整すると合意し、MVPを明確にします。毎スプリントで進捗を確認すると、遅延の兆候を捉える助けになります。
スクラムでの開発を検討するなら、時間管理の前提を押さえたうえで、複数の開発会社に体制と進め方を相談してみてください。
▼全体ガイドの記事
・スクラム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。