スクラム開発とは？流れ・役割・発注者の関与ポイントを徹底解説
開発会社の担当者から「アジャイル開発（スクラム）で進めましょう」と提案された経験はありませんか。「ウォーターフォールと違って途中で仕様変更できます」「スプリントを2週間単位で回します」と説明されたものの、具体的に何がどう動くのかイメージできず、不安を感じている発注者の方は少なくありません。
インターネットにはアジャイルやスクラムの解説記事が多数ありますが、その多くは「スクラムとは何か」という概念説明が中心です。「発注者として何を準備すれば良いか」「スプリントレビューにはどのくらい参加しなければならないか」「自社プロジェクトにスクラムは本当に向いているのか」という実践的な疑問に答える記事は意外と見当たりません。
本記事では、アジャイル開発とスクラムの基本知識に加え、開発会社に外注する立場の発注者が知っておくべき実際の開発の流れと関与ポイントを中心に解説します。スクラムを選ぶかどうかの判断に必要な情報をまとめていますので、ぜひ最後までお読みください。
目次
失敗しないためのシステム開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
こんな方におすすめです
アジャイル開発とは？ウォーターフォールとの違いを3分で理解する
アジャイル開発の詳しい手法や導入ポイントについてはアジャイル開発とは？アジャイル開発の手法から導入のポイントまで徹底解説！もあわせてご覧ください。
アジャイル開発の基本概念
アジャイル開発とは、システムやソフトウェアを小さな機能単位に分けて開発・テストを繰り返しながら進める開発手法です。「アジャイル（agile）」は英語で「素早い・俊敏な」を意味し、変化する要件に柔軟に対応できることが最大の特徴です。
ウォーターフォール開発との違い（比較表）
アジャイル開発と並んで代表的な開発手法が「ウォーターフォール開発」です。以下の表で違いを整理します。
項目 |
ウォーターフォール開発 |
アジャイル開発 |
|---|---|---|
進め方 |
要件定義→設計→開発→テスト→リリースと順番に進む |
小さな単位で開発・テストを繰り返す |
要件確定のタイミング |
プロジェクト開始前に全要件を確定 |
スプリントごとに優先度を見直せる |
途中変更への対応 |
変更コストが高い（手戻りが大きい） |
変更を前提とした設計で対応しやすい |
リリースのタイミング |
プロジェクト完了後に一括リリース |
スプリントごとに動くものをリリース可能 |
コストの見通し |
事前に総コストを把握しやすい |
スプリント単位の見積もりとなり変動する |
発注者の関与頻度 |
要件定義フェーズと検収時が主 |
スプリントごとのレビューで継続的な関与が必要 |
ウォーターフォール開発の詳しい特徴や失敗・成功事例については、システム開発のウォーターフォール開発とは？アジャイル開発との違いやメリット・デメリットを徹底解説で詳しく解説しています。
スクラムとは？アジャイル開発のなかでのスクラムの位置づけ
「アジャイル開発」と「スクラム開発」は同じ意味で使われることがありますが、正確には異なります。
アジャイル = 思想・価値観（「変化に柔軟に対応する」という考え方）
スクラム = アジャイルを実現するための具体的なフレームワーク（役割・イベント・作成物を定義したルールセット）
ラグビーの「スクラム」を語源とし、チームが一体となって開発を進めることを重視します。スクラムはアジャイルの手法の一つですが、現在では最も広く使われているフレームワークです。
アジャイルの主な手法を比較すると次の通りです。
手法 |
特徴 |
向いている場面 |
|---|---|---|
スクラム |
役割・イベントが明確に定義されたフレームワーク |
新機能開発・プロダクト開発 |
カンバン |
タスクをボードで可視化し、継続的なフロー管理を重視 |
運用・保守・サポート業務 |
XP（エクストリームプログラミング） |
ペアプログラミング・テスト駆動開発など技術プラクティスを重視 |
コード品質を最重視する開発 |
開発会社から「アジャイルで進めます」と言われた場合、その多くは「スクラムを採用する」という意味であることが一般的です。
スクラム開発の3つの役割と発注者が知るべきこと
スクラムには明確に定義された3つの役割があります。この役割の理解が、発注者として「自分は何をするのか」を把握するための出発点になります。
プロダクトオーナー（PO）の役割
プロダクトオーナー（PO）は**「何を作るか」を決める責任者**です。主な役割は以下の通りです。
- プロダクトバックログ（開発すべき機能のリスト）の作成・管理
- 各機能の優先順位の決定
- スプリントレビューで開発成果を確認し承認
- ステークホルダー（経営者・ユーザー等）の要望を整理してチームに伝える
POはビジネス側の代表者として開発チームと日常的にコミュニケーションを取る必要があります。スクラムにおいてPOは非常に責任が重い役割であり、十分な権限を持つ人物がこの役割を担うことが求められます。
スクラムマスター（SM）の役割
スクラムマスター（SM）はスクラムが正しく機能するよう支援する役割です。チームのコーチ・ファシリテーターとして機能します。
- デイリースクラム・スプリントレビューなどのイベントのファシリテーション
- 開発チームの障害（ブロッカー）の除去
- スクラムの原則をチームに浸透させる
- プロダクトオーナーとの連携支援
SMはプロジェクトマネージャーとは異なり、チームに指示を出す立場ではありません。チームが自律的に動けるよう環境を整えることが主な仕事です。
開発チームの役割
開発チームは実際にプロダクトを作る専門家たちです。スクラムでは3〜9人の規模が推奨されています。チームは自己組織化されており、「誰が何をするか」をチーム内で決定します。
受託開発でのPO体制パターン
受託開発（外注）では、POを誰が担うかが重要な論点になります。主なパターンは次の通りです。
パターン |
概要 |
発注者の関与度 |
|---|---|---|
発注者がPOを担う |
発注者側の担当者がPOとして参加 |
高（スプリントごとのレビュー・優先度決めに参加） |
外注先がPOを兼任 |
開発会社の担当者がPOを務める |
低〜中（主要な意思決定のみ関与） |
ハイブリッド型 |
発注者がビジネス要件を、開発会社がPOとして要件を整理 |
中（定期的なすり合わせに参加） |
発注者側でPOを担う場合、スプリントごとにバックログの優先度を決める判断や、スプリントレビューへの参加が求められます。「週に2〜3時間程度の時間を確保できるか」は、スクラムを選ぶ際の重要な判断基準です。
スクラム開発の流れ（スプリントサイクル）を発注者目線で解説
スクラム開発の核となる仕組みが「スプリント」です。スプリントとは、1週間〜4週間の固定された開発期間のことで、この単位を繰り返しながらプロダクトを作り上げていきます。一般的には2週間のスプリントが多く採用されています。
1回のスプリントの中には、4つの主要イベントが含まれています。
スプリント計画（スプリントプランニング）
スプリントの開始時に行われるイベントです。
- プロダクトバックログから今のスプリントで実装する機能を選ぶ
- スプリントゴール（このスプリントで達成したいこと）を設定する
- 選んだ機能をスプリントバックログ（今スプリントのToDoリスト）に落とし込む
発注者の関与: POとして参加する場合は、「今スプリントで何を優先するか」の意思決定に参加します。どの機能を先に作るかはビジネス上の判断が必要なため、発注者の意向が直接反映されます。
デイリースクラム
スプリント期間中、毎日15分行われる短いミーティングです。
- 昨日やったこと・今日やること・困っていること（ブロッカー）を共有
- 開発チームのコミュニケーションを目的としたもので、報告会ではない
発注者の関与: 基本的には開発チームとSMが参加するもので、発注者がデイリースクラムに参加する必要はありません。ただし、意思決定が必要なブロッカーが発生した場合は迅速な対応が求められます。
スプリントレビュー（発注者が参加する場面）
スプリントの終了時に行われる最重要イベントです。
- スプリントで完成した機能を実際にデモして確認する
- ステークホルダー（発注者・経営者等）がフィードバックを提供する
- 次のスプリントに向けてバックログを調整する
発注者の関与: スプリントレビューは発注者が参加すべき場面です。「動いているプロダクト」を実際に確認し、方向性のズレを早期に発見できます。ウォーターフォール開発では完成まで実物を確認できないのに対し、スクラムでは2週間ごとに動く成果物を確認できます。これがスクラムの最大のメリットの一つです。
スプリントレトロスペクティブ
スプリントレビューの後、チームの振り返りを行うイベントです。
- うまくいったこと・改善すべきことを議論
- 次のスプリントへの改善アクションを決める
- 基本的にはスクラムチーム（開発チーム・SM・PO）の内部のイベント
発注者の関与: 通常、発注者がレトロスペクティブに参加する必要はありません。ただし、発注者との関係性やコミュニケーションについての議題がある場合は招待されることもあります。
バックログの管理と優先順位決め
スクラムでは、プロダクトバックログ（実現したい機能・改善のリスト）を常に最新の状態に保つことが重要です。
- プロダクトバックログは「ユーザーストーリー」と呼ばれる形式で記述されることが多い（例:「ユーザーとして〜したい」）
- POが優先順位を決め、スプリントごとに上から順に開発する
- バックログの精緻化（バックログリファインメント）として、定期的に内容を見直す
発注者がPOを担う場合、バックログの管理と優先順位決めは最も重要な仕事の一つです。「次のスプリントで何を作るか」を決める責任を持ちます。
失敗しないためのシステム開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
こんな方におすすめです
スクラム開発のメリット・デメリット
スクラムを選ぶかどうかを判断するために、発注者視点でのメリットとデメリットを整理します。
メリット
1. 要件変更に柔軟に対応できる スプリントごとにバックログの優先度を見直せるため、ビジネス状況の変化や新しいアイデアを開発に反映しやすい構造です。ウォーターフォールでは仕様変更のたびに大きなコストが発生しますが、スクラムでは次のスプリントで対応することで変更コストを最小化できます。
2. 早期にリスクを発見できる スプリントごとに動くプロダクトを確認するため、「思っていたものと違う」というズレを早期に発見できます。開発の後半で方向性のズレが発覚した場合の手戻りコストを大幅に削減できます。
3. 早期リリースでビジネス価値を早く届けられる 完成した機能から順にリリースできるため、完成を待たずにユーザーが使い始めることが可能です。市場の反応を見ながら開発を続けることができます。
4. 透明性が高い スプリントの進捗やバックログが可視化されるため、発注者として現状把握がしやすい。ウォーターフォールのように「開発中はブラックボックス」になりにくいです。
デメリット
1. 総コストの見通しが立てにくい スプリント単位の見積もりとなるため、プロジェクト全体の費用を事前に正確に把握するのが難しい面があります。予算管理の観点からは不確実性が高まります。
2. 発注者の関与コストが増加する スプリントレビューへの参加やバックログの優先度決めなど、発注者が定期的に時間を確保する必要があります。「依頼したら後はお任せ」という進め方には向いていません。
3. プロジェクト完成形が見えにくい スクラムは変化を前提とした手法であるため、「最終的にどんなシステムが完成するか」を事前に定義することが難しく、ゴールイメージの共有が重要になります。
スクラム開発が向いているプロジェクト・向いていないプロジェクト
スクラムが適しているかどうかは、プロジェクトの性質によって異なります。以下を参考に判断してください。
スクラムが向いているプロジェクト
- 要件が変わりやすいプロジェクト: ユーザーフィードバックを受けながら機能を追加・変更していくWebサービス・アプリ開発
- MVPを早くリリースしたいプロジェクト: まず最低限の機能でリリースし、市場の反応を見ながら改善していく新規サービス開発
- ユーザーニーズが開発中に明確になるプロジェクト: ターゲットユーザーの反応を見ながら方向性を決める必要があるプロダクト
- 発注者が積極的に関与できる体制があるプロジェクト: スプリントレビューへの参加やバックログ管理に時間を割ける場合
スクラムが向いていないプロジェクト
- 要件が完全に固まっているプロジェクト: 仕様が変更されることが想定されず、決まった機能を決まった期限で作ればよい場合はウォーターフォールのほうが効率的
- 発注者が関与できない体制のプロジェクト: スプリントレビューや優先度決めに時間を確保できない場合、スクラムの恩恵を受けにくい
- 法的・安全基準が厳格なシステム: 医療・金融・航空など、変更のたびに厳密な承認プロセスが必要な分野ではスクラムの柔軟性が活かしにくい
- 短期の固定スコープ案件: 「この機能だけを3週間で作る」といったシンプルな案件では、スクラムのオーバーヘッドが不要になることもある
判断のポイント: 「プロジェクト中に要件が変わる可能性があるか」「発注者側でスプリントレビューに参加できる担当者がいるか」の2点が、スクラムを選ぶかどうかの主要な判断軸です。
スクラム開発の導入を検討するときに確認すべき5つのポイント
開発会社にスクラムでの開発を依頼する場合は、事前に以下の5点を確認することをお勧めします。
1. スプリント期間はどのくらいか
一般的には1〜4週間ですが、2週間が最も多く採用されます。スプリント期間が短いほど方向修正が速くできますが、スプリントレビューへの参加頻度も上がります。自社の業務スケジュールに合わせた期間を相談しましょう。
2. スプリントレビューへの参加頻度と形式
スプリントレビューは発注者が参加することが期待されます。「週に1回？2週間に1回？」「オンライン参加可能か？」「所要時間はどのくらいか？」を事前に確認し、社内で時間を確保できるか判断します。
3. プロダクトオーナー体制はどうなるか
発注者側でPOを担うのか、開発会社側がPO機能を持つのかを明確にしましょう。発注者がPOを担う場合は、「バックログの優先度決め」や「要件の意思決定」に定期的に関与する必要があります。これができない場合は、ハイブリッド型の体制を相談しましょう。
4. バックログ管理のツールと可視性
スクラムではJiraやAsanaなどのプロジェクト管理ツールが使われることが多いです。発注者もツールにアクセスでき、進捗をリアルタイムで確認できるか確認しましょう。透明性の高い進行管理が、発注者としての安心感につながります。
5. 契約形態と見積もりの方法
スクラム開発では、以下の契約形態が一般的です。
- 準委任契約（タイムアンドマテリアル型）：実際に使った工数に対して報酬を支払う形式。変化に柔軟に対応できるが、総コストの予測が難しい。アジャイル開発との相性が良い
- 請負契約（固定価格型）：成果物の完成に対して固定料金を支払う形式。コストの見通しが立てやすいが、仕様変更のたびに追加費用が発生しやすい
受託開発における契約形態の詳しい解説（完成責任・契約不適合責任・指揮命令権の違い等）については、ソフトウェアの受託開発とは？メリット・デメリットや費用相場を紹介をご参照ください。
初めての場合は「最初の1スプリントだけ試してみる」というトライアル形式を提案してみるのも有効です。
まとめ
アジャイル開発とスクラム開発の基本から、発注者が知るべき実践的な内容まで解説しました。要点を整理します。
- アジャイル = 変化に対応するための開発の考え方。スクラムはその代表的なフレームワーク
- スクラムは役割（PO・SM・開発チーム）とイベント（スプリントサイクル）が明確に定義されている
- 発注者に最も関係するのはPOの役割とスプリントレビューへの参加。発注者の関与なしにスクラムは機能しにくい
- スクラムが向いているのは「要件が変わりやすく、発注者が定期的に関与できる」プロジェクト
- 開発会社への発注前に、スプリント期間・PO体制・契約形態の3点を確認することが重要
スクラム開発を選ぶかどうかの判断は、技術的な知識よりも「自社がどのくらいプロジェクトに関与できるか」と「要件の変更可能性がどのくらいあるか」という視点から考えると整理しやすくなります。
システム開発の外注をお考えの方は、ぜひソフトウェアの受託開発とはもあわせてご覧ください。受託開発の基本的な知識と開発会社の選び方を解説しています。
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
秋霜堂株式会社について
秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。
システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。
失敗しないためのシステム開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
こんな方におすすめです
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
