考えてみた事のメモメモ。
見積もりの手法ってどれくらいあるかご存知ですか？
私が知るソフトウェア見積もり手法は、大まかに言って2つの種類と、3つの手法にわけられます。
2つの種類は、
1.ソフトウェアの規模
2.ソフトウェアの工数
これを見積るのですね。
手法的には、
A.比較して見積る(類推見積りやプランニングポーカー)
B.部品化して見積る(ファンクションポイント法やユースケースポイント法、LOC法等)
C.経験で見積る(標準タスク法やWBS見積り等の積算系見積り)
※これらを結果的に組合せる事になるデルファイ法なんてものもありますね
基本的には、どれか一つで見積るというのは悪手になります。 複数組合せて見積る必要がありますね。 特に大規模な案件だと、複数手法で見積るのが必須になります。
しかしどの手法も、見積る単位が大きいと、見積りの精度は上りません。
例えば、
X.富士山の重量を見積りなさい
Y.富士山に落ちている適当に拾った石の重量を見積りなさい
どちらが精度高い見積りになるのかというと、Yですよね。
では、Xをどう見積るかというと、Yで重量と体積を見積り、それと富士山を比較類推して、富士山はこの石のZ倍であると類推され、それぞれの比重を等しいと仮定した時、富士山の重量はYZである。
とか、まあ例えばそんな感じになるのではないでしょうか。
という事で、今の見積もりの中には、 石という部品を見積った手法と、石と富士山を比較して見積った手法と、経験的に、多分トータル的には平均的な比重の石を拾ったのではないかという経験的な手法(ちょっと強引だけど)の3種類を利用して見積りしてみた訳です。
ソフトウェア開発における見積もりって、結構、この程度の話とあまり変らない事であるのを認識しないといけません。すなわち
実際測って(やって)みないと、正確なところは分らない。
これにつきます。
しかしながら、計画はどうしたってやらないといけない訳なので、分らないからといって見積もりをしない訳にもいけない。けれど、それは正確なものである根拠というのは基本的には「無い」。
見積もりに根拠を求めてはいけません。
ただ、できるだけ「納得感」のある見積もりにしないといけない訳です。
んじゃ、何が見積もりの為には必要なの？って事なんですけど。
まず、富士山に相当する全体として「何」を作るのかを決めないといけない。その次に、その比較可能で且つ計測可能な単位の粒度に見積もり対象の部品をサンプリングして、それを経験値もしくは可能であれば実際に計測してみて見積る。
こういう工程が必要になるわけですね。
そして多分、これを実現する為に必要な事は、一般的に行なわれていると思われる、標準タスク法だけでは見積もりの精度は属人的な領域からは抜けだす事はできない。
ので、WBSから標準タスク法へ落し込む方法とプランニングポーカーを現場のメンバーは行ない、ファンクションポイント法を係長や課長やプロジェクトリーダーが行ない、類推法による超概算見積もりをプロジェクトマネージャーや部長以上の人達で行ない、それぞれを計測していって、工数の係数の補正を行なっていく方法ってのが、最も王道としての組織的な見積もり手法でないかと思います。
また、それぞれの見積もり手法が可能になる程度まで、タスクが分解されて、仕事を分割して下の人間に下されているかってのが、上司の部下に対する仕事の丸投げをふせぐ一つの指標になるのではないかと思っています。
ま、とりあえず、なにか一つの見積もり手法が良いとか悪いとかではなくて、どれもちゃんと計測できないという前提から見積もりは出発しないといけないってのと、そもそも何を見積るのか？ってのがはっきりしないと無理なんでございます。
