お久しぶりです、技研の”むらたん”です。
少し前になりますが、認定スクラムマスター研修を受講したので、紹介をしたいと思います。
講師の江端さんは研修を「トレーニング」と称しており、カリキュラムは「現場で起こりうる問題をスクラムマスターとして、どう乗り越えるか」を研修参加者全員で体験し、答えを導くという内容でした。
具体例として、研修は5人グループが6つの30人が参加しておりますが、講師から、
「どんな研修にしたいか、全員で決めて下さい」
といったお題が出されます。
30人の合意形成をする方法として、学校では「多数決」みたいな手法を教えられたかと思うのですが、全員が納得した形では決まらない場合が殆どで、何らかの”妥協”が生じています。
スクラムにおけるチームは「自律したチーム」を目指しています。チームのメンバーは誰に指示されることなく、全員が同じベクトルに向かって、次に何をすべきかが分かって実践し、改善しつづけられることを是としています。
「”妥協”がある中で、本当の合意が取れたのか？」は「（スクラムマスターは）そんなやり方で自律したチームを編成出来ると思う？」と問いと同義になり、スクラムにおいては、多数決が必ずしも合意形成をしているとは限らないということを学びます。
「スクラムとは何か？」みたいな話は、書籍や参考文献がたくさんありますので、今回は教科書からは読み取りにくい部分を紹介したいと思います。
スクラムはプロジェクトやチームの状態を可視化し、改善させるためのフレームワークです。
デイリースクラム等の様々なセレモニーや、プロダクトバックログなどの成果物を通じて、チームの透明性(Transparency)が保たれ、検証(Inspect)と適用(Adopt)で改善を実現できる状態になります。
状態を見て改善するのはスクラムチームです。スクラムやってれば救われるって訳ではありません。
例えば、ある機能をリリースするまで期間を知りたいと思ったとします。
1スプリント回すだけで、チームのベロシティが可視化されます。
リリースしたいバックログのポイントの総計をベロシティで割れば、現時点での生産性で必要なスプリント数が分かります。
リリース予定日までに全ての機能をリリースできないとなった場合、何らかの決断をし、行動しなければなりませんが、それが出来ることがスクラムの素晴らしいところなのです。
先程、「決断」とでてきましたが、決断するのは「プロダクトオーナー」です。
スクラムには3つのロールが定義されていますが、それぞれが重責を担っています。
研修では以下のように説明を受けました。シンプルですが、これに尽きると思います。
- プロダクトオーナー(PO)：チームのROIを最大化する、決断の準備をする
- スクラムマスター(SM)：スクラムを最大限活用する、他の手法も学び、最適な手法を提案する(決定出来ない)
- 開発チーム：スプリントプランニングで約束したことは守る、生産性を向上させる
それぞれの役割間で話し合いはいくらでも出来ます。しかし、最終的に決定するのは「プロダクトオーナー」ですし、決定に対して、「開発チーム」は実現可能な案をコミットしたら、やりとげなければなりません。
お互いが同程度の権限を持っていれば、話し合って、落とし所を決められるのが理想ですが、思うようには行かない現実があり、「スクラムマスター」がスクラムを活用して、チームの活動が上手く回るように動き回る。
このバランス、よく出来ていると思いませんか？現実の仕事の世界では「POとSMを兼務」なんていう話を聞いたりしますが、役割と責務の本質的な部分を見落としてしまっている気がします。
今回は割愛します。が、書籍や参考文献で「やり方」を学んだセレモニーにも、それぞれに目的やタブーがあるので、そこを見失わないように、スクラムを回していく必要があることを実感した、実りのある3日間でした。
