スクラムガイド2020を旧版と比較してみる
スクラムに関心を抱いている人たちにとって、今年最大となるかもしれないビッグニュースが訪れた。そう、スクラムガイドの改訂だ。
これに際し新版スクラムガイドの感想を語り合う社内イベントを主催することになったが、上記の記事を読んだだけではざっくりとした変更点しか見えてこない。
百戦錬磨のスクラムマスターたちが今何を感じているのか。その胸の内が知りたくて、ふりかえり実践会による「スクラムガイド2020を読み解いてみよう」というイベントに参加した。
イベントの中で何が語られたかについては、この記事の最後にイベントレポートのリンクを貼るのでそちらを参照いただきたい。
(レポートを書いてくださった方に感謝。)
その道のベテランが集っていただけに議論のレベルが高く、残念ながらひよっこの自分は話の内容についていくのがやっとだった。
後半に「スクラムガイドは ガイドブックであってルールブックではない ので、これを絶対視しないでほしい」といった旨の話があったため若干ためらったが、今の自分が2017年版と読み比べてどのように解釈したか書き留めることはきっと意義のあることと信じ、今回このような記事を書くに至った。
Twitterで背中を押してくれたフォロワーさんには感謝している。
前提
一応、これを書いている私の背景について。
・QAエンジニアに転身して1年半になる、元ソフトウェアエンジニア(SWE)。
・SWE時代はウォーターフォール開発。アジャイルやスクラムへの憧れがあったので入門書を少し読んでいた。
・この半年間、QAとして2つのスクラムチームに所属。実務でのスクラムはこれが初めてとなる。
というわけで、私はスクラムの世界では素人の部類に入るだろう。
ベテランの方々から見たら誤った解釈をしているかもしれないが、ご容赦いただきたい。
「過干渉な母親」から脱却したスクラムマスター
まずひときわ話題を呼んだのは、こちらの記述ではないだろうか。
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。
(2020版、p.8 「スクラムマスター」より)
2017版にあった「サーバントリーダー」から大きく飛躍している。
スクラムマスターは、スクラムチームのサーバントリーダーである(訳注:メンバーが成果を上げるた めに支援や奉仕をするリーダーのこと)。
(2017版、p.7「スクラムマスター」より)
『SCRUMMASTER THE BOOK』を読んだ後に2017版を読むと、スクラムマスターがあれこれ手を焼いている様子が伺えるだろう。
スクラムマスターは、スクラムチームとやり取りをするとき に役に立つこと/立たないことをスクラムチームの外部の人たちに理解してもらう。
(2017版、p.7「スクラムマスター」より)
価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。
(2017版、p.7「スクラムマスターはプロダクトオーナーを支援する」より)
スクラムマスターは、 参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。
(2017版、p.9「スプリントプランニング」より)
スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。
(2017版、p.11「デイリースクラム」より)
デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、 開発チームの邪魔にならないようにスクラムマスターが配慮する。
(2017版、p.11「デイリースクラム」より)
スクラムマスターはスプリントレビューが確実に開催されるようにして、参加者には目的を理解してもらうようにする。スクラムマスターは関係者全員 にタイムボックスを守るように伝える。
(2017版、p.11「スプリントレビュー」より)
スクラムマスターは、 このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。
スクラムマスターは、このミーティングがポジティブで生産的になるようにする。スクラムマスターは、 全員にタイムボックスを守るように伝える。
(2017版、p.12「スプリントレトロスペクティブ」より)
スクラムマスターは、次のスプリントが効果的で楽しいものになるように、スクラムチームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。
(2017版、p.12「スプリントレトロスペクティブ」より)
不完全な透明性に対処するには、いくつかのプラクティスが存在する。スクラムマスターは、そのなかから最適なプラクティスを選択してもらえるように支援する。
(2017版、p.14「作成物の透明性」より)
どうだろう、『SCRUMMASTER〜』で言うところの「過干渉な母親」像が浮かばないだろうか。
2020版ではスクラムマスターの振る舞いへの言及が少ない。
スクラムのプラクティスはスクラムマスターだけでなくチーム全員で理解してほしい、そしてスクラムマスターにはチームを越えた偉大なるマスターとしての役目を果たしてほしいといった期待がここに込められているのだろう。
タイムボックスにこだわらない
2017版にあったこちらの記述は、2020版では削除されている。
すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。 スプリントを開始すると、その期間は固定され、増減することはできない。
(2017版、p.8「スクラムイベント」より)
アップデートの目的である「より指示的な記述を少なく」という方針にそったからとも読めるが、これに関してはタイムボックスに懐疑的な意見があったからではないかと推察している。
メンバーの専門性を尊重する傾向へ
「チームはより一丸となって成果にコミット」という方針でアップデートされた2020版。その意図が伺える記述がいくつかある。
スクラムチーム内 には、サブチームや階層は存在しない。これは、一度にひとつの目的(プロダクトゴール)に 集中している専門家が集まった単位である。
(2020版、p.6 「スクラムチーム」より)
開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。
(中略)
・専門家としてお互いに責任を持つ。
(2020版、p.7 「開発者」より)
「専門家」というワードがここで出されるようになったのが個人的には印象的だった。ソフトウェアエンジニア以外のチームでもスクラムが適用されるようになったという背景もあるだろうが、スクラムチームのメンバーは機能横断的であらねばならないという縛りからの開放と、メンバー各自のスペシャリスト性を尊重する意図も感じる。
それを踏まえて2017版を読むと、「チーム以外に頼らずに」など必要なリソースを囲い込みたいようにも見え、チームが孤立化しかねない危うさがある。
機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。
(2017版、p.5「スクラムチーム」より)
・テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。
(2017版、p.6「開発チーム」より)
「コラボレーション」という言葉も2020版から登場したものだ。
スクラムチームの外側にいる人たちの見解も積極的に取り入れていくべきだという姿勢の変化がそこにはあったのかもしれない。
品質はスクラムの中で守る
さて、私たちQAエンジニアとスクラムとの関わりはどのように変化しただろうか。
構成員のひとつ、「開発チーム」が「開発者」へと変化したことでそれが指すロールの幅が広がったという見方がある。前述の専門家のくだりからも、QAエンジニアが開発者の範疇に収まったと読めるだろう。
また、2017版では品質保証をスクラムの外側に置いていたとも読める以下の記述が2020版で修正されているのも面白い。
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。
(2017版、p.4「適応」より)
↓
プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要がある。
(2020版、p.5「適応」より)
主語を削除したことにより、受け入れ判定がスクラムチームに委ねられるようになった。
インクリメントは、完成していて、検査可能なものであり、スプリントの終 了時の経験主義を支援するものである。
(2017版、p.14「インクリメント」より)
↓
すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。
(2020版、p.14「インクリメント」より)
またこちらについては、検証のタイミングがスプリント終了後からスプリント終了前にシフトしていると読めないだろうか。
QAエンジニアをスクラムチームのメンバーに加えるべきか(あるいはQAエンジニア不要のチームを目指すのか)、テストをどのようにスプリントの流れに組み込んでいくかについては意見が分かれるところである。
それが今回のガイド改訂によって、スクラムチームの中で品質を担保していくという考えがより一層メジャーとなるだろう。
少なくともこれからのQAエンジニアは、スクラムのプラクティスとは無関係でいられなくなりそうだ。