スクラムについて
スクラムとは
スクラム(Scrum)とは
スクラムとは、スクラムチームを組み、短期間内でのリリースサイクル(分析、設計、実装、テスト)を繰り返し、プロダクトを完成させるアジャイル開発手法です。
公式には「複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。」と定義されています。
スクラムという語源は、その方法論として「チーム力」を重視することから、ラグビーにおいて各チームの8人ずつが肩を組む「スクラム」に喩えて名付けられています。
スクラムの3本柱と5つの価値基準
スクラムの3本柱は、スクラムイベントを機能させるために必要な要素です。
Transparency(透明性) |
透明性とは、状況を可視化することです。 作業遅延や技術課題などを含めて、今なにをしているか、どのような状況なのか見えるようにすることです。 公式には「創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。」とあります。 |
Inspect(検査) | 検査は、プロジェクトの状態を検証することです。 望ましくない変化や問題に気づくために、作成物や進捗状況は頻繁かつ熱心に検査する必要があります。 |
Adapt(適応) | 適応とは、検査によって得たものをプロジェクトに適応することです。 プロセスやプロダクトが許容範囲を逸脱する状況であれば、出来るだけ早く軌道修正を図ること。 |
5つの価値基準は、スクラムチームの行動指針となります。
スクラムの三本柱の実現には、これらの価値基準を体現することが必要です。
確約 | チームは、ゴールを達成し、お互いにサポートすることを確約する。 |
勇気 | チームは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。 |
尊敬 | チームのメンバーは、お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬される。 |
公開 | スクラムチームとステークホルダーは、作業や課題を公開する。 |
集中 | チームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。 |
スクラムの効果について
スクラムとは、プロジェクトの状況を把握するためのフレームワークです。
なので、スクラムという方法論自体には、直接的な問題解決する方法は提示されていません。
つまり、「問題を発見するが、問題を解決するものではない。」という点に注意が必要です。
スクラムの開発体制
スクラムチーム
スクラムの基本単位はスクラムチームという小さなチームとなります。
チームの人数は、5人から9人が適当とされ、実装とテストの能力を持ちます。
このチームは、作業プロセスと作業結果に対して責任を持ち、自らチーム内の管理を実施する「自己管理型の組織」です。
プロダクトオーナー(ProductOwner: PO)
プロダクトオーナーは、製品の総責任者であり、顧客意思の代表としての役割を担います。
顧客の要望(ユーザーストーリー)を明確にし、意図や内容を関係者に明確に伝えることが求められます。
環境変化や顧客からのフィードバックを受けた際には、作業の優先順位を入れ替える役割を担当します。
スクラムマスター(ScrumMaster: SM)
SMは、スクラムがフレームワークとして正しく適用されていることを保証する役割を担います。
スクラムチームに対して、スクラムを理解・実践できるようにすること、および継続的な改善を支援することに責任を持ちます。
そのために、スプリント計画、デイリーミーティングの主導、レトロスペクティブ(振り返り)の実施を担当します。
開発者
スクラムにおける開発者とは、利用可能なインクリメント(完成の定義が満たされ、リリース可能な成果物)を作成する役割とされています。
開発者はスプリントにおいて行う作業や成果物を計画し、完成の定義を満たす成果物の作成にあたります。
スクラムにおいて、開発者は上司からの指示を受けて活動するではなく、自発的に活動する必要があります。
【備考】スクラムチームの成熟について
スクラムでは、「チームコミュニケーション」こそが最も重要な要因となります。
つまり、効果を最大化するには、円滑なコミュニケーションが可能なように、チームのメンバーが固定されている必要があります。
そして、固定メンバーのプロジェクトチームを結成してから、何度か失敗と改善を繰り返して、チームを成熟させていく必要があります。
一般的には、スクラムでチームを本格的に始動するには、チーム結成から最低3か月かかるといわれています。
スクラムイベントと作成物
5つのスクラムイベント
スクラムイベントとは、スクラム開発を実践する上で開発を円滑に進めるために定期的に実施する打合せのことです。
このイベントは、透明性、検査、適応性を確保し、チームが協力しながら作業を進めるための手段となります。
イベント | 説明 |
---|---|
スプリント | スプリントとは、実際にソフトウェア開発が行われる工程です。 期間(基本的に1ヵ月以内)を定めて、プロダクトゴールが達成されるまで反復的(イテレーティブ)に何度も繰り返されます。 |
スプリントプランニング | スプリントプランニングは、スプリントの起点であり、スプリントで実行する作業の計画を立てます。 当該スプリントで開発者が実施すべきタスクを明確にします。 |
デイリースクラム | デイリースクラムは、毎日(同刻、同所、最長15分)進捗や問題を確認する打合せです。 チームメンバーがお互いの状況や課題を把握することを目的とします。 |
スプリントレビュー | スプリントレビューは、ステークホルダーに対して、当該スプリントの成果のデモを実施します。 フィードバックや改善点を引き出すことを目的とします。 |
スプリントレトロスペクティブ(振り返り) | スプリントレトロスペクティブは、スプリントに対する振り返りを実施します。 スプリント中にどのような問題が発生したかを特定し、その原因を調査し、解決策を検討します。 |
3つのスクラムの作成物
指定 | 説明 |
---|---|
プロダクトバックログ | プロダクトバックログとは、プロダクトに必要な機能を項目として挙げ、優先順に並べた一覧です。 ユーザのフィードバック、環境変化、技術進歩等を受けて、POが常に優先順位を更新します。 |
スプリントバックログ | スプリントバックログとは、プロダクトバックログを開発者が実施出来るタスクの粒度にまで落とし込んだ計画項目です。 デイリースクラムで進捗が検査できる程度の粒度で作成します。 |
インクリメント | インクリメントとは、プロダクトバックログの項目をもとに作られる各作成物です。 インクリメントをまとめたものをスプリントレビューで提示することになります。 |
スクラムの開発プロセス
プロダクトバックログとスプリント
プロダクトバックログは、プロダクト全体に対する要求です。
プロダクトバックログからスプリント用にスプリントバックログを抽出します。
スプリントにおいて、スプリントバックログを完成させ、イテレーション単位の成果物を作成します。

スプリントの流れ
スプリントでは、プランニング、開発作業、レビュー、レトロスペクティブを実施します。
スプリントレビューにおいて、スプリントで開発した機能を関係者にデモンストレーションします。
