スクラムとは｜意味や役割・イベントなどの仕組みをわかりやすく解説

スクラムとは、アジャイル開発を実践するための枠組み（フレームワーク）の一つです。短い期間（スプリント）を繰り返しながら、チームで価値を生み出すための枠組みで、守るべき要素は公式の「スクラムガイド」に定められています。

私はプロジェクトマネージャーとして、ウォーターフォールとアジャイルの両方の現場を経験し、認定スクラムマスター（CSM）の資格も持っています。スクラムを取り入れた現場では、役割やイベントの意味が人によって違うまま運用され、会議だけが増えてしまう場面も見てきました。

この記事では、スクラムという言葉の意味と由来を整理したうえで、スクラムを支える理論と価値基準、3つの責任、5つのイベント、3つの作成物を、スクラムガイドにもとづいて解説します。あわせて、メリット・デメリットとよくある誤解も紹介します。

執筆者：和田匠真

IT業界で20年以上の実務経験を持つプロジェクトマネージャー。プログラマー・SEを経てPMとなり、大手企業のシステム提案からデリバリーまで一貫して従事。PMP／認定スクラムマスター（CSM）保有。ウォーターフォール／アジャイル双方の現場経験をもとに、プロジェクト管理に関する記事を執筆。

スクラムでプロダクトバックログやスプリントを管理するなら、当社が提供するLychee Redmineもご検討ください。Neoバックログでスプリントの計画を、Neoカンバンで日々の進捗を共有でき、30日間の無料トライアルでお試しいただけます。

 

スクラムとは

スクラムは、アジャイル開発を実践するための枠組みの一つで、短い期間（スプリント）を繰り返しながら、チームで価値を生み出すための枠組みです。まずは全体像を押さえ、そのうえで定義や言葉の由来を確認していきましょう。

スクラムガイドによる定義

スクラムの公式な定義は、考案者のケン・シュエイバー氏とジェフ・サザーランド氏が書いた「スクラムガイド」に示されています。2020年11月版では、次のように定義されています。

「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。」

「軽量級フレームワーク」とは、守るべき最小限の要素だけを定め、具体的なやり方はチームが決める、という意味です。スクラムガイドは公式サイトで無料公開されており、日本語訳も読めます。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

スクラムという言葉の由来とビジネスで使われる意味

スクラムは英語で「scrum」と書きます。辞書では、ラグビーで反則などの後にプレーを再開するときに双方の選手が組み合うこと、デモなどで多くの人が腕を組んで横に並ぶこと、そして比喩として「全員が一丸となること。一致団結すること」という意味が示されています。

ビジネスで「スクラムを組む」と言う場合は、関係者が一致団結して取り組むという意味で使われます。開発のフレームワークとしてのスクラムは、この言葉に由来する名前ですが、言葉の意味とは別のものとして理解しましょう。
（出典：デジタル大辞泉「スクラム」）

スクラムが生まれた経緯

1986年、竹内弘高氏と野中郁次郎氏はHarvard Business Reviewの論文で、チームが一体となって進める新製品開発の進め方を、ボールをチーム内で回しながら進むラグビーにたとえました。
（出典：Harvard Business Review「The New New Product Development Game」）

その後、1995年のOOPSLAカンファレンスで、ケン・シュエイバー氏とジェフ・サザーランド氏がスクラムを共同発表しました。2010年に最初のスクラムガイドが書かれ、現在の最新版は2020年11月版です。なお、アジャイルソフトウェア開発宣言が発表されたのは2001年で、1995年ではありません。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」／「アジャイルソフトウェア開発宣言」）

アジャイル開発とスクラムの関係

アジャイル開発は、アジャイルソフトウェア開発宣言に示された価値観と原則にもとづく、開発の考え方の総称です。決まった手順を指す言葉ではありません。

一方、スクラムは、その考え方を実践するための枠組みの一つです。「アジャイル開発」という大きな考え方の中に、スクラムという具体的な枠組みがある、という関係で理解するとわかりやすいでしょう。アジャイル開発の全体像は、次の記事で解説しています。

