はじめに

こんにちは、Engineering Managerの渡邊です！

ギフティでは『Geek Suit（ギークスーツ）』という行動指針のもと、ビジネスサイドとともにエンジニアもビジネスの成果やプロダクトの価値に向き合って開発していく文化が根づいています。

開発の手法はチームによって異なりますが、1週間または2週間サイクルでのアジャイル開発が多く採用されています。

今回は、とあるチームのアジャイル開発プロセスの改善をお手伝いした話を紹介します。

このチームではgiftee for business事業の基盤となる、法人向けデジタルギフトサービスの案件管理プラットフォームの刷新プロジェクトを行っています。事業拡大に伴う案件数の増加に対応していくための、運用業務の効率化や利用者の体験向上を目的としており、プロダクトマネージャーと開発チームとが一体となって開発を進めています。このチームのリードエンジニアから、「開発チームのアウトプットの質と速度をさらに高めていくために改善のサイクルをうまく回していきたい」みたいな相談を受けたことが今回の支援のきっかけ。 Registed Scrum Master（最近名前が変わったみたい）としては、ぜひお手伝いさせていただきたいということで、早速チームのミーティングに同席させてもらうことにしました。

ふりかえりからはじめる

改善サイクルを効果的に回していくための第１歩として、まずはふりかえりミーティングから見直しをすることにしました。このチームでは、もともと毎回のイテレーションの最後にふりかえりミーティングが行われていましたが、いくつかのトピックを扱うミーティングの1枠として行われていました。そこで、ふりかえりの効果をより高めるためにスプリントレトロスペクティブとして独立した会議体にし、タイムボックスを60分に設定して十分に議論できるように見直しました。

ふりかえりフレームワークは、チームが慣れているKPTをそのまま使うことにしましたが、KPTのやり方は少しだけ見直しました。

ポイントにしたのは、個人としてのKeepやProblemではなく、チームとしてのKeep、Problemを話し合うように意識づけをしたことと、一つひとつのトピックに集中して話し合えるよう、オンラインホワイトボードツールのMiroを利用するように変更したこと。

ホワイトボードツールを使ってデジタルの付箋を貼り付けて話すことで、参加者の視線が付箋に集中して議論が活性化したり、類似する付箋をまとめることで意見を整理したりなど、ワークショップのような雰囲気でふりかえりができるようになりました。

またTryでは、必ず次のイテレーションで達成できるような実効性のあるアクションを最低1つ出すようにしました。どんな小さな改善でもいいので前回よりもちょっとよくする。この積み重ねがチームの自信やモチベーションを高め、結果として生産性の向上につながっていきます。

実際のところ、ここに書いたようなミーティングスタイルの改善はただの小さなきっかけで、チームは自律的に議論を活性化させていき、毎回のふりかえりで実効性のある改善アクションが実行されていくようになりました。

もともとギフティのエンジニアリング組織はボトムアップ型で、主体的で自走力のあるメンバーが揃っていることもあって、プロセス改善の支援と言っても実はフレームを少し整えるだけで、あとは自然と改善が回るようになっていきました。

リファインメントの時間を増やす

ふりかえりの中でたびたび出てきたのが、バックログアイテムがイテレーション内に完了しない、という課題。これは本当によくあるというか、自分もスクラムはじめたばかりの頃はずっとこうだった思い出が。

未完了のアイテムが増える一般的な要因としては、プロダクトバックログアイテムが1イテレーション内で完了できるサイズになっていない、十分に詳細化されていないために開発を進めていく中で関係者への確認が必要となる、場合によってはスコープが変わってしまう、などがよくあるケースです。

スクラム開発では、バックログリファインメントというイベントでプロダクトバックログアイテムを詳細化したり分割したりして、対象を小さくすることで開発がスムーズに進むように設計されています。ところがスクラムガイドには、リファインメントをいつ、どのくらいの頻度で実施すべきかが明示されていません。このためリファインメントの不足によりプロダクトバックログアイテムが十分に詳細化されず、イテレーションの中でアイテムを完了にしきれないということが起こりがちです。

そこで、このチームではリファインメントを毎週定例で実施するようにし、プロダクトバックログアイテムの詳細化に力を入れることにしました。さらに、リファインメントへの理解を深めるために『リファインメント本格入門』という勉強会を開催し、チーム全員でリファインメントについてを学びました。

ここでは、プロダクトバックログアイテムをうまく扱う上で鍵となる「ユーザーストーリー」や「バーティカルスライス」、「なぜ相対値で見積るのか」「準備完了の定義とは」などについてを学び、チームでどのように取り組むかを話し合いました。

プロダクトバックログに積むストーリーとタスク（epicとissue）を混同しないようにプロダクトバックログとスプリントバックログをちゃんと使い分けよう、スプリントバックログに相当する粒度のタスクは直近のイテレーションで取り組むものだけバックログに積もう、などの運用上の決め事も、チーム内でどんどん決まっていきました。

そういえば前職時代でも、バックログアイテム未完了問題への対策として、外部コーチを招聘してリファインメント研修を受けて、チーム全体で少しずつうまくなっていったという経緯がありました。やっぱリファインメント大事や。

スクラムフレームワークの効能

スクラムとはフレームワークでありその中身は自由に実装することができます。フレームワークの「型」は重要ですが形式だけ取り入れてもあまり効果はあがりません。効果的に運用するためには、プラクティスの背景にあるコンセプトや理念をチームの全員が理解する必要があります。

そこで今回、チーム全員でスクラムガイドを読み込む輪読会を開催し、ガイドに書かれていることを自分たちの取り組みに照らし合わせて深堀りするディスカッションをしました。

2020年版スクラムガイドは、従来版よりもやや抽象度が高く記述されています。これを読むだけで実践していくのは割と難易度高いのですが、チーム全員で読み込んでそれぞれの解釈と意見を交換することで、具体的にどう実践していくべきかの理解を深めることができました。ちなみにこの輪読会も、レトロスペクティブで出た改善アクションの1つです。

このように、チームに自走力と目的意識があれば、プロセスの枠組みが安定するだけで自然と改善のサイクルが回り出し、プロダクト価値にフォーカスしてデリバリー速度を高めるためにチーム全員が自分たちのやり方で取り組むことができます。

この『チーム全員で改善を繰り返してプロダクト価値の向上にコミットする』ことができるのが、スクラムフレームワークの効能だと、今回改めて感じました。

まとめ

書籍『More Effective Agile』では、効果的なアジャイルのよい出発点として、スクラムから始めることが薦められています。自分自身のこれまでのスクラム経験をふまえてもこれには本当に共感します。

とはいうものの、スクラムガイドにある「スクラムは省略して適用すると効果が制限される」という記述に引っ張られすぎて、最初から「完全なスクラム」を目指そうとしすぎることにも注意が必要だと思っています。形だけスクラムにすることは本質的ではなくて、「チームをいい感じに改善したい」という思いがあり、直面する課題の解決のために色々試した結果が自然とスクラムにたどり着いたというのが一番いい取り組み方だと思っています。

内発的動機から改善が実践されていくのは、質の高いプロダクトを作り早く世に出したいという強いWillがあるからこそ。チームの支援を通してギフティのエンジニアの自走力と意欲の高さを実感した取り組みでもありました。余談ですが、たまにはチームの支援だけではなく自分も1人のスクラムマスターとしてチームにがっつり入りたいなーと思ったりもしました。

こんな自走力高いギフティのエンジニアチームに少しでもご興味をお持ちいただけましたら、ぜひカジュアル面談にお越しください！

最後までお読みいただきありがとうございました。