認定スクラムマスター研修に参加して印象に残ったこと

https://gyazo.com/9c1309784e9d670b9f76e767ae290f75

はじめに

2024年1月24日から26日の二泊三日、オンサイト型の認定スクラムマスター研修に参加してきました。

https://ogp-image.deno.dev/svg?url=https://www.attractor.co.jp/info/csm-hakone-20240124/#.svg

スクラムをしているつもりだが、ミニウォーターフォールになってしまっている感覚がする

スプリントゴールが設定できない

ベロシティだけで数ヶ月間の未来予測をしており、リファインメントができていない作業を見積もらなければならない

スクラムマスターが何をすればいいのかわからない

ふりかえりで良いアイデアが出てこない

作ったものがなかなかリリースできない

ステークホルダにマイクロマネジメントされてしまう

社内ではスクラムマスター同士の情報交換をする場があり、困った時にアトラクタの書籍やWebの資料を目にする機会が多くありました。その後、アトラクタのメンバーから直接教えていただける認定スクラムマスター研修に参加すると体系的に学ぶことができて良いのではないかということで、参加してみることにしました。

印象に残ったこと

私が研修に参加した上で印象に残ったことを紹介します。

アジャイルな開発が向いている領域

現代はソフトウェア・ハードウェアともに進化の速度が早く、世の中で受け入れられるプロダクトも次々に変わっていきます。このような状況下でのプロダクト開発は未来予測が難しいため、素早く仮説検証を行って必要なものを無駄なく作る必要があります。

問題を分類して意思決定をモデル化したフレームワークとして「クネビンフレームワーク」と言うものがありますが、カオスな領域・複雑な領域に属するものは問題を解決する方法が理解できないので（複雑な領域の場合は）試行錯誤を行ったり、（カオスな領域の場合は）まず何か行動してみる必要があります。

https://ogp-image.deno.dev/svg?url=https://slide.meguro.ryuzee.com/slides/101?vertical=1#.svg

https://ogp-image.deno.dev/svg?url=https://www.ryuzee.com/contents/blog/7147#.svg

ウォーターフォールの場合は作ったものが役に立つものなのかを知るのに時間がかかり過ぎるため、作ったものがムダになるリスクが高まります。このような領域ではアジャイルな開発が適しています。

未熟なチームこそスクラムを導入すべき

研修を受ける前は、優秀なチームメンバーでなければ良いスクラムはできないと思っていました。しかし、実際には未熟なチームこそスクラムを導入すべきと言われています。なぜなら、チーム結成当初からいきなり成熟した優秀なメンバーを十分に揃えることは稀だからです。また、スクラムでは全体の時間の約20%をスクラムイベントに費やすため、開発時間だけ考えれば非効率と言えます。しかし、この非効率さこそスクラムをうまくやるための仕掛けなのです。

アジャイルマニフェストにも示されているような価値観を大事にするために必要なエッセンスが詰まっています。仮に、チームが本当に未熟で成果が出せないとすれば、それは最初のスプリントレビューですぐに気づくことができ、対処するために動くこともできます。

スプリントレビューで価値あるフィードバックを得るために

明確なスプリントゴールがあれば、メンバーは目標達成に必要な行動を考えることができ、POをサポートできます。そして、実装を行ってインクリメントを作ります。結果として、スプリントレビューで得られるフィードバックはスプリントゴールを達成したインクリメントに対する価値判断になります。

タイムボックスを意識する

スクラムにおいて、タイムボックスを意識することは重要なルールの一つです。これは時間内に話を終わらせることを意味します。たとえ話が終わりそうになくても必ず一度タイムボックスで区切り、その後必要に応じて再検討する必要があります。

毎回話がまとまらない場合は、その理由を分析し改善方法を検討する必要があります。実際に私のチームではデイリースクラムの時間が30分以上かかってしまう問題がありました。原因として、デイリースクラムに直接関係のない内容を話しているということがありました。この問題を解決するために、デイリースクラムの時間まで話すのを待つのではなく普段から相談したい相手とコミュニケーションを取るように促し、デイリースクラムでは必要な報告だけを行うように努めてもらい、時間内に終わるようにしました。

