スクラム開発では、長くても1ヶ月を「スプリント」という固定の期間に区切って開発を進めていきます。スプリントの中には、要件定義→設計→開発→実装→テスト→運用の一連の開発工程が含まれており、各スプリントを短期間で進めます。このスプリントを何度も繰り返していくことで、徐々に機能を増やしていくのです。このように進めることで、優先順位の高い重要な機能から開発できます。

スクラム開発とアジャイル開発の違い

アプリやソフトウェアの開発において重要なのは「アジャイル」という概念です。アジャイルは、「素早い」「機敏な」といった意味を持ちます。その名のとおり、アジャイル開発では、要件定義→設計→開発→実装→テスト→運用のサイクルを短期間で素早く行うのが特徴です。一連のサイクルを細かい単位で繰り返すことで、スピード感を持って開発できます。

スクラム開発とは、アジャイル開発における具体的な手法の1つです。スクラム開発では、チームを組んで役割を分担し、全員で協力することで短期間で開発を進めていきます。アジャイル開発の中でも、コミュニケーションが特に重要な開発手法なのです。

スクラム開発とウォーターフォール型開発の違い

アプリやソフトウェア開発における代表的な開発手法が、「ウォーターフォール型開発」です。ウォーターフォールは、日本語で「滝」を意味します。滝が上から下へ落ちるように、開発工程を上流から下流まで順に完了させていく開発手法です。ある工程が終わったら次の工程に進み、すべての工程が終わるとようやくリリースに至ります。前工程が完了しないと次の工程に進めないのが特徴です。

スクラム開発が一連のサイクルを何度も繰り返すのに対し、ウォーターフォール型開発では、基本的に前の工程に戻ることはありません。ウォーターフォール型開発は、仕様変更を前提としていないプロダクトの開発に適しています。一方、仕様変更が頻繁に起こるプロダクトについては不向きです。

ウォーターフォール型開発は、アジャイル開発が提唱される前まで主流の開発手法でした。しかし、昨今ではスクラム開発が主流です。

スクラム開発の特徴

スクラム開発には、以下のように2つの特徴があります。

2種類のバックログ（プロダクトバックログ・スプリントバックログ）がある
チーム主体のロールでコミュニケーションを重要視

特に、チーム内でメンバーそれぞれが役割を担い、コミュニケーションをとって進めていくのが大きな特徴です。

ここでは、スクラム開発の特徴について解説します。

2種類のバックログがある

バックログとは、開発中のプロダクトに実装すべき機能や取り組むべき課題、チームやメンバーがやるべき業務など、プロジェクト全体でやるべきタスクの一覧のことです。バックログをもとに、作業計画を立てます。スクラム開発の特徴は、このバックログが2種類存在することです。

プロダクトバックログ
スプリントバックログ

以下では、それぞれのバックログについて解説します。

種類1.プロダクトバックログ

プロダクトバックログとは、プロダクトに実装すべき機能や改善すべき要素などをまとめたものです。一般的には、プロダクトごとに 1 つのプロダクトバックログを作成し、そのバックログに1つのチームを割り当てることとされています。プロダクトバックログでは、やるべきことが優先順位によってリスト化されており、それを見れば誰もがやるべきことを理解し、開発を進めることが可能です。

プロダクトバックログを構成するのは、以下の4つの要素です。

フィーチャー
バグ修正
技術的負債
知識獲得

フィーチャーは、ユーザーが価値を感じられるプロダクト機能のことを指します。

バグ修正は、その名のとおりプロダクトにおけるバグを修正することです。プロダクトバックログにおいては、優先的に修正すべき重要なバグは上位に表示され、逆に優先順位が低いバグについては、下位や次のスプリントに回されます。

技術的負債は、開発のスピードを重視して簡単なソリューションを選んだ結果生じる、追加作業のコストのことです。意図せず発生することもありますが、スピーディーな納品を優先し、意図的に発生させることもあります。

そして知識獲得とは、タスクを達成するために必要な情報を集めることで、知識がなかったためにタスクを達成できないという事態を防ぐものです。

プロダクトバックログの作成方法については後述します。

このプロダクトバックログを、スプリントごとに細分化したものがスプリントバックログです。

プロダクトバックログは、定期的に関係者全員に共有され、プロジェクト全体の進捗と今後やるべきタスクを把握するのに役立ちます。

