アソビューで最近スクラムマスターを担当している上中です。
アソビューでは数年前からスクラムでの開発を行ってきましたが、正直にいうと俺たちは雰囲気でスクラムをやっている状態になっており、それを大きく見直したり改善したりということをあまりやってきませんでした。
そこで、それまで何となくでスクラムをしていたチームのレベルを引き上げるべく、初心者スクラムマスターが最初にどういう改善を行なったのかについてまとめておきたいと思います。

なぜスクラムの改善を行うのか？

前述の通り、アソビューではスクラムを導入していますが、少なくとも自分が所属するチームは正直に言うとよくあるなんちゃってスクラムのようになっており、実態としてはウォーターフォールのような開発になってしまっています。
つまりタスク分解はしつつスクラムイベントでスクラムを回している体ではあるものの、全体通してみると設計、開発、テスト、リリースという１つ１つのプロセスを、複数のスプリントに跨いで順番にこなしているような状況です。
そこで、市場への価値提供速度を向上させる(いわゆるフロー効率を良くする)目的の一環として、スクラムを一から見直し、少しずつ改善していくことにしました。

スクラム成熟度によるチーム分析と、その前準備

まず、実際のところ自分たちのスクラムの現在地がどうなのかを客観的に知るため、「あなたのスクラムチームの成熟度は？」の表を参考にさせていただき、自分たちのスクラムチームとしての成熟度を判定することにしました。
しかし、スクラムチームの成熟度の表を見ていただくとわかりますが、スクラムの基礎知識がなければ、記述されている内容の意味となぜそれが必要なのかを理解することができません。
ちょうど最近チームの編成も変更になったところだったので、準備としてスクラムガイドをチーム全員で読み直すところから始めました。
スクラムガイドを各自で読んでもらい、内容について

重要だと思ったこと
初めて知ったこと
自分たちができていること/できていないこと
その他質問など

に分類して意見を出してもらう、というのを３回に分けて実施しました。
そこで出た意見や質問をきっかけにスクラムガイドを見直すことで、スクラムガイドの理解を深めました。

スクラム成熟度の解釈と判定

スクラムガイドについての共通理解がとれたところで、スクラムチームの成熟度モデルに話を戻します。まずは成熟度の表に記載されている内容が結構曖昧なので解釈が必要になります。
そこで

スクラムガイドのどの部分に該当するのか
その基準に該当するのかどうなのかの判断基準

を明確にしました。
例えば、開発チームのレベル１には、"個人の知識や標準（standard）によって個人のタスクを決めている"という項目がありますが、これについては、

解釈

スクラムガイド「知識や標準はチームで共通化し、それに従う。スクラムを構成するのは、作業に必要なすべてのスキルや専⾨知識をグループ全体として備える⼈たちである。」
-> 特定の１人しかできない属人的な作業が存在しないか？
-> いなくなる時に引き継ぎが必要になるルールは存在しないか？

判定

特定のメンバに依存する作業や引き継ぎが必要な作業やルールが存在する
->該当

という感じです。
自分たちの成熟度がどうなっているか？よりも、スクラムガイドの理解を深めたり、今の自分たちとの違いを具体的にイメージするために必要な作業だったと思います。
効率的に進めるなら解釈の部分はAIにサポートして貰うと良いと思います。

分析で見えてきた自チームにおけるスクラムの課題

これらの作業を通じて、各々が普段から感じていたが言語化してこなかったことや、かなりぶっちゃけたことなど、以下のような課題や認識齟齬が明らかになりました。

スクラムマスター(以後SM)、プロダクトオーナー(以後PO)が誰かわからないメンバーがいる（最近JOINしたメンバや、スクラムをよく知らないメンバ）
スプリントレビューがただの進捗共有会(フィードバックがない、ステークホルダがPOだけ)
プロダクトゴールがない、わからない
完成の定義が明確に定められていない
プロダクトバックログをほとんど見ない。（優先度も内容も整理されていないので見る意味がない
タスクの粒度がデカすぎる
- 複数のスプリントにまたがっている
- 進捗やスプリントゴールの達成の度合いが聞かないとわからない
次何をやったらいいのか、リーダーに聞かないとわからない
スプリントゴールの達成を危険に晒すような変更がある
最近JOINしたメンバもいるが、オンライン作業なのでお互いを知る機会がないなど、もはやスクラムとは言えないような状態でしたが、これらをチーム全員で自認できただけでも収穫は大いにありました。

改善することは多々あるが、まずは何から始める？

これらの課題を抽出する中で、チームメンバ各々が改善したいことがイメージできてきたのではないかと感じていました。そこで、チームメンバが特にどういった部分に関心があるのかを見極めるために、どんなチームにしたいのかみんなで出し合いました。すると、

