アジャイル開発の開発期間・スケジュール・納期について

アジャイル開発は、変化の激しい市場環境のなかで「正解がわからない」プロダクトを作るための開発アプローチとして、いまや国内のシステム開発でも標準的な選択肢の一つになっています。スクラム、カンバン、エクストリーム・プログラミング（XP）、リーンソフトウェア開発といった複数の手法（プラクティス）を総称する考え方であり、共通するのは「短い反復（イテレーション）を繰り返しながら、動くソフトウェアを少しずつ成長させていく」という点です。しかし、ウォーターフォール型の開発に慣れた発注担当者からは、「アジャイルだと納期が読めないのではないか」「いつ完成するのか見通しが立たないのでは」という不安の声を多く聞きます。実際、IPA（情報処理推進機構）の調査では、アジャイル開発は全体のロードマップが見えにくいという特性が指摘されており、ここが従来型開発との最大の心理的なギャップになっています。

本記事では、アジャイル開発における開発期間・スケジュール・納期の考え方を、スクラムやカンバンといった個別手法の枠を超えた「アジャイル全般」の視点から体系的に解説します。イテレーションの長さの決め方、適応的計画（ローリングウェーブ計画）の進め方、ウォーターフォール型との期間管理の違い、そして「固定納期」のプロジェクトでアジャイルをどう成立させるかまで、具体的な数値とともにお伝えします。これからアジャイル開発の発注を検討されている方が、開発会社と納期について建設的な議論を行うための判断軸を得られる内容です。

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

▼全体ガイドの記事
・アジャイル開発の完全ガイド

アジャイル開発における「期間」の考え方

アジャイル開発における「期間」を理解するうえで最初に押さえておきたいのは、従来のウォーターフォール型開発とは時間の捉え方そのものが根本的に異なるという点です。ウォーターフォール型では、プロジェクト開始時に要件定義から設計、開発、テスト、リリースまでの全工程を見積もり、「○月○日に完成」という一本のゴールに向かって計画を固定します。これに対してアジャイル開発では、最初からすべての計画を確定させるのではなく、1〜4週間程度の短い反復（イテレーション）を単位として、その都度「次の数週間で何を作るか」を決め、計画を継続的に適応させていきます。つまりアジャイルの「期間」は、固定された一本のスケジュールではなく、反復の積み重ねによって動的に形成されていくものだと考える必要があります。この発想の転換ができていないと、「いつ終わるのか答えてくれない」という不満につながりがちですが、実際には後述するベロシティやリリースプランニングといった仕組みによって、アジャイルでも十分に納期を予測することが可能です。

アジャイル開発の期間設計の基本単位となるのが、イテレーション（反復）の長さです。スクラムでは「スプリント」、その他の手法でも「イテレーション」や「タイムボックス」と呼ばれますが、いずれも一定の固定された期間で開発のサイクルを区切るという点は共通しています。一般的に、この反復サイクルは1〜4週間（1ヶ月以内）の範囲で設定されます。期間を短くするほど、計画・開発・検証・改善という学習サイクルが速く回り、判断の誤りやコストのリスクを短い時間枠のなかに封じ込めることができます。たとえば1週間スプリントであれば、もし方向性が間違っていたとしても、失われるのは最大でも1週間分の工数にとどまります。一方で、反復期間を2週間を超える長さに設定すると、改善（カイゼン）のループが回り出すのが遅くなり、チームにリズムが生まれにくいというアンチパターンが指摘されています。実務では、新規プロダクトで不確実性が高く頻繁にフィードバックを得たい場合は1週間、ある程度方向性が固まり安定して開発を進めたい場合は2週間というのが、国内でも最も採用されている設定です。東京都が公開しているアジャイル開発の実践事例でも、スプリント期間は1週間または2週間に設定されており、これが実務上の一つの目安となっています。

