スクラムガイド(LeSS版)

PDFのダウンロード

Craig Larman & Bas Vodde (original by Ken Schwaber & Jeff Sutherland) 2024年7月

スクラムガイドの目的

スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。

Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。

LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラムの構造を有し、プロダクト全体のレベルではスクラムのコンセプトを反映させている。（スクラムはこのガイドで定義されている）

なぜこのガイドをつくったのか？最新のスクラムガイドはLeSSとは異なる進化の道を歩んでおり、大規模スクラム（LeSS)が前提としているスクラムが異なるバージョンとなることで、矛盾を孕んだり、複数チームでの環境ではより複雑な状況を生み出したり、適応性の低下が起こる事が考えられた。

LeSS版のスクラムガイドはLeSSが想定しているスクラムを定義したものである。 Craig Larman と Bas Vodde はLeSSを提唱し、 Ken Schwaberが提唱したスクラムガイドを基礎とした、このスクラムガイドを提唱している。

This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. 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.

スクラムの定義

スクラムは軽量のフレームワークで複雑で適応性を必要とする課題解決をサポートし、組織が効果的でクリエイティブに最も価値の高いプロダクトを提供する事を支援する。

スクラムには下記の要素が必要である：

プロダクトオーナーがプロダクトをインクリメンタルに作るためにアイディアに優先順位を付ける。
チームが選んだアイディアを価値のあるプロダクトインクリメントにしていく。
チーム、プロダクトオーナー、およびステークホルダーが一緒に結果を検査し、次のスプリントに向けて調整する。
上記を繰り返す。

スクラムのフレームワークは意図的に不完全に作られている。スクラムは骨格を提供するだけで、隙間は関わる人たちの集合知で埋めていく事を期待しているわけである。これにより、現状の管理手法、環境、仕事に関する技術の相対的な効率性の透明性が高まり、プロダクト、チーム、および仕事をする環境に対する継続的な改善が可能になる。

スクラムはシンプルである。スクラムは具体的なやり方を伝える代わりに役割、イベント、作成物をはじめとするスクラムのルールが関係性や相互作用を管理していく事につながる。ここでいう、スクラムのルールとはこのドキュメント全体で語られている事柄である。

スクラムの理論

スクラムの基礎は経験主義である。経験主義は経験から知識を得る事が可能なので、観察した事をベースに意思決定を行うという考え方となる。スクラムは反復的にインクリメンタルな手法となるので、リスクを早いタイミングで検知する事につながる。

経験主義は、透明性、検査、適応という３つの柱で支えられている。

透明性

スクラムは透明性を必要としていると同時に透明性を提供してくれる。スクラムを導入する事により、検査と適応の機会が増え、透明性を提供してくれている。しかしそのためには、同時に実際の仕事をしている人たちやプロダクトを受け取る人たちに対してプロダクト面でもプロセス面でも透明性が求められる。透明性が検査を可能とするのである。透明性の無い検査は間違った方向に進んでしまい、ムダである。

検査

進捗とプロセスは改善の機会を見つけ、提供する価値を高め、適応性を向上し、より効果的に仕事の満足度を高める為に頻繁に、そして入念に検査される必要がある。スクラムは４つのイベントにより検査を促してくれる。

検査により適応が可能になるのである。適応しない検査には意味はない。スクラムのイベントは変化をさせる為に作られているのである。

適応

もし、改善の可能性や新たに探求すべき事がみつかったのであれば、開発内容やプロセスは調整されるべきである。この調整をすぐに実施することで、価値提供を最大化する事につながるのである。

関わっている人たちに権限が移譲されてなかったり、自己管理できてない状態だと適応が難しくなってしまう。

スクラムの価値基準

スクラムを成功させるためには、5つの価値基準をより高度に実践することが求められる。

確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）

チームは継続的な改善とお互いのサポートを確約する。チームは最善の成果を上げるために、スプリントでの作業に集中する。チーム、プロダクトオーナー、そしてステークホルダーは、作業と課題を公開する。チームのメンバーはお互いを能力があり自立した人間として尊敬し、一緒に働く人たちからも尊敬される。チームメンバーは、正しいことを実行し、困難な問題に取り組む勇気を持つ。

これらの価値基準は、作業、⾏動、そして振る舞いの⽅向性を⽰している。下される決定、実⾏される手段、スクラムの使⽤⽅法は、これらの価値基準を強化するものであり、減少させたり損なったりするものであってはならない。これらの価値基準がチームや⼀緒に働く⼈たちによって体現されると、スクラムの経験主義を支える三本柱「透明性」「検査」「適応」が実際に機能し、信頼が築かれる。

