【書評？】WEB+DBプレス vol.93「実践見積もり」で気になったところをまとめる（前提条件・注意点編）
見積もりは深いですね。深すぎる。深すぎて溺れかけます。
見積もりなんて言葉は、ピラミッドや古墳、パルテノン神殿が作られてた大昔から存在すると思うのですが、正確に見積もることがどれだけ難しいことか…。
だから最近、ソフトウェア界隈で「アジャイルvsウォーターフォール（vsDevops）」戦争が勃発したり、ベンダーとエンドユーザーの構築遅延をめぐる訴訟合戦が絶えなかったりします。
simplearchitect.hatenablog.com
https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/blogs.msdn.microsoft.com
そんな時に今月のWEB+DBプレス vol.93で見積もりに関する記事が掲載されてました。今回はその中でも、特に僕が気になった部分を2つの記事に分けてまとめました。
今回は見積りの前提条件と注意点についてです。
前提条件
- 見積もる対象は「費用」とは限らない。「原価」や「日数」などほかの項目も含まれる
- 見積もるという言葉には、「おおよその見当を付ける」という意味と「数字を計算して出す」という2つの意味がある
単純に「見積り」という言葉だけを使うと人によって受け止め方が違う可能性がある、コンテキスト依存性がある
普段、何気なく使っている見積りという言葉にもたくさんの意味があり、共通のコンテキストがあるから伝わる意味もコンテキストが違えばまったく違う意味になりうるということがわかると思います。
その見積りが「どう使われるのか」についても最初に知っておくべき事項になるのです。見積りをする際には、
- 何のために見積もるのか
- 何を見積もるのか
- その見積りがどう扱われるのか
の3点が明確になるように事前によく相談してください。
何のために何を見積もるのかというのは気にしていましたが、その見積りがどう扱われるかということについては僕もそこまで気にしたことはありませんでした。
見積りの注意点
- プロジェクトの初期の段階では、費用見積もりは実際の費用に対して0.25〜4倍の誤差がある
- スケジュールの見積りについても、初期の段階では実際のスケジュールに対して0.6〜1.6倍の差がある
- プロジェクトのフェーズが進むにつれて、誤差がだんだんなくなっていく
実際の費用が当初の見積りの0.25〜4倍！！！つまり100万のプロジェクトが4倍に膨れ上がる可能性があるということですね。僕が経営者ならぞっとします。。。
認知バイアスには何種類かありますが、そのうちの1つに正常性バイアスというものがあります。これは自分によって都合の悪い情報を無視したり、今回は大丈夫だと過小評価したりしてしまう特性のことです。
（中略）
また別の認知バイアスの例として、見積りをする際に相手から次のように言われた時のことを考えてみてください。
- 営業「だいたい100万円くらいでできる？」
- 幹部「5日くらいで作れる？」
このような質問をされると、そこで出された数字によって後から出す数値の判断がゆがめられ、最初に出された数字（アンカー）に近づくバイアスがかかります。
（中略）見積もるときにはこれあらの認知バイアスをいかに避けるか、もしくは認知バイアスが起こることを認識し、その影響をどう織り込むかがポイントとなります。
なんか心当たりがありそうなことが出てきましたね。ある数字を言われるとそれに少しでも近づけた方がいいんじゃないかって思うやつです。
認知バイアスの影響を軽減する一番の方法は、集合知を使うことです。集合知を使うとは、すなわち複数人で見積もることを意味します。（中略）そのやり方の1つにワイドバンド・デルファイ法（広域デルファイ法）があります。
ワイドバンド・デルファイ法は、グループによる費用見積りの手法の一つです。グループはまとめ役が1人と見積りをする人（見積り者）が複数人から構成されます。代表的なやり方は次のようになります。
- まとめ役が仕様書と見積書のフォームを見積り者に提示する
- 見積り者はそれぞれ単独で見積りを行なう
- まとめ役がミーティングを開催する。ここで見積り者どうしが内容について議論を行なう。議論があまりなく結論に合意してしまった場合には、誰かに「結論に対する反対役」を割り当てて議論を促す
- 見積り者は3での議論を踏まえて自分の見積りを無記名で提出する。その際以前に自分が出した見積りから変更してもよい
- まとめ役は提示されたものをまとめたものを用意して全員に渡し、比較できるようにする
- まとめ役は見積り者を集めて、まとめた結果について議論させる
- 見積り者は平均値を受け入れるかどうか無記名で投票する。1人でもNOの場合は3に戻る
- 最終的な見積りは一点見積りになる
僕も前職から見積りをしていましたが、こういう見積りの手法があるのははじめて知りました。
冒頭で見積りの不確実性や納期が確率分布であることを見てきましたが、なぜ誤差が出るのかあらためて整理しておきましょう。
（中略）2つ目の理由としては、プロジェクトを実施する組織やチームの能力についてただしう理解できていないことです。（中略）小〜中規模程度であれば実際にものを作る人達で見積りをすることが重要になります。
（中略）そして、実際にモノを作る人達の現在の能力をもとにすることも重要です。
（中略）最後の理由として、そもそも見積りのプロセス自体から発生する不正確さもあります。（中略）一般的に就業時間のうちに実作業に使える時間は平均で50〜60%程度になります。
最後の理由については僕も激しく同意します。僕自身、以前に自分の時間の使い方を計測しましたが、いかに自分のコア業務に使えていないか痛感しました。
多くの場合、見積りは覚えていても実際の結果を覚えていないことが多いのですが、実際の結果を把握し比較することが大事です。
一般的には、開発者は過小見積もりしてしまう傾向が強いと言われていますが、そういった傾向が数字を使うことでより明白になるのです。
その数字を見て、なぜか入りが起こったのか、それをどのようにして改善するのかを定期的に確認し行動に移してください。これはフィードバックサイクルを回すということでもあります。
たしかに見積りというのは、僕自身の過去の経験も含めて、往々にしてその時の見積りだけで終わって結果どうだったかの振り返りができていない気がします。
まとめ
以上、前提条件と注意点に関してまとめました。次回は（気が向いたら）実際の見積り方法についてをまとめたいと思います。
それではまた。
photo credit: Burndown_Chart via photopin (license)
