この記事は、ニフティグループ Advent Calendar 2023 23日目の記事です。

はじめに

こんにちは。新卒1年目の終わりが近づいてきていることに怯えている西根です。
ニフティでは複数のチームでスクラム開発を採用しています！
ジョブローテーションで配属されていたチームでもスクラム開発（厳密にいうとなんちゃってスクラム開発）を採用していました！
今回は、あるスプリントのレトロスペクティブでTRYとして挙がったデイリースクラムの改善に取り組んだ方法について紹介します。

背景

チーム編成とプロダクト

私が所属していたチームは5人の先輩と、私を含めて2人のジョブローテーションの新人という編成でした。
そのチームが抱えているプロダクトは4つあり、そのうち1つのメインプロダクトについてスクラムで開発を行っているという状況でした。
メインプロダクトのみをスクラムで行っているとはいえ開発メンバーは同じなので、すべてのプロダクトをプランニング時に考慮し、デイリーでの進捗確認も行っていました。

当時のデイリースクラム

TRYに改善が挙がった当時は9:45-10:00の15分間で以下の流れでデイリースクラムを行っていました。

1. チームメンバーがそれぞれ以下を報告する。その間画面共有をしてるファシリの人が、なんとなくGitHubのProjects（開発側のチケット）やNotionのチケット（事業側のチケット）を確認する。
   • 前営業日に行ったタスク、参加したミーティング
   • その日行うタスク、参加するミーティング
2. ファシリがNotionチケット（事業側のチケット）の更新内容を確認する。
3. 今日のアラート確認、運用作業の担当者を確認する。
4. 共有事項や困っていることの相談を行う。

ですが、個人の作業報告で時間を取られてしまい、肝心の相談や共有にあまり時間を割けていませんでした。
また、15分を超えてしまうこともあり、デイリーの直後のミーティングに十分な時間が割けなくなってしまうこともありました。

課題

私は時間がかかりすぎてしまうのは以下が原因だと考えました。

• 誰が担当のタスクかを把握できていないのでファシリは誰に話を振れば良いかわからない（特にスプリントの前半）
• Projectsの今スプリントの中に半期継続の作業（改善タスクやモブプログラミング）や進展がなくなったタスクも含まれており、今スプリントのPBIがわかりづらい

また、開発の進捗に影響がある課題だと感じていた以下についてもデイリーで解決できないかと考えていました。

• slackで行っているレビュー依頼が流れてしまい、2日以上放置になってしまっていることがある

具体的な改善に向けて

TRYに挙がったレトロスペクティブでは、

• 今スプリントの対応内容のストーリーごとに作業を報告する
• それ以外の作業があれば別途共有する

ということになりましたが、実際にやってみると思うように進めることができませんでした。
slackの自分のtime（分報）チャンネルで悩んでいると、別のチームの先輩から見学しにくる？とお声がけをいただきました！（timeはこれがあるから最高ですよね）

改善までの道のり

自分が実際にデイリースクラムの改善までに踏んだ手順は以下の通りです。

1. 見学先のチームへのアポ & 自分のチームへの説明
2. 実際に見学
3. そもそもデイリースクラムとは何かを勉強
4. チームへの共有資料作成
5. チームへ共有し、実際にどう改善するか相談

1つ1つ細かく取り上げていきたいと思います。

1. 見学先のチームへのアポ & 自分のチームへの説明

timeでお声がけしていただいた先輩に行きたい旨を伝えたら、見学先のチームへの共有までしてくださっていました（本当にありがとうございます）
自分のチームとデイリーの時間帯がかぶっていたので、自分のチームには事前にデイリーで「他のチームの見学に行くのでデイリー欠席します」と伝えておきました！

2. 実際に見学

宣言通り見学に行きます。
最初に挨拶をした以外は基本的にそのチームのデイリーを見てメモして…という形で見学していました。
わからないことが出てきたらslackで聞く形を取らせていただきました！手厚いサポートがありがたいですね。

3. そもそもデイリースクラムとは何かを勉強

改善を行うにあたり、まずはデイリースクラムってそもそも何なの？という部分をスクラムガイドと、社内で行われていたスクラムガイド輪読会の資料から考えていきます。（関係ないですが、輪読会や勉強会の資料が自由に見れるとこういうときに助かったりしますよね）

デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。

スクラムガイド 2020年11月

進捗共有の意味合いはありそうな気がしますね。

開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの1⽇の作業の実⾏可能な計画を作成する限り、必要な構造とやり⽅を選択できる。これは集中を⽣み出し、⾃⼰管理を促進する。

スクラムガイド 2020年11月

「実行可能な計画を作成する」ということは、どこまでやる！と決めるということですが、このチームではステークホルダーが多く、割り込み作業が少なくなかったため、ここを完璧に実行する必要はないと判断しました。
（開発者という集団として）「自己管理を促進する」ということは、極論開発者たちが自走していけるならば、デイリーのやり方自体に正解はないということだと解釈しました。
そうなってくると、自分のチームに合ったやり方を模索する必要が出てくることがよくわかりますね！