種類2.スプリントバックログ

スプリントバックログは、各スプリントの期間中に行うべきタスクをリストアップしたものです。

プロダクトバックログが、プロダクトのためにチーム全体が取り組むべき課題や業務のすべてをまとめたものであるのに対し、スプリントバックログは各スプリント期間中にやるべきタスクを一覧にしたものです。そのため、スプリントバックログはプロダクトバックログの一部といえます。

スプリントバックログによって、各スプリント期間中にチームがやるべきこととやらなくてよいことが明確になり、スコープクリープの発生を防げるでしょう。スコープクリープとは、プロジェクトの要件が途中で変更されたり、追加されたり、成果物が事前に決めていたプロジェクトスコープよりも増えたりすることです。

スコープクリープの原因の1つとして、社内のコミュニケーション不足が挙げられます。スプリントバックログでやるべきことを明確化し、チーム内で共有するとスコープクリープの発生を防げるのです。

また、スプリントバックログではタスクが明確になるため、チームの生産性もアップします。

チーム主体のロールでコミュニケーションを重要視

スクラム開発では、チーム全体を統括するプロダクトマネージャーがおらず、チームごとに主体的にマネジメントを行うのが特徴です。チームは5〜10名程度の少人数のメンバーから構成されます。

メンバーは固定であり、チーム内のメンバーにはプロダクトオーナー、開発者、スクラムマスターという役割がそれぞれ与えられ、まさに8人の選手が肩を組んで協力してボールを前に進めるラグビーのスクラムのように、チームワークが非常に重要なのです。

プロダクトオーナーとは、プロダクトの方向性を決め、スプリントごとに評価を行う役割のことです。プロダクトオーナーの意思決定に従って、開発者が開発業務を進めていきます。そして、全体を調整する役割を担うのがスクラムマスターです。スクラムマスターは、開発が円滑に進むよう、プロダクトオーナーや開発者が抱える課題を解決します。

このように、スクラム開発ではチーム主体のロールが存在し、それぞれがコミュニケーションをとって開発を進めていくのです。

スクラム開発の流れ

スクラム開発は、一般的に以下の流れで行われます。

プロダクトバックログの作成
スプリントプランニングミーティングの実施
デイリースクラムの実施
スプリントレビューの実施
スプリントレトロスペクティブの実施

スプリントプランニングミーティング以降は、各スプリントごとに実施されるため、スクラム開発では、これらの流れを繰り返して開発を進めていくのです。

ここでは、スクラム開発の一連の流れを詳しく解説します。

1.プロダクトバックログの作成

まずは、プロダクトのゴールから機能や修正などプロダクトに必要なものを抽出し、プロダクトバックログを作成します。

プロダクトのゴールは、プロダクトの将来の状態とチームの長期的な目標をもとに決定しましょう。ゴールが不明瞭なまま開発を進めると、有効なプロダクトバックログを作成できず、開発もスムーズに進められません。十分な時間をかけてゴールを決定することで、開発の目的や方向性を明確化し、メンバーの考えや行動も統一できます。

次に、プロダクトバックログの管理方法についても検討しましょう。これには管理ツールを利用したデジタル管理と、付箋やカードなどを利用したアナログ管理があります。プロジェクトの状況やメンバーに応じて、適切な管理方法を選択してください。

ゴールと管理方法が決まったならば、ゴールを実現するために必要な要素やタスクを一覧にします。要素が出揃ったならば整理して、優先順位をつけていきましょう。優先順位をつけたあとは、重要なものから順番にそのタスクを実施する目的、KGIやKPI、仕様や画面のイメージ、想定リスクなど、各要素の詳細について決定します。プロダクトバックログを見ただけで、誰もが開発を進められるレベルに詳細を決定することが大切です。

2.スプリントプランニングミーティングの実施

プロダクトバックログを作成したならば、それをスプリントレベルに細分化するためにスプリントバックログを作成します。作成にあたっては、スプリントプランニングミーティングを実施しましょう。

これは「スプリント計画会議」とも呼ばれ、プロダクトバックログをもとに、今回のスプリントで実装するタスクや詳細な使用、担当者などを決めるものです。このミーティングによって作成されるのがスプリントバックログであり、今回のスプリントで実施しなくてよい項目は次のスプリントに回されます。