スクラムイベントのタイムボックスを守ることがルールを守ることになり、スプリントゴールを達成する目標を果たすことにもつながります。「時間がもっとあれば…」と言いたくなる気持ちをグッと堪えて、小さなインクリメントを積み上げスプリントゴールを達成することが重要です。

一方で、研修中はスプリントレビューに最も時間を割いて（各チーム時間制限なしで）全チームの発表を聞きました。最も重要な時間であることの表れなのかもしれません。また、チームの調子がよくなれば良いフィードバックが増えるので、続けていくにつれて時間が短くなっていくのかもしれないなと感じました。

研修で体感したスクラムの力

研修では、その場で集まったメンバーでチームを組み、実際にプロトタイプの開発を行います。スクラムイベントを除いた開発時間は、たったの20分程度です。まだ知り合って間もないメンバーで息を合わせて作業を行うのは困難でしたが、それでもスプリントレビューで成果を発表しなければなりません。実際、初回のスプリントレビューでは厳しい意見が数多く出ました。しかし、チームは次のスプリントで軌道修正を図り、次の発表では「使ってみたくなった」とフィードバックをいただくことができました。ふりかえってみると、もし最初の段階でフィードバックをもらえていなかったら…と思うとゾッとします。

楽しく楽に仕事できるようにするためのふりかえり

スプリントレトロスペクティブは、開発プロセスそのものを改善するための場です。つまり、プロダクトやバグではなく、開発方法の問題に焦点を当て、より楽しく楽に仕事ができるように改善していくことが目的です。

これまで、私のチームでは何のふりかえりなのか明確にしておらず、プロダクト改善や技術的な試みがしばしば議論されていましたが、これは誤りでした。プロダクトに関するレトロスペクティブは、「リリースレトロスペクティブ」など別の機会を作って、それに合わせてメンバーも調整して行うといいようです。

また、成熟したチームは、レトロスペクティブ前に問題を見つけて改善できるため、次のステップとして、例えば「Slackで朝の挨拶をする」というような簡単で実験的な取り組みを入れてみると良いことを学びました。一見意味がないように思えるような取り組みでも、予期せぬ良い改善につながる可能性があります。良いと思えば続ければいいし、意味がないならやめれば良いだけなので、確かにデメリットはなさそうです。

現在読んでいる「アジャイルレトロスペクティブ」には様々なゲームが紹介されているので、ユーモアのある面白いゲームを取り入れて、楽しいレトロスペクティブを開催し、チーム全体で楽しく楽に仕事ができる環境を作っていきたいと思います。

スクラムマスターはチームを自立へと導く存在

研修最終日では、「偉大なスクラムマスター」について考えました。スクラムマスターは、チームやメンバー、組織を支援する縁の下の力持ち的な存在です。サーバントリーダーとして、メンバーに指示をするのではなく、チームを注意深く観察し、自走できるよう支援します。

メンバーのマインドセットを変えるのは容易ではありません。状況によって求められることも異なるため、一概にこれをやれば良いといったタスクリストはありません。その点でスクラムマスターは大変な仕事ではありますが、一つ一つ確実に原則を守ってやっていけば良いんだという一定の安心感と自信を得られました。

さらに、チームが自立し始めると、スクラムマスターの存在は必要なくなり、「見えなくなる」という興味深い考え方も学びました。

https://ogp-image.deno.dev/svg?url=https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/sprint/daily-scrum/scrummaster-incognito#.png

最終的に自分の居場所がなくなるというのはちょっと寂しい気持ちもありますが、開発でいう「属人性を排除する」イメージに近い気もします。ここまで到達できるように努力したいです。

最後に

Special Thanks

スクラムマスターの育成にも力を入れている弊社では新しいメンバーを大募集中です。記事を見てもし興味がある方がいたらこちらから誰とでもカジュアル面談できます。お気軽にご連絡ください。

https://ogp-image.deno.dev/svg?url=https://monicle.co.jp/recruit/engineer#.png https://monicle.co.jp/recruit/engineer