ストーリーポイントが時間じゃない理由

工数見積というとどんな尺度を想像するだろうか？一般的には時間が考えられる。他にも人日や人月といった人件費に関する尺度が使われることがある。

スクラムでは工数をどう考えているか。スクラムにはストーリポイントという工数の尺度がある。これは、ウォーターフォールなど他の開発プロセスが採用する尺度とかなり異なる。ストーリポイントは時間ではない。相対的な尺度と言われる。

ここで疑問になるのは、どうして時間ではないのかという点だ。時間を尺度にしたほうがスケジュールが立てやすいのではないだろうか。

チーム主義のスクラムは全体速度に注目する

スクラムはチームでの成果を重視する。個人のパフォーマンスはチームを支えるが、個人にはあまり着目しない。そういう原則がスクラムにはある。

もし、時間で見積りをした場合、個人のパフォーマンスを色濃く反映したものになりがちだ。例えば、同じタスクをこなすにしても、Aさんなら1時間、Bさんなら2時間といった具合だ。しかし、本当に知りたいのは開発チーム全体でのベロシティ(速度)だ。「この開発チームの平均ベロシティは1スプリントで80ポイント」という様に表現できるようになる。開発チームのベロシティがわかるようになると、プロダクトバックログ全体がどのくらいの時間で終わるかが見えるようになる。

一歩進んで、ポイントで見積るようになると、チームメンバー全員が共通した基準で見積ることができるようになる。時間で見積る場合は、個人ごとに基準があるため全員で同じ基準を作ることは困難だ。

「扱いやすさ」と「ある程度の正確さ」のバランスを取る

ストーリーポイントは相対的な値だ。ストーリーAはストーリーBに比べて大きいか小さいかを判断するだけである。5秒で答えが得られる。科学的な根拠はないものの、絶対的な大きい時間を把握するより、相対的な小さい数字のほうが人間は直感的に理解できる。例えば「ユーザは商品を検索できる」というストーリーの実現に46時間と言われるより、「ユーザは商品の一覧を見れる」が8ポイントだとしたら「ユーザは商品を検索できる」は13ポイントと言われる方が直感的に理解できるのではないだろうか。

スクラムは、ビジネス要件が日々変わるプロジェクトで、開発がそれに追いつけるようにするための開発プロセスだ。時間ベースの見積もりは、それだけで大仕事になることがある。設計や仕様を明確に決めきらないと、妥当な時間が算出できないからだ。

例えば、ユーザ登録を機能を考えたときに、詳細な時間を見積ろうとすると、画面をどうするか、機能をどうするか、データベース設計をどうするか、内部設計はどうかなどと詳細項目が多数ある。これらの詳細な見積もりは1時間では到底終わらない。

プロジェクトの規模にもよるが、ストーリーの数が50個になったとする。これらごと詳細な見積もりに3時間かかるとしたら1,500時間を見積りに費すことになる。変更になるかもしれないストーリーに多大なコストを支払って詳細な見積もりを実施すべきだろうか。

仮に詳細な見積もりを成し遂げたとしよう。ビジネスや要求が変化しやすい状況下では、頑張って見積もった機能を作らないことになることもある。見積もりにかけた時間が無駄になる可能性があるということだ。そして、追加の機能案が出てきたら、また見積もりをしなければならない。

計画変更時に柔軟に対処するためも、計画時のコストを多大に支払うべきでない。直感で決めた見積もりでも8〜9割の精度があると言われている。 (要出典)