個々の反復が1〜4週間であるとして、では全体としてどれくらいの期間でプロダクトが形になるのか、というのが発注者の最大の関心事でしょう。この点について、IPA（情報処理推進機構）が実施した国内のアジャイル開発に関する実態調査では、アジャイル開発の半数が「2〜4ヶ月」という開発期間で行われているというデータが示されています。つまり、1〜2週間のスプリントを4回から8回ほど繰り返したあたりで、最初のまとまった成果物（初回リリース）に到達するというのが、国内における一つの相場感です。前述の東京都の実践事例でも、対象としているのは「2〜3ヶ月である程度の成果が見込める小規模な案件」とされており、IPAの調査と整合します。ここで重要なのは、この「2〜4ヶ月」がプロジェクトの完全な終了を意味するわけではないという点です。アジャイル開発は「リリースして終わり」ではなく、初回リリース後も継続的に機能を追加・改善していくことを前提としています。したがって「2〜4ヶ月」は、あくまで「使える状態のプロダクトが最初に世に出るまでの期間」と捉え、その後も継続的な開発投資が続くものとして予算と体制を計画することが、現実的なアプローチになります。

適応的計画（ローリングウェーブ）でスケジュールを組む

アジャイル開発のスケジュールづくりを理解する鍵が、「適応的計画（アダプティブプランニング）」という考え方です。これは、最初に詳細な全体計画を作り込んでその通りに進めようとするのではなく、近い未来は具体的に、遠い未来は粗く計画しておき、反復を重ねるごとに先の計画を具体化・修正していくという手法です。プロジェクトマネジメントの世界では「ローリングウェーブ計画法」とも呼ばれます。波（ウェーブ）が転がる（ローリング）ように、計画の詳細化が時間とともに前進していくイメージです。アジャイルでは要求・開発・テストの短い反復を繰り返し、動くソフトウェアを成長させながら作っていくため、最初の段階で半年先・1年先の作業まで詳細に決め込むことはしません。なぜなら、開発を進めるなかで得られる学びやユーザーからのフィードバックによって、当初の想定は必ず変化するからです。むしろ「変化することを前提に計画する」ことこそが、アジャイルにおける正しいスケジュール管理の姿勢だといえます。

適応的計画といっても、現場では完全に行き当たりばったりで進めるわけではありません。IPAの調査では、リリースに向けた進め方として大きく3つのプロセスモデルが整理されており、これを知っておくとスケジュールの全体像が描きやすくなります。第一のモデル1（基本形態）は、企画フェーズが終わった後、要求・開発・テストの反復をひたすら繰り返し、適宜リリースを行っていくという最もシンプルな形です。不確実性が高く、最初から作るべきものが流動的な新規プロダクトに向いています。第二のモデル2（アーキテクチャ先行型）は、反復に入る前に、システムの基盤や共通部分をウォーターフォール型などであらかじめ作り込み（要求・アーキテクチャ設計・基盤開発）、その上で個別の機能群をアジャイルで反復開発していく形です。大規模システムや、技術的な土台が複雑で先に固めておくべき場合に適しています。第三のモデル3（テスト専用フェーズ型）は、反復を繰り返した後、特に高い品質が求められる場合に、リリース直前で「重点的なテスト」を行う専用期間を設ける形です。金融や医療など、品質要件が厳しい領域でよく採用されます。自社のプロジェクトがどのモデルに近いかを開発会社と早期に握っておくことで、全体スケジュールの精度が大きく向上します。

