スクラム開発とは何か？特徴やメリット、プロセスをやさしく解説
スクラム開発の概要
スクラム開発はアジャイル開発手法の１つです。ラグビーのスクラムが語源となっており、ラグビー選手がスクラムを組むようにして、チーム一丸となって開発に取り組む、コミュニケーションを重視した手法です。
スクラム開発では、少人数のチームメンバーが目的を達成するために協力し合いながら作業を進めるのを特徴としており、プロジェクト期間中にすべての機能を一気に制作するのではなく、短い期間（スプリント）ごとに機能をいくつか開発していきます。
現在採用されているプロダクト開発の手法には、従来主流であった「ウォーターフォール開発」と、2000年頃から取り入れる企業が増加した「アジャイル開発」があります。
プロジェクト初期に立てた計画を重視するウォーターフォール開発に対し、アジャイル開発ではチームメンバーや関係者からフィードバックを定期的に受けながら柔軟に計画を調整しようとする開発思想です。
そのアジャイル開発を実践する手法の１つがスクラム開発です。
スクラム開発の特徴
スクラム開発には、以下の特徴が挙げられます。
- 要求を価値・リスク・必要性を基準にして並べ替えてその順にプロダクトを作ることで成果を最大化する
- 固定の短い時間（タイムボックス）に区切って作業を進める
- 現在の状況や問題点を常に明らかにする（透明性）
- 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか仕事の進め方に問題がないかどうかを確認する（検査）
- やり方に問題がある・もっとうまくできる方法があればやり方そのものを変える（適応）
スクラム開発は不確定要素の多い複雑な問題を扱うのに適した手法で、最低限のルールで構成されています。
そのため、自分たちの開発に合ったルールを適用させていく必要があるのです。
スクラム開発のルールは「スクラムガイド」で定義されており、2010年に初版が公開されて以降１年～２年ごとに内容は改訂されています。
- 参考：Scrum Guides
また、ソースコードの記述ルールやテスト項目や実施方法などのスクラム開発で決められていない部分には、自分たちの状況を踏まえて取り組んでいく必要があります。
スクラム開発の役割
スクラム開発におけるチーム編成は以下の役割で構成されます。
プロダクトオーナー
プロダクトオーナーはプロダクトの価値を最大にすることに責任を持つ役割です。
主な作業として、プロダクトバックログ（ロードマップと要件に基づいて開発チームが取り組む作業に優先順位を設定したリスト）を作成・管理します。
プロダクトの費用対効果を考慮しつつ、チームメンバーがスムーズに作業に取り組めるようプロダクトバックログの明確化や開発の動機づけに努めます。
プロダクトオーナーは作業の指示権限を持ちませんが、チーム全体の進行管理と状況に応じた適切な対応が必要です。
スクラムマスター
スクラムマスターは開発チームの価値を最大にする責任を持つ役割です。
開発チームのメンバーが後述するスクラムイベントの内容を把握し、スプリントを円滑に回すために動きます。
また、プロダクトオーナーに対して開発チームの状況を報告したり、ステークホルダー（企業の利害関係者）に開発プロセスの実態や狙いを説明したりします。
スプリント実施中は、スプリントバックログの開発に貢献しない活動がないか監督し、改善していくことも役割の１つです。
スクラムチーム
スクラムチームはスプリントごとにプロダクトを提供することに責任を持つ役割です。
プロダクトの開発を行い、リリースできるかどうかはスプリントレビュー時に判断されます。
また、スクラムチームは、新たな開発プロセスや手法を採用したり、改善の方法を決定したりといった取り組みにおいても積極的に動きます。
これらスクラム開発の体制については、下記の記事もご参照ください。
https://ssaits.jp/promapedia/role/scrum-development-system.h...スクラム開発のプロセス
スクラム開発のプロセスは、「スプリント」と言う反復期間を繰り返すことで機能を追加で開発していきます。スプリントについては、下記の記事もご参照ください。
また、スプリントでは以下のスクラムイベントが実施されます。
スプリントプランニング
プロダクトオーナーとチームメンバーは、全体のプロダクトバックログの中からスプリントで実装する機能をスプリントプランニングで決定します。
この中で実装が決まった機能一覧は「スプリントバックログ」と呼ばれます。
デイリースクラム
チームメンバーは、デイリースクラムと呼ばれる毎日の短時間のミーティングで、開発の進行状況や課題などを共有し、その日の仕事の進め方を決めます。
スプリントレビュー
スプリントの最後にはスプリントレビューを実施し、ステークホルダーに向けて開発した機能をデモンストレーションし、フィードバックをもらいます。
スプリントレビューの結果に問題がなければ機能はリリースされ、問題がある場合には次回以降のスプリントまでリリースは持ち越されます。
スプリントレトロスペクティブ
スプリントレビューの終了後にチームで今回のスプリントを振り返り、次回のスプリントに向けて改善計画を立てます。
スクラム開発のメリット
スクラム開発のメリットには以下の３つがあります。
- 正確な作業工数を見積もれる
- 素早い問題検知ができる
- 生産性が上がる
正確な作業工数を見積もれる
従来のウォーターフォール開発とは異なり、スクラム開発はスケジュールを細かく決めて開発を進めるわけではありません。
しかし、スクラム開発でも工数を見積もることは重要です。
スクラム開発ではスプリントごとにどの程度の開発を行うかで作業工数を見積もるため、スプリントごとの工数を押さえられれば、プロジェクト全体の作業工数も極めて正確に見積もれます。
素早い問題検知ができる
スクラム開発はコミュニケーションを重視した開発手法であるため、開発チーム内の問題検知を素早くできるといったメリットがあります。
デイリースクラムでミーティングを行う際に、プロダクトの進捗や問題点、目標などを確認し合うことになります。
そのため、問題点があればミーティング時にチーム内で問題点を共有でき、問題の改善や軌道修正も素早く行うことが可能です。
生産性が上がる
スクラム開発の場合、ウォーターフォール開発よりも短期間でプロダクトの機能を開発していくことになるため、全体としても短期間で成果を上げられます。
また、コミュニケーションを重視した開発という点も生産性の向上に貢献しています。
コミュニケーションを取ることで進捗状況や問題点、メンバーのスキルなどもメンバー内で把握できるため、遅れている部分や技術的に難しい場合などにメンバー内でフォローし合うことが可能です。
結果としてプロジェクト全体の進行もスムーズになります。
スクラム開発はなぜ必要なのか？
アジャイル開発とは対極とも言えるウォーターフォール開発は、プロダクトの要件定義からリリースまでにそれなりの期間が必要になります。
プロダクトが最低限動作する形になるまでに、数ヶ月～数年をかけて開発を続ける必要があるのです。
このような長期間における開発の欠点と言えるのが、要件の陳腐化になります。
開発当初に求められていたプロダクトの要件をビジネス環境や企業の状況に合わせて定義したとしても、リリースするまでに数年が経過してしまうとビジネス環境や企業の状況も大きく変化しています。
そのため、数年かけて開発したプロダクトがリリース時点ではもう古い、必要ないものになってしまいかねないのです。
このような開発手法の欠点を打開するために生まれたのがアジャイル開発です。
アジャイル開発ではプロダクトを１週間～２週間程度の短期間でアップデートしていくため、利用者からリアルタイムでフィードバックを受けつつ、修正を重ねながら市場が求める理想のプロダクトを作ることができます。
中でもスクラム開発は、制作時の作業状況をメンバーがコミュニケーションを取りながら把握することで、より円滑に開発を進めるための手法として生まれたものです。