スクラム開発とは？進め方・3つの役割・5つのイベントとメリット・デメリットをスクラムガイドで解説

スクラム開発とは、1か月以内の短い期間（スプリント）を繰り返しながら、動くソフトウェアを少しずつ積み上げていくアジャイル開発の代表的なフレームワークです。役割は3つ、会議体は5つ、作成物は3つと、決まりごとは驚くほど少なく、その分だけ運用する側の理解度で成果が大きく変わります。この記事では、公式ドキュメントであるスクラムガイド2020年版の定義を軸に、役割・イベント・作成物を整理し、1スプリントの流れとベロシティの計算例、向く案件と向かない案件の判断基準、開発会社へ依頼するときの契約形態まで、導入を検討する立場で順に解説します。

まとめ：スクラム開発の要点

先に結論を押さえます。スクラム開発は次の要素で構成されます。

• 定義：アジャイル開発を実践する軽量フレームワーク。1か月以内の「スプリント」を反復する。基準文書はスクラムガイドの2020年11月版（2026年10月時点で最新）。
• 3つの役割（責任）：プロダクトオーナー・スクラムマスター・開発者。合わせて通常10人以下。
• 5つのイベント：スプリント（器）＋スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブ。
• 3つの作成物と確約：プロダクトバックログ（プロダクトゴール）・スプリントバックログ（スプリントゴール）・インクリメント（完成の定義）。
• 進め方の見通し：完了ポイントの実績（ベロシティ）から残りのスプリント数を予測し、総量ではなく優先順位で範囲を調整する。
• 向き不向き：要件が固まりきらず、変化に応じて優先順位を組み替えたい開発に向く。仕様と納期が完全固定の受託には向きにくい。
• 外注するなら：成果物の完成に対価を払う請負ではなく、業務の遂行に対価を払う準委任契約が基本線。

以下、それぞれを公式定義と実務の観点から掘り下げます。アジャイルやウォーターフォールとの違いを先に比較で押さえたい場合はウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分けを参照してください。

スクラム開発とは何か：スクラムガイド2020年版が定める定義と位置づけ

スクラムガイドが定める軽量フレームワークと経験主義の3本柱とは

スクラムは、複雑な問題に対応するためにケン・シュウェイバーとジェフ・サザーランドが体系化したフレームワークです。両者が管理する公式ドキュメント「The 2020 Scrum Guide」が現在の基準で、日本語訳もスクラムガイド2020年版（日本語PDF）として公開されています。A4で十数ページの短い文書に、役割・イベント・作成物・ルールだけが定義されています。

スクラム自体は開発技法やツールではありません。「経験主義」に基づく枠組みで、その柱は透明性・検査・適応の3つです。作業と成果を誰からも見える状態にし（透明性）、定期的にゴールとのズレを確かめ（検査）、ズレを見つけたら計画ややり方を変える（適応）。内部にどんな設計手法やプログラミング言語、テスト手法を組み込むかはチームに委ねられます。ラグビーのスクラムのように、チームが一体となって前進する様子が名前の由来です。

アジャイル開発・ウォーターフォールとの違いを上位概念から整理する

アジャイルは「変化に対応しながら反復的に開発する」という考え方（思想）で、2001年のアジャイルソフトウェア開発宣言がその原点です。宣言は「計画に従うことよりも変化への対応を」といった4つの価値を掲げており、その考え方を具体的な役割とイベントに落とし込んだ実装の一つがスクラムです。つまりアジャイルが上位概念、スクラムがその代表的なやり方という関係になります。

一方ウォーターフォールは要件定義・設計・実装・テストを順番に一度ずつ進める計画駆動型で、途中の仕様変更に弱い代わりに計画とコストが読みやすい特徴を持ちます。同じアジャイル系でも、タスクの流れを可視化して仕掛かり量を絞るカンバンは、スプリントという区切りを持たない点がスクラムと異なります（カンバン方式のタスク管理とボードの作り方・WIP制限の考え方で詳しく扱っています）。3手法の詳しい比較は前掲の比較記事で、アジャイル全体の進め方を先に知りたい場合はアジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説が入口になります。

