スクラム開発の開発期間・スケジュール・納期について

スクラム開発は、アジャイル開発を代表するフレームワークとして、変化の激しい新規プロダクト開発やDX案件の現場で広く採用されています。最大の特徴は、「スプリント」と呼ばれる1〜4週間の短い反復サイクルを繰り返しながら、動くソフトウェア（インクリメント）を継続的に積み上げていく点にあります。要件をすべて固めてから一括で作るウォーターフォール型とは異なり、スクラムは「変化を前提とし、短いサイクルで検査と適応を繰り返しながら予測可能性を高めていく」という考え方を取ります。そのため、「スクラムで開発すると期間はどれくらいかかるのか」「納期はどう見積もればよいのか」「スプリントを回す方式で本当にスケジュールを管理できるのか」といった疑問は、発注を検討する企業担当者がまず直面する論点になります。

本記事では、スクラム開発における開発期間・スケジュール・納期に焦点を当て、スプリントとタイムボックスによる期間設計、ベロシティとストーリーポイントを用いた見積もり、リリースプランニングによる完了予測、ウォーターフォール型との納期管理の違い、そして「固定納期」との折り合いの付け方や遅延を防ぐ実践策までを、具体的な期間目安とともに体系的に解説します。スクラムは「いつ終わるか分からない」という誤解を持たれがちですが、適切に運用すれば、むしろ完了予測の精度を高められる手法です。最後までお読みいただくことで、スクラム特有の時間管理の考え方と、現実的な納期設定の判断軸が身に付くはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・スクラム開発の完全ガイド

スクラム開発における開発期間の考え方

スクラム開発の開発期間を理解するうえで最初に押さえるべきは、「あらかじめ全期間を固定して逆算する」という従来の発想とは前提が異なるという点です。ウォーターフォール型では、要件定義の段階で全工程のスケジュールを引き、ゴールまでの日数を確定させます。これに対してスクラムでは、開発全体を1〜4週間のスプリントに分割し、各スプリントの終わりに「動く成果物」を完成させながら、徐々に全体像を確定していきます。つまり「最初に決めた期間に向けて作る」のではなく、「一定のリズムで価値を積み上げ、その実績から完了時期を予測する」という構造になっています。国内のアジャイル開発プロジェクトのデータでは、約8割が8名以下の小規模チームで行われ、開発期間の半数が2〜4か月に収まっているとされており、これがスクラムで進める中規模プロダクトの一つの目安になります。

ただし、「2〜4か月」というのはあくまで一つのプロダクトを立ち上げる初期開発の目安であり、スクラムの本質はリリース後も継続的にスプリントを回し続けることにあります。スクラムは「作って終わり」のプロジェクトよりも、リリース後も改善を続けるプロダクト運営に向いた手法です。そのため、開発期間を考える際には「初回リリースまでの期間」と「その後の継続的な改善サイクル」を分けて捉える必要があります。初回リリース（MVP）までを最短化し、以降は四半期ごとにロードマップを見直しながらスプリントを継続する、という時間軸の設計が、スクラム開発における期間計画の基本形です。本記事では、まずスプリントの単位から順に、この時間設計の仕組みを具体的に見ていきます。

スクラムにおける期間の考え方が従来型と決定的に異なるのは、「スケジュール」「スコープ（機能範囲）」「コスト」のうち、何を固定し何を変動させるかという優先順位です。ウォーターフォール型は、スコープ（作る機能）を固定したうえで、それを実現するための期間と費用を見積もります。一方スクラムは、チームの体制（コスト）と一定のリズム（期間）を固定し、その枠の中で優先度の高い機能から作っていく方式です。言い換えれば、「決められた期間とチームで、どこまで価値を出せるか」を最大化する考え方です。この前提の違いを理解しないまま「スクラムなのに納期を約束してほしい」と求めると、双方の認識がかみ合わなくなります。スクラムでは納期そのものを固定することは可能ですが、その場合は「納期に間に合う範囲のスコープ」を調整するという交換条件が前提になる、という点を最初に共有しておくことが重要です。

スクラムで進める場合でも、プロダクトの規模感によって初回リリースまでの期間はおおよその目安があります。小規模なプロダクト（コア機能に絞ったMVP、画面数で5〜10程度）であれば、1〜2週間のスプリントを3〜6回ほど回す1.5〜3か月が目安です。中規模なプロダクト（業務システムや顧客向けWebアプリ、画面数20〜50程度）では、2週間スプリントを6〜10回程度回す3〜5か月が現実的なラインです。大規模なプロダクト（複数システム連携や複雑な業務ロジックを伴うもの）では、初回リリースまでに6か月以上を要することもありますが、スクラムの場合は全機能を待たずに「コア機能のMVPを早期にリリースし、以降のスプリントで拡張する」アプローチを取れるため、初回の価値提供までの期間はウォーターフォール型より大幅に短縮できるのが特徴です。これらはあくまで初期の概算であり、正確な期間は最初の数スプリントを回してチームの実力（ベロシティ）を計測したうえで確定します。