アジャイル開発とスクラムの関係や、スクラムの採用を判断するポイントについては、こちらの記事も参考にしてください。

 

スクラムを支える理論と価値基準

スクラムは、経験主義とリーン思考を土台とし、三本柱と5つの価値基準で支えられています。ここでは、スクラムガイドの用語のまま、土台となる考え方を説明します。用語の意味をチームでそろえておくと、イベントの目的もぶれにくくなります。

経験主義とリーン思考

スクラムガイドでは、スクラムは経験主義とリーン思考に基づくと説明されています。経験主義は「知識は経験から生まれ、意思決定は観察に基づく」という考え方、リーン思考は「ムダを省き、本質に集中する」考え方です。

先の見通しが立ちにくい仕事では、最初にすべてを計画しても、途中で前提が変わることがあります。利用者の反応や技術的な課題は、実際に作って試してみるまでわからないことも少なくありません。そのためスクラムでは、短い間隔で実際の成果を確かめ、その結果をもとに次の行動を決めながら進めます。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

透明性・検査・適応の三本柱

経験主義を支えるのが、透明性・検査・適応の三本柱です。透明性は、作業と成果が、作業をする人とその成果を受け取る人に見えている状態を指します。検査は、成果とゴールに向けた進み具合を頻繁に確かめること、適応は、問題が見つかったときに早く調整することです。

三本柱は、スクラムのイベントを通じて実現されます。たとえばデイリースクラムでは進み具合を検査して計画を適応させ、スプリントレビューでは成果を関係者に見せて今後の方向を決めます。透明性がなければ、正しく検査することも適応することもできません。

5つの価値基準

スクラムガイドでは、スクラムチームが大切にする5つの価値基準が示されています。

• 確約（Commitment）は、ゴールの達成と、お互いの支援に責任を持つことです。
• 集中（Focus）は、スプリントの作業とゴールに集中することです。
• 公開（Openness）は、作業や課題を関係者に隠さず示すことです。
• 尊敬（Respect）は、お互いを能力のある独立した人として尊重することです。
• 勇気（Courage）は、正しいことを行い、難しい問題に取り組む勇気を持つことです。

価値基準が共有されていると、三本柱が形だけにならず、チームの中で機能しやすくなります。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

 

スクラムチームの3つの責任

スクラムチームは、プロダクトオーナー・スクラムマスター・開発者で構成されます。2020年版のスクラムガイドでは、これらを「役割」ではなく「責任（アカウンタビリティ）」と表現しています。一般には役割とも呼ばれます。

プロダクトオーナー

プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することに責任を持ちます。プロダクトゴールを示し、プロダクトバックログの項目を作成・説明し、並び順を決めることが主な仕事です。

プロダクトオーナーは1人の人間であり、委員会ではありません。多くの関係者の要望を聞いたうえで、何を優先するかを最終的に判断します。判断が遅れると開発者の作業が止まるため、チームに継続して関われることが大切です。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

スクラムマスター

スクラムマスターは、スクラムガイドで定義されたスクラムを確立させ、スクラムチームの有効性に責任を持ちます。チームだけでなく、プロダクトオーナーや組織に対しても、スクラムの理解と実践を支援します。

スクラムガイドには、自己管理型で機能横断型のチームメンバーをコーチすることも、スクラムマスターの仕事として挙げられています。スクラムマスターは、ときどき登場する指揮役ではなく、スクラムチームに必ず置く責任です。指示や管理ではなく、支援とコーチングによってチームの力を引き出す立場だと理解しましょう。

開発者

開発者は、各スプリントで、利用可能なインクリメント（成果）を作ることに責任を持ちます。スプリントバックログの作成、完成の定義を守ることによる品質の確保、日々の計画の調整も、開発者の仕事です。

開発者という名前ですが、エンジニアだけを指すわけではありません。デザイナーやテスト担当など、インクリメントを作るために必要な専門性を持つ人が含まれます。以前の版の「開発チーム」という呼び方は、2020年版で「開発者」に改められました。