2025年公開のスクラムガイド拡張パックは2020年版の置き換えではない

2025年には、ジェフ・サザーランドとラルフ・ヨッハム、ジョン・コールマンの3名による「スクラムガイド拡張パック」が公開されました。名前から「スクラムガイドの新版が出た」と受け取られがちですが、サイト上では2020年版スクラムガイドの補完資料と位置づけられています。役割・イベント・作成物という骨格は2020年版のままで、プロダクト戦略や成果の測り方、AIとの関わり方などの解説と任意の追加要素をまとめた文書です。2026年10月時点で、スクラムの定義そのものを確かめる基準は引き続き2020年版と考えて差し支えありません。

スクラムを構成する3つの役割：プロダクトオーナー・スクラムマスター・開発者

スクラムガイド2020年版では、この3つを「ロール」ではなく「アカウンタビリティ（責任）」と表現します。上下関係ではなく、一つのスクラムチームの中で責任を分担する関係です。チームを組むときの人選や文化づくりの手順はスクラムチームの作り方と強いチームに必要な要素にまとめています。

プロダクトオーナー（PO）はプロダクトの価値とバックログの並び順に責任を持つ

プロダクトの価値を最大化する責任を負います。何を作るか・作らないかを決める最終決定者で、プロダクトバックログの中身と優先順位を管理します。ステークホルダーの要望を取捨選択し、開発者が迷わないよう各項目の意図を明確にするのが役割です。決定が分散すると開発が止まるため、POは委員会ではなく1人に定めます。

スクラムマスター（SM）は障害を取り除きチームのスクラム実践を支える

スクラムが正しく機能するよう支援する責任を負います。進捗を管理する「管理職」ではなく、チームの障害を取り除き、スクラムの理解と実践を促す立場です（2020年版では「真のリーダーとしてチームに奉仕する」奉仕型リーダーと表現）。デイリースクラムが形骸化していないか、POが抱え込みすぎていないかといった問題に介入します。プロジェクトマネージャーと混同されがちですが、指示ではなく自律を促す立場である点が本質的に異なります。

開発者（Developers）は完成の定義を満たすインクリメントを毎スプリント作る

スプリントで実際にインクリメントを作る全員を指します。2020年版で「開発チーム」から「開発者」へ表現が変わり、プログラマーだけでなく設計・テスト・分析など完成に必要な作業を担う人すべてを含みます。役割で細かく分業せず、チーム全体で成果に責任を持つのが原則です。POとSMを含めた合計は通常10人以下とされ、これより大きくなる場合はチームを分割します。

スクラムの5つのイベント（セレモニー）：タイムボックスと各会議で決めること

スクラムのリズムを作るのは、決まったタイミングで繰り返し開く一連のミーティングです。すべてのイベントには時間の上限（タイムボックス）が定められています。2020年版スクラムガイドが1か月スプリントの場合として示す上限は次のとおりで、スプリントが短ければそれに応じて短縮します。

スプリントは他の4つのイベントを内包する1か月以内の固定期間

他の4つのイベントを内包する「器」で、1か月以内の固定期間です。多くの現場で設定されているスプリントの長さは1〜2週間です。スプリントの長さは途中で変えず、期間を一定に保つことで開発ペースと見通しを安定させます。スプリントの目的はスプリントゴールとして言語化します。

スプリントプランニングでスプリントゴールと着手する項目を決める

スプリントの開始時に、この期間で何を達成するか（スプリントゴール）と、そのために着手する項目を決めます。POが優先順位を示し、開発者が実現可能な量を見積もって項目を選ぶ流れです。1か月スプリントで最大8時間が上限で、期間が短ければそれに応じて短縮します。

デイリースクラムは開発者自身が計画を調整するための毎日15分の場

