 |
この本 は 「 ソフトウェア工学 の 聖書 」 と呼ばれている。
なぜなら、誰もがこの本を読んでいるが、
誰もこの本で述べていることを実践しないからである。
プロジェクト本部 から 連絡が来た。
「 連絡を忘れていました。仕様変更がありました 」
なので、
「 増員として、ｘｘｘ を そっちに廻してやる！。
これでいいだろ！。」
「 （ …… こいつ、本気か？ 凸(- -# 。）
（ 『 システム工学 』 『 システム構築 』 というものを
（ならば …… と …… 、）
「 ぢゃあ、逆に、現状、まだ手付かず の 案件があります。
今の案件が終わり次第、そちらのｘｘｘさんから説明を受ける手筈でした。
ｘｘｘの案件、主担当者にお返ししますので、
『 実構築担当ｘｘｘでお願いします。』
これで、どうでしょう？」
「 うん！、わかった！。
それで行こう！。」
「（わかってないんだろうなぁ …… ）」
The Mythical Man-Month: Essays on Software Engineering
No Silver Bullet - essence and accidents of software engineering
この本は「ソフトウェア工学の聖書」と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。
つまり、人月を使ってスケジュールを見積もることで、その見積もりが失敗し、スケジュールが遅れてしまうのである。そういう事態に陥ってしまった場合、スケジュールの遅れを取り戻すために、プロジェクトの人員を増やすという対策が取られることが多い。しかし、それでは、火に油を注ぐことになってしまうとブルックスは主張する。彼は、それを「ブルックスの法則」と呼び、以下のように定義している。
ブルックスの法則：遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
プロジェクト本部から連絡が来た
「連絡を忘れていました。仕様変更がありました」
なので、
「ｘｘｘを増員してやる！。これでどうだ！。」
「（ …… こいつ、本気か？）」
「ぢゃあ、逆に、ｘｘｘの案件、主担当者にお返ししますので、
『実構築担当ｘｘｘでお願いします。』
これで、どうでしょう？」
「うん！、わかった！。
それで行こう！。」
「（わかってないんだろうなぁ …… ）」
