2020年11月に3年ぶりのスクラムガイドの改定がありました。
変更点を自分なりに整理しておきたいと思います。今回のスクラムガイドの改定は、私自身がスクラムで経験し、感じたこととと重ね合わせると実践者の振り返りが反映されたとつくづく感じます。この記事では、私にとってのすっきり腹落ちポイントを中心にまとめます。
スクラムガイド(2020年版)
（英語） https://scrumguides.org/scrum-guide.html
（日本語）https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
#2020年版での変更点
すでに2020年版の解説をされているサイトも増えているので、個人的にうれしかった内容での変更点への考察と説明を試みます。
###・スクラムの定義
新しくなった定義の記述は”おー、ちゃんと書いてくれた！”と思いました。特に気に入った部分を太字にしてみます。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、
理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。スクラムフレー
ムワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが
定義されている。スクラムは実践する人たちの集合知で構築されている。スクラムのルールは
詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、手法を使用できる。スクラムは
既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在の
マネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
スクラムは、フレームワークであることを忘れないようにしたいです。PMBOKも同じくプロジェクトマネジメントのフレームワークであり、スクラムと対立するすものでは全くありません。この辺は、誤解が多いところです。
たとえば、ユーザーストリーもXPもスクラムを実践するためのプラクティスの一つです。”プロダクトバックログアイテム（PBI）は、ユーザーストーリー形式”という決まりはどこにもありません。
###・作成物の確約（コミットメント）の明示
確約（コミットメント）が登場しました。ゴールを定義することにより、プロダクトとチームが目指す方向（WHY）がより明確になると思います。
・**プロダクトゴール：**これは、以前より私が最重要だと思っていたことです。ゴールがないと検査、適応できないことは当然の話ですよね。私が執筆した社内の「アジャイルガイドライン（スクラム）」では100ページ中、50ページはスプリントが始まるまでのゴールと計画策定について解説しているくらい重要だと考えています。
上の図のように、どの港に向かっているかのゴールが明確になっていないといつまでたっても価値を生み出すことができません。プロダクトゴール自体も、常に最新の状況により更新されることはお忘れなく。
###・スクラムマスターとチームの役割の再定義
スクラムマスターの役割が、「サーバントリーダー」から「チーム・組織に奉仕する真のリーダー」というふうに表現が変わっています。これは、サーバントリーダーシップを発揮することで、チーム・組織に奉仕する真のリーダーとなる問うことだと思います。
要は、プロダクトの価値、プロジェクトの成功/失敗の責任はスクラムマスターにもありますよ。そのために、必死にスクラムチームを誘導してくださいね。ということだと考えています。
また、開発チームという言葉がなくなり、”チーム”は、PO、SM、開発者の３つの異なる責任を持ち、同じ目的を共有するひとつの「スクラムチーム」だけになりました。今まではスクラムチームと開発チームで不毛な定義議論を考えなくてよくなったのはうれしいことです。
#結論：今やっているクラムのやり方を変えろというものではない
自分たちのスクラムチームを新しいスクラムガイドで振り返ってみるとよいでしょう。新しいスクラムガイドでのふりかえりとアップデートをしてみたらよいと思います。
スクラムガイドが新しくなったから変えるというものではないです。あと、自分たちが*”スクラムあるある”*になっていないか？もう一度、胸に手を当てて振り返ってみましょう。
####あなたのチームは、”スクラム(アジャイル)あるある”とか”ゾンビアジャイル”になってませんか？
1. スクラムという開発方法論＝スクラムイベントがプロジェクト管理、形式的になっている
スクラムマスターがPMとして開発チームに指示出しをしていたり、スプリントバックログがワークパッケージになっていませんか？
そこまででなくても、プロセスに従うことにこだわっていませんか？
2. スクラムマスターがリリースされるプロダクト、インクリメントに対する責任を放棄
リリースされるプロダクトはプロダクトオーナーと開発チームの責任で、スクラムマスターの私には責任がない。ほんとでしょうか？
スクラムマスタのサーバントリーダーシップとは何でしょうか？
3. プロダクトオーナーと開発チームが交渉相手
プロダクトオーナーと開発チーム間の緊張が、けんか腰のやれ、やれないの交渉となっていませんか？
#スクラムガイドのポイント
最後に、この記事をご覧になっている方々は、スクラムの知識をお持ちの方が多いと思いますが、スクラムガイドのポイントをおさらいしておきます。
スクラムの定義
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織
が価値を生み出すための軽量級フレームワークである。
スクラムはソフトウェア開発手法ではありません！！ウォーターフォール型開発と比較することはナンセンスです。と声を大にして言いたいです。（いつも、言ってますけどｗ）
スクラムガイドをもとに、スクラムの構造を図示します。いちおう、いつもの絵です。
スプリントを通して、スクラムチームは価値のある有用なインクリメントを作成します。スクラムガイドでは、そのためのスクラムイベント、アーティファクト（作成物）が定められています。また、チームも開発者、プロダクトオーナー、スクラムマスターという３つの明確な責任が定義されています。
このフレームワークが機能するための**スクラムの理論（透明性、検査、適応）、価値基準（確約、集中、公開、尊敬、勇気）**が端的に解説されています。
今回のスクラムガイドの進化は？
今回の改定は、どのように・何を(How,What）を削いでより何のための理由（WHY）にフォーカスしたフレームワークとして改良されたものです。全体的には、”スクラム(アジャイル)あるある”とか”ゾンビアジャイル”にならないよう（誤解を排除するために）に、内容がより研ぎ澄まされたのだと思わないですか？
（参考）スクラムガイド2020のアップデートについて （Scrum Inc. Japanの記事）