スクラムチームの人数と体制

スクラムチームは、価値を生み出すために必要なスキルを備えた機能横断型のチームです。また、誰が何をいつどのように行うかをチームの中で決める、自己管理型のチームでもあります。

スクラムチームは通常10人以下で、スクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成されます。チームの中にサブチームや上下関係は作りません。チームが大きくなりすぎた場合は、同じプロダクトを担当する複数のスクラムチームに分けることを検討します。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

 

スクラムの5つのイベント

スクラムには、スプリント・スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブの5つのイベントがあります。各イベントには、時間の上限（タイムボックス）が決められています。実際の進め方の例は、次の記事も参考にしてください。

スプリント

スプリントは、ほかのすべてのイベントを含む入れ物となるイベントです。スクラムガイドでは、スプリントは1か月以内の決まった長さとすると定められています。前のスプリントが終わると、すぐに次のスプリントが始まります。

スプリント中は、スプリントゴールの達成を危うくするような変更は行いません。一方で、学びが得られれば、プロダクトオーナーと相談しながら作業の範囲を明確にしたり、交渉し直したりすることができます。スプリントの長さや決め方は、次の記事で詳しく解説しています。

スプリントプランニング

スプリントプランニングは、スプリントで行う作業を計画するイベントです。スクラムチーム全体で、このスプリントはなぜ価値があるのか、このスプリントで何ができるのか、選んだ作業をどのように進めるのか、の3点を話し合います。

話し合いの結果として、スプリントゴールと、選んだプロダクトバックログの項目、それを届けるための計画がまとまります。スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大8時間です。スプリントが短ければ、通常はこれより短い時間で行います。

デイリースクラム

デイリースクラムは、スクラムチームの開発者のための15分のイベントです。スプリントの各稼働日に、同じ時間・同じ場所で行います。

目的は、スプリントゴールに対する進み具合を検査し、必要に応じてスプリントバックログを調整することです。デイリースクラムの15分は、スプリントの長さに関係なく一定です。進め方は開発者が決めてよく、スプリントゴールに向けた計画の調整につながるものであれば、形式は問われません。

開発者以外の人が参加する場合は、話し合いの主体が開発者であることを意識しましょう。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

スプリントレビュー

スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することです。スクラムチームは、主要な関係者に成果を見せ、プロダクトゴールに向けた進み具合を一緒に確認します。

その場で出た意見をもとに、次に何をするかを話し合い、プロダクトバックログを調整します。単に完成した機能をテストして評価する場ではなく、成果を関係者と確かめ、プロダクトの方向を決める場です。スプリントが1か月の場合、タイムボックスは最大4時間です。

スプリントレトロスペクティブ

スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することです。スクラムチームは、個人・相互作用・プロセス・ツール・完成の定義について、スプリントがどうだったかをふりかえり、改善策を決めます。

私が関わったスクラムチームでも、ふりかえりで「レビューの直前に作業が集中する」という課題が出たため、次のスプリントでは完成の定義を見直し、早めに確認を受ける進め方を試しました。改善策は小さく決めて次のスプリントで試し、結果をまたふりかえることで、進め方が少しずつ良くなります。スプリントが1か月の場合、タイムボックスは最大3時間です。

 

スクラムの3つの作成物と確約

スクラムには、プロダクトバックログ・スプリントバックログ・インクリメントの3つの作成物があります。一般には成果物とも呼ばれます。それぞれに、進み具合を測る基準となる「確約（コミットメント）」が対応しています。

プロダクトバックログとプロダクトゴール

プロダクトバックログは、プロダクトの改善に必要なものを順番に並べた一覧です。スクラムチームが行う作業の唯一の情報源で、プロダクトオーナーが並び順に責任を持ちます。

プロダクトバックログに対応する確約は、プロダクトゴールです。プロダクトゴールは、プロダクトの将来の状態を表すもので、スクラムチームが目指す長期的な目標になります。プロダクトバックログの項目は、プロダクトゴールに近づくために何が必要かという視点で追加・整理されます。

