見積りってなんだろう？

こんにちは。@ryuzeeです。

今度書く原稿が見積りに関するものになりそうなので、事前にちょっと整理しておこうと思います。特にオチとかはありません。

まず言葉の意味を正しく把握してみよう

まずは言葉の意味を正確に確認しておきましょう。辞書は大辞泉(Goo国語辞典です)

み‐つもり【見積（も）り】

見積もること。また、その数字。「―を立てる」
「見積書」の略。

み‐つも・る【見積（も）る】

目分量や心づもりではかっておおよその見当をつける。目算する。「入場者数を―・る」
工事や製品などの、原価・日数・経費などを前もって計算して出す。「経費を―・る」「工事を―・る」

言葉の定義が広いため、コンテキスト依存性がある

国語辞典の結果を見ると分かるように、「見積もる」というのは、おおよその見当をつける・計算するという動詞であることが分かりますが、一方で、この単語の中に既に「何を」の部分が複数含まれているのが話をややこしくしています。

つまり、誰が誰にどんな状況で「見積り」を依頼したかによって「何を」の部分がかわります。たとえば以下のような例が考えられます(乱暴に書いていますので必ずしもどこの環境でもあてはまるとはか限りません)。

お客さんがSIベンダーの営業に対して「見積りをくれ」といった場合は、実際にお客さんが支払う費用を指すことが多いでしょう
SIベンダーの営業が開発部門に「見積りをくれ」といった場合は、総内部工数と原価を指すかもしれません
Webサービスを内製で作っている会社が「見積もって」とチームメンバーに言えば、内部的に発生するであろう工数か期間を指しているかもしれません

単純に「見積り」という言葉だけを使うと人によって受け止め方が違う可能性がある、コンテキスト依存性があるというのが分かると思います。そして、「対象」に対する誤解を避けるために、きちんと「何を」見積もるのか正しく依頼する必要があります。

見積りが「どう扱われるか」が与える影響

見積りがどう扱われるかが分かっている場合と分かっていない場合とで見積りが違ってくることがあります。

身近にこんな例がある不幸な方もいるかもしれません(大手SIerはこのあたりは赤字プロジェクト撲滅という名のもとに色々審査があるのでいきなり見積書が勝手な金額で出て行くというのはないはずですが)。

営業から「だいたいいくらでできる？」と聞かれて「○万円くらい？」と答えたらある日発注がいきなり来た
幹部から「何日くらいで作れる？」と聞かれて「○日くらい？」と答えたら、なぜかリリース日が決まっていてアナウンスされていた

上記の例での問題点は、あくまで「予測」として出したものが「約束」として扱われてしまっていることです。最初から「約束」として使われることが分かっているのであれば、リスクを踏まえて数字を積むことになるはずです。

したがって、その見積りを「どう使うか」についても最初に知っておくべき事項になります。

アンカリングによる数字のゆらぎ

ちょっと話は逸れますが、上の例での質問を以下のように変えてみましょう。

営業「だいたい100万円くらいでできる？」
幹部「5日くらいで作れる？」

こういう質問の仕方に変えると、そこで出された数字によって後の数値の判断が歪められ、最初に出された数字(アンカー)に近づくバイアスがかかったりもします。これはその数字でやろうとする根拠を探しだそうとする力が働くからでもあります。

したがって、見積りを求めるときは、先入観なく判断をさせるようにしてください。

でも、そもそも正確な見積りって可能なんだろうか？

本質的には、規模が大きくなればなるほど、いかなるものの見積りも難しいと考えてよいと思います。いかなるもの、というのは、原価や期間、必要なリソースなどなどです。

例えば上のビル群の左2つの高さを見積もってみてください。これをいきなり正確に見積もるのは困難だと思います。いきなり、と書いたのは類似のビルを建てたことがあれば話は変わってくるからで、例えば以前建てた50階建てのビルは高さ120mだ、みたいなのを理解していると見積りの精度は上がります。一方でソフトウェアの場合は、毎回作るものが違い、作る人のスキルにも大きな差があります。過去の数字の蓄積によってある程度カバーできたとしても、建築物に比べると、誤差の範囲は大きくなると思われます(もちろん新国立競技場の話もあるので、建築物だとしても一定規模を超えた新しいものの規模や費用の見積りは難しいということが分かります)。

見積りの精度は時間の経過とともに高くなる(はずである)

当たり前ではありますが、手持ちの情報が増えたり、フェーズが進むに連れて見積りの精度は上がっていきます。

