👇🏿 🥄 👩🏼‍🤝‍👨🏻 ソフトウェア開発における人件費の評価について私たちが知っていることと知らないこと 🌓 🙇 👬

調査と報告書の大半は、プログラムプロジェクトの予算とスケジュールを超過する傾向を確認しています。平均して、この超過は約30パーセント¹です。さらに、1980年代の評価の精度と最近の研究に現れた評価の精度を比較しても、有意差は見られません（評価の質の大幅な改善を示唆する唯一の分析はStandish GroupのChaos Reportsにあります。しかし、この「改善」、最も可能性が高いのは、研究者がデータの品質を改善し、問題のあるプロジェクトの過負荷からより代表的なサンプルに移行したという事実に起因しています² ）。評価方法も大幅に変更されていません。正式な評価モデルの分野での集中的な研究にもかかわらず、「ピアレビュー」は依然として支配的な方法です³

人件費を評価するための方法論を改善する上での突破口の明らかな欠如は、これについて私たちがもっと知らなかったことを意味しません。この記事では、私が現在持っている知識の一部を要約してみます。この知識の一部は評価の質を潜在的に改善する可能性があり、一部はおそらくそれを改善することができず、一部はソフトウェア開発における人件費の評価について知らないことに関する知識に関連しています。私が論文を確認するために使用するすべての資料は公開されています¹ 。

私たちは何を知っていますか

人件費の評価に関する研究を分析した後、ほとんどの研究と一致する7つの結果を選択しました。

「最良の」モデルや評価方法はありません

さまざまなモデルと方法を使用して得られたスコアの精度を比較するために多くの研究が行われていますが、これらの競技会ではさまざまな「勝者」の精度を観察しています⁴ 。この結果の安定性の欠如の主な理由は、たとえばプロジェクトのサイズと開発の複雑さなど、多くの重要な関係がコンテキストごとに大きく異なるためと思われます⁵ 。さらに、労働集約度に最も大きな影響を与える変数もさまざまであるため、モデルと評価方法はそれらが適用される状況に合わせて調整する必要があると結論付けられます。

重要な関係の安定性の欠如は、統計的に高度な推定モデルが、単純なモデルと比較して、評価の精度を原則として改善しない、または実際に改善しない理由も説明します。統計的に高度なモデルは、履歴データに依存しすぎており、異なるコンテキストで適用した場合、単純なモデルよりもさらに悪い結果を生む可能性があります。得られた結果は、開発会社が独自の評価モデルを構築する方が、特定の状況において普遍的な方法とツールが正確であると期待するよりも優れていることを示唆しています。

顧客が低価格に焦点を合わせると、コスト超過につながる

人件費を過小評価する傾向は、見積を要求するときなど、価格に基づいてサプライヤの選択が行われる状況で最も顕著です。社内開発など、価格に敏感ではない状況では、そのような傾向はありません。実際、ここでは反対の現象に遭遇することさえあります。これは、過小評価の主な理由は、可能な限り低い価格、つまり人件費を過小評価したサプライヤーが請負業者になる可能性が高いことにクライアントが集中していることを示唆しています。この観察結果は、顧客が見積コストにあまり注意を払わず、請負業者の能力にもっと注意を払うことにより、予算超過を回避できることを示唆しています。

「最小-最大」評価間隔が狭すぎる

90％信頼区間などの推定間隔は、労働要件の実際の不確実性を反映するには体系的に狭すぎます。労働の最小および最大レベルを見積もることができないという自信のある確認にもかかわらず、現在の評価方法はこれが解決可能な課題であると仮定し続けています。これは、推定推定値が最も可能性の高い、最小および最大の推定値に基づいているPERTメソッド（3点推定）を使用する場合に特に顕著です。

専門家の見積もりを使用して人件費の最小および最大の見積もりを決定する代わりに、開発者は以前の評価エラーに関する履歴データを使用して、現実的な最小間隔と最大間隔を設定する必要があります⁶ 。

大切な人を誤解させるのは簡単ですが、取り除くのは難しいです