スプリントバックログとスプリントゴール

スプリントバックログは、スプリントゴール（なぜ）、スプリントのために選んだプロダクトバックログの項目（何を）、インクリメントを届けるための計画（どのように）で構成されます。開発者が作り、開発者のための計画として使います。

スプリントバックログに対応する確約は、スプリントゴールです。スプリントゴールはスプリントの唯一の目的で、スプリントプランニングで決めます。作業の進め方が変わっても、スプリントゴールがあれば、チームは同じ方向を向いて調整できます。

インクリメントと完成の定義

インクリメントは、プロダクトゴールに向けた具体的な成果です。スプリント中に複数のインクリメントを作ることもでき、それぞれが前のインクリメントに積み重なっていきます。

インクリメントに対応する確約は、完成の定義です。完成の定義とは、インクリメントがプロダクトの品質基準を満たした状態を正式に示したものです。完成の定義を満たした作業だけがインクリメントとして扱われるため、チーム内で「完成」の意味がずれるのを防げます。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

 

スクラムのメリット

スクラムを正しく運用すると、次の3つの効果が期待できます。メリットとデメリット、採用の判断についてさらに詳しく知りたい場合は、前述のアジャイル開発とスクラム開発の違いの記事も参考にしてください。

短い間隔で成果を確かめ方向を修正できる

スプリントごとにインクリメントを確認できるため、要求の変化や認識のずれに早く気づけます。数か月後に完成品を見て初めて「想定と違う」とわかる、という事態を防ぎやすくなるでしょう。

スプリントレビューで関係者と成果を確かめ、その意見をプロダクトバックログに反映すれば、次のスプリントで方向を修正しやすくなります。作ったものが使われないまま終わるリスクを、早い段階で小さくできる点もメリットです。市場や利用者の要望が変わりやすいプロダクトほど、この効果を感じやすいはずです。

チームの状況と課題が見えやすくなる

プロダクトバックログとスプリントバックログによって、何をどの順番で進めているかが、チームと関係者に見える状態になります。デイリースクラムでは、進み具合と課題を毎日確認できます。

これは、三本柱の「透明性」を支える仕組みです。作業と課題が見えていれば、問題が大きくなる前に気づいて手を打てます。誰か1人だけが状況を知っている、という属人化も防ぎやすくなるでしょう。関係者が状況を自分で確認できるため、報告のための資料作りも減らせます。

チームが自ら改善を続けられる

スプリントレトロスペクティブで、チーム自身が進め方をふりかえり、改善策を決めて次のスプリントで試せます。改善が仕組みとして毎スプリント組み込まれている点が、スクラムの特徴です。

外から指示された改善ではなく、チームが自分たちで決めた改善なので、続けやすくなります。スプリントを重ねるごとに、チームに合った進め方が少しずつ固まっていきます。チームのメンバーが自分たちの働き方に責任を持つことで、主体的に動きやすくなる効果も期待できます。

 

スクラムのデメリットと注意点

スクラムでは、イベントや作成物を運用する時間と、継続して判断できる体制が必要です。また、不確実性の高い仕事では、開始時点で納期と範囲を確定できない場合があります。ここでは、導入前に確認したい3つの注意点と、それぞれへの対応方法を紹介します。

イベントと作成物を正しく運用する負担がある

スクラムでは、決まったイベントを毎スプリント行い、作成物を更新し続けます。目的を理解しないまま形だけ続けると、会議の負担だけが増えたと感じやすくなります。

たとえば、デイリースクラムが毎日の報告会になり、レトロスペクティブで同じ話を繰り返すような状態です。対策は、各イベントの目的をチームで確認し、目的に合わない進め方になっていれば見直すことです。スクラムマスターが、イベントが目的どおりに機能しているかを支援します。

プロダクトオーナーが関わらないと機能しにくい

プロダクトバックログの並び順や判断が遅れると、開発者は何を優先すべきか決められなくなります。プロダクトオーナーがほかの業務と兼任していて時間が取れない場合に、起こりやすい問題です。

