人月の神話【新装版】

著者 : Jr FrederickP.Brooks 滝沢徹 牧野祐子 富澤昇

• 丸善出版 (2014年4月22日発売)

感想・レビュー・書評

[tosihisaさんの感想 · 2020年4月30日]

この書籍は，ソフトウェア開発の中で，アーキテクト（と言う立場の人）の重要性について触れています．私自身，ソフトウェア開発を30年ほど経験して，ソフトウェアが大規模化，分業化が進む中で，このアーキテクトの存在は欠かせず，かつ大きいと感じます．
この書籍は，1975年に初版が出たようで，2020年の今となっては古典とも言え，書籍の中で出てくるプログラミング言語は時代を感じますが，本書籍で著者が述べている本質は，2020年の今でも，そう大きくは変わらず通用するものと思います．
この書籍は，ソフトウェア開発リーダ，マネージャが読むと良いと思います．若手リーダ，マネージャは，自分の悩みが独りだけの悩みではないと気づくと思いますし，ベテランリーダ，マネージャは，自身が体得してきたことへの，答え合わせになると思います．
1回読んで終わりではなく，ソフトウェア開発実践の中で，繰り返し読むと良い書籍だと思います．

[kaizenさんの感想 · 2021年8月20日]

恥ずかしながら、有澤先生の「ソフトウェア工学」という本を読んで、ブルックスがソフトウェア工学の大家であることを知りました。

ひょっとしたら、この本はその前から読んでいたかもしれません。
プログラマには当たり前のことが書かれていて、納得感がありました。

ソフトウェア工学の大家の書いたことと、この本とが一致したのは何年か後のことです。
仕事で何か行き詰ったときに、この本を読み返すとよいかもしれません。

ソフトウェアを書かずに、現場の役にも立とうとする人は必読かもしれません。
管理者の方々や、大学の先生は、現場の意見を聞く前に、本書を読んでおくとよいかもしれません。

本書を読んで、何がわかったかが、一つのリトマス試験紙になるかもしれません。

[アリエッティさんの感想 · 2021年1月3日]

20200103 読んでる途中

◆文章が頭に入ってこない
　・和訳した本のため
　・自分がPM理論を理解していない
　・エッセイなのでテーマが体系化されていない

最近よくみてたPMBOKと繋がる部分は頭に入ってくる実感があった。読む順番を間違えていると思うので、いったんPM理論が体系化された本を読んでからリベンジしようと思う。

[tabathyさんの感想 · 2020年10月11日]

20201003読了
プロジェクトマネジメントの古典。有名な本だが読んだ事ないので原典を読んでみた。以下感想。

・内容が古くなってる部分もあるが、大規模ソフトウェアを作ることの本質的な困難さについて書かれている

・ブルックスの法則が今でも語り継がれているように、その困難さはまだ解決できてない事がよく分かる

・和訳に一部独特な表現があり、やや読みにくい。

・16章までの内容が冗長。18章にまとまってるのでそこから読むと入りやすい

・多分Wikipediaとかネットのまとめ的なのを読んだ方が頭に入る

[ikuodanakaさんの感想 · 2021年11月22日]

本書の初版が出版されたのは1975年。今は2021年。ほぼ半世紀の年月が流れたことになるが、それでも本書の内容が今日的であることには驚かされる。
1975年の時点で「インクリメンタルな開発」について言及があるが、2021年の我々はインクリンタルに開発できているだろうか。この問いに即答でYESと答えられない以上、本書が朽ち果てることはないだろう。

[よーへいさんの感想 · 2021年5月6日]

エンジニアリングの根幹を学ぶ一冊。経験積んだ上級者向け。

[disktnkさんの感想 · 2016年10月2日]

40年前に(初版が)出版されながらも、未だに多くの示唆に富んだ内容が含まれている。読み度に新しい発見がある。ソフトウェア開発において「人」が大切、プログラミングの構造化と生産性の向上、文書化による情報の共有と隠蔽、アーキテクトの重要性などなど、しっかり言語化されていて良い。18章のN行まとめは定期的に読み返すようにしたい。

[zerobaseさんの感想 · 2016年1月8日]

何度目かの再読。やはり発見があった。最初に呼んだのは90年代、学生のころ。古典的名著。

[ryohoさんの感想 · 2015年11月14日]

ソフトウェア開発における古典。最初から真面目に読まず、あえて１６章から読んでもいいのかもしれない。

[tbpgrさんの感想 · 2014年12月20日]

私が生まれるより前の書籍にも関わらず、いまもなおシステム開発の現場で問題になっている
課題と同じ内容が書いてあったり、アジャイル・XPなどのノウハウと通じる概念が記載されている。

以下、特に印象に残った内容を列挙します

・少数精鋭が理想だが、それができない大規模案件のジレンマ
・マニュアルは形式的定義で厳密さを、散文形式でなぜか？を説明する
・最初から実現不可能なプロジェクトをバベルの塔に例える
・有能な管理的能力と強力な技術的能力を兼備している人間は稀
・技術的騎兵隊としてトップクラスのプログラマの確保が重要。管理職のキャリアパスと技術職のキャリアパスを用意。両者は同一ランクなら同格。技術職から同格の管理職への移動で昇給されてはならない。
・ツール担当。マネージャーはツール製作の要員を出し惜しみしてはならない。
・分業と部分最適化の弊害。実装担当に対する利用者思想の啓蒙はマネージャーの責務
・ソフトウェアは本質的に難しいので万能策はない。偶有的(副次的)な難しさがほとんどなら銀の弾もありえたのであろうが。
・ソフトウェアの複雑性。規模の拡大は同じ要素ではなく、異なる要素が増えるためどんどん複雑になる。
・構文上の誤りは、システムのコンセプトの誤りに比べてとるにたらない
・人月の神話20年を経ての著者の意見。こんにちでも人月の神話が支持される理由。ソフトウェア開発が、正常に、適切に進化しなかった。 労働集約的なまま。