開発者が毎日同じ時刻・同じ場所で開く15分の短い会です。ゴールに対する進捗を確認し、その日の計画と障害を共有します。進捗報告会ではなく、開発者自身が計画を調整するための場であり、15分を超える議論は終了後に必要な人だけで行います。

スプリントレビューで完成物を見せてプロダクトバックログを見直す

スプリントの終盤に、完成したインクリメントをステークホルダーへ提示し、フィードバックを受けて今後のプロダクトバックログを見直す場です。完成物のデモを軸にした対話であり、資料発表会にしないことが成果につながります。1か月スプリントで最大4時間が上限です。

スプリントレトロスペクティブで進め方の改善策を1つ以上決める

スプリントの最後に、チーム自身の進め方を振り返る場です。プロダクトではなく「働き方」を対象に、うまくいった点・改善点・次に試す具体策を1つ以上決めます。この継続的な改善こそがスクラムの中核で、レトロスペクティブを省くとチームは成長しません。1か月スプリントで最大3時間が上限です。ふりかえりの材料を集めて議論を具体化する方法はレトロスペクティブの進め方とふりかえりの材料を自動で集める実装で紹介しています。

スクラムの3つの作成物と確約：バックログ・インクリメントと完成の定義

スクラムでは、進行状況の透明性を保つために3つの作成物を用います。2020年版では各作成物に「確約（コミットメント）」が結び付けられ、進む方向がぶれないよう設計されています。

プロダクトバックログとプロダクトゴールはプロダクトの長期の行き先

プロダクトに必要な要求をすべて集め、価値の高い順に並べた生きた一覧です。POが管理し、状況に応じて随時並び替えます。2020年版で導入されたプロダクトゴールは、このバックログが目指す長期的な到達点として、日々の項目がどこへ向かうのかを一本化するものです。項目の書き方やスプリントバックログとの違いはプロダクトバックログの書き方とスプリントバックログとの違いで例を交えて解説しています。

スプリントバックログとスプリントゴールは今回の期間で達成する目的

プロダクトバックログの上位から、そのスプリントで実現する項目を抜き出し、達成計画を加えたものです。スプリントゴールは「このスプリントで何を成し遂げるか」を一文で表した目的で、個別の項目より優先されます。ゴールを満たせるなら、途中で項目の入れ替えを調整する余地があります。

インクリメントと完成の定義（Definition of Done）で品質の線を引く

インクリメントは、スプリントで作り上げた「実際に動く」成果の積み上がりです。作りかけは含めません。「完成の定義（Definition of Done）」は、何をもって完成とみなすかの品質基準で、テスト済み・レビュー済み・本番相当の環境へデプロイ済みといった条件をチームで共有します。この基準が曖昧だと、動かないものが完成扱いされ後工程で破綻します。

スクラム開発の進め方：1スプリントの流れとベロシティによる見通しの立て方

役割・イベント・作成物を実際の時間軸に並べると、1スプリントは次のように回ります。この1周を繰り返し、毎回レトロスペクティブで進め方を改善していくのがスクラムの基本サイクルです。

なおスクラムガイドは、プロダクトバックログを細分化して詳細を詰める作業（リファインメント）を独立したイベントとしては定めていません。実務では週に1回程度の定例として時間を確保し、次のスプリントで着手できる粒度まで項目を分解しておくと、プランニングが短時間で終わります。見積もりはストーリーポイントなどの相対的な手法で行うのが一般的で、具体的なやり方や成功のコツはスクラム開発の5つの実践ポイント（ストーリーポイント見積もりと完成の定義）で詳しく解説しています。

ベロシティから残りのスプリント数を見積もるPythonの計算例

スクラムでは「全部でいつ終わるか」を最初の見積もりで約束するのではなく、実績から予測を更新します。基本になるのが、1スプリントで完了したストーリーポイントの合計（ベロシティ）です。直近数スプリントの実績と、プロダクトバックログに残っているポイントから、あと何スプリント必要かを計算できます。次のコードはPython 3系でそのまま実行できます。

