アジャイルな見積りはポイントがいい理由

プロジェクトの見積り尺度は大別すると２つある。

絶対見積り（理想日）
相対見積り（ポイント）

理想日は集中して作業した場合にかかる日数だ。例えば、3理想日なら、１人のエンジニアがその仕事を集中して行ったら３日で完成するという意味である。だが、理想日の課題は実際には3日で終らない点だ。作業者が他のタスクと兼務しており、1つの作業に専念できない状況であったり、他のタスクと依存関係があり、その作業が終らないと取りかかれないケースなど。途中にレビュー者や承認者がいて、待ち時間を含めると実際には2週間かかるケースもある。理想日は実際にはもっと時間がかかるのに、あたかも「約束」のように取られてしまうのが課題だ。

その点、ポイントがなぜいいかと言うと、ポイントはあえて抽象化しており、それだけでは意味を成さないことだ。ある仕事が3ポイントだと言われても、時間ではないから一人歩きしても悪さをしない。ピンとこないことが、ポイント見積りの重要なポイントなのだ。

アジャイルでポイントというと、通常次のどれかを使う。

フィボナッチ数列（0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610….）
準フィボナッチ数列（0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, ∞, ???）
倍数（0, 1, 2, 4, 8, 16, 32, 64, 128, 256…..）

そして、アジャイルな見積りでポイントがいい理由は3つある。

ソリューションに依存しない
チームの成熟度に依存しない
スケールしやすい

では順番に見ていこう。

ソリューションに依存しない

フルマラソンは誰が走っても42.195㎞である。完走にかかる時間は様々だろうが、距離は変わらない。仮にクルマで移動しても、自転車で移動しても、距離は変わらず42.195㎞だ。歩いても、フェラーリでぶっ飛ばしても、絶対距離は42.195㎞だ。使うシステムや媒体に影響を受けない。

チームの成熟度に依存しない

成熟度によって作業時間は変わる。同じことをするなら、成熟度の高いメンバーの方が成熟度の低いメンバーより速いだろう。同じ時間をかけるなら、ベテランの方が新米より多くの作業ができる。当たり前である。同じエンジニアでも、成長することでだんだん処理スピードが速くなる。3ヶ月前に3時間かけていた仕事が、今では1時間でできるようになっているかもしれない。チーム全体で3日間かけていたテストが、自動化によって30分で終るようになっているかもしれない。成熟度や成長度により、所要時間は変化するが、作業量は同じである。手動でも自動でも、しなくてはならない作業の量は変わらない。

具体的に1つ例を挙げてみよう。例えば、100㎡の2LDKの清掃。最初は1時間かけて掃除していたものが、徐々にコツを掴んで30分で清掃できるようになった。最終的には、ルンバやディーボットのような自動掃除機を設置することで拭き掃除10分で完了するようになったとしよう。手際よくなって、プロセス改善したり自動化したりして、清掃力を大幅に増強した訳だが、部屋の広さは変わらず100㎡だ。広さで見積っておけば、習熟度やプロセス改善に左右されない。

スケールしやすい

ひとつの共通のプロダクトバックログを複数のチームでさばいていく場合、当然のことながらベロシティはチーム毎に異なる。だが、複数チームがこなせる合計ベロシティーを知らないと、プロダクトのリリース計画が作れない。チーム毎の見積り尺度を統一しないと、プロダクト全体のリリースロードマップがかけない。

一般的には、プロダクトバックログから共通のバックログをいくつか選び全員で見積る。バックログの規模感（見積り）のコンセンサスが得られたら、今度はチーム単位で、手分けして残りのバックログを相対見積りしていく。それらを全て合算すればプロダクトバックログの総合計ポイントがわかる。そしてチームの総ベロシティーがわかれば、割り算することでリリースにかかる時間が割り出せる。

例えば、１つのプロダクトを３チームで手分けして実装していくケースを考えてみよう。

プロダクトバックログの総合計ポイント：1,000ポイント
チームAのベロシティ：50ポイント
チームBのベロシティ：30ポイント
チームCのベロシティ：20ポイント
全チームのベロシティ：100ポイント（50+30+20=100）

このケースでは、プロダクトバックログを実装する為に10スプリント必要なことがわかる。仮に2週間周期でひとつのスプリントを回している場合、必要となる期間は20週間だ（10スプリントｘ2週間）。ひと月4週間とすると5ヶ月かかる計算だ。

ベロシティはチーム単位のものなので、単体チームなら使う尺度はなんでもいい。

フィボナッチ数列
動物ポイント
フルーツポイント
Tシャツサイズ

だがスケールするなら、ベロシティの尺度をあわせないといけない。単純に合計しても意味不明だからだ。。

550ポイント
128サクランボ
101チワワ
58 Sサイズ

これでは合計しても意味を成さない。プロダクトのリリース計画が立てられない。プロダクトバックログであれプログラムバックログであれ、スケールするなら見積り尺度をあわせよう。

アジャイルな見積りにポイントがいい理由がわかってもらえただろうか。作業時間（理想日）で見積ると、実装方法（システムやアプリケーション）やチームの力量により、見積りが複雑になるし、納得感のある見積りが困難になる。

アジャイルでは、チームの成長や働き方のカイゼンを継続的に求めるから、時間で見積ると頻繁に見積り直さなくてはいけなくなる。不変の尺度である規模で見積り、ポイントで抽象化し、ソリューションやチーム力に影響を受ける所要時間との関係性をなくす。その普遍性からスケールしたアジャイルにも適用しやすいのがポイント見積りなのである。