こんにちは、エンペイでエンジニア兼スクラムマスターをしている小口です。
この記事では、今年8月にスクラムマスター研修を受講した後に研修で得た知見をもとに行ったスクラムマスターとしての活動をご紹介します。
研修を受けることになった背景
エンペイでは昨年5月頃からスクラムチームを組んでいましたが、今年4月にenpayチームと新規プロダクトチームの2チーム体制になりました。
そのときにenpayチームにいたスクラムマスターが新規プロダクトチームへ移動し、enpayチームにはスクラムマスターが不在の状態になりました。
2022/06時点のエンジニア組織。2022/12現在でも人数は異なりますがこの2チーム体制です。
その後しばらくスクラムマスター不在だったのですがスクラムをもっとうまく回したいと考え、CTOと相談した結果、今年の8月に会社負担で研修を受講できることになりました。
受けた研修コース
Scrum Inc.認定スクラムマスター研修を受講しました。
この研修は2日間オンラインでアジャイルやスクラムについて学び、60%は講義、40%がワークで構成されていました。
講義はアジャイルとは何かから始まり、スクラムの3つの役割・5つのイベント・3つの作成物やスクラムパターンなどを学びました。
各テーマを講義で学んだ後にワークを行い、5〜6名のスクラムチームを組んでプロダクトバックログの作成、優先順位付け、プランニングポーカーなどを体験しました。
個人的にはオンラインの研修で質問しづらくないかを危惧していたのですが、休憩を兼ねた質問タイムがあり、各チームに付いているインストラクターの方へ質問できたのが良かったです。
ワークで使用していたボードにあらかじめ質問を書いておくか、質問タイムのときにその場で疑問に思ったことを質問する形式でした。
研修を受けた後に取り組んだこと
前提
enpayチームでは前述のとおりすでにスクラムが採用されており、5名でチームを組んでいました。
が、研修で知った内容すべてが実践されているわけではありませんでした。
そこで研修後、スクラムマスターとして以下の内容を実践し、開発プロセスの改善に取り組んでいくことにしました。
- スクラムパターンの実践
- 妨害リストの作成と障害の共有・対応
スクラムパターンの実践
スクラムパターンとはチームの生産性を高めるためのスクラムにおける必勝パターンで、以下のページで公開されています。
実践したスクラムパターンは以下のとおりです。
昨日の天気の計測
スプリントごとのベロシティはJIRAを使って計測していたのですが、稼働人日を加味したベロシティまでは把握できていませんでした。
例えば、全員がフルでスプリントを走りきった場合を100%として、祝日やチームメンバーの休暇により100%の稼働ではなくなることがあります。
その分を加味して以下の計算を行い、真のベロシティを算出しています。
実際のベロシティ / 稼働人日(%) = 真のベロシティ真のベロシティの算出により、ベロシティが低下したことの原因から稼働日数の増減による影響を排除して検討できるようになりました。
スウォーミング
一定の規模の開発を並行すると明らかにチームの開発効率が落ちる傾向があったため、マルチタスクを回避するために、研修を受ける以前にも以下の取り組みを行っていました。
- リソース効率からフロー効率へ
- プルリクエストのレビューを最優先にする
- プルリクエストが複雑な場合はプルリクエストを分割したり口頭でレビューする
詳細は以下のブログやスライドをご参照ください。
ですが、実際コンテキストスイッチがどのくらい発生しているかを可視化できていなかったため、「なんとなくリソース効率に陥っているかも…？」レベルの認識しか持てていませんでした。
そこで、タスク管理に活用しているJIRAのボード上に「PENDING」列を追加しました
他の優先度の高いタスクが舞い込んできた、などの理由から一度作業し始めたタスクを中断するときに、この列へタスクを移動させます。
JIRAでは、チーム単位で「PENDING」列に置くタスクの最大数を設定でき、最大数を超えると列が黄色くなります。
「PENDING」列を導入した当初はPRレビュー待ちのタスクも「PENDING」列に置いていましたが、コンテキストスイッチの原因がPRレビューなのかそれ以外かを可視化するために「PRレビュー中」列を追加しました。
こうすることでタスクの滞留が把握でき、コンテキストスイッチが発生していることがわかるようになりました。
デイリースクラムでこのボードを見てタスクが滞っていそうなら、手が空きそうな人が別タスクに着手せず既存のタスクで協力できるところに入れないか検討するようにしています。
割り込みのパターン
緊急で修正しなければならない不具合が起きた場合などスプリントプランニング時には計画に無かったタスクが割り込んでくることがあります。
今までは割り込み作業がどれくらい発生しているのか可視化できておらず、割り込みが発生する都度JIRAにタスクを追加していました。
そこでJIRAのラベルに「割り込み」を追加し、割り込みが発生したタスクに付与することで、全体でどのくらい割り込みが発生したかを把握できるようにしました。
これにより、1スプリントで発生する割り込みタスクのストーリーポイントを合計し、直近3スプリントの平均値を算出して、スプリント開始時に平均値分のバッファを加味してストーリーポイントを少なめに積むことで、割り込みに計画的に対処しています。
割り込みが発生しない場合はその分追加でどのタスクに着手するか相談して決めます。
幸福指標
ベロシティは生産性のメトリクスではなく、主にプランニングのメトリクスです。
ベロシティが高くても、開発者が長時間労働で疲弊していた、モチベーションが低い、などベロシティに現れないところでチームが健全でなくなっている可能性もあります。
昨日の天気の計測でベロシティは把握できていたものの、チームの健康状態は把握できていなかったためスクラムマスターとしてチームメンバーと1on1をすることにしました。
隔週で15分間、スプリントが終わったタイミングで実施しており、レトロスペクティブで作成したタイムライン上に気分のアップダウンを波線で書きこんでもらっています。
書き込んでもらいながら、何にモチベーションが上がったか下がったかを会話して明らかにしていきます。
黒い波線がモチベーションの波を表しています
最初は以下の質問に対する5段階のスコア付けをしてもらったのですが、隔週でスコアが変化する内容とも思えなかったので上記の方法に変えました。スコア付けは期の終わりなど一定の期間をあけて実施しようと考えています。
- 会社内での自分の役割についてどう感じるか？
- チームについてどう感じるか？
- 会社についてどう感じるか？
- もっと良い感じになるには何があるとよいか？
研修では、幸福度とベロシティには相関があり
- 幸福度が低下すると、ベロシティも低下する傾向がある、という研究結果が出ている
- 幸福度が低いということはチームが重大な課題を抱えていることが想定される
といったことを学びました。
1on1で気分のアップダウンを見ることで課題が潜在化していることに気づくきっかけになり、デイリースクラムやレトロスペクティブなどでの相談へとつながっています。
妨害リストの作成
スクラムパターンによる改善以外にも、妨害リストの作成と障害の共有・対応にも着手しました。
具体的にはスクラムチームにとって障害と思われることを書き出し、チームにレトロスペクティブなどの場で共有、対応策を検討し実施しています。
直近ではスプリントレビューでフィードバックがあまり出てこない問題に対して、
- スプリントレビューの目的はフィードバックを得ることといった前提の共有
- スプリントレビューで説明した内容について、エンジニア以外の社員にもアプリを操作して体験してもらう
といった施策を実施しました。
実際の妨害リストの一部
おわりに
スクラムマスターとして今まで取り組んできたことをご紹介しましたが、これらはすべて実施する前にチームメンバーへ共有し、同意を得た上で実施しています。
目的がわからなかったりチームメンバーが納得して進めていないことは形骸化しがちです。
そうならないために今後もチームメンバーと会話しながら、ユーザーへ価値を届けるためのプロセス改善を継続していきます。
エンペイはエンジニアに限らず様々な職種で絶賛採用中です！
ご興味を持っていただけましたら是非カジュアルにお話しましょう！