スプリントとタイムボックスによる期間設計

スクラム開発のスケジュールは、「スプリント」という固定長の反復サイクルを基本単位として組み立てられます。スプリントの長さをどう設定するか、そしてスプリント内の各イベントにどれだけの時間を割り当てるか（タイムボックス）が、開発リズムと生産性を大きく左右します。ここでは、スプリントの期間設定とタイムボックスの考え方を具体的な時間目安とともに解説します。これらはスクラム特有の時間管理の根幹であり、納期を語るうえで欠かせない前提知識です。

スプリントは「1か月以内」の決まった長さと定義されており、実務では1〜4週間に設定するのが一般的です。行政分野のアジャイル導入事例でも、1週間または2週間でスプリントを設定するケースが多く見られます。スプリント期間を決める際の基本原則は、「短ければ短いほど、学習サイクルと改善のループが速く回る」という点です。1週間スプリントであれば、毎週末に成果物のレビューと振り返りが行われ、軌道修正の機会が頻繁に訪れます。一方、スプリントを2週間を超える長さ（3〜4週間）に設定すると、カイゼンのリズムが生まれにくく、計画と実績のズレが発覚するのが遅くなるため、リスクが大きくなる傾向があります。実務上は2週間スプリントが最もバランスが良く採用されやすい設定です。重要なのは、一度決めたスプリント長はプロジェクト途中でむやみに変えないこと。固定したリズムを維持することで、チームのベロシティ（後述）が安定し、納期予測の精度が高まります。

スクラムにおける各イベント（会議）には、ダラダラと長引くことを防ぐために「タイムボックス（最大制限時間）」が厳密に設定されています。これはスケジュール管理の規律そのものであり、超過した場合は強制終了するといったルールを設けることが推奨されます。具体的な目安は、スプリント期間によって変わります。デイリースクラム（毎日の朝会）は、スプリント長にかかわらず15分以内です。スプリントプランニング（計画会議）は、1か月スプリントで最大8時間、2週間スプリントで最大4時間が目安です。スプリントレビュー（成果物の確認）は、1か月スプリントで最大4時間、2週間スプリントで最大2時間。スプリントレトロスペクティブ（振り返り）は、1か月スプリントで最大3時間、2週間スプリントで最大1.5時間が目安となります。これらの会議体に費やす時間も「開発期間」の一部としてスケジュールに織り込んでおく必要があります。会議時間を軽視すると、実装に充てられる時間が圧迫され、計画した作業量が消化できなくなるためです。

タスクの分割粒度も、スプリント内で作業を滞らせないための重要な時間設計です。理想は「1タスク＝1〜2日以内に完了できるサイズ（おおむね4〜6時間程度）」にまで細かくブレイクダウンすることです。タスクが大きすぎると、スプリントの最終日まで完了状況が見えず、終盤で「実は終わっていなかった」という事態を招きます。小さく分割しておくことで、デイリースクラムで日々の進捗が明確になり、遅れの兆候を早期に検知できます。この粒度管理が、スプリント単位での納期遵守を支える地味ながら決定的な実践です。

ベロシティとリリースプランニングによる納期予測

「スクラムは終わりが見えない」という批判は、実は誤解に基づいています。スクラムには、チームの実績データから完了時期を科学的に予測する仕組みが備わっており、それがベロシティとリリースプランニングです。ここでは、ストーリーポイントによる相対見積もり、ベロシティの計測方法、そしてそれらを使って「あと何週間で完了するか」を算出するリリースプランニングの実践を解説します。スクラム特有の納期予測の核心部分です。

スクラムでは、スケジュールを絶対的な「時間（人日・人月）」で精緻に見積もることはしません。代わりに、労力・複雑さ・不確実性を総合した「ストーリーポイント」という単位を用いて、各機能（プロダクトバックログアイテム）を相対的に見積もります。たとえば「ログイン機能を3ポイント、商品検索機能を5ポイント」というように、機能同士の相対的な重さで点数を付けていきます。人間は「これは正確に何時間かかるか」を当てるのは苦手ですが、「AよりBの方が2倍くらい大変だ」という相対比較は比較的得意である、という性質を利用した見積もり手法です。そして、チームが1スプリント内で実際に消化できたストーリーポイントの合計を「ベロシティ」と呼びます。このベロシティが、納期予測の基礎データになります。