# 直近スプリントの完了ポイント（ベロシティ）から残りスプリント数を見積もる
import math

done = [21, 18, 24]   # 直近3スプリントで完了したストーリーポイント
remaining = 130       # プロダクトバックログに残っているポイント

avg = sum(done) / len(done)
low = min(done)

print(f"平均ベロシティ: {avg:.1f}")
print(f"見込み: {math.ceil(remaining / avg)} スプリント")
print(f"慎重な見込み: {math.ceil(remaining / low)} スプリント")

実行すると「平均ベロシティ: 21.0」「見込み: 7 スプリント」「慎重な見込み: 8 スプリント」と表示されます。2週間スプリントなら14〜16週間後が完了の目安という読み方です。ここで押さえたいのは、予測を単一の値ではなく幅で示すという考え方です。平均だけで約束すると、実績が下振れしたスプリントで計画が崩れます。また、ベロシティはチームごとにポイントの基準が違うため、チーム間の比較や個人評価に使うと数字が水増しされ、予測の役に立たなくなります。

スクラム開発のメリット：仕様変更への強さと手戻りの小ささが生まれる理由

スクラムが選ばれる最大の理由は、仕様変更に強いことです。開発の途中で市場やユーザーの要望が変わっても、次のスプリントで優先順位を組み替えて取り込めます。要件を最初に固めるウォーターフォールとの決定的な差がここにあり、以下の利点はいずれもこの「反復」から派生します。

• 仕様変更に強い：スプリントごとに優先順位を組み替えられるため、市場やユーザーの要望変化を次の反復ですぐ取り込める。
• 手戻りが小さい：短い周期で動くものを確認するので、認識のズレが数か月分ではなく1スプリント分で済む。
• 進捗が見えやすい：完成したインクリメントという事実で進捗を測るため、「9割完成」のような曖昧な報告に頼らない。
• 価値の高い機能から先に使える：優先順位の高い項目から完成させるため、全機能がそろう前に一部をリリースして効果を確かめられる。
• チームが自律的に改善する：レトロスペクティブで毎スプリント改善策を実行し、回を重ねるほど生産性が上がる。

スクラム開発のデメリットと対策：全体像・役割理解・納期固定でつまずく点

一方で、スクラムは万能ではありません。導入で最もつまずくのは「全体像を最初に固定しにくい」点で、総工数・総費用を契約時点で確定したい組織ほど摩擦が大きくなります。対策とあわせて、押さえるべき弱点を挙げます。

• 全体像が固定しにくい：反復で作る性質上、最終的な総工数・総費用を最初に確定しづらい。対策として、プロダクトゴールと大枠のリリース計画を先に合意し、詳細だけを反復で詰める。前章のベロシティ予測を毎スプリント更新して共有するのも有効。
• 役割の理解が難しい：SMをただの進行役、POを単なる窓口と誤解すると機能しない。対策は、導入初期にスクラム経験者やSMを立て、形だけの運用を防ぐこと。
• 納期固定の案件と相性が悪い：納期と仕様が両方固定だと、変化に対応する余地というスクラムの利点が消える。対策は、固定するのは納期だけにし、スコープ（機能範囲）を調整可能にしておく。
• チーム維持のコスト：頻繁なメンバー交代は積み上げた改善を失わせる。対策は、チームを固定して稼働させ、育成もチーム単位で行う。
• ドキュメントが薄くなりやすい：「動くソフトウェア」を優先する解釈が行き過ぎると、保守に必要な設計情報が残らない。対策は、完成の定義に「設計メモと運用手順の更新」を含めること。

導入がうまくいかなかった現場で何が起きていたかは、アジャイル開発が失敗する5つの原因で原因別に整理しています。

スクラム開発が向くプロジェクト・向かないプロジェクトを分ける判断基準