スクラムの役割

スクラムはスクラムマスター、プロダクトオーナー、そしてチームで構成されており、プロダクトビジョンの達成に全員が集中している状態である。

チームは敏捷性を維持できる程度に小さく、スプリントで十分な仕事を終わらせられる程度には大きい必要があるが、多くの場合、10名以下となる。ほとんどの場合、小さなチームの方がコミュニケーションが上手くいき、生産性も高い。もし、チームが大きくなりすぎたら、同一のプロダクトを開発する密接に仕事をする複数のチームに分割を検討すべきである。同一のプロダクトを密接に開発するという事は、プロダクトビジョン、プロダクトバックログとプロダクトオーナーを共有するという事を意味している。

チームとプロダクトオーナーはプロダクトに関する全ての活動に対して責任を持つ。それは、ステークホルダーとのコラボレーション、確認、メンテナンス、オペレーション、実験、R&Dなどプロダクトを作る上で必要な全てという事になる。チームとプロダクトオーナーは自分たちの仕事を自分たち自身で管理できる構造、そして権限を付与される。そして、維持可能なペースでスプリントを過ごす事により、集中し、継続性を改善していけるのである。

チーム

チームは各スプリントで利用可能なプロダクトインクリメントを作る事にどのような側面であろうと貢献する事を確約している人たちで構成されている。

チームは下記のような要素を持っている：

チームは自己管理をしている。というのは、チーム内で誰が、何を、いつ、どのように実施するのかを決める。そして、自分たちのプロセスと進捗を自分たち自身で、管理、監視する責任を持つ。
チームはクロスファンクショナルである。というのは、チームとしてプロダクトインクリメントを作る上で必要な全てのスキルを有している。
チームにはテスト、アーキテクチャ、運用、UXなどのサブチームを有していない。
チームメンバーは専門的なスキルや得意なエリアがあるかもしれないが、チームとして共同責任を負う。
チームメンバーは責任の範囲を限定してしまうような肩書きや役割を持たない。

チームメンバーに求められるスキルは仕事の分野によって大きく異なる。それでも、チームメンバーは下記の点について常に責任を持つ：

スプリントの計画をし、スプリントバックログを作る。
完成の定義を厳守する事で品質を維持する。
スプリントゴールに向けての計画を現状に合わせて適応させる活動を日々おこなう。そして、
プロフェッショナルとしてお互いに責任を持つ。

プロダクトオーナー

プロダクトオーナーはチームの労力の結果として出来上がるプロダクトの価値を最大限に高める事に責任を持つ。どのように実践するかは組織の状況により変わるが、プロダクトオーナーは下記のようなプロダクトバックログの管理についても責任を持つ：

プロダクトのビジョンを明確にし伝えていく。
プロダクトバックログアイテムを追加し、そのアイテムがどのようにプロダクトビジョンに貢献するのかを伝える。
プロダクトバックログアイテムの並び替え、そして、
プロダクトバックログが透明性が高い状態になっており、理解されている事を保証する。

プロダクトオーナーは上記のような仕事や責任を他の人に委譲する事もある。しかし、権限を委譲した場合でも常にプロダクトオーナーは最終的な責任を負う事になる。

プロダクトオーナーとして成功するには、組織全体がプロダクトオーナーの意思決定を尊重する環境が必要である。プロダクトオーナーの意思決定はプロダクトバックログの内容や並び順、そしてスプリントレビューでインクリメントの検査を通じて透明性の高い状態になっている事が重要である。

プロダクトオーナーは1人の人であり、委員会などのグループではない。プロダクトオーナーは多くのステークホルダーからの要望を受ける事になり、ステークホルダーを代表して意思決定を行う事になる。プロダクトバックログの優先順位を変更したいという要望がある場合、かならずプロダクトオーナーを説得して優先順位を変えてもらうようにする。

スクラムマスター

スクラムマスターはこのスクラムガイドで定義されているスクラムを確立させる事に責任を持つ。全員にスクラムの原理原則と手法を伝える事でその責任を果たしていくのである。

スクラムマスターはチームとプロダクトオーナーが健全に機能している事、そして組織に価値提供と適応性向上を目的にスクラムを使うことの理解を促す。改善を支援することでこれを実現する。

スクラムマスターはチーム、プロダクトオーナーと組織全体に貢献する真のリーダーである。スクラムマスターはサーバントリーダーシップを発揮して、貢献する。
スクラムマスターはチームに対して下記のような貢献をする：

