スクラム公式ガイド: ゲームのルール

2020年11月¹

日本語版

このHTMLバージョンのスクラムガイドは、2020年11月版の直接の移植版であり、PDFで入手できますこちら。

スクラムガイドの目的

我々は 1990 年代初頭にスクラムを開発した。世界中の⼈たちがスクラムを理解できるように、スクラムガイドの最初のバージョンを 2010 年に執筆した。それ以来、機能的に⼩さな更新を加えながらスクラムガイドを進化させてきた。我々は共にスクラムガイドを⽀援している。

スクラムガイドにはスクラムの定義が含まれている。フレームワークの各要素には特定の⽬的があり、スクラムで実現される全体的な価値や結果に⽋かせないものとなっている。スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。場合によっては、スクラムが役に⽴たなくなることさえある。

成⻑を続ける複雑な世界において、スクラムの利⽤は増加しており、我々はそれを⾒守っている。スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。そうした状況を⾒ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専⾨家もスクラムを利⽤するようになった。スクラムでは「開発者」という⾔葉を使っているが、開発者以外を排除しているのではなく、単純化のために使⽤しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。

スクラムを利⽤していると、本⽂書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発⾒・適⽤・考案することもあるだろう。そうしたものについては、スクラムガイドの⽬的の範囲外である。これらは状況に依存しており、スクラムを利⽤する状況によって⼤きく異なるからだ。スクラムフレームワークで利⽤できる戦術にはさまざまなものが存在するが、それらはスクラムガイド以外のところで説明されている。

Ken Schwaber & Jeff Sutherland 2020 年 11 ⽉

スクラムの定義

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。

1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
4. 繰り返す。

スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。

スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

スクラムの理論

スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。

スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤している。スクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える⼈たちである。また、必要に応じてそうしたスキルを共有または習得できる⼈たちである。

スクラムでは、検査と適応のための 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 時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。

スクラムの作成物

スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最⼤化できるように設計されている。作成物を検査する⼈が、適応するときと同じ基準を持っている。

各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。

• プロダクトバックログのためのプロダクトゴール
• スプリントバックログのためのスプリントゴール
• インクリメントのための完成の定義

これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。

プロダクトバックログ

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。

スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。

作業を⾏う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を⽀援することもできる。

確約（コミットメント）：プロダクトゴール

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（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）の各社に感謝したい。

翻訳について

本ガイドは、上記の開発者による英語バージョンを⽇本語に翻訳したものである。⽇本語訳は⾓征典、荒本実、和⽥圭介が担当した。

過去の版の翻訳レビューについては、守⽥憲司さん、⾼江洲睦さん、永瀬美穂さん、栗秋宏徳さん、川⼝恭伸さん、⾓⾕信太郎さん、⽊村卓央さん、原⽥騎郎さん、吉⽻⿓太郎さん、むらはしけんいちさん、いろさん、たなべすなおさんに協⼒いただいた。

翻訳に関する連絡先：⾓征典(kdmsnr@gmail.com)

⽤語集

General Terms ⼀般⽤語
Scrum スクラム

Theory 理論
Empiricism 経験主義
Transparency 透明性
Inspection 検査
Adaptation 適応

Events イベント
Sprint スプリント
Sprint Planning スプリントプランニング
Daily Scrum デイリースクラム
Sprint Review スプリントレビュー
Sprint Retrospective スプリントレトロスペクティブ

Roles 役割
Scrum Team スクラムチーム
Scrum Master スクラムマスター
Product Owner プロダクトオーナー
Developers 開発者

Artifacts 作成物
Product Backlog プロダクトバックログ
Sprint Backlog スプリントバックログ
Increment インクリメント

Misc その他
Definition of Done 完成の定義

スクラムガイド 2017 年版からスクラムガイド 2020 年版への変更点

指⽰的な部分を削減

スクラムガイドは時間が経つにつれて少し指⽰的なものになっていた。2020 年版では、指⽰的な表現を削除または緩和して、スクラムを最⼩限かつ⼗分なフレームワークに戻すことを⽬的としている。たとえば、デイリースクラムの質問の削除、PBI（プロダクトバックログアイテム）の属性に関する記述の緩和、スプリントバックログにあるレトロスペクティブのアイテムに関する記述の緩和、スプリントの中⽌のセクションの削減などを実施した。

ひとつのチームがひとつのプロダクトに集中する

これはチーム内で分断が発⽣し、PO と開発チームの関係が「プロキシ」や「我々と彼ら」といった問題につながることを排除するためである。存在するのは、PO、SM、開発者の 3 つの異なる責任を持ち、同じ⽬的を共有するひとつの「スクラムチーム」だけである。

プロダクトゴールの導⼊

スクラムガイド 2020 年版では「プロダクトゴール」を導⼊した。スクラムチームに⼤きな価値のある⽬的に集中してもらうためである。各スプリントでは、プロダクトを全体的なプロダクトゴールに近づける必要がある。

スプリントゴール、完成の定義、プロダクトゴールの居場所

以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴール」と「完成の定義」について説明していた。これらは作成物ではなく、作成物に付随するものだった。2020 年版では「プロダクトゴール」を導⼊し、これらの位置づけを明確にした。3つの作成物には、それぞれの「確約（コミットメント）」が含まれる。つまり、プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義（カッコをなくした）が含まれる。これらの存在により透明性がもたらされ、作成物の進捗に集中できるようになる。

⾃⼰組織化よりも⾃⼰管理

以前のスクラムガイドでは、開発チームは⾃⼰組織化しており、「誰が」「どのように」作業するかを選択できるとしていた。2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。

スプリントプランニングの 3 つのトピック

これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラムガイド 2020 年版では、3 つ⽬のトピック「Why」に重点を置いた。これはスプリントゴールで⾔及されている。

幅広い読者のために全体的に⽂章を簡略化

スクラムガイド 2020 年版では、冗⻑で複雑な⽂章と IT に関する記述（例：テスト、システム、設計、要求など）を排除している。以上の変更で、スクラムガイドは 13 ページ未満となった。