対策として、プロダクトオーナーがスプリントプランニングやスプリントレビューに参加し、継続して判断できる体制を整えましょう。判断に必要な権限をプロダクトオーナーに持たせることも大切です。組織として、プロダクトオーナーの判断を尊重する合意を作っておくと、判断の遅れや差し戻しを減らせます。

プロダクト全体の納期や範囲を見通しにくい

要求や技術に不確実性がある仕事では、開始時点で納期と範囲を同時に確定することは難しいものです。スクラムでは、実績と学習をもとに見通しを更新していきます。

スクラムガイドでは、予測可能性を最適化してリスクを制御するために、反復的で漸進的なアプローチを採用すると説明されています。スクラムが不確実性を生むのではなく、短い間隔で検査と適応を行うことで、見通しの精度を高める仕組みです。対策として、プロダクトゴールとプロダクトバックログを見える状態にし、スプリントごとの実績をもとに見通しを関係者と共有しましょう。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

 

スクラムでよくある誤解

スクラムについては、言葉のイメージから生まれた誤解も少なくありません。ここでは、よくある3つの誤解と、スクラムガイドにもとづく実際の考え方を紹介します。誤解したまま運用すると、スクラムの効果が出にくくなるため注意しましょう。

スクラムマスターはプロジェクトマネージャーと同じという誤解

スクラムマスターを、計画を立てて指示を出す管理者と同じように捉える人がいます。しかし、スクラムガイドでは、スクラムマスターはスクラムを確立させ、スクラムチームの有効性に責任を持つ立場とされています。

スクラムマスターの仕事は、指示や管理ではなく、チーム・プロダクトオーナー・組織への支援とコーチングです。作業の進め方は自己管理型のチームが決めるため、スクラムマスターはチームが自ら判断できるように働きかけます。

デイリースクラムは進捗を報告する会議という誤解

デイリースクラムを、管理者に進み具合を報告する朝会だと考える人もいます。しかし、デイリースクラムは開発者のためのイベントで、スプリントゴールに向けて計画を調整する場です。

報告そのものが目的になると、問題を共有して計画を変える、という本来の役割が果たせなくなります。「昨日やったこと」を順番に話すだけで終わっていないか、スプリントゴールに近づくために今日何を変えるかを話せているかを確認しましょう。管理者が状況を知りたい場合は、スプリントバックログやスプリントレビューで確認する形にすると、デイリースクラムの目的を保てます。

一部のイベントだけ取り入れてもスクラムになるという誤解

デイリースクラムだけ、スプリントだけ、といった形で一部の要素を取り入れて、スクラムを実践していると考える場合があります。

スクラムガイドには、「スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない」と書かれています。要素はお互いにつながっているため、一部を省くと、問題を見つけて改善する仕組みが働きにくくなります。一部だけを取り入れる場合は、スクラムとは別の取り組みとして位置づけ、目的を明確にしておきましょう。
（出典：Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月）日本語訳」）

 

スクラムを実践するならLychee Redmine

当社が提供するLychee Redmineでは、スクラムの作成物とイベントを支える機能として、Neoバックログ・Neoカンバンをご利用いただけます。スクラムの運用を支える使い方を紹介します。

Neoバックログでプロダクトバックログとスプリントを計画する

Neoバックログでは、バックログの並び順を変更すると、チームの実績にもとづいてスプリントへの割り当てが自動で再計算されます。計算には、1スプリントで消化できるポイントの目安を示す「ベロシティ」を用います。

計算結果は、計画を検討するための目安です。実際に取り組む項目は、スプリントゴールや今回の稼働状況を踏まえ、プロダクトオーナーと相談しながら開発者が選びます。

見積もり（ストーリーポイント）の入力やステータスの変更も同じ画面で行え、スプリントゴールは画面の上部に常に表示されます。リリースラインごとにチケットを管理でき、期日に間に合わないチケットはアラートで知らせます。Neoバックログは、スタンダード・プレミアム・ビジネスの各プランで利用できます。