チームメンバーを自己管理、そしてクロスファンクショナルな状態になるようにコーチする。
チームが完成の定義を満たした高い価値のインクリメントを作る事を支援する。
チームの進捗の妨げになるような障害を取り除き、そして、
全てのスクラムイベントが実施され、前向きで、生産的で、タイムボックス内で実施される事を保証する。

スクラムマスターはプロダクトオーナーに対して下記のような貢献をする：

効果的にプロダクトビジョンを定義したり、プロダクトバックログの管理の仕方をサポートする。
プロダクトオーナーやチームに対して明確で一貫性のあるプロダクトバックログアイテムの重要性に対する理解を促す。
複雑な環境において、漸進的なプロダクト計画を実現し、そして、
必要や要望に応じて、ステークホルダーとのコラボレーションをファシリテートする。

スクラムマスターは組織に対して下記のような貢献をする：

リーダーシップの発揮、トレーニング、そしてスクラム導入に必要なコーチングを提供する。
組織に対してスクラム導入の計画やアドバイスを行う。
複雑な仕事に対して従業員やステークホルダーが漸進的な開発のアプローチが有効であるという理解を促す。そして、
ステークホルダー、チームとプロダクトオーナーの間にある壁を取り除いていく。

スプリント

スプリントはスクラムの最も重要な要素である。なぜなら、アイディアが価値に変換される場だからである。スプリントは一貫性を生むために作られる固定された1ヶ月以下の期間の枠である。前のスプリントが終わり次第、次のスプリントが始まる。
プロダクトビジョンを実現する為に行う全ての仕事がスプリントに含まれている。これには、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブとプロダクトバックログリファインメントが含まれる。

スプリントの期間中：

スプリントゴールを脅かすような変更は行わない。
品質も犠牲にしない。
スプリント期間中にも学習は進むので、プロダクトオーナーとスコープの明確化や再交渉が行われる事はある。

スプリントが開発にリズムを与え、プロダクトビジョンに向けて検査と適応が実施される事を保証する。そして、スプリント期間を短くする事で、より多くの学習サイクルが作られ、コストや労力に対するリスクを限定する事になる。捉え方によっては、スプリントは小さなプロジェクトだと捉える事もできる。

進捗を予測するためのさまざまな手法が存在する。予測は時に必要だが、予測の手法は経験主義の重要性を置き換えるものではない。複雑な環境では、何が起こるかはわからない。すでに起こったことだけが、将来を見据えた意思決定に活用できる。

スプリントゴールが意味のないものになった場合、スプリントはキャンセルされることがある。スプリントをキャンセルする権限があるのはプロダクトオーナーだけである。

スクラムイベント

スクラムの全てのイベントは検査と適応を実施する正式な場となる。そして、これらのイベントは透明性を担保する為に設計をされたものである。もし、スクラムで定義されているイベントが省略されたり、削られたりした場合、検査と適応を行う機会を失ってしまう事になる。

スプリントプランニング

スプリントプランニングはスプリントで実施される仕事を明確にする場となる。この計画はチームとプロダクトオーナーが協働した結果として作られるものである。アドバイスをもらうためにチーム以外の人をスプリントプランニングに招待してもよい。
プロダクトオーナーはプロダクトビジョンを達成する為に最も重要なプロダクトバックログアイテムについて参加者が議論できる状態になっているかを確かなものにする。

スプリントプランニングでは下記のようなトピックが話し合われる：

なぜこのスプリントに価値があるのか（Why） — プロダクトオーナーはプロダクトがこのスプリントを通じて如何に価値や有用性を高める事が可能なのかを提案する。そして、チームとプロダクトオーナーが協働しながらスプリントゴールを定める事によりステークホルダーにとってこのスプリントでの活動がどのような価値をもたらし、プロダクトビジョンにどのように貢献するかを伝える。スプリントゴールはスプリントプランニングが終わるまでに定められる。

このスプリントで何ができるか(What) — プロダクトオーナーと議論しチームはプロダクトバックログの一番上にあるアイテムからこのスプリントで対応するアイテムを選択する。必要な場合はチームがリファインメントを行うこともある。

どのように選択した仕事を終わらせるのか(How) — チームが選択したプロダクトバックログアイテムについて、どのような作業をすれば、完成の定義を満たしたインクリメントを作ることができるのかを計画する。多くの場合、この計画はプロダクトバックログアイテムを小さな（1日かそれ以下）のタスクに分割する事で作られるが、実際にどのように作るからはチームの裁量に委ねられている。

