スクラムとは

本ページではアジャイル開発手法の中でもっとも使われているスクラムについて説明します。

スクラムは不確定な要求に対応して開発するためのフレームワーク

スクラムはアジャイル開発手法の一つで、「アジャイル開発のミニマムセット」と呼ばれるコンパクトなアジャイル開発フレームワークです。アジャイル開発の中でもっとも使われている手法です。

スクラムは、単純化すると以下の4つの特徴を持ちます。

  • スプリントという一定の期間毎に動くソフトウェアを作る
  • 要求はプロダクトバックログという優先順位付けされた一覧表に保管される
  • 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する
  • スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う

スクラムは、スプリントという一定の期間毎に、プロダクトバックログ項目の優先順位が高いものから動くソフトウェアを作り、作成されたソフトウェアを評価する形で開発を進めます。その結果、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発することを可能にしました。この利点がスクラムの普及の大きな原動力となりました。

 スクラムの第一歩は体験してこそ腑に落ちる!

スクラムを適用した開発事例

スクラムを適用した開発事例は「アジャイルモデリングへの道Vol.2:スクラム組んで開発しよう!」をご覧ください。

変化する要求を管理するプロダクトバックログ

プロダクトバックログ項目は優先順位付けされた要求の一覧です。プロダクトバックログはプロダクトオーナーが責任をもって管理します。プロダクトバックログは、開発初期にすべてを確定して要求を固定するのではなく、開発を進める中で変化していきます。


スクラムにおける開発の流れのイメージ(スクラムの一部のイベントと成果物のみ記載)

プロダクトオーナーの役割

プロダクトオーナーは、プロダクトのビジネス価値に責任を持つ人です。プロダクトオーナーは、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)に対する仮説をプロダクトバックログの項目として表現し、スプリント毎にできる動くソフトウェア(プロダクトの増分)を評価することで自らの仮設の妥当性を確認しながらプロダクトの開発を進めます。その結果として、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発することができます。

プロダクトオーナーは以下のような作業を行います。

  • プロダクトバックログを管理する
  • プロダクトの機能、優先順位、リリース日とリリース内容を決める
  • プロダクト(の増加分)について受け入れるかどうかを判断する

 スクラムの第一歩は体験してこそ腑に落ちる!

プロダクトバックログ項目を表現するユーザーストーリーとは

スクラムはコンパクトなアジャイル開発フレームワークとして誕生したため、プロダクトバックログ項目の表現形式や定義プロセスについての具体的な方法は当初既定されていませんでした。スクラムが発展する過程で、XP(eXtreme Programming)というアジャイル手法の考え方を取り入れ、ユーザーストーリーを用いてプロダクトバックログ項目を定義することが今では一般的です。

ユーザーストーリーは、ユーザーと開発者の両方が理解できる言葉で、ユーザーにとってのプロダクトの価値やシステムの振る舞いを示します。ユーザーストーリーは、従来のように開発者の視点でシステムの機能を説明するものではなく、ユーザーに対する価値を重視するという点で優れています。

ユーザーストーリーは、一般的には下図に示すようなユーザーの声形式で表現します。

またユーザーストーリーを考える方法として、Ron Jefferiesにより3C (カード、会話、確認)の3段階でユーザーストーリーを定義する方法が提案されました。

  • Card(カード): 内容を記述し、計画やリマインダとして使用 する
  • Conversation(会話): 詳細化するための会話
  • Confirmation(確認): 完了しているかどうかの判断材料

さらに、ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリリースや要求種別を軸に並べて各リリースの内容を考えることが提案されました。これらの方法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現したり、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすることが可能になりました。

プロダクトバックログのライフサイクル

アジャイル開発ではスプリントを進めながら徐々に要求を明確にして確定していきます。その要求を管理するプロダクトバックログが、スプリントを進める中でどのように変化するのか、以下に説明します。

開発初期のプロダクトバックログ:開発初期のプロダクトバックログには、その時点で明確な要求が優先順位の上位に並べられます。優先順位の下位には、その時点では曖昧だがプロダクトに必要だと考えている要求が並べられます。

各スプリントで行うこと:各スプリントでは、プロダクトバックログの優先順位の高いものの中から、そのスプリントで開発するバックログ項目をプロダクトオーナーと開発チームが合意して決定します。開発チームはそのスプリントで開発すると決定したバックログ項目の具体的な作業を計画し(スプリント計画、スプリントバックログ)、開発します。

このとき、スプリントで開発するバックログ項目の内容は明確でなければいけません。また、そのスプリントで何ができていれば完了とするのか、という完了条件を明確にしてから開発を進めます。

プロダクトバックログは各スプリントの5~10%の時間を使って、1~2回先のスプリントのためにバックログ項目の詳細、見積り、優先度を見直してプロダクトバックログを洗練します(プロダクトバックログの手入れ)。開発初期は頻繁に行い、安定したら定期的に行います。

スプリントの終わりには、プロダクトオーナーと利害関係者、開発チームが集まって、そのスプリントで開発したプロダクトの増加分をレビューします(スプリントレビュー)。開発チームはデモを行い、プロダクトオーナーは完了条件を基に完了したかどうかを判断します。プロダクトオーナーは、このスプリントレビューを判断材料の一つとして、新たな要求を発見したり、プロダクトバックログの優先順位を見直したりします。

こうして、プロダクトバックログは変化します。

開発後期のプロダクトバックログ:スプリントを繰り返し、開発を進めていくと、優先順位の高いバックログ項目の中には完了するものも出てくるでしょう。開発後半のプロダクトバックログには、完了したバックログ項目が並び、優先順位が低い要求も開発初期と比べると要求が明確になって詳細化されています。

 スクラムの第一歩は体験してこそ腑に落ちる!



※この記事に掲載されている内容、および製品仕様、所属情報(会社名・部署名)は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。