Retty新卒エンジニアのmoriwakiですこの記事ではRetty webチームのスクラムマスターとしての振り返りを書こうと思います

そもそも

Rettyのweb開発チームは今年4月からスクラム開発の導入を始めていました。

スクラム開発の概略ですが、これはアジャイル開発の手法のうちの一つで、スプリントと呼ばれる一定期間のサイクルを繰り返しながら開発を進める手法です。プロダクトオーナー、スクラムマスター、チームといった役割があり、スプリントごとに行う作業はプロダクトオーナーが決めた(バックログにあるユーザーストーリーの)優先度順に行い小さな単位でリリースされるので、その時々の状況にあうように計画を練り直し、より価値の高いプロダクトをリリースすることが可能です。スクラムマスターはスクラム開発がうまく進むようにチームやプロダクトオーナーを支援する役割を持ちます。より詳しい説明はスクラムガイドをご覧ください。

新卒研修が終わった5月からそのチームに投入されました。自分はチーム開発の経験もない状態でしたが、「1週間のスプリントというものがあり、その中にいくつかのイベントがあり、なんかその時にポイントがタスクごとに割り振られるので、頑張ってポイントを消化しよう」、という非常にあやふやな理解ながらもスクラム開発に従って仕事を行えるようになりました。

7月になって、開発体制の変化によりwebのスクラムチームも1つから2つに別れることになりました。それに伴い、スクラムマスターを募っていました。「スクラムマスターはスクラム開発の中の役割であってチームのリーダー的な存在ではない」、という説明もあり、新卒でもできるのではと思い、さらに個人の課題として「チームへの貢献が足りない」を感じていたのもあいまって、立候補しました

やったこと

スクラム開発の復習

そもそものスクラムイベントへの理解が曖昧だったので『SCRUM BOOT CAMP THE BOOK』などを参考に、このイベントはなんのために集まっているのか、からもう一度確認しました。前述のクオーターでスクラム開発の流れを経験していたので、個々のイベントの役割に関して「実はこういう意図があったのか」という再発見の連続があり、腑に落ちました

一例をあげると、スプリントプランニングで行うストーリーごとの見積もりについてです。最初の頃はストーリーの見積もりをなるべく作業時間として厳密にしていこうと思っていました。が、まだ着手もしていない作業を厳密に見積もることはむずかしく、それには時間もかかります。ストーリーを見積もることで知りたいことは、各々のストーリーがどのくらいの時間で終わるか、ではなく、このスプリントでバックログのどこまでのストーリーがリリースされるかです。ですので、すでに完了したストーリーと比べてどれくらいの規模かで見積もったポイントと、前回のスプリントでどれくらいポイントを消化したかのベロシティで、今回のスプリントに新しくチームが着手できるポイントを算出した方が早くて説得力がある。といったことが経験を通して納得できました。

スクラムイベントのファシリテーション

朝会(デイリースクラム)や振り返りでのファシリテーターとして動きました。

ファシリテーションと言ってもたいそうなことをやったのではなく、デイリースクラムでは一人ずつにやっていることと困っていることを聞く、振り返り(物理付箋を使ったKPT方式)では出てきた内容をグルーピングしたりその内容を書いた人に深掘ったりです。

同じ時間に集まるというリズムが作れたと思うので、そろそろ次は積極的なファシリテーションをやめ、持ち回りにしていきたいと思っています。

わかったこと

Be Agileであることはむずかしい

チームでスクラムイベントをこなし、ベロシティが安定したことに満足して、チームでの開発効率を高めるような「実験」的なことを行なっていませんでした。

実験、というのは試しにチームでやってみる効率を高めようとするなんらかのことで、1スプリント程度やってみてよかったら継続する、悪かったらもうやめる、のようなチーム環境を改善しようとする動きが対してできませんでした。これはまさに、ただプラクティスに従うだけの「 Don't just do agile. Be agile.」ではない状態です。

ある程度安定すると余裕が出てきますが安心せずに、より良くすることを欲張ろうと思いました。

振り返りはむずかしい

KPTの流れに従っていただけで、出てきたTRYに関しても当たり障りのないものが多くなっていきました。

単純に「前回のTRYが達成できてよかった」で終わらせずに、本当にチームの開発効率をあげるような本質的なTRYに辿りつけるような振り返りを行うことが理想です。また、1イテレーションのうちに解決できずに、次の振り返りでもまだ同じ問題が起こっている状態ではKPTをやる意味もモチベーションも薄れていくと思います。なので、KPTに固執せず、別の振り返り方法も試して行こうと思いました。

それに加えて、振り返りを楽しめるようなチームの雰囲気作りにあまり貢献できなかったこともありますモブプロ、ペアプロや、上の「実験」を通したチームを良くしようとするコミュニケーションを繰り返していくことが発言への心理的ハードルを下げますが、そのようなことを行う機会を作れなかったと思います。

チームの出力(ベロシティ)だけに注力してチームの雰囲気を考えないことは、チーム開発の利点が薄れていきます。そうなると、ある段階から開発効率が頭打ちになってしまうと考えられるので、どうにかスクラムマスターとして支援できるようになりたいと思いました。