フレデリック・P,Jr. ブルックス

定価: ¥ 3,045
販売価格:
人気ランキング: 162816位
おすすめ度:

発売日: 1996-02
発売元: アジソンウェスレイパブリッシャーズジャパン
発送可能時期:
???ソフトウェアプロジェクト管理・ソフトウェア開発論の古典『ソフトウェア開発の神話』(企画センター刊、絶版)を改題。論文「銀の弾などない──本質と偶有」を再録し、数章を加えた原書発行20周年記念増補版だ。 ???著者のブルックスは、IBMにおいてOS/360メインフレーム用のオペレーティングシステム開発マネジャーを経験し、現在はコンピュータサイエンス学科の大学教授。本書では、OS/360用のオペレーティングシステム開発で生じたさまざまな問題をもとに、プロジェクト管理の問題点と今後どのようにすべきかを論じている。 ?『人月の神話』はすでに古典と呼んでもよいほど有名な本だ。もし、この本のタイトルを知らなくても、ソフトウェア開発にかかわっている人であれば「ブルックスの法則」は聞いたことがあるはずだ。ブルックスの法則の中で最も有名なのは、「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」というものだ。 ???原書は1975年に出版され、その後長い間読み継がれてきた。これは、ソフトウェア開発における問題は、本質的には変わっていないことを意味している。ブルックスの言葉はさまざまな書籍でも引用され、賛同あるいは反証が示されてきた。さらに本書では、ブルックスのもうひとつの衝撃的な論文「銀の弾などない」(1986年発表、IEEE COMPTER誌の1987年7月号に再録されている)も第16章に収録されている。この論文では、「ソフトウェアの生産性をひとりでにもたらすようなプログラミング技法は今後10年間は登場しない」と予言し、議論を引き起こした。この論文を含むブルックスの主張は、その後のコンピュータおよびソフトウェア技術の急速な発展により、一部は誤認であったことが著者自身により認められている。だが、その一部を除く大半は今でも成り立つものだ。プロジェクト管理に関心があるのであれば、一度は読んでおきたい。 ???第17章から第19章は、増補版刊行にあたり新たに書き下ろされたもの。ここでは、初版刊行以降の識者のコメントや著者の新たな論考(ウォーターフォールモデルの誤りなど)、あるいは誤認の訂正が示されている。その中では、ケイパー・ジョーンズ(『ソフトウェア開発の定量化手法』の著者)やトム・デマルコ(『ピープルウエア』、『デッドライン―ソフト開発を成功に導く101の法則』の著者)やエドワード・ヨードン(『Death March』の著者)などに対するコメントが掲載されている。(遠野 諒)
恥ずかしながら、有澤先生の「ソフトウェア工学」という本を読んで、 ブルックスのことを知りました。
恥ずかしながら、有澤先生の「ソフトウェア工学」という本を読んで、ブルックスがソフトウェア工学の大家であることを知りました。
ひょっとしたら、この本はその前から読んでいたかもしれません。
プログラマには当たり前のことが書かれていて、納得感がありました。
ソフトウェア工学の大家の書いたことと、この本とが一致したのは何年か後のことです。
仕事で何か行き詰ったときに、この本を読み返すとよいかもしれません。
ソフトウェアを書かずに、現場の役にも立とうとする人は必読かもしれません。
管理者の方々や、大学の先生は、現場の意見を聞く前に、本書を読んでおくとよいかもしれません。
本書を読んで、何がわかったかが、一つのリトマス試験紙になるかもしれません。
何故いままで読んでなかったのだろう
IBMの大成功したコンピュータのソフトを作った人の書く
ソフトウェアエンジニアリングについて述べた本
1964年当時、何もないと言っていいほどの所から
大ヒットしたIBM 360システムのシステムソフトを作り上げた時の
知見をまとめたものです。
1章から15章までは、題名にもなっている2章の「人月の神話」
をはじめとして、開発に当たって実施したこと、および得られた知見に
ついてまとめています。
16章がこの本の副題にもなっている「銀の弾などない」であり
ソフトウェアエンジニアリングに対しての知見をまとめています。
それ以降の章が20年経ってから増訂された内容で、17章が
「銀の弾などない」の補足、18章が、15章までのコメント、
そして19章が全体の補足と、他の書籍へのレビューとなっています。
さすがに16章までの内容は古くさいものがあるものの、現在でも
通用する知見の固まりになっており良くできていると思います。
そして、その古くささは、17章以後の増訂により間違いは修正され
その後の良書との対比により、本書の位置づけがわかりやすくなっています。
タールの沼に陥らないために何を考えなければならないのかを
まとめようとした本書は、古典ではあるのですが、避けては通れない
重要な課題であることを認識できた良い本です。
マネジメントに関わる人間にとって示唆に富む本
コンピュータのソフトウェア開発や開発マネジメントに関するエッセイである。エンジニアの立場で読んでも、マネジメントの立場で読んでも納得するところが多いし、組織の中での個人の働きをいかに効率化するかという視点で広く読者に訴える物がある(個々のエピソードや用語にはバックグランドである大型コンピュータのソフト開発の知識が必要な箇所はあるが、読み飛ばしても理解を損なうことはない)。本書でアーキテクトの重要性、開発ドキュメントの必要性、バグの収斂がいかに進むかなどには認識を新たにさせられた。
初版が上梓されてから四半世紀を越えての新装版でも基本的には内容は古びていない。そこに個人のスキルに密接に関わるソフト開発の難しさがあると言える。ソフトウェアのマネジメントの立場で、部下から本書に出てくるような警句を口にされたらどうしよう? そのときこそマネジメントの役割が監視ではなく、環境作りであることを改めて肝に銘じるときなのだと思う。解決策は本書の中に提示されているのだから。