はじめに
9月20日から3日間、株式会社アトラクタ主催の認定スクラムマスター研修 （Certified ScrumMaster） を受講しました。
一言でいうと、「レビュー・フィードバックの大切さをとても実感できる研修」でした。
いろいろ心に残ったことがあったので、参加レポートという名の自分用備忘録を書きます。
経緯
私は 2022 年に Scrum Inc. が提供する認定資格スクラムマスター研修 Registered Scrum Master® Training を受講しました。
その経験を基に、チームにスクラム勉強会などを開催し、スクラムを実践してきました。
しかし、所々でうまくいかず、時間が経つにつれ妥協した結果の自己流スタイルになっていき、以下のような課題を抱えるようになりました。
- 見積もりをしていない
- そもそも見積もりをできるまでバックログのリファインメント（分割・詳細化）をしていない
- スプリントゴールがいつも達成できない
- スプリントレビューで動くものがない
- そもそもスプリントレビューにステークホルダーを呼ばず、開発チーム内の進捗チェックになっている
こういった課題に対し、どうやって解決していこうかと考えるにあたり、Ryuzee.com の記事を参考にすることが多くなりました。
いつか直接 ryuzee さんに教えてもらいたいな～と思っていたある日、アトラクタの CSM 研修で ryuzee さんが講師の回を見つけ、参加することに決めました。
ついでに社内で「誰か一緒に参加しませんか？」と誘ったら、2 名の同僚が一緒に参加してくれることになりました。
RSM（旧 LSM）との違いとおすすめ
結論、ほぼ未経験でインプット目的なら RSM、ある程度スクラムの実践経験があるなら CSM をおすすめします。
RSM と CSM の特徴（主観）
- RSM（バーチャル）
- 講師の質が安定している
- 資料が整っていて見やすい
- チームごとにコーチがついており、適宜フォローしてくれたり、質問に答えてくれる
- 座学（インプット）多め
- 各イベントについてバランスよく学べる
- ワークショップが楽しい
- 様々なプラクティス（スクラムパターン）が学べるので、実践のイメージがつきやすい
- Scrum@Scale などの応用パターンについても触れられる
- より集合研修に近いイメージ
- 質問はホワイトボードツールに書いておいたらコーチの人が丁寧に回答してくれる（バーチャルの場合）
- CSM（アトラクタ）
- 会社（団体）・講師によって質やスタイルはバラバラ
- CSM テストの受験資格を得られるかどうかは講師次第（厳しい会社・講師もあるらしい）
- 勉強会等の登壇者自己紹介で言及されるのは大体こっち
- （ここからはアトラクタ（ryuzee さん）の CSM 研修の感想）
- スクラムガイドにより忠実（プラクティスより原則を重視している印象）
- 自由度が高い。より「自己管理されたチーム」を目指せる（が、その分チームの主体性と力量が問われる）
- 実践（アウトプット）が多め
- フィードバックの重要性を実感できる。全チームのスプリントレビューをみんなで見て、フィードバックしたり。
- よりアットホーム、インタラクティブ（１チーム６名で４チーム）
- Slack で講師の 吉羽さん や 原田さん、永瀬さん、高橋さん といった一流講師陣に直接質問できる（研修後約 2 週間まで OK）
どちらを受けようか迷っている人がいたら連絡してください。相談に乗ります。
どちらもおすすめなので、両方受けられるのがベストです。（最初 RSM を受講して、ある程度実践経験を積んだら CSM を受講する、など）
なお、RSM の方はオンサイト形式の講習もあり、そちらも多少雰囲気が違うようです。（付箋を使ったり、オンサイトならではのワークショップがあったり）
以下なども参考になると思います。
響いた内容（本題）
ここからは CSM 研修を受けて個人的に響いた内容を紹介します。
アジャイル・スクラムの価値とは
不確実性が高まり何が受け入れられるか分からない現代では、多数の取り組みを素早く回して、ポテンシャルのあるものを見極めていく必要があります。
素早い投資判断。素早い実行。素早い撤退。うまくいけば素早く追加投資・・・
大企業になればなるほど、素早い撤退やピボットが苦手です。しかし早く止めることができないと、重要なリソース（人・お金）を重要な個所に振り向けられません。
また、ムダな機能が作られる事による損失も無視できません。
「必要かもしれない」と思って入れた機能は使われません。
規模が大きくなると加速度的に保守の労力が上がり、開発速度が遅くなっていきます。
- 自分たちは、顧客の要求を本当に理解できているのか？
- 自分たちは無駄な機能を作っていないか？無駄な機能を保守していないか？
この 2 点を自問自答していく必要があります。
ウォーターフォールでは、これらのリスクが高まります。
アジャイル、スクラムの価値とは、この 2 点を最小限に抑えることにあると感じました。
「失敗するなら小さく・素早く」という考え方です。
つまり、アジャイルは「決まったもの速く安く作る」方法ではない。「限られた予算の中で効果的なやり方を模索する」やり方 であるということです。
（"Agile" という単語を考慮するならば「素早く方向転換する」やり方とも言えるかもしれません）
以下も参考になると思います。
アジャイルソフトウエア開発宣言、スクラムガイドの本質さ
スクラムを導入しようとすると、「いかにうまくスクラムができるか」ということにフォーカスしてしまいがちですが、スクラムは手段でしかありません。
この研修を受けるまでは、「見積もりがうまくできない」「スプリントゴールが達成できない」といった課題に対して、スクラムのプラクティスを追いかけていました。
しかしこの研修を通じて、原則を重視することの大切さを学びました。
アジャイルソフトウェア開発宣言は、適応型の開発手法（軽量型開発手法）の提唱者が集まって整理された共通の価値観だということを学びました。
スクラム、カンバン、XP など、様々な軽量型開発手法がありますが、それらは手段であり、結局達成したい価値観は同じなんだなと実感しました。
スクラムガイド も同様です。
スクラムガイドはスクラムを実践する上で、必要最低限のルールを定めたものです。
ガイドの文章が固く、抽象的であるから、今まで「読んでもあまり入ってこないなぁ」と思っていたのですが、ryuzee さんの講義で何度も「スクラムガイドにはこう書いてあります。つまり・・・」と解説をしてもらうことで、スクラムガイドにはスクラムのエッセンスが詰まっていることを実感しました。
「スクラムガイドは何度読んでも気づきがある」と聴いたことがありますが、正にその通りだと思います。
スクラムで悩んだことがあったら今まではプラクティスを漁っていたのですが、これからはまずスクラムガイドを読み返してみようと思います。
経験主義とスクラムの三本柱を常に根底に
スクラムで一番大事なのは、この 3 つなんじゃないかと思います。
「経験主義を支える３本柱によって、スクラムが機能するようになる」ということを学びました。
-
透明性
- プロダクト、作成物、プロセス、ゴール、完成の定義、人、状況、問題点などを常に共有する
-
検査
- 透明性を踏まえて、頻繁に作成物や進捗を検査し、期待する結果との差を明らかにする。プロセスや人も同じ
-
適応
- 透明性と検査を踏まえて、できるだけ早く調整や変更を行う
スクラムの各イベントは、これらを達成するためにデザインされていると感じました。
スクラムのイベントで上手くいかない課題感を感じた場合、「透明性」「検査」「適応」のどれが足りないのかを考えてみるとヒントが見つかるかもしれないな、と思いました。
スプリントレビューの重要性
ryuzee さんは「人によって意見は違うかもしれないが、スクラムにおいてスプリントレビューが一番大事。」って言っていました。
スプリントレビューでステークホルダーからフィードバックをもらうことで、自分たちが作っているものが本当に価値があるものなのかを検査できるからです。
価値は提供元のチームや組織の外側で決まる（顧客やユーザーが決める） のです。
そのため、スクラムにおいてスプリントレビューが機能しているかが最も重要なポイントとなってくる、と理解しました。
つまり、「インクリメントを見せられないのは論外」 とのことです（グサッ）。
上記の思想からか、研修自体もかなりスプリントレビューに時間を割いていました。
他チームのスプリントレビューも含めて、複数回のスプリントレビューを実施し、全員参加型でフィードバックをする、という形式でした。
フィードバックが結構手厳しかったりするのですが、「耳の痛いフィードバックであっても、それを早い時点で得られるのは大きなメリット」 であることを実感しました。
そして、こういったフィードバックをもらえるのは動くインクリメントを見せているから （インクリメントを見せられなかったらそもそもフィードバックをもらえない） ということも学びました。
実際、どのチームも初回のスプリントレビューではズタボロに言われるのですが、翌スプリントで適応し、スプリントレビューで「とてもよくなった」と言われていました。
私のチームは課題設定やフィードバックの反映がうまくいったおかげか好評価をいただき、「素晴らしかった」「過去の研修の中でも、このレベルはなかなかいなかった」と言ってもらえました 
ryuzee さんにこう言ってもらえたことがめちゃくちゃ嬉しかったです（録音して家宝にしたかった・・・）
これがめちゃくちゃやる気に繋がったのですが、モチベーションの観点からも「フィードバックで褒められるって大事だな」と思いました。
（スクラムマスターがステークホルダーに「次回のレビュー、不満もあると思いますが、めっちゃ褒めてください。後々効果大きいですよ」とこっそり伝える、という方法もあるそうです）
また、研修中に「『プロダクトオーナーがスプリントレビューで完成しているかチェックする』イベントにしている例は多いが、これは違う」という話を聞きました。
正直、自分たちのチームは現状プロダクトオーナーからフィードバックをもらう形式のスプリントレビューになっているので、改善が必要だと感じました。
以下も参考になると思います。
逆算したスプリントプランニング
以下の「スプリントゴール」や「プロダクトバックログリファインメント」の項目とも関連しますが、以下について学びました。
- スプリントゴールやスプリントレビューから投入するバックログアイテムを逆算する
- つまり、適切なスプリントゴールの設定、そのゴールを達成しているインクリメントをスプリントレビューで見せられることを重視する必要がある
- 準備ができているプロダクトバックログアイテムを投入する
- つまり、「生煮えバックログアイテムを食べると腹をこわす」
とても重要なことなのですが、自分たちはどちらもできていません・・・
以下も参考になると思います。
スプリントゴールの目的と考え方
スプリントゴールを設定する目的を学びました。
ざっくりいうと、スプリントゴールを設定することで、チームが集中しやすくなり、フィードバックを得やすくなる、ということです。
決して「これらすべてのバックログアイテムを完了させること」ではありません。
スプリントゴールは「プロダクトゴールを達成するために、このスプリントではどういった価値を提供できそうか」「次のレビューでどういったフィードバックが欲しいか」を考えて設定するものです。
私のチームでは「バックログの上から３つくらいができそうだから、それらに関連するゴールを設定しよう」という感じでしたが、これは間違いでした。
限られたプロダクト開発期間・予算・状況のなかで「今このテーマに取り組むのはなんでだっけ？」と自問自答しながら、「このプロダクトは次のスプリントでどういった価値を生み出せるか」を考えていきたいと思います。
最初から完璧な見積もりを出す方法はない
「なるべくずれない見積もりの方法」は知りたいという人が多いが、「最初から完璧な見積もりを出す方法はない」ということにチームが気づくのがスタートです。
作っていき、見積もりと実績を比較していって、徐々に学んでいく。（作ったことのあるものしか見積もれない）
「学習した内容を踏まえて、見積もりは何度も更新する」 というのが見積もりのコツ、とのことです。
また、「なぜプロダクトバックログアイテムを見積もるのか？」という見積もりの目的について、チームやステークホルダーと理解・合意してもらう必要があることを学びました。
弊害はベロシティの悪用など・・・
見積もりの目的を合意できると、「No Estimates」（一定の小さいサイズまで分割して、経験則から見積もる）といった経験主義のアプローチも選択肢に入ってくるでしょう。
この「No Estimates」という概念は研修で軽くしか触れられていませんでしたが、調べてみると興味深かったです。
いつかこれができるチームになれるといいなと思います。
もしかしたら「上層部に進捗報告をする必要があるため、生産性指標としてベロシティを使っている」という人もいるかもしれません。
それはベロシティの悪用であり、 スクラムチーム外の人がベロシティを使うのは意味がないどころか害を与えます。
結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。
アジャイルソフトウェア開発宣言の背後にある原則に 「動くソフトウェアこそが進捗の最も重要な尺度です」 とあるように、ステークホルダーにスプリントレビューに来てもらい、動くインクリメントを見せて今後の見通しを話すことが、進捗を理解・納得してもらう上で重要なんだろうなと感じました。
（上記で紹介した「見積もりをしない。 - 見積もりの目的と効果」に記載されているように、「（ステークホルダーと）信頼を積み上げていく」という観点からも、スプリントレビューに参加してもらうのは効果的そうです）
以下も参考になると思います。
継続的なプロダクトバックログリファインメントの重要性
人は時間がないと、すぐに着手したくなります。
ただし一度立ち止まり、着手する・計画する前にチーム内で着地点の合意を取らないと、「欲しいのはこれじゃない」と手戻りが発生するリスクがあります。
また、プロダクトバックログは常にメンテナンスする必要があることを学びました。
最初にバックログを作成して、それが完璧であることはまずありません。
不確実性が高いプロダクトであれば、「とっとと作ってフィードバックもらって、継続的にバックログをメンテナンスしていく必要がある」 とのことです。
ryuzee さんはよく
「時間がなくて、プロダクトバックログの手入れにそんなに時間かけられません・・・」
という質問を受けるそうです。
これは逆で、「プロダクトバックログの手入れをしないので時間が無くなる」 とのことでした。
まさに自分がその典型です・・・
どうしても開発に時間をかけたくなっちゃいますが、チームでの手戻りを防ぐために、プロダクトオーナーと協力しつつプロダクトバックログリファインメントの時間を確保していきたいと思います。
あと、自分たちのチームは「プロダクトバックログアイテムを分割したら親子関係ができて、受入基準などの依存管理が大変」という悩みがあったのですが、これについては 「分割後の親タスクは捨ててしまっていい。プロダクトバックログアイテム同士で依存関係は持たせない方がいい。プロダクトバックは階層構造をもたず、一直線に。」 という回答をもらいました。
結構自分たちの価値観を変える必要があることも分かりましたが、それも含めて悩みを直接質問できたのはよかったです。
以下も参考になると思います。
自分たちの仕事を「簡単」にするためのふりかえり
「パフォーマンスを改善するうえで最も効果がありそうな変更を明らかにし、なるべく早く着手する」というのがスプリントレトロスペクティブの目的であることを学びました。
改善は 「自分の仕事を安全にする」「自分の仕事を簡単にする」 という観点で考えるといいそうです。（「チェックリストを作りました！」は簡単になっていない）
また、持続的なペースで改善を続けること、一度にたくさんのことを変更しようとしないことも学びました。
最後に、改善のアクションアイテムは「具体的」であることが重要とのことです。（「具体的」って難しいですよね）
以下も参考になると思います。
スクラムゴールを達成するためのデイリースクラム
以下のようなテーマで登壇があるように、「デイリースクラムが進捗報告会になりがち」など、形骸化することはよくある課題だと感じます。（私のチームもそうです）
デイリースクラムは、スプリントゴールに対して現在のインクリメントの作成状況を検査して、スプリントゴールを達成できなさそうであれば適応する場です。
「スプリントでインクリメントを毎回作れているか？」「スプリントゴールは多くのスプリントで達成できているか？」 と自問し、問題ないのであれば現状のデイリースクラムでも問題はないかもしれません。
しかし、インクリメントを作れない、スプリントゴールを達成できないということであれば、それを真っ先に直さなければいけません。
そして、スプリントゴール達成の可能性を少しでも上げるにはデイリースクラムでの検査が重要になってきます。
そこで検査ができないのであれば、「透明性が不足している」ということで、進捗状況の見える化（小さな作業アイテムへの分解やスクラムボードの活用など）やチームメンバーの関係性（心理的安全性やチーム設計など）が課題になってくるかもしれません。
透明性があっても検査ができていないのであれば、デイリースクラムの進め方に問題があったり、そもそもチームがデイリースクラムの目的を理解（共通認識として合意）できていないかもしれません。
検査はできていていも適応ができていないのであれば、スプリントゴールのサイズや立て方、プロダクトバックログアイテムの受入基準、プロダクトオーナーとのコミュニケーションなどが課題になってくるかもしれません。
「透明性」「検査」「適応」ということを意識し、デイリースクラムで「スプリントゴールを達成するために何ができるか」を考えていきたいと思います。
以下も参考になると思います。
機能横断的で自己管理されたチームになるための継続的な投資
「スクラムチームは自己管理する（いつ、何を、どうやって、誰がやるかは自分たちで決める）」ということを学びました。
また、チーム内で仕事のアサインを役割分担型にすると属人化しやすいため、非常事態でも安定的なクロスファンクション型にしていくのがいい、と学びました。
ただし、最初から機能横断的で自己管理されたチームができていることは稀です。
チーム内で徐々にスキルを増やす・トランスファーしていく努力が持続的なチーム運営をしていくためには必要です。
あまり多くは語られませんでしたが、このあたりを詳しく知りたい場合は チームトポロジー あたりを勉強するといいのかなと思いました。
スクラムマスターの重要スキル「観察」
最終日に「スクラムマスターロールプレイ」という、スクラムマスターになりきってあらゆる悩み事を解決していくワークショップを行いました。
その中で、根本的な問題がどこにあるか見極めるために、スクラムマスターのスキルとして「観察すること」がとても大事であることを学びました。
必要に応じて開発者と MTG や 1on1 を行うなどして、チームの状況を把握する必要があります。
（スクラムマスターが忙しすぎるとチームの観察ができないため、危険な兆候）
観察のポイントについては、以下も参考になりそうだなと感じました。
また、スクラムマスターはスクラムチームにも組織にも支援する必要があり、チームが潤滑に動くようにするためのことなら何でもやるということです。
改めて、スクラムマスターの仕事って大変だなぁ・・・と思いました。
以下も参考になると思います。
ベストプラクティスなんてない。実験と学習の繰り返し
チームはそれぞれ違います。
あるチームでうまくいったことも、あるチームではうまくいかない可能性があります。
プラクティスを集めて輸入することは、必ずしも効果が上がることではありません。
もちろん試してみるのはいいことです。
ベストプラクティスを盲目的に適用するのではなく、「試しに１，２スプリント実践してみて、自分たちにとって良さそうであれば継続しましょう」というように実験的な扱いにするといい、とのことです。
危険な兆候として、上長などが
「一番良いやり方を導入して標準化、横展開したい」
と言ってくることがあります。
しかし、これは「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」というアジャイルソフトウェア開発宣言の背後にある原則に違反します。
ガイドみたいなものを作るのはいいですが、「この通りにやりなさい」という巻物を押し付けるのはよくありません。
チームによって検査・適応していく必要があります （経験主義）
この研修を受けていろいろ試してみたい衝動に駆られていますが、「実験的にやっていきましょう」というスタンスでチームに取り入れていきたいなと思います。
その他、聞きたかったけど十分に聞けなかったこと
以下の事柄についてもスクラムの文脈・観点から聞いてみたいと思っていましたが、自分の経験不足もあり、具体的な質問は思い浮かびませんでした。
ただし、今回様々な原則を教えてもらったので、今後迷ったときにはそれらと照らし合わせて考えていきたいと思います。
研修を終えて
色々学んで、自分たちのチームで試したいことができました。
しかし、まずは以下についてチームで認識を揃えることからかなと思います。
スプリントレビューでステークホルダーからフィードバックをもらうために、
スプリントプランニングで適切なスプリントゴールを設定し、
デイリースクラムでスプリントゴールを達成するためにタスクの検査・適応をし、
スプリントレトロスペクティブでスプリントゴールを達成するためにプロセスの検査・適応をしていく。
というサイクルを回していくことが大事だと思いました。
あと、自分たちは「なんちゃってスクラム（正しいやり方をやらずに自分たちの都合に合わせてる）」状態なので、まずは守破離の「守」から実践していきたいです。
（ただし、スクラムを導入すること自体を目的とせずに、あくまで自分たちが達成したいミッションや価値観の実現手段として）
道のりは長いですが、一歩ずつ。
「素早く」「頻繁に」「安定的に」価値を届ける能力を身に着けられるよう、チームで頑張っていきたいと思います！ 
おわりに
自分のためにまとめたのですが、ありがたいことに ryuzee さんに記事のツイートをリポストしていただきました
ryuzee さんの CSM 研修、とてもおすすめです。
公開されているブログやスライドを漁るだけでも十分勉強になりますが、ryuzee さんの言葉を直接聴き、ロールプレイで実践し、自分たちの悩みを相談するという体験は他に代えがたいものがあります。
（あと一番驚いたことは、吉羽さんや原田さんめちゃくちゃ優しいです笑 こんなこと言ったら失礼ですが、よく X でキレのあるポストを投稿しているので怖いイメージを持っていたのですが、「どんな質問でも遠慮なくしてください」と言ってくれ、実際「こんなしょうもない質問していいのかな・・・」というような質問でも爆速かつ丁寧に回答してくれました）
また定期的に実施するようなので、社内のメンバー等を誘って参加してみてはいかがでしょうか。
（直近だと 2023年12月13日(水) 〜 12月15日(金) にあるようです）
あと、一緒に参加した同僚も記事を書いているので、よかったら読んでみてください 
スクラムは実践が大変ですが、価値あるものを作っていけるよう一緒にがんばっていきましょう～！