ソフトウェア開発の分野における人件費の評価は、正式な評価モデルに基づいても、専門家の判断が必要です。しかし、専門家の判断はかなり正確である可能性がありますが、外部要因の影響も大きく受けます。人件費の評価に関与する人々が、評価の前または評価中に、予算、顧客の期待、実装に利用できる時間、またはいわゆるその他の価値についての情報を受け取ったときに、おそらく最も強い（そしてマイナスの）影響が生じます。「魅力評価のアンカー。」これに気付かずに、専門家は「アンカー」の値に不当に近いこのような評価を行います。たとえば、顧客が低価格または少数の工数を期待していることを知ることは、人件費を過小評価する可能性があります。専門家の判断は、「このような小さくて単純なプロジェクトの費用はいくらですか」などの「ロードされた」単語を含むクエリの影響を受ける場合もあります。

誤った前提を取り除く方法と評価の偏りを中和する方法に関する多くの研究にもかかわらず、これに対する信頼できる方法は特定されていません。この状況からの主な結論は、評価の責任者は、関係のない情報や誤解を招く可能性のある情報に対して、たとえば要件文書から削除するなど、あらゆる点で注意を払う必要があるということです。

独立した評価を組み合わせることで精度が向上します

さまざまなソースからの複数の評価の平均は、ほとんどの個々の評価よりも正確である可能性が高くなります。精度を向上させるための重要な要素は、評価の「独立性」です。つまり、得られる評価は、専門知識、専門家の背景、および使用する評価プロセスが異なる必要があります。開発者が独自に取得した人件費の見積もり（「カード」）を表示する「ポーカープランニング」などの「 Delphicメソッド」を使用した評価プロセスは、ソフトウェア開発の人件費を評価する場合に特に役立ちます。

グループの構造化された評価プロセスは、評価の機械的な組み合わせに比べて付加価値をもたらします。これは、知識の交換によりグループ内の知識の総量が増加するためです。「グループ思考」などのグループ判断を適用することのマイナスの影響や、グループ内でより多くのリスクを負う意思（個人の意思決定と比較して）は、ソフトウェア開発の人件費を評価する場合には文書化されていません。

評価モデルは、平均して、専門家の推定よりも精度が低くなります。ただし、モデルと専門家の評価による評価プロセスの違いにより、両方のアプローチの組み合わせは、評価の精度を向上させるのに特に役立ちます。

評価は有害な場合があります

見積もりは、将来を予測するだけでなく、多くの場合、それに影響を与えます。評価が低すぎると、品質が低下し、後続の段階で再作業が行われ、プロジェクトが失敗するリスクが高くなります。マークが高すぎると、パーキンソンの法則に従って生産性が低下する可能性があります。

そのため、この段階で人件費を評価することが本当に必要かどうかを慎重に分析することが重要です。実際にこれが絶対に必要でない場合、評価なしで作業するか、または追加情報が表示された後の段階に延期することがより信頼できることが判明する場合があります。前のスプリントまたはリリースからのフィードバックを使用して次のスプリントまたはリリースのみを計画する柔軟な「アジャイル」ソフトウェア開発方法論は、早すぎる評価による害を回避するための良い方法です。

わからないこと

研究の量にもかかわらず、満足のいく解決策がまだ見つかっていない評価問題がいくつかあります。それらのうち3つは、この分野の知識の不足を強調しています。

巨大で複雑なソフトウェアプロジェクトの人件費を正確に評価する方法

メガプロジェクトでは、人件費を評価するための要件が増加しています。大きな賭け金がかかっているからだけでなく、関連する経験と履歴データの不足も原因です。多くの参加者がさまざまな関心や目標に関与している組織の問題を解決するなど、メガプロジェクトに典型的な活動の多くは、正確に評価することが非常に困難です。通常、ビジネスプロセスの変更を伴い、プロジェクト参加者と既存のソフトウェア間の複雑な相互作用を伴います。

正確な評価のためにプログラムのサイズと複雑さを測定する方法

プログラムのサイズと複雑さを測定するための長年の研究にもかかわらず、提案されたメトリックのどれも人件費の見積もりに関しては十分ではありません。サイズと複雑さのコンテキストによっては、明らかに正しい評価が容易になりますが、そのようなコンテキストは非常にまれです。

生産性を測定および予測する方法

プロジェクトの規模と複雑さを十分に理解している場合でも、[信頼性の高い評価のために]チームとプロジェクトに取り組む必要があるチームメンバーの生産性を確実に予測する必要があります。この予測は、チーム間およびチーム内のパフォーマンスの驚くほど大きな違いにより複雑です。このような評価のための信頼できる方法はありません（トライアルソーシングの可能性を除く）。

