はじめに
こんにちは。Product Unit SINIS for Instagram開発チームの諸石です。SINIS for Instagramの開発チームではスクラム開発を今年の4月から始めました。今回はスクラム開発を始めるまでに行った準備についてお話しします。これからスクラム開発を始める方の参考になればうれしいです。
1. スクラム開発の理解をチームで深める
スクラム開発を導入する前にやったこととして、SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発という本の輪読会を行いました。この輪読会にはエンジニア以外にプロダクトマネージャーにも参加してもらい、チーム全体で理解した状態になるように進行しました。
もともとテテマーチでは週に1回輪読会があったのですが、一冊の本を読むのに3~5ヶ月ぐらいかかっていました。ただ、スクラム開発を始めるまでに時間が掛かりすぎるとモチベーションも下がるので、1時間の枠を週に2回開催にして5週で読み終わるようにしました。
輪読会では毎回ファシリテーターを順番に回して進行をするようにしています。ファシリテーターの人は輪読会の前に予習としてどこまで読んできて欲しいかをメンバーにアナウンスし、メンバーは事前に指定の箇所まで読んでよく分からなかった所や、認識を合わせたい所などをアジェンダに記載します。輪読会の時間になったらアジェンダに書いたことについて参加メンバーで議論をするという形で進めました。この進め方だとチームで認識を合わせ、納得するまで議論ができたので非常に良かったです。また、議論をしたことでメンバーのスクラム開発に対するモチベーションが上がったのもよかったポイントです。
2. 関係者と役割の洗い出し
スクラム開発の理解が深まった後は各種スクラムイベントや変数を決めていきました。まずは関係者と役割の洗い出しをします。以下のことを決めました。
プロダクトオーナーはもともとスクラム開発に協力的なプロダクトマネージャーがいたのでその人にお願いをし、スクラムマスターについては開発チームから少し距離があるエンジニアにやってもらうことになりました。ステークホルダーは当初事業責任者としていたのですが、スクラム開発を実際にやっていく中で変わっていき、今はステークホルダー ＝ スプリントレビューに招待する人になりました。PBIを作る際に、誰に見てもらうかということを都度決めてスプリントレビューに招待するようにしています。開発するものがバグ修正や使い勝手に関係するのであればカスタマーサクセスの人、ログイン画面や効果測定に関するものであればマーケティングの人、というようにそのプロダクトの開発するものに関わる人を招待することで、現場からの声を貰えるようになりました。
3. スクラムイベントの設定
各種スクラムイベントを決めていきます。テテマーチでは以下のように決めました。
- スプリントプランニング
- 火曜日10:30から1時間
- デイリースクラム
- 火曜日以外の10:30から30分
- スプリントレビュー
- 月曜日15:00から1時間
- スプリントレトロスペクティブ
- 16:00から30分
- リファインメント
- 金曜日14:15から2時間
月曜日は祝日や振り替え休日になりやすいからという経緯で火曜日をスプリントの切り替わりタイミングにしています。スプリントプランニング、デイリースクラムはもともと同じような目的の時間があったのでその時間をそのまま設定しました。スプリントレビューは新しく追加し、スプリントの終わりのほうでステークホルダーが参加しやすい時間ということで月曜日になっています。
スプリントレトロスペクティブはスプリントレビューの後に振り返るようにしています。スクラム開発に絞った振り返りを行うので最初のうちは課題点が多く出ていましたが、スプリントレトロスペクティブを重ねるにつれて課題が解消されてスムーズにスクラム開発を行うことが出来るようになりました。また、最初はスプリントレトロスペクティブの時間を用意してさらに開発組織の振り返りを別の時間で行っていたのですが、まとめてもいいよねということでスプリントレトロスペクティブをなくして開発組織の振り返りで行いようにしました。ただ、スクラムに関する振り返りが出づらくなったので今はスプリントレトロスペクティブを復活させています。
リファインメントはPBIの詳細詰めとタスク分解を行ってプランニングポーカーで見積もり、スプリントプランニングでは割り振るだけという状態になるようにしています。参加者はプロダクトオーナーと開発チームです。メリットとしてチームでPBIやタスクの共通認識を作れる、先の分までPBIが分解できるのでストーリーポイントからどのくらい開発にスプリントが必要などの見積もりができます。タスクの共通認識や設計などをこの時間で行うので、議論が活発になり、最初のころは2時間でも時間が足らないこともありました。慣れていくにつれてスムーズに進めることができるようになります。
4. ツールの選定
スクラム開発で利用するタスク管理ツールを決めました。JiraやRedmineなどいろいろありますが、テテマーチでは開発メンバー以外のビジネスメンバーでも状況確認やPBIの起票ができるように、従業員全員がアカウントを持っているNotionのスクラムボードテンプレートで行うようにしています。
ただ、このスクラムボードテンプレートを導入した当時はNotionにグラフ描画の機能が無かったので、スプリントバーンダウンチャートとベロシティは別途スプレッドシートで集計して表示するというように手動で運用しています。現状この運用は属人化しているので何かしらの改善は今後必要になりそうです。
5. スプリントの周期を決める
スプリントの周期として1週間を1スプリントにするか、2週間を1スプリントにするかということを決めました。観点としてはスプリントレビューで見せるものを1週間で作れるか？2週間いるか？という観点です。テテマーチでは1週間1スプリントにしています。1週間1スプリントだと、それに合わせてPBIの粒度も小さくする必要がありました。スクラム開発を始めて最初のほうはPBIのサイズが大きすぎて1スプリントに収まらなかったり、1スプリントで完了したPBIが0だったりしたので、ベロシティの数値が集計しにくいといった問題が発生していました。PBIのサイズを調整してからは集計もできるようになったので1週間1スプリントでも問題なく進めることが出来るようになりました。
終わりに
テテマーチでスクラム開発を始めるまでにやったことを紹介しました。テテマーチ流にカスタマイズしている所もありますが、スクラム開発に切り替えてのメリットも享受できています。実際にやってみて変えたほうが良さそうなところなどもあったので、今後改善編ややってみての感想のブログも公開します。
テテマーチでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ herp.careers
エンジニアチームガイドはこちら！ tetemarche01.notion.site
