こんにちは、19新卒として入社して今freee関西支社でエンジニアをしているりょう(@liaoziyang)です。この記事は freee Developers Advent Calendar 2019 の 18 日目の記事になります。
スクラムマスタになったきっかけ
組織が成長することによって、当時2,3名だった頃に決めたなんちゃってスクラムの回し方に課題感を感じており「じゃあ、スクラムマスタやってみよう」とジャーマネ (freeeでのマネージャーの呼び方)から言われたことをきっかけにチャレンジすることになりました。ただ、やってみたいと思ったものの、それまで今のチーム以外で働いた経験がなく、最初は結構不安でした。特にスクラムマスタは開発プロセスを守る役割で、しっかりとスクラムを理解しないといけません。その不安を解消するために「スクラム修行」ということで、1週間ぐらいかけて、社内の他のスクラムを上手く実行しているチームのミーティングに参加して、現役のスクラムマスタたちの話を聞いてくるなどしました。
なんちゃってスクラムを改善するため取り組んだこと
アジャイルワークショップ
チームの力を最大限を発揮するために、まずはチームメンバーが共通認識を持ってお互いを信頼する関係を築くことが大事です。作るものや開発プロセスについて共通認識を持つように、東京オフィスから開発プロセスについて詳しい方を招いて、二日間でアジャイルワークショップを開催しました。
内容はこんな感じです。非常に楽しい、学びになった二日間でした。
- プロダクトバックログの価値と作り方
- バックログを低リスクで早く実現する方法の体験(コイン渡し)
- 開発のフローの見える化と無駄の排除(ValueStreamMapping)
- チームと作るものの明確化(インセプションデッキ)
- チームビルディング(ドラッカー風エクササイズ)
- チームの働き方やルールを決めるWorking Agreementの作成
スプリントイベント
今までやってきたスクラムはスプリントを使っていたものの、スプリントのイベントとしてスプリントレビューと計画しかありませんでした。スプリントイベントを省略した分の時間は開発に回せましたが、レトロスペクティブが抜けているため、チームの問題点の意識や改善はできていない状態です。チームより良くするために、レトロスペクティブもスプリントイベントの重要な１つとして取り入れました。
チームとプロジェクト状態の可視化
スクラムは問題を見えるようにするもので、継続的に問題を可視化できる仕組みを保つことによって問題を早期発見し、直していくことができます。問題を発見するために、チームと「今進行しているプロジェクトの状態」を可視化して客観的に分析する必要があります。
平均ベロシティ
ベロシティとは、決められた期間の中で、あるチームが届けることができる要求の量のことです。 これは同じチームメンバーが固定の期間で繰り返している場合においては正しいものですが、チームメンバーの人数や期間が変われば、自動的にベロシティは変わります。特に毎スプリントの作業時間が不定であり、祝日やメンバーの休み、会社のイベントなどより変動します。なのでベロシティそのものはそこまで信頼できる値ではありません。
この図は実際の作業時間とベロシティの推移になりますが、作業時間が安定していないので、ベロシティーも常に変動しています。
一方で、時間の変動を排除すれば、単位時間のベロシティはある程度チームの平均生産性を表すことができます。平均ベロシティを計測して、高めて安定させることを目指して施策を打っています。
この図は実際にスプリントごとで算出した平均ベロシティですが、sprint1とsprint7以外は安定しているように見えます。安定していない週について、なぜこうなったのかをチームで深掘りして、次に活かします。
スプリントバーンダウンチャート
スプリントバーンダウンチャートは残作業の合計や目標日時を可視化することで、進捗が把握しやすくなります。デイリースクラムの前に、BOTがSlackチャンネルに投稿するので、これを元にタスクの調整や作戦を考えたりします。
アジャイルQAの導入
今までは開発プロセスとQAプロセスを分離してやっていたのですが、膨大なテストケースにより、QAプロセスのバッチサイズが大きくなりすぎるところにデメリットがありました。QAであげた修正が間に合わないためにリリース予定がずれるリスクも大きくなります。 そこで、アジャイルQAを導入することにしました。 アジャイルQAは開発プロセスとQAプロセスを分離せず、QAプロセスをスプリント内で入れます。
↓こんなことをしました。
- スプリントイベントにQAチームの担当者に参加してもらう
- スプリントレビューのデモ範囲でQAテストを行う
- 次回スプリント計画時に、前スプリントの開発内容のQAチケットを整理・優先度決め、優先度高い順で消化する計画を立てる
アジャイルQAを導入することで、バグが早期発見、解決できるようになってより高い品質保った状態で開発していくことができるので安心感が高いです。
Tryの管理
スプリントレトロスペクティブはKPT形式でやっていますが、せっかくあげてきたTryがそのまま放置されないように、KPTの最後に今までのTryを振り返ったりします。その中で完了したものは完了マークをつけて、継続して行うものは継続のマークをつけて管理しています。
こんな感じです。
ちなみに、とあるスプリントのTryに「スプリントが終わったらクラッカーを鳴らす」が書いてあったので、実際に次のスプリントからはクラッカーを鳴らすようになりました。予想以上にみんなテンション上がっていたので、良いカルチャーとして続けていきたいと思っています。
最後に
スクラムマスタをやる前には、エンジニアとしてコード書く時間を増やせば多く成果出せるというマインドでしたが、スクラムマスタやってみて、コードを書く時間以外にも、振り返りや改善の時間を惜しまずに確保することも大事だなと思いました。引き続き頑張っていきたいと思います。
明日は、freee OSAKAについて熱く語ってくれる@yoshiさんです。お楽しみに！
