ソフトウェア開発工数見積もり

ソフトウェア開発において、工数見積もりとは、不完全で不確実かつノイズの多い入力に基づいて、ソフトウェアの開発または保守に必要な最も現実的な工数（人時または金額で表される）を予測するプロセスです。工数見積もりは、プロジェクト計画、反復計画、予算、投資分析、価格設定プロセス、入札ラウンドへの入力として使用できます。^{[ 1 ] [ 2 ]}

見積もり手法に関する公表された調査によると、ソフトウェア開発工数の見積もりにおいては、専門家による見積もりが主流の戦略であることが示唆されている。^{[ 3 ]}

一般的に、工数見積もりは楽観的すぎる傾向があり、その正確性に対する過信が強い。平均的な工数超過は約30%で、時間の経過とともに減少する傾向は見られない。工数見積もり誤差調査のレビューについては、^{[ 4 ]}を参照。ただし、見積もり誤差の測定には問題がある。見積もりの​​正確性の評価を参照。工数見積もりの​​正確性に対する過信が強いことは、ソフトウェア専門家が実際の工数を最小値から最大値までの区間に含めることに平均して90%の確信、つまり「ほぼ確実」な場合、実際の工数を含める頻度は60～70%に過ぎないという調査結果からも明らかである。^{[ 5 ]}

現在、「工数見積もり」という用語は、最も可能性の高い工数の使用（最頻値）、50%の確率で超過しない工数（中央値）、計画工数、予算工数、または顧客への入札や価格の提案に使用される工数など、さまざまな概念を表すために使用されています。これは、コミュニケーションの問題が発生する可能性があり、概念が異なる目的を果たすため、好ましくないと考えられています。^{[ 6 ] [ 7 ]}

ソフトウェア研究者や実務家は、少なくとも1960年代からソフトウェア開発プロジェクトの工数見積もりの​​問題に取り組んできました。例えば、Farr ^{[ 8 ] [ 9 ]}やNelson ^{[ 10 ]の研究を参照してください。}

研究の大部分は、正式なソフトウェア工数見積もりモデルの構築に焦点を当ててきました。初期のモデルは、一般的に回帰分析に基づいているか、他の分野の理論から数学的に導出されたものでした。それ以来、事例ベース推論、分類木と回帰木、シミュレーション、ニューラルネットワーク、ベイズ統計、要求仕様の語彙分析、遺伝的プログラミング、線形計画法、経済生産モデル、ソフトコンピューティング、ファジー論理モデリング、統計的ブートストラップ、およびこれらのモデルの2つ以上の組み合わせに基づくアプローチなど、多数のモデル構築アプローチが評価されてきました。今日おそらく最も一般的な見積もり方法は、パラメトリック見積もりモデルであるCOCOMO、SEER-SEM、およびSLIMです。これらは1970年代と1980年代に行われた推定研究を基礎としており、その後新しい較正データで更新され、最後の主要なリリースは2000年のCOCOMO IIです。機能ベースのサイズ尺度、たとえばファンクションポイントに基づく推定アプローチも1970年代と1980年代に行われた研究に基づいていますが、1990年代にはユースケースポイント^{[ 11 ]}やオブジェクトポイント 、COSMICファンクションポイントなどの修正されたサイズ尺度と異なるカウントアプローチで再較正されています。

推定手法を分類する方法は数多くあります。例えば、^{[ 12 ] [ 13 ]}を参照してください。最上位のカテゴリは次のとおりです。

• 専門家による推​​定：定量化ステップ、つまり判断プロセスに基づいて推定値を作成するステップ。^{[ 14 ]}
• 形式的な推定モデル：定量化のステップは、例えば過去のデータから導き出された数式の使用など、機械的なプロセスに基づいています。
• 組み合わせに基づく推定：定量化の段階は、異なる情報源からの推定値を、判断と機械的な方法に基づいて組み合わせることによって行われます。

以下に、各カテゴリーにおける推定手法の例を示します。

さまざまな推定手法やモデルの推定精度における差異に関する証拠は、「最良の手法」は存在せず、ある手法やモデルの相対的な精度は、状況に大きく依存することを示唆している。^{[ 18 ]}これは、組織によって異なる推定手法から得られるメリットが異なることを意味する。手法の期待される精度に基づいて推定手法を選択することを支持する可能性のある調査結果^{[ 19 ]}には、次のものがある。

