人月の神話−第3章

概略

前文

• 少数精鋭の開発チームの方が何百人もの二流のプログラマを抱えたプロジェクトよりも望ましい
• この素朴な二者択一の意見は、妥当なスケジュールで大規模システムを構築するにはどうしたらよいかという難しい問題から逃げてしまっている

問題点

• 最高と最低の実績比率は生産性にして平均十対一、プログラム開発のスピードと量では何と五対一だった
• 事実、たいていの大規模プログラム開発の実績から見て、やみくもに人を動員するやり方は、コストがかさむばかりで、はかどらない非効率的なもの
• 少数精鋭チーム案には、非常に大きなシステム開発には時間がかかり過ぎる
• 効率性とコンセプトの完全性の観点から見れば、デザインと製作は少数精鋭で行いたい。だが、大規模なシステムでは、製品をタイムリーに発表できるように、できるだけ大量の要員を投入する方法が望ましい

ミルズの案

• 外科手術チームのように編成されたチーム
  • メンバー一人一人が問題を切り分ける代わりに、一人が執刀して他のメンバーはそれを助け、効果と生産性が上がるようにする
    • 執刀医
    • 副執刀医
    • 管理者
    • 編集者
    • 二人の秘書
    • プログラム事務係り
    • ツール製作者
    • テスト担当者
    • 言語エキスパート

大規模化する

• 大規模化の成功は、各部分でのコンセプトの完全性が根本的に改善されるかどうかにかかっている
• 仕事が管理できるようになるには、アーキテクチャとインプリメンテーションを厳密に区別することが必要
• システムアーキテクトはアーキテクチャから逸脱せぬよう細心の注意を払わなければならない

思ったこと・感じたこと

少数精鋭のほうが望ましいけれども、少ない人数で大規模システムを作り上げるには膨大な時間がかかってしまう。その折り合いをどうつけるのか、ということが書かれていてとてもおもしろかった。