テクノロジー

新規プロジェクトへのスクラム導入(第二回)

挨拶

こんにちは、BE部の吉江です。
普段はサーバーサイドエンジニアとして、広告配信システムの開発・運用を担当しています。

現在私が担当しているプロジェクトではスクラム開発を導入しています。
この記事では、D2Cの開発現場で実際にどのようにスクラム開発が行われているかを2回に渡ってご紹介しています。

前回の記事では、主にスクラムを始めるにあたっての準備を紹介しました。
今回の記事は、実際の私たちの開発現場で各種セレモニーをどのように行っているか紹介していきたいと思います。

この記事の対象読者

本記事の対象読者・前提知識は下記を想定しています。

対象読者
スクラムの導入を検討している
D2Cの開発の流れを知りたい

前提知識
スクラムに登場する基本的なワードについて理解している

D2Cのスクラム(セレモニー編)

プロジェクトチーム

私たちのプロジェクトは、スクラムマスター1名,プロダクトオーナー1名,開発メンバー9名でスクラムチームを形成しています。
まずは、スクラムプロジェクトで各ロールのメンバーが担っている役割を簡単に紹介します。

プロダクトオーナー

プロダクトオーナーは、プロダクトバックログの作成と管理を主に担当します。
スクラムガイドにはプロダクトバックログの管理について下記のように記載されています。

プロダクトバックログアイテムを明確に表現する。
ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
開発チームが行う作業の価値を最適化する。
プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。
必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。

プロダクトオーナーはスプリント中、次スプリント以降で実施されるバックログの内容の作成や具体化の作業を行いつつ、開発の優先度を決定します。
リファインメントやスプリントプランニング1部でバックログの内容を開発チームに説明し、スプリントレビューでは開発された機能の確認を行います。

プロダクトオーナーが参加するセレモニーは下記の通りです。

  • スプリントプランニング 1部
  • スプリントプランニング 2部(仕様確認のための呼び出しや,見積もり結果の共有で一部のみ参加します)
  • リファインメント
  • スプリントレビュー
  • スプリントレトロスペクティブ

開発チーム

開発チームは、バックログの見積もりと開発に責任を持ちます。
スプリントプランニング2部でストーリーポイントの見積もりと設計を行い、スプリントで実際に開発を行います。
スプリント中はもちろん開発をメインで行いますが、必要な場合は技術的視点で今後のバックログについての相談をプロダクトオーナーと行います。

開発チームが参加するセレモニーは下記の通りです。

  • デイリースクラム
  • スプリントプランニング 1部
  • スプリントプランニング 2部
  • リファインメント
  • スプリントレビュー
  • スプリントレトロスペクティブ

余談ですが、私たちの開発チームの人数は9名で、スクラムガイドで推奨されているギリギリの人数です。
個人的には、人数が多くなることでチーム内での発言者の偏りが生まれてしまうなど、チームとしてまとまって動くことが難しくなるように思いますし、検査によって得られたフィードバックや反省点も自分ごととして捉えづらくなっていくように感じています。
今後はスクラムチームを分割するなどの対応が必要となりそうです。

スクラムマスター

スクラムマスターは、スクラムチームの支援をメインに行います。
サーバントリーダーというような表現がよくされますが、スクラムチームが成果を上げるためのあらゆる支援を行うのがスクラムマスターの役目です。
スクラムの知識の共有や、より上手く回るためのアドバイスなどをプロダクトオーナーや開発チームに提供していきます。

役割上、スクラムマスターは全てのセレモニーに参加します。

  • デイリースクラム
  • スプリントプランニング 1部
  • スプリントプランニング 2部
  • リファインメント
  • スプリントレビュー
  • スプリントレトロスペクティブ

スプリントのスケジュール

私たちのスクラムチームはスプリントを2週間で行っています。
前回の記事でも紹介しましたが、各セレモニーのカレンダーは下記のようになっています。

以降では、実際の各セレモニーをどのように行っているか紹介していきます。

スプリントプランニング 1部

スプリントの初日に、スクラムチーム全員で集まりスプリントプランニングを行います。
スプリントプランニングは1部と2部に分けて行い、合わせて8時間をタイムボックスとしています。

スプリントプランニング1部は2~4h程かけて行い、プロダクトオーナーが開発チームに今回のスプリントで開発するプロダクトバックログアイテム(PBI)の内容とゴールの説明を行います。

プロダクトオーナーは、着手可能なレベルに具体化できたPBIの内容を説明します。
(私たちの場合はリファインメントで事前説明 → プランニング1部でFIXしたPBIを説明 という形式になることが多いです。)
また、説明の際にはPBIの受け入れ基準を必ず説明に含めるようにします。
ここで説明された内容を元に開発チームは実現方法を検討していきますので、プランニング1部では開発チームがPBIの内容を理解できていることがプランニング1部の完了条件としています。