個々のイテレーションの計画とは別に、プロジェクト全体のロードマップを描くのが「リリースプランニング（リリース計画）」です。これはアジャイルにおける「いつ・何が・どこまでできるのか」という納期の見通しを関係者で共有するための重要な作業です。具体的には、開発したい機能の全体ボリュームを見積もり、それをチームが1反復あたりにどれだけ消化できるか（後述するベロシティ）で割ることで、「あと何回の反復で、つまり何週間で目標の機能群が完成するか」を予測します。リリースプランニングを行うことで、「3ヶ月後の展示会までに最低限ここまでは作る」「半期末までにこの機能セットをリリースする」といったビジネス上のマイルストーンと、開発の進捗を結びつけて管理できるようになります。重要なのは、このリリース計画も固定された約束ではなく、反復を重ねるごとに実績を反映して継続的に更新していくものだという点です。最初に立てた予測はあくまで初期仮説であり、数回の反復を経て実際の開発ペースが見えてきた段階で、より精度の高い納期見通しへと洗練させていきます。この「計画の継続的な更新」こそが、アジャイルが従来型より変化に強い納期管理を実現できる理由です。

ベロシティによる納期予測の仕組み

「アジャイルは納期が読めない」という誤解を解く鍵が、ベロシティという考え方です。アジャイル開発では、作業量を「○時間」「○人日」といった絶対的な時間で見積もるのではなく、ストーリーポイントと呼ばれる相対的な大きさで見積もる手法が広く用いられます。ストーリーポイントは、ある作業の「労力・複雑さ・不確実性」を、基準となる作業との相対比較で数値化したものです。そして、1回の反復でチームが消化できたストーリーポイントの合計を「ベロシティ（速度）」と呼びます。たとえば、あるチームが過去3回の反復でそれぞれ20・24・22ポイントを消化したとすれば、平均ベロシティは約22ポイントとなります。残っている作業の総ポイント数を、この平均ベロシティで割れば、「残作業をあと何回の反復で消化できるか」が算出でき、反復の長さを掛ければ「あと何週間で完了するか」という納期予測に変換できます。この方法の優れた点は、チームの実際の開発ペースという「実績」に基づいて予測する点にあります。机上の希望的観測ではなく、過去数回の実データから先を読むため、反復を重ねるほど予測精度が高まっていくのです。

ベロシティによる納期予測を成立させるうえで注意すべきなのが、プロジェクト開始直後はベロシティがまだ安定しないという点です。チームが立ち上がったばかりの時期は、メンバー同士の連携、開発環境の整備、対象ドメインへの習熟などに時間を要し、消化できるポイント数も反復ごとにばらつきます。そのため、最初の2〜3反復は「ベロシティを計測するための期間」と割り切り、この間に出した予測は暫定値として扱うのが定石です。3回程度の反復を終えてベロシティが安定してきたら、その平均値をもとに本格的な納期予測を立て直します。発注者の立場からすると、契約直後に「正確な完成日を約束してほしい」と求めたくなるものですが、アジャイルにおいては「最初の数反復でチームの実力を計測し、その実績から納期を確定させる」という進め方が、結果として最も信頼できる見通しを得る方法です。逆にいえば、計測期間を経ずに開発会社が最初から確定的な納期を断言してきた場合、それはウォーターフォール的な希望的見積もりである可能性が高く、後の手戻りリスクを内包しているといえます。

ベロシティと並んで、アジャイルの進捗・納期管理を支えるのがバーンダウンチャートです。これは、残っている作業量（残ストーリーポイント）を縦軸、時間（反復の経過）を横軸にとり、作業が消化されて残量が減っていく様子を右肩下がりの線で可視化したグラフです。理想線（このペースで進めば期限内に完了するという目安）に対して、実績線がどう推移しているかを見ることで、計画と実績のズレが一目でわかります。もし実績線が理想線の上を推移し続けている（＝想定より作業が消化できていない）場合、それは納期遅延の早期の兆候であり、スコープの調整や体制の見直しといった手を早い段階で打つ判断材料になります。ウォーターフォール型では遅延が表面化するのが終盤のテスト工程になりがちで、気づいたときには手遅れということが起こりますが、アジャイルではこうした可視化ツールによって、毎反復ごとに進捗の実態が明らかになります。発注者にとっても、バーンダウンチャートを定期的に共有してもらうことで、開発会社の報告を待つだけでなく、自らプロジェクトの健康状態を把握できるようになります。

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

