私が所属する会社で全社的にスクラムを推進していて、チーム内でもスクラムについて話題に上がることが多かったので、詳しく学びたいと思い「スクラム実践入門」を読みました。

タイトルどおり実践的な内容が多く、実際に導入する際は事前に復習したい内容が多かったのでまとめました。

そもそもスクラムとは？

スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。

私の中の理解としては、ソフトウェアの開発は現実の問題がすごく複雑で時間とともに変化し、開発する目的も手段も不確実になっているため、スプリントという一定の期間で計画→実行→振り返りを行い、経験主義的に問題を解決しながら開発をしていくフレームワークと考えています。

導入にあたる課題

本の中の事例としてスクラムを導入する際に問題には以下のようなものがありました。

そのため実際に導入してみると、スクラムを推進できずうまくいかなかったり、振り返りで見つかったチームの問題を改善する行動が取られないといったことが起きていました。

改善をするためには、研修などでスクラム自体を深く学びことや、スクラムマスターをしっかりと専任させることが大事です。そうすることで、スクラム推進の支援をおこなったり、チーム内の問題の改善を促しや動機づけを行うことで問題解決に繋がります。

私自身、一度本書の形だけスクラムのような状態で開発するチームに所属をしたことがありました。このときは、振り返りをすると問題は顕在化していたのですが、まったく改善がされないという問題がありました。

本書を読んで振り返ると、問題解決の支援をするスクラムマスターのような人が不在だったのが原因でした。

スクラムはあくまで振り返りの機会を提供しているだけで、問題解決自体は自分たちで行う必要があります。スクラムやってもうまくいかないと諦めるのではなく、チーム内でスクラムに関する勉強会などをを開き理解を深めることで問題の原因をちゃんと考える必要があったと思います。

また、本書で出てきて気になるキーワードとしてスクラムの奴隷というキーワードがありました。

とスクラムマスターが考えてしまう状態です。

あまりスクラムに固執し過ぎると開発チームの中でスクラムに疑問を持つ人や、ビジネス側の人からする信頼を失うようなことにつながってしまいます。

あくまでスクラムは課題解決をするために導入している手段のため、フレームワークなどを使ってスクラム導入の目的を明らかにしていくと良いです。

また以下のようなコミュニティがあるので一度参加してみたいと思います