スプリントゴールはスプリントで目指すべき唯一の目標である。スプリントゴールはチームにスプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。もし、スプリント中に仕事が想定と異なる状況になった場合、スプリントゴールを変えずにスコープを変える事ができないかを、チームとプロダクトオーナーは話しあう。また、スプリントゴールはチームが個々人でバラバラに仕事をするのではなく、チームとして集中し、協働する環境を作ることも促す。

スプリントゴール、スプリントで実施するプロダクトバックログアイテム、そして実施の計画の全てがスプリントバックログに反映される。

スプリントプラニングはタイムボックスが決まっており、1ヶ月スプリントの場合、最大８時間となる。ほとんどの場合、スプリントが短くなればスプリントプランニングのタイムボックスも短くなる。

デイリースクラム

デイリースクラムの目的はスプリントゴールへの進捗を検査し、状況に応じてスプリントバックログを適応させ、次に何の仕事をすべきか調整する場である。

デイリースクラムは最大15分のチームのイベントで、シンプルに運用する為、勤務日は毎回、同じ時間と場所で実施する。

どのような方法で実施しても構わないが、チームはスプリントゴールに対する進捗を重要視する事と、次の２４時間の実行可能な仕事の計画を明確にする。この活動が集中する環境を作り、自己管理を促進する。

デイリースクラムはコミュニケーション、課題の発見、意思決定の速度を改善する。その結果として、今まで実施していた不要なミーティングの削減にもつながる。

デイリースクラムはチームが計画を調整する唯一の場ではなく、チームは常に一緒に仕事をしているので、他の時間にも残りのスプリントで実施する仕事に対する議論をして適応したり、再計画をしたりする。

スプリントレビュー

スプリントレビューの目的はスプリントの成果物を検査し、どのように適応をさせて行くかを考える場である。チームとプロダクトオーナーがプロダクトのインクリメントを主要なステークホルダーに対して見せ、プロダクトビジョンに向けての進捗を議論する。

イベントの最中にチーム、プロダクトオーナーとステークホルダーはスプリントの成果物をレビューし、どのような環境の変化があったのかを共有する。これらの情報を元に参加者の人たちが協働しながら次に何をするべきかを検討する。プロダクトバックログも新たな機会に適応する為に調整される。そして、スプリントレビューはあくまで動く物を中心とした場であり、ただスライドで説明するような場にはしないでほしい。

スプリントレビューはスプリントの最後から２番目のイベントとなり、1ヶ月スプリントの場合は最大４時間というタイムボックスがある。短いスプリントの場合はスプリントレビューも短くなる。

スプリントレトロスペクティブ

スプリントレトロスペクティブの目的は品質、効果、楽しみを向上させる計画を立てる場である。

チームはこのスプリントが個人として、協働の仕方、プロセス、ツール、そして完成の定義がどうだったのか検査する。検査対象は仕事のドメインにより異なるが、どのような仮説が間違いを産んだのかを特定し、その原因を探求する。チームはそのスプリントで何が上手くいったのかを議論し、どのような課題に直面したのか、そしてそれらの課題はどのように解決されたのか（または解決されなかったのか）を議論する。

チームは何を変える事が最も効果的な改善につながるのかを特定し、なるべく早く実行に移す。場合によっては、次のスプリントで対応する為にスプリントバックログに追記する場合もある。

スプリントレトロスペクティブがスプリントの終わりを意味している。1ヶ月スプリント場合は３時間のタイムボックスが設定されるが、短いスプリントの場合はイベントの時間も短くなる。

プロダクトバックログリファインメント

プロダクトバックログリファインメントの目的はプロダクトバックログがしっかりとメンテナンスされている状態を作り、スプリントプランニングの準備、プロダクトビジョンと方向性が合致している事を確認する。プロダクトバックログリファインメントは活動としてイベントの外で行われたり、スプリントプランニングの一部として実施されたり、スプリント中に独立したイベントとして実施される場合がある。

プロダクトバックログリファインメント中にプロダクトオーナーはプロダクトビジョンを念押しした上で、チーム、プロダクトオーナーと、必要な場合は主要なステークホルダーと一緒に（１）直近の数スプリントで対応する可能性のあるアイテムの明確化。（２）大きなアイテムで近々検討を進めるアイテムの分割（３）プロダクトバックログアイテムの見積り又は必要に応じて既に見積もられたアイテムの再見積りを実施する。