ベロシティは最初から正確に分かるわけではありません。実務では、最初の2〜3スプリントを「計測期間」と割り切り、チームが実際にどれだけのポイントを消化できるかを観測します。その後は「過去3スプリントの平均ベロシティ」をもとに、次のスプリントで現実的にこなせる作業量（計画量）を決定していきます。たとえば過去3スプリントの平均ベロシティが20ポイントであれば、次のスプリントには20ポイント前後の作業を計画する、という具合です。この「実績に基づいて次の計画量を決める」というフィードバックループが、スクラムの計画精度を支えています。発注側にとって重要なのは、最初の数スプリントのベロシティが安定するまでは、全体の完了時期を断定的に約束しないという姿勢を理解しておくことです。

スクラムはスプリント単位の短期計画には強い一方で、対策をしなければプロジェクト全体の完了時期が見えにくくなり、要件が追加され続けて終わらない「スコープクリープ」に陥る危険があります。これを防ぐために、スプリント計画とは別に「リリース計画（リリースプランニング）」を作成し、全体のロードマップを可視化します。完了予測の算出方法はシンプルです。「プロダクトバックログに残っている総ストーリーポイント数」を「現在の平均ベロシティ」で割ることで、「あと何スプリント＝何週間で完了できそうか」という完了予測を定期的に算出できます。たとえば残ポイントが120、平均ベロシティが20であれば、残り約6スプリント＝2週間スプリントなら約12週間で完了見込み、という形です。この予測はスプリントごとに更新されるため、進捗の実態に応じて常に最新の完了見通しを関係者と共有できます。

この完了予測を視覚的に管理するのが「バーンダウンチャート」です。縦軸に残作業量（ポイント）、横軸に時間（スプリント）を取り、残作業が右肩下がりにゼロへ向かう様子をグラフ化します。実際の消化ペースが理想線より上にあれば「遅れ気味」、下にあれば「順調」と一目で判断できます。発注側はこのチャートを定例で確認することで、専門用語を細かく理解しなくても、プロジェクトが納期に向かって順調に進んでいるかを直感的に把握できます。ウォーターフォール型のガントチャートが「計画通りに進んでいるか」を見るのに対し、バーンダウンチャートは「実績から逆算した完了予測」を見るという違いがあり、これがスクラムの納期管理の特徴です。

ウォーターフォール型との納期管理の違い

スクラム開発の納期管理を正しく理解するには、ウォーターフォール型との対比が欠かせません。両者は「いつリリースするか」「変更にどう対応するか」という点で根本的に異なる思想を持っており、その違いを理解することが、自社のプロジェクトにどちらが適しているかを判断する材料になります。ここでは、リリースのタイミングと変更対応という2つの観点から、両者の納期管理の違いを掘り下げます。

ウォーターフォール開発では、最初にガントチャート等で全体スケジュールとゴールを固定し、要件定義・設計・実装・テストという全工程が完了した最後に一括でリリースします。そのため進捗の全体像は把握しやすく、「いつ何が完成するか」という計画が立てやすい反面、最後のリリースまで動くものが手に入らないという弱点があります。途中で「実は仕様が違った」と気づいても、後戻りには莫大なコストと遅延が伴います。一方スクラム開発では、変更を前提としているため、スプリントごとに「動く成果物（インクリメント）」を完成させ、いつでもリリース可能な状態を作り続けます。これにより、プロダクトをビジネスの最適なタイミング（市場の波）に合わせて機動的にリリースできる強みが生まれます。たとえば「年末商戦に間に合わせるため、コア機能だけ先に出す」といった柔軟なリリース戦略を取れるのは、継続的リリースを前提とするスクラムならではの利点です。

納期に対する仕様変更の影響も、両手法で大きく異なります。ウォーターフォール型では、要件を確定してから作るため、終盤での仕様変更は設計のやり直しを伴い、スケジュール全体を後ろにずらす要因になります。だからこそ、変更を抑制する厳格な変更管理プロセスが必要になります。スクラム型では、仕様変更はむしろ織り込み済みです。新しい要求が出てきたら、それをプロダクトバックログに追加し、優先順位を付け直すだけです。次のスプリントで取り組むか、後回しにするかをプロダクトオーナーが判断します。ただし、これは「いくらでも変更できる」という意味ではありません。スプリントの実行中（進行中のスプリント）には、原則としてそのスプリントの作業内容は変更しない、というルールがあります。変更はあくまで「次のスプリント以降」に反映するのが基本です。この「進行中は固定、次回以降は柔軟」という仕組みが、変化への対応力と短期的な集中の両立を可能にしています。発注側は、変更を出すこと自体は歓迎されるが、その分どこかの機能の優先度が下がる（＝全体の完了時期に影響する）というトレードオフを理解しておく必要があります。

