#見積もりの最適解
最近自社の事業部側から開発チームに対して見積もり依頼が多く、肝心の実装にリソースを割きづらい状況が生まれてきていたので、見積もりについて整理してみた。
状況：チームはアジャイルで周っていて、自社の開発チームで、見積もり提出先も自社の事業側。
##結論：
見積もりの方法は使い分けよう。
というのも、見積もりを依頼している目的が依頼ごとに異なるからである。
また、開発チームが目的を解釈して、適切な見積もり方法を決めて、提出したとしても相手も理解していないと後々トラブルになると思うので、下記の手順で実施するとよさそう
・見積もりの目的を聞く
・実施する見積もり方法のメリット、デメリット、提出する見積もりはどのような性質かを説明する。
・合意の上で見積もり実施、提出
##・見積もりの目的について：
(ほんとはこちらで想像するものではなく、見積もり依頼が来た時に依頼者に確認するべき)
今までの経験上、以下のものが思い浮かぶ。
・会社の方針上ほぼ実装することが決まっている機能で予算を確保するのに必要。
・いくつかある機能のなかで、工数の大小も実施判断の材料にしたい。
上記二つだけでも利用する目的の違いから求められるものが違うことがわかる。
1つ目に関しては、予算も絡んでくることから正確性が求められる。その場合、時間を要したとしても正確性のある見積もり方法をとるべき。
2つめに関しては、大小を比較するために使うので、相対的に把握できることを求められてる。
このように、見積もりの目的に応じて求められるものが違うのでその都度最適な方法を選択するのが良い。
そうすれば、無駄にリソースを割いてものすごく正確な見積もりをだそうとすることもないし、逆に大きなプロジェクトなのにざっくりとした見積もりを出して、後々追加を許容できないほど予算が足りない、ということも避けられると思います。
##・工数見積もり方法：
以下は、少し調べて自分のいるチームに合いそうな見積もりの方法を箇条書き
・プランニングポーカー
チームでタスクやユーザーストーリーごとにポイントを決める。
メリット：bottom upより時間がかからない。チームでやるので見積もり時点で課題点などを共有できる。
デメリット：慣れていないシステムや新規の大きいプロジェクトの場合に誤差が大きくなる。
・ボトムアップ
作業を明確に細分化してその作業に対する工数を積み上げていく。
メリット：タスクを細分化しているので誤差が少ない。
デメリット：時間がかかる
・類推見積もり
過去の類似の事例の実績値をもとに見積もる。
メリット：過去の実績に基づいているので誤差は少ないのが期待できる。
デメリット:どれくらい類似しているかで誤差が変わってくる。
自分のいるチームは、ADOに過去のUSやそれに対するタスクと実績があるのでそれを参照できる。
また現在の環境を考慮して算出した見積もり￥に係数(0.75 ~ 2)をかけてもよいかと。
0.75の例:過去に対応したものとものすごく類似していて、また過去の実装担当者と今回の実装担当者が同じ。
2の例：過去に対応したものが少しだけ類似していて、また過去の実装担当者がいなく、過去の実装担当者と今回の実装担当者を比較した際に過去の実装担当者が誰もが優秀だと思う方だった。
##・最後に：
会社の文化や状況によって適切な方法は変わると思いますので、手順、特に事業側と見積もりの性質については合意することが大事だと思います。
また正確で短い時間で出せる、こんな素敵でみんながハッピーになるような方法がいつか出てくることを願う。