スクラムの見積もりがバラバラ！スキルの違いで工数の見積もりが一致しない場合は平均を取れ

人によって見積もりが違う場合、どうしたらいいのか分からない

私に寄せられる相談の中で、初心スクラムチームに多いのがこれ。

「チームメンバーの得意分野が異なるので、工数の見積もりが一致せず困っている」

ソフトウェアを開発している場合、フロントエンドが得意な人もいればバックエンドが得意な人もいます。メンバーそれぞれの開発経験が違うため、経験の少ない分野の工数をイメージするのは苦手です。初めからどの分野もバランスよくできる人ばかりでチームが組めるなんてことはごく稀。だから、この問題は多くのチームがぶち当たる問題です。

実は結論は簡単で、「予想工数の平均値」で問題ありません。そんなことをすれば予想と実際がずれてしまった場合大変だ！と考えるかもしれませんがそれについても理由を説明します。

スクラムによる見積もりってそもそも何を指す？お金？時間？

一般的に「見積もり」という言葉はコストを予測するときに使われる言葉です。

しかし、スクラム開発における見積もりは、工賃や工期の見積もりではなく工数の見積もりになります。つまり、一般的にイメージされる「お金や時間」を予測することとは別物であることを前提に知っておけば、スクラムの見積もりが平均でも構わない理由を理解できます。

スクラムでは基本的に開発は準委任契約で進められるため「契約期間＝費用」になります。準委任契約には以下のような特徴があります。

• 労働や作業に対して給料が発生する。（労働義務がある）

• 予算内に完成させること自体に給料は発生しない。（完成義務はない）

• 時間内に完成させること自体に給料は発生しない。（完成義務はない）

準委任契約という特性上、予算や時間内の完成義務はないので工賃や工期を見積もる必要はありません。しかし、労働義務はあるので工数を把握しておく必要はあります。

スクラムにおける工数見積もりの場面は2つあります。その二つは以下の通り。

• PBI（プロダクトバックログアイテム）の相対ポイント見積もり

  • PBIとは搭載したい機能を優先順位の高い順に並べたリスト。

  • 各機能の工数はポイント数の高さで評価する。

• タスク時間見積もり

  • どのPBIをスプリントで実装するか決めた後に、PBIをタスクに分割した後のタスクの時間見積もり。

メンバーによる見積もりが異なる問題の対処法

では、2つの方式の見積もりで、得意不得意の影響で見積もりに差が出てきた場合は、どのように対処したらよいのでしょうか？

PBIの相対ポイント見積もりの場合

プロダクトバックログアイテムの見積もりは、プランニングポーカーで実施しているチームが一般的なので、プランニングポーカーで見積もりをしていることを前提に解決策を紹介します。

プランニングポーカーとはメンバー同士で各工程の工数を予想し、せーので出し合うことをいいます。初めはみんなの意見はバラバラなのですぐには合意点は形成されませんが、これを繰り返すことで工数は徐々に収束します。最終的には話し合いや平均を取るなどしてポイントを決めます。

この仕組みであれば得意領域に差があっても、多数決（最頻値）、平均値や中央値を取ることで実装とのブレが許容範囲内なので影響が少なくなります。

見積もりの差に対する心配というのは、実装の予測と実作業時間の差分に対して心配しているのもあると思います。しかし、複数人で1つのプロダクトバックログアイテムに着手することで、予測と実作業時間の差が小さくなります。

また、1人でプロダクトバックログアイテムを担当したとしても、得意領域が多いものを担当することもあれば、得意領域が少ないものを担当することもあり、複数のアイテムをこなすことを考えると、最終的には見積もりに近いところに収束します。

PBIの相対ポイント見積もりではズレることを前提に考えるため、それなりの正確さで時間をかけずに素早く見積もることを目的にしています。厳密さを求めて見積もりに時間をかけすぎては、本末転倒になってしまうので注意が必要です。

PBIの相対ポイント見積もりのズレは気にしなくて問題ありません。なぜなら、プランニングポーカーを正しくやれば、見積もりの差を吸収してくれるようになっているからです。詳しくは別の記事で紹介します（執筆予定）。

タスクの時間見積もりの場合

タスクの時間見積もりは、決まった形式の方法があるわけではないものの複数人がチェックする形を取ることで影響が少なくなります。

タスクの見積もりは、全員で並列作業で作業時間を入力していく場合もあるかと思います。

しかし、見積もり時間に差が大きいことを自覚しているのであれば複数人でタスクの見積もり時間を確認して、平均を取るようにすることをおすすめします。中央値や最頻値で計算する場合でも問題ありません。

平均値についての影響を考えてみます。チームに1人能力の高い人がいる場合は、どうなるのでしょうか。平均時間は小さくなる方に引っ張られますが、その能力の高い人が多くの仕事をこなせるため、結果的には影響が少ないです。逆に、チームに1人能力の低い人がいる場合は、平均時間は大きくなります。しかし新人は多くのタスクを同時に抱え込むわけではないので負の影響は小さく、チームとしても伸び代として考えることもできるため問題ありません。

得意な人が得意な領域だけをやることで生産速度を高める方法の悲惨な末路

ここまで説明を見ても、「バックエンドが得意な人がバックエンドを、フロントエンドが得意な人がフロントエンドをというふうに、得意領域に特化して開発する場合は、見積もりの問題が解消するじゃないか」と考える方も少なくないと思います。

それについての回答は、こちらの記事（得意領域に分業が、ビジネス価値の生産にマイナスの影響を与えるスクラムの事例 ）にて記載しています。簡単に説明すると、スクラム開発において、得意領域での分業をすることは、生産速度は上げるものの、ビジネス価値を生み出すことには障害になってしまうので、ソフトウェア開発がビジネスとして成功しづらくなってしまうのです。そのため、できる限り避ける必要のある解決策です。

まとめ

• スクラムにおける見積もりで、個人の得意不得意が見積もりに影響を与えて収束しなくなってしまう問題についての対処法は、プロダクトバックログアイテムの相対ポイント見積もりでも、タスクの時間見積もりでも解決策は同様に平均や中央値、最頻値を取ることで同様に解決する。

• 相対ポイント見積もりは、時間をかけずにそれなりの正確さのものを、素早く見積もることを目的にしているので、見積もりに時間をかけることで正確さを高めないようにする。

• 気をつけなければならないのは、解決策として、分業することで生産速度を上げようとすることである。これは生産速度を高めるが、ビジネス価値を生みづらくするのでビジネスとして失敗しやすくなる。