このグラフは、1968年に IBMサンノゼ研究所が調査したデータに基づくものです。
以下の書籍に掲載されていたものを、グラフに書き起こしてみました。


データ自体はかなり古いものであり、
生産性も各プロジェクトチームごとに異なるものです。
また、開発するソフトウェアの種類にも左右されるので、
数値は当てになるものではありません。

しかし、規模の不経済を表すグラフとしては、今でも参考になるものだと思います。


ただ、グラフを見て、


・・・と思ったかもしれませんが、そう単純ではありません。

フェーズ比率の変化

前出のグラフを見ると、「生産性の低下」以外に以下のことが分かります。

• 小規模なプロジェクトでは「開発者の能力の差」が最も影響が大きい
• 規模が大きくなるに従い「開発者の能力の差」の影響は小さくなる

もちろんそれもあります。
しかし、もうひとつ要因があります。



これは単なるイメージ図ですが、開発規模が大きくなるにつれて、
プロジェクト全体に占める「実装コストの割合」が減ってくる、ということを表しています。

小規模なプロジェクトでは、開発コストの半分以上が「実装コスト」になります。
極端な話、スーパープログラマが一人いて


と言ってくれれば小規模プロジェクトは安泰です。
私の経験上、

経験豊富な開発者の「実装コスト」の見積もりは大体当たる

というのがあります。（いや、ほんとに）

ですので、私は、開発者が「ムリです」と答えたら、無理強いすることはしません。
「じゃぁ、ここを削ったらできる？」など、交渉に入ります。

逆に、開発者には以下の傾向があります。

「実装コスト」のみを見積もってしまう

なぜなら、見積もりやすいからです。
そして、

• 今後、要求の変更がどれくらい入るか？
• 最終的なシステムテストで、どれくらいトラブルが発生するか？

この見積もりは、相当難しい・・・（￣へ￣；）

しかし、これらのことを考慮してプロジェクトを運営しないと、
プロジェクトの規模が大きくなるに従い、スケジュールの超過が目立つようになり、
最終的には、吸収できないほどにスケジュールをオーバーすることになります。

そして、マネージャがそれを放置していると、
品質の劣化、プロジェクトの中止、開発者の離職などを招くことになります。

今日のまとめ

• ソフトウェア開発には規模の不経済が働く
• 開発規模が変わると、工数のフェーズ比率も変化する
• 開発規模が大きくなったら、以前の見積もり、開発手法を踏襲してはいけない

「じゃぁ、どうすんの？」
・・・という問いに対する完全な答えはないのですが、
私の経験則をもとに、その辺の疑問に役立つ話を、今後も書いていきたいと思います。