チームのメンバー変更が良い機会だったので、スクラム改善を進めた話

crowdworks.jpでEMをしている久村です。

2023年5月より1つのチームのスクラムマスターをすることになりました。私は開発者としてスクラムの経験はありましたが、スクラムマスターの経験はなかったです。

この記事では、直近チームで改善したことの内容と、そこからの学びを記事にしようと思います。

チーム説明

私がスクラムマスターとして関わっているチームは以下です。

エンジニアメンバーの異動・退職があり人数が減少し、プロダクトオーナー（PO）もメインとサブ（入社年次が浅い）で2名いましたが、サブの方が独り立ちしてメインで担当されるように変更になりました。そのタイミングでスクラムマスターとして私がメンバーに加わりました。

メンバー変更した当初の状況としては、1週間のスプリント期間で以下のスクラムイベントは実施しておりました。

デイリースクラム
リファインメント
レトロスペクティブ
プランニング

この前提の元、チームとして改善したことを共有できればと思います。

改善したこと

スプリントゴールへの意識改善

元々プランニングの中で、次回のスプリントで行うタスクの整理を行い、その中でも特に重要なタスクには「今週の目標」ラベルをつけることはやっており、意識できていないわけではなかったです。

ただ、「今週の目標」が達成できた要因や、達成できなかった要因の深掘りができているかと言うとそうではなく、コミットメントも弱い状況でした。

どのように改善したか？

レトロスペクティブの中で、スプリント評価を行うようになりました。これは組織的（crowdworks.jpのエンジニア組織）な取り組みであり、人事評価にも紐づけるものです。スプリントレビューと近しいところはありますが、あえてスプリント評価として別イベントとして扱っております。

具体的には以下の内容をチームで確認しています。スプリントゴールの確認だけであれば、「スプリントゴールが達成できたか？」だけで良いと思いますが、スクラムをより円滑にすることも意識したいと思い、質問を増やしました。

評価をそれぞれで記入し、内容を共有する運用にしています。

レトロスペクティブだとチーム・個人に関わる幅広い関心ごとを扱いますが、スプリント評価ではスプリントゴールが達成できたかを中心に振り返ることができます。

実際にメンバーからも以下のフィードバックを得られており、良い傾向に感じます。

こちらの評価をする前に、KPTでの振り返りを行っており、それを踏まえて、最後にスプリント評価を行うようにしています。ミーティング時間は多少長くなりましたが、必要な時間だと判断しております。

スプリント評価を行うことで、スプリントゴールへの意識は強くなっていると感じています。

バックログ管理の改善

バックログの管理にはtrelloを使用していました。運用上大きな問題はなかったのですが、タスクの親子関係が作れない点や、バックログが煩雑になっており、より良いやり方を検討する余地がありました。

どのように改善したか？

trelloからnotionへ移行しました。利点としては柔軟なタスク管理ができるようになります。親子関係の管理はもちろん、ボードビューなど見せ方も調整することができます。

notionへの移行に伴い、プロダクトバックログとスプリントバックログを別のボードで管理するようにしました。その際に、アイテムの粒度は以下を意識して管理するようになりました。

まずはプロダクトバックログの説明です。上記の図でいう、Epic、Feature、User Storyを管理しています。

プロダクトバックログのボードビューではUser Storyをカード化して管理しています。

直近だとインボイスの対応を行っており、インボイス対応をEpic、Epicの分解としてFeature、Featureの分解としてUser Storyにしています。

プロダクトバックログはチームの所有物として扱っています。優先度の判断はPOが行っております。

もともとプロダクトバックログのボードがなかったので、タスクの状態・ステータスは可視化できていたが、プロダクトバックログアイテム（PBI）ごとの状態・ステータスは可視化できていなかったです。今回プロダクトバックログを作ることで、PBIごとの状態、ステータス、優先度を視覚的に把握しやすくなりました。それにより、数スプリント先を見通しやすくなることで、どのPBIまでを詳細化しておくべきかを把握しやすくなりました。

またPBIの粒度が大きく、スプリントレビューを導入しづらい状況でもありました。 PBIの粒度をEpicレベルからUser Storyレベルへ細分化し、スプリント毎に1つ以上のUser StoryをDoneにすることを目指せる土台をつくり、スプリントレビューを実施しやすい状態にも改善できました。

次はスプリントバックログの説明です。スプリントバックログは、スプリントで扱うタスク管理をメインで行っております。タスクはUser Storyに紐づけて管理しています。

ボードビューと別にテーブルビューも作ることで、ポイント計算もしやすくなりました。今までは手動でポイントを計算していたのも、自動で計算できるようになり、運用の改善につながっています。

スプリントバックログは開発者がメインで管理しているものです。

スプリント期間中にバックログを見る機会は多く、見やすいバックログであることは重要だと感じます。今回の改善により、タスクの状態や今後やりたいことが把握しやすくなっています。

ベロシティ信頼度の改善

ベロシティの計測は行っていたのですが、そこに対する納得感が低い状態でした。メンバーからも「ベロシティの値への納得感が低い」や、「タスクポイントの基準が曖昧」などの意見がありました。

その状況では、適切な量のプランニングは難しく、積んだタスクへの納得感がないと、やり切るという意欲も弱くなりやすい状況でした。

どのように改善したか？

タスクポイントの基準見直しと、スプリント期間中でのポイント変更を行いました。

タスクポイントの基準見直し

今までは0.5,1,2,3でポイントをつけることが多く、その中でも0.5,1でポイントづけすることが多かったです。その結果、0.5よりも分解したいタスクが発生することもあり、以下のような課題感に繋がっておりました。

