[工数vsポイント]スクラムの相対見積もりを再考してみた
まえがき
みなさんこんちは、こんばんはtsucciです。最近はエンジニア兼スクラムマスターとして活動しているのですが、スクラムにおける相対見積もりについて論争となる場面があったので、この機会に再考してみたいと思います。テーマはこちらです。
- 工数とポイントは可換であるか?
注)本記事は、スクラム開発をある程度理解されている方を対象としています。
工数見積もり
先に対となる工数見積もりについて考えてみます。とあるプロジェクトがあるとして、
本プロジェクトは全部で100タスクあり、1タスクあたりの平均工数は4時間である。
この場合、プロジェクトの完了に必要な工数は400時間となる。
(1人日=8時間稼働とした場合)
- 1リソースの場合:50人日→バッファ込みで60人日
- 2リソースの場合:25人日→バッファ込みで30人日
みたいな見積もりになると思います。筆者も「分かりやすい!」と思っていた時期がありました。
気になる点
1タスクあたりの平均工数は4時間である
便宜上平均をとっていますが、問題なのは数値の根拠です。一体誰が担当する想定なのでしょうか?ベテランエンジニアと新米エンジニアが同じタスクに対して同じ工数が必要でしょうか?工数見積もりがダメだというつもりはないので、念の為よく使われる手法を紹介しておきます。(気になる方は検索してみてください)
- 類推法
- 係数法
- 3点見積もり法
要点は、工数見積もりが「期間」の見積もりであるということです。
相対見積もり
続いて相対見積もりですが、一言で言うと「作業量」の見積もりです。例えば、
ある運動場の50mトラックの距離を5ポイントとする(これが基準となる)。
このとき野球場の1、2塁間の距離は何ポイントになるか?
- 半分くらい?いや半分よりもう少し長いか。
- (ポイントは整数であるとすると)3ポイント?(実際の距離は約27m)
となります。
このポイント(≒距離)は誰が走ったとしても同じ距離(ポイント)です。但し、何秒で走ることができるか(≒期間)は人によってばらつきが出ます。実務ではこの距離が作業量に相当します。このように「作業量」を見積もることでプロジェクト全体の規模を把握するのが相対見積もりです。
気になる点
じゃあ「期間」はどうやって測るのか?ですね。ずばり「ベロシティ」です。
スクラム開発においてはスプリントという単位で開発を進めていきます。あるスプリントで消化したタスクの合計が30ポイントである場合、このスクラムチームのベロシティは30ポイントとなります。であれば、2スプリント後(20営業日後)にはあと60ポイント消化することができる、という具合にプロジェクトの見通しを立てることができます。
本題:ポイントを工数に換算できるか?
ここからが本題です。いきなりポイントと言われても理解しづらく、やはり工数で判断したいと考える方は一定数いますよね。例えば、
- 3リソース
- 1スプリントは10営業日
- 基準となるタスクは3ポイント
- あるスプリントでは30ポイント消化した
とした場合、30ポイント=30人日となり、1ポイント=1人日となります。
「あれっ、実態とそぐわない!」
なんかポイントに対して人日(工数)が過剰になってしまいます。
なぜ?
- フィボナッチ数列でポイントを見積もっているから
- スクラムと従来手法の違い
フィボナッチ数列で見積もる理由
[1, 2, 3, 5, 8, 13, 21, ...]
ずばり「迅速に見積もるため」です。隣接する数字が離れているので、8 or 9ポイントどちらかで迷うといったことがなくなります。大きい数字ほど誤差が大きくなるため、大きくなった場合は分割して、1つのタスクが基準に近いポイントに収まるようにします。ただ弊害として、5~8のようにある範囲内のタスクがいずれかのポイントにマージされてしまうので精度は落ちます。このマージによる誤差が、工数換算時の不整合の一因として考えられます。
ちなみにですが、プロジェクト初期は不確定要素が多く正確に見積もることが難しいので、精度よりも迅速さを優先してプロジェクトの見通しを立てよう、というスクラムの考え方に基づいています。
スクラムと従来手法の違い
従来は工程ごとに進めますが、スクラムは工程を横断しスプリント単位で進めていきます。従来であれば工数とは純粋な「開発工数」ですが、スクラムでは他工程を内包した意味での工数となります。ポイントを工数に換算しようとするとき、この前提を見落としていると前述の通り、ポイントに対して工数が過剰になるという事態が起きると考えられます。
結論、まとめ
結論ですが今回考えた限りでは「ポイントは工数に換算できない」です。確かに各タスクについて各工程が何ポイントなのかを出していけば、開発工数を抽出することはできるかもしれませんが、それに時間を割いてしまっては本末転倒です。従ってできない、やるべきではないというのが今回得た私見となります。
改めて考えてみるとそれなりに説得力のある理由は考えられましたが、議論の場で即答できなかったのが悔しい限りです。まだまだ新米スクラムマスターなのでこれからも精進していきたいと思う今日この頃です。