ソフトウェア開発見積の課題
一品ものが多く定価のないソフトウェア開発。このことは、開発案件お成否において見積が重要であることを意味しています。
例えば、最終的なコストを見積が大きく下回っていた場合、経営にインパクトを与えますし、その逆はお客様からの不信感を買ってしまう場合もあります。
今回からは、ソフトウェア開発の見積について、課題や解決方法を考えていきます。
今回は、IPAから公開されている以下の資料（ソフトウェア開発見積りの基本的な考え方）を使って見積の課題を確認していきます。
[blogcard url=”https://www.ipa.go.jp/files/000005394.pdf”]
プロジェクトを失敗させる原因
この資料は、見積の課題を整理・分析していますが、冒頭でプロジェクトの失敗原因について下記引用にて総括しています。
「プロジェクトを大失敗させる原因は二つある。ひとつは、見積りミスだ」
1.楽観的な見積り：見積り根拠があいまいで、必要な要素をきちんと見積もっていない。
2.早期の見積り：作るものが決まっていない状況で見積りを行う。
3.目標と見積りの混同：営業、マーケティング担当者や顧客の事情で決定される。
4.一度決まったら修正されない見積り
5.時間の余裕がないことが多い
「もうひとつは、仕様未凍結だ」
ロバート・グラス、「ソフトウェア開発55の真実と10のウソ」、2005
具体的には、見積の”詳細設計に３人月”といった項目を具体的に説明できない見積（上記１．）、お客様から要件や仕様が曖昧な状況での見積（２．）、要件がほとんど決まっていない状況でまるで予算を作成するような見積（３．）、概算見積でよいとの指示で作成した見積金額にいつの間にか縛られる（４．）、別の開発作業を行いながらの見積実施（５．）といった状況を指していると思います。
見積ミスを引き起こす原因
次に、見積ミスを引き起こす原因について下記引用をしています。
1.要求が完全に決定される前に、正式な見積りが求められる。
Capers Jones, “Social and Technical Reasons for Software Project Failures”,Crosstalk, June, 2006
2.過去の実績データがなく見積りのキャリブレーション（較正）ができない場合が多い。
3.新しい要求が加えられても、見積りは変更されない。
4.主要なソフトウェア開発プロジェクトにおいて、見積りツールが使われるわけではない。
5.保守的な見積りは封じられ、挑戦的な見積りに置きかえられる。
6.期間と工数に関して、「望み」と「見積り」が混同されている場合
LM. Liard & M.C. Brenman, “Software Measurement and Estimation: APractical Approach”, John Wiley & Sons, Inc., 2006
7.期待に基づいた計画がなされる場合
8.見積りに関して根拠をきちんと説明できない場合
9.要求が曖昧な場合、要求が変化し増加していく場合
10.成果物の品質が悪い（顧客の満足が得られない）ことが判明した場合
上記を作業工程（見積以降の開発を含む）と責任の所在で表組みすると、以下のようになると思います。
上記表組みは、両社に責任のあるグレーゾーンも無理にどちらかに倒しましたので、ちょっと乱暴かもしれませんが、開発会社側が精度の高い見積をする努力をし、お客様に説明して妥当な合意を得ていくことが重要であると考えられます。
見積の課題
資料で指摘している見積の課題は、以下のように整理できます。
- 見積の根拠不足
- 情報不足でどうしても推測が入ってしまう
- 見積段階で決めた前提が変わっていく
- 過去の見積データの蓄積がない
- 見積実施者はコストを低く見る傾向がある
- 目標や予算に合わせた見積となってしまう
青下線の課題は、人の問題と考えられますので、教育などスキルを上げていくことでの解決が必要となりそうです。
赤下線の課題は、事業遂行上やむを得ないことであると考えられますので、見積の前提（契約内容）でヘッジしていく必要がありそうです。
黄下線の課題は、組織として取り組まなければならない課題といえます。
まとめ
今回は、IPAの公開資料を使ってソフトウエア開発見積の課題について確認しました。
見積はお客様要求が不確定な中で行うことが多く、更には他の作業と片手間で行うケースがほとんどだと思いますが、そんな中で根拠のある見積を作成し、お客様と見積前提の合意を通してコスト増のガードを掛けることが重要であると考えられます。
次回以降は、具体的な課題の解決方法について考えていきたいと思います。