固定納期との折り合いと遅延の防ぎ方

実際のビジネスでは、「リリース日が絶対に動かせない」という固定納期のケースは頻繁にあります。展示会、法改正対応、契約上の期限などがその典型です。スクラムは変化を前提とする手法ですが、固定納期とまったく相容れないわけではありません。むしろ、固定納期を守るための現実的な仕組みを持っています。ここでは、固定納期とスクラムを両立させる考え方と、遅延を未然に防ぐための実践策を解説します。

スクラムは、そもそも「スコープ（機能要件）」か「納期」のいずれかが調整可能であるという前提で成り立っています。したがって、納期を固定する場合に必要になるのは、「この納期に間に合わせるために、どの機能を削る（後回しにする）か」というスコープ調整の議論です。ここで有効なのが、品質・コスト・納期・スコープといった要素のうち、何を優先し何を譲るかをプロジェクト開始時に合意しておく「トレードオフスライダー」という手法です。たとえば「納期は絶対固定、品質も妥協できない、その代わりスコープは柔軟に調整する」という優先順位を関係者全員で握っておけば、終盤で「間に合いそうにない」となったときに、感情的な対立ではなく「では優先度の低い機能Cを次フェーズに回そう」という建設的な判断ができます。固定納期のプロジェクトでスクラムを成功させる鍵は、納期を死守する代わりにスコープを変動させるという合意を、発注側と開発側が最初に共有しておくことに尽きます。MVP（必須機能の最小セット）を明確に定義し、それだけは確実に納期内で仕上げ、追加機能は納期後のスプリントで継続的に拡張する、という段階的アプローチが定石です。

スクラムの大きな利点は、遅延の兆候を早期に検知できる仕組みが標準で組み込まれている点です。ウォーターフォール型では、遅れが表面化するのが終盤のテスト工程になりがちで、気づいたときには手遅れということが起こります。スクラムでは、毎スプリントのレビューで動く成果物を確認し、バーンダウンチャートで残作業の消化ペースを可視化するため、計画と実績のズレが2週間ごとに必ず明らかになります。たとえば「3スプリント連続でベロシティが計画を下回っている」という状況が見えれば、納期に間に合わない可能性を早い段階で察知し、スコープ調整や体制増強などの手を打てます。具体的な予防策としては、(1)最初の2〜3スプリントでベロシティを確実に計測し、楽観的すぎる完了予測を避けること、(2)タスクを1〜2日粒度に分割して日々の進捗を可視化すること、(3)技術的に不確実な要素は早期のスプリントで検証（スパイク）して後半のリスクを減らすこと、(4)デイリースクラムで障害（インペディメント）を即座に共有し、スクラムマスターが速やかに除去すること、が挙げられます。これらの仕組みを着実に回すことで、スクラムは「終わりが見えない」どころか、むしろ予測可能性の高い納期管理を実現します。

まとめ

本記事では、スクラム開発の開発期間・スケジュール・納期について、スプリントとタイムボックスによる期間設計、ベロシティとリリースプランニングによる納期予測、ウォーターフォール型との納期管理の違い、そして固定納期との折り合いと遅延の防ぎ方までを体系的に解説しました。スクラムは「固定期間の逆算」ではなく「実績ベースの予測」で時間を管理する手法であり、1〜4週間のスプリントを基本単位に、ストーリーポイントとベロシティから「あと何週間で完了するか」を算出します。国内アジャイル案件の半数が2〜4か月で初回リリースに至るというデータが一つの目安ですが、正確な期間は最初の数スプリントでベロシティを計測してから確定するのが正しい進め方です。固定納期のプロジェクトでも、「納期を固定する代わりにスコープを調整する」という合意とMVPの明確化によって、スクラムは十分に対応できます。むしろ毎スプリントの可視化によって遅延の兆候を早期に捉えられる点は、ウォーターフォール型にはない大きな強みです。スクラムでの開発を検討される際は、こうした時間管理の前提を理解したうえで、複数の開発会社に体制と進め方を相談してみることをお勧めします。

▼全体ガイドの記事
・スクラム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。