人月の神話 増訂版: 狼人間を撃つ銀の弾はない (Professional Computing Series 別巻 3)

著者 : Jr.フレデリック・Pブルックス 滝沢徹 富沢昇 牧野祐子

• アジソン・ウェスレイ・パブリッシャーズ・ (1996年2月1日発売)

作品紹介・あらすじ

IBM360システムおよびOS/360の開発リーダーであった著者が、開発の過程で遭遇したさまざまな問題にどのように対処したか。その結果は正しかったのか。今も繰り返してなされる間違った判断と認識。本書では、未だに色あせてない議論がなされており、ソフトウェア開発管理者・プログラマのみならず、現在のパソコンの神話ならぬ真実の世界を知りたい一般のパソコンユーザも読んでおくべき書である。

感想・レビュー・書評

[kimt1688さんの感想 · 2012年1月22日]

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

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

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

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

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

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

[へ〜たさんの感想 · 2004年10月30日]

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

[縞猫屋さんの感想 · 2015年12月1日]

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

[ndoiさんの感想 · 2015年6月28日]

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

[yasu2keiさんの感想 · 2014年2月28日]

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

[c3po2008さんの感想 · 2013年6月16日]

2007/06/03 読了 ★★★★
2013/06/16 読了

[246skmさんの感想 · 2012年12月29日]

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

[たこさんの感想 · 2011年10月2日]

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

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

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

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

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

[penxeraさんの感想 · 2011年6月3日]

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

[gadgetcheckさんの感想 · 2010年11月20日]

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

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