• 専門家による見積もりは、平均的にはモデルに基づく工数見積もりと同等以上の精度を持つ。特に、不安定な関係性や、モデルに含まれていない重要な情報が存在する状況では、専門家による見積もりが有効であると考えられる。もちろん、これは関連経験を持つ専門家が確保できることを前提としている。
• 特定の組織の状況に合わせて調整されていない正式な見積もりモデルは、非常に不正確になる可能性があります。したがって、見積もりモデルの中核となる関係性（例えば、計算式のパラメータ）が類似のプロジェクト状況に基づいていることを確信できない場合は、自社の過去のデータを使用することが不可欠です。
• 正式な推定モデルは、モデルが組織の状況に合わせて調整されている場合（自社の過去のデータを使用する場合、またはモデルが類似のプロジェクトや状況から導き出されている場合）、特に有用である可能性があり、専門家の推定には強い希望的観測が含まれる可能性が高い。

多くの予測分野において最も確実な発見は、異なるアプローチを適用することが望ましい独立した情報源からの推定値の組み合わせが、平均的に推定精度を向上させるということである。^{[ 19 ] [ 20 ] [ 21 ]}

ソフトウェア開発の生産性を測定する従来の各アプローチの限界を認識しておくことが重要です。^{[ 22 ]}

さらに、アプローチの結果を理解し伝えやすく、アプローチを使いやすく、アプローチの導入コスト^{[ 23 ]などの他の要素も選択プロセスで考慮する必要があります。}

平均推定精度の最も一般的な指標はMMRE（平均相対誤差の大きさ）であり、各推定値のMREは次のように定義されます。

MRE = ⁠ | (実際の労力) - (推定労力) | / (実際の労力) ⁠

この尺度は批判されており^{[ 24 ] [ 25 ] [ 26 ]}、より対称的な尺度^{[ 27 ]} 、 相対誤差の四分位数の加重平均(WMQ) ^{[ 28 ]}、推定値からの平均変動(MVFE) ^{[ 29 ]など、いくつかの代替尺度が存在する。}

個々の項目が偏っている場合、MREは信頼性が低くなります。推定精度の指標としては、PRED(25)が推奨されます。PRED(25)は、予測値のうち、実際の値から25%以内の範囲にある値の割合を示します。

見積もり誤差が大きいからといって、必ずしも見積もり能力が低いと解釈できるわけではありません。代替的、競合的、または補完的な理由としては、プロジェクトのコスト管理の低さ、開発作業の複雑性の高さ、当初の見積もりよりも多くの機能が提供されることなどが挙げられます。見積もり誤差測定のより良い使用と解釈のためのフレームワークは、^{[ 30 ]に含まれています。}

過度に楽観的な努力見積もりをする傾向が強い理由を説明する可能性のある心理的要因は数多く存在する。これらの要因は、正式な見積もりモデルを使用する場合でも考慮することが不可欠である。なぜなら、これらのモデルへの入力の多くは判断に基づいているからである。重要であることが実証されている要因としては、希望的観測、アンカリング、計画の誤謬、認知的不協和などが挙げられる。^{[ 31 ]}

• 既知の情報を概算するのは簡単だ。
• 既知の未知数（既知の未知数）を推定するのは難しい。
• 未知であるとさえ知られていないものを推定するのは非常に難しい。（未知の未知）

開発作業の労力を慢性的に過小評価する傾向は、数々のユーモラスな格言を生み出し、普及させてきた。例えば、実際には多くの労力が必要となるにもかかわらず、ある作業を「ちょっとしたプログラミングの問題」と皮肉っぽく表現したり、過小評価に関する法則を引用したりするなどだ。

• 90対90の法則：

コードの最初の 90 パーセントが開発時間の最初の 90 パーセントを占めます。残りの 10 パーセントのコードが開発時間の残りの 90 パーセントを占めます。^{[ 32 ]}

• ホフスタッターの法則：

ホフスタッターの法則：ホフスタッターの法則を考慮に入れたとしても、物事は常に予想よりも時間がかかる。

• フレッド・ブルックスの法則：

プログラマー1人が1ヶ月でできることを、プログラマー2人が2ヶ月でできる。