システムの工数見積とは統計である
ちょいと、見積もりについて語りたくなったり。
見積には、規模見積、工数見積、原価見積、価格見積と色々ありますが、まずは工数見積から。
今回は
の2本立ての見積もりの話です。
以下、受託開発のシチュエーションで語ってます。
システム見積もり技法のおさらい
長かった提案活動が終わり、必要要件の調整がつきました。
さて、いよいよ開発着手。。。ってわけにも行きません。
要件を基に、契約を結ぶ必要があります。
オッサンが受託などでよく使う見積もり手法は以下の様な感じです。
- 類推法 ・・・ 過去の対応案件で似たような案件を元に見積もりを行う技法。類似案件を間違えると見積が明後日の方向にいくことがあり。
- WBS法(積み上げ法) ・・・ 要件をモデルタスクに分割し、個々のタスクごとの想定作業量を積み上げる技法。想定作業の抜け漏れがあったりすると、見積はえらいことになります。誤差も蓄積しやすい。
- パラメトリック法(with FP法) ・・・ 要件より外部仕様を整理し、ファンクションポイント法に基づきFPをもとめ開発規模を算出し、開発生産性係数などから作業量を見積る技法。契約間の外部設計完了するまではモデルケースで見積もったりしますが設定モデルが実際の設計後の姿と解離すると、見積はとんでもないことに。
- KKD法 ・・・ 勘・経験・度胸でエイヤ!で規模を求める技法?所詮勘や経験なんて属人的なもので、経験値が低いと見積は当たるも八卦なんて状態に。
とまあ、複数の技法を使い分けます。他にもありますが、よく使うのは上記4つです(4つ目は技法?なのかな)。
契約前見積の本質 = 統計的な回帰分析
さて。いろいろな見積技法を書いたのですが、もうひと考察します。
前述の見積技法。それぞれぱっと見違うようですけど。。。基本設計前の見積では、実はいずれも過去の経験から見積もっているって点では類推法と変わらなかったりします。
いうならば、類推法は「案件単位」で類似経験から推測。積上法は「作業単位」で類似経験から推測。パラメトリック法は「機能単位」で類似経験から推測、みたいな感じになります。
類推法の見積 = 過去の類似案件開発規模×α
積上法の見積 = Σ ( 過去の類似作業工数×α )
パラ法の見積 = Σ ( 過去の類似機能工数×α )
要は見積の粒度を変えて、最終的にはKKDで見積もっているわけです。
これは、見積の本質が、過去のプロジェクト実績を、次のプロジェクトの将来実績とするための回帰分析だから、といえます。
で、前述の見積技法の違いは説明変数の取り方の違いと。
ソフトウェアの工数見積とは言え、所詮は見積。販売予測見積などと同じ様に統計に落ち着くのだと思います。
というわけで、見積を何度もやってると経験がものをいうんだなって感じる場面がしばしば。
経験上、若手がFP法やWBS法で見積もった見積より、ベテランのオッサンがKKDでざっくり見積もったほうが精度が高い場合なんてザラにあるんですよね。。。
オッサンも、若手の頃は先輩の指摘に苦労しました。
なお、経験経験いってますが、回帰分析をする元のモデルケースがあればよいので、過去の対応事例集を集めるだけでも効果があります。
まあ、今度はどのモデルを適応するのか、で結局経験やスキルが必要なんですけどね。
それでもKKD から脱却が必要な理由
じゃあ、見積なんてKKD だけで良くね?って話になりがちですけど、これはNGです。
要件変更や、追加要件が発生した場合に「それは対応範囲外です」と言えなくなってしまいます。
積上法にせよパラ法にせよ、想定見積内容をKKDより具体的に契約前提として顧客に提示することができます。もし、設計段階で当初要件から解離すれば、顧客に契約外である旨も明示可能です。そうすれば、交渉力次第ですが、変更案件として追加予算の交渉も可能だったり。
つまり、プロジェクトを守るための盾として必要になるワケです。
また、見積技法の違いは説明変数の取り方の違いと記述しましたが、見積要件のモデル化が正しければ、そこから取り出される見積因子(=説明変数の代入値)によらず結果は近い値をとるはずです。
なので、見積技法を使うことは、見積内容の見える化により、見積モデルの妥当性、抜け漏れチェックに役立つわけです。
まとめ
まただらだら書きましたが、工数見積についてまとめると以下の通りとなります
- いろんな見積技法があるものの、結局のところ精度の高い見積するためには経験(=過去の実績の積み重ね)がものをいう。今後、ビッグデータ解析とかの手法が導入されたらまた変わるかもしれないけど。
- 見積技法は、見積内容の見える化で活用する。結果を過信しない。
- 見積の見える化でプロジェクトを炎上から守る盾にする