人月の神話 狼人間を撃つ銀の弾はない 増訂版 みんなのレビュー

投稿元：

レビューを見る

「遅れているプロジェクトに人を追加すると、余計に遅れる」の法則で有名な超古典。読んでいないと恥ずかしいので、読んだ。

投稿元：

レビューを見る

SEとして知るべき古典中の古典。1975年発売でもいまだに色あせない。ブルックスの法則は、未来に受け継がれるでしょう。

投稿元：

レビューを見る

社会人4年目ぐらいに読んだ本。
トラブルプロジェクトに人を沢山入れても期間は短くならないという話。
是非トラブルプロジェクトのPM/PLの方々には読んで欲しい本。
ただ、昔の本だから現代的でないところと読んでてかなり眠くなる本だったから★2つです。

投稿元：

レビューを見る

評価4.0
ソフトウェア業界の古典中の古典。
でも古臭さがないのはすげーぇよ！（出てくるシステムじゃあないですぜ）

投稿元：

レビューを見る

タイトル買いしたもの。
大半はコンピューター職種の専門用語がぎっしりで、よく分からない。

タイトルの人月の神話、というのは、「人数を増やせばその分必要な時間は減る」という考え方が神話であり、それに対する有効な手段（銀の弾）は存在しない、という意味のようだ。

確かにかなりの割合で自動化が進んでいる流れ作業で、熟練の必要がないものであれば、確かに単純に人数を増やせば時間が減るが（皿洗いとか）、プロジェクトのように話し合い、調整しながら進めていくのには、人数が多いと逆に時間がかかる（人数多くして船山に上がる状態か）。

投稿元：

レビューを見る

システム開発の計画予測不能性は今に始まったことではなく、コンピュータ黎明期から続く深い問題であることがわかった。

とは言っても、日程遵守はビジネスマナーの基本である。

投稿元：

レビューを見る

大規模組織だったら割とどの業界にも当てはまる。大規模な業務がうまくいかない理由がたくさん書いてある反面教師な本。説明が丁寧だけどやや、省かれてるとこもあり、納得しにくいかも。

投稿元：

レビューを見る

昔、仕事でたいへんお世話になった方に、仕事が伸び悩んでいる時に、技術的な部分を補足するために、この本を勧められました。

この本は、大規模なソフトウェア開発において、考えなければいけない仕組みや、チームで何をどうやって考えればよいのかの概要を記述していると思います。

本の題名から、ソフトウェアの見積もりの話だと想像してましたが、そうではなく、ソフトウェア開発のどこが難しいか説明した文だと思いました。

自分がなるほどと思った箇所は、
「システムにおけるコンセプトの完全性がこそが使いやすさを決定するものである。システムの基本コンセプトと一致しないなら、優れた機能であれ、アイディアであれ、除外するのが一番だ。」と書かれていることろです。前後の文章も大事ですので、ぜひ、全部読んでみてください。

多少、記載内容が古かったり、記述的に難しい箇所もありましたが、自分は、要所要所で、深く読み、たいへん充実しました。
ソフトウェア開発を始めて、中堅に位置する方におすすめです。

投稿元：

レビューを見る

本文でのシステム開発の例がOS/360と今となっては古い汎用機の話となっているので★4つとしたが、元SEとしては満点を出してもいい内容。最後に1995年段階での追補（注釈）も加えられているが、あまり変わっていない事がわかる。新しい本（版）も出ているようだが中身は一緒のようだ。

システム開発の見積もりの単位に「人月」というものが使われる。これは「何人」の人を「何ヶ月」動かすか？動員するか？というお金の話から出てくる単位であって、開発を建設的に進める単位ではない。

ただ、しばしば現場でも作業量の単位として使われてしまう。一人の作業として、2ヶ月分として見積もった作業が期間内で終わらなかった（終わらなそうな）場合、「2人月」という見積もりが正しければ、という前提のもとで増員して対応しようというものだ。それが間違いであることを本書では明確に、具体的に否定している。

ソフトウェア開発というものは、砂袋をA地点からB地点まで決められた数だけ運ぶような単純作業ではない。人が増えればコミュニケーションが必要になる。一人の仕事であるうちはその一人がすべてを把握していればいい（マネージャへの進捗報告は別）。が、二人以上で分担した場合には、その互いの作業をすりあわせ、整合性を取るためにコミュニケーションが必要になる。そして、そのコミュニケーションの量は人が増えるごとにドンドンと増えていく。人を増やすごとに、仕事（実作業）以外の時間が必要になるというのだ。現場にいればよくわかるし、当然の話しである。

また、冒頭で、革新的な小さなプログラムを少人数であっという間に開発することと、大人数で整備されたドキュメントと徹底されたテストをこなされたプログラムの開発の違いについても触れられている。このあたりは、徹底的に全ルートテストが行われる業務用アプリと、しばしばエラー処理が省かれる（実装を後回しにされる）個人用のアプリケーションの違いを言っているともとれ、非常に興味深かった。確かに、仕事で作るプログラムのほうがはるかに手がかかるものである。

特にドキュメントの整備、あれは気の遠くなる作業である。

投稿元：

レビューを見る

重厚感のあるプロジェクト炎上の歴史（笑）こういうのにも古典ってあんるですね。デスマーチほど笑って読めないけど。1章と3章とまとめはWebのプロ監もあてはまる。

投稿元：

レビューを見る

古典。
未だにソフトウェア開発にかかる時間を見積もる方法と大規模開発におけるコミュニケーションの問題は解決されていないように思う。

投稿元：

レビューを見る

ソフトウェアの進歩が例外的に遅すぎるのではない。コンピューターハードウェアの発達があまりにも速すぎ、価格性能比を30年の間に6桁も上げている。
ソフトウェア構築において困難な部分は、概念構造体の仕様作成とデザインおよびテストであって、それを表現することやその表現の忠実化をテストすることではない。そういう意味で、遅延をなるべく起こさないスケジュール作成の目安は、計画1/3、コーディング1/6、単体結合1/4、システムテスト1/4くらいにしておくとよい。
ソフトウェアの開発量は、仕様作成などのデザイン部分も含めて人月で見積もられる。プロジェクトが遅延すると、人を追加して遅れを取り戻そうとするが、遅れたプロジェクトに人員を追加しても、さらに遅延するだけである。それは、相互コミュニケーションが必要な作業は人が増えるとむしろ作業コストが上がるためで、人と月が交換可能なのは、多くの作業者の間でコミニュケーションを図らなくても仕事分担ができる作業のみである。
ソフトウェア開発に銀の弾はないが、①購入できるものを構築しない、②プロトタイプを作成する、③機能を追加しながらシステムを育成させる開発をする、④システムデザイナーの発掘、育成を行う、などにより、開発を遅延させず、生産性を向上させることができる。また、それ以外に、少数精鋭チーム、コンセプトの統一性、完全性、コミュニケーション、動きやすい環境に投資する、ことが重要である。

投稿元：

レビューを見る

コンピューター関係のシステム開発のみならずプロジェクトマネジメント全般でヒントになることが色々とちりばめられている。ことある毎に図書館から繰り返し借りて読んでいる（商業的には悪い読者だ）。この版では各章のまとめに加えて、原著出版から20年後の時点での書かれた内容の検証が追記されており、時間のない人はそこから読むと良い。