現時点では、ソフトウェア開発の分野のプロジェクトに「規模の経済」（プロジェクトサイズの増加に伴う生産性の向上）があるのか、「節約」（プロジェクトサイズの増加に伴う生産性の低下）があるのかさえわかりません。ほとんどの経験的研究は、平均してソフトウェア開発プロジェクトには「規模の経済」があることを示しているようですが、ほとんどの実務家は反対を信じています。残念ながら、「節約」の存在を確認する研究の結果は、明らかに、研究の組織化の結果であり、プロジェクトの範囲と生産性の間の詳細なリンクを明らかにしていません。

したがって、ソフトウェア開発における人件費の評価について現在わかっていることは、実際には、実際のプロジェクトの人件費を見積もる問題を解決することはできません。ただし、原則として、このような推定の信頼性を向上させることができるいくつかのプラクティスを指摘できます。特に、企業は次の場合に見積もりの精度を改善できる可能性があります。

-専門家の評価方法と組み合わせて、コンテキストに適合した単純なモデルを開発および適用します。

-推定誤差に関する履歴データを使用して、最小最大間隔を構築します。

-専門家が誤解を招く情報や無関係な情報にさらされるリスクを回避する。

-この組織でテストされたチェックリストを使用します。

-グループ評価の構造化された方法を使用し、推定値の独立性を保証します。

-不完全な情報に基づく早期評価を避けます。

低コストに重点を置いた競争の激しい入札は、過度に楽観的な請負業者を選択する可能性が高く、その結果、契約の期限に間に合わず、ソフトウェアの品質が低下します。他の分野では、これは「勝者の呪い」と呼ばれます。長い目で見れば、ほとんどの顧客は、ソフトウェア開発の分野で最も低い契約価格に焦点を合わせると、最終的にプロジェクトの成功にマイナスの影響を与えることに気付くでしょう。それまでは、開発会社は、プロジェクトの過度に楽観的な評価の場合にのみ選択できる状況を追跡し、「勝者の呪い」に対抗または回避するための在庫対応戦略を持つ必要があります。

ソース：

1. T. HalkjelsvikおよびM.Jørgensen、「折り紙からソフトウェア開発へ：パフォーマンス時間の判断ベースの予測に関する研究のレビュー」Psychological Bulletin、vol。 138、いいえ。 2、2012、pp。 238–271。

2. M.JørgensenおよびK.Moløkken-Østvold、「ソフトウェアコストのオーバーランはどれくらいですか？ 1994年のCHAOSレポート、「情報とソフトウェアテクノロジー、vol。 48、いいえ。 4、2006、pp。 297-301。

3. M.ヨルゲンセン、「ソフトウェア開発努力の専門家評価に関する研究のレビュー」、J。Systems and Software、vol。 70、いいえ。 1、2004、pp。 37-60。

4. T. MenziesおよびM. Shepperd、「ソフトウェアエンジニアリング予測における再現性のある結果に関する特別な問題」、Empirical Software Eng。、Vol。 17、いいえ。 1、2012、pp。 1-17。

5. JJ Dolado、「ソフトウェアコスト関数の問題について」、情報およびソフトウェアテクノロジー、vol。 43、いいえ。 1、2001、pp。 61–72。

6. M.JørgensenおよびDIKSjøberg、「以前の推定精度の経験的分布に基づく努力予測間隔アプローチ」、情報およびソフトウェアテクノロジー、vol。 45、いいえ。 3、2003、pp。 123-136。

7. B. Flyvbjerg、「計画における楽観的偏見と戦略的不実表示の抑制：実際の参照クラス予測」、欧州計画研究、vol。 16、いいえ。 1、2008、pp。 3-21。

著者について

Magne JorgensenはSimula Research Laboratoryの研究者であり、オスロ大学の教授です。彼の科学的研究の主な分野は、人件費の評価、請負業者の検索、アウトソーシング、ソフトウェア開発者の報酬の評価のプロセスです。彼にメールで連絡できます。メールmagnej@simula.no

ソフトウェア開発における人件費の評価について私たちが知っていることと知らないこと