3.デイリースクラムの実施

デイリースクラムとはスプリント期間中、毎日同じ時間に行われるミーティングのことです。デイリースクラムでは、スプリントバックログに沿ってメンバーそれぞれが進捗や課題、今後の進め方などを報告して共有します。

デイリースクラムは、15～30分程度の短時間で行われるのが特徴です。基本的には、スクラムマスターがチーム全員に対して質問し、その回答を確認する形式で進められます。必要に応じて、デイリースクラム内でスプリントバックログを更新することも多いです。

デイリースクラムの内容は、プロダクトオーナーに共有されます。デイリースクラムは、コミュニケーションが大切なスクラム開発において、非常に重要な役割を担うミーティングです。

4.スプリントレビューの実施

スプリントレビューとは、スプリントの最終日にプロダクトオーナーが成果物を確認することです。デモンストレーションを実施し、スプリントバックログの要求を満たしているか、問題はないかを確認します。

スプリントとスプリントレビューは、スプリントバックログの要求を十分に満たしていると判断されるまで、繰り返し行われるのが特徴です。開発チームだけではなく、顧客や営業担当者などの関係者にも参加してもらうと、あらゆる視点から成果物をチェックできるでしょう。

スプリントレビューの結果、問題はないと判断された場合、リリースに至ります。問題が見つかった場合にリリースは先送りされ、再びスプリントとレビューが行われるのです。

5.スプリントレトロスペクティブの実施

スプリントレトロスペクティブとは、スプリントの振り返りのために、各スプリントの最終日に行われるミーティングのことです。メンバーで議論して課題を洗い出し、次のスプリントでは発生しないよう改善させます。

スプリントレトロスペクティブの後は、再びスプリントプランニングミーティングを実施し、以降デイリースクラム、スプリントレビュー、スプリントレトロスペクティブと各工程を繰り返すのです。

スクラム開発のメリット

スクラム開発のメリットは以下のとおりです。

短い期間で最大限の成果
作業の工数見積もりが正確
ビッグバンテストを回避
チームワーク強化によって生産性向上が期待

特に、スプリントを繰り返して機能を増やしていくという性質上、短期間で成果を出しやすく、柔軟性が高いのがメリットです。また、リリース直前に大きな問題が見つかるという事態も回避できます。

ここでは、スクラム開発のメリットについて詳しく解説しましょう。

1.短い期間で最大限の成果

スクラム開発では、スプリント単位で各工程を実施し、それを繰り返していきます。短期間で必要な機能を開発して実装し、必要な機能が出揃ったタイミングでリリースできるため、短い期間で成果を出しやすいのがメリットです。

また、非常に柔軟性が高い手法であるため、問題が起きた際の軌道修正はもちろん、顧客の要求や要件変更にも適宜対応できます。これは、従来のソフトウェア開発手法と大きく異なるメリットです。

2.作業の工数見積もりが正確

スクラム開発では、スプリントごとに工数を見積もります。完成までの長期的な期間について工数を見積もるウォーターフォール型開発とは異なり、プロダクトの機能ごとに見積もるため、より精度の高い見積もりが可能です。また、前のスプリントでの経験を参考に工数を見積もるため、非常に正確な工数見積もりをもとにした実現性の高い計画を立てられます。

3.ビッグバンテストを回避

ウォーターフォール型開発のように、一連の工程を上流から下流へ順番に進めていく場合、リリース前に大型のテストであるビッグバンテストを実施します。もしもビッグバンテストで大きな問題が見つかった場合は、その解決に非常に時間がかかり、生産性が低下してしまう恐れがあるのです。

一方のスクラム開発では、各スプリントごとにテストを実施するため、問題にすぐに気づいて対応できます。ビッグバンテストを回避し、プロジェクトの終盤で問題が見つかるという事態を防げるのが大きなメリットです。

4.チームワーク強化によって生産性向上が期待

スクラム開発では、メンバーの得意領域を活かしながら協力して進めるため、効率的に作業を進められたり、モチベーションを維持できたりします。また、デイリースクラムのようにメンバーでコミュニケーションをとる機会も多く、チームワークを強化させて生産性を向上させられるのです。日頃から同じメンバーで開発を進めている場合は、スクラム開発に向いています。