フクロウラボのスクラム開発の中身をお見せします！

はじめに

こんにちは！
dev3 チーム所属の佐藤と申します。
私は2023年の3月にフクロウラボにフロントエンドエンジニアとして入社し、現在は dev3 チームでプロダクトオーナーを務めております。

私が所属する dev3 チームではスクラム開発を導入して、 Circuit X の管理画面のリプレイスを進めています。
スクラム開発を導入している会社は多くあれど、どのようにスクラムイベントを行っているかは会社によって千差万別です。
そこで、フクロウラボのdev3チームではどのようにスクラム開発を行っているのかをお話ししたいと思います。

開発フローの全体像

以下の順でイベントを回して、開発しています。
厳密には、インセプションデッキとユーザーストーリーマッピングはスクラムのイベントではないのですが、今回は開発フローの1つのイベントとしてお話しさせていただきます。

1. インセプションデッキ
2. ユーザーストーリーマッピング
3. バックログリファインメント
4. スプリントプランニング
5. スプリントレビュー
6. スプリントレトロスペクティブ

各イベントごとに焦点を当てていきましょう。

1. インセプションデッキ

新たにスクラムを始める前に必ず行っています。
参加者は開発チーム全員です。
どんな機能を作るのか、対象となるユーザーは誰か、開発優先度などの共通認識を揃えるために行います。
dev3 チームでは10の質問から以下を取り上げ、話し合っています。
Miro を使用し、後で振り返れるようにインセプションデッキを組みます。

・我々はなぜここにいるのか
・エレベーターピッチ
・やらないことリスト
・期間を見極める
・ご近所さんを探せ

一部公開用に加工しておりますが、このようなテンプレートを用意して、話しています。

この質問を取り上げたのは以下の理由からです。

• どんな機能を誰のために作るのかを明確にしたいから（我々はなぜここにいるのか）

• 誰向けのどんなプロダクト、機能を開発するのかの共通理解を持ちたいから（エレベーターピッチ）

• このスクラムでどんなことに取り組み、逆にどんなことはしないのかをはっきりさせたいから（やらないことリスト）

• いつまでにリリースしたいかの共通理解を持ちたいから（期間を見極める）

• 困った時に頼れる人を事前に知っておきたいから（ご近所さんを探せ）

2. ユーザーストーリーマッピング

インセプションデッキで誰のためのどんな機能を作るのかを決めたら、次は要件定義を行っていきます。
dev3 チームでは、開発チーム全員とステークホルダーが集まって、ユーザーストーリーマッピングを行っています。

ユーザーストーリーマッピングについては過去に dev3 チームのメンバーが記事を上げていますので、以下の記事もぜひご覧になってくださいね。

3. バックログリファインメント

ユーザーストーリーマッピングを終えたら、バックログリファインメントを行います。
開発メンバー全員の理解のシンクロ率が高いうちに、作る機能をプロダクトバックログに起票していきます。
参加者はプロダクトオーナー、スクラムマスター含めた、開発チーム全員です。
基本的な進め方は以下の通りです。下記をメンバー全員で行います。

• ユーザーストーリマッピングでマッピングした付箋の一つ一つをプロダクトバックログとして起票する

• プロダクトバックログのストーリーとデモ手順を書き出す

• ユーザーの要求を満たすためのプロダクトバックログが全て起票されているかを確認する

• 起票したプロダクトバックログのストーリーとデモ手順を確認する

• プロダクトバックログの優先度を決め、順番を入れ替える

• プロダクトバックログにポイントを振る

4. スプリントプランニング

次はスプリントプランニングを行います。
dev3 チームでは、1スプリント1週間で設定しています。
開発スコープをプロダクトオーナーがメンバーに共有し、過去のベロシティをもとに、プロダクトバックログをスプリントに入れていきます。

dev3 チームでは、スプリントプランニングの時間内で、スプリントバックログを立てています。
スプリントバックログは GitHub で管理しているので、GitHub の Issue を使用して、プロダクトバックログのデモ手順の内容を開発要件に落とし込んでいきます。

スプリントプランニングを実施したら、あとはひたすら開発です！
開発チームが開発している間、プロダクトオーナーは次のスクラムのスコープの決定や、プロダクトバックログの優先度の調整などを行います。
また、必要に応じて、再度メンバーを召集してバックログリファインメントを行ったりします。

5. スプリントレビュー

開発を進め、スプリントの最終日にスプリントレビューを実施します。
開発スコープを主に利用する社内のユーザーを含め、ステークホルダーを招集し、dev 環境でプロダクトバックログのデモ手順を動作していきます。
dev3 チームでは develop ブランチに push が走ったら自動で dev 環境にリリースされる workflow を構築し、それをスクラムのインクリメントとしています。

作った機能をデモして、機能に不満がないか、どんな UI だったらもっと使いやすくなりそうかをフィードバックしていただきます。
どんなに些細なことでもいいからフィードバックしていただけるように、メンバー全員で意識してレビューに臨んでいます。

dev3 チームでは、スプリントレビュー後すぐにバックログリファインメントを開催することで、レビューでいただいたフィードバックを、新鮮なうちにプロダクトバックログとして起票するようにしています。
フィードバックいただいた機能をいつリリースするかは、プロダクトオーナーがステークホルダーと話し合い、開発優先度を調整しています。

6. スプリントレトロスペクティブ

スプリントレビューを終えると、ラストはスプリントレトロスペクティブです。
dev3 チームでは、Miro で以下のようなテンプレートを作成し、スプリントレトロスペクティブを実施しております。

よくなかったことや、よくなかったことをどう対策するかを話すときはどうしてもトーンが落ちてしまうため、各自お菓子を持ち込んだり、Miro のスタンプを多用してコミュニケーションすることで、暗い雰囲気にならないようにしています。

また、フクロウラボでは全国各地からリモートで働くメンバーがいるため、 Google Meet などのビデオ会議で行います。

プロダクトオーナーとしては、オンラインだから、と妥協せず、メンバーが楽しく、そして次に活かせる振り返りを行える場づくりをしていきたいですね。

最後に

今回は dev3 チームでどのようにスクラム開発をしているのか、中身を詳しくご紹介させていただきました。

スクラム開発はメンバー全員が協力し、主体的にコミュニケーションをとることが非常に大事です。
フクロウラボのメンバーは全員がオーナーシップを持ってプロダクト開発に取り組んでいるので、スクラム開発は非常にマッチしているのかなあと思います。

一方で、各イベントまだまだ改善の余地があるのは事実です。
どうしたら良いプロダクトを提供できるかという軸をぶらさず、一つ一つのイベントに目を向け改善を重ねていきたいですね。