Neoカンバンでデイリースクラムの認識をそろえる

Neoカンバンは、Neoバックログと同じスプリント・同じチケットのデータを共有します。計画はNeoバックログ、実行はNeoカンバン、という形で使い分けられます。

プロダクトバックログの各項目（PBI）を表す親チケットごとに、子タスクをまとめて表示できます。デイリースクラムでは、開発者が同じ画面を見ながら、スプリントゴールへの進み具合を確認し、必要に応じて計画を調整できます。タスクはドラッグ＆ドロップで状態を更新でき、複数人が同時に開いていても、更新は自動で反映されます。スプリント中に新たに必要だとわかったタスクも、その場で追加できます。
（出典：Lychee Redmine「Neoバックログ」／Lychee Redmine「Neoカンバン」）

アジャイル導入支援で運用の定着を進められる

Lychee Redmineでは、企業のアジャイル開発の導入と定着を支援するコーチングサービスも提供しています。ツールを入れるだけでなく、現場の状況や課題に合わせた運用と改善を支援します。

ガントチャートを使うプロジェクトとNeoバックログを使うプロジェクトを同じ環境で管理できるため、一部のチームからスクラムを始められます。なお、Neoバックログが有効なプロジェクトでは、スプリント期間でチケットを絞り込んでガントチャートで確認する機能もあります。ただし、併用はスケジュールの二重管理につながりやすいため、日常的な運用には推奨されていません。上長やクライアントにスケジュールの根拠を示す必要がある場合など、やむを得ない場面に限って使いましょう。
（出典：Lychee Redmine「リリースノート Lychee Agile」）

Neoバックログの詳細は、次のページをご覧ください。

 

スクラムに関するよくある質問

最後に、スクラムについてよくある質問に回答します。スクラムを学び始めた段階で、迷いやすい点を中心に取り上げました。

スクラム開発とアジャイル開発は何が違いますか？

アジャイル開発は、価値観と原則にもとづく開発の考え方の総称です。スクラムは、その考え方を実践するための枠組みの一つです。つまり、スクラムで進める開発はアジャイル開発の一種といえます。詳しくは、次の記事で解説しています。

ラグビーのスクラムとは何ですか？

ラグビーで、反則などの後にプレーを再開するときに、双方の選手が組み合う体勢のことです。チームが一体となってボールを回しながら進むラグビーのたとえが、開発の枠組みとしての「スクラム」という名前の由来につながっています。

スクラムとカンバンは何が違いますか？

スクラムは、スプリントという決まった期間と、3つの責任・5つのイベントを定めた枠組みです。カンバンは、作業の流れを見える化し、同時に進める作業の量を抑えながら流れを改善する手法です。ほかのアジャイル開発の手法は、次の記事で紹介しています。

スクラムガイドはどこで読めますか？

公式サイト（scrumguides.org）で、日本語訳を含めて無料で公開されています。2026年10月時点の最新版は、2020年11月版です。2020年版の補助文書として「Scrum Guide Expansion Pack」も公開されていますが、スクラムガイド本体の改訂版ではありません。
（出典：Scrum Guides「Scrum Guides」／Scrum Guide Expansion Pack「Scrum Guide Expansion Pack」）

 

まとめ：スクラムの意味と仕組みを正しく理解し、チームで実践しよう

スクラムは、複雑な問題に対応しながら価値を生み出すための軽量級フレームワークです。経験主義とリーン思考を土台に、三本柱と5つの価値基準に支えられ、3つの責任・5つのイベント・3つの作成物で成り立っています。

要素をそろえて運用し、スプリントレトロスペクティブで改善を続けることが、スクラムを機能させるポイントです。まずはスクラムガイドを読み、チームで用語の意味をそろえるところから始めましょう。

スクラムのプロダクトバックログやスプリントを管理するなら、当社が提供するLychee Redmineもおすすめです。Neoバックログ・Neoカンバンを30日間の無料トライアルでお試しいただけます。