プロダクトバックログリファインメントはスプリントの最大10%程度を使う。

スクラムの作成物

スクラムで定義されている作成物は重要な情報の透明性を最大化する為に作られ、全員が作成物に対して同じ理解を得られるように設計されている。

プロダクトバックログ

プロダクトバックログは漸進的で、プロダクトを進化させる為に必要なプロダクトバックログアイテムが並べられたリストである。チームが仕事を受け取る唯一の物である。

プロダクトバックログは完成する事はない。プロダクトの環境が進化するのに応じてプロダクトバックログも進化していく。そしてプロダクトバックログはダイナミックに変化する。プロダクトバックログは常にプロダクトがどうあるべきなのか、競争に生き残る為に何が必要か、そして何が便利なのかなどが発見される度に常に変化をしていくのである。

プロダクトバックログアイテムには説明、見積り、価値などいくつかの属性が存在する。チームは見積りに責任を持つ。チームがスプリントに持ち込むアイテムの多くは前のプロダクトバックログリファインメントで明確化されたものである。

スプリントバックログ

スプリントバックログはスプリントゴール（Why）、スプリントに持ち込む選択をされたプロダクトバックログアイテム（What）とどのようにインクリメントを届けるかの実施計画（How）から成り立っている。

スプリントバックログは、チームによりチームの為に作られた計画である。スプリントゴールを達成する為にチームが作った計画であり、透明性の高い現時点での仕事の状態を反映したものである。スプリントバックログは常に更新され、スプリントが進むとスプリントバックログは常に変化をし、学習が進む事で変わっていく。そして、デイリースクラムで進捗を確認できる程度に詳細がわかる状態が好ましい。

インクリメント

インクリメントはスプリントの成果物でもあるし、プロダクトビジョンに辿り着くまでの途中で出来た生成物でもある。インクリメントは以前に作られたインクリメントに追加され、徹底的に検証がされているものである。価値を届ける為に、インクリメントは利用可能な状態である必要がある。

完成の定義

完成の定義は、プロダクトバックログアイテムが完成したと見なす基準をプロダクトオーナーとチームが定めたものある。多くの場合、どのような品質を完成したプロダクトバックログアイテムが満たすべきかが書かれている。

完成の定義はインクリメントはどのような仕事がされたものなのかの透明性を全員に提供するものである。もし、１つのプロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできないし、スプリントレビューでのレビュー対象にもならない。代わりにアイテムはプロダクトバックログに戻され、将来のどこかで開発を続けるか再検討される。

チームメンバーは完成の定義を確認する必要がある。もし、複数チームで仕事をする場合、関わる全てのメンバーが完成の定義を一緒に定義をし、守る必要がある。

おわりに

スクラムは無料で提供されており、このガイドがスクラムの定義となる。そして、ここに記されているスクラムフレームワークの概要は普遍である。もちろん、スクラムの一部だけを導入することは可能だが、それはスクラムとは呼べない。スクラムは全てが揃って初めて十分に役割を果たし、他の技術的な物も含めた手法やメソッドの入れ物として機能するのである。

謝辞

人々

スクラムに貢献した数千人の中でも、特に初期に重要な役割を果たした人々を取り上げる。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）を称賛する。

適応事項

この文書は、Ken SchwaberとJeff Sutherlandによるオリジナルのスクラムガイドの改訂版である。2024年にCraig LarmanとBas Voddeによって、オリジナルの文書に対して細かな修正や、更新概要を含めた変更が加えられている。

LeSS版の更新概要

このスクラムガイドの更新はスクラムガイド2020版を基にしているが、一部スクラムガイド2017版からの内容が含まれている。主な変更点は以下の通りである。

「複雑な問題への取り組み」からプロダクトへの表現に戻した。
スクラムチームという概念を削除した。
開発者をチームに変更した。
スプリントをスクラムイベントから外し、独立した項目にした。
プロダクトゴールをプロダクトビジョンに変更した。
プロダクトオーナーのセクション内、バックログの管理から「プロダクトバックログアイテムを作成し、明確に伝える」を削除した。
スプリントプランニングのセクションの、トピック1・2・3をwhy/what/howに変更した。
プロダクトバックログリファインメントをスクラムイベントに追加したが、イベントとしてではなく、活動として実施できることにも言及した。
スクラムの作成物に対するコミットメントの記載を削除した。
スプリントゴールをスプリントプランニングの中に配置した。
完成の定義をコミットメントではなく合意するものとして位置付けした。