スクラム開発の機能は、3つの役割、5つのイベント、3つの作成物が組み合わさって、検査と適応を繰り返す仕組みとして働きます。
発注企業や情報システム部門の方に向けて、各要素が担う機能を順に説明します。全体像をまだ把握していない方は、まずスクラム開発の完全ガイドから読むことをおすすめします。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
スクラムの3つの役割が担う機能
スクラムの最も基本的な機能は、役割ごとに責任をはっきり分けることです。スクラムには、プロダクトオーナー（PO）、スクラムマスター（SM）、開発チームという3つの役割があり、それぞれが担う責任が重ならないよう設計されています。役割分担が曖昧だと、誰が優先順位を決め、誰が障害を取り除くのかが定まらず、スクラムは機能しません。
プロダクトオーナーが担う価値を最大化する機能
プロダクトオーナーの判断は、チームが何に時間を使うかを左右します。
- 作るものの決定：プロダクトの価値の最大化につなげる判断。
- バックログの優先順位づけ：限られた開発資源の配分を決める判断。
- 意思決定の窓口：チームの迷いを減らす、単一の窓口。
プロダクトオーナーは、「何を作るか（What）」に責任を持つ役割で、プロダクトの価値を最大化することを使命とします。スクラムでは作るものを事前にすべて固定しないため、「今のスプリントで何を優先すべきか」を決め続ける人が必要になります。その判断の権限と責任を一手に担い、バックログの優先順位づけを通じて、限られた開発資源を最も価値の高い機能に振り向けます。
優先順位の窓口が複数あると、開発チームは混乱します。たとえば、関係者それぞれが別の優先順位を主張すると、チームはどの作業を先にすべきか決められません。そこで、要望をすべて引き受けて唯一の優先順位リストにまとめることで、チームは迷わず作業に集中できます。
発注企業がスクラムを導入する際は、この役割を担える人材を社内に確保できるか、優先順位の判断を任せられるかが、成否を大きく左右します。
スクラムマスターと開発チームが担う機能
スクラムマスターと開発チームは、それぞれ次の機能を担います。
- スクラムマスター：進行を支え、障害を取り除く。
- 開発チーム：「どう作るか（How）」を決め、スプリント内で動くソフトウェアを完成させる。
- 自己完結型のチーム：連携待ちの減少と、主体性の向上につながる。
スクラムマスターは、チームがスクラムを正しく機能させられるよう支援する役割です。進捗を管理する従来のプロジェクトマネージャーとは違い、チームの自己組織化を促すことに専念します。会議の進行（ファシリテーション）やスクラムの原則の浸透、外部からの割り込みを防ぐ役割を通じて、開発チームが集中できる環境を整えます。
この役割は専門性が高く、国内の有資格者は不足しています。そのため、外部からスクラムマスターを調達する選択肢も現実的です。
理想は、外部に頼らず機能を完成できる自己完結性（クロスファンクショナル）を、開発チームが備えることです。加えて、国内のアジャイルチームの約8割は、8名以下で構成されています。
少人数で自己完結する設計があるからこそ、迅速な意思決定と高い当事者意識が生まれます。三つの役割が「何を・どう支援し・どう作るか」を分担する点こそ、スクラムが提供する最も根本的な機能です。
役割をRFPでどう調達するかについては、『スクラム開発のRFP・要件定義書・提案依頼書について』もあわせてご覧ください。
スクラムの5つのイベントが担う機能
スクラムのイベントは、検査と適応のリズムを作る機能を担います。スプリントという固定期間の中で、計画・進捗確認・成果確認・振り返りの四種類のイベントが回ります。また、これらを包むスプリントそのものも、五つのイベントの一つです。
国内のアジャイル開発では、半数が2〜4か月で行われるとされます。その中で、1〜4週間のスプリントを繰り返すのが一般的です。各イベントの役割を、順に見ていきます。
スプリント・プランニング・デイリースクラムの機能
スプリントの計画と毎日の確認は、期間内に作業を前に進めるための仕組みです。
- 計画と予測のリズム：固定長の期間が、計画と予測を立てやすくする。
- スプリントプランニング：優先順位を踏まえて、実施範囲を決める。
- デイリースクラム：進捗と障害を、毎日の短い時間で早期に確認する。
スプリントは、すべての作業を包む1〜4週間の固定期間です。この中で、動くソフトウェアを必ず一つ完成させます。
スプリントプランニングは、スプリントの開始時に行われ、開発チームが現実的な作業量を見積もります。
デイリースクラムの目的は、進捗の報告で終わらせず、「スプリントゴール達成を妨げる障害を早期に発見し、その日の作業を調整する」ことにあります。
15分程度のタイムボックスで行い、長時間の議論は、その場では扱わず別途行うのが原則です。こうした毎日の短い検査によって、問題が大きくなる前に手を打てる点が、デイリースクラムの最大の価値です。
スプリントレビューとレトロスペクティブの機能
レビューとレトロスペクティブは、動くものへの反応と働き方の振り返りを、次の行動につなげる場です。
- スプリントレビュー：動くものへの関係者の反応を、次の計画に反映する。
- レトロスペクティブ：次回に行う具体的な改善を決める。
- 根本原因の把握：5 Whysなどで、表面ではなく根本の原因を探る。
スプリントレビューは、スプリントの終わりに実際に動くものをステークホルダーに見せ、フィードバックを得るイベントです。資料で進捗を説明するよりも、実物を見せることに意味があります。
そのため、プロダクトオーナーやステークホルダーは「思っていたものと違う」というズレを早い段階で見つけ、次のスプリントの優先順位に反映できます。レビューは、市場やユーザーの反応を開発に取り込む「適応」の入口の役割を果たします。
スプリントレトロスペクティブは、チーム自身の働き方を振り返り、次のスプリントでの改善策を決めるイベントです。ここで陥りやすいのは、単なる不満の発表会になってしまうことです。
一方で、本来のレトロスペクティブは、「何がうまくいき、何を変えるか」を建設的に話し合い、具体的な改善アクションを一つでも決めて次に生かす場です。問題の根本原因を掘り下げる「5 Whys」のような手法を使い、表面的な現象ではなく構造的な原因にたどり着くことが、振り返りの質を高めます。
レビューが動くものを、レトロスペクティブが進め方を改善する、という役割分担です。この二つの振り返りが、スクラムの継続的改善という機能を支えています。
スクラムの3つの作成物が担う透明性の機能
スクラムの作成物は、透明性を確保する機能を担います。三つの作成物は、残っているもの、今回行うこと、完成したものを、それぞれ見えるようにします。プロダクトバックログ、スプリントバックログ、インクリメントがこれに当たります。
透明性はスクラムの基本となる考え方の一つです。特に、検査と適応は、この見える状態の情報を前提に成り立っています。
プロダクトバックログとリファインメントの機能
プロダクトバックログとリファインメントは、これから作るものを見える状態に保つ働きをします。
- 作る機能の優先順位づけ：プロダクトバックログで、作る順番を決める。
- リファインメント：項目の分解と見積もり、内容の更新を行う。
- 定期的な手入れ：作成物の透明性を保つ。
プロダクトバックログは、これから作るべき機能や改善を優先順位順に並べた一覧です。スクラムでは、やることリストの「単一の真実」として機能します。
完成形を固定する仕様書とは違い、上位の項目ほど詳しく、下位はざっくり書きます。そのうえで、状況に応じて随時並べ替えます。
優先順位を機動的に変えられるため、要件が変わっても契約をやり直さずに吸収できます。これがスクラムの強みです。
このバックログを健全に保つ活動が、バックログリファインメントです。上位の項目を実装できる粒度まで分解し、見積もりを更新して、不要になった項目を整理します。この継続的な手入れを怠ると、スプリントプランニングの場で項目の意味が分からず、議論が紛糾してしまいます。
リファインメントは正式なイベントには数えられません。しかし、バックログの透明性を保つ、重要な運用の機能です。
バックログの各項目は、後述するユーザーストーリーの形で書かれることが多いです。その書き方は、要件定義の章で詳しく扱います。
インクリメントと完成の定義（DoD）の機能
インクリメントの品質は、完成の基準と自動化の仕組みで支えられます。
- インクリメント：スプリントごとに完成し、リリースできる増分。
- DoD：テスト、レビュー、文書などの完成基準を明文化する。
- CI：変更の統合と自動テストで、品質を保つ。
インクリメントは、各スプリントで完成し、リリース可能な状態になったプロダクトの増分です。スプリントを重ねるごとに積み上がり、プロダクトが育っていきます。
インクリメントの品質を支えるのが、完成の定義（Definition of Done、DoD）です。DoDは、「どこまでやったら完成とみなすか」をチームで合意した基準です。DoDが曖昧だと、メンバーがそれぞれの基準で「完成」を宣言してしまい、後工程で手戻りが起きます。
インクリメントの品質を毎スプリント安定させるうえで、運用面では継続的インテグレーション（CI）が重要な役割を果たします。コードの変更を頻繁に統合し、自動でテストするCIによって、スプリントの短いサイクルでも品質を保ったまま機能を積み増せます。
実際、大規模アジャイルの約7割がCIを実施しているとされ、規模が大きくなるほど、この自動化の重要性は増します。作成物は透明性を、DoDは品質の基準を、CIは品質を保つ自動化を担います。この三つが揃って初めて、毎スプリント信頼できるインクリメントを生み出せます。
ベロシティと見積もりが担う予測の機能
スクラムには、進捗を予測し、見えるようにする仕組みもあります。作業量はストーリーポイントで見積もり、ベロシティで計測します。バーンダウンチャートで進捗を見える化し、「あとどれくらいで終わるか」を関係者に示します。
これらは作成物や正式なイベントには当たりません。一方で、スクラムを実務で回すうえで欠かせない運用の仕組みです。
ストーリーポイントとプランニングポーカーの機能
相対見積もりとプランニングポーカーは、作業量の見積もりをチームの対話に変える手段です。
- ストーリーポイント：人日ではなく、相対的な作業量で見積もる。
- プランニングポーカー：全員の見積もりを同時に示す。
- 見積もりの差：リスクや前提のずれに気づくきっかけになる。
ストーリーポイントは、基準となる小さな作業を1として、それと比べて何倍の労力がかかるかで作業量を表す方法です。時間で見積もると個人差や心理的なプレッシャーが入り込みやすいのに対し、相対見積もりは、チームの共通認識を作りやすいという利点があります。
見積もりを全員で行うこの手法は、声の大きい人に引きずられず、多様な視点を見積もりに反映できる点が特徴です。プランニングポーカーの価値は、数字を当てることよりも、見積もりの過程で生まれる対話にあります。
あるメンバーが大きく見積もり、別のメンバーが小さく見積もったとき、その差を話し合うことで、作業に潜むリスクや前提のズレが表面化します。さらに、見積もりは要件の理解を深めて認識を揃える機能も兼ねています。
ストーリーポイントによる見積もりには賛否の議論もあり、その判断については『スクラム開発のメリット・デメリット・効果と判断基準について』で詳しく扱います。
ベロシティとバーンダウンによる見える化
ベロシティとバーンダウンは、進捗を見える化し、先の見通しを立てるための仕組みです。
- ベロシティ：同じチームの完了量をもとに、先の見通しを立てる。
- バーンダウンチャート：計画に対する残作業を見える化する。
- ベロシティの使い方：チーム間の比較ではなく、チーム内の予測に使う。
ベロシティは、チームが1スプリントで完了できるストーリーポイントの量で、チームの実力を示す指標です。過去数スプリントのベロシティが安定してくれば、残りのバックログのポイント総量を割ることで、おおよその完了時期を予測できます。
そのため、要件を固定しないスクラムでも、「いつ頃どこまで到達するか」を関係者に説明できます。ベロシティは、そのチームの見積もり基準で測った数字です。
バーンダウンチャートは、残作業量が時間とともに減っていく様子を示すグラフです。スプリントやプロジェクトの進み具合は、線が予定より上にあれば遅れ、下にあれば前倒しと、誰が見ても把握できます。
ベロシティとバーンダウンによる見える化があるからこそ、デイリースクラムでの調整や、スプリントレビューでの説明に説得力が生まれます。
見積もり、実力、進捗を一連でつなぐ予測の機能が、不確実性の高い開発に秩序と説明のしやすさを与えています。
まとめ
スクラムの機能は、3つの役割で責任を明確にし、5つのイベントで検査と適応を繰り返し、3つの作成物で透明性を保つという三層の構造にまとめられます。プロダクトオーナーは何を作るかに、開発チームはどう作るかに責任を持ち、スクラムマスターがその全体を支援します。
スプリントからレトロスペクティブまでのイベントが短いサイクルで改善を回し、プロダクトバックログとインクリメントが、進むべき方向と達成済みの成果を見えるようにします。さらに、ストーリーポイント・ベロシティ・バーンダウンが進捗を予測可能にし、CIが品質を支えます。
これらの構成要素は、揃えたうえで運用し続けて初めて力を発揮します。各役割の権限を明確にし、イベントの目的を見失わず、作成物を手入れし続けることが前提になります。
国内ではスクラムマスターの担い手が不足しているため、外部の専門人材を活用しながら内製化を進めるのも、現実的な選択肢です。また、riplaは、フルスクラッチ受託と外部スクラムマスターの提供を通じて、これらの機能を自社に正しく実装する支援を行っています。全体像を改めて確認したい方は、完全ガイドをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。