スクラムガイド2017→2020のまとめ

はじめに

NTTレゾナントテクノロジー アジャイルデザイン部 の藤井です。
2020年11月にスクラムガイドが更新されました(前版は2017年版)。
内容の大筋はぶれていませんが、世界中のスクラム導入事例を踏まえて、表現方法が一新されたようです。本記事では、修正箇所を確認しつつ、背景を考察(？)していきます。

参考：スクラムガイド2020
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

スクラムの理論（３本柱）

「Transparency（透明性）」「Inspection（検査）」「Adaptation（適応）」という３本柱に変更はありませんが、「結果責任を持つ者」「検査担当者」といった役割を限定するような表現が削除され、「誰が」の部分が拡大解釈できるような表現に変わっています。
スクラム開発は、開発プロセスがうまく回り出すと組織の壁(ルール、慣例)にぶつかることも多いため、スクラムチームのメンバーだけでなく、組織全体で理解を深めていく必要があるということでしょう。

スクラムチーム

プロダクトオーナー(以下、PO)、スクラムマスター(以下、SM)の人数が各１名と明言され、開発チームは「複数の開発者」という表現に変更になりました。また、「自己組織化」という表現が削除され、スクラムチームが「自己管理型」であるべきとされました。
これは開発チームのサイロ化やスクラムチーム内の対立(PO vs 開発チーム、SM vs 開発チーム、PO vs SM)といったアンチパターンの事例が多く報告されたことが伺えます。スクラムチーム(≠開発チーム)が成果を出すために、一人一人が責任感と意思を持ち、"協力しながら"各役割をこなすことが求められるようになったのだと考えています。また、各役割でなすべきことについても垣根が低くなり、より協力を促す表現に変わった印象があります。

スクラムイベント

形骸化しやすいイベントについては、念を押すような言い回しが入りました。特に、スプリントレビューについては「プレゼンテーションの場ではなく、ワーキングセッションの場である」と明記されています。スクラムのイベントは規定されているからやるのではなく、イベントの設定されている目的を理解して臨むことが大切です。(イベントを行うことが目的になってしまっている事例は良く見聞きします)

スクラムの作成物

各アイテムに対し、ゴール、もしくは完成の定義なるものへの確約(コミットメント)が求められるようになりました。それぞれ以下のようなイメージを持っています。

プロダクトゴール
長期的なプロダクトの目標。半年～１年程度で設定する。インセプションデッキで設定したプロダクトの目的や方向性に沿ったものにする。（評価方法は現時点では考えどころ）
例：基本機能（ダウンロード、閲覧、入会、課金）が揃った状態でアプリを公開する

スプリントゴール
スプリント完了時に達成すべきこと。インクリメントを開発した時にどのような状態になっているのか（ユーザにどのような価値を提供するか）を定義する。評価はスプリントプランニングで計画した作業を完了し、スプリントレビューにインクリメントを提供できたかどうか。
例：ダウンロードしたものが一覧で確認できる、ｖX.X.Xとしてアプリをリリース可能にする

完成の定義
開発アイテムに対し、どのような状態になればそのアイテムが「完成」したと見なすかを定めた判断基準（≒品質基準）。プロダクトの性質によって、粒度は調整する。結果については、スクラムチームで責任を持つ。
例：コードレビュー、静的解析、自動テストのエラーが取り除かれている、開発者による機能試験が完了している

さいごに

序文に そのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を生み出すかどうかを判断してほしい。 あとがきに スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。 という記載があり、スクラムガイドの解釈を誤って失敗した事例や最初からアレンジした形で始めて失敗する事例(所謂、"なんちゃって"スクラム)が多かったことが伺えますが、もともとガイドに従ってスクラム開発ができているチームにとっては、大きな影響を与える変更はほぼなかったように思えます。(プロダクトゴールくらいでしょうか）
もし、現状うまくいっていないというプロダクトがあれば今一度基本に立ち返るのが良いかもしれません。