スクラム開発について学ぶにあたって、薦められた本だったので読んだ。

スクラムの基本的な知識と、具体的な課題を1つひとつ乗り越えていく様子を、プラクティスとして学ぶことができる。マンガ形式なのが分かりやすかったが、読み返しながら読んでいたので時間がかかってしまった。

※スクラムについてはこの本を読み返す、または、スクラムガイドを参照するとして割愛する。

この本を読んでアクションしたこと

1.プロダクトバックログのリファインメントのイベントを増やした
期間を空けてしまうと忘れてしまったり、すぐに情報が更新されたりと、手入れをしてあげないといけない。リファインメントは週にn時間とかだったので、毎日朝会で強制的にやるようにしたら、優先順も分かるし、プロジェクトの見通しも良くなってきたので続けたい。

2.仕様についてのヒアリング・ペーパープロトタイピングを頻繁にやるようにした
仕様なんて曖昧なまま進めていいんじゃね？みたいな考えが甘かった。
スクラムとはいえ、手戻りがあったり、手が止まってしまっては時間（お金）の無駄になってしまう。本にはこう書いてある。

- 実現したことは先に深く理解しておく
- 決めるべき仕様は決めておく
- 技術的にどういうふうに実現するといいかを確認しておく

スクラム開発に関係なく、当たり前なことが分かっていなかったんだと思う。。
開発チームが作業に集中できるように、具体的に何を作るか示してあげないといけない。毎スプリント、こまめに仕様を決めていくのは大変だけど、手戻りの少ない方法なんだと実感した。

印象に残ったこと

1.見積もりは時間をかけず、素早くやること

あいまいなことを確実にしようとして膨大な時間を費やしても、確実なものにはならない。素早く見積もって、自分たちの推測を実際に試してみて確実なものにしていく。Scrumでは、推測に時間を費やすことよりも確実なものにすることのほうに時間を使うんだ。そのためにも、見積りは素早くやろう。

どうしても開発プロジェクトの場合は、タスクを細かく見積もりたくなる。だけど、これはスクラムの本質ではない。要は実績を積んで、その経験・学びから自分たちの見積もり精度を上げていけば良い。

2.スクラムの本質は、学びの仕組みであること

今まで知らなかったことを体験しながら学んでいける。それをくりかえしながら、スクラムチームは成長していく。

↑の1.で書いたことに対して、更に納得した。不確実なことはどうしようもないので、今までの経験や・誰かの助けを借りてやってみるしかない。
失敗しても、同じ失敗をしなければ、それでチームは成長したことになる。
さらに、こう書いてある。

私たちは、Scrumの本質は、こうした学びの仕組みだと考えている。そしてこれが、私たちがScrumを好きな理由だ。みんなに喜んでもらえるようなプロダクトをつくるのは簡単じゃない。いろんな知識やスキルが必要だったりする。けれど、それはものすごいスキルを持った人だけの特権じゃない。平凡なスキルしかない私たちにだって、学び続けていけば、いつか自分たちの代表作だと胸を張れるものがつくれるんだ。

学びがあるっていうのは、次へのモチベーションにもなるし、それを他人と共有できればそれば、何倍にもなる。

課題に思っていること

1.レトロスペクティブの改善
著者の意図もあってレトロスペクティブ（振り返り）については、詳しく記述されていない。改善のための振り返りなので、効果をもっと高めるために別の本を読んで勉強しようと思う。

2.ユーザーストーリーの作り方
未だに、開発工程別になってしまったり、サブタスクみたいな作り方をしてしまう。これじゃあスプリントレビューがちゃんと機能しないわけだ。
詳しくは書けないけど、（何回か聞いてるけど）色々先輩SMに相談してみようと思う。

まとめ

スクラムマスターを始めたとき、何をして良いかよく分からず悩んでいた。
とりあえず、ファシリテートして、見積もり手伝って、教科書通りにやろうと必死だった。今はようやく慣れて、身体に染み付いてきた気がするので、ノウハウを学びつつ、チームの課題解決に全力を注いでいきたい。