開発チームの速度がわからないときは、短い期間で速度を計測する
タスクを書き出し、それぞれに工数を見積もり、いざ開発が始められる段階になると、とある疑問が生まれてくる。「このチームだと本当のところいつプロダクトが完成するのだろうか？」という疑問だ。こうした疑問があると、誰もが不安になりスケジュールに自信が持てなくなる。
この疑問の根源は、開発チームのスピードを誰も知らないことにある。一方で、開発チームの実際のところの速度が分かってしまえば、プロダクトがいつごろ完成するのかの見通しが立てられるようになる。スケジュールについても自信を持てるようになろうだろう。
解決策
開発チームがどのくらいの速度で開発できるかを知るには、短い期間、例えば1週間で計測する。すると割りと早い段階で実際どのくらいの速度が出るかを確認することができる。スクラムではこの短い期間をスプリントと言うが、2週間を1スプリントにするのが基本だ。しかし、開発速度が分かっていない状況では、1週間で1スプリントを回すほうが良い。何故かと言うと、2週間以上になると測定結果がでるまでに時間がかかりすぎるからだ。逆に1週間より短くなると、何も成果が出ないことが多くなり、消化できた工数が算出しにくくなってしまう。チームの速度が分かってしまったら、スプリントは2週間に戻せば良い。
解決策の実施手順
- 計測する期間を決める
- その期間でやることを決める
- やることひとつひとつのポイントを見積る
- 期間が終わったら集計する
ステップ1: 計測する期間を決める
まずはどのくらいの期間で計測するかを決定する。私の経験から初回の計測は1週間が最適だと考えられる。1週間のスプリントを3回以上繰り返せば速度が分かるようになる。
ステップ2: 決定した期間でやることを決める
その期間の中でやること、例えば機能やストーリーを決める。最初はどのくらいの量になるか現時点では分からないため、多めに考えておく。そして、測定期間中にすべて消化できなくても良いという共通認識をチームで持つようにする。目的は、ノルマの達成ではなくチームのパフォーマンス分析にあるからだ。
ステップ3: やることひとつひとつの工数を見積る
決定したやること全部にかかりそうな工数を見積る。この時工数は具体的な時間ではなく、ポイント という単位を使う。このポイントは、ストーリーポイント とも呼ばれる。
なぜこのようなポイントを使うかというと、速度の把握には数時間の精度は必要がなく、時間での見積りは時間がかかるからだ。ポイントは相対的で、あのタスクよりこのタスクのほうが大きいといった捉え方をする。
このポイントは、0, 0.5, 1, 2, 3, 5, 8, 13, 21という値を使う。0ならばそのタスクの実施にはほぼ時間がかからないことを意味し、0.5ならすこし、1ならまぁまぁ。3ならそれなり、といった具合だ。
ステップ4: 期間が終わったら集計する
決定した期間が終わったら完了したタスクのポイントを合計する。
このとき、40ポイント完了していて期間が1週間であれば開発チームの速度は1週間で40ポイントである、と言える。1週間で全員の稼動が5日であれば1日8ポイントの速度がある。
速度がわかれば、作ろうとしているプロダクト全体がどのくらいで完了するかが判明する。例えばプロダクト全体のポイントを見積り、それが600ポイントだとすると、600÷40でそのプロダクトの完成におよそ15週間かかるだろう、ということだ。