以下のような進め方を アジャイル開発 と呼ぶ。
- 関係者は目的の達成のためにお互いに協力し合いながら進める
- 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届けて評価を繰り返す
- 利用者の反応や関係者からフィードバックを継続的に得ながら、作っているもの自体や計画を調整する
2001 年に アジャイルソフトウェア開発宣言 を示したのが始まり。
スクラムには以下の特徴がある。
- 要求を価値やリスクや必要性を基準にして並び替えて、その順にプロダクトを作ることで成果を最大化する
- スクラムでは固定の短い時間に区切って作業を進める。固定の時間のことを タイムボックス と呼ぶ
- 現在の状況や問題点を常に明らかにする。これを 透明性 と呼ぶ
- 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認する。これを 検査 と呼ぶ
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変える。これを 適応 と呼ぶ
スクラムはわかっていることよりもわからないことが多いような複雑な問題を扱うのに適している。
スクラムは、5つのイベント、3つのロール、3つの作成物など、最低限のルールのセットで構成されている。
あくまで最低限のルールのみ用意されているので、そのルールを実際どのように適用していくのかは自分たちで考える必要がある。
スクラムのルールは スクラムガイド で定義されている。
スクラムでは、機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並び替えた プロダクトバックログ と呼ばれるリストを作成する。
それぞれの項目はプロダクトバックログ上で一意な順番を持ち、順番が上のものから開発する。
また、計画の際に利用するために、それぞれの項目は見積もられている必要がある。
見積もりには時間や金額などの絶対値ではなく、作業の量を相対的に表した値がよく使われる。
プロダクトバックログは、プロダクトを作っている間はずっと更新を続け、常に最新に保つ必要がある。
プロダクトバックログの管理の責任者を プロダクトオーナー と呼ぶ。
プロダクトオーナーはプロダクトの責任者であり、1プロダクトにつき1人とする。
開発チームを活用して、そのプロダクトが生み出す価値を最大化する責任がある。
プロダクトオーナーは次のようなことを行う。
- プロダクトのビジョンを明らかにし、周りと共有する
- おおよそのリソース計画を定める
- 予算を管理する
- 顧客、プロダクトの利用者や組織の関連部署などの関係者と、プロダクトバックログの項目の内容を確認したり、作る順番や実現時期を相談したりする
- 既存のプロダクトバックログの項目の内容を最新の状態に更新する
- プロダクトバックログの項目の内容を関係者が理解できるように説明する
- プロダクトバックログの項目が完成しているかどうかを確認する
プロダクトバックログの作成や更新は、プロダクトオーナー1人ではなく、開発チームらとともに行う場合もあるが、最終的な責任はあくまでプロダクトオーナーにある。
プロダクトの How を担当するのが 開発チーム。
開発チームの主な役割は、プロダクトオーナーが順位づけしたプロダクトバックログの項目を順番に開発していくこと。
開発チームは通常、3人から9人までで構成される。
（10人以上の場合は、コミュニケーションコストが増えることによって開発の効率が落ちるため、開発チームを分割して適切なサイズを維持するのが一般的。）
開発チームは、プロダクトを作るために必要な全ての作業ができる必要がある（ 機能横断的 チーム）。
開発チーム内には役職やスキルなどによる特定の肩書きや役割はない。
開発チーム内での仕事の進め方は、開発チームメンバーの合意のもとで決め、外部から仕事の進め方を指示されることはない。
あくまで開発チーム全体で責任を持って作業を進める（自己組織化）。
開発チームで主体的に作業を進めることによって、開発チームの能力は継続的に向上していく。
スクラムでは最長1ヶ月までの固定の期間に区切って、繰り返し開発を行う。
この固定の期間のことを スプリント と呼ぶ。
開発チームはこの期間の中で、計画、設計、開発、テストなどプロダクトバックログ項目を完成させるのに必要な作業全てを行う。
たとえスプリントの最終日に作業が残っていても、スプリントは終了し、期間は延長しない。
なお、状況の変化によって現在のスプリントでの作業の意味がなくなった場合は、プロダクトオーナーの判断によってのみスプリントを途中で中止することができる。
スプリントで何を作るのか、どのように作るのかを計画する必要がある。
計画は、 スプリントプランニング と呼ばれるイベントで決定する。
スプリントプランニングに使える時間は、1ヶ月スプリントであれば8時間、スプリント期間が短ければそれに合わせて短くするのが普通。
スプリントプランニングでは、次の2つのトピックを扱う。
- スプリントゴールを決める
- 具体的な作業計画を立てる
1つ目のトピックは、「スプリントで何を達成するかを決める」こと。
最初に、プロダクトオーナーが今回のスプリントで達成したい目的を明らかにする。
次に、今回のスプリントでそれを達成するために完成させるプロダクトバックログ項目を選ぶ。
選択する項目は並べ替えてあるプロダクトバックログの上位の項目になるのが一般的（優先度順に並び替えてあるはず）。
選択するプロダクトバックログの個数は、それぞれの項目の見積サイズや開発チームの過去の実績、今回のスプリントで作業に使える時間などを踏まえて仮決定する。
また、検討した内容を踏まえて今回のスプリントの目標（スプリントゴール）を簡潔にまとめておく。
スプリントプランニングを開始する前に、プロダクトバックログの上位の項目については事前準備が必要。
例えば以下のような準備を行う。
- 項目の中身を具体的にする
- 項目の疑問点を解決する
- 項目は何ができたら完成なのか（受入基準）を明らかにする
- 項目を自分たちが扱えるサイズに分割する
- 項目を見積もる
これらの活動のことを プロダクトバックログリファインメント と呼ぶ。
リファインメントに使う時間は、スプリントの 10% 以内にするのが一般的。
2つ目のトピックは、「開発チームがプロダクトバックログ項目をどうやって実現するかについて計画を立てる」こと。
つまり、選択したプロダクトバックログ項目ごとに、具体的な作業内容を洗い出すなどして作業計画を立てる。
選択したプロダクトバックログ項目と作業の一覧を合わせて スプリントバックログ と呼ぶ。
個々の作業は1日以内で終わるように分割するのが一般的。
注意しなければならないのは、開発チームはスプリントプランニングで合意した内容を完成させるように全力を尽くす必要はあるものの、計画したことをすべて完成させることを約束している訳ではない、という点。
スクラムでは、スプリント単位で評価可能な インクリメント を作ることが求められる。
インクリメントとは、過去に作ったものと今回のスプリントで完成したプロダクトバックログ項目を合わせたもの。
多くの場合、動作しているソフトウェアとして提供され、スプリント終了時点で完成していて、正常に動作しなければならない。
プロダクトオーナーと開発チームは、「完成」の指す内容について共通の基準を持つ必要がある。
これを 完成の定義 という。
開発チームは、この定義を満たしたソフトウェアを作る必要がある。
デイリースクラム は開発チームのための会議。
スプリントバックログの残作業を確認し、このまま進めてスプリントゴールが達成できるのかどうかを、毎日、同じ時間、同じ場所に開発チームのメンバーが集まって検査する。
デイリースクラムでは、開発チームの人数に関係なく、15分間のタイムボックスで行い、延長はしない。
進め方に決まりはないが、開発チームのメンバーが以下の3つの質問に答える形式で進めることが多い。
- 昨日やったことは何か
- 今日やることは何か
- 障害となるものはあるか
デイリースクラムは、問題解決の場ではないことに注意。
メンバーが問題を報告した場合は、デイリースクラム終了後に改めて、問題解決に必要な人を集めた別の会議を設定するなどして、15分のタイムボックスを守るようにすること。
スプリントの最後に、プロダクトオーナー主催でスプリントの成果をレビューするイベントを開催する。
これを スプリントレビュー と呼ぶ。
プロダクトオーナーはスプリントレビューに必要な利害関係者（ステークホルダ）を招待する。
スプリントレビューの最大の目的は、プロダクトに対するフィードバックを得ること。
スプリントレビューでは、開発チームがスプリント中に完成させたインクリメントを実際に披露する。
（実際に動作する環境を見ながら確認できるようにする。）
スプリントレビューでデモすることができるのは完成したものだけ。
そのため、プロダクトオーナーと開発チームとで、スプリントレビューの前までに、完成したプロダクトバックログ項目と完成しなかったプロダクトバックログ項目を明らかにしておくのが一般的。
スプリントレビューのあとに、スプリント内の最後のイベントである スプリントレトロスペクティブ を行う。
スプリントレトロスペクティブでは、直近のスプリントでのプロダクトの開発に関わる活動において問題がなかったか、もっと成果を出すためにできることはないか検査を行い、次回のスプリント以降のアクションアイテムを決める。
スプリントレトロスペクティブに使える期間は、1ヶ月スプリントであれば3時間、それより短い期間であれば期間に応じて時間を短くするのが一般的。
スクラムのプロセスを円滑に回して、プロダクトをうまく作れるようにプロダクトオーナーや開発チームを支えるのが スクラムマスター。
スクラムマスターは、スクラムのルールや作成物、進め方をプロダクトオーナーや開発チームに理解させ、効果的な実践を促し、スクラムの外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守る。
スクラムマスターがプロダクトオーナーや開発チームに対して行うことの一例は次の通り。
- プロダクトオーナーや開発チームにアジャイル開発やスクラムについて説明して理解してもらう
- スプリントプランニングやスプリントレトロスペクティブなどの会議の進行を必要に応じて行う
- プロダクトオーナーと開発チームの会話を促す
- プロダクトオーナーや開発チームの生産性が高くなるように変化を促す
- わかりやすいプロダクトバックログの書き方をプロダクトオーナーや開発チームに教える
- プロダクトバックログの良い管理方法を探す
これまでに出てきたプロダクトオーナー、開発チーム、スクラムマスターを合わせて、スクラムチーム と呼ぶ。
スクラムを活用して良い結果を生むには、スクラムの5つの価値基準を取り入れて実践していく必要がある。
- 確約： それぞれの人がゴールの達成に全力を尽くすことを確約する
- 勇気： 正しいことをする勇気を持ち、困難な問題に取り組む
- 集中： 全員がスプリントでの作業やゴールの達成に集中する
- 公開： すべての仕事や問題を公開することに合意する
- 尊敬： お互いを能力ある個人として尊敬する
- ロールが求めることに熱心に取り組んでくれる人を探すと良い
- うまくできていないことはスクラムチームで補っていけばいい
- スクラムマスターとプロダクトオーナーは方向性が違うから兼任しない方が良い
スクラムチームで進んでいく先とプロダクトバックログは密接に結びついている。
進んでいく先のことをよく知っていれば、プロダクトバックログはうまく作れるはず。
そのためには、スクラムチームに期待されている2つのことを知っておく必要がある。
- どういうことを実現するのか（ゴール）
- 絶対に達成したいことは何か（ミッション）
（スクラムのルールには含まれていないが）それを補うための活動として、 インセプションデッキ がよく使われている。
インセプションデッキは、何かの開発を始める前に明らかにしておくべきことを知るために行う。
明らかにすべきことが 10 個の質問という形でまとめられていて、それぞれの質問についてスクラムチーム全員で話し合う。
The Agile Inception Deck | The Agile Warrior
開発を始めるときに、いつまでに何が終わるかを 100% 約束するのはスクラムでも不可能。
しかし、「これで大丈夫そうだ」と思える今後の見通しを立てることならできる。
スクラムでは、プロダクトバックログがこの先の計画を知るための道標になる。
最初に作るときには、実現したいことに大きな漏れがないようにしておくのが大事。
そのためのやり方としては、たとえば、スクラムチームみんなで、プロダクトバックログに含めた方がいいと思う項目を付箋などに書き出していく手法がある。
さまざまな人のいろんな視点で洗い出すことで、致命的な漏れをなくすのが目的。
スクラムチームで達成すべきゴールや開発して実現していくものの概要がわかる資料を持ち寄ると良い。
十分に洗い出せたら、次のその一つ一つに順序をつけていく。
プロダクトバックログの順序はスクラムチーム自身が考えるべし。
こうした順序をスクラムチームで決めるのは難しそうだからと、ステークホルダなどに決めてもらいたいと思うかもしれない。だけど、詳細に順序をつけることにステークホルダ自身が慣れていなくて決められなかったり、なぜそういう順序にしたのかをスクラムチームが理解できなかったりする。また、本当は開発をうまく進めるためには別の順序の方が良いと思うこともあるだろう。これでは自分たちが大丈夫と思えるような見通しは立たない。自分たちで順序をつけることで、自分たちが大丈夫だと思えるものにするんだ。そのために必要な情報が足りないなら、まずは情報を集めるところから始めよう。
大まかな順序をつけることで、これからの開発をどのように進めていくかという全体の流れがわかる。
何を重要だと考えて、どれを先にやるつもりなのかもわかる。
もう1つ大事なのは、スクラムチームがプロダクトバックログについて十分理解していることだ。スプリントが始まれば、プロダクトバックログを道標にして開発は進む。なので、何が重要なのかを知っておかないと作業はうまく進められない。また、ゴールにより近づくために、プロダクトバックログの項目や順序は絶えず見直さないといけない。こういうことをうまくやるためには、スクラムチームはプロダクトバックログの中身について十分に知っておかないといけない。
スクラムでは、プロダクトバックログの各項目を見積もる。
それぞれの項目を実現するのに必要な時間やお金を概算できれば、最初のリリースの時期や必要な予算などもわかってくる。
多くのスクラムチームでは、時間やお金で見積もっていくのではなく、プロダクトバックログの項目を終わらせるためにどれくらいの量の作業があるかに注目する。
多くのスクラムチームが使っているのは、「相対見積もり」というやり方。
基準となる数字を決めて、それとの比較で作業の量を考えていく。
基準となるのは、プロダクトバックログ項目のどれか。
作業の量を把握していくための基準なので、必要な作業が具体的にイメージできるものにすると良い。
相対見積もりというやり方は、見積もっていく対象が不確実なものだということを前提にしている。
（まだ実現していないものを見積もっているので、推測にすぎない。）
相対見積もりでは不確実なものを少しでもうまく扱えるように、使う数字を工夫している。
見積もりには、たとえば 1、2、3、5、8、13…といったフィボナッチ数を使うことが多い。
（不確実なことによる多少の誤差は考えなくて済む、というのが理由。）
たまに、開発が始まったばかりなのに、ずっと先のことまでものすごく細かくて大量の項目を含んだプロダクトバックログを見かけることがある。項目が詳細だと、見積もりは正確な気がする。けれど、実はこれはよくない兆候である場合が多い。もし項目をいくつか実現したあとに、最初の推測が間違っているとわかったら、そのために使った時間は無駄になってしまう。
プロダクトバックログの項目を詳細にするのは、直近の数スプリント分くらいが良い。
このやり方で大事なのは素早く見積もること。
素早く見積もれば、先の見通しを確実にするための時間に当てることができる。
スクラムでは、実際に作業を進めていく開発チームが一番詳しい専門家である。
開発チームなら、以下のような情報を元に具体的な見積もりができる。
- 実装するロジックは簡単だけど多くのコードを書くので手間がかかる
- 開発チームのスキルで十分に扱えそうか
情報を持っていない人が見積もると、どうしても周りから期待されているリリースを希望する日に間に合わせようとしたり、偏った見積もりをしてしまう。スクラムでは、そうしたことを起こさないために、最終的な見積もりは実際に作業をする人と決めている。
スクラムでは、実際にコードを書く以外にも、アーキテクチャや仕様を検討したり、要件をまとめたりといった作業もすべて開発チームが行う。
内容をよくわかっていて、より確実な見積もりができるのは開発チームしかいない。
自分たちの作業は自分たちで見積もるべし。
多くのスクラムチームでは、プランニングポーカーを使って見積もりを行っている。
ポーカーには、開発チームの意見を拾いやすくすることができる、という利点がある。
ポーカーは、あいまいなことを明らかにしていく。認識のズレが数字の違いとしてあらわれてくるんだ。その違いを話し合えば、あいまいなものをどう解釈すべきかが見えてくる。 （中略） また、話し合ううちに見積もっている対象についての疑問が出てくる。この疑問について話すことで、あいまいなことをより明らかにできる。それも素早くやりたいので、見積もりにプロダクトオーナーも同席するなど積極的に協力しよう。
ポーカーが重視しているのは、実際に作業を進める人たちが対話すること。
もし、開発チームのシニアエンジニアのような人ばかりが発言して対話になっていない、ということがあれば、それはよくない兆候。
（シニアといえど何か見落としているかもしれない。）
そんな場合は、その人には見積もりから一旦外れてアドバイザーになってもらうと良い。
スクラムでは、プロダクトバックログの項目を見積もれば、先のことについて考えることができる。
プロダクトバックログには実現したいことが整理されていて、それぞれがどれくらい大変か、作業量が見積もられている。
単位はなんでもよくて、ポイント と呼ばれる単位を使うことが多い。
あとは、スクラムチームがスプリントごとにどれくらいの作業をこなせるかがわかれば、さまざまなことが見えてくる。
スプリントごとに終わらせられるポイント数のことを ベロシティ と呼ぶ。
ベロシティがわかれば、先の見通しが見えてくる。
ベロシティは決めるものではなく、測るもの。
スプリントでどれくらい実現できるかは、実際に測ってみるのが最も確実。
また、先の見通しを立てるときは、スクラムチームの実力を考慮しておくと良い。
数スプリントぐらいの余裕を持たせておけば、1回くらいベロシティが0になっても、挽回できるチャンスが残されている。
また、スクラムを始めたばかりであれば、このやり方に慣れるまでの期間は、ベロシティが上がらない可能性もある。
スプリントプランニングは、これから始まるスプリントの計画を作るための活動である。
ここでは、プロダクトバックログの中からどれを実現するかをプロダクトオーナーと開発チームが2つのトピックについて話し合って決定する。
- このスプリントで何ができるか
- どのように達成するか
何を実現するかの目処がついたら、スプリントの期間で本当に完成できるかを見極める。
開発チーム全員で、必要な作業を洗い出して詳細に見積もる。
そして、本当に達成できるのかを判断する。
作業の洗い出しは、スプリントをどういう作業の流れで進めるかをイメージするとやりやすい。
（まず画面の構成や項目を考えて、設計して、実装して、テストして…という具合に。）
タスクが洗い出せたら、それを見積もろう。よく使われるのが時間での見積もりだ。このタスクを終わらせるまでにかかる時間を考える。時間の見積もりを合計すれば、スプリントの期間内に完成できるかどうかが判断できる。 （中略） 会議に参加したりメールを見たりと普段の開発作業以外に使う時間もあるので、1日で使える時間は5〜6時間程度だと考えよう。
最後に、洗い出したタスクと見積もりはまとめておく。
これはスクラムで決められている作成物で、スプリントバックログと呼ばれている。
日々の進捗状況の共有に使ったり、問題が起こったときに原因を見つけるために使ったりする。
これは開発チームの持ち物。スプリントをうまく進めるために使う。
開発チーム以外の誰かが口を出そうとするかもしれないが、それは無視して構わない。
スプリントプランニングでは、スクラムチーム全員が「これなら確実に達成できるぞ」と自信が持てるぐらい、具体的で詳細な計画を作る必要がある。
実現するものの認識を揃えておこう。何を実現したいかがわからないままでは確実な計画は作れない。そのためによく使われるのが、デモ手順を決めておくことだ。 （中略） 実際にどんなデモになるかを考えることで、どういうものを実現したいのかを全員が理解できる。これはとても大切で、この話し合いにたくさんの時間を割いているスクラムチームも多いんだ。
タスクの洗い出しと見積もりを確実にする。
タスクはいつ着手して、いつ終わるのか判断できるようにする。
タスクの一覧を張り出したものの前にでも集まって、どう作っていくかを話し合いながらタスクの洗い出しを洗練させる。
クラス図を書いて設計の確認をしたり、具体的な日付を見ながらどういう風に開発を進めるのかイメージする。
開発チーム全員で考えることで、作業の抜けを見つけたり、お互いの認識を揃えたりすることができる。
…むしろ怖いのは、良くない結果が隠されてしまうことだ。たとえば、チーム外から期待される進捗のことが気になって、本当は達成できていないのにできたことにしてしまったり、やらないといけないテストを少しサボってしまったりすることはないだろうか。それはあとになって必ず深刻な問題になって返ってくる。
スプリントプランニングは、スクラムチームで達成したいゴールに確実に近づくための活動。
期待されているリリース日や期日までに必要なものを全部揃えることを守るために、逆算した計画を作るのが目的ではない。
「今回のスプリントでは確実にこれだけは達成できる」と確信を持てる計画にすることが重要。
デイリースクラムは、一日一回、同じ時間に同じ場所で毎日開催する。
デイリースクラムをすることで、スプリントの状況がわかる。
スプリントという短い期間では、小さく見える問題でも、放置すると致命的な問題になるかもしれない。
でも、早いうちに解決しておけばスプリントゴールは達成できる。
そのためのうまいやり方が毎日 15 分だけ集まる、といやり方。
デイリースクラムでは、全員がその目的を理解していないとうまくいかない。たとえば、デイリースクラムが誰かへの進捗報告になっている場合だ。報告に意識が向いてしまっていては、問題を見つけるのは難しいんだ。
デイリースクラムがスクラムマスターへの進捗報告になっている場合は、以下のような質問を投げかけてみると良い（かもしれない）。
- その作業はあとどれくらいで終わるの？
- スプリントレビューの準備は順調？
それでも特定の誰かへの進捗報告会になったままなら、その人はデイリースクラムに参加しないようにしてもらい、開発チームは目的をもう一度考えるべし。
デイリースクラムで問題を見つけたら、すぐに対策する。
デイリースクラムの後に必要な人だけが残り、話し合って解決する。
（問題を見つけたからといって、デイリースクラムの途中で問題の解決について長々と議論しないよう注意。）
スプリントが順調に進んでいるかを確認する方法としては タスクボード が良く使われる。
やり方は簡単で、スプリント内で実施するプロダクトバックログの項目とそのためのタスクを、開発チームの見えるところに全部張り出すだけ。
その時に、それぞれのタスクの状況をわかりやすくするために、未着手（ToDo）、着手（Doing）、完了（Done）といったタスクの状態ごとの列を設けて、それに合わせて貼っておく。
こうすれば、スプリント内のタスクの作業状況を透明にできる。
誰がどのタスクをやっているかがわかるように印をつけておけば、タスクを抱えすぎている人が誰なのかがわかる。
着手中でずっと進んでいないタスクがあれば、良くないことが起きている可能性が高い、ということもわかる。
また、グラフなどの図で表しておくのも効果的。
代表的なのが スプリントバーンダウンチャート。
スプリントでの進み具合が大丈夫なのかを確認するには、スプリントの最後までに残タスクの見積もり時間が全て 0 になるように順調に減っていくかを確認すれば良い。
スプリントは、スプリントレビュー と スプリントレトロスペクティブ を最後に開催して終わりとなる。
スプリントレビューは、今回のスプリントで完成したものと今後について明らかにするイベント。
スプリントレトロスペクティブは、今回のスプリントでの作業の進め方を確認して、次のスプリントをよりうまく進めていくために用意されている（いわゆる「振り返り」）。
スプリントレビューでは、スプリント開始時に決めたプロダクトバックログ項目のうち、完成したものを披露して、今後のためのフィードバックを引き出す。
スプリントレビューの進め方は以下の通り。
- プロダクトオーナーは、何が完成していて、何が完成していないかを説明する
- 開発チームはそれぞれ完成したものを説明しながらデモをする
- 内容について質問や議論をする
ちゃんと要望通りに作ったと報告されても、動くものも見ずに鵜呑みにすることはできない。言葉はあいまいで表現も認識も人によってバラバラだからだ。そのため、実際に出来上がった物をデモをして目で見るのが一番確実なんだ。
プロダクトバックログに書いたものは、あくまで書いた時点でプロダクトにとって良いと仮定したもの。
その仮定が正しいかどうかを確かめる必要がある。
それには、実施に動くプロダクトを見たり触ったりしてもらい、フィードバックをもらうのが確実。
ソフトウェアは中身も大事。
見た目は大丈夫そうでも、コードの品質が悪かったり他に影響するバグがあれば、期待に応えられない。
中身についても完成を判断できるように 完成の定義 を決めると良い。
完成の定義はたとえばこういうもの：
- デモ手順の通りに動作する
- public メソッドのテストコードがある
- 調査した内容は wiki にまとめてある
- 最新の仕様が wiki にまとめてある
- リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる
完成の定義はスクラムチームで合意しないといけない。
スクラムでは、全てのイベントにタイムボックスが設けられている。
もしスクラムを始めたばかりなら、まずはタイムボックスを守るところから始めると良い。
- スプリントの期間は 1 ヶ月以内
- デイリースクラムは 15 分以内
- スプリントプランニングは 8 時間まで（スプリント期間が 1 ヶ月の場合）
- スプリントレビューは 4 時間まで（スプリント期間が 1 ヶ月の場合）
- スプリントレトロスペクティブは 3 時間まで（スプリント期間が 1 ヶ月の場合）
スプリントは、タイムボックスの代表例。
スプリントの期間を一定にして、実際にどこまでできたかを計測する。
もし一日でも延長したら、他のスプリントとは比較ができない。
（つまり、この実績が何の予測にも使えなくなる。）
リリース時期などスケジュールに関する今後の見通しがわからなくなるリスクを冒してまでスプリントの期間を延長することに、メリットがあるのかどうかを考えるべし。
もし 15 分でデイリースクラムが終わっていなければ、どうなるだろう？時間が長くて途中で疲れたり飽きたりしていて、スプリントゴールの達成に向けて問題がないかどうかの検査のイベントとして成立していないかもしれない。また、スプリントプランニングが何もかかるようなら、おそらくスクラムチームの実力以上のことを計画しようとしているはずだ。もしかすると、スクラムのイベントについての理解が不足した状態で開発を進めているのかもしれない。
タイムボックスが守れないということは、スクラムチームが未熟なことのあらわれ。
スクラムで開発を進めていくためにも対処した方がいい箇所を指し示してくれている。
その機会を奪わないためにも、タイムボックスは延長してはいけない。
最も大事なのは、扱うものを小さくすること。
扱うものが小さいと、より具体的にイメージでき、確実にこなせる。
そうすれば開発も確実に前に進んでいく。
開発を先に進めたければ、次に何をするかはプロダクトバックログを見れば簡単にわかる。
（次のプロダクトバックログ項目をやればいいだけ。）
開発チームからプロダクトオーナーに対して、「早く終わったので次の項目に着手します。ここの仕様はこれでいいですか？」と連絡すれば良い。
実は、誰でもプロダクトバックログに追加していい。
それは、スクラムチーム以外の人であっても構わない。
この開発の中で実現したいことや、もっとこうした方がいいということは、なるべく多く集めないといけない。また、ある程度の時間が必要な作業もプロダクトバックログに追加すればいい。プロダクトバックログは、そうしたことがすべて記載されている一覧でないといけない。
もし、プロダクトバックログに誰も追記しなくなっていたら、それは良くない兆候。
スクラムでは、スクラムイベントを形だけやっていてもうまくいかない。それぞれのスクラムイベントやロールは何のためにあるのだろう？ また、何をすべきなんだろう？ こうしたことをスクラムチーム全員で考えていくことで、求められていることに応えていけるんだ。
ベロシティには「安定していること」が求められる。
ベロシティは先のことを考えるのに不可欠。
ベロシティを元にして、あとどれくらいのことを実現できそうかがわかってくる。
でも、そのもとになるベロシティがスプリントごとにバラバラの数字では、先のことはわからない。
ベロシティが安定しているのは良いスクラムチームの特徴。
（スプリント期間中のトラブルにうまく対処できているからこそ、安定している。）
スクラムチームとしてはベロシティを安定させたいと思っていても、周りから上げてほしいという声があがるかもしれない。だけど、その声に耳を傾けてはいけない。ベロシティをあげることに意識がいくと、別の悪影響が出てくる。それは、ベロシティをあげるように細工してしまうことなんだ。
ベロシティが安定しているスクラムチームは、全員が協力して作業を進めている。
新しい人がスクラムチームに馴染むまでには、どうしても時間が必要となる。
まずはその人にスクラムチームについて色々と知ってもらわないといけない。
ベロシティをあげるには、今より仕事を進めやすくすれば良い。
例えば、以下のような取り組みができないかを探してみると良い。
- 開発チームが今より高性能な PC で開発できたら作業は今よりうまく進まないだろうか？
- プロダクトオーナーが次のスプリントの準備に集中できるように、割り込んでくる作業を手伝ってあげたらどうだろうか？
- 余計な会議への参加をやめられないだろうか？
スクラムチームが全員参加すると決められているイベントは 3 つある。
- スプリントプランニング
- スプリントレビュー
- スプリントレトロスペクティブ
スクラムイベントに参加すべき理由はまだある。それは開発をうまく進めるうえで大切な情報を得るためなんだ。開発チームはスプリントレビューに参加することで、作るものにかけられた期待や、全体の状況を知ることができる。スクラムマスターなら、スクラムチームやステークホルダーの状況に異変がないかを知ることができる。こうした情報で、もっと作業はしやすくなる。
スクラムイベントでは大切な情報が得られる。
プロダクトオーナーを支援するのもスクラムマスターの大事な仕事。
ロールで担当する部分が分かれていることで、どこに問題があるかを見つけやすくしている。
問題を見つけたら、スクラムチームで解決する。
ユーザーストーリー とは、実際に使う人たちの視点で実現したいことを簡潔に記述したもの。
以下のようなフォーマットで書かれることが多い。
- 〈どういったユーザや顧客〉 として
- 〈どんな機能や性能〉 が欲しい
- それは 〈どんなことが達成したい〉 ためだ
ユーザストーリーの形式では伝えたいことを全部書き尽くすことはできない。
そのため、細かい部分は書かれたユーザストーリーを見ながら話す必要が出てくる。
わざと短く書くことによって、実現したいことについてスクラムチームが話し合う機会を頻繁に持つようにしている。
大事ななのは、実現したいものをなんとしてでも伝えること。
プロダクトオーナーは何を実現したいのかを考え、開発チームはどうやって実現するのかを考える。
実現したいことには理由がある。
それはスクラムチーム全員が知っていないといけない。
それをうまくやるためにできることはなんでもやるべし。
スクラムチームを常に良い状態にしておくのがスクラムマスターの役目。
スクラムチームを観察して、どこがうまくいっていないのかを見つけよう。
…たとえば、その予兆は書いたコードからもわかる。どう見ても良いコードではないのに誰も話題にしていないとか、ほかにも、開発チームが残業続きなのにスプリントプランニングでさらに多くの項目をやろうとしているとかもそうだ。こうしたことを見逃さないように、工夫をしてみよう。実際、何時まで開発作業をしているかとか、テストコードが増えているかを測る仕組みを自動化しているスクラムチームもあるんだ。こういう仕組みはスクラムマスターが率先して準備しよう。
もし問題が起きてしまったら、なるべく早く対処するしかない。
問題は放置すればするほど、スクラムチームに与える影響が大きく深刻になる。
だから、問題の解決も日々の作業として取り組むのが良い。
理想的な姿、活動の妨げとなるものを 障害 と呼ぶ。
障害を取り除くことで、スクラムチームはより理想に近づく。
そうすればスクラムチームが生む問題は減っていく。
スクラムマスターは障害になっていることを見つけて、取り除かないといけない。
一度にすべては取り除けないので、まずはそれを一覧にして管理しよう。
頻繁に見直すものなので、順序をつけた一覧にしておくとやりやすい。
この一覧はスクラムチームの見えるところに貼っておこう。そうすれば、スクラムチームを巻き込みやすくなる。たとえば、デイリースクラムが 15 分で終わらないことを、開発チームは良くないことと思っていないかもしれない。だけど、壁などに張り出すことで、スクラムマスターがそれをすごく深刻に捉えていることを伝えられる。 （中略） また、一覧を貼り出すことでスクラムマスターが問題を抱えていることもわかってくる。障害への取り組みに進捗が見られなかったり、新しい障害を見つけていなかったりしたら、スクラムマスターが何か問題を抱えているだろう。スクラムマスターもスクラムチームの一員なので、その時は周りで助けてあげよう。
まずはみんなの見えるところにそれを貼り出す。
そして、スクラムマスターはそれを率先して解決していく。
少しずつ良くし続ければ、周りのみんなも取り組めば良くなるんだと関心を持ってくれる。
プロダクトバックログに様々な意見が書かれているなら、それを整理してゴールを達成していくための最善の方法を見つけていくと良い。
そのために、プロダクトバックログについては以下のような作業を行う。
- 重要なことを見逃さないために順序を見直す
- 見積もりを最新にする
- ゴールを達成する上で最適な順序になるように見直す
スクラムは、状況に合わせて修正しながらゴールを達成していくやり方だ。当然スクラムチームを取り巻く状況はいつも変わる。たとえば、スプリントレビューでこうしたほうがいいと思った時点で、最初のスプリントの頃とは状況が変わっているんだ。その状況にいつも合わせるために、プロダクトバックログを更新する。そしてそれを整理するために見直し続けるのが重要なんだ。
スクラムではこうした活動はとても重要。
これをプロダクトバックログの手入れ（プロダクトバックログ・リファインメント）と呼んでいる。
この活動は日頃から取り組むことなので、定期的なイベントとしては規程されていない。
手戻りが起きやすいのは、何を実現したいかがあいまいなとき。
また、明確になっていないことに着手すると、今後のことも見えなくなってしまう。
着手した不明確な項目の見積もりはベロシティにも関係するので、今後の予想に大きな影響を与えるかもしれない。
プロダクトバックログのすべての項目を明確にする必要はない。
プロダクトバックログには、単なる思いつきのような漠然としたものも含まれていたほうがいい。
手戻りが起きないようにするのは、直近のスプリントで実現しようと考えているものだけで十分。
まずは大きな手戻りが起きないようにする。
直近の項目をどう実現すればゴールを達成できそうかを、スプリントで着手する前に確認しておくとよい。
（開発チームに意見をもらう、ペーパープロトタイピングで操作感を確認する、など。）
大きな手戻りが起きないようにできたら、次は、作業の手を止めてしまうような小さな手戻りもなくしていく。
- 実現したいことは先に深く理解しておく
- 決めるべき仕様を決めておく
- 技術的にどういう風に実現するといいかを確認しておく
スプリントで着手するための準備をしておくのは、とても大事なことなんだ。そうすれば、開発チームは、スプリントの期間中、実現したいものを実際に作っていく作業に集中できる。 （中略） また、あいまいになっていることが事前に取り除かれているので、スプリントプランニングでは確実な計画を作りやすくなったり、スプリントレビューではより今後のことについて考えるのに十分な時間を使ったりすることができる。そして、ベロシティが安定することにも繋がる。 （中略） スプリントの準備が必要なんだ。そしてそれは、少なくとも実際に着手するスプリントが始まる前までに済ませておくんだ。
準備のためのイベントを用意すると良い。
スクラムチームで定期的に集まって、プロダクトオーナーは次回以降のスプリントで実現したいことを伝え、みんなでそれについて話し合って詳細にしていく。
そして、着手するために必要なことを洗い出して、日々の作業に組み込む。
多くのスクラムチームでは、準備などのプロダクトバックログのリファインメントにスプリントの 10% ぐらいの時間を確保して、スプリントの計画に組み込んでいる。
ゴールに近づくための方法は2つある。
- スクラムチームの仕事の進め方を良くする
- 何かを調整してゴールに近づく
開発を進める上で調整できるものは次の 4 つ。
- 品質：これは絶対妥協してはだめ
- 予算
- 期間
- スコープ
どうしても調整が必要になった場合、最初に調整すべきはスコープ。
「達成してほしいゴールは、本当にそのスコープを守ることなんだろうか？」
「最初に決めたソフトウェアやドキュメントがすべて揃っていることなんだろうか？」
本当に達成したいことは、別にあるはず。
実現しない項目を削ったりして調整するのが難しいなら、どう実現するかに強弱をつけて調整してみよう。
当初想定していた機能は提供できなくても、簡単に実現できそうなほかのやり方で代替できないかを考えてみると良い。
スクラムでは、開発チームは自己組織化していて、機能横断的であることが求められている。
簡単にいうと、開発チームは「実現したいことに多少のバラツキがあっても、それらにうまく対応してタイムボックスまでに終わらせてくれる人たち」。
作業中に何か困ったことがあっても自分たちが中心となって解決するし、どの作業をするか指示をしなくても自分たちで考えることができる。
自己組織化とは、自分たちで状況に応じて役割を決めていくこと。
…そのときどきの状況で最も力を発揮できる人がリーダーシップを発揮して開発チームを引っ張っていけば、どんな状況も乗り越えやすいと思わないだろうか？ こうしたことを自然にできる開発チームのことを、自己組織化した開発チームと呼んでいる。
機能横断的であるとは、開発チームだけでスプリントを円滑に進めていけるようになっていること。
スプリントを進めていくのに必要なさまざまなことを、一人ひとりではなく開発チーム全員でうまく協力できていれば十分。
（一人ひとりが全部を完璧にこなせるようになっている必要はない。）
もし、開発チームがうまく開発を進められるだけのスキルや経験があるのか、そもそも誰が何を得意としているのかがわからないなら、 スキルマップ を書いてみると良い。
ここで大事なのは、開発チームとしてどんな状況で何ができるかを明らかにすることだ。これはスキルに限った話じゃない。考え方や経験、どういう仕事のやり方が得意かってことも大事なんだ。 （中略） お互いのそうした性格や得意不得意を知っていれば、開発チームはさまざまな状況を乗り越えていけるんだ。
ドラッカー風エクササイズ でチームの特徴を掴むと良い。
- これまでどんな開発をしていて、何が得意なのか
- どういう風に仕事をするタイプなのか
- 自分が大切に思う価値は何なのか
- 自分はどうやって貢献できそうか
もちろん、みんなが得意な作業だけをやっていてはだめ。
一人でやれることには限界がある。
誰かが困っていたら、ほかの人が助けるんだ。その状況で、苦手だからとか自分の役割はこうだとか考えていては、手遅れになってしまう。そういうことができるってことが、開発チームの一人ひとりが優秀であることより大切なことだ。
スクラムに代表されるアジャイル開発では、コミットメント という価値観を大事にしている。
コミットメントとは責任を伴う約束のこと。
スクラムでは、こうしたコミットメントを表明する機会はほかにもある。
- 今回のスプリントでどれぐらいの項目を実現させるのか
- 次のスプリントでは仕事の進め方のどこを良くするのか
実際の作業に関係のない人の意見はあくまで参考意見、ととらえる。
…最初は、その判断を的確にやるのは難しいと思うかもしれない。開発を進めていく上での大事な判断をしていくには、責任を持って取り組む必要があるからだ。誰もがそうした判断ができるように、スクラムではコミットメントを表明する機会を数多く用意しているんだ。そうしてコミットメントを繰り返し表明していくことで責任感が芽生えやすくなる。自分たちでこれはやるぞと決めたら、達成することを強く意識するだろう。それを、責任を持つきっかけにしてほしいんだ。スクラムなどのアジャイル開発は、みんなが責任を持って仕事に取り組んでくれることを期待している。なぜなら、みんながそういう姿勢で仕事に取り組むことが必ず良い結果に繋がっていくと考えているからだ。
ただし、コミットメントには良くない側面もある。
（約束を守ろうとして無理をしてしまう、など。）
まずは、責任を持って約束できるようになろう。それには自信を持てるようにならないといけない。自分たちが自信を持ってやれないうちに、適当な約束ばかりしちゃダメだ。もちろん最初は難しいかもしれない。けれど、最初は失敗してもかまわないから、自分たちでやれるかどうかの判断をしてみよう。その判断が間違っていたら、なぜ間違ったのかを考えればいい。そうすれば、その経験を生かして、次の機会には自信を持って判断できるようになるんだ。
大事なのは失敗から学ぶこと。
スクラムチームができたばかりの頃と、しばらくたった後で、スクラムチームの実力が同じではいけない。
開発は進めば進むほど、どんどん大変になる。
決めた仕様も書いたコードもどんどん増える。
その積み重なったものに押しつぶされないために成長しないといけない。
スクラムで求めているのは、コミットメントを必ず果たしてくれるスクラムチームではない。
責任を持って取り組んでいくことに価値を感じるスクラムチーム。
そういうスクラムチームを少しずつ築き上げていくべし。
実践編で書かなかったスクラムの大事なことが2つある。
- スプリントレトロスペクティブ
- 「プロダクト」という考え方
スプリントレトロスペクティブは、スクラムチームの仕事の進め方をもっと良いものに変えていくためのイベント。
最初の頃のスプリントレトロスペクティブは、スプリントで起きた問題に対処しようとして、問題解決のイベントになりがち。
自分たちで仕事の進め方を良くしていくことに頭を使うべし。
プロダクト は、スクラムチームが作るものの全体を指す言葉。
はじめのうちは、開発をどううまく進めるかに意識が向いてしまいがち。
が、出来上がったプロダクトをどれだけ良いものにしていくかが本当は大事。
もしあなたが開発チームの一員なら、もっと良いコードを書くためにエンジニアリングのスキルを伸ばしたり、良いプロダクトを作るのを手伝えるようにデザインやプロダクトオーナーの力になれることも学んだりしよう。もし、スクラムマスターなら、どうやって人に教えていくかを学んだり、せっかく育ったsクラムチームが解散するのを防いだりするなど自分の組織へアプローチする方法も学んだりしよう。プロダクトオーナーなら、もっと喜ばれるプロダクトにするために使える知識が世の中にはたくさんあるので、それを学ぼう。
良いスクラムチームになれるように、少しずつ学んで上達していくのが大事。