最近はゼルダにハマりながらも子供とともに夜10時に寝ることの多いid:d-haru です。
チームのスクラムマスターとして独り立ちしてもうすぐ1ヶ月が経とうとしています。今回認定スクラムマスター研修を受講し、晴れて認定スクラムマスターになることができました。
正直に言うと、すでにある程度スクラム開発を経験していたのと、実際に研修を受講した方やスクラムに詳しい方とお話する機会も多く、ここでどのぐらい学びとれるかいささか不安もありましたが、思いの外気づきもありました。
わたしとスクラム
スクラム開発そのものは本格的には今の会社に入社してから経験してスクラム歴半年と少しという状態でした。その前にもウォータフォール開発、アジャイル開発もどき?の経験はありました。
直近ではチームのスクラムマスターを引き継ぐ形となり、自分なりに役割や改善方法を模索している毎日です。
今回の研修は agilergo のJames Coplienさんが講師でした。
https://www.jp.agilergo.com/online-csm-coplien-202306www.jp.agilergo.com
オンラインの受講で、ワークなどはどうしてもやりづらさもありましたが話に集中してメモを取りつつ質問しながら参加するような形でした。
認定スクラムマスター研修の学びと気づき
メモを振り返りつつ気になったところとかを振り返っていきます。
スクラムのルーツがそもそも製造業から、というのはなんとなくは聞いたことがありましたが、思いの外トヨタ生産方式の具体的な話（アンドンやカンバンなど）がでてきて驚きつつも懐かしんでいました。（かつて製造業で働いた）
正しいプロセスを作ることで正しいものができる
これも元々製造業由来の考えだと思います。自分はプロダクトの開発とソフトウェア開発は似て非なるものと思っているので製造業を単純に真似るだけではうまく行かないというのは身にしみて感じていたので、最初は懐疑的なところありました。
ただ、不確実性が高いからこそ絶対の正解はなく、正解を探すというアプローチであるという話があり、これは納得感がありました。
月曜にやることは、マネージャーを廃止することだ
ただの感想ですが、これめちゃくちゃ何回も言っていて面白かったです。マネージャー不要論について語るとそれだけとずっと書いていそうですが、スクラムにおいては不要であるというのはその通りだと思いました。
スプリントプランニングでは「なにを」「どのように」よりもなぜ?を考えるよう
これは最近リファインメントのタイミングでも、まずは「Why」が腑に落ちないと具体的な話をするのは危険だなぁと思っていました。
ある程度チームが成熟しているとプラニングの時点ではこれらを語ることはない、あっても少量のはずというのはそのとおりだなぁと。
ビジョンがあってそのためにはPBIができる
当たり前だけど改めて言われるとPBIに何が書かれているべきかという問題は結構陥っているし整理したいと思っていたので興味深い一言でした。
アジャイル開発宣言には、早いという言葉はない
これもハッとさせられる一言でした。トヨタの製造に対してのアプローチはプランニングに時間をとることである、という話もあり改めて各スクラムイベントの役割を再認識しました。
予測の大変さは、当初と条件が変わること
これは共感です、という気持ちがメモを見ると高ぶっていた。
開発している最中に前提条件が変わる ということもあるし、理解が進むことで必要なもの、あるいは不要なものが見えてくることも多いです。
ウォーターフォール開発は当初の条件から長期間の予測をする手法だが、最悪なのは見込みがずれるとわかったときに期間の修正ができなかったりやらなかったとき。
これは本当に地獄なんですよね。。。
開発者に期待するのはチームがベストを尽くすことだけ:
POに許可を求めるな、謝罪せよ
自分のことだけどこれめっちゃ求めがちだ、、、と思ったやつです。
ちょっと挑戦してみたら? というものに対しては許可を求める時間が無駄とのこと。つまり、もっと失敗すべきでそれを容認していくような信頼関係を構築しろということだろう。
これは自分よりも他のメンバーの方が丈夫なんじゃないかと感じているので、もっと背中を押したり、ゴールやプランにだけ引っ張られすぎないような視座が必要そうだと感じている。
優れたスクラムマスターは障害リストを持っている
似たようなものをは運用しているが、初期フェーズではないため少し様子が違う気がしている。
チームを巻き込むようにはしているが、その仕組みはまだまだ改善余地がある、という感じなのでここは引き続き考えていきたい
スプリントは50%は失敗する
わかりつつも成功できるような計画を組みがち、、、これも挑戦意欲が少し弱いということだろうか?
スクラムにおける挑戦がどういうものなのかまだわかっていないような気がするが、それこそ開発手法やアプローチを抜本的に変えるとなるとこういうことが起きるかも。
ユニットテスト不要論について
理屈としては、
- オブジェクト思考のテストの場合、過去に書いた間違ったテストによる可能性もある
- 1つの要件しかもともとなかった処理があった
- コードの不具合を取り除くのにはコスパは悪い
- 本来、ユースケースこそテストするべき
ちょっと極端じゃないか?とは思ってはいるのでまぁ参考程度に止めようかと思っている。テストコードだけでは不十分というのはそう思う。
そしてDHHのTDDについての話も一緒に共有されていたが、システムテストに偏るのもやめてくれという話もあるのでここもベストを模索していく類のものだと理解している。
面白かった質疑応答
スクラムマスターの目標を立てるのが難しいなと感じています。効果的な考え方、具体例などあるでしょうか。なんとなくプロダクトオーナーに比べると社内での評価が軽視されている気がして、うまく評価されるような方法はあるでしょうか。
A: 過去、自分は評価に関しては捨てていた。会社の文化もあるので難しいところもあるが、チームとしての成果が上がれば一緒にあげられるかもしれない
まぁそう言うしかないよなぁという感想をもった。
スクラムマスターが外部からの攪乱や進捗の妨げになるものを取り除く上で、ある程度の権限（役職）が必要になるケースが多いと思っています。役職が低いうちからスクラムマスターのロールを実践していくうえで、何かコツのようなものはありますか。（往々にしてスクラムマスターを飛ばして上位役職者に相談したほうが早い）
先輩のスクラムマスターにきいてみると良いかもしれないが、役職が低いからSMができないということはない。多くの企業は管理職に話をするのは気が引けるものと思っているが、管理職は問題を知りたいと思っているはず。25年前の日本とは違っていると思っている。一方で話しづらいのもわかるがやるしかないと思う
個人的には役職がなくてもできると思っている。役職を言い訳にしているケースもあると思う。もちろん本当に話が通りにくい組織があるのも事実だとは思うが、意外と現場を変えていく人は役職関係なく変化をさせられると思っている。
バックログに何が書かれているべきか?
プロダクトオーナーの頭の中にあるものを言語化したもの。仕様というのはQ&Aで作っていくものである、PBIの中身は情報としては少ないが要件はビジネス側のもの、プロダクトの管理になる
PBIには仕様を書きがちだったが、本来は何をしたいかが書かれているべきなのはたしかにと思う。対話で仕様を決めていくというのもその通り。
見積もりについて、悲観的ベロシティが15, 楽観的ベロシティ20
これはいろんな話題があるが、まずはひとりでやらないことと見積もりは進むに連れて変化する可能性があることを認知してもらうよう努力すべき
バーンダウンチャートが最後の方に一気に下るようなスプリントが多い。無事にゴールを達成しているが、このままで良いか？それともPBIの細分化をすべきか?
そもそもバーンダウンを直線的にする必要はない。ただし、うまくやっていれば直線に近づけることはできる。PBIが代替同じサイズになることで、上記に近づけることができるだろう。また、チームでPBIを分担して進めているのではないか？Swarmingをすれば後はあまりならないと思う。これはスクラムマスターは注意すべき
個人的に一番ためになった質問だった。自分のチームもそうだったので、チームにも共有しSwarmingの機会を増やせないかといった話がレトロスペクティブ（ふりかえり）でできていてとても良い話だった。
感想
改めて自分のチームがどういう状況か、どうなっているとよいか見ないな部分を考える良いきっかけになりました。
そして質疑応答で垣間見える他社のスクラム開発の状況や課題などがやっぱり興味深かったです。当たり前ですが、こちらの方が現場の話なのでスクラムらしいというか、この状況のベストがなにか?を考えるほうが面白かったです。
ワークも面白かったですが、他の参加者ともう少し懇親会的に話してみると意外と発見ありそうだなぁと思っていました。
