アジャイル開発を外注した際、契約書や提案書に「スプリント」という言葉が頻繁に登場します。「2週間ごとにリリースします」「スプリントレビューに参加いただきます」——こうした説明を受けながら、具体的に何が変わるのかイメージできなかった経験はないでしょうか。
従来のウォーターフォール型開発では、月次報告で進捗を確認し、最終的に完成物を受け取るのが一般的でした。スプリントを用いたアジャイル開発では、そのサイクルが根本的に変わります。発注者として参加を求められるスプリントレビューでは、「何を確認すればいいか」「どんな意思決定をすればいいか」が明確でないと、ただ時間を過ごすだけになってしまいます。
費用の観点も同じです。「このスプリントに100万円払っているが、何が完成したのか」「残りの予算でどこまで作れるのか」——これらの疑問に答えられなければ、スプリント型の開発契約の恩恵を十分に受けられません。
本記事では、システム開発の発注者に向けて、スプリントの仕組みをゼロから解説します。スプリントレビューで実際に確認すべきポイント、費用対効果の評価方法、そしてスプリントが機能しなくなる兆候まで、発注者目線で整理しました。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
スプリントとは？2週間区切りにする理由と発注者が知るべきこと
スプリントとは、アジャイル開発のフレームワーク「スクラム」において使われる開発期間の単位です。1〜4週間の固定された期間内に、設計・開発・テストを完了させることを目指します。実際の現場では、2週間を1スプリントとするケースが最も多く見られます。
スクラムの概念全体（スプリント以外のロール・イベント・アーティファクト）については、スクラム開発とは？アジャイル開発の進め方を解説で詳しく解説しています。本記事はスプリントという「時間単位」の仕組みに絞って深掘りします。
スプリントと従来の月次報告はどう違うか
ウォーターフォール型開発では、要件定義→設計→開発→テストというフェーズを順番に進め、月次で「現在どのフェーズにいるか」を報告するのが一般的です。一方、スプリントを用いたアジャイル開発では、2週間ごとに「動くソフトウェア」を届けることを目標とします。
発注者から見た最大の違いは、成果物の確認タイミングです。月次報告では完成物を受け取るのはプロジェクト終盤ですが、スプリントでは2週間ごとに実際に動く機能を確認できます。「作っているものが想定と違う」と気づくタイミングが格段に早くなります。
2週間が多い理由——フィードバックの早さとオーバーヘッドのトレードオフ
スプリント期間が短すぎると（例：1週間）、計画・レビュー・振り返りといった周辺作業の比重が大きくなり開発時間が圧迫されます。逆に長すぎると（例：1ヶ月）、フィードバックが遅くなり問題の発見が遅れます。このトレードオフの落としどころとして、2週間が多くの現場で採用されています。
スプリントの1サイクルの流れ——発注者はどこに登場するか
1スプリントは4つのイベントで構成されます。発注者（または発注者の代理として動くプロダクトオーナー）は、単にスプリントレビューに参加するだけでなく、スプリント全体を通じて重要な役割を持っています。
スプリントプランニング——次の2週間で何を作るかを決める場
スプリントプランニングは各スプリントの開始時に行われます。「プロダクトバックログ」と呼ばれる機能要求の優先順位リストの中から、今回のスプリントで実装する項目を選択し、スプリントゴールを設定します。
発注者の役割は、プロダクトバックログの優先順位を決めることです。「ユーザーログイン機能とダッシュボード機能のどちらを先に作るか」といった判断を、ビジネス価値や緊急性を踏まえて下します。この判断なしには、スプリントプランニングは進められません。
スプリントレビュー——デモを見て判断を下す場
スプリントの終了時に行われるのがスプリントレビューです。開発チームがスプリントゴールとして設定した機能のデモを見せ、発注者はそれを評価・フィードバックします。「承認の場」ではなく「対話の場」であることが重要なポイントです。
次のスプリントで何を優先するかの議論もここで行われます。スプリントレビューの具体的な確認ポイントは、後述の「スプリントレビューで発注者がすべき3つのこと」で詳しく解説します。
スプリントレトロスペクティブ——改善の場（参加は任意だが効果的）
スプリントレビューの後に行われる振り返りがレトロスペクティブです。開発チームが「うまくいったこと」「改善すべきこと」を話し合います。発注者の参加は必須ではありませんが、参加することで開発チームの課題を早期に把握し、必要に応じてサポートできます。
スプリントレビューで発注者がすべき3つのこと
スプリントレビューは、単なる報告会ではありません。開発チームが見せるデモを評価し、次のスプリントに向けた意思決定をする場です。「よくわからなかったけど承認しました」では、スプリントの効果を発揮できません。
確認① スプリントゴールは達成されたか
まず確認すべきは、今スプリントで設定したスプリントゴールが達成されたかどうかです。デモを見ながら、以下の問いを自分に投げかけてください。
- 「このスプリントで何が完成しましたか？」——完成の定義（完了の定義）を確認する
- 「スプリントゴールとして設定した機能は実際に動いていますか？」——デモで実際の動作を確認する
- 「完了できなかった項目はありますか？その理由は？」——未完了の原因を把握する
完了した機能を確認する際は、「動いている」だけでなく「自分たちのビジネス要件を満たしているか」という観点で評価することが重要です。
確認② 次のスプリントの優先順位は正しいか
スプリントレビューでは、今スプリントの評価と同時に、次のスプリントで何を作るかを議論します。現在のプロダクトバックログの優先順位が、今もビジネス状況に即しているかを確認してください。
- 「このスプリントで気づいたことで、バックログの優先順位を変えたい項目はありますか？」
- 「追加で実装したい機能が出てきましたか？それをバックログに加えて優先度を設定できますか？」
市場の変化や社内の事情によって優先順位は変わります。スプリントレビューはその見直しをするための絶好のタイミングです。
確認③ 期待とのギャップはないか——フィードバックの出し方
「思っていたのと違う」という感想は、スプリントレビューで最も価値あるフィードバックの一つです。ただし、「なんか違う」ではなく、具体的に伝えることが重要です。
効果的なフィードバックの形式:
- 「〇〇の画面で△△ボタンを押したとき、□□という動作を期待していたが、実際は××だった」
- 「エンドユーザーの立場から見ると、◇◇のステップが多すぎて使いにくいと感じる」
感覚的な評価よりも、「誰が」「何をしようとしたとき」「何が問題か」を具体的に伝えることで、開発チームはより効果的に改善を進められます。
スプリントを通じた予算管理——ベロシティと費用の関係
アジャイル開発において、発注者が悩みやすいのが予算管理です。スプリントを活用すると、残りの開発にかかる費用を定期的に再予測できるようになります。
スプリント単価とベロシティで残予算を見積もる方法
ベロシティとは、1スプリントでチームが完了できる作業量を数値化したものです（単位: ストーリーポイント）。例えば、過去3スプリントのベロシティが20・22・18だった場合、平均ベロシティは20ポイントとなります（Atlassian ベロシティの解説）。
残りのプロダクトバックログの総ポイントが100ポイントで、平均ベロシティが20ポイントであれば、完了まであと5スプリント（100 ÷ 20）が必要と推定できます。1スプリントあたりの費用が100万円であれば、残り約500万円の見込みとなります。
この計算はあくまで推定値ですが、「残りをどう優先するか」という議論の基礎になります。
費用対効果を判断する3つの指標
スプリント単位で費用対効果を評価するための指標として、以下の3つが実践的です。
① スプリントゴールの達成率 設定したスプリントゴールが達成されたか否か。「達成された機能が計画通りかどうか」を追うことで、開発チームの生産性と見積もり精度を把握できます。
② 完了ストーリーポイント数（ベロシティ） スプリントごとに完了したストーリーポイントを記録します。3〜5スプリントのデータが溜まると、残りの開発量の予測精度が上がります。ベロシティが大幅に下がっている場合は、何らかの問題が起きているサインです。
③ プロダクトバックログの消化率 全体のバックログに対して、今のスプリントでどれだけ消化できたかを確認します。予想より消化が遅い場合は、スコープの見直しや優先順位の再調整を検討してください。
スプリントが機能しなくなる兆候と発注者が取れる対策
スプリントを導入していても、徐々に形骸化するケースは少なくありません。以下の兆候が見られたら、早めに対処することが重要です。
要注意サイン——スプリントが形骸化するパターン
サイン1: スプリントレビューが報告会になっている デモではなくスライドで進捗を「報告」するだけで、発注者からのフィードバックを求めない形式になっている場合は要注意です。スプリントレビューは対話の場であるべきです。
サイン2: スプリントゴールが毎回「作業完了」だけ 「タスクをこなす」ことがゴールになり、「このスプリントでどんなビジネス価値を届けるか」が明確でなくなっている状態です。スプリントゴールがビジネス視点で設定されていないと、何を作るかの判断がしにくくなります。
サイン3: バックログが増え続けて整理されない スプリントをこなすたびにバックログの項目が増え、優先順位が見えなくなっている場合は、バックログリファインメント（整理の場）が機能していないサインです。
サイン4: ベロシティが不安定または低下傾向 チームの生産性を示すベロシティが大幅にばらついたり、継続的に低下している場合は、技術的負債の蓄積やチーム内の課題がある可能性があります。
発注者にできる3つの改善アクション
アクション1: スプリントレビューで積極的にフィードバックを出す 形骸化の最大の原因は、発注者がレビューで受け身になることです。「デモを見て、何でも質問する」という姿勢が、チームの改善意識を引き出します。
アクション2: バックログ整理の場を定期的に設ける 週に1度、30〜60分程度のバックログリファインメントセッション（次スプリントの準備会）を設定することで、優先順位の混乱を防げます。「何を次に作るかが常に明確な状態」を維持することが重要です。
アクション3: 問題が疑われたら早めに開発会社に相談する スプリントの運営に問題を感じたら、我慢せずに開発会社のプロジェクトマネージャーやスクラムマスターに相談しましょう。スプリント期間や運営方法の見直しは、チームと合意すれば変更できます。
スプリントを有効に機能させるかどうかは、発注者の関与の質に大きく左右されます。「お任せしました」ではなく、スプリントの仕組みを理解した上で積極的に関与することが、システム開発の成功につながります。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