ここは判断が分かれる論点なので、立場を明確にします。スクラムは「何を作れば正解かを最初に確定できない開発」でこそ価値が出ます。具体的には、自社サービスや新規プロダクトのように、ユーザーの反応を見ながら仕様を育てたい場合です。逆に、要件も納期も契約時点で完全に固定される受託開発、あるいは1〜2人で完結する小規模開発では、スクラムの役割分担やイベントがオーバーヘッドになりやすく、無理に導入すると「セレモニーだけ守って改善が伴わない」形骸化に陥ります。

判断基準を一つに絞るなら「開発途中で優先順位を組み替える必要があるか」です。組み替えの余地がないならウォーターフォールの方が計画・コストの見通しで勝ります。表の項目のうち、とくに「発注側の関与」は見落とされがちで、POを担える人が発注側にいない状態でスクラムを選ぶと、優先順位が決まらずスプリントが空転します。

スクラム開発を開発会社に依頼するときの確認点と準委任契約の考え方

スクラム開発を外部の開発会社へ依頼する場合、確認すべきは体制と契約形態です。まず、認定スクラムマスターやアジャイル開発の実績があるかを確認します。次に、成果物と検収条件が固定される請負契約はスクラムと噛み合いにくいため、期間や工数に対して対価を払う準委任契約が適します。

この考え方は公的なひな形にも表れています。IPAが公開する「情報システム・モデル取引・契約書（アジャイル開発版）」は、あらかじめ特定した成果物の完成に対価を払う請負ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を払う準委任契約を前提としています（2020年3月公開、2026年9月時点で更新あり）。請負・準委任・派遣の違いと使い分けは準委任契約とは？請負・派遣との違いとシステム開発での使い分けを参照してください。

あわせて、次の3点を契約前に確認しておくと、丸投げによる方向ズレを防げます。

• POの所在：プロダクトバックログの優先順位を発注側が握れるか。ベンダ側に任せきりにしない。
• レビューへの参加：スプリントレビューに自社の担当者が参加し、毎回フィードバックできる体制か。
• メンバーの固定：スプリントをまたいでメンバーが入れ替わらないか。交代が多いとベロシティが安定しない。

一創では、スクラムを含むアジャイル開発の体制を、国内のチームを常設するラボ型開発（国内）として提供しています。POの立て方やスプリントの長さの決め方といった立ち上げの段階から相談できます。

よくある質問

スクラム開発とは何ですか？

アジャイル開発を実践するための軽量フレームワークです。1か月以内のスプリントを反復し、3つの役割・5つのイベント・3つの作成物という最小限のルールで、変化に対応しながら動くソフトウェアを継続的に作ります。定義の基準はスクラムガイド2020年版です。

スクラムマスターとは何をする人ですか？

スクラムが正しく機能するよう支援する責任者です。進捗を管理するのではなく、チームの障害を取り除き、スクラムの理解と実践を促すサーバントリーダーで、指示ではなく自律を促す点でプロジェクトマネージャーと異なります。

スクラムとアジャイルの違いは何ですか？

アジャイルは反復的に開発するという考え方（思想）で、スクラムはその考え方を役割とイベントに落とし込んだ具体的なフレームワークの一つです。アジャイルが上位概念、スクラムが代表的な実装という関係です。

スプリントの期間はどのくらいが適切ですか？

スクラムガイドでは1か月以内と定められ、実務では1〜2週間が一般的です。短いほどフィードバックの頻度が上がる反面、イベントの負荷も増えます。一度決めた長さは途中で変えないのが原則です。

スクラム開発は何人で行いますか？

プロダクトオーナー・スクラムマスター・開発者を合わせて通常10人以下とされています。これより大きくなる場合は、同じプロダクトゴールを共有する複数のスクラムチームに分割して運用します。

関連記事

• ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け
• スクラム開発の5つの実践ポイント｜ストーリーポイント見積もりと完成の定義
• アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説
• スクラムチームの作り方｜強いチームに必要な要素と文化を定着させる手順
• プロダクトバックログとは？スプリントバックログとの違い・書き方の例をスクラムガイド2020で解説