そこでタスクポイントを見直すミーティングを行い、基準値のすり合わせを行いました。まずはポイントの考え方として、ポイントは時間見積もりでない、ポイントは相対評価であることを共有し、その上でポイントの基準合わせを行いました。

具体的には、タスク分割できる数を目安にポイントの基準を検討しました。例えばvueファイルの実装タスクの場合は、cssの実装とコンポーネント作成の2つに分割できるので2ptという感じで基準を作りました。タスクの難易度も考慮すると、基準合わせの時間が膨大になってしまうと感じたので、簡単・一般的なタスクを想定した場合に絞りました。（難しめのタスクの見積もりの時は、その都度会話で認識を合わせる運用にしております。）

ポイントの付け方も0.5をなくし、1,2,3,5,8でつけるように変更しました。

FBとしても以下の感想があり、メンバーの納得感も高いと感じます。

スプリント期間中でのポイント変更

実際にやってみたら想定よりもポイントが大きかった、小さかったは起こります。その際には、増加ポイント・減少ポイントを入力してポイントを調整しております。

下の画像の例だと、見積もり時は3ptでしたがやってみたら1pt程度の内容だったため、減少ポイントに2を追記しております。

タスクポイントの基準見直しと、スプリント期間中でのポイント変更を行い、ベロシティ信頼度の改善を行なっております。

プロダクト理解の改善

レトロスペクティブでどのようにするとうまく開発できるかの振り返りはできていました。しかし、何を作ると良いかや、ユーザーはどう思っているかというプロダクト理解についての学習はなかなか進められていませんでした。

どのように改善したか？

評価指標を決める会とスプリントレビューを行いました。

評価指標を決める会

KPIに直接的にヒットしない施策でも、リリース後に必ず全員で施策評価、振り返りを実施できる仕組みをつくること目的に評価指標を決める会を実施しました。

指標を決める際に定量的な指標だけでなく、定性的な指標も含めてチームで納得感のある指標にすることを意識しました。

具体的には以下の内容をチームで会話し、指標を決定しました。

4つの観点を軸に、それぞれで意見を出し、それを集約させる形で指標を定めました。直近の施策では以下の項目を定めております。

（直近の施策として、インボイス発行事業者登録番号の確認機能開発を行っておりました。https://blog.crowdworks.jp/archives/5339/ ）

この場を設けることで、施策についてより考えることができました。具体的に「どうなっていたら嬉しいか？」を考えるためには、施策の背景・目的を理解する必要があり、プロダクトの理解を深める効果があったと感じます。

現在施策は取り掛かり中ですが、施策リリース後にはこの視点での振り返りを行い、プロダクトに対しての学びをより深めたいと考えております。

スプリントレビュー

もう一つはスプリントレビューの実施です。今までこのスクラムイベントは実施できていなかったです。

実施するにあたり、まずは以下の目的を共有しました。

その後、ユーザーストーリー（= スプリントゴール）の説明、デモの実施、デモ内容についての質問、感想共有という流れでスプリントレビューを実施しました。

メンバーからも以下のフィードバックをもらえており、スプリントレビューの有用性を感じられております。

レトロスペクティブや、スプリント評価ではプロダクト自体に関しての学びは少なかったので、その視点での理解を深める場にできていると感じます。

改善を通じて学んだこと

スプリントゴールの意識づけがスクラム改善の起点

上記の改善でも書きましたが、スプリントゴールの意識づけがスクラム改善を進める上でのポイントだと感じました。この意識が持てることで、スクラムイベントの目的やスクラム理論を理解しやすくなりました。

スプリントゴールを達成するために、デイリースクラムでは検査を行うことが重要であり、進捗共有にならないようにすることを理解できました。加えて、検査するためには透明性がないといけないことから、バックログ管理やチームで発言しやすい状況（= 心理的安全性）を作る必要性を理解しました。

またゴールが意識できていたからこそ、スプリント期間内でゴールが達成して時間が余ったらどうする？という点もやっていく中で会話することができ、スクラムへの理解を深められていると感じます。（その際は以下を参考に、勉強、リファクタリング、バックログリファインメントといった活動に時間を使う選択肢を持つことができるようになりました。https://www.ryuzee.com/faq/0054/ ）

スクラムの理解が深まることで、改善のアイデアは増えると感じます。その起点としてスプリントゴールの意識づけがポイントだと思います。

型にこだわり過ぎない

スクラムガイドに書いてあることをまずは試してみたいと思っていましたが、それをやろうとすると大きく変えなくてはいけないこともあります。まずはできるところから変えていき、時間をかけてスクラムガイドのようにしていくのも良いと感じました。

具体的にはスプリントレビューをしたいとなった時です。スプリントレビューをするには、まずはスプリントゴールを立てる必要があり、スプリントゴールの粒度はユーザーに価値が届けれるアウトプットにする必要があります。それを実現するには、現状のバックログの粒度を変更する必要がありと、やりたいことに対して先にやらないといけないことが複数ある状態でした。

それらを改善してからスタートをするのもありだと思いますが、そうするとアクション開始に時間がかかってしまいます。

まずはタスクの列挙でも良いので、それをスプリントゴールと定めて、改善サイクルを回すのも一つの手段ということを学びました。

今回のチーム改善の場合でも、スプリントゴールの意識づけとユーザーストーリー単位でのアイテム管理が可能になったことから、スプリントレビューも実施しやすい状態になっておりました。

スプリントを回す中で、あるべき姿に近づけていくことも大事だと思い、最初の段階で型にこだわり過ぎないことも大切だと感じました。