アラート検知型デイリースクラムに移行した話

こんにちは。Groovesエンジニアリングマネージャーのloasnirです。 Groovesにはいくつかの開発組織がありますが、本日はスクラム開発を実践し、私がスクラムマスターを務めているForkwellの開発組織について、日々の検査の場であるデイリースクラムを改善した話をしてみようと思います。

まずスクラム開発を実践している方には馴染みのある話かと思いますが、スクラムガイドによると、スクラムは意図的に不完全なものであるとされています。以下に2020年版のスクラムガイド（日本語）の「スクラムの定義」から抜粋してみます。

スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。

スクラムガイトとは文字通りガイドラインであって、実践するチームの内情に合わせて肉付け（アレンジ）をしていくことが許容されているんですね。

さて、今回の本筋であるデイリースクラムですが、その役割は大きく4つあります。

• コミュニケーションを改善する
• 障害物を特定する
• 迅速な意思決定をする
• その結果、他の会議を不要にする

この4つの役割が果たされている限り、アレンジをする必要はありません。 後に説明しますが、私たちのチームではほとんどの項目に課題が見つかったため、デイリースクラムを改善しようという流れになりました。

デイリースクラムとForkwell開発の歩み

Forkwellの開発は2012年から続けられていますが、紆余曲折あって2021年1月からメンバーを再編して再始動しました。それ以前からスクラム開発は取り入れられていましたが、再出発を機に、まずは純粋なスクラムの形でやってみる運びとなりました。守破離でいう「守」を実践しようという話です。この時は、すでにスクラムガイド2020年版が発表されていましたが、理解が十分ではなかったため2017年版を基準として採用しました。その後2020年版へ移行していくのですが、本筋からは外れるため割愛します。

また、弊社は多様性のある働き方を実践するため、コロナウィルスが世界的な流行となった2020年よりも以前から、リモートワークを推進しています。Forkwellのスクラムチームもこの流れを踏襲しており、すべてのスクラムイベントをオンラインで実施しています。これを実践するために、いくつかのオンラインサービスを利用することにしています。以下に代表的なものをピックアップしてご紹介します。

• Slack
• JIRA
• Miro
• Google Workspace

これらを利用した初期のデイリースクラムが、どんな感じで進行していたのかを見てみましょう。

アジェンダ

1. アイスブレイク
2. 確認パート on JIRA
   1. スプリントゴールの確認
   2. バーンダウンチャートの確認
3. 検査パート on Googleドキュメント
   1. 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
   2. 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
   3. 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
4. 共有パート

これらを毎朝実施し、Googleドキュメントに記録していくスタイルを採用していました。 運用していく中で検査パートの会場がMiroへ移行され、俯瞰的に状態を検査できるようにするなど、細かいチューニングは行われていました。大筋はこの形で2021年9月まで続きました。

Miroでの記録はこんな感じです。

デイリースクラムの様子

課題の発見と対処

スクラム開発にはスプリントレトロスペクティブというイベントがあります。これは「品質と効果を⾼める⽅法を計画する」という目的を持ったイベントで、私たちはKPTという手法をこのイベントに導入しています。KPTではスプリントで起こった事実をKeepとProblemに分類し、次のスプリントで実施するTryを考えるのですが、デイリースクラムについて以下のようなProblemが提起されました。

• アラートの発覚がスプリント後半になり、挽回できない。
• 1人1人の確認に時間がかかり、タイムボックスを超過することがままある。
• 検査パートが作業報告になっている。

これらを解決するために、Tryを考えるパートでは以下のようなやりとりが交わされてました。

• 作業報告になりがちなのは問題？
  • 終わったことを知ってもできる事はないし、その時間がムダなのでは。
  • デイリースクラムの目的は状態検査なので、順調かそうでないかだけで良いはず。
• 各々がアラートを自己申告するという方法について
  • メンバーが十分に自走できている場合
    • それで良い
  • メンバーが自走できない場合、つまり自分でアラートを上げられない場合
    • キャッチアップする仕組みが別途必要
• 最終日はレビューとフィードバック対応で終わる段取りが良い
• キャッチアップする仕組み
  • ScMの方で検討するが、全体を俯瞰して粗探しできるとよいか？

これを受けて、それぞれに対処を行います。

まずは検査パートをアラート自己申告制に変更しました。これはデイリースクラムの検査パート中で「アラートがある人はいますか？」という問いかけを行う方法です。これによって、各々の確認のための時間を削減でき、タイムボックス内で完了できるようになりました。加えて、作業報告になりがちという問題にも対処できました。

次に、潜在的なアラートを検出する手法についてですが、これは2つの手段を用いることとしました。 1つ目は全体を俯瞰するためのダッシュボードです。JIRAでは利用者が自由にカスタマイズできるダッシュボードが提供されているため、こちらを利用して全体を俯瞰できるようにしました。

ダッシュボード

2つ目は、スプリントのある時点において各種の値がどういう状態になるのが適切なのか？の定義です。現時点ではあまり厳密には決めていませんが、おおよそ以下の様な取り決めにしてあります。前提として、スプリントの長さは2週間です。

• 2日目
  • レビュー詰まってる場合は優先的に見よう
• 4日目
  • レビュー詰まってる場合は優先的に見よう
  • 大きめのタスクはプランニングを確認しよう
• 6日目
  • 大きめのタスクはプランニングを確認しよう
• 7日目
  • レビュー詰まってる場合は優先的に見よう
  • 終わりそうにない課題はPOと相談しよう
• 8日目
  • 今日中に、すべてレビュー中に持っていけるかを確認しよう
• 9日目（最終日）
  • スプリントレビューの準備をしよう

最終的なアジェンダは以下の通りです。

アジェンダ

1. Miroを更新しながらアイスブレイク
2. 確認パート on JIRA
   1. スプリントゴールの確認
   2. バーンダウンチャートの確認
3. 検査パート on Miro
   1. アラート自己申告
   2. ダッシュボードで潜在的な問題を検出
4. 共有パート

効果

いくつかありますが、もっとも効果を実感できている部分はベロシティです。グラフからはちょっと分かりにくいですが、スプリント中盤以降の安定感が増していて、達成見込みが早い段階で立てられるようになりました。このおかげで、スプリント最終日は心穏やかに過ごせる。

ベロシティとチームストレングス

このグラフについての補足

• チームストレングスは直近5スプリントのコミット数の平均値。
• 8/13スプリントのコミット数が突出していますが、これは7/30スプリントでギリギリ達成できなかった分が積まれているから。
• 8/27スプリントでコミット数が減少しているのは、メンバーが長期休暇*1に入り、一時的に離脱したため。

また、当初期待されていたタイムボックスを守るという部分についても達成できており、かつ短くなった時間の中で十分な検査が実施できています。

最後に

今回は、Forkwellの開発組織におけるデイリースクラム改善の話をさせていただきました。スクラムはチームによって適するやり方が異なります。私たちの改善方法が合わない場面というのも往々にしてあるかと思いますが、改善事例の1つとして認識いただけると幸いです。

最後になりますが、私たちGroovesは一緒にサービスを良くしていってくれる仲間を絶賛募集中です。Forkwellの開発組織へ配属になった暁には、この改善の続きを私たちと一緒にやってみませんか？興味を持っていただけた方は、是非弊社の求人をご確認ください。

*1:弊社には一定の条件を満たすと長期休暇を取得できる福利厚生制度があります。詳しくは弊社求人情報をご覧ください。