ソフトウェア開発の労力見積もり

ソフトウェア開発において、労力見積りとは、不完全で不確実でノイズの多い入力に基づいて、ソフトウェアの開発や保守に必要な最も現実的な労力（人時または金額で表す）を予測するプロセスです。労力見積りは、プロジェクト計画、反復計画、予算、投資分析、価格設定プロセス、入札ラウンドへの入力として使用できます。^{[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年代に実施された研究に基づいていますが、修正されたサイズ測定と、ユースケースポイント^[11]やオブジェクトポイント 、 1990年代のCOSMICファンクションポイントなどの異なるカウントアプローチで再較正されています。

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

• 専門家による推​​定：定量化のステップ、すなわち、判断プロセスに基づいて推定値が生成されるステップ。^[14]
• 正式な推定モデル: 定量化の手順は、履歴データから導き出された式の使用など、機械的なプロセスに基づいています。
• 組み合わせベースの推定: 定量化のステップは、さまざまなソースからの推定値を判断的かつ機械的に組み合わせることに基づいています。

以下に、各カテゴリ内の推定アプローチの例を示します。

異なる推定アプローチやモデルの推定精度の違いに関する証拠は、「最良のアプローチ」というものは存在せず、あるアプローチやモデルと他のアプローチやモデルとを比較した場合の相対的な精度は、状況に大きく依存することを示唆している。^[18]これは、異なる組織が異なる推定アプローチから利益を得ることを意味している。アプローチの予測精度に基づいて推定アプローチを選択することを支持する調査結果^[19]には、次のものがある。

• 専門家による推​​定は、平均すると、モデルベースの労力推定と同等以上の精度があります。特に、関係が不安定な状況や、モデルに含まれていない重要度の高い情報がある場合には、専門家による推​​定の使用が推奨されます。もちろん、関連する経験を持つ専門家が利用できることが前提となります。
• 特定の組織独自の状況に合わせて調整されていない正式な見積モデルは、非常に不正確になる可能性があります。見積モデルのコア関係 (数式パラメータなど) が同様のプロジェクト状況に基づいていることを確信できない場合は、独自の履歴データを使用することが非常に重要です。
• 正式な推定モデルは、モデルが組織の状況に合わせて調整され（独自の履歴データの使用、またはモデルが類似のプロジェクトや状況から派生する）、専門家の推定がかなりの程度の希望的観測に左右される可能性がある状況で特に役立ちます。

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

ソフトウェア開発の生産性を測定する従来のアプローチにはそれぞれ限界があることを認識することが重要です。^[22]

さらに、アプローチの結果を理解して伝えることの容易さ、アプローチの使いやすさ、アプローチの導入コストなどの他の要素も選択プロセスで考慮する必要があります。

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

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

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

個々の項目が歪んでいる場合、MRE は信頼できません。推定精度の尺度としては PRED(25) が適しています。PRED(25) は、実際の値の 25% 以内にある予測値の割合を測定します。

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

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

• 既知の事柄を推定するのは簡単です。
• 何が未知であると知られているかを推定するのは難しい。(既知の未知)
• 知られていないものを未知であると推定するのは非常に困難です。(未知の未知)

開発努力の慢性的な過小評価により、タスクを「プログラミングの小さな問題」と皮肉を込めて言及したり（多くの労力が必要になる可能性が高い場合）、過小評価に関する法則を引用したりするなど、多くのユーモラスな格言が生み出され、人気を博しています。

• 90-90ルール:

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

— ベル研究所のトム・カーギル氏

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

ホフスタッターの法則: ホフスタッターの法則を考慮しても、予想よりも常に時間がかかります。

— ダグラス・ホフスタッター『ゲーデル、エッシャー、バッハ：永遠の黄金の編み紐』 ^[32]

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

1 人のプログラマーが 1 か月でできることは、2 人のプログラマーが 2 か月でできます。

— フレッド・ブルックス、^[要出典]