# スクラムガイド スクラム公式ガイド:ゲームのルール（2020 年 11 月） ## スクラムガイドの目的 我々は1990年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを2010年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。 スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。 成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採用されている。そうした状況を見ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専門家もスクラムを利用するようになった。スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。 スクラムを利用していると、本文書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発見・適用・考案することもあるだろう。そうしたものについては、スクラムガイドの目的の範囲外である。これらは状況に依存しており、スクラムを利用する状況によって大きく異なるからだ。スクラムフレームワークで利用できる戦術にはさまざまなものが存在するが、それらはスクラムガイド以外のところで説明されている。 Ken Schwaber & Jeff Sutherland 2020年11月 ## スクラムの定義 スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。 簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。 * プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。 * スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。 * スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。 * *繰り返す。* スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。 スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。 ## スクラムの理論 スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。 スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している。スクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。 スクラムでは、検査と適応のための4つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。 ### 透明性 創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。 ### 検査 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を支援するために、5つのイベントでリズムを提供している。 検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。 ### 適応 プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最小限に抑えるため、できるだけ早く調整しなければならない。 関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。 ## スクラムの価値基準 スクラムが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっている。 ***確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）*** スクラムチームは、ゴールを達成し、お互いにサポートすることを*確約*する。スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に*集中*する。スクラムチームとステークホルダーは、作業や課題を*公開*する。スクラムチームのメンバーは、お互いに能力のある独立した個人として*尊敬*し、一緒に働く人たちからも同じように*尊敬*される。スクラムチームのメンバーは、正しいことをする*勇気*や困難な問題に取り組む*勇気*を持つ。 これらの価値基準は、スクラムチームの作業・行動・振る舞いの方向性を示している。下される意思決定、実行される手順、スクラムの使用方法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。これらの価値基準がスクラムチームや一緒に働く人たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。 ## スクラムチーム スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位である。 スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。 スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は10人以下である。一般的に小さなチームのほうがコミュニケーションがうまく、生産性が高いことがわかっている。スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。 スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上する。 スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという3つの明確な責任を定義する。 ### 開発者 開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。 開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。 * スプリントの計画（スプリントバックログ）を作成する。 * 完成の定義を忠実に守ることにより品質を作り込む。 * スプリントゴールに向けて毎日計画を適応させる。 * 専門家としてお互いに責任を持つ。 ### プロダクトオーナー プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、 * プロダクトゴールを策定し、明示的に伝える。 * プロダクトバックログアイテムを作成し、明確に伝える。 * プロダクトバックログアイテムを並び替える。 * プロダクトバックログに透明性があり、見える化され、理解されるようにする。 上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化される。 プロダクトオーナーは1人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。 ### スクラムマスター スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう支援することで、その責任を果たす。 スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。 スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。 スクラムマスターは、さまざまな形でスクラムチームを支援する。 * 自己管理型で機能横断型のチームメンバーをコーチする。 * スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。 * スクラムチームの進捗を妨げる障害物を排除するように働きかける。 * すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。 スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。 * 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。 * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。 * 複雑な環境での経験的なプロダクト計画の策定を支援する。 * 必要に応じてステークホルダーとのコラボレーションを促進する。 スクラムマスターは、さまざまな形で組織を支援する。 * 組織へのスクラムの導入を指導・トレーニング・コーチする。 * 組織においてスクラムの実施方法を計画・助言する。 * 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。 * ステークホルダーとスクラムチームの間の障壁を取り除く。 ## スクラムイベント スプリントは他のすべてのイベントの入れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運用しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を生み、スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる。 すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。 ### スプリント スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。 一貫性を保つため、スプリントは1か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。 スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。 スプリントでは、 * スプリントゴールの達成を危険にさらすような変更はしない。 * 品質を低下させない。 * プロダクトバックログを必要に応じてリファインメントする。 * 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。 スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも1か月ごとに確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。 進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる。 スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろう。プロダクトオーナーだけがスプリントを中止する権限を持つ。 ### スプリントプランニング スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。 プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。 スプリントプランニングは次のトピックに対応する： **トピック1：このスプリントはなぜ価値があるのか？** プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。 **トピック2：このスプリントで何ができるのか？** 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。 スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる。 **トピック3：選択した作業をどのように成し遂げるのか？** 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することによって行われる。これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。 スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。 ### デイリースクラム デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。 デイリースクラムは、スクラムチームの開発者のための15分のイベントである。複雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの1日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、自己管理を促進する。 デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。 開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通じて頻繁に話し合う。 ### スプリントレビュー スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。 スプリントレビューは、スプリントの最後から2番目のイベントであり、スプリントが1か月の場合、タイムボックスは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。 ### スプリントレトロスペクティブ スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。 スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。 スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。 スプリントレトロスペクティブをもってスプリントは終了する。スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。 ## スクラムの作成物 スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最大化できるように設計されている。作成物を検査する人が、適応するときと同じ基準を持っている。 各作成物には、透明性と集中を高める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。 * プロダクトバックログのためのプロダクトゴール * スプリントバックログのためのスプリントゴール * インクリメントのための完成の定義 これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。 ### プロダクトバックログ プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。 作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。 #### 確約（コミットメント）：プロダクトゴール プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。 プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。 プロダクトゴールは、スクラムチームの長期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。 ### スプリントバックログ スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。 スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。 #### 確約（コミットメント）：スプリントゴール スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、一貫性と集中を生み出し、スクラムチームに一致団結した作業を促すものでもある。 スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。 ### インクリメント インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。 スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするための関門と見なすべきではない。 完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない。 #### 確約（コミットメント）：完成の定義 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。 完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。 インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。 ## 最後に スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである。 ### 謝辞 #### 人々 スクラムに貢献してくれた多くの方々の中でも、最初に尽力してくれた人物の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いたJeff McKennaとJohn Scumniotales。それから、Ken Schwaberと一緒に働いたMike SmithとChris Martin。みんなで一緒に働いたこともあった。その後の数年間は、さらに多くの方々が貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。 #### スクラムガイドの歴史 Ken SchwaberとJeff Sutherlandが、1995年のOOPSLAカンファレンスにおいてスクラムを共同発表した。この発表は、KenとJeffが過去数年間で学んだことを文書化したものであり、はじめて公開された正式なスクラムの定義である。 スクラムガイドは、Jeff SutherlandとKen Schwaberが30年以上かけて開発・進化・保守しているスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン、プロセス、インサイトなどが提供されている。これらは、生産性・価値・創造性・結果に対する満足度を高める可能性がある。 スクラムの詳細な歴史については、別のところで説明されている。初期の試行錯誤および証明の場であるIndividual, Inc.、Newspage、Fidelity Investments、IDX（現GE Medical）の各社に感謝したい。 ## 翻訳について 本ガイドは、上記の開発者による英語バージョンを日本語に翻訳したものである。日本語訳は角征典、荒本実、和田圭介が担当した。 過去の版の翻訳レビューについては、守田憲司さん、高江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川口恭伸さん、角谷信太郎さん、木村卓央さん、原田騎郎さん、吉羽龍太郎さん、むらはしけんいちさん、いろさん、たなべすなおさんに協力いただいた。 **翻訳に関する連絡先**：角征典（） ## 用語集 | | | | | | -------------------- | -------------- | ------------------ | ---------- | | **General Terms** | **一般用語** | **Roles** | **役割** | | Scrum | スクラム | Scrum Team | スクラムチーム | | **Theory** | **理論** | Scrum Master | スクラムマスター | | Empiricism | 経験主義 | Product Owner | プロダクトオーナー | | Transparency | 透明性 | Developers | 開発者 | | Inspection | 検査 | **Artifacts** | **作成物** | | Adaptation | 適応 | Product Backlog | プロダクトバックログ | | **Events** | **イベント** | Sprint Backlog | スプリントバックログ | | Sprint | スプリント | Increment | インクリメント | | Sprint Planning | スプリントプランニング | **Misc** | **その他** | | Daily Scrum | デイリースクラム | Definition of Done | 完成の定義 | | Sprint Review | スプリントレビュー | | | | Sprint Retrospective | スプリントレトロスペクティブ | | | ## スクラムガイド2017年版からスクラムガイド2020年版への変更点 ### 指示的な部分を削減 スクラムガイドは時間が経つにつれて少し指示的なものになっていた。2020年版では、指示的な表現を削除または緩和して、スクラムを最小限かつ十分なフレームワークに戻すことを目的としている。たとえば、デイリースクラムの質問の削除、PBI（プロダクトバックログアイテム）の属性に関する記述の緩和、スプリントバックログにあるレトロスペクティブのアイテムに関する記述の緩和、スプリントの中止のセクションの削減などを実施した。 ### ひとつのチームがひとつのプロダクトに集中する これはチーム内で分断が発生し、POと開発チームの関係が「プロキシ」や「我々と彼ら」といった問題につながることを排除するためである。存在するのは、PO、SM、開発者の3つの異なる責任を持ち、同じ目的を共有するひとつの「スクラムチーム」だけである。 ### プロダクトゴールの導入 スクラムガイド2020年版では「プロダクトゴール」を導入した。スクラムチームに大きな価値のある目的に集中してもらうためである。各スプリントでは、プロダクトを全体的なプロダクトゴールに近づける必要がある。 ### スプリントゴール、完成の定義、プロダクトゴールの居場所 以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴール」と「完成の定義」について説明していた。これらは作成物ではなく、作成物に付随するものだった。2020年版では「プロダクトゴール」を導入し、これらの位置づけを明確にした。3つの作成物には、それぞれの「確約（コミットメント）」が含まれる。つまり、プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義（カッコをなくした）が含まれる。これらの存在により透明性がもたらされ、作成物の進捗に集中できるようになる。 ### 自己組織化よりも自己管理 以前のスクラムガイドでは、開発チームは自己組織化しており、「誰が」「どのように」作業するかを選択できるとしていた。2020年版ではスクラムチームの自己管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。 ### スプリントプランニングの3つのトピック これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラムガイド2020年版では、3つ目のトピック「Why」に重点を置いた。これはスプリントゴールで言及されている。 ### 幅広い読者のために全体的に文章を簡略化 スクラムガイド2020年版では、冗長で複雑な文章とITに関する記述（例：テスト、システム、設計、要求など）を排除している。以上の変更で、スクラムガイドは13ページ未満となった。 © 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at and also described in summary form at . By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons. # 勝手に注釈付き参考文献 翻訳者が参考文献だと思うものを淡々と追加していくよ ## 方針 * シンプルにするのはいいけれど、参考文献がないのはどういうことなの？という思いから * とはいえ、網羅的なものにはしない（疲れるので） * スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） ## 歴史的な背景 スクラムガイドでは「**我々は1990年代初頭にスクラムを開発した**」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 * Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard business review, 64(1), 137-146. ただし、Jeffがこの論文を直接参照したわけではない。彼は、Peter DeGraceとLeslie Hulet Stahlの著書『Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms』を経由して、間接的に「スクラム」を参照したのである。 * DeGrace, P., & Stahl, L. H. (1990). Wicked problems, righteous solutions. Yourdon Press. 『Wicked Problems〜』では、なぜウォーターフォールがうまくいかないのかの考察と、それに対抗するための「All-at-Onceモデル」が提唱されている。 [![Image from Gyazo](https://i.gyazo.com/afa781440ce824e3613d831e964442f3.png)](https://gyazo.com/afa781440ce824e3613d831e964442f3) そして、この「All-at-Onceモデル」を構成するのが、日本の製造業における「刺身」と「スクラム」であり、先ほどの竹内・野中の「The new new product development game」で提唱された概念だったのだ。 このあたりの経緯については、以下のJeffの論文にも載っている。 * Sutherland, J. (2001). Inventing and Reinventing SCRUM in five Companies. Cutter IT journal, 14, 5-11. この論文によれば、最初のスクラムはJeffが所属するEasel Corporation社のプロジェクトでやっていたものだった。「みんなが模索していた時代」なので、その話を聞きつけたKen Schwaber（とMike Beedleも？）がやってきて、協力してスクラムの理論を作っていくことになる。そして、JeffとKenの2人の見解をまとめたものが、Kenの論文として出版される。著者名にKenしかないが、実際は複数人で書いたものらしい（要出典）。 * Schwaber, K. (1995). Scrum Development Process: Advanced Development Methods. In Proceedings of OOPSLA’95 Workshop on Business Object Design and Implementation, London, UK. * 「スクラム」に関する最初の論文 * [![Image from Gyazo](https://i.gyazo.com/18ff8ab8ae93e9e1b9b85a1db41c945b.png)](https://gyazo.com/18ff8ab8ae93e9e1b9b85a1db41c945b) * Gartner, L. (1996). The Rookie Primer. Radcliffe Rugby Football Club. * 「スクラム」とは何なのかをラグビーの説明書で調べたみたいだ 繰り返しになるが、当時は「みんなが模索していた時代」なので、似たようなことをやっている人たちは他にもいた。たとえば、James Coplienが、ボーランド社のコンパイラのチームを観察研究していた。その後『組織パターン』となるこの研究は、以下の論文として出版されている。JeffとCoplienはお互いに知見を共有していたようだ。たとえば「デイリースクラム」は[このプロジェクトに由来](https://www.scruminc.com/origins-daily-scrum/)している。 * Coplien, J. O. (1994, June). Borland software craftsmanship: A new look at process, quality and productivity. In Proceedings of the 5th Annual Borland International Conference (Vol. 5). また、当時はMitchell M. Waldropの『Complexity: The Emerging Science at the Edge of Order and Chaos』（邦訳：『複雑系』）が流行し、複雑系やカオス理論に対する関心が高まっていた。ものすごく噛み砕いて言えば、先のことなんかよくわからん！（計画なんて無理じゃね？）という感じ。 スクラムが複雑性やカオスを扱うきっかけとなった論文は以下に挙げたものなどいくつかあるが、なかでもBabatundeの論文はKenのお気に入りのようで、頻繁に引き合いに出される。 * James, G. (1987). Chaos: Making a new science. Viking Penguin, 9-31. * Langton, C. G. Artificial Life VI,(1988). * Babatunde, A. O., & Ray, W. H. (1994). Process dynamics, modeling and control. Oxford University Press. Kenは上記に影響を受けて「スクラムはカオスをコントロールする」という論文を書いている。 * Schwaber, K. (1996). [Controlled chaos: Living on the edge](http://jeffsutherland.org/oopsla96/schwaber.html). American Programmer, 9, 10-16. また、カオスや複雑性は「人々」「要求」「技術」から生じるノイズが原因だとして、概念図として、「ステーシーのチャート」を用いるようになる。ただ、これは根拠がはっきりしないためか、最近では使われないようだ。代わりに、Snowdenの「クネビンフレームワーク」が使用されることが多い。 * Stacey, R. D. (1999). Strategic management and organisational dynamics: The challenge of complexity to ways of thinking about organisations (3rd edition). Pearson education. * [![Image from Gyazo](https://i.gyazo.com/b2c5229f1986b9a878445471d8afd2be.png)](https://gyazo.com/b2c5229f1986b9a878445471d8afd2be) * Snowden, D. J., & Boone, M. E. (2007). A leader's framework for decision making. Harvard business review, 85(11), 68.（邦訳：「臨機応変の意思決定手法「クネビン・フレームワーク」による」） * [![Image from Gyazo](https://i.gyazo.com/75fd96d9403231dda2e27adf1cbc7257.png)](https://gyazo.com/75fd96d9403231dda2e27adf1cbc7257) その後、Mike Beedleがファーストオーサーとなり、KenとJeffも名を連ねている論文が1999年に発表される。Mikeの趣味だと思われるが、パターンランゲージがスクラムの世界に持ち込まれている。以下の図にも記載されているとおり、前述のCoplienの組織パターンともリンクされている。なお、これは後に『A Scrum Book』のスクラムパターンとして結実する。 * Beedle, M., Devos, M., Sharon, Y., Schwaber, K., & Sutherland, J. (1999). SCRUM: An extension pattern language for hyperproductive software development. Pattern languages of program design, 4, 637-651. * [![Image from Gyazo](https://i.gyazo.com/f271fdd6ba3c77a0b5b0621966bf96da.png)](https://gyazo.com/f271fdd6ba3c77a0b5b0621966bf96da) ## スクラムの理論 こうした複雑系への対応策として、スクラムは「**「経験主義」と「リーン思考」に基づいている**」とスクラムガイドに記載されている。 ### 経験主義 「経験主義」は*empiricism*の訳語であり、辞書にこう載っているので他に訳しようがないのだが、これを哲学における「（イギリス）経験論」のことだと思うとよくわからないことになってしまう。観念は経験や感覚から生ずる……みたいな意味ではない。大陸合理主義と対比しても意味はない。 スクラムにおける「経験主義」とは、前述のBabatundeがデュポン社に導入したプロセス制御理論に由来するもので、「複雑なプロセスは事前に予測・定義することはできず、経験的なモデルを必要とする」ことを意味している。つまり、試行錯誤しながらプロセスを制御していきましょう、ということ。簡単。 * Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall.（邦訳：『アジャイルソフトウェア開発スクラム』） ### リーン思考 「リーン」については検索すればいくらでも出てくるのだけど、簡単に言えばMITのジェームズ・P・ウォマックらが1980年代に日本の自動車産業を研究し、ムダを排除した生産方式の様子を「リーン（ぜい肉の取れた、体が締まった）」と名付けた、というもの。 スクラムも以下の書籍から多くの概念を拝借していると思われる。たとえば、工場の班長から「スクラムマスター」の概念をもらっている（Jeffいわく）。明言はないが、おそらく「プロダクトオーナー」もチーフエンジニア（当時は主査と呼ばれていた：車種のトップの人のこと）からもらっているはず。 * James P. Womack, Daniel T. Jones, Daniel Roos, & Massachusetts Institute of Technology. (1991). The machine that changed the world: The story of lean production. Harper Collins.（邦訳：『リーン生産方式が、世界の自動車産業をこう変える。―最強の日本車メーカーを欧米が追い越す日』） その後、ウォマックは「リーン・シンキング」という概念を提唱。タイトルは原著を踏襲しているのだろうが、文中では「リーン思考」として出てくるので、スクラムガイドでも「〜思考」とした。 * Womack, J. J., & Jones, J. DT (1996) Lean Thinking-Banish Waste and Create Wealth in Your Corporation. Simon & Shuster, New York, 400.（邦訳：『リーン・シンキング』） * [![Image from Gyazo](https://i.gyazo.com/4ee3092e2e480bcee728a59fa88ffcbe.png)](https://gyazo.com/4ee3092e2e480bcee728a59fa88ffcbe) リーンの話をすると忘れがちなのが、なんでムダを省くのか？ってところだ。それは上の図にもあるように「価値の流れを生み出すため」である。あるいは「創造的な仕事をするため」である。いずれにしても、ムダをやめるのには目的があるのだ。 ### 検査と適応 検査（inspect）と適応（adapt）は「複雑な環境下で検査を繰り返しながら適応していきましょう」という意味なので、出てきて当然というか、当たり前の話である。元々はそれぞれスプリントレビューとスプリントレトロスペクティブで行われるものだったが、現在はもっと細かい単位（デイリースクラムとか）でやりましょうという感じになっているので、特に2つのイベントに限定されない。 ただ、この2つの言葉がいつからセットで使われ始めたのかは定かではない。 Kenの最初の論文には "adaptation to change（変化に対する適応）" や "adaptively（適応的に/適応型で）" という表現は登場するが、"adapt" そのものは見られない。では、どこが出典なのかというと、Kenの2004年の本が初出とされることが多いようだ。 * Schwaber, K. (2004). Agile project management with Scrum. Microsoft press.（邦訳：『スクラム入門-アジャイルプロジェクトマネジメント』） もちろん文中でも登場するのだが、それよりも前に「序文」でMike Cohnが「you’ll learn \[snip] how to use its frequent **inspect-and-adapt** cycles（これからスクラムの検査と適応のサイクルを学びます）」と唐突に説明を始めている。どこで知ったんだ、その言葉。 ### 透明性 透明性（transparency）は「誰の目にも見える」という意味。「透明」だったら何も見えないじゃん、とかいうツッコミはとりあえず脇に置いておこう。英語っぽい表現なんだよねえ。直訳の日本語だと適していないのかもしれない。でも、まあ定訳なので仕方ないです。 で、透明性についても初出がKenの2004年の本のようだ。特に断りもなく「I also reminded the team members that Scrum requires **transparency**.（私はチームメンバーにスクラムには透明性が求められると伝えた）」と出てくる。そうですか。 ちなみに似たような表現として「Information Radiator（情報ラジエーター）」というのがある。冷却するんじゃなくて、情報を放射するという意味ね。ラジオを思い浮かべるといいだろう。これはAlistair Cockburnが提唱した言葉で、KPT以外にヒット作にめぐまれないAlistairの傑作だと思う！ * Cockburn, A. (2001). Agile software development: the cooperative game. Pearson Education. ## 価値基準 価値基準はKenの最初の本には載っていて、いつの間にか忘れられたんだけど、スクラムガイド2016年版から戻ってきた。そのことについて、JeffとKenが語っている動画があるので見るとよい。 * [Scrum Guide Refresh July 2016 - Scrum Pulse Episode #14](https://www.youtube.com/watch?v=0hRZffDD1ec) 価値基準はすべて漢字2文字で統一したかったので、「確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）」とした。ただ、この訳語を使うべきというつもりもないので、英語を併記することにした。 「確約（Commitment）」だけ、少し補足が必要だろう。辞書を引くと「献身、責任、約束」などがあるが、上記の動画でKenが「がんばりますー、やってみますー」みたいな気持ちでは、ゴールを達成できるわけがないだろ、みたいなことを言っていたので、少し強めの表現を使いたかったのだ。そこで、約束よりも強い「確約」にした。まあ、日常的には「コミットメント」としてもよいです。 ちなみに「価値を届ける」ときの価値は「Value」で、価値基準は「Values」。アジャイルやXPなどは歴史的な経緯で仕方なく、Valuesでも「価値」になってるけど、本来は「価値基準」がよかった。 ## 作成物 作成物は「artifact」の訳語なんだけど、artifactは訳すのが超絶難しくて、辞書には「人工物 、成果物、加工品」などがあるけど、どれもしっくりこなかった。なかでも「成果物」にするのは絶対によくなくて、たとえばプロダクトバックログなんか別に成果ちゃうやろ！と思っていたのだ。そんなとき、翻訳レビューアの守田さん（だったと記憶してるけど）が「作成物はどう？」って言ってくれたので、即採用したのだった。 ### インクリメント はじめて見た人は「はて……インクリメントとは……」と途方に暮れるかもしれない。これは、最終成果物となる製品などの部分集合を意味している。スプリントで生み出される何かだと考えてほしい。用語の初出は、Kenの最初の本に「Product Increments」として登場したときだろう。スクラムでは、成果物をIncrementally（漸進的に/増加的に）に作るため、増分を意味する「インクリメント（Increment）」が使われたのだと思われる。でも、ソフトウェア以外の世界でも使うのかな？ ## スクラムチーム 「**スクラムチームは（中略）通常は10人以下である**」とあるが、なぜ10人なのか。まず、以下の論文から最適なチーム規模は「4.6人」というのを参考値にしているようだ。 * Hackman, J. R., & Vidmar, N. (1970). Effects of size and task type on group performance and member reactions. Sociometry, 37-54. * [![Image from Gyazo](https://i.gyazo.com/313dbd73c53a1fe3934233449a907c47.png)](https://gyazo.com/313dbd73c53a1fe3934233449a907c47) スクラムでも基本的には「5人まで」がよいとされているが、XP由来のペアワーク／ペアプログラミングを考慮して、最適値の2倍の9.2人（≒10人）まで許容しているのかな？と思う（要出典）。 今回から「**スクラムチーム（中略）自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する**」と記載され、従来の「自己組織化」が「自己管理」に変わった。「自己組織化」は、前述の竹内・野中論文にある6つの特性のひとつ「Self-organizing project teams（自己組織化されたプロジェクトチーム）」が元ネタになっていると思われる。とはいえ、彼らのオリジナルの言葉ではなく、当時はこういう言い回しが流行ったのではないか。Wikipediaによれば「[1977年のノーベル化学賞を受賞した化学者・物理学者であるイリヤ・プリゴジン](https://ja.wikipedia.org/wiki/%E8%87%AA%E5%B7%B1%E7%B5%84%E7%B9%94%E5%8C%96)」が定義したそうな。それにしても、HBRの論文は参考文献がないから、これは論文というより、エッセイなんじゃなかろうか。査読してるの？ チームの話題でよく引用される本： * Lencioni, P. (2002). The five dysfunctions ofa team. Jossey-Bass （邦訳：『あなたのチームは、機能してますか？』） ### プロダクトオーナー ### スクラムマスター * Kotter, J. P., & Rathgeber, H. (2006). Our iceberg is melting: Changing and succeeding under any conditions. Macmillan.（邦訳：『カモメになったペンギン』） * Kotter, J. P. (1995). Leading change: Why transformation efforts fail.（邦訳：『企業変革力』） ## スクラムイベント ### スプリントプランニング ### スプリントレトロスペクティブ * Derby, E., Larsen, D., & Schwaber, K. (2006). Agile retrospectives: Making good teams great. Pragmatic Bookshelf.（邦訳：『アジャイルレトロスペクティブズ』） * 序文をKen Schwaberが書いている ## 著者の著書・論文 ### by Jeff Sutherland * Schwaber, K., & Sutherland, J. (2012). Software in 30 days: how agile managers beat the odds, delight their customers, and leave competitors in the dust. John Wiley & Sons.（邦訳：『Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド』） * Sutherland, J., & Sutherland, J. J. (2014). Scrum: the art of doing twice the work in half the time. Currency.（邦訳：『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』） * Sutherland, J., & COPLIE, J. (2019). A Scrum Book: The Spirit of the Game. Pragmatic Bookshelf. * Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). The secret history of agile innovation. Harvard Business Review, 4. （邦訳：「アジャイル開発を経営に活かす６つの原則」） * Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing agile. Harvard Business Review, 94(5), 40-50. * Rigby, D. K., Sutherland, J., & Noble, A. (2018). Agile at scale. Harvard Business Review, 96(3), 88-96.（邦訳：「アジャイル 全社展開の実践法」） ### by Ken Schwaber * 【再掲】Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1). Upper Saddle River: Prentice Hall.（邦訳：『アジャイルソフトウェア開発スクラム』） * 【再掲】Schwaber, K. (2004). Agile project management with Scrum. Microsoft press.（邦訳：『スクラム入門-アジャイルプロジェクトマネジメント』） * Schwaber, K. (2007). The enterprise and scrum. Microsoft press. * 【再掲】Schwaber, K., & Sutherland, J. (2012). Software in 30 days: how agile managers beat the odds, delight their customers, and leave competitors in the dust. John Wiley & Sons.（邦訳：『Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド』） * 【再掲】Schwaber, K. (1995). Scrum Development Process: Advanced Development Methods. In Proceedings of OOPSLA’95 Workshop on Business Object Design and Implementation, London, UK. * 【再掲】Schwaber, K. (1996). Controlled chaos: Living on the edge. American Programmer, 9, 10-16. ## 参考文献の参考文献 * [Jeff Sutherland’s Papers | Scrum Inc](https://www.scruminc.com/jeff-sutherlands-papers/) * [Origins of Scrum | Scrum Inc](https://www.scruminc.com/origins-of-scrum/) * [The Origins and Future of Scrum | Scrum.org](https://www.scrum.org/resources/origins-and-future-scrum) * [iki-iki](https://scrapbox.io/iki-iki/) # スクラムガイド2020 スクラム公式ガイド:ゲームのルール（2020 年 11 月） ## スクラムガイドの目的 我々は1990年代初頭にスクラムを開発した。世界中の人たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを2010年に執筆した。それ以来、機能的に小さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを支援している。 スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の目的があり、スクラムで実現される全体的な価値や結果に欠かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に立たなくなることさえある。 成長を続ける複雑な世界において、スクラムの利用は増加しており、我々はそれを見守っている。スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採用されている。そうした状況を見ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専門家もスクラムを利用するようになった。スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。 スクラムを利用していると、本文書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発見・適用・考案することもあるだろう。そうしたものについては、スクラムガイドの目的の範囲外である。これらは状況に依存しており、スクラムを利用する状況によって大きく異なるからだ。スクラムフレームワークで利用できる戦術にはさまざまなものが存在するが、それらはスクラムガイド以外のところで説明されている。 Ken Schwaber & Jeff Sutherland 2020年11月 ## スクラムの定義 スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。 簡単に言えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。 * プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。 * スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。 * スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。 * *繰り返す。* スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。 スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。 ## スクラムの理論 スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。 スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している。スクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである。 スクラムでは、検査と適応のための4つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。 ### 透明性 創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。 ### 検査 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を支援するために、5つのイベントでリズムを提供している。 検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。 ### 適応 プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最小限に抑えるため、できるだけ早く調整しなければならない。 関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。 ## スクラムの価値基準 スクラムが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっている。 **確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）** スクラムチームは、ゴールを達成し、お互いにサポートすることを*確約*する。スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に*集中*する。スクラムチームとステークホルダーは、作業や課題を*公開*する。スクラムチームのメンバーは、お互いに能力のある独立した個人として*尊敬*し、一緒に働く人たちからも同じように*尊敬*される。スクラムチームのメンバーは、正しいことをする*勇気*や困難な問題に取り組む*勇気*を持つ。 これらの価値基準は、スクラムチームの作業・行動・振る舞いの方向性を示している。下される意思決定、実行される手順、スクラムの使用方法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。これらの価値基準がスクラムチームや一緒に働く人たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。 ## スクラムチーム スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位である。 スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。 スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は10人以下である。一般的に小さなチームのほうがコミュニケーションがうまく、生産性が高いことがわかっている。スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。 スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上する。 スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという3つの明確な責任を定義する。 ### 開発者 開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。 開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。 * スプリントの計画（スプリントバックログ）を作成する。 * 完成の定義を忠実に守ることにより品質を作り込む。 * スプリントゴールに向けて毎日計画を適応させる。 * 専門家としてお互いに責任を持つ。 ### プロダクトオーナー プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、 * プロダクトゴールを策定し、明示的に伝える。 * プロダクトバックログアイテムを作成し、明確に伝える。 * プロダクトバックログアイテムを並び替える。 * プロダクトバックログに透明性があり、見える化され、理解されるようにする。 上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化される。 プロダクトオーナーは1人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。 ### スクラムマスター スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう支援することで、その責任を果たす。 スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。 スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。 スクラムマスターは、さまざまな形でスクラムチームを支援する。 * 自己管理型で機能横断型のチームメンバーをコーチする。 * スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する。 * スクラムチームの進捗を妨げる障害物を排除するように働きかける。 * すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする。 スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。 * 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する。 * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。 * 複雑な環境での経験的なプロダクト計画の策定を支援する。 * 必要に応じてステークホルダーとのコラボレーションを促進する。 スクラムマスターは、さまざまな形で組織を支援する。 * 組織へのスクラムの導入を指導・トレーニング・コーチする。 * 組織においてスクラムの実施方法を計画・助言する。 * 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。 * ステークホルダーとスクラムチームの間の障壁を取り除く。 ## スクラムイベント スプリントは他のすべてのイベントの入れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運用しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を生み、スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる。 すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。 ### スプリント スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。 一貫性を保つため、スプリントは1か月以内の決まった長さとする。前のスプリントが終わり次第、新しいスプリントが始まる。 スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。 スプリントでは、 * スプリントゴールの達成を危険にさらすような変更はしない。 * 品質を低下させない。 * プロダクトバックログを必要に応じてリファインメントする。 * 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。 スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも1か月ごとに確実になり、予測可能性が高まる。スプリントの期間が長すぎると、スプリントゴールが役に立たなくなり、複雑さが増し、リスクが高まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。 進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる。 スプリントゴールがもはや役に立たなくなった場合、スプリントは中止されることになるだろう。プロダクトオーナーだけがスプリントを中止する権限を持つ。 ### スプリントプランニング スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計画を立てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。 プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。 スプリントプランニングは次のトピックに対応する： **トピック1：このスプリントはなぜ価値があるのか？** プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。 **トピック2：このスプリントで何ができるのか？** 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と自信が高まる。 スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる。 **トピック3：選択した作業をどのように成し遂げるのか？** 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することによって行われる。これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。 スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。 ### デイリースクラム デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。 デイリースクラムは、スクラムチームの開発者のための15分のイベントである。複雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの1日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。これは集中を生み出し、自己管理を促進する。 デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。 開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通じて頻繁に話し合う。 ### スプリントレビュー スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。 スプリントレビューは、スプリントの最後から2番目のイベントであり、スプリントが1か月の場合、タイムボックスは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。 ### スプリントレトロスペクティブ スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。 スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。 スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。 スプリントレトロスペクティブをもってスプリントは終了する。スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。 ## スクラムの作成物 スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最大化できるように設計されている。作成物を検査する人が、適応するときと同じ基準を持っている。 各作成物には、透明性と集中を高める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。 * プロダクトバックログのためのプロダクトゴール * スプリントバックログのためのスプリントゴール * インクリメントのための完成の定義 これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。 ### プロダクトバックログ プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。 作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。 #### 確約（コミットメント）：プロダクトゴール プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。 プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。 プロダクトゴールは、スクラムチームの長期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。 ### スプリントバックログ スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。 スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。 #### 確約（コミットメント）：スプリントゴール スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、一貫性と集中を生み出し、スクラムチームに一致団結した作業を促すものでもある。 スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。 ### インクリメント インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利用可能にしなければならない。 スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするための関門と見なすべきではない。 完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない。 #### 確約（コミットメント）：完成の定義 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。 完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。 インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。 ## 最後に スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである。 ### 謝辞 #### 人々 スクラムに貢献してくれた多くの方々の中でも、最初に尽力してくれた人物の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いたJeff McKennaとJohn Scumniotales。それから、Ken Schwaberと一緒に働いたMike SmithとChris Martin。みんなで一緒に働いたこともあった。その後の数年間は、さらに多くの方々が貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。 #### スクラムガイドの歴史 Ken SchwaberとJeff Sutherlandが、1995年のOOPSLAカンファレンスにおいてスクラムを共同発表した。この発表は、KenとJeffが過去数年間で学んだことを文書化したものであり、はじめて公開された正式なスクラムの定義である。 スクラムガイドは、Jeff SutherlandとKen Schwaberが30年以上かけて開発・進化・保守しているスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン、プロセス、インサイトなどが提供されている。これらは、生産性・価値・創造性・結果に対する満足度を高める可能性がある。 スクラムの詳細な歴史については、別のところで説明されている。初期の試行錯誤および証明の場であるIndividual, Inc.、Newspage、Fidelity Investments、IDX（現GE Medical）の各社に感謝したい。 ## 翻訳について 本ガイドは、上記の開発者による英語バージョンを日本語に翻訳したものである。日本語訳は角征典、荒本実、和田圭介が担当した。 過去の版の翻訳レビューについては、守田憲司さん、高江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川口恭伸さん、角谷信太郎さん、木村卓央さん、原田騎郎さん、吉羽龍太郎さん、むらはしけんいちさん、いろさん、たなべすなおさんに協力いただいた。 **翻訳に関する連絡先**：角征典（） ## 用語集 | **General Terms** | **一般用語** | **Roles** | **役割** | | -------------------- | -------------- | ------------------ | ---------- | | Scrum | スクラム | Scrum Team | スクラムチーム | | **Theory** | **理論** | Scrum Master | スクラムマスター | | Empiricism | 経験主義 | Product Owner | プロダクトオーナー | | Transparency | 透明性 | Developers | 開発者 | | Inspection | 検査 | **Artifacts** | **作成物** | | Adaptation | 適応 | Product Backlog | プロダクトバックログ | | **Events** | **イベント** | Sprint Backlog | スプリントバックログ | | Sprint | スプリント | Increment | インクリメント | | Sprint Planning | スプリントプランニング | **Misc** | **その他** | | Daily Scrum | デイリースクラム | Definition of Done | 完成の定義 | | Sprint Review | スプリントレビュー | | | | Sprint Retrospective | スプリントレトロスペクティブ | | | ## スクラムガイド2017年版からスクラムガイド2020年版への変更点 ### 指示的な部分を削減 スクラムガイドは時間が経つにつれて少し指示的なものになっていた。2020年版では、指示的な表現を削除または緩和して、スクラムを最小限かつ十分なフレームワークに戻すことを目的としている。たとえば、デイリースクラムの質問の削除、PBI（プロダクトバックログアイテム）の属性に関する記述の緩和、スプリントバックログにあるレトロスペクティブのアイテムに関する記述の緩和、スプリントの中止のセクションの削減などを実施した。 ### ひとつのチームがひとつのプロダクトに集中する これはチーム内で分断が発生し、POと開発チームの関係が「プロキシ」や「我々と彼ら」といった問題につながることを排除するためである。存在するのは、PO、SM、開発者の3つの異なる責任を持ち、同じ目的を共有するひとつの「スクラムチーム」だけである。 ### プロダクトゴールの導入 スクラムガイド2020年版では「プロダクトゴール」を導入した。スクラムチームに大きな価値のある目的に集中してもらうためである。各スプリントでは、プロダクトを全体的なプロダクトゴールに近づける必要がある。 ### スプリントゴール、完成の定義、プロダクトゴールの居場所 以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴール」と「完成の定義」について説明していた。これらは作成物ではなく、作成物に付随するものだった。2020年版では「プロダクトゴール」を導入し、これらの位置づけを明確にした。3つの作成物には、それぞれの「確約（コミットメント）」が含まれる。つまり、プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義（カッコをなくした）が含まれる。これらの存在により透明性がもたらされ、作成物の進捗に集中できるようになる。 ### 自己組織化よりも自己管理 以前のスクラムガイドでは、開発チームは自己組織化しており、「誰が」「どのように」作業するかを選択できるとしていた。2020年版ではスクラムチームの自己管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。 ### スプリントプランニングの3つのトピック これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラムガイド2020年版では、3つ目のトピック「Why」に重点を置いた。これはスプリントゴールで言及されている。 ### 幅広い読者のために全体的に文章を簡略化 スクラムガイド2020年版では、冗長で複雑な文章とITに関する記述（例：テスト、システム、設計、要求など）を排除している。以上の変更で、スクラムガイドは13ページ未満となった。 © 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at and also described in summary form at . By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons. # スクラムガイド2017 スクラム公式ガイド:ゲームのルール（2017年10月） 2017年10月 [![Image from Gyazo](https://i.gyazo.com/ce73c8d51862b077fb418516fa1c6ee8.png)](https://gyazo.com/ce73c8d51862b077fb418516fa1c6ee8) Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland ## スクラムガイドの目的 スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割・イベント・作成物と、それらをまとめるルールが含まれる。スクラムは、Ken SchwaberとJeff Sutherlandが開発したものであり、スクラムガイドはこの2人が執筆・提供する。両者は共にスクラムガイドを支援している。 ## スクラムの定義 スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 スクラムとは、以下のようなものである。 * 軽量 * 理解が容易 * 習得は困難 スクラムは、1990年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない。さまざまなプロセスや技法を取り入れることのできるフレームワークである。スクラムは、これまでのプロダクト管理や仕事のテクニックの相対的な有効性を明らかにして、プロダクト・チーム・作業環境の継続的な改善を可能にする。 スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。 スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体で説明する。 スクラムフレームワークを使用する具体的な方法にはさまざまなものがあり、それらについては本稿では触れない。 ## スクラムの用途 当初、スクラムはプロダクトの開発と管理のために開発された。1990年代初頭から使用され、今では以下のように世界中で広く利用されている。 1. 有望な市場・技術・プロダクトの研究および特定 2. プロダクトや追加機能の開発 3. プロダクトや追加機能のリリース（1日に何度もリリースされる） 4. プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守 5. プロダクトの保守や刷新 スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。 技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、スクラムがその対応に有効であることは日々証明されている。 スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。 スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、数千人の成果やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。チームは協力や情報交換をしながら、洗練された開発アーキテクチャやターゲットとするリリース環境を整えていく。 スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、それは上記のような複雑な作業を意味している。 ## スクラムの理論 スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。 経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。 ### 透明性 経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。 例： * プロセスの用語を参加者全員で共有している。 * 作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。 ### 検査 スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。 ### 適応 プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。 スクラムでは、検査と適応のための4つの公式なイベントを規定している。詳しくは、「スクラムイベント」の節で説明する。 * スプリントプランニング * デイリースクラム * スプリントレビュー * スプリントレトロスペクティブ ## スクラムの価値基準 スクラムチームが、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり、あらゆる人に対する信頼が築かれる。スクラムチームのメンバーは、スクラムの役割・イベント・作成物に触れて仕事を進めるなかで、これらの価値基準を学習・探索する。 スクラムを活用するには、これらの5つの価値基準を上手に実践しなければいけない。個人は、スクラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。全員が、スプリントの作業とスクラムチームのゴールに集中しなければいけない。スクラムチームとステークホルダーは、すべての仕事とそれらを遂行する上での課題を公開することに合意しなければいけない。スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。 ## スクラムチーム スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。 スクラムチームは、前述した用途や複雑な仕事において、非常に高い効果を自ら証明している。 スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完成」したプロダクトを漸進的に届けることで、動作するプロダクトで役に立つ可能性のあるバージョンを常に利用可能にする。 ### プロダクトオーナー プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 * プロダクトバックログアイテムを明確に表現する。 * ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。 * 開発チームが行う作業の価値を最適化する。 * プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。 * 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。 上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。 ### 開発チーム 開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。「完成」したインクリメントは、スプリントレビューに必要である。インクリメントを作成できるのは、開発チームのメンバーだけである。 開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。 開発チームには、以下のような特徴がある。 * 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。 * 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。 * ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。 * テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。 * 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。 #### 開発チームの規模 開発チームに最適な人数は、小回りが利く程度に少なく、1つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。 ### スクラムマスター スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。 #### スクラムマスターはプロダクトオーナーを支援する スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。 * スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。 * 効果的なプロダクトバックログの管理方法を探す。 * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。 * 経験主義におけるプロダクトプランニングについて理解する。 * 価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。 * アジャイルを理解・実践している。 * 必要に応じてスクラムイベントをファシリテートする。 #### スクラムマスターは開発チームを支援する スクラムマスターは、さまざまな形で開発チームを支援する。 * 自己組織化・機能横断的な開発チームをコーチする。 * 開発チームが価値の高いプロダクトを作れるように支援する。 * 開発チームの進捗を妨げるものを排除する。 * 必要に応じてスクラムイベントをファシリテートする。 * スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。 #### スクラムマスターは組織を支援する スクラムマスターは、さまざまな形で組織を支援する。 * 組織へのスクラムの導入を指導・コーチする。 * 組織へのスクラムの導入方法を計画する。 * スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう。 * スクラムチームの生産性を高めるような変化を促す。 * 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。 ## スクラムイベント スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。スプリントを開始すると、その期間は固定され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。これは、プロセスでムダなことをせずに、必要な分だけ時間を使うためである。 スプリント以外のスクラムイベントは、何かを検査・適応するための公式な機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、非常に重要な透明性と検査の両方が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多くの機会を失う。 ### スプリント スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。開発中はスプリントの長さは常に一定である。スプリントが終了すると、すぐに新しいスプリントが開始される。 スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。 スプリントでは、 • スプリントゴールに悪影響を及ぼすような変更を加えない。 • 品質目標を下げない。 • 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。 スプリントは1か月以内のプロジェクトと考えることができる。プロジェクトと同様に、スプリントは何かを成し遂げるために使うものである。スプリントには、開発対象のゴール、開発のための設計や柔軟な計画、実際の作業、成果となるプロダクトインクリメントが含まれる。 スプリントの期間は1か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも1か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも1か月分のコストに収まるようになる。 #### スプリントの中止 スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このときに、ステークホルダー・開発チーム・スクラムマスターの意見を参考にすることもできる。 スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといって影響があることはほとんどない。 スプリントを中止した場合は、プロダクトバックログの「完成」したアイテムをレビューする。部分的にリリース判断可能なものについては、通常はプロダクトオーナーが受け入れる。未完成のプロダクトバックログアイテムは、再見積りをしてからプロダクトバックログに戻す。そこにかかった作業の価値は急速に低下するため、頻繁に再見積りが必要になる（訳注：作りかけの機能や設計については、時間が経つと状況が変わってしまうため、その価値が失われてしまうことが多い。そうすると、最初から見積りをやり直す必要が出てくる）。 スプリントを中止すると、新しいスプリントのスプリントプランニングのために全員が再度集まる必要があり、リソースを消費してしまう。また、スプリントの中止がチームのトラウマになってしまうこともある。とはいえ、スプリントの中止はめったに発生しない。 ### スプリントプランニング スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業である。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。 スプリントプランニングでは、以下の質問に答える。 • スプリントの成果であるインクリメントで何を届けることができるか？ • インクリメントを届けるために必要な作業をどのように成し遂げるか？ #### トピック1：スプリントで何ができるか？ 開発チームは、スプリントで開発できそうな機能を予想する。プロダクトオーナーは、スプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。 スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チームだけである。 スプリントプランニングでは、スクラムチームがスプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメントを開発する指針となるものである。 #### トピック2：選択した作業をどのように成し遂げるか？ プロダクトバックログアイテムを選択し、スプリントゴールを設定したら、開発チームはスプリントでそれらの機能を「完成」したプロダクトインクリメントにする方法を決める。選択したプロダクトバックログアイテムとそれらを届ける計画を合わせて、スプリントバックログと呼ぶ。 開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する。作業の規模や工数はバラバラであっても構わないが、開発チームが次のスプリントで実現できそうなものを計画する。開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。作業の単位は1日以下にすることが多い。開発チームは自己組織化して、スプリントバックログの作業を引き受ける。これはスプリントプランニングだけでなく、必要であればスプリントでも行う。 プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテムについて、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人を招待してアドバイスを求めることもできる。 スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとして、どのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。 #### スプリントゴール スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するものである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールはスプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チームは一致団結して作業ができる。 開発チームが作業するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するために、機能や技術を実装する。開発チームの予想と異なることが判明した場合は、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。 ### デイリースクラム デイリースクラムとは、開発チームのための15分間のタイムボックスのイベントである。スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の24時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。 開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。 デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。 * 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？ * 開発チームがスプリントゴールを達成するために、私が今日やることは何か？ * 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？ 開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業について、詳細な議論・適応・再計画を行うこともある。 スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任は開発チームにある。スクラムマスターは、デイリースクラムを15分間のタイムボックスで終わらせるように開発チームに伝える。 デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。 デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、検査と適応の重要なイベントである。 ### スプリントレビュー スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。 スプリントが1か月の場合、スプリントレビューは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。スクラムマスターはスプリントレビューが確実に開催されるようにして、参加者には目的を理解してもらうようにする。スクラムマスターは関係者全員にタイムボックスを守るように伝える。 スプリントレビューには、以下の要素が含まれる。 * 参加者は、スクラムチームと、プロダクトオーナーが招待した重要なステークホルダーである。 * プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。 * 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを議論する。 * 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。 * プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在の進捗から、可能性のある目標とデリバリーの日程を予測する。 * グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。 * 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性をレビューする。 * 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。 スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである。新たな機会に見合うように、プロダクトバックログを全体的に調整することもある。 ### スプリントレトロスペクティブ スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。 スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。 スクラムマスターは、このミーティングがポジティブで生産的になるようにする。スクラムマスターは、全員にタイムボックスを守るように伝える。スクラムマスターは、スクラムのプロセスを説明するために、チームメンバーとして参加する。 スプリントレトロスペクティブには、以下の目的がある。 * 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。 * うまくいった項目や今後の改善が必要な項目を特定・整理する。 * スクラムチームの作業の改善実施計画を作成する。 スクラムマスターは、次のスプリントが効果的で楽しいものになるように、スクラムチームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。スプリントレトロスペクティブにおいてスクラムチームは、作業プロセスの改善や「完成」の定義を調整することにより、プロダクトの品質を向上させる方法を計画する。ただし、プロダクトや組織の基準と衝突しないように適切に行う。 スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければいけない。これらの改善策の実施は、スクラムチーム自体の検査に対する適応になる。改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応に集中するための公式な機会である。 ## スクラムの作成物 スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最大化するように設計されている。 ### プロダクトバックログ プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。 プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダクトが存在する限り、プロダクトバックログも存在し続けるのである。 プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれていることが多い。 プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物である。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。 複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバックログに追加することもある。 プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。 並び順が上のプロダクトバックログアイテムほど明確で詳細である。明確で詳細であれば、見積りも正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チームが従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく細分化する。開発チームが1つのスプリントで「完成」できそうなプロダクトバックログアイテムは、スプリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なすことができる。プロダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。 開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。 #### ゴールへの進捗を追跡する いずれかの時点で、ゴールに対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビュー時点の残作業の合計と比較して、希望する期日までにゴールに到達できるかどうかを評価する。この情報はステークホルダー全員に明らかにする。 進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなどのさまざまなプラクティスが使用されている。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、これから先の意思決定に使用できる。 ### スプリントバックログ スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、次のインクリメントに含まれる機能と、その機能を「完成」したインクリメントにして届けるために必要な作業について、開発チームが予想したものである。 スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。 スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイリースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。 新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了すれば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリントバックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。 #### スプリントの進捗を追跡する スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。 ### インクリメント インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものである。スプリントの終了時には、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。 ## 作成物の透明性 スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 スクラムマスターは、プロダクトオーナー、開発チーム、その他の関係者と一緒になって、作成物が完全に透明化されているかを理解する。不完全な透明性に対処するには、いくつかのプラクティスが存在する。スクラムマスターは、そのなかから最適なプラクティスを選択してもらえるように支援する。スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違いを把握することで、不完全な透明性を検知できる。 スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。 ### 「完成（Done）」の定義 プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。 この定義は、開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる。各スプリントの目的は、そのときの「完成」の定義に合ったリリース判断可能な機能のインクリメントを届けることである。 開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能なものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に関して、開発組織の慣例・標準・ガイドラインが存在する場合は、スクラムチームは最低でもそれを守らなければいけない。 インクリメントの「完成」の定義が開発組織に**存在しない**場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。 インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。 スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。新しい定義を作り、それを使用していくと、以前に「完成」したインクリメントにも手を加えなければいけないことが明らかになる可能性がある。あらゆるプロダクトやシステムは「完成」の定義を備えるべきである。それがあらゆる作業の完了基準となる。 ## 最後に スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・イベント・作成物・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。 ## 謝辞 ### 人々 スクラムに貢献してくれた非常に多くの人たちのなかでも、最初に貢献してくれた人物の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いたJeff McKennaとJohn Scumniotales。それから、Ken Schwaberと一緒に働いたMike SmithとChris Martinと同僚たち。翌年からは、その他にも多くの人たちが貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。 ### 歴史 Ken SchwaberとJeff Sutherlandが1995年からスクラムに取り組み、1995年のOOPSLAカンファレンスにおいて、スクラムを共同発表した。この発表は、KenとJeffが過去数年間で学んだことを文書化したものであり、はじめて公開された正式なスクラムの定義である。 スクラムの歴史は別のところで説明されている。最初の試行錯誤の場であるIndividual, Inc.、Newspage、Fidelity Investments、IDX（現 GE Medical）に感謝したい。 スクラムガイドは、Jeff SutherlandとKen Schwaberが20年以上かけて開発・進化・保守してきたスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン、プロセス、インサイトなどが提供されている。これらは、生産性、価値、創造性、結果に対する満足を高める可能性がある。 ## 翻訳 本ガイドは、Ken SchwaberとJeff Sutherlandによる英語バージョンを日本語に翻訳したものである。日本語訳は、角征典が担当した。最新版の翻訳は、守田憲司さん、高江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川口恭伸さん、角谷信太郎さん、木村卓央さん、原田騎郎さん、吉羽龍太郎さんにご協力いただいた。以前の版では、むらはしけんいちさん、いろさん、たなべすなおさんにもご協力いただいた。 **翻訳に関する連絡先**：角征典（） ## スクラムガイド2016年版と2017年版の変更点 ### **1.「スクラムの用途」のセクションを追加した。** 当初、スクラムはプロダクトの開発と管理のために開発された。1990年代初頭から使用され、今では以下のように世界中で広く利用されている。 1. 有望な市場・技術・プロダクトの研究および特定 2. プロダクトや追加機能の開発 3. プロダクトや追加機能のリリース（1日に何度もリリースされる） 4. プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守 5. プロダクトの保守や刷新 スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。 技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、スクラムがその対応に有効であることは日々証明されている。 スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。 スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、数千人の成果やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。チームは協力や情報交換をしながら、洗練された開発アーキテクチャやターゲットとするリリース環境を整えていく。 スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、それは上記のような複雑な作業を意味している。 ### **2.「スクラムマスター」のセクションの表現を変更し、役割を明確化した。** スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。そのためにスクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援する。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。 ### **3.「スクラムマスターはプロダクトオーナーを支援する」のセクションに以下を追加した。** スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。 ### **4.「デイリースクラム」のセクションの最初の段落を以下のように変更した。** デイリースクラムとは、開発チームのための15分間のタイムボックスのイベントである。スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の24時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。 ### **5.「デイリースクラム」のセクションを変更して、デイリースクラムのゴールを明確化した。** デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。 ・開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？\ ・開発チームがスプリントゴールを達成するために、私が今日やることは何か？\ ・私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？ ### **6.タイムボックスについて明確化した。** 「最大」という言葉を追加して、イベントを時間どおりに行なう必要があるのかという疑問を解消し、許容される最大の時間であることを明確にした。 ### **7.「スプリントバックログ」のセクションに以下を追加した。** 継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。 ### **8.「インクリメント」のセクションが明確になるように以下を追加した。** インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。 ©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at and also described in summary form at . By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons. # スクラムガイド2016 スクラム完全ガイド:ゲームのルール（2016年7月） 6Developed and sustained by Ken Schwaber and Jeff Sutherland ## スクラムガイドの目的 スクラムは、複雑なプロダクトを開発・維持するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割・イベント・作成物と、それらをまとめるルールが含まれる。スクラムは、Ken SchwaberとJeff Sutherlandが開発したものであり、スクラムガイドはこの2人が執筆・提供する。両者は共にスクラムガイドを支援している。 ## スクラムの定義 スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 スクラムとは、以下のようなものである。 * 軽量 * 理解が容易 * 習得は困難  スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることのできるフレームワークである。これらのプロダクト管理や開発プラクティスの相対的な有効性を明確にし、改善を可能にするのである。 スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。 スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体で説明する。 スクラムフレームワークを使用する戦略にはさまざまなものがあり、それらについては本稿では触れない。 ## スクラムの理論 スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験*と*既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。 経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。 #### 透明性 経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。 例： * プロセスの用語を参加者全員で共有している。 * 作業をする人とその作成物を受け取る人が「完成」の定義を共有している。 #### 検査 スクラムのユーザーは、スクラムの作成物や進捗を頻繁に検査し、変化を検知する。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行えば、検査は最大の効果をもたらす。 #### 適応 プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査人が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。 スクラムでは、検査と適応のための4つのイベントを規定している。詳しくは、「スクラムイベント」の節で説明する。 * スプリントプランニング * デイリースクラム * スプリントレビュー * スプリントレトロスペクティブ ## スクラムの価値基準 スクラムチームが、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり、あらゆる人に対する信頼が築かれる。スクラムチームのメンバーは、スクラムのイベント・役割・作成物に触れて、仕事を進めるなかで、これらの価値基準を学習・探索する。 スクラムを活用するには、これらの5つの価値基準を上手に実践しなければいけない。個人はスクラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない。スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を公開することに合意しなければいけない。スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。 ## スクラムチーム スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。 スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完成」したプロダクトを漸進的に届けることで、動作するプロダクトを常に利用可能な状態にする。 ### プロダクトオーナー プロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 * プロダクトバックログアイテムを明確に表現する。 * ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。 * 開発チームが行う作業の価値を最適化する。 * プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。 * 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。 上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。開発チームに作業を依頼できるのは、プロダクトオーナーだけである。開発チームもプロダクトオーナー以外から作業依頼を受け付けてはいけない。 ### 開発チーム 開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバーだけである。 開発チームは、自分たちの作業を構成・管理する。そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。 開発チームには、以下のような特徴がある。 * 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。 * 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。 * ある人にしかできない作業があったとしても、メンバーの肩書きは開発者だけである。このルールに例外はない。 * テスティングやビジネス分析のような領域であっても、スクラムは開発チームのサブチームを認めていない。このルールに例外はない。 * 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。 #### 開発チームの規模 開発チームに最適な人数は、小回りが利く程度に少なく、1つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと、経験的プロセスの管理が複雑になってしまう。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。 ### スクラムマスター スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。 #### スクラムマスターはプロダクトオーナーを支援する スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。 * 効果的なプロダクトバックログの管理方法を探す。 * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。 * 経験主義におけるプロダクトプランニングについて理解する。 * 価値を最大化するためにプロダクトバックログを調整する方法を知っている。 * アジャイルを理解・実践している。 * 必要に応じてスクラムイベントをファシリテートする。 #### スクラムマスターは開発チームを支援する スクラムマスターは、さまざまな形で開発チームを支援する。 * 自己組織化・機能横断的な開発チームをコーチする。 * 開発チームが価値の高いプロダクトを作れるように支援する。 * 開発チームの進捗を妨げるものを排除する。 * 必要に応じてスクラムイベントをファシリテートする。 * スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。 #### スクラムマスターは組織を支援する スクラムマスターは、さまざまな形で組織を支援する。 * 組織へのスクラムの導入を指導・コーチする。 * 組織へのスクラムの導入方法を計画する。 * スクラムや経験的プロダクト開発を社員や関係者に理解・実施してもらう。 * スクラムチームの生産性を高めるような変化を促す。 * 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。 ## スクラムイベント スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。スプリントを開始すると、その期間は固定化され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。プロセスでムダなことをせずに、必要な分だけ時間を使うためである。 スプリント以外のスクラムイベントは、何かを検査・適応するための正式な機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、重要な透明性や検査が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多くの機会を失う。 ### スプリント スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。スプリントは、開発作業を行う連続した期間である。スプリントが終了すると、新しいスプリントが開始される。 スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。 スプリントでは、以下のようなことを行う。 * スプリントゴールに悪影響を及ぼすような変更を加えない。 * 品質目標を下げない。 * 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。 スプリントは1か月以内のプロジェクトと考えることができる。プロジェクトと同様に、スプリントは何かを成し遂げるために使うものである。スプリントには、開発対象の定義・開発のための設計や柔軟な計画・開発作業・成果となるプロダクトが含まれる。 スプリントの期間は1か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも1か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも1か月分のコストに収まるようになる。 #### スプリントの中止 スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このときに、関係者・開発チーム・スクラムマスターの意見を参考にすることもできる。 スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといってさほど意味をなすことはない。 スプリントを中止した場合は、プロダクトバックログの「完成」したアイテムをレビューする。部分的にリリース判断可能なものがあれば、プロダクトオーナーが受け入れることになる。未完成のプロダクトバックログアイテムは、再見積りをしてからプロダクトバックログに戻す。そこにかかった作業の価値は急速に低下するため、頻繁に再見積りが必要になる（訳注：作りかけの機能や設計については、時間が経つと状況が変わってしまうため、その価値が失われてしまうことが多い。そうすると、最初から見積りをやり直す必要が出てくる）。 スプリントを中止すると、新しいスプリントのスプリントプランニングが必要となり、そのためのリソースを消費してしまう。それから、スプリントの中止がチームのトラウマになってしまうこともある。とはいえ、スプリントの中止はめったに発生しない。 ### スプリントプランニング スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業だ。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。 スプリントプランニングでは、以下の質問に答える。 * スプリントの成果であるインクリメントで何を届けることができるか？ * インクリメントを届けるために必要な作業をどのように成し遂げるか？ #### トピック1：スプリントで何ができるか？ 開発チームは、スプリントで開発する機能を予想する。プロダクトオーナーは、スプリントで達成すべき目的と、完成後にスプリントゴールを達成するプロダクトバックログアイテムについて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。 スプリントプランニングのインプットは、プロダクトバックログ・最新のプロダクトインクリメント・開発チームの予想キャパシティと実績である。プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何が達成できるかを評価できるのは、開発チームだけである。 開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとに、スクラムチームでスプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメントを開発する指針となるものである。 #### トピック2：選択した作業をどのように成し遂げるのか？ プロダクトバックログアイテムを選択し、スプリントゴールを設定したら、開発チームはそれらの機能をスプリントで「完成」プロダクトインクリメントにする方法を決める。選択したプロダクトバックログアイテムとそれらを届ける計画を合わせて、スプリントバックログと呼ぶ。 開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する。作業の規模や工数はバラバラであっても構わないが、作業の計画については開発チームがスプリントで達成できそうなものにする。開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。作業の単位は1日以下にすることが多い。開発チームは自己組織化して、スプリントバックログの作業を引き受ける。これはスプリントプランニングだけでなく、必要であればスプリントでも行う。 プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテムについて、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人にアドバイスを求めることもできる。 スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとしてどのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。 #### スプリントゴール スプリントゴールはスプリントの目標セットであり、プロダクトバックログの実装によって実現するものである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールはスプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チームは一致団結して作業ができる。 開発チームが計画するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するために、それらの機能や技術を実装する。開発チームの予想よりも難しいと判明した場合は、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。 ### デイリースクラム デイリースクラムとは、開発チームが活動の速度を合わせ、次の24時間の計画を作る15分間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。 デイリースクラムは毎日、同じ時間・場所で開催する。これは、複雑にならないようにするためである。デイリースクラムでは、開発チームのメンバーが以下のことを説明する。 * 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？ * 開発チームがスプリントゴールを達成するために、私が今日やることは何か？ * 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？ 開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの作業の進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。開発チームまたは一部のチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業について詳細な議論・適応・再計画を行うこともある。 スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任は開発チームにある。スクラムマスターは、デイリースクラムを15分間のタイムボックスで終わらせるように開発チームに伝える。 スクラムマスターは、デイリースクラムには開発チームのメンバーしか参加できないというルールを遵守する。 デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、検査と適応の重要なイベントである。 ### スプリントレビュー スプリントレビューとは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームと関係者がスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、非公式なミーティングである。インクリメントを提示することで、フィードバックやさらなる協力を引き出すことを目的とする。 スプリントが1か月の場合、スプリントレビューのタイムボックスは4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。スクラムマスターは参加者に目的を理解してもらうようにする。スクラムマスターはスクラムチームにタイムボックスを守るように伝える。 スプリントレビューには、以下の要素が含まれる。 * 参加者（スクラムチームと重要な関係者）はプロダクトオーナーが招待する。 * プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。 * 開発チームは、スプリントでうまくいったこと・直面した問題点・それをどのように解決したかを議論する。 * 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。 * プロダクトオーナーは、現在のプロダクトバックログを審議する。（必要であれば）現在の進捗から完了日を予測する。 * グループ全体で次に何をするかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。 * プロダクトの市場や今後の利用状況についてレビューした場合、次に行う最も価値の高いことが変更されることもある。 * プロダクトの次のリリースに対するスケジュール・予算・性能・市場をレビューする。 スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである。新たな機会に見合うように、プロダクトバックログを全体的に調整することもある。 ### スプリントレトロスペクティブ スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。 スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブのタイムボックスは3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。スクラムマスターは、スクラムプロセスを説明するためにチームメンバーとしてイベントに参加する。 スプリントレトロスペクティブには、以下の目的がある。 * 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。 * うまくいった項目や今後の改善が必要な項目を特定・整理する。 * スクラムチームの作業の改善実施計画を作成する。 スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。スクラムチームは、「完成」の定義を適切に調整して、プロダクトの品質を向上させる方法を計画する。 スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければいけない。これらの改善策の実施は、開発チーム自体の検査の適応になる。改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応に集中するための正式な機会である。 ## スクラムの作成物 スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最大化するように設計されている。 ### プロダクトバックログ プロダクトバックログは、プロダクトに必要なものがすべて並べられた一覧であり、プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。 プロダクトバックログは決して完成しない。開発の初期段階には、最初から明確でよく理解できた要求が並べられている。プロダクトバックログは、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダクトが存在する限り、プロダクトバックログは不滅である。 プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。 プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物である。ビジネス要求・市場の状態・技術の変化が、プロダクトバックログの変化につながる。 複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。また、アイテムをグループにまとめる属性をプロダクトバックログに追加する。 プロダクトバックログアイテムに詳細・見積り・並び順を追加することを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。 並び順が上のアイテムほど明確で詳細である。明確で詳細であれば、見積りも正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チームが従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく細分化する。開発チームが1つのスプリントで「完成」できそうなプロダクトバックログアイテムは、スプリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なせる。プロダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。 開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。 #### ゴールへの進捗を監視する いずれかの時点で、開発ゴールに対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビューのときの残作業の合計と比較して、希望する時間までにゴールに到達できるかどうかを評価する。この情報は関係者全員に明らかにされる。 進捗の見通しを立てるために、バーンダウンやバーンアップなどのさまざまなプラクティスが使用されている。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに起きたものだけが、これから先の意思決定に使用できる。 ### スプリントバックログ スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、開発チームが作成するインクリメントに含まれる機能と、その機能を「完成」インクリメントにして届けるために必要な作業の予想である。 スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。 スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイリースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。 新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了すれば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリントバックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。 #### スプリントの進捗を監視する スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。 ### インクリメント インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものである。スプリントの終わりには、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。 ## 作成物の透明性 スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物が不完全に透明化されていれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 スクラムマスターは、プロダクトオーナー・開発チーム・その他の関係者と一緒になって、作成物が完全に透明化されているかを理解する。不完全な透明性に対処するには、いくつかのプラクティスが存在する。スクラムマスターは、そのなかから最適なプラクティスの選択してもらえるように支援する。スクラムマスターは、作成物の検査・パターンの察知・言説の傾聴・期待値と実際値の違いを把握することで、不完全な透明性を検知できる。 スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。 ### 「完成（Done）」の定義 プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。 この定義は、開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる。各スプリントの目的は、そのときの「完成」の定義に合ったリリース判断可能な機能のインクリメントを届けることである。 開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能なものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に関して、開発組織の慣例・標準・ガイドラインが存在する場合は、スクラムチームは最低でもそれを守らなければいけない。インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。 インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。 スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。プロダクトやシステムは「完成」の定義を備えるべきである。それがあらゆる作業の完了基準となる。 ## 最後に スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・作成物・イベント・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。 ## 謝辞 ### 人々 スクラムに貢献してくれた非常に多くの人たちのなかでも、最初の10年間に貢献してくれた人の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いてくれたJeff McKenna。それから、Ken Schwaberと一緒に働いてくれたMike SmithとChris Martin。翌年からは、その他にも多くの人たちが貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。 ### 歴史 1995年のOOPSLAカンファレンスにおいて、Ken SchwaberとJeff Sutherlandがスクラムを共同発表した。この発表は、KenとJeffがスクラムを数年間適用した経験から学んだことを文書化したものである。 スクラムの歴史は長い。最初の試行錯誤の場であるIndividual, Inc.・Fidelity Investments・IDX（現 GE Medical）に感謝したい。 スクラムガイドは、Jeff SutherlandとKen Schwaberが20年以上かけて開発・保守してきたスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン・プロセス・インサイトなどが提供されている。これらは生産性・価値・創造性・プライドを最適化するものである。 ### 翻訳 本ガイドは、Ken SchwaberとJeff Sutherlandによる英語バージョンを日本語に翻訳したものである。日本語訳は角征典（ワイクル株式会社）<>が担当した。 翻訳レビューは、守田憲司（@wsfjp）さん、むらはしけんいち（@sanemat）さん、角谷信太郎（@kakutani）さん、栗秋宏徳さん、@irohirokiさん、@takaesu0さん、 @miholovesqさん、@sunaotさん、@kawagutiさんにビューにご協力いただいた。
## 変更履歴 ### 2013年から2016年にかけてのスクラムガイドの変更点 1\. 「スクラムの価値基準」のセクションを追加。\ \ スクラムチームが、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり、あらゆる人に対する信頼が築かれる。スクラムチームのメンバーは、スクラムのイベント・役割・作成物に触れて、仕事を進めるなかで、これらの価値基準を学習・探索する。\ \ スクラムを活用するには、これらの5つの価値基準を上手に実践しなければいけない。個人はスクラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない。スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を公開することに合意しなければいけない。スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。 ### 2011年から2013年にかけてのスクラムガイドの変更点 1\. 「作成物の透明性」の節を追加した。スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物が不完全に透明化されていれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 2\. スプリントプランニングが1つのイベントになった。そのなかで「スプリントで何ができるか？」と「選択した作業をどのように成し遂げるのか？」の2つのトピックを扱う。開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとに、スクラムチームでスプリントゴールを設定する。スプリントゴールは、開発チームの作業に一貫性を持たせるものである。それは、共通のゴールがないバラバラのチームでは成し遂げられなかった作業である。このスプリントゴールを正式に追加した。 3\. プロダクトバックログは、グルーミングではなくリファインメントする。リファインメントされたプロダクトバックログアイテムは透明化され、スプリントプランニングのインプットとして十分に理解可能であり、適切な粒度となっている。このように透明化されたプロダクトバックログアイテムのことを「準備完了（Ready）」であるという。「準備完了（Ready）」と「完成（Done）」は、透明性を補強する2つの状態である。 4\. スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントはタイムボックス化されていて、時間に上限がある。スプリント（他のイベントのコンテナ）は期間が固定化され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。プロセスでムダなことをせずに、必要な分だけ時間を使うためだ。 5\. プランニングイベントとしてのデイリースクラムの重要性を強調した。ステータス確認のイベントになっているのをよく見かける。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。このイベントのインプットは、スプリントゴールに向かってチームがどのように活動しているかであり、アウトプットは、スプリントゴールを達成するためにチームの作業を最適化する新しいあるいは改訂した計画である。したがって、個人ではなくチームを強調するために、3つの質問を再構成した。 a. 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？ b. 開発チームがスプリントゴールを達成するために、私が今日やることは何か？ c. 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？ 価値の概念をスプリントレビューで使うために強化した。スプリントレビューでは、スプリントの成果について、スクラムチームと関係者が一緒に議論する。スプリントの成果とスプリントで変更したプロダクトバックログを参考にして、参加者全員は価値を最適化するために次に何ができるかを一緒に考える。 # スクラムガイド2013 スクラム完全ガイド:ゲームのルール（2013年7月） Developed and sustained by Ken Schwaber and Jeff Sutherland ## スクラムガイドの目的 スクラムは、複雑なプロダクトを開発・維持するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割・イベント・作成物と、それらをまとめるルールが含まれる。スクラムは、Ken SchwaberとJeff Sutherlandが開発したものであり、スクラムガイドはこの2人が執筆・提供する。両者は共にスクラムガイドを支援している。 ## スクラムの定義 スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 スクラムとは、以下のようなものである。 * 軽量 * 理解が容易 * 習得は困難  スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることのできるフレームワークである。これらのプロダクト管理や開発プラクティスの相対的な有効性を明確にし、改善を可能にするのである。 スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。 スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体で説明する。 スクラムフレームワークを使用する戦略にはさまざまなものがあり、それらについては本稿では触れない。 ## スクラムの理論 スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。 経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。 #### 透明性 経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。 例： * プロセスの用語を参加者全員で共有している。 * 作業をする人とその作成物を受け取る人が「完成」の定義を共有している。 #### 検査 スクラムのユーザーは、スクラムの作成物や進捗を頻繁に検査し、変化を検知する。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行えば、検査は最大の効果をもたらす。 #### 適応 プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査人が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。 スクラムでは、検査と適応を行う4つのイベントをスプリントで規定している。詳しくは、「スクラムイベント」の節で説明する。 * スプリントプランニング * デイリースクラム * スプリントレビュー * スプリントレトロスペクティブ ## スクラムチーム スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。 スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完成」したプロダクトを漸進的に届けることで、動作するプロダクトを常に利用可能な状態にする。 ### プロダクトオーナー プロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 * プロダクトバックログアイテムを明確に表現する。 * ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。 * 開発チームが行う作業の価値を最適化する。 * プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。 * 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。 上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。開発チームに作業を依頼できるのは、プロダクトオーナーだけである。開発チームもプロダクトオーナー以外から作業依頼を受け付けてはいけない。 ### 開発チーム 開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバーだけである。 開発チームは、自分たちの作業を構成・管理する。そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。 開発チームには、以下のような特徴がある。 * 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。 * 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。 * ある人にしかできない作業があったとしても、メンバーの肩書きは開発者だけである。このルールに例外はない。 * テスティングやビジネス分析のような領域であっても、スクラムは開発チームのサブチームを認めていない。このルールに例外はない。 * 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。 #### 開発チームの規模 開発チームに最適な人数は、小回りが利く程度に少なく、1つのスプリントで重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと、経験的プロセスの管理が複雑になってしまう。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。 ### スクラムマスター スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。 #### スクラムマスターはプロダクトオーナーを支援する スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。 * 効果的なプロダクトバックログの管理方法を探す。 * 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。 * 経験主義におけるプロダクトプランニングについて理解する。 * 価値を最大化するためにプロダクトバックログを調整する方法を知っている。 * アジャイルを理解・実践している。 * 必要に応じてスクラムイベントをファシリテートする。 #### スクラムマスターは開発チームを支援する スクラムマスターは、さまざまな形で開発チームを支援する。 * 自己組織化・機能横断的な開発チームをコーチする。 * 開発チームが価値の高いプロダクトを作れるように支援する。 * 開発チームの進捗を妨げるものを排除する。 * 必要に応じてスクラムイベントをファシリテートする。 * スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。 #### スクラムマスターは組織を支援する スクラムマスターは、さまざまな形で組織を支援する。 * 組織へのスクラムの導入を指導・コーチする。 * 組織へのスクラムの導入方法を計画する。 * スクラムや経験的プロダクト開発を社員や関係者に理解・実施してもらう。 * スクラムチームの生産性を高めるような変化を促す。 * 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。 ## スクラムイベント スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。スプリントを開始すると、その期間は固定化され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。プロセスでムダなことをせずに、必要な分だけ時間を使うためである。 スプリント以外のスクラムイベントは、何かを検査・適応するための公式の機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、重要な透明性や検査が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多くの機会を失う。 ### スプリント スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。スプリントは、開発作業を行う連続した期間である。スプリントが終了すると、新しいスプリントが開始される。 スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。 スプリントでは、以下のようなことを行う。 * スプリントゴールに悪影響を及ぼすような変更を加えない。 * 品質目標を下げない。 * 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。 スプリントは1か月以内のプロジェクトと考えることができる。プロジェクトと同様に、スプリントは何かを成し遂げるために使うものである。スプリントには、開発対象の定義・開発のための設計や柔軟な計画・開発作業・成果となるプロダクトが含まれる。 スプリントの期間は1か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも1か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも1か月分のコストに収まるようになる。 #### スプリントの中止 スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このときに、関係者・開発チーム・スクラムマスターの意見を参考にすることもできる。 スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといってさほど意味をなすことはない。 スプリントを中止した場合は、プロダクトバックログの「完成」したアイテムをレビューする。部分的にリリース判断可能なものがあれば、プロダクトオーナーが受け入れることになる。未完成のプロダクトバックログアイテムは、再見積りをしてからプロダクトバックログに戻す。そこにかかった作業の価値は急速に低下するため、頻繁に再見積りが必要になる（訳注：作りかけの機能や設計については、時間が経つと状況が変わってしまうため、その価値が失われてしまうことが多い。そうすると、最初から見積りをやり直す必要が出てくる）。 スプリントを中止すると、新しいスプリントのスプリントプランニングが必要となり、そのためのリソースを消費してしまう。それから、スプリントの中止がチームのトラウマになってしまうこともある。とはいえ、スプリントの中止はめったに発生しない。 ### スプリントプランニング スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業だ。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。 スプリントプランニングでは、以下の質問に答える。 * スプリントの成果であるインクリメントで何を届けることができるか？ * インクリメントを届けるために必要な作業をどのように成し遂げるか？ #### トピック1：スプリントで何ができるか？ 開発チームは、スプリントで開発する機能を予想する。プロダクトオーナーは、スプリントで達成すべき目的と、完成後にスプリントゴールを達成するプロダクトバックログアイテムについて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。 スプリントプランニングのインプットは、プロダクトバックログ・最新のプロダクトインクリメント・開発チームの予想キャパシティと実績である。プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。スプリントで何が達成できるかを評価できるのは、開発チームだけである。 開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとに、スクラムチームでスプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメントを開発する指針となるものである。 #### トピック2：選択した作業をどのように成し遂げるのか？ プロダクトバックログアイテムを選択し、スプリントゴールを設定したら、開発チームはそれらの機能をスプリントで「完成」プロダクトインクリメントにする方法を決める。選択したプロダクトバックログアイテムとそれらを届ける計画を合わせて、スプリントバックログと呼ぶ。 開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する。作業の規模や工数はバラバラであっても構わないが、作業の計画については開発チームがスプリントで達成できそうなものにする。開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。作業の単位は1日以下にすることが多い。開発チームは自己組織化して、スプリントバックログの作業を引き受ける。これはスプリントプランニングだけでなく、必要であればスプリントでも行う。 プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテムについて、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人にアドバイスを求めることもできる。 スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとしてどのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。 #### スプリントゴール スプリントゴールはスプリントの目標セットであり、プロダクトバックログの実装によって実現するものである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールはスプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チームは一致団結して作業ができる。 開発チームが計画するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するために、それらの機能や技術を実装する。開発チームの予想よりも難しいと判明した場合は、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。 ### デイリースクラム デイリースクラムとは、開発チームが活動の速度を合わせ、次の24時間の計画を作る15分間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。 デイリースクラムは毎日、同じ時間・場所で開催する。これは、複雑にならないようにするためである。デイリースクラムでは、開発チームのメンバーが以下のことを説明する。 * 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？ * 開発チームがスプリントゴールを達成するために、私が今日やることは何か？ * 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？ 開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの作業の進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。開発チームまたは一部のチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業について詳細な議論・適応・再計画を行うこともある。 スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任は開発チームにある。スクラムマスターは、デイリースクラムを15分間のタイムボックスで終わらせるように開発チームに伝える。 スクラムマスターは、デイリースクラムには開発チームのメンバーしか参加できないというルールを遵守する。 デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、検査と適応の重要なイベントである。 ### スプリントレビュー スプリントレビューとは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームと関係者がスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、非公式なミーティングである。インクリメントを提示することで、フィードバックやさらなる協力を引き出すことを目的とする。 スプリントが1か月の場合、スプリントレビューのタイムボックスは4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。スクラムマスターは参加者に目的を理解してもらうようにする。スクラムマスターはスクラムチームにタイムボックスを守るように伝える。 スプリントレビューには、以下の要素が含まれる。 * 参加者（スクラムチームと重要な関係者）はプロダクトオーナーが招待する。 * プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。 * 開発チームは、スプリントでうまくいったこと・直面した問題点・それをどのように解決したかを議論する。 * 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。 * プロダクトオーナーは、現在のプロダクトバックログを審議する。（必要であれば）現在の進捗から完了日を予測する。 * グループ全体で次に何をするかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。 * プロダクトの市場や今後の利用状況についてレビューした場合、次に行う最も価値の高いことが変更されることもある。 * プロダクトの次のリリースに対するスケジュール・予算・性能・市場をレビューする。 スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである。新たな機会に見合うように、プロダクトバックログを全体的に調整することもある。 ### スプリントレトロスペクティブ スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。 スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブのタイムボックスは3時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。スクラムマスターは、スクラムプロセスを説明するためにチームメンバーとしてイベントに参加する。 スプリントレトロスペクティブには、以下の目的がある。 * 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。 * うまくいった項目や今後の改善が必要な項目を特定・整理する。 * スクラムチームの作業の改善実施計画を作成する。 スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。スクラムチームは、「完成」の定義を適切に調整して、プロダクトの品質を向上させる方法を計画する。 スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければいけない。これらの改善策の実施は、開発チーム自体の検査の適応になる。改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応のための公式な機会である。 ## スクラムの作成物 スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最大化するように設計されている。 ### プロダクトバックログ プロダクトバックログは、プロダクトに必要なものがすべて並べられた一覧であり、プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。 プロダクトバックログは決して完成しない。開発の初期段階には、最初から明確でよく理解できた要求が並べられている。プロダクトバックログは、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダクトが存在する限り、プロダクトバックログは不滅である。 プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。 プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物である。ビジネス要求・市場の状態・技術の変化が、プロダクトバックログの変化につながる。 複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。また、アイテムをグループにまとめる属性をプロダクトバックログに追加する。 プロダクトバックログアイテムに詳細・見積り・並び順を追加することを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の10%以下にすることが多い。ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。 並び順が上のアイテムほど明確で詳細である。明確で詳細であれば、見積りも正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チームが従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく細分化する。開発チームが1つのスプリントで「完成」できそうなプロダクトバックログアイテムは、スプリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なせる。プロダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。 開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。 #### ゴールへの進捗を監視する いずれかの時点で、開発ゴールに対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビューのときの残作業の合計と比較して、希望する時間までにゴールに到達できるかどうかを評価する。この情報は関係者全員に明らかにされる。 進捗の見通しを立てるために、バーンダウンやバーンアップなどのさまざまなプラクティスが使用されている。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに起きたものだけが、これから先の意思決定に使用できる。 ### スプリントバックログ スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、開発チームが作成するインクリメントに含まれる機能と、その機能を「完成」インクリメントにして届けるために必要な作業の予想である。 スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。 スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイリースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。 新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了すれば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリントバックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。 #### スプリントの進捗を監視する スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。 ### インクリメント インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものである。スプリントの終わりには、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。 ## 作成物の透明性 スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物が不完全に透明化されていれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 スクラムマスターは、プロダクトオーナー・開発チーム・その他の関係者と一緒になって、作成物が完全に透明化されているかを理解する。不完全な透明性に対処するには、いくつかのプラクティスが存在する。スクラムマスターは、そのなかから最適なプラクティスの選択してもらえるように支援する。スクラムマスターは、作成物の検査・パターンの察知・言説の傾聴・期待値と実際値の違いを把握することで、不完全な透明性を検知できる。 スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。 ### 「完成（Done）」の定義 プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。 この定義は、開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる。各スプリントの目的は、そのときの「完成」の定義に合ったリリース判断可能な機能のインクリメントを届けることである。 開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能なものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に関して、開発組織の慣例・標準・ガイドラインが**存在する**場合は、スクラムチームは最低でもそれを守らなければいけない。インクリメントの「完成」の定義が開発組織に**存在しない**場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。 インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。 スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。プロダクトやシステムは「完成」の定義を備えるべきである。それがあらゆる作業の完了基準となる。 ## 最後に スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・作成物・イベント・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。 ## 謝辞 ### 人々 スクラムに貢献してくれた非常に多くの人たちのなかでも、最初の10年間に貢献してくれた人の名前を挙げたい。まず、Jeff Sutherlandと一緒に働いてくれたJeff McKenna。それから、Ken Schwaberと一緒に働いてくれたMike SmithとChris Martin。翌年からは、その他にも多くの人たちが貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されていなかっただろう。 ### 歴史 1995年のOOPSLAカンファレンスにおいて、Ken SchwaberとJeff Sutherlandがスクラムを共同発表した。この発表は、KenとJeffがスクラムを数年間適用した経験から学んだことを文書化したものである。 スクラムの歴史は長い。最初の試行錯誤の場であるIndividual, Inc.・Fidelity Investments・IDX（現 GE Medical）に感謝したい。 スクラムガイドは、Jeff SutherlandとKen Schwaberが20年以上かけて開発・保守してきたスクラムを文書化したものである。その他の情報源では、スクラムフレームワークを補完するパターン・プロセス・インサイトなどが提供されている。これらは生産性・価値・創造性・プライドを最適化するものである。 ## 翻訳 本ガイドは、Ken SchwaberとJeff Sutherlandによる英語バージョンを日本語に翻訳したものである。日本語訳は角征典<>が担当した。翻訳レビューには、守田憲司（@wsfjp）さん、むらはしけんいち（@sanemat）さん、角谷信太郎（@kakutani）さん、栗秋宏徳さんにご協力いただいた。以前の版では、@irohirokiさん、@takaesu0さん、 @miholovesqさん、@sunaotさん、@kawagutiさんにもレビューにご協力いただいた。 ## 2011年から2013年にかけてのスクラムガイドの変更点 1\. 「作成物の透明性」の節を追加した。スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物が不完全に透明化されていれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 2\. スプリントプランニングが1つのイベントになった。そのなかで「スプリントで何ができるか？」と「選択した作業をどのように成し遂げるのか？」の2つのトピックを扱う。開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとに、スクラムチームでスプリントゴールを設定する。スプリントゴールは、開発チームの作業に一貫性を持たせるものである。それは、共通のゴールがないバラバラのチームでは成し遂げられなかった作業である。このスプリントゴールを正式に追加した。 3\. プロダクトバックログは、グルーミングではなくリファインメントする。リファインメントされたプロダクトバックログアイテムは透明化され、スプリントプランニングのインプットとして十分に理解可能であり、適切な粒度となっている。このように透明化されたプロダクトバックログアイテムのことを「準備完了（Ready）」であるという。「準備完了（Ready）」と「完成（Done）」は、透明性を補強する2つの状態である。 4\. スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。すべてのイベントはタイムボックス化されていて、時間に上限がある。スプリント（他のイベントのコンテナ）は期間が固定化され、増減することはできない。スプリント以外のイベントについては、目的が達成されたときに終了することもある。プロセスでムダなことをせずに、必要な分だけ時間を使うためだ。 5\. プランニングイベントとしてのデイリースクラムの重要性を強調した。ステータス確認のイベントになっているのをよく見かける。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。このイベントのインプットは、スプリントゴールに向かってチームがどのように活動しているかであり、アウトプットは、スプリントゴールを達成するためにチームの作業を最適化する新しいあるいは改訂した計画である。したがって、個人ではなくチームを強調するために、3つの質問を再構成した。 a. 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？\ b. 開発チームがスプリントゴールを達成するために、私が今日やることは何か？\ c. 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？ 6\. 価値の概念をスプリントレビューで使うために強化した。スプリントレビューでは、スプリントの成果について、スクラムチームと関係者が一緒に議論する。スプリントの成果とスプリントで変更したプロダクトバックログを参考にして、参加者全員は価値を最適化するために次に何ができるかを一緒に考える。 # スクラムガイド2011 スクラム完全ガイド:ゲームのルール（2011年10月） Developed and sustained by Ken Schwaber and Jeff Sutherland ## スクラムガイドの目的 スクラムは、複雑なプロダクトを開発・維持するためのフレームワークである。本ガイドでは、スクラムの定義を説明する。スクラムの定義には、スクラムの役割、イベント、成果物、そして、それらをまとめるルールが含まれる。スクラムは、Ken SchwaberとJeff Sutherlandによって開発されたものである。スクラムガイドは、この両者が共に執筆・提供・支援する。 ## スクラムの概要 スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 スクラムとは、次のようなものである。 * 軽量 * 理解が容易 * 習得は非常に困難 スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることのできるフレームワークである。プロダクト管理や開発プラクティスの相対的効果を明確にすることで、改善を可能にするのである。 ### スクラムフレームワーク スクラムフレームワークは、スクラムチームとその役割・イベント・成果物・ルールで構成される。それぞれに目的があり、スクラムの利用や成功に欠かせないものである。 スクラムフレームワークを使用する戦略にはさまざまなものがあり、それらについては別のところで記述するものとする。 スクラムのルールは、役割・イベント・成果物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体を通して説明する。 ## スクラムの理論 スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。 経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。 **透明性** 経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、この点が標準化され、関係者全員が共通理解を持つことである。 例： * プロセスを指す用語が、関係者全員で共有されていなければならない。 * 「完了（Done）」の定義1 が、作業をする人と成果物を受け取る人で共有されていなければならない。 **検査** スクラムでは、好ましくない変化を検知できるように、成果物や進捗がゴールに向かっているかを頻繁に検査しなければならない。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行うことで、検査は最大の効果をもたらすものである。 **適応** プロセスに不備があり、成果物であるプロダクトを受け入れられないと検査人が判断した場合、プロセスやその構成要素を調整しなければならない。調整はできるだけ早く行い、これ以上の逸脱を防がなければならない。 スクラムでは、検査と適応を行う4つの機会を公式に設けている。詳しくは、「スクラムイベント」の節で説明する。 * スプリント計画ミーティング * デイリースクラム * スプリントレビュー * スプリントレトロスペクティブ ## スクラム スクラムは、複雑なプロダクト開発を支援するためのフレームワークである。スクラムは、スクラムチームとその役割・イベント・成果物・ルールで構成される。それぞれに目的があり、スクラムの利用や成功に欠かせないものである。 スクラムのルールは、役割・イベント・成果物をまとめ、それらの関係性や相互作用を統括するものである。スクラムのルールについては、本稿全体を通して説明する。 ## スクラムチーム スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。 スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化するためである。「完了」したプロダクトを漸進的に届けることで、動作するプロダクトが常に利用可能な状態にしている。 ### プロダクトオーナー プロダクトオーナーは、プロダクトの価値と開発チームの作業を最大化することに責任を持つ。その作業は、組織・スクラムチーム・個人によって、大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ唯一の人物である。プロダクトバックログの管理には、次のようなものがある。 * プロダクトバックログの項目を明確に表現する。 * ゴールとミッションを達成できるようにプロダクトバックログの項目を並び替える。 * 開発チームが行う作業の価値を保証する。 * 全員にプロダクトバックログを見える化・透明化・明確化し、スクラムチームに次の作業を伝える。 * プロダクトバックログの項目を開発チームが理解できるようにする。 上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーは1人の人間であり、委員会であってはならない。委員会の要求をプロダクトオーナーがプロダクトバックログに反映することもできるが、優先度を変えるにはプロダクトオーナーが納得しなければならない。 プロダクトオーナーが成功するには、組織全体でプロダクトオーナーの意見を尊重しなければならない。プロダクトオーナーの決定は、プロダクトバックログの内容や順番付けという形で見える化されている。開発チームの作業に依頼できるのは、プロダクトオーナーだけである。また、開発チームもその他からの作業依頼を受け付けてはいけない。 ### 開発チーム 開発チームは、リリース判断可能な「完了」したプロダクトのインクリメントを、各スプリントの終わりに届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバだけである。 開発チームは、自らの作業を構成・管理するものであり、そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。開発チームには、次のような特徴がある。 * 自己組織化されている。プロダクトバックログをリリース判断可能なインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。 * 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。 * ある人にしかできない作業があったとしても、メンバの肩書きは開発者だけである。このルールに例外はない。 * メンバに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。 * テストやビジネス分析などに特化したサブチームは存在しない。 #### 開発チームの規模 開発チームに最適な人数は、小回りが利く程度に少なく、重要な作業が成し遂げられる程度に多い人数である。開発チームのメンバが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、チームの規模が小さいと、スキル不足が原因で出荷判断可能なインクリメントをスプリントで届けられない可能性もでてくる。メンバが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと、経験的プロセスの管理が複雑になってしまう。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数には含まれない。 ### スクラムマスター スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。スクラムマスターは、スクラムチームのサーバントリーダー（訳注：メンバが成果を上げるために支援や奉仕をするリーダーのこと）である。 スクラムマスターは、スクラムチームとのやり取りで役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらうようにする。スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。 #### プロダクトオーナーの支援 スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。 * 効果的なプロダクトバックログの管理方法を探す。 * ビジョン・ゴール・プロダクトバックログの項目を明確に開発チームに伝える。 * 明確で簡潔なプロダクトバックログの項目の作成方法を開発チームに教える。 * 経験主義における長期のプロダクト計画について理解する。 * アジャイルを理解・実践する。 * 要望・必要に応じてスクラムイベントをファシリテートする。 #### 開発チームの支援 スクラムマスターは、さまざまな形で開発チームを支援する。 * 自己組織化・機能横断的な開発チームをコーチする。 * 高価値のプロダクトを作る方法を開発チームに教育・指導する。 * 開発チームの進捗を妨げるものを排除する。 * 要望・必要に応じてスクラムイベントをファシリテートする。 * スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。 #### 組織の支援 スクラムマスターは、さまざまな形で組織を支援する。 * スクラムの導入を指導・コーチする。 * 組織にあったスクラムの推進方法を計画する。 * スクラムと経験的プロダクト開発を従業員や関係者に理解・実施してもらう。 * スクラムチームの生産性を高めるような変化を促す。 * 他のスクラムマスターと一緒に組織へのスクラム導入の効果を高める。 ## スクラムイベント スクラムでは、イベントを設けて規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化している。イベントには、時間に上限のあるタイムボックスを使う。これは、計画プロセスで時間を無駄にせず、必要な分だけ時間を使うようにするためである。 スプリント以外のすべてのスクラムイベントは、何かを検査・適応する公式の機会である（スプリントはその他のイベントの入れ物である）。これらのイベントは、重要な透明性や検査が実現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の機会の多くを失うのである。 ### スプリント スクラムの中心はスプリントである。これは、「完了」した、動作する、リリース判断可能なプロダクトのインクリメントを作るための、1か月以下のタイムボックスである。スプリントは、開発作業を行う連続した期間である。スプリントが終了すると、新しいスプリントが開始される。 スプリントは、スプリント計画ミーティング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。 スプリントでは、次のようなことを行う。 * スプリントゴールに影響するような変更を加えない。 * 開発チームの編成を維持する。 * 品質目標を下げない。 * 学習が進むにつれて、スコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。 スプリントは1か月以内のプロジェクトと考えることができる。プロジェクト同様、スプリントは何かを成し遂げるために使う。スプリントには、開発対象の定義・開発のための設計や柔軟な計画・開発作業・成果物となるプロダクトが含まれる。 スプリントの期間は1か月以内である。スプリントが長すぎると、開発対象の定義が変更されたり、複雑度が上昇したり、リスクが増大したりする可能性がある。スプリントでは、ゴールへの進捗を少なくとも1か月ごとに検査・適応して、予測可能にしている。また、リスクも1か月分のコストに収まるようにしている。 #### スプリントの中止 スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このとき、関係者・チーム・スクラムマスターの意見を参考にすることもできる。 スプリントゴールが古くなったらスプリントを中止する。会社の方向性や市場・技術の状況が変化すると、スプリントゴールが古くなってしまう。通常、状況を考えて意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといってさほど意味をなすことはない。 スプリントを中止したら、プロダクトバックログの「完了」した項目をレビューする。出荷判断可能なものであれば、プロダクトオーナーが受け入れる。未完成のものは、再見積もりをしてから、プロダクトバックログに戻す。かかった作業は失われたものとなるので、再見積もりが必要になることが多い。 スプリントが中止されると、新しいスプリントのスプリント計画ミーティングが必要となり、それを開催するリソースを消費してしまう。スプリントの中止によって、チームのトラウマになることもある。しかし、中止はめったに起きないことである。 ### スプリント計画ミーティング スプリントの作業は、スプリント計画ミーティングで計画する。計画はスクラムチームの共同作業である。 スプリントが1か月の場合、スプリント計画ミーティングのタイムボックスは8時間である。スプリントの期間が短ければ、その長さに比例して時間が短くなる。たとえば、スプリントが2週間の場合、スプリント計画ミーティングは4時間になる。 スプリント計画ミーティングは2部構成となる。 それぞれ半分ずつのタイムボックスを使い、次の質問に答える。 * スプリントの成果であるインクリメントに何を入れるか？ * インクリメントを届けるためにどのように作業をするか？ #### 第1部：スプリントで何をするか？ 第1部では、開発チームがスプリントで開発する機能を計画する。プロダクトオーナーが順番の付けられたプロダクトバックログを開発チームに渡し、スクラムチーム全体で協力して、スプリントの作業を理解する。 入力は、プロダクトバックログ・最新のプロダクトインクリメント・開発チームがスプリントで発揮する作業能力の予測・開発チームの過去の実績である。プロダクトバックログから選択する項目数については、開発チームが責任を持つ。次のスプリントで何を達成するかを評価できるのは、開発チームだけである。 次に、スクラムチームでスプリントゴールを作る。スプリントゴールは、プロダクトバックログを実装して達成するスプリントの目標であり、開発チームにとっては、なぜそのインクリメントを開発するのかという指針になる。 #### 第2部：選択した項目をどのように完了するか？ スプリントの作業を選択したら、その機能を「完了」プロダクトインクリメントにする方法を開発チームが決定する。スプリントで作業を行うプロダクトバックログの項目と、それを届ける計画を合わせて、スプリントバックログと呼ぶ。 開発チームは、プロダクトバックログを動くプロダクトインクリメントにするシステムや作業の設計から始めることが多い。作業の規模や見積もり工数はさまざまだが、スプリント計画ミーティングでは、開発チームがスプリントで達成できると予測できる作業を計画する。スプリントの最初の数日間で開発チームが行う作業は、このミーティングで1日以下の単位に分解される。スプリント計画ミーティングでは、開発チームが自己組織化してスプリントバックログの作業を受け持つ。必要であればスプリントの最中にも行う。 第2部にプロダクトオーナーが参加して、選択された項目を明確にしたりトレードオフを助けたりすることもできる。作業が多すぎたり少なすぎたりした場合は、開発チームとプロダクトオーナーが、スプリントバックログの項目について話し合う。開発チームは、技術やドメインについて助言してくれる人たちを招待することもある。 開発チームは、スプリントゴールを達成し、期待されたインクリメントを作成するために、自己組織化チームとしてどのように作業を行うのかを、プロダクトオーナーとスクラムマスターに対してスプリント計画ミーティングの終了までに説明できるようにしておかなければならない。 #### スプリントゴール スプリントゴールによって、スプリントで実装する機能に柔軟性が出てくる。 開発チームが作業をするときは、このスプリントゴールを心に留めておく。スプリントゴールを達成するには、機能と技術を満たさなければならない。開発チームの予想が外れた場合は、プロダクトオーナーに相談して、スプリントバックログのスコープを調整する。 スプリントゴールは、大きなプロダクトロードマップのマイルストーンになることもある。 ### デイリースクラム デイリースクラムは、開発チームが活動の状況を確認し、次の24時間の計画を作る15分のタイムボックスである。前回のデイリースクラムから行った作業の点検と、次回のデイリースクラムまでに行う作業の予測を行う。 デイリースクラムは、複雑にならないように、毎日、同じ時間・場所で開催する。デイリースクラムでは、開発チームメンバが次のことを説明する。 * 前回のデイリースクラムから行ったこと * 次回のデイリースクラムまでに行うこと * 問題点 開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの作業の進捗を評価する。デイリースクラムによって、開発チームはスプリントゴールを達成する可能性を最適化できる。デイリースクラムが終わったら開発チームはすぐに集まって、スプリントの残作業を再計画する。開発チームは、スプリントゴールを達成し、期待されたインクリメントを作成するために、スプリントの残り時間で自己組織化チームとしてどのように作業を行うのかを、プロダクトオーナーとスクラムマスターに毎日説明できるようにしておかなければならない。 スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任があるのは、開発チームである。スクラムマスターは、開発チームにデイリースクラムを15分以内に終わらせるように伝える。 スクラムマスターは、デイリースクラムに参加できるのは開発チームのメンバだけというルールを設定する。デイリースクラムは上司への進捗報告会ではない。プロダクトバックログの項目をインクリメントに変える人たちのものである。 デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害を特定・排除し、迅速な意思決定を助長して、開発チームのプロジェクト知識のレベルを向上させるものである。これは、重要な検査と適応のミーティングである。 ### スプリントレビュー スプリントレビューは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームと関係者がスプリントの作業をレビューする。レビュー結果とプロダクトバックログの変更をもとにして、次にできることを議論する。これは非公式なミーティングであり、インクリメントを提示することで、フィードバックとさらなる協力を引き出すことができる。 スプリントが1か月の場合、スプリントレビューのタイムボックスは4時間である。スプリントの期間が短ければ、その長さに比例して時間が短くなる。たとえば、スプリントが2週間の場合、スプリントレビューは2時間になる。 スプリントレビューには、次の要素が含まれる。 * プロダクトオーナーは、「完了」したものと「完了」していないものを特定する。 * 開発チームは、スプリントでうまくいったこと・直面した問題点・それをどのように解決したかを議論する。 * 開発チームは、「完了」したものをデモして、インクリメントに対する質問に答える。 * プロダクトオーナーは、現在のプロダクトバックログについて議論する。現在の進捗から完了日を予測する。 * グループ全体で次に何をするかを議論し、価値のある入力を次のスプリント計画ミーティングに提供する。 スプリントレビューの成果は、次のスプリントで選択する可能性のある項目を定義した改訂版のプロダクトバックログである。また、新しい状況に合わせて、プロダクトバックログ全体を調整することもある。 ### スプリントレトロスペクティブ スプリントレトロスペクティブは、スクラムチームの検査とスプリントの改善計画を作成する機会である。 スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリント計画ミーティングが始まる前に行う。スプリントが1か月の場合、スプリントレトロスペクティブのタイムボックスは4時間である。スプリントの期間が短ければ、その長さに比例して時間が短くなる。 スプリントレトロスペクティブには、次の目的がある。 * 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。 * うまくいった項目や今後の改善点を特定・整理する。 * スクラムチームの改善実施計画を作成する。 スクラムマスターは、スクラムプロセスフレームワークの開発プロセスやプラクティスをより効果的にして、次のスプリントで楽しめるように、スクラムチームに改善を促す。スクラムチームは、「完了」の定義を適切に調整して、プロダクトの品質を向上させる方法を計画する。 スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければならない。これらの改善策は、開発チームの検査に適応したものだ。改善はいつでも実施できるが、スプリントレトロスペクティブは検査と適応のための公式な機会である。 ## スクラムの成果物 スクラムの成果物は、さまざまな形で作業や価値を表したものであり、透明性や検査・適応の機会に役に立つものである。スクラムで定義された成果物は、スクラムチームが「完了」インクリメントを確実に届けるために必要な情報の透明性を最大化できるように設計されている。 ### プロダクトバックログ プロダクトバックログは、プロダクトに必要なものがすべて順序付きで一覧になったものであり、プロダクトの変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・順序に責任を持つ。 プロダクトバックログは決して完成しない。開発の初期段階には、最初から明確でよく理解できた要求が並べられている。プロダクトバックログは、プロダクトや使用環境に合わせて変化するのである。プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて、絶えず変化する。プロダクトが存在する限り、プロダクトバックログは不滅である。 プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。プロダクトバックログの項目には、詳細・並び順・見積もりの属性が設けられている。 プロダクトバックログは、価値・リスク・優先度・必要性などで並べられている。1番上の項目から開発を開始する。順番が上の項目ほどよく考えられており、その項目や価値について合意がとれたものである。 順番が上の項目ほど明確で詳細である。明確で詳細であれば、見積もりも正確になる。順番が下の項目ほど不正確で詳細ではない。次のスプリントで開発チームが従事するプロダクトバックログの項目は、スプリントで「完了」できるようにうまく細分化されている。スプリントで開発チームが「完了」にできる項目は、「準備完了（ready）」や「着手可能（actionable）」と呼ばれ、スプリント計画ミーティングで選択できる。 プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログは巨大で包括的な一覧になっていく。要求の変更は止まらない。プロダクトバックログは生きた成果物である。ビジネス要求・市場の状態・技術の変化が、プロダクトバックログの変化につながる。 同じプロダクトで複数のスクラムチームが作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述される。また、項目をグループにまとめる属性が追加される。 プロダクトバックログの項目に詳細の追加・見積もり・並び替えを行うことを、プロダクトバックログの手入れと呼ぶ。これは、プロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログの手入れによって、項目のレビューと改訂が行われる。ただし、プロダクトオーナーによって、項目が更新される可能性もある。 プロダクトバックログの手入れは、プロダクトオーナーと開発チームが、スプリントの一環として行う活動である。開発チームは、手入れをするためのドメイン知識を持っている。いつどのように手入れをするかは、スクラムチームが決定する。手入れには、開発チームの作業の10%程度を消費する。 開発チームは見積もりに対して責任を持つ。トレードオフの理解や選択を手伝うなど、プロダクトオーナーが開発チームに影響を及ぼすこともあるが、最終的な見積もりは実際に作業をする人が行う。 #### ゴールへの進捗を監視する いずれかの時点で目標に対する残作業を合計する。プロダクトオーナーは、少なくともスプリントレビューにおいて、この合計残作業を追跡する。プロダクトオーナーは、前回のスプリントレビューの合計残作業と比較して、希望する時間までにゴールに到達するかどうかを評価する。この情報は関係者全員に明らかにされる。 進捗の見通しを立てるために、バーンダウンやバーンアップなどのさまざまなプラクティスが使用されてきた。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに起きたものだけが、これから先の意思決定に使用できる。 ### スプリントバックログ スプリントバックログは、プロダクトバックログから選択した項目と、その項目をプロダクトインクリメントにして届け、スプリントゴールを達成する計画とを合わせたものである。スプリントバックログは、開発チームが作成するインクリメントに含まれる機能と、その機能を届けるために必要な作業を表した予測である。 スプリントバックログは、開発チームがプロダクトバックログの項目を「完了」インクリメントに変える作業を定義している。スプリントバックログは、開発チームがスプリントゴールを達成するのに必要な作業をすべて見える化している。 スプリントバックログは、デイリースクラムで変更点が共有できる程度に詳細な計画である。スプリントでは、開発チームがスプリントバックログを修正し、スプリントバックログが明確化されていく。これは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。 新しい作業が必要になれば、開発チームがスプリントバックログに追加する。作業が完了すれば、残作業の見積もりを更新する。計画が不要になれば、削除する。スプリントでスプリントバックログを削除できるのは、開発チームだけである。スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映されている。スプリントバックログは開発チームのものである。 #### スプリントの進捗を監視する スプリントのいずれかの時点で、スプリントバックログの項目の残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この合計残作業を追跡する。日次で追跡することで、スプリントゴールの達成に見通しを立てる。スプリントの残作業の追跡をすることで、開発チームは進捗を管理できる。 スクラムでは、スプリントバックログに費やした作業時間を考慮しない。参考にするのは、残作業や日付といった数値だけである。 ### インクリメント インクリメントは、これまでのスプリントで完了したプロダクトバックログの項目をまとめたものである。スプリントの終わりには、新しいインクリメントが「完了」しなければならない。これは、インクリメントが動く状態であり、スクラムチームの「完了」の定義に合っていることを意味する。プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動く状態になければならない。 ## 「完了」の定義 プロダクトバックログの項目やインクリメントが「完了」したならば、全員が「完了」の意味を理解していなければならない。スクラムチームによってその意味は大きく異なるが、透明性を確保するためにも、作業の完了について共通の理解がなければならない。これは、スクラムチームの『「完了」の定義』と呼ばれ、プロダクトインクリメントの作業完了の評価に使われる。 この定義は、スプリント計画ミーティングでプロダクトバックログの項目を開発チームがいくつ選択するかの指針にもなる。スプリントの目的は、スクラムチームの「完了」の定義に沿ったリリース判断可能な機能のインクリメントを届けることである。 開発チームは、スプリントごとにプロダクトのインクリメントを届ける。インクリメントは実際に動くものなので、プロダクトオーナーはすぐにリリースできる。インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分にテストされたものである。 成熟したスクラムチームでは、「完了」の定義にさらに厳しい品質条件を追加することもある。 ## 結論 スクラムは、本ガイドが無料で提供されている。スクラムの役割・成果物・イベント・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。 ## 謝辞 ### 人々 スクラムに貢献してくれた非常に多くの人たちのなかでも、最初の10年間に貢献してくれた人の名前を挙げたい。まず、Jeff SutherlandとJeff McKenna。それから、Ken SchwaberとMike SmithとChris Martin。翌年からは、その他にも多くの人たちが貢献してくれた。彼らの助けがなければ、スクラムは今日のように洗練されてはいなかっただろう。David Starrは、見事な見識と編集能力をこのスクラムガイドに提供してくれた。 ### 歴史 Ken SchwaberとJeff Sutherlandが、1995年のOOPSLAカンファレンスでスクラムを共同発表した。この発表は、KenとJeffがスクラムを数年間適用した経験から学んだことを文書化したものである。 スクラムの歴史は長い。最初の試行錯誤の場であるIndividual, Inc.・Fidelity Investments・IDX（現 GE Medical）に感謝したい。 ### 翻訳 本ガイドは、Ken SchwaberとJeff Sutherlandによる英語版の翻訳である。日本語訳は、角征典（@kdmsnr） が担当した。翻訳のレビューには、@irohiroki、@takaesu0、@miholovesq、@sunaot、@kawagutiが参加してくれた。 # スクラムガイド2010 ## 謝辞 ### 全般 スクラムは産業界で受け入れられたベストプラクティスに基づいている。それらは数十年かけて使用さ れ、実証されてきたものだ。後に、経験プロセス理論の一部となっている。ある時、Jim Coplienが Jeff Sutherlandに言った。「みんなスクラムが好きになるよ。追い詰められた時にいつもやってるこ となんだから」 ### 人々 スクラムに貢献してくれた非常に多くの人たちのなかでも、最初の10年間に貢献してくれた人をまず挙 げよう。まず、Jeff Sutherland と Jeff McKenna。それから、Ken Schwaber と Mike Smith と Chris Martin。スクラムは、公式には OOPSLA 1995 で発表された。次の5年間では、Mike Beadle と Martine Devos が大きく貢献してくれた。それから、みなさん。みなさんの助けがなければ、今のように洗練されたスクラムは存在しなかった。 ### 歴史 スクラムの歴史は、ソフトウェア開発の世界だと、すでに長い部類に入っていることだろう。まずお礼を述べたいのは、最初の試行錯誤の場である。Individual, Inc.、Fidelity Investments、IDX(現 GE Medical)に感謝したい。 ## 翻訳 本ガイドは、Ken Schwaber と Jeff Sutherland による英語版の翻訳である。日本語訳は 角 征典 <> が担当している。翻訳のレビューには、@takaesu0、@sunaot、 @kawaguti が参加してくれた。 ## 目的 スクラムは1990年代初頭から複雑なプロダクトの開発に使用されてきた。本稿では、スクラムをプロダクト開発に使用する方法を説明する。ただし、スクラムはプロセスや技術ではない。正しくは、様々なプロセスや技術を取り込むことのできるフレームワークである。スクラムの役割は、**複雑なプロダク開発が可能なフレームワークを提供する**ことで、開発プラクティスの効果を相対的に浮き彫りにし、改善することである。 ## スクラムの理論 スクラムは「経験的プロセス制御」の理論を根拠としており、反復的で漸進的な手法を用いて、予測可能性を最適化し、リスクをコントロールする。経験的プロセス制御の実現は、3本の脚に支えられている。 ### 1つ目の脚は透明性 透明性とは、成果に影響するプロセスの様子が、成果を管理する人の目に見えることを保証することである。また、目に見えるものは知られていなければならない。つまり、物事の完了とプロセスを検査する人が考える完了の定義は等しくなければならない。 ### 2つ目の脚は検査 プロセスの様子は、受け入れ難い変化をすぐ検知できるように、頻繁に検査しておかなければならない。ただし、検査によってプロセス自体が変更されてしまうことを考慮に入れておくこと。必要となる検査の頻度がプロセスの許容を超えてしまってはいけない。幸いなことに、これはソフトウェア開発には当てはまらないようだ。プロセスに影響を与える要因としては、他にも、作業の成果を検査する人の技術や勤勉さなどがある。 ### 3つ目の脚は適応 検査結果を見て、プロセスに不備があり、成果となるプロダクトを受け入れられないと判断した場合、検査する人はプロセスまたは成果物を調整しなければならない。調整はできるだけ早く行い、これ以上の逸脱は防がなければならない。 スクラムには検査と適応を行う場所が3つある。まず、デイリースクラムミーティングである。スプリントゴールに対する進捗を検査し、次の作業日の価値を最適化するように適応する。次に、スプリントレビューとスプリント計画ミーティングである。リリースゴールの進捗を検査し、次のスプリントの価値を最適化するように適応する。最後に、スプリントレトロスペクティブである。終了したスプリントを検査し、次のスプリントをより生産的に、充実した、楽しいものにする適応方法を決める。 ## スクラムの内容 スクラムフレームワークは、**スクラムチーム**とその役割、**タイムボックス**、**成果物**、および**ルール**で構 成される。 スクラムチームは、柔軟性と生産性の最適化を目指すものである。チームは、自己組織化しており、ク ロスファンクショナルであり、反復的に作業をする。スクラムチームには3つの役割がある。(1)**スクラムマスター**(チームがプロセスを理解し、追従することに責任を負う)、(2)**プロダクトオー ナー**(スクラムチームの作業の価値を最大にすることに責任を負う)、(3)**チーム**(作業をする)。チームは、スプリントの終了までに、プロダクトオーナーの要求をリリース判断可能なプロダクトの断片に変えるスキルを持った開発者の集まりである。 スクラムがタイムボックスを採用しているのは、規則的なリズムをつけるためである。タイムボックスには、**リリース計画ミーティング**、**スプリント計画ミーティング**、**スプリント**、**デイリースクラム**、**スプリントレビュー**、**スプリントレトロスペクティブ**が含まれる。スクラムの中心は**スプリント**である。 スプリントとは、1ヶ月またはそれ以下のイテレーションで、一連の開発作業が継続する長さとなっている。すべてのスプリントで同じスクラムフレームワークを使用し、リリース判断可能な最終プロダクトのインクリメントを納品する。スプリント終了直後に次のスプリントを開始する。 スクラムは4つの主要な成果物を採用している。**プロダクトバックログ**は、プロダクトで必要となる可能性のあるものすべてに優先度をつけた一覧である。**スプリントバックログ**は、スプリントにおいて、プロダクトバックログを出荷判断可能なプロダクトのインクリメントに変えるために必要なタスクの一覧である。バーンダウンは、残ったバックログの項目を時間をかけて計測するためのものである。**リリースバーンダウン**は、リリース計画中に残ったプロダクトバックログの項目を計測するためのものだ。**スプリントバーンダウン**は、スプリント中に残ったスプリントバックログの項目を計測するものだ。 ルールは、スクラムのタイムボックス・役割・成果物を結びつけるものである。ルールについては、本稿の至るところで説明する。例えば、「チームメンバー(プロダクトバックログをインクリメントに変えることにコミットした人たち)だけが、デイリースクラムで話すことができる」などがスクラムのルールである。スクラムを導入するためのルールではなく、こちらからの提案については、「Tip」枠内で述べることにする。 ## スクラムに登場する役割 スクラムチームは、スクラムマスター、プロダクトオーナー、およびチームで構成される。スクラムチームのメンバーは「豚」と呼ばれる。 プロダクトオーナーはプロダクトバックログの「豚」である。チームはスプリント作業の 「豚」である。スクラムマスターはスクラムプ ロセスの「豚」である。その他の人はすべて 「鶏」である。鶏は「豚」に作業のやり方を命 令することはできない。鶏と豚とは、次のよう な物語に由来する。 あるとき鶏と豚が一緒にいた。鶏が「レストランを始めよう!」と言い出した。\ 豚はよく考えてからこう尋ねた。「レストランでは何を出すんだい?」\ 鶏は「ハムエッグだよ!」と答えた。\ 豚は言った。「それはやめておこうかな。私は身を削るのに、君はちょっと関わってるだけじゃない か」 {% hint style="info" %} Tip: ルールが規定していない部分 は、スクラムのユーザーは自ら何を行 うべきかを考えなければならない。問 題というものは頻繁に変更されるもの なので、最初から完全な解を見つけよ うとはしないこと。その代わり、何か を試してみて、その効果を確かめるこ と。検査と適応という仕組みは、経験 的に何かを獲得していくというスクラ ムの特性であり、あなたを導いてくれ ることだろう。 {% endhint %} ### スクラムマスター スクラムマスターは、スクラムチームがスクラムの価値、慣習、およびルールに忠実であるこ とを保証する責任がある。スクラムマスター は、スクラムチームと組織がスクラムを採用す ることを支援する。スクラムマスターは、コーチングやリーディングを使って、スクラムチームがより生産的に、より質の高いプロダクトを 作れるよう指導する。スクラムマスターは、スクラムチームが自己組織とクロスファンクションを理解し、実践することを支援する。スクラムマスターの役割は、スクラムチームにとって のサーバントリーダー(訳注:メンバーが成果 をあげるための支援や奉仕をするリーダーのこと)的な存在であると言える。 {% hint style="info" %} Tip: スクラムマスターは、顧客やマネージャーと一緒にプロダクトオーナーを具体的に特定する。そして、プロダクトオーナーにその役割を伝え る。プロダクトオーナーは、スクラム を使って価値を最適化する方法を知っておかなければならない。知らない場合は、スクラムマスターがプロダクトオーナーに説明する。 {% endhint %} ### プロダクトオーナー プロダクトオーナーは、プロダクトバックログ の管理に責任を持ち、チームの作業の価値を保 証する唯一の人物である。プロダクトオーナー は、プロダクトバックログを維持し、みんなに 確実に見えるようにする。どれが最優先項目な のかを知らせ、何に取り組めばよいのかが分か るようにする。プロダクトオーナーは1人の人 間であり、委員会であってはならない。助言したり影響を与えたりする委員会があってもよい が、項目の優先度を変更したい人はプロダクトオーナーを納得させなければならない。スクラムを導入する会社は、自社のこれまでの優先度付けや要 求の決め方に影響を受けるかもしれない。 {% hint style="info" %} Tip: スクラムマスターは、スプリント のタスクを行う開発者などのチームメンバーが兼任することもある。しか し、障害の除去かタスクの消化かのいずれかを選ばなければならない場合には、矛盾につながる。なお、スクラムマスターはプロダクトオーナーが兼任 してはならない。 {% endhint %} プロダクトオーナーが成功するには、組織のみ んながプロダクトオーナーの決定を尊重しなけ ればならない。優先度を変えて作業をチームに 命じることは他の誰にも認められておらず、 チームにも、異なることを言う人の意見を聞く ことは許されていない。プロダクトオーナーの 決定は、プロダクトバックログの内容と優先度 で見ることができる。この見える化はプロダクトオーナーの努力にかかっており、そのためプ ロダクトオーナーの役割は困難だが、やり甲斐のあるものとなっている。 {% hint style="info" %} Tip: 商用開発の場合、プロダクトオーナーはプロダクトマネージャーに なるだろう。社内開発の場合は、自動的にビジネス組織のマネージャーにな るだろう。 {% endhint %} ### チーム 開発者の集まりであるチームは、プロダクトバックログをスプリントごとに出荷判断可能な 機能のインクリメントに変える。さらに、チームはクロスファンクショナルである。つまり、 チームメンバーは、インクリメントを作成するのに必要なスキルをすべて持っていなければな らない。チームメンバーは、プログラミング、 品質管理、経営分析、アーキテクチャ、ユー ザーインターフェース設計、あるいはデータベース設計のような特化したスキルを持っている。しかし、チームメンバーが共有するスキル――つま り、要求を見出し、それを利用可能なプロダクトに変える技術――のほうが重要である場合が多い。 アーキテクトや設計者だからとコーディングを断るような人はチームにふさわしくない。新しいスキル を学んだり古いスキルを思い出したりする必要があっても、みんなが力を貸すこと。チーム内に肩書き はない。また、このルールに例外はない。チームには、テストやビジネス分析といったドメインに専念 するサブチームは存在しない。 {% hint style="info" %} Tip: プロダクトオーナーはチームメン バーが担当してもよい。開発業務を 行っても構わない。しかし、責任が増 えることによって、ステークホルダー と作業をするプロダクトオーナーの能 力が下がってしまうかもしれない。な お、プロダクトオーナーはスクラムマスターであってはならない。 {% endhint %} さらに、チームは自己組織である。誰も――スクラムマスターでさえも――プロダクトバックログを出 荷可能な機能のインクリメントに変える方法をチームに伝えることはない。チームは自身でこれを解決 する。個々のチームメンバーはその専門知識をすべての問題に適用する。その結果生じるシナジーに よって、チーム全体の効率と効果が向上する。 チームに最適な規模は、7±2名である。チームメンバーが5名未満の場合、相互作用が少なく、生産性 の上昇が低い。さらに、スプリント中に技術的制約に遭遇したり、リリース可能なプロダクトを納品で きなかったりするかもしれない。チームメンバーが9名を超える場合、単純に調整する量が多くなって しまう。大きなチームは、経験的プロセスを管理するにはあまりにも複雑である。とはいえ、この範囲 に入らない規模のチームが成功した例に我々は何度か遭遇したことがある。プロダクトオーナーとスク ラムマスターは、スプリントバックログの作業に関わる豚でないのであれば、人数には含まない。 スプリントが終了すると、チーム構成が変わることもある。チームメンバーが替わるたびに自己組織に よって獲得した生産性は低下する。チーム構成を変更するときは注意すべきである。 ## タイムボックス スクラムのタイムボックスには、**リリース計画ミーティング**、**スプリント**、**スプリント計画ミーティン グ**、**スプリントレビュー**、**スプリントレトロスペクティブ**、および**デイリースクラム**がある。 ### リリース計画ミーティング リリース計画ミーティングの目的は、スクラムチームや組織全体が、理解した上でコミュニケーション できる計画やゴールを確立することである。リリース計画は「どのようにすれば最良の方法でビジョン を成功プロダクトに変えることができるのか。どのようにすれば求められる顧客満足やROIを満たす (あるいは超える)ことができるのか。」といった疑問に答えるものである。リリース計画では、リ リースゴール、プロダクトバックログの最優先項目、主なリスク、全般的なフィーチャ、およびリリー スに含む機能を決める。さらに、納品予定日、何も変更が発生しなかった場合にかかるコストも決めて おく。組織は進捗を検査して、スプリントごとにリリース計画を変更できる。 スクラムではプロダクトを反復的に構築するため、各スプリントでプロダクトのインクリメントを作成 することになる。このとき、最も価値があり、最もリスクの高いものから着手する。スプリントのたび に、プロダクトのインクリメントが追加される。インクリメントは、プロダクトの出荷判断可能な断片 である。十分にインクリメントを作成し、出資者にとって価値のある役立つものとなったら、プロダク トをリリースする。 ほとんどの組織には、既にリリース計画プロセスが存在するだろう。しかし多くの場合、その計画はリ リースの初期に行い、時間がたっても変更することはない。スクラムリリース計画では、全体のゴールや成果物を定義する。通常、このリリース計画には、従来のリリース計画に費やすわずか15\~20%の 時間しかかからない。ただし、スクラムのリリースは、スプリントレビューやスプリント計画ミーティ ングのたびにジャストインタイムで計画を立てる。さらに、デイリースクラムミーティングでは、毎日 ジャストインタイムで計画を立てる。合計すると、スクラムのリリースへの取り組みは、おそらく伝統 的なリリース計画への取り組みよりも、わずかに手間がかかることになる。 リリース計画では、リリースに向けてプロダクトバックログを見積もり、優先度付けをしなければなら ない。そのために有効なテクニックはスクラム以外にも数多くあり、それらを使うことも有用である。 ### スプリント スプリントは1つのイテレーションである。スプリントはタイムボックスになっている。スクラムマス ターは、スプリント中にスプリントゴールに影響する変更が行われないことを保証する。チーム構成と 品質目標は、どちらもスプリント中は一定である。スプリントは、スプリント計画ミーティング、開発 作業、スプリントレビュー、およびスプリントレトロスペクティブを含んでおり、それらで構成されて いる。スプリントは間隔を置かずに次々と開始する。 プロジェクトとは、何かを達成するために使用するものだ。ソフトウェア開発では、プロダクトまたは システムを構築するために使用する。すべてのプロジェクトは、構築するものの定義、構築する計画、 計画に沿って行う作業、および最終プロダクトで構成される。すべてのプロジェクトには地平線があ る。つまり、計画に適した時間枠である。地平線が遠すぎると、定義が変わったり、様々な変数が入っ てきたり、リスクが大きくなりすぎたりする。スクラムは、最大1ヶ月のプロジェクトのためのフレー ムワークである。これでも十分に複雑であり、これ以上長くなるとリスクが高い。プロジェクトの予測 可能性は、少なくとも月次でコントロールしなければならない。コントロール不能や予測不能のリスク は、少なくとも月次で抑えるようにしなければならない。 スプリントはタイムボックスが終わる前に中止 できる。プロダクトオーナーだけがスプリント を中止する権限を持つ。このとき、ステークホ ルダー、チーム、あるいはスクラムマスターの 意見を聞いてもよい。それでは、スプリントが 中止されるのはどんな状況だろうか?スプリン トゴールが古くなった場合には、マネジメント がスプリントを中止するかもしれない。会社の 方向性が変わったり、市場や技術の状況が変 わったりする場合にも、中止する必要があるか もしれない。一般的に、つじつまが合わない状 況になったら、スプリントを中止したほうがよい。しかし、スプリントの期間は短く、中止したからといってそれほど意味をなすことはない だろう。 {% hint style="info" %} Tip: チームが作業が多すぎることに 気づいたときは、プロダクトオーナー に会って、スプリントに選んだプロダ クトバックログのスコープを削除した り縮小したりしてもらうこと。逆に時 間が余ることに気づいたときは、プロ ダクトオーナーと追加するバックログ を選ぶこと。 {% endhint %} スプリントが中止になったら、プロダクトバッ クログの完成あるいは「完了(done)」した項目をレビューする。出荷判断可能なインクリメントになっていれば、受け入れられるだろう。その他 の項目は、最初の見積もり数値のままプロダクトバックログに戻される。それらにかかった作業は失わ れたものとなる。スプリントの中止は、別のスプリントを開始するためにスプリント計画ミーティング を開かなければならないため、リソースを消費する。スプリントの中止はチームにとってトラウマにな ることが多い。しかし、中止はめったに起きないことである。 {% hint style="info" %} Tip: チームがスクラムを始めるとき は、不確実なことに惑わされない学習 期間を2週間とるとよい。2週間のス プリントであれば、インクリメントを2つ合わせることで、他のチームと同 期をとることもできる。 {% endhint %} ### スプリント計画ミーティング スプリント計画ミーティングでは、イテレーションを計画する。1ヶ月のスプリントの場合、ミーティ ングは8時間のタイムボックスとなる。もっと短いスプリントの場合は、スプリントの長さに比例して 時間を割り当てる(例えば、スプリントが2週間の場合は、スプリント計画ミーティングを4時間にす る)。スプリント計画ミーティングは2部構成である。第1部では、スプリントで何を行うかを決め る。第2部(1月のスプリントだと4時間のタイムボックス)では、決まった機能をプロダクトインクリ メントにどのように組み込むかをチームで考える。 スプリント計画ミーティングは2部構成である:「What?」部と「How?」部だ。なかには、この2つ を一緒に行うスクラムチームもある。最初の部分では、スクラムチームは「What?」の質問に取り組 む。プロダクトオーナーは、プロダクトバックログの最優先項目をチームに提示する。ここで一緒に次 のスプリントで開発する機能を考える。ミーティングへのインプットは、プロダクトバックログ、プロ ダクトの最新インクリメント、チームの許容量、およびチームの過去の実績である。バックログの量は チームの責任で選択する。次のスプリントで遂行できるかどうかを判断できるのはチームだけである。 プロダクトバックログを選択したら、スプリントゴールを丹念に設定する。スプリントゴールはプロダ クトバックログを導入することで満たす目的である。これは、チームがインクリメントを構築する理由 のガイドとなるステートメントである。スプリントゴールはリリースゴールの部分集合である。 スプリントゴールを設定するのは、チームが自由に機能を扱えるようにするためである。例えば、上記 のスプリントのゴールは次のような感じになる:「安全で復元可能なトランザクションミドルウェアを 使って、クライアントアカウントの修正機能を自動化する」チームが作業をする上で、このゴールを覚 えておく。ゴールを満たすために、チームは機能と技術を実装する。予測したよりも作業が困難である と判明した場合、チームはプロダクトオーナーと相談して、一部の機能を実装する。 スプリント計画ミーティングの第2部では、チームは「How?」の質問に取り組む。スプリント計画 ミーティングの第2部(1ヶ月のスプリントだと4時間)でチームは、スプリント計画ミーティング (What)で選択したプロダクトバックログをどのように完了インクリメントに変えるかを考える。通 常、チームは、作業の設計から始める。そして、タスクを見つけ出す。これらのタスクは、プロダクト バックログを動くソフトウェアに変えために必要となる詳細な作業である。タスクは、1日未満で行う ことができるように分解すべきだ。タスク一覧はスプリントバックログと呼ばれる。チームは自己組織 化し、スプリント計画ミーティングまたはスプリント中にジャストインタイムで、スプリントバックロ グの作業を請け持つ。 スプリント計画ミーティングの第2部では、プ ロダクトオーナーはプロダクトバックログを明 確にし、トレードオフを支援する。作業が多す ぎたり少なすぎたりした場合は、チームはプロダクトオーナーと交渉して、プロダクトバック ログを調整する。技術やドメインのアドバイス を求めるために、チームは他の人をミーティン グに招待するかもしれない。新しいチームの場 合、チームとしてうまくやっていけるかどうか は、このミーティングで分かる。チームはチー ムを頼らなければならないことに気づく。これ に気づけば、チームは自己組織を始め、真のチームとしての特性を持ち、そのように振る舞えるように なる。 {% hint style="info" %} Tip: 通常、スプリント計画ミーティングでは、スプリントバックログの 60\~70%しか出てこないだろう。残りはあとで対応する。あるいは、とり あえず大きな見積もりをしておいて、 あとで分解する。 {% endhint %} ### スプリントレビュー スプリントの最後にスプリントレビューを開く。1ヶ月のスプリントの場合、タイムボックスは4時間 となる。もっと短いスプリントの場合は、スプリントの長さに比例して時間を割り当てる(例えば、ス プリントが2週間の場合は、スプリントレビューを2時間にする)。スプリントレビューでは、スクラ ムチームとステークホルダーが、完了した項目について協議する。この結果とスプリント中のプロダク トバックログへの変更に基づいて、次に完了すべきことを協議する。これは非公式のミーティングであ り、機能のプレゼンテーションなどを行って、次に行うことの協働を促進する。 このミーティングには、少なくとも次の要素が含まれている。プロダクトオーナーは、何が完了した か、何が完了しなかったかを識別する。チームは、スプリント中にうまくいったこと、遭遇した問題 点、およびどうやって問題を解決したかを議論する。その後チームは、完了した作業のデモンストレー ションを行い、質問に答える。プロダクトオーナーは、現状のプロダクトバックログについて話し合 う。そして、様々なベロシティを仮定して、有望な完成日を予測する。その後みんなで、これまで見た こと、そしてそれが次に行うべきことにどんな意味があるかを議論する。スプリントレビューは、後の スプリント計画ミーティングにとって価値のあるインプットとなる。 ### スプリントレトロスペクティブ スプリントレビューと次のスプリント計画ミーティングの間に、スクラムチームはスプリントレトロス ペクティブを開く。1ヶ月のスプリントの場合、タイムボックスは3時間となる(スプリントの長さに 比例して時間を割り当てる)。このミーティングでスクラムマスターは、次のスプリントをより有効 で、より愉快にするために、スクラムプロセスフレームワークとプラクティスでチームが開発プロセス を改善するように促す。レトロスペクティブで使用するのに有用な技術が、多くの書籍で述べられてい る。 レトロスペクティブの目的は、先のスプリントを人々、関係、プロセス、ツールの面から検査すること である。検査は、うまくいった主要な項目と、違ったやり方をすればもっと良くなったかもしれない項 目を識別して優先付けをすべきである。ここには、スクラムチームの構成、ミーティング規約、ツー ル、「完了」の定義、コミュニケーションの方法、およびプロダクトバックログの項目を「完了」に変 えるプロセスが含まれる。スプリントレトロスペクティブの終了までに、スクラムチームは、次のスプ リントで導入できる実行可能な改善を特定すべきだ。こうした改善が経験的な検査への適応となる。 ### デイリースクラム チームは、デイリースクラムと呼ばれる15分のステータスミーティングで毎日顔を合わせる。スプリン ト中のデイリースクラムは、同じ時間、同じ場所で開かれる。チームメンバーは次のことを説明する: * 前回のミーティングから今日までに行ったこと * 次回のミーティングまでに行うこと * 何かを行う上で障害となること デイリースクラムは、コミュニケーションを改善し、その他のミーティングを除去し、開発の障害を特 定して排除し、迅速な意志決定を強調して促進し、みんなのプロジェクト知識のレベルを向上するもの である。 スクラムマスターは、チームが確実にミーティングを開くようにする。チームは、デイリースクラムを 行うことに責任を負う。スクラムマスターは「簡潔に話す」というルールを実施し、デイリースクラム が短くなるようにチームに伝える。さらにスクラムマスターは、「デイリースクラムでは、鶏は話すこ とを許されない。どのような方法でも口出しは許されない」というルールも実施する。 デイリースクラムは進捗報告会議ではない。プロダクトバックログの項目をインクリメントに変える人 々(すなわちチーム)以外のためのものではないのだ。チームは、スプリントゴールとプロダクトバッ クログの項目にコミットする。デイリースクラムは、スプリントゴールに向けた進捗の検査である(3 つの質問)。通常、スプリントで行う作業に適応するためのミーティングをこの次に開く。チームが ゴールを達成する見込みを最適化するためである。これが、スクラムの経験的プロセスにおけるカギと なる検査と適応のミーティングである。 ## スクラムの成果物 スクラムの成果物は、プロダクトバックログ、リリースバーンダウン、スプリントバックログ、および スプリントバーンダウンである。 ### プロダクトバックログとリリースバーンダウン チームが開発しているプロダクトへの要求はプロダクトバックログに一覧されている。プロダクトオー ナーは、プロダクトバックログ、その内容、利用可能性、および優先度に責任を負う。プロダクトバッ クログは永遠に完成しない。最初に着手するときは、よく知られて、よく理解されている要求だけが並 べられている。プロダクトバックログは、プロダクトや環境に合わせて進化する。プロダクトが適切 で、競争力のある、有用なものになるには何が必要かを特定するために、バックログは絶えず変化しな ければならない動的なものである。プロダクトが存在する限り、プロダクトバックログも存在する。 プロダクトバックログには、成功するプロダクトを開発し、ローンチするために必要なものすべてが表 されている。すべてのフィーチャ、機能、技術、要望、およびバグフィックスなど、将来のリリースで プロダクトに加えられる変更の一覧となっている。プロダクトバックログの項目には、詳細、優先度、 見積もりの属性がある。優先度は、リスク、価値、および必要性を考慮して決定する。こうした属性を 算定するための技術が数多くある。 プロダクトバックログは優先度でソートする。 優先度の高いプロダクトバックログはすぐ開発 に入ることができる。優先度が高いほど、緊急 度が高いほど、より考えられたものほど、より 多くの同意が得られたものほど、価値があると 判断する。優先度の高いバックログには、優先 度の低いバックログよりも明確で、情報の記述 が多い。より良い見積もりとは、明確さと情報 の多さで決められる。項目の記述ができるよう になるまで、優先度は低く、情報は少ないままである。 プロダクトが使用され、価値が増加し、市場がフィードバックを提供するようになると、プロダクト バックログは大きくて網羅的な一覧に変わる。要求の変化はとどまることを知らない。プロダクトバッ クログは生きたドキュメントなのだ。ビジネス要求、市場、技術、および人材の変化は、プロダクト バックログの変化を引き起こす。手戻りを最小化するには、最優先項目だけを記述しなければならな い。次のスプリントでチームが携わるプロダクトバックログの項目は、スプリント期間内に完了するよ う分解されており、程よい粒度になっている。 複数のスクラムチームが同じプロダクトに取り 組むことがよくある。この場合も、1つのプロ ダクトバックログで、これから手がけるプロダ クトの作業を記述する。このとき、プロダクト バックログの項目をグループ化する属性を採用 する。グループ化には、フィーチャセット、技 術、あるいはアーキテクチャを使い、スクラム チームの作業を整理する。 リリースバーンダウンは、プロダクトバックロ グの残工数の合計を、時間軸でグラフ化したも のである。工数の単位は、チームや組織が決定 した作業の単位になる。時間軸の単位は、通常 はスプリントになる。 プロダクトバックログの項目の見積もりは、最 初はリリース計画で算出し、あとで作りながら 算出していく。プロダクトバックログの調整で は、それをレビューし、改訂する。ただし、変 更はいつでも行うことができる。チームは、す べての見積もりに責任を負っている。理解やト レードオフを助けることで、プロダクトオー ナーがチームに影響を及ぼすことがあるかもし れない。しかし、最終的な見積もりはチームが 行う。プロダクトオーナーは、常に更新される プロダクトバックログやリリースバックロクグバーンダウンを最新状態で維持管理しておかねばならない。トレンド線については、残作業に基づいて 引くことができる。 {% hint style="info" %} Tip: 通常、プロダクトバックログの 項目は、ユーザーストーリーで記述す る。ユースケースの使用も適切だが、 それは生命に関するソフトウェアや基 幹ソフトウェアに使用するとよい。 {% endhint %} {% hint style="info" %} Tip: 通常、スクラムチームは、スプ リントの10%の時間を使ってプロダ クトバックログを上記の定義に合うよ うに調整する。程よい粒度になった ら、プロダクトバックログの最上位に ある項目(優先度が最も高く、価値が 最も高い項目)を、1つのスプリント に入るように分解する。この調整プロ セスで、項目を分析し、吟味する。ス プリント計画ミーティングでは、これ らの最優先項目は十分に理解されてお り、簡単に選ぶことができる。 {% endhint %} {% hint style="info" %} Tip: 受入テストもプロダクトバックロ グの項目の属性としてよく使用する。 これは、プロダクトバックログの項目 が完成したときに行わなければならな いテスト可能な詳細なテキスト記述で ある。 {% endhint %} ### スプリントバックログとスプリ ントバーンダウン スプリントバックログは、プロダクトバックロ グの項目を「完了」インクリメントに変えるた めにチームが行うタスクで構成される。その多 くは、スプリント計画ミーティングで作られ る。これは、スプリントゴールを達成するのに チームが必要と考えた作業のすべてである。ス プリントバックログの項目は分解されていなく てはならない。変化の具合がデイリースクラム で理解できれば、十分に分解できているといえ る。項目にかかる作業時間は、通常は、1日程 度である。 チームは、スプリント中に追加されるスプリン トバックログだけでなく、スプリントバックロ グ全体に対して常に修正を加えていく。個別の タスクに落とし込むなかで、必要なタスクや時 間の多寡に気づくかもしれない。新しい作業が 必要になったら、チームはスプリントバックロ グに作業を加える。タスクの着手時や完了時に は、タスクの見積り残作業を更新する。タスク が不必要であれば削除する。スプリント中にス プリントバックログを変更することができるのはチームだけである。内容や見積もりを変更することが できるのもチームだけである。スプリントバックログは、よく目立つところに置かれ、スプリント中に チームが遂行する作業をリアルタイムに反映したものであり、チームが占有するものである。 スプリントバックログバーンダウンは、スプリントバックログの残作業の量を時間軸で表したグラフで ある。このグラフを作成するには、バックログの見積もりを毎日合計して、残作業を算出しなければな らない。スプリントの残作業は、スプリントバックログに残された作業の合計である。この合計値を毎 日追跡して、残作業を示すグラフを作る。グラフ上の点を線で結ぶことで、チームはスプリントの進捗 を管理することができる。スクラムでは、期間は考慮しない。残作業と日付だけが対象となる変数であ る。 スプリントの目的に関係するスクラムのルール がある。それは、出荷判断可能な機能のインク リメントを納品するために、「完了」の定義を 作ることである。 {% hint style="info" %} Tip: 組織によっては、完了するより も多くの作業がバックログに加えられ ることもある。このときのトレンド線 は、水平か、あるいは上方へ傾斜する ことになる。これを補い、かつ透明性 を確保するには、作業の増減に応じ て、新しい下限を設けるとよい。下限 は、変更が著しいときにだけ手を加え るようにし、十分にドキュメント化し ておくようにする。 {% endhint %} {% hint style="info" %} Tip: 初めて一緒になるチームだった り、プロダクトをよく知らなかった り、基盤技術をあまり理解していな かったりすると、リリース初期の2\~3 スプリントのトレンド線については、 信頼度が低いかもしれない。 {% endhint %} {% hint style="info" %} Tip: バーンダウンチャートは、可能な 限り、大きな模造紙に手書きで描い て、チームの作業場所に貼り出しておくこと。Excelなどのツールよりも大 きく目につくチャートのほうが、チー ムが目にする可能性が高い。 {% endhint %} ## 完了 スクラムでは、チームはすべてのスプリントでプロダクト機能のインクリメントを作らなけれ ばならない。このインクリメントは出荷判断可 能なものでなければならず、プロダクトオーナーが直ちに導入を決定できるものでなければならない。 そのためには、インクリメントはプロダクトの完全な断片でなければならない。そして、それが「完 了」していなければならない。インクリメントは、先行するすべてのインクリメントに付加するもので あり、十分にテストされたものであり、すべてが一緒に動くものでなければならない。 機能が完了しているというのは、プロダクト開発の場合、少なくともコードがクリーンで、リファクタ リングされていて、ユニットテストが通り、実装が終わり、受入テストが通ったものだと考えるかもし れない。あるいは、実装が終わっただけのものだと考える人がいるかもしれない。「完了」の定義が分 からないと、経験的プロセス制御の2本の脚が機能しない。誰かが「完了」について説明すれば、みん なが「完了」の意味を理解するはずだ。 完了とは、チームがスプリントでプロダクトバックログの項目を「作業中(doing)」にするときの意 味を定義するものである。ドキュメントが含まないプロダクトでは、「完了」の定義にドキュメントが 含まれていない。完全な「完了」インクリメントでは、すべてのプロダクトバックログの項目に対し て、分析、設計、リファクタリング、プログラミング、ドキュメント、およびテストが行われる。テス トには、ユニットテスト、システムテスト、ユーザーテスト、回帰テスト、それから、パフォーマンス テスト、スケーラビリティテスト、セキュリティテスト、統合テストなどのような非機能テストも含ま れる。完了には国際化も含まれる。なかには完了の定義をすべて満たせないチームもある。そのとき は、プロダクトオーナーに説明しなければならない。残作業については、プロダクトを導入する前に完 了しなければならないだろう。 ## まとめ 1つのスプリントで完全なインクリメントを構 築することができない組織もある。それは、自 動テストのインフラがなくてテストを終了でき ないからかもしれない。その場合、インクリメ ントに2つのカテゴリーを作成する。「完了」 作業と「未完了」作業である。「未完了」作業 は、インクリメントの一部であり、あとで完了 しなければならない。プロダクトオーナーは、 スプリントの終了時に検査するものを正確に 知っている。プロダクトオーナーは「完了」の 定義を理解しており、インクリメントがその定義に合っているかを確かめればよい。「未完了」作業 は、「未完了作業」という名でプロダクトバックログの項目に追加する。リリースバーンダウンのグラ フに正しく反映するためである。これによって、リリースへの進捗の透明性を確保できる。スプリント レビューでの検査と適応は、この透明性と同じくらい正確なものである。 {% hint style="info" %} Tip: 「未完了(Undone)」作業は、 「未完了作業(Undone Work)」あ るいは「実施検討作業 (Implementation Work)」と呼ば れるプロダクトバックログの項目に蓄 積する。こうした作業を蓄積しておく と、プロダクトバックログのバーンダ ウンがきちんと停滞するようになる。 {% endhint %} 例えば、チームがプロダクトバックログの項目に、パフォーマンステスト、回帰テスト、スタビリティ テスト、セキュリティテスト、および結合テストを行うことができなければ、分析、設計、リファクタ リング、プログラミング、ドキュメンテーション、ユニットテスト、およびユーザーテストが完了した 作業との比率を計算できる。では、仮に「完了」作業が6個、「未完了」作業が4個の割合だとしよ う。プロダクトバックログの項目を6個終了したら(チームは「やり方」を知っている前提で見積もっ ている)、その時点で4個の「未完了」プロダクトバックログの項目を追加する。 スプリントを重ねるごとに、各インクリメントの「未完了」作業は蓄積されるため、プロダクトのリ リース直前にこれらの残作業に取り組まなければならない。残作業は、組織の特性に左右されるため指 数関数になることもあるが、基本的には直線的に蓄積される。こうした「未完了」作業を消化するため のリリーススプリントをリリース直前に追加する。スプリントの数は、「未完了」作業の蓄積が線形で なければ、予測不能である。 # スクラムガイド2009 2009年5月 著：Ken Schwaber、訳：角征典 ## スクラム入門 スクラムは1990年代初頭から複雑なプロダクトの開発に使用されてきた。本稿では、スクラムをプロダクト開発に使用する方法を説明する。ただし、スクラムはプロセスや技術ではない。正しくは、様々なプロセスや技術を取り込むことのできるフレームワークである。スクラムの役割は、**複雑なプロダクト開発が可能なフレームワークを提供することで**、開発プラクティスの効果を相対的に浮き彫りにし、改善することである。 ## スクラムの理論 スクラムは「経験的プロセス制御」の理論を根拠としており、反復的で漸進的な手法を用いて、予測可能性を最適化し、リスクをコントロールする。経験的プロセス制御の実現は、3本の脚に支えられている。 ### 1つ目の脚は透明性 透明性とは、成果に影響するプロセスの様子が、成果を管理する人の目に見えることを保証することである。また、目に見えるものは知られていなければならない。つまり、物事の完了と、プロセスを検査する人が考える完了の定義は等しくなければならない。 ### 2つ目の脚は検査 プロセスの様子は、受け入れ難い変化をすぐ検知できるように、頻繁に検査しておかなければならない。ただし、検査によってプロセス自体が変更されてしまうことを考慮に入れておかなければならない。必要とする検査の頻度がプロセスの許容を超えてしまってはいけない。幸いなことに、これはソフトウェア開発には当てはまらないようだ。他にも、プロセスに影響を与える要因としては、作業の成果を検査する人の技術や勤勉さなどがある。 ### 3つ目の脚は適応 検査結果を見て、プロセスに不備があり、成果となるプロダクトを受け入れられないと判断した場合、検査人はプロセスまたは成果物を調整しなければならない。調整はできるだけ早く行い、これ以上の逸脱は防がなければならない。 スクラムには検査と適応を行う場所が3つある。まず、デイリースクラムミーティングである。スプリントゴールに対する進捗を検査し、次の作業日の価値を最適化するように適応する。次に、スプリントレビューとスプリント計画ミーティングである。リリースゴールの進捗を検査し、次のスプリントの価値を最適化するように適応する。最後に、スプリントレトロスペクティブである。終了したスプリントを検査し、次のスプリントをより生産的に、充実した、楽しいものにする適応方法を決める。 ## スクラムの内容 スクラムフレームワークは、**スクラムチーム**とその役割、**タイムボックス**、**成果物**、および**ルール**で構成される。 スクラムチームは、柔軟性と生産性の最適化を目指すものである。チームは、自己組織化しており、クロスファンクショナルであり、反復的に作業をする。スクラムチームには3つの役割がある。（1）**スクラムマスター**（チームがプロセスを理解し、追従することに責任を負う）、（2）**プロダクトオーナー**（スクラムチームの作業の価値を最大にすることに責任を負う）、（3）**チーム**（作業をする）。チームは、スプリントの終了までに、プロダクトオーナーの要求をリリース判断可能なプロダクトの断片に変えるスキルを持った開発者の集まりである。 スクラムがタイムボックスを採用しているのは、規則的なリズムをつけるためである。タイムボックスには、**リリース計画ミーティング**、**スプリント計画ミーティング**、**スプリント**、**デイリースクラム**、**スプリントレビュー**、**スプリントレトロスペクティブ**が含まれる。スクラムの中心は**スプリント**である。スプリントとは、1ヶ月またはそれ以下のイテレーションで、一連の開発作業が継続する長さとなっている。すべてのスプリントで同じスクラムフレームワークを使用し、リリース判断可能な最終プロダクトのインクリメントを納品する。スプリント終了直後に次のスプリントを開始する。 スクラムは4つの主要な成果物を採用している。**プロダクトバックログ**は、プロダクトで必要となる可能性のあるものすべてに優先度をつけた一覧である。**スプリントバックログ**は、スプリントにおいて、プロダクトバックログを出荷判断可能なプロダクトのインクリメントに変えるために必要となるタスクに優先度をつけた一覧である。バーンダウンは、時間をかけて残ったバックログの項目を計測するためのものである。**リリースバーンダウン**は、リリース計画中に残ったプロダクトバックログの項目を計測するためのものだ。**スプリントバーンダウン**は、スプリント中に残ったスプリントバックログの項目を計測するものだ。 **ルール**は、スクラムのタイムボックス、役割、および成果物を結びつけるものである。ルールについては、本稿の至るところで説明する。例えば、「チームメンバー（プロダクトバックログをインクリメントに変えることコミットした人たち）だけが、デイリースクラムで話すことができる」などがスクラムのルールである。スクラムを導入するためのルールではなく、こちらからの提案については、「Tip」枠内で述べることにする。 {% hint style="info" %} Tip: ルールが設定されない場合は、スクラムのユーザーは自ら何を行うべきかを考えなければならない。問題は頻繁に変更されるので、最初から完全な解を見つけようとはしないこと。その代わり、何かを試してみて、その効果を確かめること。検査と適応という仕組みは、経験的に何かを獲得していくというスクラムの特性であり、あなたを導いてくれることだろう。 {% endhint %} ## スクラムに登場する役割 スクラムチームは、**スクラムマスター**、**プロダクトオーナー**、および**チーム**で構成される。スクラムチームのメンバーは「豚」と呼ばれる。その他の人はすべて「鶏」である。鶏は「豚」に作業のやり方を命令することはできない。鶏と豚とは、次のような物語に由来する。 * あるとき鶏と豚が一緒にいた。鶏が「レストランを始めよう！」と言い出した。 * 豚はよく考えてからこう尋ねた。「レストランでは何を出すんだい？」 * 鶏は「ハムエッグだよ！」と答えた。 * 豚は「それはやめておこうかな。私は身を削るのに、君はちょっと関わってるだけじゃないか」 {% hint style="info" %} Tip: スクラムマスターは、顧客やマネージャーと一緒にプロダクトオーナーを具体的に特定する。そして、プロダクトオーナーにその役割を教える。プロダクトオーナーは、スクラムを使用する価値を最適化するための管理方法を知っておかなければならない。プロダクトオーナーが知らない場合は、スクラムマスターがその責任を負う。 {% endhint %} ### スクラムマスター スクラムマスターは、スクラムチームがスクラムの価値、慣習、およびルールに忠実であることを保証する責任がある。スクラムマスターは、スクラムチームと組織がスクラムを採用することを支援する。スクラムマスターは、コーチングやリーディングを使って、スクラムチームがより生産的に、より質の高いプロダクトを作れるよう指導する。スクラムマスターは、スクラムチームが自己管理とクロスファンクションを理解し、実践することを支援する。ただし、スクラムマスターがスクラムチームを管理することはない。スクラムチームは自己組織なのである。 {% hint style="info" %} Tip: スクラムマスターは、スプリントのタスクを行う開発者などのチームメンバーが兼任することもある。しかし、障害の除去かタスクの消化かのいずれかを選ばなければならない場合には、矛盾につながる。なお、スクラムマスターはプロダクトオーナーが兼任してはならない。 {% endhint %} ### プロダクトオーナー プロダクトオーナーは、プロダクトバックログの管理と、チームの作業の価値を保証することのできる唯一の人物である。プロダクトオーナーは、プロダクトバックログを維持し、みんなに確実に見えるようにする。どれが最優先項目なのかを知らせ、何に取り組めばよいのかが分かるようにする。プロダクトオーナーは1人の人間であり、委員会であってはならない。助言したり影響を与えたりする委員会があってもよいが、項目の優先度を変更したい人はプロダクトオーナーを納得させなければならない。スクラムを導入する会社は、自社の優先度付けや要求の決め方に影響があるかもしれない。 {% hint style="info" %} Tip: 商用開発の場合、プロダクトオーナーはプロダクトマネージャーになるだろう。社内開発の場合は、自動的にビジネス組織のマネージャーになるだろう。 {% endhint %} プロダクトオーナーが成功するには、組織のみんながプロダクトオーナーの決定を尊重しなければならない。優先度の異なる作業をチームに命じることは他の誰にも認められておらず、チームにも、異なることを言う人の意見を聞くことは許されていない。プロダクトオーナーの決定は、プロダクトバックログの内容と優先度で見ることができる。この見える化はプロダクトオーナーの努力にかかっており、そのためプロダクトオーナーの役割は困難だが、やり甲斐のあるものとなっている。 {% hint style="info" %} Tip: プロダクトオーナーはチームメンバーが担当してもよい。開発業務を行っても構わない。しかし、責任が増えることによって、ステークホルダーと作業をするプロダクトオーナーの能力が下がってしまうかもしれない。なお、プロダクトオーナーはスクラムマスターであってはならない。 {% endhint %} ### チーム 開発者の集まりであるチームは、プロダクトバックログをスプリントごとに出荷判断可能な機能のインクリメントに変える。さらに、チームはクロスファンクショナルである。つまり、チームメンバーは、インクリメントを作成するのに必要なスキルをすべて持っていなければならない。チームメンバーは、プログラミング、品質管理、経営分析、アーキテクチャ、ユーザーインターフェース設計、あるいはデータベース設計のような特化したスキルを持っている。しかし、チームメンバーが共有するスキル――つまり、要求を見出し、それを利用可能なプロダクトに変える技術――のほうが重要である場合が多い。アーキテクトや設計者だからとコーディングを断るような人はチームにふさわしくない。新しいスキルを学んだり古いスキルを思い出したりする必要があっても、みんなが力を貸すこと。チーム内に肩書きはない。また、このルールに例外はない。チームには、テストやビジネス分析といったドメインに専念するサブチームは存在しない。 さらに、チームは自己組織である。誰も――スクラムマスターでさえも――プロダクトバックログを出荷可能な機能のインクリメントに変える方法をチームに伝えることはない。チームは単独でこれを解決する。チームメンバーは専門知識をすべての問題に適用する。その結果生じるシナジーによって、チーム全体の効率と効果が向上する。 チームに最適な規模は、7±2名である。チームメンバーが5名未満の場合、相互作用が少なく、生産性の上昇が低い。さらに、スプリント中に技術的制約に遭遇したり、リリース可能なプロダクトを納品できなかったりするかもしれない。チームメンバーが9名を超える場合、単純に調整する量が多くなってしまう。大きなチームは、経験的プロセスを管理するにはあまりにも複雑である。とはいえ、この範囲に入らない規模のチームが成功した例に我々は何度か遭遇したことがある。プロダクトオーナーとスクラムマスターは、彼らが豚でないのであれば、人数に含まない。 スプリントが終了すると、チーム構成が変わることもある。チームメンバーが替わるたびに自己組織によって獲得した生産性は低下する。チーム構成を変更するときは注意すべきである。 ## タイムボックス スクラムのタイムボックスには、**リリース計画ミーティング**、**スプリント**、**スプリント計画ミーティング**、**スプリントレビュー**、**スプリントレトロスペクティブ**、および**デイリースクラム**がある。 ### リリース計画ミーティング リリース計画ミーティングの目的は、スクラムチームや組織全体が、理解した上でコミュニケーションできる計画やゴールを確立することである。リリース計画は「どのようにすれば最良の方法でビジョンを成功プロダクトに変えることができるのか。どのようにすれば求められる顧客満足やROIを満たす（あるいは超える）ことができるのか。」といった疑問に答えるものである。リリース計画では、リリースゴール、プロダクトバックログの最優先項目、主なリスク、全般的なフィーチャ、およびリリースに含む機能を決める。さらに、納品予定日、何も変更が発生しなかった場合にかかるコストも決めておく。組織は進捗を検査して、スプリントごとにリリース計画を変更できる。 スクラムを使用してプロダクトを反復的に構築するには、スプリントでプロダクトのインクリメントを作成することになる。このとき、最も価値があり、最もリスクの高いものから着手する。スプリントのたびに、プロダクトのインクリメントが追加される。インクリメントは、プロダクトの出荷判断可能な断片である。十分にインクリメントを作成し、出資者にとって価値のある役立つものとなったら、プロダクトをリリースする。 ほとんどの組織には、既にリリース計画プロセスが存在するだろう。しかし多くの場合、その計画はリリースの初期に行い、時間がたっても変更することはない。スクラムリリース計画では、全体のゴールや成果物を定義する。通常、このリリース計画には、従来のリリース計画に費やすわずか15～20%の時間しかかからない。ただし、スクラムのリリースは、スプリントレビューやスプリント計画ミーティングのたびにジャストインタイムで計画を立てる。さらに、デイリースクラムミーティングでは、毎日ジャストインタイムで計画を立てる。合計すると、スクラムのリリースへの取り組みは、おそらく伝統的なリリース計画への取り組みよりも、わずかに手間がかかることになる。 リリース計画では、リリースに向けてプロダクトバックログを見積もり、優先度付けをしなければならない。そのために有効なテクニックはスクラム以外にも数多くあり、それらを使うことも有用である。 ### スプリント スプリントは1つのイテレーションである。スプリントはタイムボックスになっている。スクラムマスターは、スプリント中にスプリントゴールに影響する変更が行われないことを保証する。チーム構成と品質目標は、どちらもスプリント中は一定である。スプリントは、スプリント計画ミーティング、開発作業、スプリントレビュー、およびスプリントレトロスペクティブで含んでおり、それらで構成されている。スプリントは間隔を置かずに次々と開始する。 プロジェクトとは、何かを達成するために使用するものだ。ソフトウェア開発では、プロダクトまたはシステムを構築するために使用する。すべてのプロジェクトは、構築するものの定義、構築する計画、計画に沿って行う作業、および最終プロダクトで構成される。すべてのプロジェクトには地平線がある。つまり、計画に適した時間枠である。地平線が遠すぎると、定義が変わったり、様々な変数が入ってきたり、リスクが大きくなりすぎたりする。スクラムは、最大1ヶ月のプロジェクトのためのフレームワークである。これでも十分に複雑であり、これ以上長くなるとリスクが高い。プロジェクトの予測可能性は、少なくとも月次でコントロールしなければならない。コントロール不能や予測不能のリスクは、少なくとも月次で抑えるようにしなければならない。 {% hint style="info" %} Tip: チームが作業が多すぎることに気づいたときは、プロダクトオーナーに会って、スプリントに選んだプロダクトバックログのスコープを削除したり縮小したりしてもらうこと。逆に時間が余ることに気づいたときは、プロダクトオーナーと追加するバックログを選ぶこと。 {% endhint %} {% hint style="info" %} Tip: チームがスクラムを始めるときは、不確実なことに惑わされない学習期間を2週間とるとよい。2週間のスプリントであれば、インクリメントを2つ合わせることで、他のチームと同期をとることもできる。 {% endhint %} スプリントはタイムボックスが終わる前に中止できる。プロダクトオーナーだけがスプリントを中止する権限を持つ。このとき、ステークホルダー、チーム、あるいはスクラムマスターの意見を聞いてもよい。それでは、スプリントが中止されるのはどんな状況だろうか？スプリントゴールが古くなった場合には、マネジメントがスプリントを中止するかもしれない。会社の方向性が変わったり、市場や技術の状況が変わったりする場合にも、中止する必要があるかもしれない。一般的に、つじつまが合わない状況になったら、スプリントを中止したほうがよい。しかし、スプリントの期間は短く、中止したからといってそれほど意味をなすことはないだろう。 スプリントが中止になったら、プロダクトバックログの完成あるいは「完了（done）」した項目をレビューする。出荷判断可能なインクリメントになっていれば、受け入れられる。その他の項目は、最初の見積もり数値のままプロダクトバックログに戻される。それらにかかった作業は失われたものとなる。スプリントの中止は、別のスプリントを開始するためにスプリント計画ミーティングを開かなければならないため、リソースを消費する。スプリントの中止はチームにとってトラウマになることが多い。しかし、中止はめったに起きないことである。 ### スプリント計画ミーティング スプリント計画ミーティングでは、イテレーションを計画する。1ヶ月のスプリントの場合、ミーティングは8時間のタイムボックスとなる。もっと短いスプリントの場合は、スプリントの長さのおよそ5%を割り当てる。ミーティングは2部構成である。最初の部分（4時間のタイムボックス）では、スプリントで行うことを決める。第2の部分（また別の4時間のタイムボックス）では、決まった機能をプロダクトインクリメントにどのように組み込むかをチームで考える。 スプリント計画ミーティングは2部構成である：「What?」部と「How?」部だ。なかには、この2つを一緒に行うスクラムチームもある。最初の部分では、スクラムチームは「What?」の質問に取り組む。プロダクトオーナーは、プロダクトバックログの最優先項目をチームに提示する。ここで一緒に次のスプリントで開発する機能を考える。ミーティングへのインプットは、プロダクトバックログ、プロダクトの最新インクリメント、チームの許容量、およびチームの過去の実績である。バックログの量はチームの責任で選択する。次のスプリントで遂行できるかどうかを判断できるのはチームだけである。 プロダクトバックログを選択したら、スプリントゴールを丹念に設定する。スプリントゴールはプロダクトバックログを導入することで満たす目的である。これは、チームがインクリメントを構築する理由のガイドとなるステートメントである。スプリントゴールはリリースゴールの部分集合である。 スプリントゴールを設定するのは、チームが自由に機能を扱えるようにするためである。例えば、上記のスプリントのゴールは次のような感じになる：「安全で復元可能なトランザクションミドルウェアを使って、クライアントアカウントの修正機能を自動化する」チームが作業をする上で、このゴールを覚えておく。ゴールを満たすために、チームは機能と技術を実装する。予測したよりも作業が困難であると判明した場合、チームはプロダクトオーナーと相談して、一部の機能を実装する。 スプリント計画ミーティングの第2部では、チームは「How?」の質問に取り組む。この新たな4時間でチームは、スプリント計画ミーティング（What）で選択したプロダクトバックログをどのように完了インクリメントに変えるかを考える。通常、チームは、作業の設計から始める。そして、タスクを見つけ出す。これらのタスクは、プロダクトバックログを動くソフトウェアに変えために必要となる詳細な作業である。タスクは、1日未満で行うことができるように分解すべきだ。タスク一覧はスプリントバックログと呼ばれる。チームは自己組織化し、スプリント計画ミーティングまたはスプリント中にジャストインタイムで、スプリントバックログの作業を請け持つ。 {% hint style="info" %} Tip: 通常、スプリント計画ミーティングでは、スプリントバックログの60～70%しか出てこないだろう。残りはあとで対応する。あるいは、とりあえず大きな見積もりをしておいて、あとで分解する。 {% endhint %} スプリント計画ミーティングの第2部では、プロダクトオーナーはプロダクトバックログを明確にし、トレードオフを支援する。作業が多すぎたり少なすぎたりした場合は、チームはプロダクトオーナーと交渉して、プロダクトバックログを調整する。技術やドメインのアドバイスを求めるために、チームは他の人をミーティングに招待するかもしれない。新しいチームの場合、チームとしてうまくやっていけるかどうかは、このミーティングで分かる。チームはチームを頼らなければならないことに気づく。これに気づけば、チームは自己組織を始め、真のチームとしての特性を持ち、そのように振る舞えるようになる。 ### スプリントレビュー スプリントの最後にスプリントレビューを開く。1ヶ月のスプリントの場合、タイムボックスは4時間となる。もっと短いスプリントの場合、スプリントの5%以上を費やしてはならない。スプリントレビューでは、スクラムチームとステークホルダーが、完了した項目について協議する。この結果とスプリント中のプロダクトバックログへの変更に基づいて、次に完了すべきことを協議する。これは非公式のミーティングであり、機能のプレゼンテーションなどを行って、次に行うことの協働を促進する。 このミーティングには、少なくとも次の要素が含まれている。プロダクトオーナーは、何が完了したか、何が完了しなかったかを識別する。チームは、スプリント中にうまくいったこと、遭遇した問題点、およびどうやって問題を解決したかを議論する。その後チームは、完了した作業のデモンストレーションを行い、質問に答える。プロダクトオーナーは、現状のプロダクトバックログについて話しあう。そして、様々なベロシティを仮定して、有望な完成日を予測する。その後みんなで、これまで見たこと、そしてそれが次に行うべきことにどんな意味があるかを議論する。スプリントレビューは、後のスプリント計画ミーティングにとって価値のあるインプットとなる。 ### スプリントレトロスペクティブ スプリントレビューと次のスプリント計画ミーティングの間に、スクラムチームはスプリントレトロスペクティブを開く。スクラムマスターは、この3時間のタイムボックスのミーティングで、次のスプリントがより有効で、より愉快にするために、スクラムプロセスフレームワークとプラクティスでチームが開発プロセスを改善するように促す。レトロスペクティブで使用するのに有用な技術が、多くの書籍で述べられている。 レトロスペクティブの目的は、先のスプリントを人々、関係、プロセス、ツールの面から検査することである。検査は、うまくいった主要な項目と、違ったやり方をすればもっと良くなったかもしれない項目を識別して優先付けをすべきである。ここには、スクラムチームの構成、ミーティング規約、ツール、「完了」の定義、コミュニケーションの方法、およびプロダクトバックログの項目を「完了」に変えるプロセスが含まれる。スプリントレトロスペクティブの終了までに、スクラムチームは、次のスプリントで導入できる実行可能な改善を特定すべきだ。こうした改善が経験的な検査への適応となる。 ### デイリースクラム チームは、デイリースクラムと呼ばれる15分のステータスミーティングで毎日顔を合わせる。スプリント中のデイリースクラムは、同じ時間、同じ場所で開かれる。チームメンバーは次のことを説明する: * 前のミーティングから今日までに行ったこと * 次のミーティングまでに行うこと * 何かを行う上で障害となること デイリースクラムは、コミュニケーションを改善し、その他のミーティングを除去し、開発の障害を特定して排除し、迅速な意志決定を強調して促進し、みんなのプロジェクト知識のレベルを向上するものである。 スクラムマスターは、チームが確実にミーティングを開くようにする。チームは、デイリースクラムを行うことに責任を負う。スクラムマスターは「簡潔に話す」というルールを実施し、デイリースクラムが短くなるようにチームに伝える。さらにスクラムマスターは、「デイリースクラムでは、鶏は話すことを許されない。どのような方法でも口出しは許されない」というルールも実施する。 デイリースクラムは進捗報告会議ではない。プロダクトバックログの項目をインクリメントに変える人々（すなわちチーム）以外のためのものではないのだ。チームは、スプリントゴールとプロダクトバックログの項目にコミットする。デイリースクラムは、スプリントゴールに向けた進捗の検査である（3つの質問）。通常、スプリントで行う作業に適応するためのミーティングをこの次に開く。チームがゴールを達成する見込みを最適化するためである。これが、スクラムの経験的プロセスにおけるカギとなる検査と適応のミーティングである。 ## スクラムの成果物 スクラムの成果物は、**プロダクトバックログ**、**リリースバーンダウン**、**スプリントバックログ**、および**スプリントバーンダウン**である。 ### プロダクトバックログとリリースバーンダウン チームが開発しているプロダクトへの要求はプロダクトバックログに一覧されている。プロダクトオーナーは、プロダクトバックログ、その内容、利用可能性、および優先度に責任を負う。プロダクトバックログは永遠に完成しない。最初に着手するときは、よく知られて、よく理解されている要求だけが並べられている。プロダクトバックログは、プロダクトや環境に合わせて進化する。プロダクトが適切で、競争力のある、有用なものになるには何が必要かを特定するために、バックログは絶えず変化しなければならない動的なものである。プロダクトが存在する限り、プロダクトバックログも存在する。 プロダクトバックログには、成功するプロダクトを開発し、ローンチするために必要なものをすべてを表されている。すべてのフィーチャ、機能、技術、要望、およびバグフィックスなど、将来のリリースでプロダクトに加えられる変更の一覧となっている。プロダクトバックログの項目には、詳細、優先度、見積もりの属性がある。優先度は、リスク、価値、および必要性を考慮して決定する。こうした属性を算定するための技術が数多くある。 {% hint style="info" %} Tip: 通常、プロダクトバックログの項目は、ユーザーストーリーで記述する。ユースケースの使用も適切だが、それは生命に関するソフトウェアや基幹ソフトウェアに使用するとよい。 {% endhint %} プロダクトバックログは優先度でソートする。優先度の高いプロダクトバックログはすぐ開発に入ることができる。優先度が高いほど、緊急度が高いほど、より考えられたものほど、より多くの同意が得られたものほど、価値があると判断する。優先度の高いバックログには、優先度の低いバックログよりも明確で、情報の記述が多い。より良い見積もりとは、明確さと情報の多さで決められる。項目の記述ができるようになるまで、優先度は低く、情報は少ないままである。 プロダクトが使用され、価値が増加し、市場がフィードバックを提供するようになると、プロダクトバックログは大きくて網羅的な一覧に変わる。要求の変化はとどまることを知らない。プロダクトバックログは生きたドキュメントなのだ。ビジネス要求、市場、技術、および人材の変化は、プロダクトバックログの変化を引き起こす。手戻りを最小化するには、最優先項目だけを記述しなければならない。次のスプリントでチームが携わるプロダクトバックログの項目は、スプリント期間内に完了するよう分解されており、程よい粒度になっている。 {% hint style="info" %} Tip: 通常、スクラムチームは、スプリントの10%の時間を使ってプロダクトバックログを上記の定義に合うように調整する。程よい粒度になったら、プロダクトバックログの最上位にある項目（優先度が最も高く、価値が最も高い項目）を、1つのスプリントに入るように分解する。この調整プロセスで、項目を分析し、吟味する。スプリント計画ミーティングでは、これらの最優先項目は十分に理解されており、簡単に選ぶことができる。 {% endhint %} 複数のスクラムチームが同じプロダクトに取り組むことがよくある。この場合も、1つのプロダクトバックログで、これから手がけるプロダクトの作業を記述する。このとき、プロダクトバックログの項目をグループ化する属性を採用する。グループ化には、フィーチャセット、技術、あるいはアーキテクチャを使い、スクラムチームの作業を整理する。 {% hint style="info" %} Tip: 受入テストもプロダクトバックログの項目の属性としてよく使用する。これは、プロダクトバックログの項目が完成したときに行わなければならないテスト可能な詳細なテキスト記述である。 {% endhint %} リリースバーンダウンは、プロダクトバックログの残工数の合計を、時間軸でグラフ化したものである。工数の単位は、チームや組織が決定した作業の単位になる。時間軸の単位は、通常はスプリントになる。 プロダクトバックログの項目の見積もりは、最初はリリース計画で算出し、あとで作りながら算出していく。プロダクトバックログの調整では、それをレビューし、改訂する。ただし、変更はいつでも行うことができる。チームは、すべての見積もりに責任を負っている。理解やトレードオフを助けることで、プロダクトオーナーがチームに影響を及ぼすことがあるかもしれない。しかし、最終的な見積もりはチームが行う。プロダクトオーナーは、常に更新されるプロダクトバックログやリリースバックログバーンダウンを最新状態で維持管理しておかねばならない。トレンド線については、残作業に基づいて引くことができる。 {% hint style="info" %} Tip: 組織によっては、完了するよりも多くの作業がバックログに加えられることもある。このときのトレンド線は、水平か、あるいは上方へ傾斜することになる。これを補い、かつ透明性を確保するには、作業の増減に応じて、新しい下限を設けるとよい。下限は、変更が著しいときにだけ手を加えるようにし、十分にドキュメント化しておくようにする。 {% endhint %} {% hint style="info" %} Tip: 初めて一緒になるチームだったり、プロダクトをよく知らなかったり、基盤技術をあまり理解していなかったりすると、リリース初期の2～3スプリントのトレンド線については、信頼度が低いかもしれない。 {% endhint %} ### スプリントバックログとスプリントバーンダウン スプリントバックログは、プロダクトバックログの項目を「完了」インクリメントに変えるためにチームが行うタスクで構成される。その多くは、スプリント計画ミーティングで作られる。これは、スプリントゴールを達成するのにチームが必要と考えた作業のすべてである。スプリントバックログの項目は分解されていなくてはならない。変化の具合がデイリースクラムで理解できれば、十分に分解できているといえる。 チームは、スプリント中に追加されるスプリントバックログだけでなく、スプリントバックログ全体に対して常に修正を加えていく。個別のタスクに落とし込むなかで、必要なタスクや時間の多寡に気づくかもしれない。新しい作業が必要になったら、チームはスプリントバックログに作業を加える。タスクに着手したりタスクを完了したりすれば、見積もり残作業の時間を更新する。タスクが不必要であれば削除する。スプリント中にスプリントバックログを変更することができるのはチームだけである。内容や見積もりを変更することができるのもチームだけである。スプリントバックログは、よく目立つところに置かれ、スプリント中にチームが遂行する作業をリアルタイムに反映したものであり、チームが占有するものである。 プリントバックログバーンダウンは、スプリントバックログの残作業の量を時間軸で表したグラフである。このグラフを作成するには、バックログの見積もりを毎日合計して、残作業を算出しなければならない。スプリントの残作業は、スプリントバックログに残された作業の合計である。この合計値を毎日追跡して、残作業を示すグラフを作る。グラフ上の点を線で結ぶことで、チームはスプリントの進捗を管理することができる。スクラムでは、期間は考慮しない。残作業と日付だけが対象となる変数である。 {% hint style="info" %} Tip: バーンダウンチャートは、可能な限り、大きな模造紙に手書きで描いて、チームの作業場所に貼り出しておくこと。Excelなどのツールよりも大きく目につくチャートのほうが、チームが目にする可能性が高い。 {% endhint %} スプリントの目的に関係するスクラムのルールがある。それは、出荷判断可能な機能のインクリメントを納品するために、「完了」の定義を作ることである ## 完了 スクラムでは、チームはすべてのスプリントでプロダクト機能のインクリメントを作らなければならない。このインクリメントは出荷判断可能なものでなければならず、プロダクトオーナーが直ちに導入を決定できるものでなければならない。そのためには、インクリメントはプロダクトの完全な断片でなければならない。そして、それが「完了」していなければならない。インクリメントは、先行するすべてのインクリメントに付加するものであり、十分にテストされたものであり、すべてが一緒に動くものでなければならない。 機能が完了しているというのは、プロダクト開発の場合、少なくともコードがクリーンで、リファクタリングされていて、ユニットテストが通り、実装が終わり、受入テストが通ったものだと考えるかもしれない。あるいは、実装が終わっただけのものだと考える人がいるかもしれない。「完了」の定義が分からないと、経験的プロセス制御の2本の脚が機能しない。誰かが「完了」について説明すれば、みんなが「完了」の意味を理解するはずだ。 完了とは、チームがスプリントでプロダクトバックログの項目を「作業中（doing）」にするときの意味を定義するものである。ドキュメントが含まないプロダクトでは、「完了」の定義にドキュメントが含まれていない。完全な「完了」インクリメントでは、すべてのプロダクトバックログの項目に対して、分析、設計、リファクタリング、プログラミング、ドキュメント、およびテストが行われる。テストには、ユニットテスト、システムテスト、ユーザーテスト、回帰テスト、それから、パフォーマンステスト、スケーラビリティテスト、セキュリティテスト、統合テストなどのような非機能テストも含まれる。完了には国際化も含まれる。なかには完了の定義をすべて満たせないチームもある。そのときは、プロダクトオーナーに説明しなければならない。残作業については、プロダクトを導入する前に完了しなければならないだろう。 {% hint style="info" %} Tip: 「未完了（Undone）」作業は、「未完了作業（Undone Work）」あるいは「実施検討作業（Implementation Work）」と呼ばれるプロダクトバックログの項目に蓄積する。こうした作業を蓄積しておくと、プロダクトバックログのバーンダウンがきちんと停滞するようになる。 {% endhint %} {% hint style="info" %} Tip: 1つのスプリントで完全なインクリメントを構築することができない組織もある。それは、自動テストのインフラがなくてテストを終了できないからかもしれない。その場合、インクリメントに2つのカテゴリーを作成する。「完了」作業と「未完了」作業である。「未完了」作業は、インクリメントの一部であり、あとで完了しなければならない。プロダクトオーナーは、スプリントの終了時に検査するものを正確に知っている。プロダクトオーナーは「完了」の定義を理解しており、インクリメントがその定義に合っているかを確かめればよい。「未完了」作業は、「未完了作業」という名でプロダクトバックログの項目に追加する。リリースバーンダウンのグラフに正しく反映するためである。これによって、リリースへの進捗の透明性を確保できる。スプリントレビューでの検査と適応は、この透明性と同じくらい正確なものである。例えば、チームがプロダクトバックログの項目に、パフォーマンステスト、回帰テスト、スタビリティテスト、セキュリティテスト、および結合テストを行うことができなければ、分析、設計、リファクタリング、プログラミング、ドキュメンテーション、ユニットテスト、およびユーザーテストが完了した作業との比率を計算できる。では、仮に「完了」作業が6個、「未完了」作業が4個の割合だとしよう。プロダクトバックログの項目を6個終了したら（チームは「やり方」を知っている前提で見積もっている）、その時点で4個の「未完了」プロダクトバックログの項目を追加する。スプリントを重ねるごとに、各インクリメントの「未完了」作業は蓄積されるため、プロダクトのリリース直前にこれらの残作業に取り組まなければならない。残作業は、組織の特性に左右されるため指数関数になることもあるが、基本的には直線的に蓄積される。こうした「未完了」作業を消化するためのリリーススプリントをリリース直前に追加する。スプリントの数は、「未完了」作業の蓄積が線形でければ、予測不能である。 {% endhint %} スクラムレトロスペクティブの実施に役立つ技術は、以下の書籍に記されている： * "Agile Retrospectives: Making Good Teams Great," Ester Derby and Diana Larsen, Pragmatic Bookshelf, 2006. * 翻訳『アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き』角征典（訳）、オーム社、2007年 * "User Stories Applied:For Agile Software Development," Mike Cohn, Addison-Wesley, 2004. * "Writing Effective Use Cases," Alistair Cockburn, Addison-Wesley, 2000. * 翻訳『ユースケース実践ガイド―効果的なユースケースの書き方』、ウルシステムズ株式会社（監修）、山岸耕二（訳）、矢崎博英（訳）、水谷雅宏（訳）、篠原明子（訳）、翔泳社、2001年