一人一人が状況を見て考えて動けるチーム
アウトカムに関心を持てるチーム
心理的安全性を確保した上で議論できるチーム
POなど他のステークホルダとエンジニアの距離が近いチーム
バックログの意図がわかるチーム
情報の透明性があるチーム
越境できる（いろんな技術に挑戦できる）チーム
誰か特定の一人に依存しなくても価値を届けられるチーム

などの意見が出ました。各メンバーが何を重要視したいのか、方向性がなんとなく見えてきました。これらの意思を尊重しつつ、まずはすぐにアクションが取れる足元の課題から改善していくことにしました。

リファインメントは毎日やって、スプリント内で達成できる粒度にまで細かくする
- As-Is: リファインメントはそもそもやってなかった
- To-Be: バックログを生きたものにする。１スプリントで終われる単位まで小さくする。なぜやるのか、何をすればいいのかPO含めた全員の共通理解を得る。完成の定義を決める。見積もる。
デイリーではスプリントゴールの達成状況、見通し、課題を最初に確認する
- As-Is: デイリーは各自のタスク進捗状況の共有になっていた
- To-Be: スプリントゴールが何なのか、毎日思い出す。達成状況を全員で把握する。全員でスプリントゴール達成に向けて作業をする、サポートする。
スクラムイベントのファシリテーションをスプリントごとにローテーションする
- As-Is: ファシリはスクラムマスターに依存していた
- To-Be: スクラムマスターがいなくても各イベントを推進できる。各イベントの開催意義を全員が理解している。
スプリントレビューに持っていけるインクリメントを作るために、完成の定義を用意する
- As-Is: 完成の定義がそもそもなかった
- To-Be:完成の定義に沿ってインクリメントを作成できる。完成の定義の内容を隔週で振り返る。
全てのタスクに完成の定義を適用する
- As-Is: 完成の定義がそもそもなかった
- To-Be: どこまでやればいいのかを明確にする。完成の定義を満たせない場合は、タスクの粒度や切り方、完成の定義の内容、スプリントゴールの決め方に課題があるかもしれない。
スプリントレビューでインクリメントを見せる
- As-Is: 各自の進捗共有の場になっていた
- To-Be: 実際に動くものを見せることでフィードバックをもらいやすくする。
役割を明確にした
- As-Is: 誰がSMで誰かPOかわかっていないメンバがいた。普段の業務で存在感がなかった。
- To-Be: 誰がどの役割なのかを明確にし、各役割のメンバがすべきことや参加すべきスクラムイベントをスクラムガイドに則って実施するようにした。

得られた成果

上記の改善を行ったことで、開発メンバからは概ね良いフィードバックが得られています。
特にリファインメントを毎日行ったことと、完成の定義を作成できたことが大きいと感じています。

１つ１つのバックログアイテムの内容とスコープが明確になり、ボリューム感がわかりやすくなった。
完成の定義が明確に定義されてるので、各タスクの残作業がわかりやすくなった。
タスクの粒度が小さくなり、複数のスプリントに持ち越すようなケースが少なくなった。
リファインメントでプロダクトバックログアイテムの内容と優先度を全員が理解できているので、プランニングがスムーズになった。
リファインメントで優先度について会話しているので、次に何をすべきかを各々で判断できるようになった。
割り込みがあった時に、スプリントゴール達成に影響があるかどうかで対応の判断ができるようになった。
どのバックログがどういう内容なのかを全員が把握できているので、優先度や課題について会話する時の意思疎通がスムーズになった。
スプリントレビューでデモや成果物の提示をするようになったので、フィードバックが増えた（これはPOの取り組みでスプリントレビューの参加者が増えたことも大きいです）。
毎日リファインメントをし、スプリントレビューのファシリテーションもPOが行うようになったため、POと会話する機会が圧倒的に増え、POの存在感が増した。
デイリーでスプリントゴールに対する状況を中心に会話することで、スプリントゴール関連の作業に全員で協力できるようになった。

今後について

まずは自チーム内で対応できる足元の改善を行い、それによって一定改善が得られたと感じています。
しかし、足元の課題を解消したことで、より根本的な課題が今まで以上に浮き彫りになってきました。
それは要件定義のプロセスが完全にブラックボックスとなっており、開発者はデザインまでできた状態から初めて話を聞くという状況で、開発スコープや、どうやって実現するかといった具体的なHowの調整に自由度がないことです。
このプロセスを改善しない限り、フロー効率は今以上には改善せず、ウォーターフォールからの脱却は難しいと考えています。
今後はそういった根本的なところにも手を入れ、プロダクトゴールのSMARTを定義し、日々の開発でそれをどのくらい達成できたのか、アウトカムを全員で追いかけられるところを目指していきたいと思います。