【スクラム】アジャイル開発スクラムとは？

# アジャイル？スクラム？とは何だろう
　アジャイル開発とは、何でしょうか？一言でいうと、「**一度にまとめて作るのではなく、重要なものから順に実際に動作するものを作り、評価を繰り返す**」であると考えます。そうすることで成果を最大化してサービスを提供し続けることができます。

---

　スクラムはアジャイル開発手法の一つです。スクラムには以下の特徴があります。

1. 要求を必要性を基準に並び替えてその順番にプロダクトを作ることで、成果を最大化
1. 現在の状況や問題点を常に明らかにする（**透明性**）
1. 定期的に進捗確認、仕事の進め方に問題がないか、プロダクトに期待されている成果が得られているかを確認（**検査**）
1. 問題があったり、もっと良い方法があれば、変更する（**適応**）


---

スクラムは、わからないことが多いような複雑な問題を扱うのに適しています。スクラムのルールは、[スクラムガイド](https://www.scrumguides.org/)で定義されています。
以下から簡単にスクラムの手順を述べます。

---

# 1. 機能や要求を並べ変える

　機能や要求、修正などをプロダクトに必要なものを抽出し、順番に並べ替えた**プロダクトバックログ**を作成します。これは要件定義書やロードマップをもとに作成します。
　上位にあるほど重要かつ開発を進めていくため、内容が詳細なものになります。また、各項目の際に見積もりを出しますが、時間や金額など絶対値ではなく、作業量を相対的に表した値がよく使用されます。

　プロダクトバックログは一度作って順番に並び替えたら完成ではありません。絶えず新しい要求を追加したり、変更したり、削除されたりします。作る順番も変わる可能性があります。したがって、常に最新に保つ必要があります。

　プロダクトバックログの書き方には決まりはありませんが、**ユーザーストーリー**と呼ばれる形式で書くことが多いです。
　またプロダクトバックログの上位の項目については、スプリントが始まる前に事前に準備する必要があります。例えば、項目の中身を具体的にする、項目の疑問点を解決する、各項目は何ができたら完成なのかを決める、項目を自分たちが扱えるサイズに分割する、項目の見積もりなどです。これを、**プロダクトバックログリファインメント**（リファインメント）と呼びます。
　
* プロダクトバックログ

|項目|重要度|
|---|---|
|1番目に実現したい|1|
|2番目に実現したい|2|
|3番目に実現したい|3|
|4番目に実現したい|4|
|5番目に実現したい|5|
|***|***|
|100番目に実現したい|100|

* 具体的な書き方

|ストーリー|デモ手順|見積もり|
|---|---|---|
|動画の再生速度を変更したい。これは、基本的なプレイヤーの機能であり、視聴者が自由に再生速度を変えることで、利便性の向上を図る。|プレイヤー内の再生速度変更のボタンを押すと再生速度一覧が表示されて、選択すると値に応じて再生速度が変更される。|3|

# 2. スプリントごとに計画を立てる
　1週間から1カ月の間までの同じ期間に区切って繰り返し開発をします。この固定の期間を**スプリント**と呼びます。各スプリントごとで何を作るのか（What）、どのように作るのか（How）を計画する必要があります。これを**スプリントプランニング**といいます。スプリントプランニングに使える時間は、スプリント機関が1カ月なら8時間です。

　ここでは、2つのトピックを決めます。1つ目は、今回のスプリントで達成したい目的を明らかにします。これをスプリントゴールと呼びます。そして、それに沿って、プロダクトバックログの項目を選びます。基本的にプロダクトバックログの上位の項目から選ぶのが一般的です。選択するバックログの個数は、それぞれの項目の見積もりサイズや1スプリントでできる仕事量（**ペロシティ**）、今回のスプリントで作業に使える時間などを踏まえて仮決定します。

　2つ目は、開発チームが選択したバックログをどうやって実現するのかについて計画を立てます。各項目について具体的な作業を洗い出します。ここの作業は1日以内で終わるように分割するのが一般的です。各作業の担当者はこの時には決めません。実際に作業するときに決めます。

また、スプリントは、途中で変更してはいけません。計画を立てるために利用するベロシティを正しく測定できなくなるためです。

|ストーリ|デモ手順|見積もり|
|---|---|---|
|動画の再生速度を変更したい。これは、基本的なプレイヤーの機能であり、視聴者が自由に再生速度を変えることで、利便性の向上を図る。|プレイヤー内の再生速度変更のボタンを押すと再生速度一覧が表示されて、選択すると値に応じて再生速度が変更される。|3|

|作業|具体的な手順|
|---|---|
|設計|再生速度を変更するためのクラスを設計する。クラス図、シーケンス図を書き起こす。|
|実装|クラス図を基に実装する。|
|テスト|テスト仕様書を作製し、テストをする。|
|ドキュメント作成|ドキュメントを作成する|
|デプロイ|本番にデプロイする|

# 3. スプリントごとに完成させていく
　開発チームはスプリントの期間に、計画、設計、開発、テスト、ドキュメント作成などプロダクトを開発させるために必要な作業をすべて行います。そして、スプリントごとに評価可能な**インクリメント**を作成します。これは多くの場合は実際に動くソフトウェアです。インクリメントは正常に動いている必要があります。そのため、プロダクトオーナと開発チームが完成を指す内容について共通の基準を持つ必要があります。それを**完成の定義**と呼びます。完成の定義は以下の観点などで作成することができます。

* コードレビュー
* ドキュメント
* テスト
* デプロイ
* 性能
* チェックイン

　そして、毎日状況を確認します。それを**デイリースクラム**と呼びます。タイムボックスは人数に関係なく15分と決まっています。デイリースクラムは問題などを解決する場ではないことに注意してください。問題があった場合、デイリースクラムの後に関係者だけ集めて別途会議を開き、問題解決に取り組みます。各メンバーは以下3つの提携の質問に答える形で進めることが多いです。

* 自分が昨日やったことは何か？
* 今日やることは何か？
* 障害・問題となるものがあるか？

　もし仮にスプリント内で完成しない項目があっても期間を延長してはいけません。正確な見積もりを測るためにも作業を中断し、できた個所、できなかった箇所を明らかにしておくのが一般的です。


# 4. 出来上がったプロダクトを確認する
　スプリントの最後にプロダクトオーナー主催でスプリントの成果をレビューします。これを**スプリントレビュー**と呼びます。プロダクトオーナーは各種関係者（ステークホルダー）を招待します。スプリントレビューの最大の目的は、プロダクトに対するフィードバックを得ることです。
　ここでは、プレゼンテーションをするわけではなく、ソフトウェアを動かしながらデモをします。実際に操作しながら参加者に内容を説明したり、実際に触ってもらったりして、フィードバックを引き出します。スプリントレビューでは以下のことについて報告・議論します。使える時間はスプリントが1カ月なら4時間です。

* 成果物を関係者にデモする。（実際にソフトウェアを動かす）
* スプリントで完成しなかったプロダクトバックログの項目について説明する
* スプリントでうまくいかなかったことをや直面した問題点、解決方法について議論する
* フィードバックを受け、プロダクトバックログを見直す

# 5. スプリント振り返り
　スプリントの最後に今回のスプリントで何か問題がなかったか、もっと成果を出すためにできることはないかを議論します。これを**スプリントレトロスペクティブ**と呼びます。ここで出た、アクションアイテムの最低一つは次のスプリントに含めるようにします。毎週、スプリントレトロスペクティブを行う例もあります。
　スプリントレトロスペクティブでは以下の観点を例に実施します。

- 人、プロセスなどの観点で今回のスプリントを検査する
- うまくいったこと、今後の改善点を整理する
- バグを直すのではなく、バグを生まれるプロセスを改善する
- 一度にたくさんのことを変更しようとしない

1.~5.を繰り返すことで、サービスを作っていきます。

# 各ロールについて
　ロールは以下の三種類あります。

## プロダクトオーナー（PO）
　プロダクトオーナーは以下の業務を担当します。

- プロダクトのWhatを担当
- プロダクトのビジョンを明らかにし、共有
- プロダクトの価値を最大化する
- プロダクトバックログの並び順の最終的決定権を持つ
- プロダクトバックログの管理
- プロダクトバックログの最新に更新する
- おおよそのリリース計画を定める

プロダクトバックログの作成更新は開発チームもできるが、最終的な責任、決定権はプロダクトオーナーの仕事です。

## 開発チーム


　開発チームは以下の役割があります。

* プロダクトのHowを担当
* モノを作る
* 3～9人が適正
* 各人が要求分析、設計、開発、テスト、ドキュメント作成ができることが望ましい
* 外部から指示されない


## スクラムマスター
　スクラムマスターは以下の役割があります。

* スクラムが円滑に回るように開発チームとPOを支える
* スクラムのルールや作成物、進め方を理解させる
* マネージャーや管理者ではない
* プロダクトオーナーと開発チームの会話を促す
* プロダクトバックログの良い管理方法を探す


# まとめ
　スクラム活用してより結果を生むには、スクラムの5つの価値基準を取り入れて実線していく必要があります。

- 確約：各人ゴールを目指して全力で取り組むことを確約
- 勇気：正しいことをする勇気をもち、こんなな問題にも取り組む
- 集中：全員がスプリントでの差g表やゴールの達成に集中する
- 公開：すべての仕事や問題を公開することに合意する
- 尊敬：お互いを能力ある個人として尊敬する

 
# 参考
翔泳社, スクラムチームではじめるアジャイル開発 SCRUM BOOT CAMP THE BOOK, 西村直人 他