アジャイル開発の期間管理を正しく理解するには、ウォーターフォール型との対比が欠かせません。ウォーターフォール型開発は、要件定義・設計・開発・テスト・リリースという大きなプロセスを順番に一度ずつ実施し、最後に一括でリリースして終了するアプローチです。この方式の最大の利点は、全体スケジュールの可視性が高いことです。プロジェクト開始時に全工程のガントチャートが引かれ、「いつ何が終わるか」が一本の線で明示されるため、特に経営層や予算管理者にとっては安心感があります。しかしその裏返しとして、途中で要求が変わった場合の対応が極めて苦手です。設計が固まった後に仕様変更が入ると、前工程に遡って作業をやり直すことになり、変更コストが大きく膨らみます。一方アジャイル型は、全体のロードマップが見えにくいという特性はあるものの、反復ごとに動くインクリメント（成果物）が積み上がっていくため、いつでもリリース可能な状態を保ちながら、変化を織り込んで進めることができます。どちらが優れているという話ではなく、要件の固まり具合や変化の頻度といったプロジェクトの性質によって、適した時間管理のスタイルが異なるということです。

ウォーターフォール型とアジャイル型の根本的な違いは、「何を固定し、何を変動させるか」という発想にあります。ウォーターフォール型は、作る機能の範囲（スコープ）を契約時に固定し、それを実現するために必要な期間とコストを見積もります。いわば「スコープ固定・納期変動」のモデルです。これに対してアジャイル型は、開発に投入できる期間と体制（＝コスト）を一定に保ちながら、その枠のなかで優先度の高い機能から順に作っていく「納期固定・スコープ変動」のモデルとして運用するのが本質に合っています。たとえば「3ヶ月・5人体制」という枠を先に決め、その期間で消化できる範囲の機能を、ビジネス価値の高い順に作っていくわけです。この発想の転換ができると、「全部の機能を作り終えるのはいつか」という問いではなく、「決められた期間で、最も価値のある機能群をどこまで作れるか」という問いに置き換わります。発注者がこの考え方を受け入れられるかどうかが、アジャイル開発を成功させられるかの分岐点になるといっても過言ではありません。

実際の国内プロジェクトでは、純粋なアジャイルか純粋なウォーターフォールかという二者択一ではなく、両者を組み合わせた「ハイブリッド型」が採用されるケースも増えています。たとえば、要件定義や基本設計といった全体の骨格はウォーターフォール型でしっかり固めてから、詳細設計以降の開発をアジャイルで反復的に進めるというパターンです。これは前述したIPAのプロセスモデル2（アーキテクチャ先行型）にも通じる考え方で、基盤部分の予測可能性を確保しつつ、変化の大きい機能部分には柔軟性を持たせるという「いいとこ取り」を狙うものです。官公庁の大規模システムや、高い予測可能性が求められる受託案件など、純粋なアジャイルが馴染みにくい領域では、こうしたハイブリッド型が現実解になることが少なくありません。重要なのは、自社のプロジェクトの性質、つまり「要件がどの程度固まっているか」「途中での変更がどれくらい想定されるか」「予測可能性をどこまで重視するか」を見極めたうえで、最適な期間管理のスタイルを開発会社と協議して選ぶことです。手法そのものを目的化せず、ビジネスゴールから逆算して選定する姿勢が求められます。

固定納期のプロジェクトでアジャイルを成立させる