スプリントプランニング 2部

スプリントプランニング2部は基本的には開発チームとスクラムマスターが出席します。
PBIについての追加の質問や, スプリントゴールの共有のためプロダクトオーナーが呼び出されることもあります。

開発チームは1部で説明されたPBIの内容を元に、PBIの受け入れ基準と完了の定義(完了の定義は開発チームが決定します)を満たす機能をどのように作成するかを検討していきます。

スプリントプランニング2部の完了条件は下記の通りです。

  • スプリントゴールの設定
  • スプリントバックログの作成
  • 設定したスプリントゴールとその達成方法をプロダクトオーナーへの共有

この作業にかける時間は大体4h程度となることが多いですが、プランニングの当日のうちに決まらなければ翌日に持ち越す場合もあります。

スプリントゴールの設定

スプリントゴールの設定では、チームのベロシティとストーリーポイントという概念を利用して、チームが今回のスプリントでこなせるPBIを決定していきます。
ストーリーポイントとは、開発チームがプロダクトバックログの見積もりに利用する架空の単位です。
基準となるストーリー(簡単な機能の実装など)を「XXポイント」と仮定しておき、この基準と比較した場合に見積もり対象のストーリーはどれくらいの数値になるだろうか?という相対値で見積もりを行っていきます。
スプリントの中で開発チームがこなせたストーリーポイントがベロシティとなり、次回以降のスプリントゴール設定の基準となります。

私たちのチームでは、スプリントプランニング2部の最初に前回のベロシティと今回スクラム活動にあてる時間を確認します。
スクラム活動にあてる時間は、正確なベロシティを出すために利用します。
事前にスプリント期間から休みの予定やスクラム以外の活動に当てる時間を除外し、実際にスクラム活動が行える時間を計算しておきます。
(2週間スプリントの場合でいうと、8h×10営業日のうち何%をスクラムに費やすかを事前に明らかにしておくことで、正しく比較が行えます。)
確認が終わったら、これらの数値を元に、今回の目標ストーリーポイントを設定します。

次に、PBIごとのストーリーポイントを計算していきます。
PBIのストーリーポイントが決定したら、目標ストーリーポイントと比較しながら実現可能なスプリントゴールの検討を行います。
優先度順でPBIをこなした場合に中途半端なスプリントゴールとなってしまう場合には、プロダクトオーナーと相談の上、優先度の組み替えを依頼する場合もあります。

プランニングポーカー

私たちはPBIのストーリーポイントの見積りは、プランニングポーカーという作業で行なっています。
プランニングポーカーはタスクの規模を相対的に見積もるための手法で、[?,0,1,2,3,5,8,13,20,40,∞]の数字のカードを使い、各開発メンバーが思うストーリーポイントを一斉に提示し、それに対する根拠を述べ合うことでストーリーポイントのすり合わせを行います。
(カードの数値には、細かい数値にこだわりすぎないという意味でフィボナッチ数列がよく使われるようです。)

最終的なストーリーポイントの決定の仕方はチームによって異なりますが、私たちの場合は下記のような手順で最終的なポイントを決定します。

  1. 開発メンバーそれぞれが見積もりを行い、一斉にカードを提示
  2. 提示された数がバラバラの場合 → 一番高い数値と低い数を出したメンバーがその根拠を述べ1に戻る
  3. 提示された数が隣り合った2種の数のみの場合 → 2種のうち高い側の数でストーリーポイントを決定

この作業を見積もる対象のPBIがなくなるまで繰り返し、全てのPBIのストーリーポイントを決定します。

スプリントバックログの作成

スプリントゴールが決定し次第、スプリントバックログを作成していきます。
スプリントバックログは実際の開発作業をチケット化したもので、最大でも1日以下のサイズになるように作成します。(チケット毎のサイズが揃っているとよりいいです。)
PBIをスプリントバックログに変換するには作業が明らかになっている必要があるため、ここでPBIの受け入れ基準と完了の定義を満たすための設計を行います。
設計を行なった結果、当初見積もったストーリーポイントが正しくなかったことがわかることがありますが、その場合はストーリーポイントを見直し、スプリントゴールを更新します。

全てのスプリントバックログが完成したら、スプリントゴールと見積もり内容をプロダクトオーナーに共有し、スプリントプランニング2部を終了します。

デイリースクラム

開発チームとスクラムマスターは毎日デイリースクラムを行います。
デイリースクラムは簡単に言えば朝会のようなもので、毎日同じ時間に「前日やった作業」「今日やる予定の作業」「困っていること」を開発メンバー全員が報告します。
また、スプリントゴールを達成するためにチームでどのようにな動きをするか?を相談する場でもあります。
タイムボックスは15分ですが、その場で話し合うと15分をオーバーしてしまうような話題については、デイリースクラム終了後に再度話し合いを行います。

