ソフトウェアの開発の現場では、実に様々な問題が起きますが、
マネージャたちの
開発規模への不理解に由来する問題は、意外に多いと感じています。
開発規模が変わると、経験則が使えなくなる
当たり前の話のように聞こえますが、
開発規模が大きく変われば、開発手法、プロジェクトの運営方法などを変えないといけません。
しかし、ソフトウェア開発は見積もりが非常に難しく、
ひとつ前のプロジェクトを参考に、計画を立ててしまうことがよくあります。
（私が以前働いていた職場では、計画も立てずに
見切り発車してしまうプロジェクトさえありました。。）
規模の不経済
製造業には、規模の経済という言葉があります。
「規模が大きくなるほど製造単価が下がり、生産性が上がる」というものです。
ソフトウェア開発では、その逆に、規模の不経済が働きます。
開発規模が大きくなると、生産性が下がるのです。
これを考慮せず、ひとつ前のプロジェクトの成果を基準にプロジェクトを計画してしまうと、
当然、過小見積もりになってしまいます。
このグラフは、1968年に
IBMサンノゼ研究所が調査したデータに基づくものです。
以下の書籍に掲載されていたものを、グラフに書き起こしてみました。
データ自体はかなり古いものであり、
生産性も各プロジェクトチームごとに異なるものです。
また、開発するソフトウェアの種類にも左右されるので、
数値は当てになるものではありません。
しかし、
規模の不経済を表すグラフとしては、今でも参考になるものだと思います。
ただ、グラフを見て、
なんだ、コストを少し多めに見積もっとけばいいのか（*'-'）
・・・と思ったかもしれませんが、そう単純ではありません。
フェーズ比率の変化
前出のグラフを見ると、「生産性の低下」以外に以下のことが分かります。
- 小規模なプロジェクトでは「開発者の能力の差」が最も影響が大きい
- 規模が大きくなるに従い「開発者の能力の差」の影響は小さくなる
規模が大きくなると開発者の数も多くなるんだから、当たり前じゃないか（*'-'）
もちろんそれもあります。
しかし、もうひとつ要因があります。
これは単なるイメージ図ですが、開発規模が大きくなるにつれて、
プロジェクト全体に占める
「実装コストの割合」が減ってくる、ということを表しています。
小規模なプロジェクトでは、開発コストの半分以上が「実装コスト」になります。
極端な話、スーパープログラマが一人いて
こんな機能は一週間で実装して見せるぜ（ ￣^￣）=3
と言ってくれれば小規模プロジェクトは安泰です。
私の経験上、
経験豊富な開発者の「実装コスト」の見積もりは大体当たる
というのがあります。（いや、ほんとに）
ですので、私は、開発者が「ムリです」と答えたら、無理強いすることはしません。
「じゃぁ、ここを削ったらできる？」など、交渉に入ります。
逆に、開発者には以下の傾向があります。
「実装コスト」のみを見積もってしまう
なぜなら、見積もりやすいからです。
そして、
- 今後、要求の変更がどれくらい入るか？
- 最終的なシステムテストで、どれくらいトラブルが発生するか？
この見積もりは、相当難しい・・・（￣へ￣；）
しかし、これらのことを考慮してプロジェクトを運営しないと、
プロジェクトの規模が大きくなるに従い、
スケジュールの超過が目立つようになり、
最終的には、吸収できないほどにスケジュールをオーバーすることになります。
そして、マネージャがそれを放置していると、
品質の劣化、
プロジェクトの中止、
開発者の離職などを招くことになります。
今日のまとめ
- ソフトウェア開発には規模の不経済が働く
- 開発規模が変わると、工数のフェーズ比率も変化する
- 開発規模が大きくなったら、以前の見積もり、開発手法を踏襲してはいけない
「じゃぁ、どうすんの？」
・・・という問いに対する完全な答えはないのですが、
私の経験則をもとに、その辺の疑問に役立つ話を、今後も書いていきたいと思います。
記事を気に入っていただけた方は、クリックしていただけると励みになります。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