上の図は、不確実性コーンと呼ばれるグラフで、プロジェクト初期の段階における費用見積りは、実際にかかった費用の0.25倍〜4倍の範囲に収まり、以降時系列で、要求が固まった時点で0.67倍〜1.5倍の範囲に、製品設計が終わった時点で0.8倍〜1.25倍・・・という範囲に収まることを示しています。うまく、実際にかかった金額の4倍で見積りを出していてそれが採用されているのであれば少なくとも受託した側は万々歳ですが、0.25倍の見積りで出していれば大赤字です。

この事実を踏まえると…

これが分かっていれば、大型案件をおこなうときに、企業側がRFPを作成し、複数社から提案や金額見積りをもらい、一番安いところに発注するというのが如何に恐ろしい話なのかよく分かります。

受託開発側の文脈から見ると、設計と構築を分けて契約することにして、設計部分までは準委任で行い、開発部分だけ請負で行うことでリスクを低減するというのはよくある話だということが分かります(大手SIerがよくやります)。

見積りの手法はいろいろあるけれど…

規模の見積りの方法には、ファンクションポイントやCOCOMO、CoBRAといった方法があります。大手のSIerなんかではあるプロジェクトの規模見積りをする際に必ず複数の方法を使って見積もるなんて話も聞いたことがありますが、これの前提になっているのは「事前に分かっている情報をもとに算出する」ということです。つまり不確実性コーンの絵にあるように、「事前に分からないもの」が多ければ多いほどどちらにしても見積りは不正確ということになります。

ということで？

具体的な規模見積りや費用の見積りはすごく難しいというのでよろしいでしょうか？

アジャイルの文脈だとどうなる？

ここまでの文脈はウォーターフォール型の受託開発っぽい文脈(スコープと期日と予算が固定)でしたが、アジャイルの文脈だとどうなるのか考えてみましょう。まず一般的な考えとしては、全ての要素を固定するのは避けるべきということです。

となると固定のパターンは以下が考えられます。

スコープと期日を固定(予算は可変)
スコープを固定(期日は可変、予算も可変になるはず)
期日と予算を固定(スコープは可変)

この中で一般的に機能しそうなのは、最後の「期日と予算を固定し、スコープを可変にする」ものです。つまり決められた枠の中で大事なものから順番に作っていき、リソースが尽きたり(お金を使い果たしたり)、期間が到来すれば、そこでさらにリソースや期間を追加してモノを作るのかどうかを決めます。

では必要な人数や期間はどう見積もるのか？これをするには、これから作るものの全体像がおおよそ把握できている必要があります(この点については方法論による違いはあまりありません)。したがって例えばプロダクトバックログをざっと用意して、ポイントで見積りをしてみたり、大中小に分けてみたりして把握してみましょう。時間や期間で見積もるのは非常に難しいので、あとで何らかの係数をかけたり実績値をかけることで精緻化するのが良いです。

チームのサイズが決まっている場合の費用の見積り

チームのサイズが決まっている場合、1スプリントあたりのチームにかかるコストはほぼ確定できます。例えば1ヶ月スプリントでPOとSM、開発チーム6人で、それぞれの人件費が1人100万円であれば、月間800万円の費用になり、1スプリントあたりのコストはスプリントの期間に応じて算出可能で、以下の式になります(機材など諸経費は簡単のため省略)。

総費用＝ 1スプリントあたりの費用 ×スプリント実行回数

(一方でスコープ網羅を目指して、スプリント回数が可変である場合は、プロジェクト初期では、何回スプリントをまわすべきかは確定できません。というのはチームが1スプリントあたりにどのくらいの量を作れるかの数値がないからで、その場合は、プロジェクト費用の見積りはスプリントを経るごとに正確になっていくことになります)

期間を優先し、チームのサイズをあとから決める場合

アジャイルな開発手法の多くは、チームを継続的に維持することによって、チームの文化や規律や技術力を向上させることに価値を置いています。したがって寄せ集めチームを作ったりあとから人をどんどん追加していく方法はあまりうまくいきません。一方で既存のチームに対して文化が壊れない程度に人を追加する（もちろんScrumのチーム人数の範囲で）というアプローチはないわけではありません。

この場合も実は前項の話とあまり変わりません。チームのサイズをいじったとしてもチームが1スプリントあたりに作れるモノの量は、プロジェクト開始時点では正確には分からないので見積り精度が向上するのは、スプリントを実行してからになります。

必要ベロシティ＝プロダクトバックログアイテムの合計ポイント ÷ スプリント数

すべてはチームの能力に依存する

身も蓋もない話ですが、優れたチームとそうでないチームの間には、作れるものの量や質に大きな差がでます。同じものを作るにしても所要時間が大きく変わります。したがって期間や工数や費用の見積りを行うのは実際に作業をするチームが行わなければいけません。同じチームで長く活動を続けるほど過去のメトリクスや実績の積み重ねによってチームの能力が計算しやすくなります。したがってよいチームを維持し続ける(解体しない)のが重要でもあります。