ここまでに取り入れられそうなスクラム要素
カンバンをつかって属人化解消をする話をしてきましたが、ここまでで、うさぎくんのチームでは以下のスクラムの要素がとりいれられそうです。
- デイリースクラム
- スプリント
デイリースクラムは、朝会に似ています。
うさぎくんのチームはいままでも朝会をしていましたが、カンバンがあることや属人化の解消をはじめたことで、自然とそれを囲んで、お互いが今日1日問題なく過ごせそうかを議論するようになりました。
「いまこのタスクに困っている」「このままだと期日に間に合わないかもしれないがどうするといいか」という作戦を立てる場として機能していれば、その場はデイリースクラムとしてある程度機能しているといえます。
次にスプリントですが、これは1つのリリースに必要な最低限の期間をさします。一度決めたら伸ばしたり、短縮したりすることはありません。
うさぎくんのチームでは属人化解消の進捗を1週間ごとにみていましたが、もしリリースに最低限必要な期間も1週間であれば、1スプリント = 1週間として定められそうです。
ほかにも、うさぎくんのチームがこれからの開発をスムーズに進めるために使えそうなものとして、ベロシティというものがあります。
引き継ぎがどの程度すすんでいるかを1週間くぎりで表にしましたが、この1スプリントでこなせるタスクの大きさを合計したものを「ベロシティ」と呼びます。
ベロシティはスクラムのルールにはありませんが、スクラムチームが1スプリントの終わりをどこに設定するかという見通しをたてるために強力な助けとなることが多いので、計測してみることをおすすめします。
スプリントプランニングをしてみよう
うさぎくんは、カンバンのことやチーム開発のことを学習するうちに、「スクラム」という言葉を多く見かけるようになりました。
調べてみると、スクラムにはさまざまな決まりやルールがあるようです。
その中でも、1週間というスプリントと、朝会（デイリースクラム）は、取り入れやすいし、ある程度はすでにできている気もします。
うさぎくんはほかに、「スプリントプランニング」というスクラムイベントが気になったので、チームに取り入れてみようとしました。
スプリントプランニングとは
スプリントプランニングとは、1週間のスプリントが始まる前に、そのスプリントで何をするかを計画することです。
まず、スプリントゴールを1つ決めます。この1週間で必ず達成したいことを表します。
機能をつくる、というゴールではなく、「これを改善することで離脱率を2％下げる」というような、具体的なものがよいでしょう。高い目標ではなく、達成可能な目標にします。
そして、プロダクトオーナーに、そのスプリントゴールを達成するためにやりたいことをPBI（プロダクトバックログアイテム）として挙げてもらいます。
それを実際どう開発・実現するかを「SBI」（スプリントバックログアイテム）としてタスク化します。
ここまでを理解したうえで、プロダクトオーナーと開発者をあつめてスプリントプランニングを開催しましたが、うまくいきませんでした。
優先度の軸を定めよう
このチームでは、プロダクトオーナーから開発者がひとりひとり異なるKPIを課されていました。ある人は離脱率改善、ある人は顧客対応の数、ある人はPV数と、別の目標をもっていました。
まずスプリントゴールを設定する段階で、1つしか持たないはずのスプリントゴールが3つほどできてしまいました。
さらに、プロダクトオーナーがPBIをつくってみても、チームメンバーのKPIが異なるため、優先度をつけることができません。
そこで、うさぎくんはプロダクトオーナーと相談して、いろいろあるKPIのなかで、今最も重視するのはどれかを整理しなおしました。
また、ひとりひとりでKPIを持つのはやめて、チーム全体で離脱率改善を軸に施策をしていくことに決めました。
そのような準備を整えてからもう一度スプリントプランニングをしてみたら、今度はPBIの優先度をちゃんとつけることもでき、スムーズにスプリントプランニングを終えることができました。
スプリントが終わって施策効果を測ってみると、バラバラに施策をやっていたときよりも「離脱率改善によってプロダクトの成長はあるのか」という観点に絞って効果がみられるようになり、プロダクトにとって足りないものやなにが魅力なのかという点がクリアにわかるようになりました。
プロダクト開発の納得感もあがり、以前よりもずっと、チームがひとつの目標にむかって進めるようになりました。
まとめ
スクラム導入をする際は、まずはチーム開発ができる準備が整っているかを確認してください。
そして、今やっていることに似ているものや、少しの変化で取り入れられるものを徐々に適応していくことで、チームやプロダクトが破綻しにくくなります。
スクラムにはほかにも、スプリントレビューやレトロスペクティブ、リファインメントといったイベントがあります。こういったイベントも無理なく少しずつ取り入れていくことを心がけてください。
また、スクラムにおいてもしうまく取り入れられないものがあるとしたら、それはなぜなのかをぜひチームメンバーで考えてみてください。
スクラム導入時に壁にぶつかることで、自分のチームではスクラムは無理だと諦めてしまう人もいますが、そこで断念するのが一番もったいないです。
スクラムを導入するうえで壁として見えてきた部分こそが、チームやプロダクトの成長を妨げているものです。その壁を破壊するためにどんな行動をとるかという決断が、プロダクトやチームの成長につながります。
あなたがもしチームにスクラム導入をしようと思ったら、ぜひスクラムマスターという、スクラムを支援する役割になってください。
そのときは最初から完全なスクラム導入をすることを目的とせずに、まずは徐々にスクラム導入をしましょう。そして、チームがどんな壁にぶつかるのか、それをどう壊すのかということが、スクラム導入時の最大の目的です。
スクラムを導入することをゴールとせず、プロダクト、そしてチームの成長のためにスクラムを利用しようという発想で、うまくスクラムを乗りこなせるようになりましょう。
