はじめに

結構前の話になりますが、2024/04/24~2024/04/26でスクラムマスターの研修を受けてCSMの資格を取得しました。研修を受ける前は「スクラムっぽいアジャイル開発」のチームを「スクラム開発」しているチームにしていきたいと意気込んでいました。しかし、研修で体系的にスクラム開発を実践したことで、現状のチーム状況と照らし合わせると「スクラム」が最適とは言えないと思い「スクラム」を目指すことをやめました。その判断に至った経緯などをまとめていこうと思うので、同じような状況にいる方の参考になればと思います。

「スクラム」とは

アジャイル開発の開発手法の一つです。
スクラムは以下のチーム、イベント、成果物で構成されます。
スクラムガイドより引用

チーム

スクラムチーム内には、サブチームや階層は存在しない

開発者
各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。
プロダクトオーナー
スクラムチームから生み出されるプロダクトの価値を最大化することに責任を持つ。
スクラムマスター
スクラムガイドで定義されたスクラムを確立されることの結果に責任を持つ。

イベント

スプリント
スプリントは1ヶ月以内とする。
スプリントプランニング
スプリントで実行する作業の計画を立てる。
デイリースクラム
計画された今後の作業を調整しながら、スプリントゴールに対する進捗を精査する。
スプリントレビュー
スプリントの成果を精査し、今後の適応を決定する。ステークホルダーを集めて実施する。
スプリントレトロスペクティブ
品質と効果を高める方法を計画すること。

成果物

プロダクトバックログ
創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧
スプリントバックログ
スプリントゴール、スプリント向けに選択されたいくつかのプロダクトバックログアイテム、およびインクリメントを届けるための実行可能な計画
インクリメント
プロダクトゴールに向けた具体的な踏み石。スプリントレビューではインクリメントを提示する。

全て存在しているものが「スクラム」

研修の質疑でこんな会話がありました。
(研修生)「プロダクトオーナーがいなかったり、スプリントレビューが行えない場合にスクラムは有効な手法ですか？」
(私)(うちと同じだ。気になる！)
(講師)「まず、それはスクラムではありません。スクラムと呼ばないでください」
(私)(・・・)

「スクラムっぽい」なんてものはない

冒頭で私のチームが「スクラムっぽいアジャイル」と表現しましたが、この表現自体存在しないものになります。チーム、イベント、成果物の7割くらい満たしていたので「スクラムっぽい」と表現しましたが、度合いで表現できるものはでなく0(スクラムでない)、100(スクラムである)の世界であることを知れたことが、一番の収穫だったかも知れません。研修でスクラムを学んで、チームで実施しているイベントを改善していくとよいスクラムに向かっていくはずと考えていたので、勘違いしていました。

なぜ厳密に守る必要があるか

スクラムガイドの定義に以下が記載されています。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための最軽量のフレームワークである。
・・・(中略)
スクラムはシンプルである。まずはそのままの状態で試してほしい。

スクラムは複雑な問題を解決するために、短いサイクルで実装を繰り返し、最適解を見つけるためのものです。複雑なフレームワークでは本質を見落としてしまうので、フレームワークは最低限の軽量な状態としています。必要最低限のものだけが残っているので、これらが存在しない場合は、そもそもフレームワークが適していないということになります。

所属チームについて

チーム体制や日常業務の詳細については過去に記載している記事を参照してください。
新チームになって3ヶ月で取り組んだことと悩み

「スクラム」フレームワークに適応させるか?

フレームワークを理解し、チームが「スクラムではない」ことがわかりました。せっかくスクラムマスターの資格を取ったのでフレームワークで運用するために必要なことを考えてみました。

チーム
スクラムマスター、プロダクトオーナーが不在なので誰かに担当してもらう必要があります。ただチームリーダーはスクラムマスター、プロダクトオーナー兼任している印象がありました。そもそもスクラムチームに階層は存在しないので矛盾してしまします。なのでチームの構造から変える必要がありますが、チームがスタートして軌道に乗ってきた？タイミングでもあったので変えることの必要性に疑問を感じました。
イベント
現状は開発案件ごとに完了した段階でレビューを行なっています。スプリントレビューとは若干ことなりますし、スプリントレビューにはステークホルダー(プロダクトオーナーの上司、経営者、発注者、エンドユーザーなど)を呼ぶということも必要です。ステークホルダーを呼ばなくても成立しているということは、そもそもフレームワークに適しているとは言えないのかも知れません。
研修の中でもステークホルダー(特に発注者や経営層)を呼ぶことが組織的に難しいと悩んでいる人が多かったです。組織が大きくなるほど組織は複雑になり、１〜２週間ごとにレビュー参加してもらうことが難しいようです。「スクラム」と言っていても厳密にいうと定義を守れてないことは結構多いのかも知れませんね。

既存の運用を結構変える必要があるとわかりました。目的が明確であるならば、運用を変えることは意味のあることですが、スクラムにすることで何を解決したいかが私の中でも不明瞭であることにも気がつきました。

なにが「スクラム」に適しているか

研修を受けたり、チームで話したりした中で思ったのは、基本的には新規製品、新規機能開発に向いているフレームワークだということです。不具合修正や機能改善がメインでは、チーム内で関わることが少なくなるので必ずしも適しているとは言えません。
また開発だけでなくチームでプロジェクトを進めていくことにも有効であると感じました。

目指すのは「アジャイル」、「自己組織化」

私たちのチームは自社システムを継続的に課題を素早く解決する必要があります。またその課題は必ずしもトップダウンで与えられるものではなく、チームや個人が自主的に発見し解決することが求められます。「アジャイル」なのか「スクラム」なのかなんて言葉の選択の問題なので大事なことではないのですが、私の中ではアジャイル≒スクラムとなりかけていたので、それぞれの定義を理解し区別することで目指すものが明確になりました。

スクラム研修の学びから活かしていること

スクラムマスターに必要な素質として以下が挙げられていました。これはチーム運営においてとても大切なことだと感じました。チームの心理的安全性や自主性を高めるために意識して働いています。

いつも機嫌がいい人
チームの自主性を促し、待てること

まとめ

スクラムは思っていた以上に難しい。せっかく高いお金をかけて(会社負担)学んだので機会があったらスクラムマスターとしてスクラムチームを導いていきたいですね。