私たちの場合は、デイリースクラムは毎朝10:30~10:45の時間に下記の手順で実施しています。

  1. 今日のスクラム外予定の確認
  2. 開発メンバー毎に「前日やった作業」「今日やる予定の作業」「困っていること」を報告
  3. スプリントゴールに向けた動きの確認(問題なく進めているか?)
  4. レトロスペクティブで作成したTry,Actionの確認
  5. その他共有事項の確認

デイリースクラムは日々同じことを発表するため、報告して終わり、ということになりがちですが再計画の場ということを意識するために3の手順を行うようにしています。
また、当初はファシリテーターはスクラムマスターが行なっていましたが、現在は開発メンバーの持ち回りで行うようにしています。

リファインメント

スプリントの中間の水曜日にはリファインメントを行います。
リファインメントにはスクラムチーム全員が参加し、プロダクトバックログの詳細の追加, 見積もり, 優先度の並び替えを行います。
タイムボックスは特に決まっていませんが、大体3h程度の時間をかけることが多いです。
リファインメントでは大きく2つの作業を行なっています。

直近のPBIの詳細化

1つ目の作業として、直近のPBIの詳細化を行なっています。
こちらはまず、プロダクトオーナーが次回以降のスプリントで実施予定のPBIの内容とゴールの説明を行います。
開発チームは、PBIの実装方法を検討した上で要望や改善案がある場合はプロダクトオーナーに共有します。
議論の結果優先度に変更がある場合は、バックログの並び替えを実施します。

スプリントプランニング1部でもPBIの内容とゴールの説明を行う、と記載しましたが、基本的なPBIの説明はリファインメントで行い、プランニング1部での説明は、内容の復習や細かい変更点の共有という意味合いが強いです。
また、本来この段階でストーリーポイントの見積もりも実施できているとよいのですが、私たちのチームでは詳細なストーリーポイント出しはプランニング2部で行うことになっています。

マイルストーンの検討, 見積もり

2つ目は、まだ先のPBIについての内容検討と大まかな見積もりを行なっています。
先の計画のPBIは内容がアバウトなため、この段階では正確なストーリーポイントを求めることはできません。
一方で、全体のボリュームを把握できていないと開発計画が立てられませんので、必要なタイミングでアバウトな見積もりを行い全体感を把握する作業を行っています。

スプリントレビュー

スプリントの最終日にはスプリントレビューを行います。
スプリントレビューには、スクラムチームとステークホルダーが出席します。
スプリントレビューの目的は、スクラムガイドには下記のように記載されています。

スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。
スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。

私たちの場合は、2~3h程度をかけて下記の手順でスプリントレビューを行なっています。

  1. 開発チームはプロダクトオーナーとステークホルダーにスプリントで完成した成果物の説明とデモを実施します。
  2. プロダクトオーナーとステークホルダーは成果物のレビューを行い、フィードバックを共有します。
  3. 開発チームは今回のスプリントで技術的負債となった項目や課題があれば共有します。

また、開発チームではスプリントレビューの前日にスプリントレビューの準備をする時間を取るようにしています。
スプリントレビューは、単純な進捗報告の場になってしまいがちなので意識してフィードバックを取り入れる必要があります。

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

スプリントレトロスペクティブは、簡単にいえば振り返りの場で、スプリントの最後に実施します。
時間は3h程度かけて行い、今回スプリントの検査と次回以降の改善計画をスクラムチーム全員で話し合います。
私たちのチームでは、KPTAベースでの振り返りを行なっていて、手順は下記の通りです。

  1. 今回のスプリントの実績を確認(バーンダウン, ベロシティなど)
  2. 前回のスプリントのTry,Actionが今回のスプリントで実行できていたか?を確認
  3. 今回のスプリントでのKeep,Problemはどんなものがあったか?を確認
  4. 2の結果を踏まえTryを検討.
  5. Tryからより具体的な行動をActionとして設定する.

振り返りはとても重要で、繰り返し行なっていくことで開発プロセスの改善を目指します。
ここで作成したTryとActionは、次回スプリント期間中に忘れないようデイリースクラムの場で簡単に振り返るようにしています。

まとめ

長くなってしまいましたが、私たちのスクラムチームが行っているセレモニーの内容を紹介してきました。
今回紹介したセレモニー以外にも、開発チームでは知識の偏りをなくすためペアプロ/モブプロや、開発時のソースレビューとは別の定期的なコードレビュー会を行っていたりします。
こういった取り組みは毎スプリントの振り返りでやってみよう!となって実施されることが多く、今後も増えたり減ったりすると思いますがよかったものについてはまた別の機会に紹介していければと思います。

また、もっと詳しく話を聞きたい!うちではこんな風にやっているよ!など、情報交換も今後積極的に行えるといいなと思っていますので、是非お気軽にお声がけいただければと思います。ありがとうございました。


関連タグ