アジャイル開発の期間は、反復の長さ、作る機能の範囲、チームの実績で変わるため、納期を話し合う前にこの3点を確認します。初回リリースの目安は、国内データで2〜4ヶ月です。
ウォーターフォール型と比べると、期間の捉え方や納期の決め方が大きく異なります。全体像は、下の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・アジャイル開発の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
アジャイル開発における「期間」の考え方
期間を理解するうえで要となるのは、ウォーターフォール型と時間の捉え方そのものが違う点です。ウォーターフォール型は、要件定義からリリースまで全工程を見積もり、開始時に計画を固定して「○月○日に完成」というゴールを置きます。
一方、アジャイルは1〜4週間の反復を単位にし、次の数週間で作るものを決めます。そのうえで、反復のたびに計画を状況に合わせて変えていきます。
そのため、期間は一本に固定された日程ではなく、反復を重ねて形づくられます。変化の激しい市場で、正解がまだわからないプロダクトに使われる方法です。
アジャイルは、スクラムやカンバンのほか、エクストリーム・プログラミング（XP）、リーンソフトウェア開発などを含む考え方です。共通点は、短い反復を繰り返し、動くソフトウェアを少しずつ成長させることです。
IPA（情報処理推進機構）の調査は、全体のロードマップが見えにくい特性を指摘しています。このため、期間の捉え方を切り替えられないと、「いつ終わるのか」と不満につながりがちです。ただし、ベロシティやリリースプランニングを使えば、アジャイルでも納期を予測できます。
イテレーション（反復）の長さの決め方
期間設計の基本単位は、イテレーション（反復）の長さです。スクラムでは「スプリント」、ほかの手法では「イテレーション」や「タイムボックス」と呼び、いずれも一定期間ごとに開発サイクルを区切ります。
一般的な反復は1〜4週間（1ヶ月以内）です。期間が短いほど、計画・開発・検証・改善の学習サイクルが速く回ります。
さらに、判断の誤りやコストのリスクを短い時間枠にとどめられます。たとえば、1週間スプリントなら、方向性を誤っても失う工数は最大1週間分です。
反復が2週間を超えると、改善のループが遅れ、チームにリズムが生まれにくいというアンチパターンも指摘されています。反復の長さは、目安として次のように分けられます。
- 1週間：新規プロダクトなど、不確実性が高く頻繁なフィードバックを得たい場合
- 2週間：方向性がある程度固まり、安定して開発を進めたい場合
国内でも1週間または2週間が最も採用されている設定です。また、東京都のアジャイル開発実践事例でも、スプリントは1週間または2週間です。
全体の開発期間の目安（国内データ）
IPAの国内実態調査では、アジャイル開発の半数が「2〜4ヶ月」の期間で行われています。関連して、次の2点があります。
- スプリント回数：1〜2週間の反復を4〜8回ほど重ね、初回リリースを目指します。
- 東京都の事例：2〜3ヶ月で成果が見込める小規模案件が対象で、IPAの調査と整合する内容です。
ここで押さえたいのは、2〜4ヶ月がプロジェクト全体の終わりを意味しない点です。アジャイルは初回リリース後も機能を追加・改善するため、この期間は、使えるプロダクトが初めて世に出るまでと捉えます。そのため、その後も開発投資が続く前提で、予算と体制を計画するのが現実的です。
適応的計画（ローリングウェーブ）によるスケジュールの組み方
アジャイルのスケジュールづくりでは、適応的計画（アダプティブプランニング）を使います。近い未来は具体的に、遠い未来は粗く計画し、反復のたびに先の計画を具体化して修正します。
プロジェクトマネジメントでは「ローリングウェーブ計画法」とも呼ばれ、計画の詳細化が時間とともに先へ進んでいくイメージで捉えられます。要求・開発・テストを短く反復して動くソフトウェアを育てるため、半年先や1年先までは詳細に決めません。
開発で得る学びやユーザーのフィードバックにより、当初の想定は変わります。そのため、変化を前提に計画することが、アジャイルのスケジュール管理の基本です。
IPAが示すアジャイルの3つのプロセスモデル
適応的計画は、型に沿って計画を更新していく進め方です。IPAは、リリースに向けた流れを3つのプロセスモデルに整理しています。
- モデル1（基本形態）：企画後、要求・開発・テストを反復し、適宜リリースする
- モデル2（アーキテクチャ先行型）：要求・設計・基盤開発を先行させ、機能群を反復開発する
- モデル3（テスト専用フェーズ型）：反復後、リリース直前に重点テストの期間を設ける
モデル1は、作るものが流動的な新規プロダクトに合います。一方、モデル2は、大規模または技術基盤が複雑な場合に適しています。
モデル3は金融や医療など、高い品質が求められる領域でよく採用されます。自社に近いモデルを開発会社と早めに決めておくと、全体日程の精度が上がります。
リリースプランニングによる全体像の把握
リリースプランニング（リリース計画）は、反復ごとの計画とは別に、プロジェクト全体のロードマップを描く作業です。全体の流れを先に押さえておくと、反復ごとの計画がどこへ向かうのかを関係者が把握しやすくなります。
- 見通しの共有：「いつ、何が、どこまでできるか」を関係者の間で同じ認識にする
- 完了時期の予測：機能総量を1反復で消化する量（ベロシティ）で割り、必要な反復回数と週数を見積もります。
- 目標との連動：「3ヶ月後の展示会までに最低限ここまで作る」「半期末までにこの機能群を出す」といった目標を開発進捗に結びつけます。
計画は固定の約束ではなく、反復ごとに実績をもとに更新します。最初の予測は仮説であり、数回の反復後に実際の開発ペースがわかると精度が上がります。そのため、継続的な更新によって、従来型より変化に強い納期管理を実現できます。
ベロシティによる納期予測の仕組み
「アジャイルは納期が読めない」という懸念には、ベロシティを使って実績から答えます。作業量は、時間や人日ではなく、ストーリーポイントという相対的な大きさで見積もる方法が広く使われます。
ストーリーポイントは、作業の労力・複雑さ・不確実性を、基準の作業と比べて数値化したものです。1反復で消化したポイントの合計を「ベロシティ（速度）」と呼びます。たとえば、過去3回が20・24・22ポイントなら、平均は約22ポイントです。
残作業の総ポイントを平均ベロシティで割ると、必要な反復回数が出ます。さらに、反復の長さを掛ければ、完了までの週数を予測できます。予測はチームの実績に基づき、過去数回のデータを使うため、反復を重ねるほど精度が高まります。
最初の数反復を「計測期間」と見る考え方
開始直後はベロシティが安定せず、納期予測には注意が必要です。チームの連携、開発環境の整備、対象領域への習熟に時間がかかるため、消化できるポイント数は反復ごとにばらつきます。最初の数反復は、次の2段階で扱います。
- 最初の2〜3反復：ベロシティを測り、予測は暫定値として扱う
- 3回程度の反復後：安定した平均値を使って納期予測を立て直す
発注者は契約直後に完成日の確約を求めがちですが、実績を測ってから納期を見通すほうが、信頼できる予測になります。計測期間なしに開発会社が確定日を断言する場合、希望的なウォーターフォール型見積もりの可能性があります。さらに、この見積もりには、後の手戻りリスクも含まれます。
バーンダウンチャートによる残作業の把握
バーンダウンチャートは、ベロシティとともに進捗や納期の管理を支えます。チャートは、次の3点で見ます。
- 残作業の推移：縦軸に残ストーリーポイント、横軸に反復の経過を置き、減少を右肩下がりの線で示します。
- 計画との差：理想線は期限内に終える目安で、実績線が理想線の上に続くと、想定より作業が進まず遅延の兆候になります。
- 早めの対応：遅れを早く知れるため、スコープや体制を見直す判断材料にできます。
ウォーターフォール型では遅れが終盤のテストで表面化し、手遅れになることがあります。一方で、アジャイルでは反復ごとに実態を確認できます。また、発注者もチャートを定期的に共有してもらえば、開発会社の報告を待たずにプロジェクトの状態を把握できます。
ウォーターフォール型との期間管理の違い
期間管理の違いを理解するには、ウォーターフォール型との比較が有効です。ウォーターフォール型は要件定義・設計・開発・テストを順に行い、最後に一括でリリースします。プロジェクト開始時に、全工程のガントチャートを引きます。
全体の日程は見通しやすく、いつ何が終わるかが一本の線でわかります。この点は、経営層や予算管理者に安心感を与えます。
一方、途中の要求変更には弱い方式です。設計後の変更は前工程に戻る作業を生み、コストが大きくなります。
アジャイルは全体ロードマップが見えにくいものの、反復ごとに動くソフトウェアの増分（インクリメント）を積み上げます。いつでもリリースできる状態を保ちながら、変更を取り込みます。どちらが優れているかではなく、要件の確定度や変更頻度など、プロジェクトの性質に応じて管理方法を選びます。
「スコープ固定」から「納期固定」への発想の転換
両方式の違いは、何を固定し、何を変動させるかです。固定する側が、両者でまったく逆になります。
- ウォーターフォール型：機能範囲（スコープ）を固定し、期間とコストを見積もる
- アジャイル型：期間と体制（コスト）を一定にし、優先機能から開発する
アジャイル型は、「納期固定・スコープ変動」で運用すると本質に合います。たとえば「3ヶ月・5人体制」を先に決め、その範囲で価値の高い機能から作ります。
問いは「全機能がいつ終わるか」から、「期間内に価値ある機能をどこまで作れるか」に変わります。この考えを受け入れられるかが、成功の分岐点です。
ハイブリッド型という現実的な選択肢
国内では、アジャイルかウォーターフォールかを択一で選ぶだけでなく、両方を組み合わせる場合も増えています。組み合わせ方は案件によって変わり、どの工程を先に固めるかが要になります。
- 進め方の例：要件定義や基本設計で骨格を固め、詳細設計以降をアジャイルで反復します。
- モデルとの関係：IPAのモデル2（アーキテクチャ先行型）にも通じ、基盤の予測可能性と機能開発の柔軟性を両立します。
- 適用される案件：官公庁の大規模システムや、予測可能性が重視される受託案件で現実的な選択になることがあります。
選ぶときは、要件の確定度や途中変更の見込み、必要な予測可能性を開発会社と整理します。手法を目的にせず、ビジネスゴールから選ぶのが基本です。
固定納期プロジェクトでのアジャイルの進め方
展示会や年度内のリリースなど、動かせない納期がある案件にもアジャイルは適用できます。ただし、発注側と開発側は、納期かスコープ（機能要件）のどちらかを調整できる前提を共有しておく必要があります。
納期を動かせない場合は、機能のうち何を含め、何を後回しにするかを先に決めます。納期が動かない以上、調整の余地は機能の範囲にあるからです。
納期、全機能、品質をすべて固定すると、アジャイルかどうかに関わらず破綻しやすく、終盤の炎上を招きます。そのため、成功の鍵は、開始時に何を固定し、何を譲るかを合意しておくことです。
トレードオフスライダーによる優先順位の合意
トレードオフスライダーは、プロジェクト要素の優先順位を開始時に関係者全員で決める方法です。この決め方で、途中で判断が割れる場面を減らせます。
- 合意する要素：品質・コスト・納期・スコープのうち、何を優先し、何を調整するかを決めます。
- 納期と品質を優先する例：スコープを柔軟にし、事前合意に沿って低優先度の機能Cを次フェーズへ回せば、感情的な対立を避けられます。
- 合意がない場合：納期延長・品質低下・機能削減の選択で紛糾し、進行が止まることがあります。
発注者は、自社にとって譲れない要素を事前に整理します。なお、多くの場合、リリース日は固定し、初回の機能範囲には調整の余地があります。この優先順位を言葉にして開発会社と共有すると、固定納期プロジェクトの第一歩になります。
MVPの定義と必須機能の確保
MVP（Minimum Viable Product＝実用最小限の製品）は、固定納期でスコープを調整する具体策です。進め方は、先に作る範囲を決め、残りを後から足していく形になります。
- 必須機能の定義：ユーザーに価値を届ける最低限の機能を決め、納期内に仕上げます。
- 追加機能の管理：優先度を付けてバックログに並べ、MVP完成後の残り期間や次フェーズで拡張します。
- 段階的なリリース：MVPを先に確保し、余力があれば追加機能も作ります。遅れが出ても、動くMVPを手元に保てます。
ウォーターフォール型は全工程が終わるまで動くものがなく、直前に遅れが判明すると対応が限られます。これに対して、MVPを明確に定義し、優先度に応じてスコープを調整することが、固定納期のリスクを抑える備えになります。
まとめ
スクラムやカンバンなどの手法に共通する期間の考え方を、日程の組み方から納期の決め方まで見てきました。アジャイルの期間は、固定日程ではなく、1〜4週間の反復を重ねて形づくられます。
適応的計画では、近い未来を具体的に、遠い未来を粗く計画し、更新を続けます。ベロシティは実績から納期を予測し、バーンダウンチャートは遅れを早く知るのに役立ちます。
リリースプランニングは、ロードマップを関係者で共有する役割を持ちます。こうした仕組みによって、「納期が読めない」という懸念を抑え、従来型より変化に強い納期管理ができます。
国内案件の半数が2〜4ヶ月で初回リリースに至るというIPAのデータは、期間の目安になります。ただし、正確な見通しは、最初の数反復でベロシティを測ってから立てるものです。
固定納期でも、優先順位の合意と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を創業。