プロジェクトに割り当てられた人の数と欠陥の数の間には本当に関係がありますか？

SLIMとソフトウェアの推定に関する職場でのトレーニングマニュアルからの引用を以下に示します。

また、努力と欠陥の間には相関関係があることに注意してください。つまり、特定のサイズのプロジェクトに割り当てられる人が多いほど、欠陥が多くなります。

労力は、プロジェクトの人時間（人年、人月）です。欠陥は、ライフサイクルの任意の時点で検出された欠陥の数です。サイズは、プロジェクトを構成するユースケース、機能ポイント、またはSLOCとして定義されます。

優れたプロセスと有能なエンジニアを想定すると、これは直感に反するように思われます。たとえば、より多くの人がいるということは、すべての成果物（要件の仕様、設計、コード、テスト）に注目することを意味します。より多くの目を持っていることは別として、私の直感は、適切な品質技術を利用するプロジェクトの努力と欠陥の間にはほとんど関係がないことを示唆しています。

欠陥と労力または欠陥とプロジェクトの人数との間の既知の関係を示唆する、Putnam Model（SLIMで使用される）に関するドキュメントを除いて、ドキュメントを見つけることができませんでした。これは既知の関係であり、「より多くの人=より多くの欠陥」という主張は有効ですか？

私の直感は次のようになります。

特定のサイズのプロジェクトにより多くの人が割り当てられると、コミュニケーションのオーバーヘッドが大きくなります
=>誤解やあらゆる種類のコミュニケーションの問題の可能性が高くなります
=>結果として生じる欠陥の数が多くなります。

そして

優秀な開発者は、平凡な/悪い開発者よりもまれであるため、見つけて採用するのが難しくなります。
=> 特定のサイズのプロジェクトに割り当てられる人が多く
なるほど、能力の平均レベルが低くなります。

しかし、これらは私の推論にすぎない可能性があり、証拠はありません。

サイドノートとして、以下で強調されているあなたの仮定は、私たちの職業の状態を考慮して、私見（悲しいことに）非常に強いです：

良いプロセスと有能なエンジニアを想定すると、これは直感に反するように思われます。[...]私の直感では、適切な品質技術を利用するプロジェクトでは、努力と欠陥の間にほとんど関係がないことが示唆されています。

それは単なる相関関係である可能性があります。経営陣は、より複雑だと思われるプロジェクト、多くの非一時的なバグのために遅れをとるプロジェクト、またはさまざまなコンポーネント間で多くのカップリングを必要とするプロジェクトを支援するためにより多くの人を割り当てる傾向があります。ミックスから管理上の決定を下すことができれば、逆ではないにしても、少なくとも相関関係は減ると思います。

サイズと労力の最近更新された定義を考えると、おそらく結果は、エフォート（総工数）が実際にソースが使用している測定値よりも実際のプロジェクトサイズのより良い推定量であるという事実によるものであると示唆します（エフォートはすべてのチームとチームのリソースが同等であった場合の完璧な尺度）。

したがって、実際に起こっていることは、より大きなプロジェクトにはより多くの欠陥があるということです。

優れたプロセスと有能なエンジニアを想定すると、これは直感に反するようです。

これらのいずれかを現実の世界で想定できるとは思いません。プロジェクトに参加する人が多くなればなるほど、追いついていない、最高の開発者の速度を落とすような悪いリンゴを持っている可能性が高くなります。仮に想定を進めたとしても、人数を増やすとプロジェクトが遅くなり、より多くの欠陥を引き起こす他のことがいくつかあります。

• 通信オーバーヘッド
• コード読み取りのオーバーヘッド（これにより、最高の開発者でさえ、自分のコードよりも他の人のコードの読み取りと消費に時間がかかることを意味します）
• テストはより徹底的である必要があります（すべて100％のテスト範囲で撮影しますが、現実の世界ではめったに起こりません。プロジェクトに参加する人が増えるほど、変更を期待しているだけなので、徹底的な自動テストなしでリファクタリングがより難しくなりますすべてのテストを合理的な方法で自動化することさえできないため、さらに時間がかかります。）

私の経験では、プロジェクトが非常にモジュール化されており、ティアごとに1人または2人しかいない場合、開発者がロードしたプロジェクトの悪影響はかなり小さくなります。どのバージョン管理システムを使用しているのかは気にしません。4人の開発者がすべて同じチェックインを一度に同じファイルに自動マージするのは、おそらく悪い考えです。

相関関係と因果関係には違いがあります。引用は、より多くのエンジニアが割り当てられているプロジェクトでは、欠陥の総数が多くなる傾向があると言っているようです。これは私にとって完全に理にかなっています。MSWindowsには私が作成したアプリケーションよりも多くの欠陥があると確信していますが、それは私のアプリケーションが優れた品質であることを意味しません。

別のより抽象的な例を挙げると、国ごとの総死亡数を取り上げ、それを国内の医師の総数と相関させると、「医師が多い国ほど死亡が多い」と言えるでしょう。これは、医師が死を引き起こしたためではなく、多数の医師が人口が多いことを示しているためです。

しばらくの間、人数についての断言を脇に置いておきましょう。

欠陥の数とソフトウェアのサイズの間に強い相関関係があるため、努力の増加が必然的にサイズの増加を必要とすると仮定する限り、努力の関数として注入された欠陥の数を見るのは理にかなっています。

したがって、プロジェクトにより多くの労力をかけると、より多くのコード行が記述されると仮定した場合、欠陥の数を予測するためのサイズのプロキシとして努力を使用できます。サイズ（例：LOC）と欠陥の数との相関関係は、ワッツハンフリー、ケイパーズジョーンズ、その他によって何度も研究されています。

より多くの人がより多くの努力を意味することを除いて、私は人々の数がどのように適合するかわかりません。

補足として、相関関係と因果関係を混同しないでください。サイズと挿入された欠陥の数の間には相関関係がありますが、サイズは原因ではありません。あなたが指摘したように、通常、原因は人とプロセスの問題に由来します。ただし、サイズの関数としての欠陥は、問題があるかどうかを理解し、変更の有効性を評価するための優れたメトリックです。

これはコアプログラミングチームのメンバーに限定され、UI、UX、DBAなどの専門家がいる状況ではないと想定しています。

うまく管理する必要があると思いますが、それは簡単ではありません。質の高い開発者で構成される小さなチームは、自分で管理できます。才能の低い人を作成するコードの大きなセクションを避ける可能性が高くなります。

チームメンバーを増やすと、職務を簡単に分割できます。困難な領域に、より良いまたはより経験豊富な開発者を置きます。ありふれたタスクやプログラミング以外のタスクを優れた開発者から奪い取り、後輩の開発者に割り込みを処理させます。これにはより多くの計画と思考が必要ですが、あなたの才能を活用する機会を提供します。

すでにそれを知っている平均以下の開発者よりも、新しいスキルを習得する必要のある優れた開発者がいる方が良いという考えがあります。時間があればこれは素晴らしいことです。おそらく、より多くの開発者がプロ​​ジェクトに割り当てられる理由は、必要な作業量と時間の制限によるものです。特定の分野に集中し、より熟練することができる人がいる場合があります。バランスの取れた知識を持っていることは素晴らしいことですが、時には少しの指示があれば、下位の開発者が何らかの指示を受けて実行することもできます。

現実には、成功したプロジェクトで大規模なチームを管理したことのある人は多くありません。彼らがすべて才能があっても、大規模なチームが自己管理することは困難です。エゴは邪魔しますか？