スクラムガイド（2020年版）を読む
これは、とある企業でアジャイル実践者として立ち回っている一人の開発者がスクラムガイドを読んだ個人的な記録である。
とある企業では、「そのチームの取組の目的はフレームワークに依存するものではなく自分たちの内発的動機から生まれるものである」、という前提に立った形で「北極星」を定義していた。そして、その北極星を一つの価値基準においた上でアジャイルのプラクティスを基本を抑えて使いつつ、随時自分たちの中で得られたインサイトをオリジナルなプラクティスへの肉付けしてきた。それが、以下の記事で公開していた「BANK DEV白書」としてまとめられたものであった。
この取り組みを続けていく中で最近イテレーション運用に課題が生じてきた。随時レトロスペクティブで発生した課題やアイデアをパッチ当てすることで解消してきたが、一部スクラムのプラクティスと語彙を適用している世界線において、個人的な議題として「基本に立ち戻るべくではないか」と感じていた。
スクラムフレームワークをこれまで使用していない（正確にはスクラムをしていると宣言していない）状況だったが、むしろ基本に立ち戻る意味合いではスクラムのフレームワークを基礎的なプラクティス理解の土台とすることがチームにとって良き選択なのではないか、そう考えて本書を真面目に読み始める。
スクラムガイド
Ken Schwaber と Jeff Sutherland が、1995 年の OOPSLA カンファレンスにおいてスクラムを共同発表した。その後同氏が30年以上かけて開発・進化・保守しているスクラムを文書化したものとなっている。
スクラムとは
スクラムをスクラムガイドはこう定義する。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織 が価値を生み出すための軽量級フレームワークである。
そこで行われることはかんたんにまとめられると次の4stepだと述べる。
1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに 並べる。
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調 整する。
4. 繰り返す。
『Clean Agile』ではスクラムを、XPのプラクティスを図示したCircle Of Lifeの3つのリング「ビジネス・チーム・技術」の内、一番外側のビジネスのプラクティスに該当するフレームワークだと述べていた。なお本著の注意書きにある通り初期のスクラムについて言及しており、現在はXPのプラクティスの多くをスクラムが取り込んでいる。
実際、『エッセンシャルスクラム』で次のように述べられている通り、XPがリファクタリングやシンプルな設計をプラクティスに定義しているのに対して、スクラムは技術的プラクティスを正式に定義していない。
スクラムでは技術的プラクティスを正式には定義していないが、私の見る限り、うまくいっているスクラムチームはどこも何かの技術的プラクティスを採用している。シンプルな設計、テスト駆動開発、継続的インテグレーション、自動テスティング、リファクタリングなどといったものだ
Kenneth S. Rubin. エッセンシャル スクラム (Japanese Edition) (Kindle Locations 4055-4058). Kindle Edition.
あるいは、『More Effective Agile』ではこれからアジャイルを始める組織にはまずスクラムから始めて見ることを薦めている。
アジャイルをまだ実践していない、あるいは実践しているが思ったほど効果が出ていないという場合は、出発点に戻ることをお勧めする。アジャイルでは、スクラムから始めることを指す。スクラムはアジャイルアプローチの中でも最も規律的である。
Steve McConnell. More Effective Agile ソフトウェアリーダーになるための28の道標 (Japanese Edition) (Kindle Locations 914-916). Kindle Edition.
最低限アジャイルアプローチを規律よく保つ上でスクラムが軽量級フレームワークでありながら、不可欠な必要最小限を抑えていることがここでわかる。
ひとに説明するとき用に一枚でうまく説明した資料とか無いかなと見回ったらさすがryuzeeさんだった。
スクラムの経験主義とリーン思考
スクラムの理論的バックボーンとして経験主義とリーン思考が挙げられている。
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
キーワードはイテレーティブ（反復的）でインクリメンタル（漸進的）であることだ。
経験主義のスクラム三本柱
次の３つがあげられる。
透明性
創発的なプロセスや作業は、作業を実行する人とその作業を受け取る人に見える必要がある。 スクラムにおける重要な意思決定は、3 つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
検査
スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査されなければ ならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、 検査を支援するために、5 つのイベントでリズムを提供している。
適応
プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れら れなかったりしたときは、適用しているプロセスや製造している構成要素を調整する必要があ る。それ以上の逸脱を最小限に抑えるため、できるだけ早く調整しなければならない。
スクラムの価値基準
スクラムの成功は5つの価値基準の実践ができるかによる。
1. 確約（Commitment）: ゴールの達成、そのための相互サポートを確約
2. 集中（Focus）: ゴールに向けた可能な限りの進捗のため、スプリント作業に集中する
3. 公開（Openness）: 作業・課題を公開
4. 尊敬（Respect）:
5. 勇気（ Courage）
スクラムチーム
基本単位となるのがスクラムチームである。スクラムチームは、スクラムマスター1名、プロダクトオーナー1名、複数人の開発者で構成される。
実際は、特定の誰かというよりかはロール（役割）としてこの3種別があることが大事だという趣旨があると認識している。
そして、職能横断型であり、各スプリントで価値を生み出すために必要なすべてのスキルセットを備えていることが求められる。
通常は10人以下であるとされる。ryuzeeさんが最近スクラムチームの成熟度は？という翻訳記事を上げてらっしゃっていた。
自分が今どういう現状かは成熟度モデル的なもので検査すると面白いですね。
開発者
開発者はスクラムチームの一員。「開発している」ひとだけが開発者というわけではないことはスクラムガイド冒頭で述べられていることである。
スクラムでは「開発者」という言葉を使ってい るが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。スク ラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。
開発者は次の結果に責任を持つことを求められている
1. スプリントの計画（スプリントバックログ）を作成する。
2. 完成の定義を忠実に守ることにより品質を作り込む。
3. スプリントゴールに向けて毎日計画を適応させる。
4. 専門家としてお互いに責任を持つ。
プロダクトオーナー
プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。しかし、その方法は組織・スクラムチーム・個人によって、さまざまであると述べられる。
たとえば、プロダクトゴールの策定・バックログアイテムの作成・並び替え・見える化をするといったバックログアイテム管理が挙げられるが、別に本人がやってもいいし、他の人に委任しても良いとされる。しかし、効果的なバックログアイテムの管理への責任はプロダクトオーナーで持つことになる。
スクラムマスター
スクラムマスターの責務は次のようなものだ。
スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクスを全員に理解してもらえるよう支援することで、その責任を果たす。
プロダクトオーナーはわりと固定的な役割になりうるが、スクラムマスターはローテーションしている事例もいくつかある。
この記事でいうローテーションは複数チームのスクラムマスターを兼務する場合に、当スプリントはAチーム、来スプリントはBチームといったような形で様々なチームのスクラムマスターをローテで経験することを推奨している内容だ。
スクラムチーム内でスクラムマスターをローテーションするという話には“We rotate the Scrum Master role every Sprint”にて警鐘が鳴らされている。日本語での解説・要約には以下のブログエントリーがわかりやすい
当然のことながら、スクラムマスターは誰でも簡単にすぐできる役割ではなく、「メンバ全員スクラムマスター経験者」とかで無い限り、スクラムマスターのローテーションはできません。
なお、スクラムマスターは次の動画が楽しい。
スクラムイベント
スプリントはアジャイルにおけるタイムボックス/イテレーションの呼び名でもあるが、すべてのイベントの入れ物としての概念である。規定通り運用することで透明性が実現されることを狙って設計されたものである。
面白い表現だと思ったのが以下だった。
スクラムにおけるイベントは、規則性を生み、スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる。
スクラムイベントによって、それ以外の会議を最小限に抑える。これは結果的に作業に集中つながるのだろうが、会の増減で結果的にマイナスになることで作業の集中時間が増えるという捉え方が出来ると解釈できるか。
スプリント
スプリントは1ヶ月以内の決まった長さとすることが求められる。とある所属チームではもともと1week iterationにしていたが、最近2 week iterationに変更していた。
- スプリントゴールの達成を危険にさらすような変更はしない。
- 品質を低下させない。
- プロダクトバックログを必要に応じてリファインメントする。
- 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。
スプリントプランニング
スプリントの起点となる。ここでスプリントで実行する作業計画を立てる。スクラムチーム全体の共同作業によってこれは作成される。
スプリントプランニングでは3つのトピックが話される。
1. このスプリントはなぜ価値があるのか
2. このスプリントで何が出来るのか
3. 選択した作業をどのように成し遂げるのか
1でやることはこうだ。
プロダクトオーナーは、プロダクトの価値と有用性を今回のスプリントでどのように高めるこ とができるかを提案する。次に、スクラムチーム全体が協力して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。
そして、2ではプロダクトバックログからアイテムを選択し、今回のスプリントに含めていく。このイベントの中でプロダクトバックログアイテムのリファインメントを行うことで、チームの理解と自信が高まることに繋がる。
3では、プロダクトバックログアイテムごとの完成の定義を満たすインクリメンタルを作成するために必要な作業を計画する。ここでは1日以内の小さな作業アイテムに分解することによって行われるがこれは開発者の裁量によって行われる。
スプリントゴール、スプリント向けに選択したバックログアイテム、それらを提供する計画をまとめてスプリントバックログと呼ぶ。
スプリントレビュー
目的は、スプリントの成果を検査、今後の適用を決定することにある。
主要なステークホルダーに作業の結果を提示、プロダクトゴールに対する進捗を話し合う場となる。
スプリントで達成したことと変化したことに応じて、スプリントレビュー参加者にて次にやるべきことに取り組む。プロダクトバックログの調整が行われることもある。
とある弊チームではステークホルダーの方々がアジャイル慣れしているわけではないので、「お見立て会」などと違う言葉を使っていたりする。スプリントレビューにおけるゴールが語彙を変えることで若干見えにくくなるリスクも有るのでコレは悩みどころではある。スクラム慣れしているひとであれば「わざわざ違う言葉で呼んでいるということは違う意味があるのかな？」と思うだろうし、そうじゃない人であればググっても出てこないけどどういう会なのかな〜となるかもしれない。個人的にはアジャイル用語の各自の認識の違いで変な混乱が生まれることを嫌うが、それでもスプリントレビューに対する認識の齟齬はそこまで生まれないのでわざわざ別の用語で呼ばなくても良いかもねぇと思っていたりする。しかし、チームメンバーの口馴染みとしては「お見立て会」が馴染んでいるし、そのニュアンスから完成したプロダクトを見せることに主眼があることが伝わりやすいメリットも有る。短しい期間で透明性のある動くプロダクトが出来るサイクルをそこまで作れているか微妙な側面が現状があるのであれば「プレゼンテーションをする」というニュアンスを全面に押し出した命名aliasを作っても良いのかもしれない。
スプリントレトロスペクティブ
スプリントレトロスペクティブの定義はこうだ。
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。 スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリ ントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。
とある弊チームではMad Glad Sadを試したシーンが有ったが、そういった様々振り返りワークが活用されるイベントである。
スクラムの成果物のコミットメント
スクラムの成果物には透明性と集中を高める情報を提供する「確約（コミットメント）」が含まれる
1. プロダクトバックログのためのプロダクトゴール
2. スプリントバックログのためのスプリントゴール
3. インクリメントのための完成の定義
1はプロダクトバックログに関連する。
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一 覧である。これは、スクラムチームが行う作業の唯一の情報源である。
スクラムチームはバックログリファインメントの際により小さく詳細になるように分割・定義していく作業を行う。
分割については次の記事が参考情報としてインターネットに放流されている。
プロダクトゴールはスクラムチームの長期的な目標となるものである。プロダクトの将来的な状態を表している。とある弊チームでは数イテレーションまたぐような開発プロジェクトごとにプロダクトマネージャーが「神ドキュメント」と呼んでいるプロジェクトの意義や要件のマスター資料を作成している。プロダクトゴールの具現化した形と呼べるかもしれない。2020年版のスクラムガイドで導入された概念となっている。
2および3はスプリントバックログである。スプリントバックログは開発者による開発者のための計画であると表現している。
スプリントゴールは、スプリントの唯一の目的であるとしている。スプリントゴールは開発者が確約するものになる。開発者のスプリント作業において念頭に置かれるものであり、作業が予想と異なる場合に発生する調整はスプリントゴールに影響を与えることがない用に行われる。
インクリメントは、プロダクトゴールに向けた具体的な踏み石と表現されている。複数のインクリメントスプリントレビューで提示する。スプリントレビューがリリースの関門というわけではないためスプリントレビューがスプリントの最後ではなく途中に行われることもある。『エッセンシャルスクラム』では出荷判断可能なプロダクトとあるが、他の言葉で言い換えれば技術的にはデプロイ可能なシステムとも表現できる理解である。そのためにインクリメントはコミットメントとして「完成の定義」があり完成の定義を満たしている場合は、ビジネス的な出荷判断に委ねてリリース可能と捉えられる。
各イテレーションの最後に、チームは出荷判断可能なプロダクト（もしくはプロダクトのインクリメント）を作り出さなければならない。これは条件を満たせばリリースできるプロダクトのことだ。
Kenneth S. Rubin. エッセンシャル スクラム (Japanese Edition) (Kindle Locations 1000-1001). Kindle Edition.
ユーザーストーリーベースの見積もりをする場合には、ユーザーストーリー単位での見積もり対象を完成させることでインクリメントが生まれると考えると、結果的にインクリメントの完成条件はユーザーストーリーの完成条件となる理解をしており、そのためにユーザーストーリの良き完成条件についてあれこれ考えている昨今でATDDの話などが関連していたりする。
完成の定義
プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述を「完成の定義」と呼ぶ。完成の定義があることによって透明性が生み出される。完成の定義を満たしていない場合はリリースすることができずスプリントレビューでも提示できないものとなる。
これらにの確約をもう一度整理すると、
プロダクトバックログ = プロダクトゴール
スプリントバックログ = スプリントゴール
インクリメント = 完成の定義
となっている。
エンドロール
ボリュームとしては非常に小さい。しかし、抽出された文章のため経験の有無や考察の深さによって感じられる奥行きが違うのだろう。私が感じられた奥行きはこの書評にあるくらいである。また、ネクストバージョンが出た際にどういうふうに感じられるか、さらなる奥行きを感じられるか、将来の自分に期待して締めとしたい。
この記事が気に入ったらサポートをしてみませんか？