スクラムガイド2017年版
スクラムの原典である「スクラムガイド」。
最近、Unlearn（学びほぐし）のためにチームでスクラムガイドをモブリーディングしています。昔読んだことがあっても、改訂されて内容がアップデートされていたり、経験に合わせて読む度に違う気づきがあるのでけっこう面白いです。
-
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
scrumguides.org
ちなみにこんなこともやってみました。
「スクラムガイド」モブリーディングとは
文字通りチームで「スクラムガイド」を読むだけです。
個々に読むのもいいですが、ふだん働いているチームで雑談しながら読み合わせをしたかったので、モビングスタイルで読みました。全員で同じ画面を見ながら輪読し、気になったところや分かりづらいところは「ああでもない」「こうでもない」と議論をしながら読み進めていきます。
スクラムガイドはとても短くまとまっているところが素晴らしいです。どれだけじっくり読むかによりますが、そこそこ議論をしながらすべて読み合わせをするのに、2回に分けて合計2時間程度で終わりました。見積もりのご参考までに。
モビングについて学びだければ、こんな素晴らしい本が出たそうですよ！
「スクラムガイド」で面白かったところ
今回モブリーディングをして、改めて面白かったところをご紹介します。
スクラムの定義
スクラムとは、以下のようなものである。
スクラムガイド2017年版 - スクラムの定義
• 軽量
• 理解が容易
• 習得は困難
え、ほんとに！？
なんとなく反対の印象だなー。
スクラムの理論
透明性
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。
透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
スクラムガイド2017年版 - スクラムの理論
結果責任を持つ者＝チームなんだろうな。
改めてスクラムガイドを読むと、透明性についてうるさいくらいに言及されているんだなって気づいた。スクラムガイドの中で「透明」という単語は22回出てくる。
スクラムチーム
プロダクトオーナーは 1 人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。
スクラムガイド2017年版 - プロダクトオーナー
プロダクトオーナーは1人の人間だって明確に言っているのが面白い。
開発チームには、以下のような特徴がある。
スクラムガイド2017年版 - 開発チーム
• 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
• 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
• ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。
• テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。
• 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。
スクラムでは、肩書きやサブチームは存在しない。そして、インクリメントを作成するスキルをチームとしてすべて備えているということなので、「アプリチーム」「テストチーム」「インフラチーム」みたいな分け方をしないってことが明記されているんだね。
• スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。
スクラムガイド2017年版 - スクラムマスター
2017年版で追記された項目。スクラムチームの全員（開発チームもPOもSMも）が可能な限り理解している、そうじゃなくても理解しようとしていたいよね。
デイリースクラム
デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。
スクラムガイド2017年版 - デイリースクラム
そうそう、開発チームのための時間なんだよねー。
スプリントレビュー
スプリントレビューには、以下の要素が含まれる。
スクラムガイド2017年版 - スプリントレビュー
• 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
• プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。
• 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを議論する。
• 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
• プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在の進捗から、可能性のある目標とデリバリーの日程を予測する。
• グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。
• 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性をレビューする。
• 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。
スプリントレビューってレビュワーとレビュイーみたいにくっきり分かれている場ではなくて、スクラムチーム全員で自分たちがやった最＆高の仕事を誇る場なんだなー！
スプリントレトロスペクティブ
スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう
スクラムガイド2017年版 - スプリントレトロスペクティブ
ちなみに英語だと「make it more effective and enjoyable for the next Sprint」
スクラムガイドに「楽しい」という言葉が入っていることにはじめて気づいた！
プロダクトバックログ
プロダクトが存在する限り、プロダクトバックログも存在し続けるのである
スクラムガイド2017年版 - プロダクトバックログ
なんかかっこいい！！
スプリントバックログ
継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく
スクラムガイド2017年度版 - スプリントバックログ
ここは2017年度版で追記された部分で、スプリントバックログに改善アクションを「少なくとも」1つ入れることが明記されている。
スクラムはプロダクトだけでなくチームや作業環境を継続的に改善していくことを謳っているので、ただプロダクトバックログを消化しているだけにならないように明記したのかな。「スプリントバックログは開発チームのもの」なので、チームが裁量をもって取り組むものだよってメッセージも感じる。
作成物の透明性
スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違いを把握することで、不完全な透明性を検知できる。
スクラムガイド2017年度版 - 作成物の透明性
スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。
ほー！
透明性は一夜にしてならず。透明性とは長い道のりなのである。
スクラムガイド2017年度版 - 作成物の透明性
かっこいい！！
最後に
スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・イベント・作成物・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。
スクラムガイド2017年度版 - 最後に
そうなんだー。
これに則って考えると、「自分たちはスクラムをやっている」と言える人はかなり少なそう。
スクラムガイド 2016 年版と 2017 年版の変更点
変更点を見ていると、
- スクラムがどう変化しているのか
- みんなが困りやすい点がどこなのか
とかそういうコンテキストを想像できて楽しいです。
感想
スクラムってめんどくさい。
すごくいいこと書いてあるし、たくさん学ばせてもらっているけれど、「こうしないとダメだ」「これがないとスクラムではない」みたいな説明はあんまり好きじゃないなーって個人的には思いました。
モブリーディングのススメ
個人で読んでいるときは流して読んでいるところも、チームで読むことで新たな気づきをたくさん得られて面白かったです。チームでは、スクラムガイド以外に公開されているスライドや技術要素の公式ドキュメントをモブリーディングしています。
同じものを読んでも、誰と読むかで得られる学びがぜんぜん違うし、少し経験を積んでからまた読んでも視点が変わっているから学びがあると感じました。
スクラムガイドは、実践者や色んな人がモブリーディングをしながら議論をしているのを、遠巻きに眺める場とか面白そうだと思いました。
面白そうだと思ったら、ぜひやってみてください！
