2020年度版スクラムガイドまとめ
📆05/04/2021🔖 開発
スクラムガイドが2020/11/19にアップデートされたので読んでみた。 前回のスクラムガイドは2017年なので3年ぶりの改訂。
TL;DR(結論)
概要
→ スクラムガイドはこちら(https://scruminc.jp/blog/2885)
上記の記事によると、今までのスクラムにおいては、
という大きく２つの課題感があった。
そのため、今回2020年度版で2017年度版から以下3点が主にアップデートされた。
また全体的にHowや方法論的な部分の分量を減らして、Whyにより焦点を当てた。
前提
アジャイル開発とは？
そもそもアジャイル開発とはそもそも色んな開発手法からいくつかの共通項を抜き出してまとめた概念であるので、アジャイル開発手法という物がカチッと決まっているわけではない。 共通性として以下4つの価値がありそれに即して現場で実践が求められる
- プロセスやツールよりも個人と対話を - 包括的なドキュメントよりも動くソフトウェアを - 契約交渉よりも顧客との協調を - 計画に従うことよりも変化への対応を、
そしてその4つの価値の背後には以下の12の原則がある。
- プロセスやツールよりも個人と対話を - 包括的なドキュメントよりも動くソフトウェアを - 契約交渉よりも顧客との協調を - 計画に従うことよりも変化への対応を、
〈働き方〉 - ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 - 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 - 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
〈持続可能性〉 - 動くソフトウェアこそが進捗の最も重要な尺度です。 - アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
〈持続可能性〉 - 動くソフトウェアこそが進捗の最も重要な尺度です。 - アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
〈設計〉 - 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます - シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 - 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 - チームがもっと効率を高めることができるかを定期的に振り返り、それにもとづいて自分たちのやり方を最適に調整します。
そしてこうした原則をどう実践するのかが、現場で行われているスクラムであり, スクラムガイドはそのスクラムについて簡潔にまとめたガイドをさす。
アジャイルソフトウェア開発宣言について詳しくは →アジャイルソフトウェア開発宣言の 読みとき方（https://www.ipa.go.jp/files/000065601.pdf ）を参考のこと。
スクラムとは？
スクラムとはアジャイルをベースに様々なプロセスやプラクティスを取り入れたフレームワークをさす。
そしてこれがスクラムだ！と上から降りてくるものと言うよりは、やってみてわかったことから、次にやるべきことや試すべきことを自分たちの活動に組み込んでいくという経験主義的な考え方を重視している。他の現場やチームで発見されたプラクティスを導入すればいいというわけではない。
フレームワーク自体は3つのロール、４つのスクラムイベント、３つの作成物で構成されている。
スクラムガイドにはスクラムとは上にあげたすべてを備えたものであり、その他の技法・方法論・プラクティスの入れ物として機能するものだと記載されている。
参考 スクラムの原則を、いかにして実践するか （https://eh-career.com/engineerhub/entry/2020/05/12/103000）
大きく改定されたところ
Whyに立ちかえる
スクラム開発を導入しつつも、計画と実行が完全に分離されてしまって、なんでこの作業やっているのかよくわからないよね、、という状態のままスプリントが進んでいくことがある。 このように開発者が、POの人が整理したバックログをただこなす作業者になってしまう状態は望ましくない。逆にPOの人もただバックログを整理するだけの雑用という意識を持つのも避けていきたい。
そうしたふわっと進んでいく状態から、Whyに立ち返り、後から見直せるように一定の論拠に基づいて判断を選択していける状態へと持っていく必要がある。
他にもよくあるアンチパターンとしては、
探索的にわからないからとりあえず進めるというやり方だと、検証が難しくなる。 自分たちの現在位置を把握せず、何がわかって何がわからないまま進めても、一貫した基準を持って現時点をふまえて進めたりしていかなくては、自分たちがやっていることを後で評価したりすることが難しくなる。
わからないから教科書通りに進めていっても何を目的に進めたのかという部分が定まっていなければ後ほど検証活動を行って精査することができず、積み上げが生まれにくくなる。
思っていたのとなんか違うなという気持ちを握りつぶさないでいくことが大切で、スプリント自体を振り返る時間をイベントとして想定する等の対応が必要になってくる。
自己管理化されたチームを追求する
自己組織化から自己管理化へ、チームの壁をこえてWhy/What/Howをチーム全体で考えられるように
開発チームの自己組織化からスクラムチームの自己管理化へとは何か？
自己組織化とはこれまでのスクラムでよく使われてきたキーワードだが、how（どうやって進めるか）の部分を開発チームが担うという意味に捉えられがちだった。あくまで手法だけの主導権を取っているだけで、開発部がWhy/Whatまで考え切れていないのではないかという問題もあった。
この問題を解決するために、チームにより適切な権限を与え、Why/What/Howを自分たちで決めるんだという意識を持たせようと、自己組織化から自己管理化へというキーワードに変更された。
また今回スクラムマスターの役割が、サーバントリーダー→ 真のリーダーに変更された。これはスクラムマスターがサーバントとしてあれやこれや先回りしてやっちゃうのではなく、リーダーという立場にあるだけで誰が動いてもいいということを強調する意図が込められている。スクラムガイドによれば、真のリーダーの意味はサーバントリーダーと同じであるがサーバントに囚われすぎないようにという意図を込めて今回変更された。
どちらの言葉の変更も、作業人になりすぎず、目的に立ち返られれるような意識作りの意図が込められている。
こうした言葉の背景にあるのは仕事が作業化してしまったたり、チームが役割で分業化していって分断されることへの問題であり、
というようなことがよくおこりうる。
という体制を作っていくことが大事である。
ただ分業化してじっくり取り組む方が向いているようなものの時はあえて難易度の高いスクラム開発で取り組む必要はないかもしれない。 スクラム開発は不確実性の高い新規開発を共同で取り組む時に適したフレームワークであるので、そういった仮説検証を回す必要性があるようなときは職能や立場を超えて一緒に考えて模索していける体制を作るべきである。
役割が固定化されないためにも問いを投げかけてチームのメンバーが考えるような機会を作っていくのも大事な役割になってくる。