「展示会の日程が決まっている」「年度内にリリースする必要がある」といった、動かせない固定納期を抱えたプロジェクトでもアジャイルは適用可能です。ただしその際には、アジャイルが「スコープ（機能要件）か納期のどちらかを調整できる」という前提のうえに成り立っていることを、発注側と開発側の双方が理解しておく必要があります。納期を絶対に動かせないのであれば、調整の対象になるのはスコープ、つまり「その納期に間に合わせるために、どの機能を含め、どの機能を後回しにするか」という議論です。ここで陥りがちな失敗が、「納期も固定、機能も全部必須、品質も妥協できない」とすべてを固定してしまうことです。これはアジャイルかどうか以前に、そもそもプロジェクトとして破綻しやすい条件であり、終盤での炎上を招きます。固定納期でアジャイルを成功させる鍵は、何を固定し何を譲るかを開始時に明確に合意しておくことに尽きます。

固定納期のアジャイルで有効なのが、「トレードオフスライダー」という合意形成の手法です。これは、品質・コスト・納期・スコープといったプロジェクトの要素について、何を優先し何を譲るかを、プロジェクト開始時に関係者全員で取り決めておくものです。たとえば「納期は絶対固定、品質も妥協しない、その代わりスコープは柔軟に調整する」という優先順位を全員で握っておけば、開発終盤で「このままでは全機能は間に合わない」となったときに、感情的な対立に陥ることなく、「では事前に合意した通り、優先度の低い機能Cを次フェーズに回そう」という建設的な判断ができます。この合意がないと、終盤で「納期を延ばすのか」「品質を落とすのか」「機能を削るのか」をめぐって関係者が紛糾し、プロジェクトが停滞します。発注者として準備しておくべきなのは、自社にとって何が本当に譲れない要素なのかを事前に整理しておくことです。多くの場合、リリース日（納期）が最優先で固定される一方、初回リリースに含める機能の範囲（スコープ）は調整の余地があるはずです。この優先順位を言語化し、トレードオフスライダーとして開発会社と共有することが、固定納期プロジェクト成功の第一歩となります。

固定納期でスコープを調整する際の具体的な進め方が、MVP（Minimum Viable Product＝実用最小限の製品）の定義です。MVPとは、ユーザーに価値を届けるために最低限必要な機能セットのことで、これを明確に定義し、「これだけは確実に納期内で仕上げる」と決めておきます。そして、それ以外の追加機能は優先度をつけてバックログに並べ、MVPの完成後、残り期間や次フェーズのスプリントで継続的に拡張していきます。このアプローチを取ることで、「最悪でもMVPは必ずリリースできる」という保証を得つつ、余力があれば追加機能まで作り込むという、段階的かつ安全な進め方が実現します。アジャイルは反復ごとに動くインクリメントを積み上げるため、もし途中で開発が想定より遅れても、その時点で「動く状態のMVP」が手元にある状態を保てます。これがウォーターフォール型との決定的な違いで、ウォーターフォールでは全工程が終わるまで「動くもの」が一切手に入らないため、納期直前で間に合わないと判明したときに打てる手が限られます。固定納期のリスクを最小化したいなら、MVPの明確な定義と、優先度に基づくスコープ調整こそが最も効果的な保険になるのです。

まとめ

本記事では、アジャイル開発における開発期間・スケジュール・納期の考え方を、スクラムやカンバンといった個別手法を横断する「アジャイル全般」の視点から解説しました。アジャイルの期間は固定された一本のスケジュールではなく、1〜4週間のイテレーションの積み重ねによって動的に形成されるものであり、適応的計画（ローリングウェーブ）によって近い未来は具体的に、遠い未来は粗く計画しながら継続的に更新していきます。「納期が読めない」という懸念に対しては、ストーリーポイントとベロシティによる実績ベースの予測、リリースプランニングによる全体ロードマップの可視化、バーンダウンチャートによる遅延の早期検知といった仕組みが用意されており、むしろ従来型より変化に強い納期管理が可能です。国内アジャイル案件の半数が2〜4ヶ月で初回リリースに至るというIPAのデータは一つの目安ですが、正確な期間は最初の数反復でベロシティを計測してから確定するのが正しい進め方です。固定納期のプロジェクトでも、トレードオフスライダーによる優先順位の合意と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を創業。