4. チームへの共有資料作成

見学時のメモは自分の思ったことと事実がごちゃごちゃになってしまっていたので、後から共有用にまとめなおしました。
共有用資料は以下のような構成にしました。

デイリースクラムが目指すべき姿について

これは先ほど学んだ内容をそのまま共有しました。
デイリーがどういう役割でどうあるべきなのか、という部分について考えながら改善アクションを決定したいと考え、共有資料に含めました。

他のチームとの比較（違う / 同じ）

今回見学にいったチームは、扱うプロダクトが自分のチームと近いチームだったので、似ている部分もありました。
反対に全く違う部分もあったため、比較して共有しました。

自分が良いなと思った点

自分のチームで実現できるかや、課題を解決できるかに関わらず純粋に良いと感じたものを以下のようにまとめました！

• GitHub Projectsが整備されていて使いやすそう
  • reviewやwaitingステータスがあるため、状況がわかりやすい
  • Assigneesが登録されていることで担当者が一目でわかる
• 協力会社のタスクについても状況確認を行っている
  • 私のチームでも協力会社にお願いしているタスクが存在するプロダクトがあり、そのプロダクトが属人化しがちで不透明であるということが数スプリント前にProblemとして挙がっていた
• スプリントのゴールがデイリーの進め方をまとめているslackチャンネルのcanvasに書かれている
  • あまり今まで意識していなかったが、デイリーはスプリントゴールに対する進捗の確認なので、確認しやすいことは大切
• レビュー依頼はslackのワークフローで行い、終わるまではチャンネルにピン止めしている
  • デイリーですぐ確認できるのでレビュー依頼が流れてしまうことがない

マネできそうな部分

良いと思った点から実行できそうなものと具体的なアクションを以下のようにまとめました。

• 全プロダクトがまとまったProjectsを作成する
  • 既に上期計画の時に上がっていたが断念していた
  • 今スプリント全体で一気に見れた方が時短&わかりやすい
• issueの管理方法
  • Assigneesを必ず登録する
  • reviewやwaitingステータスを作成する
  • PBIステータスを作成し、そのステータスにはPBIのissueのみ設定する
• レビュー依頼の管理方法
  • PRで管理するのが理想だが、GitHub移行できているのは一部のプロダクトのみなので、暫定対応でピン止めで対応する
  • すでにピン止めが使われているし微妙かもしれない…

5.チームへ共有し、実際にどう改善するか相談

4でまとめた資料をチーム全員に共有しました。
その中でデイリーの進め方を決めたり、Projectsの運用を改めたりなどのアクションまで行いました。

共有したときに取り組んだこと

まずはGitHub Projects自体の改善から行いました。
デイリーの時間でこれを見れば進め方が自ずとわかるものを目指し、以下の4点を変更しました。

• Reviewステータスを追加
• 不要なビューの削除
• 今のスプリントの開発対象のissueが一目でわかるボードビューの作成
• ワークフローを設定
  • プロダクトのリポジトリにissueがopenされたらProjectにissueを追加する
  • issueがProjectに追加されたらstatusをTodoにする
  • issueが再度openされたらstatusをIn Progressにする
  • issueがcloseされたらstatusをDoneにする

また、このProjectが活用できるように運用ルールを2つ新たに定めました。

• スプリントプランニングで担当者が決まったらissueにAssigneesを登録する
• Assigneesが自分でステータスを動かす

こうすることで、Projectを見るだけで進捗を確認し、各々が最大限スプリントゴールに向かって自律的に行動することができるようになりました。

デイリーの進め方

1. 各プロダクトのProjectsを見ながらファシリが担当者に確認
   • 想定より進んでいる、オンスケ、遅れているなどの進捗
     • 必要なフォローなどがあれば調整
   • 今日何をやるかもその時に共有する
2. Reviewステータスのものについて漏れがないか確認する
3. Notionチケットの確認
4. アラート確認、運用作業の担当者確認
5. 共有事項、確認事項

まとめ

実際に他のチームのデイリーに参加するのはとっても勉強になりました！ GitHubのProjectsはどんどん使いやすくなっている最中なので、リリースをチェックして便利に使っていきたいです。
ワークフローが非常に便利で複製することもできるので、複数Projectを1つのProjectにまとめることも簡単にできそうです！
今回は近しいチームのデイリーでしたが、全然違うプロダクトを扱っているチームのデイリーと比較しても面白い収穫がありそうだな～と思いました。
実際にデイリーもやりやすくなった（と思う）ので、見学に行って良かったです！
timeでいろいろ言ってるとこういうチャンスをつかめるのでとても良いですね…すべての作業や疑問をtimeに吐き出していくことを推奨しています。

明日は、上原さんです。クリスマスイブの記事もお楽しみに🎄