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

著者 : フレデリックP.ブルックスJr. 滝沢徹

• 桐原書店 (2002年11月1日発売)

作品紹介・あらすじ

本書は、プログラム開発の管理がなぜたいへんなのか、という疑問に答えようとするものである。プロのプログラマや管理職、特にプログラマの管理職を対象にしている。増訂版では、最近の考えを補足した。アメリカ計算機学会のACM/A.M.Turing賞受賞。

感想・レビュー・書評

[akiyama924さんの感想 · 2012年4月30日]

"No silver bullet"（狼男を一撃で倒す銀の弾丸などない）という有名な言葉が書かれている本です。

さて、本書ではどう書いてあるか引用してみますと、「技術においても管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない。」とあります。そしてその理由として、ソフトウェアが持つ固有の性質である、複雑性・同調性・可変性・不可視性をあげています。

しかし、ブルックスは「それぞれの難しさが引き起こす問題は、しかし、改善できるものなのだ。」と述べています。そして、「おそらく今後は、登場しそうもない解決策を待っているのではなくて、ソフトウェア生産性において可能性のある漸増的な改善を進めていけるだろう。」とまとめています。

[kaizenさんの感想 · 2011年12月29日]

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

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

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

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

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

[oshowさんの感想 · 2008年6月17日]

「人を増やせば、人を増やした分だけ教育の手間とコミュニケーションの手間がかかるため、線形に仕事の速度がアップするわけではない」ということを説明した本。
人月は、かかる金額をはかる（事後的な）指標であって、仕事量を表せる単位ではない。個人的には偶有性の話がおもしろかったです。

[金沢大学附属図書館 Kanazawa University Libraryさんの感想 · 2024年1月16日]

#図書館員の推し事(おしごと)企画/「ゆるコンピュータ科学ラジオ」を推す！

金沢大学附属図書館所在情報
▼▼▼▼▼
https://www1.lib.kanazawa-u.ac.jp/recordID/catalog.bib/BA6231433X?caller=xc-search

[柴犬さんの感想 · 2023年5月15日]

タイトルは有名な本。
やっと読むことができた。

タイトル通りの内容も含みつつ、大規模システム開発を経験したPMの実録というか、こうすればよかったを含むチームビルディングの話があった。

現在でも通用する内容であるところからすごい人なんだろうな、という印象。

[枚方さんの感想 · 2022年7月30日]

面白くはないので飛ばし飛ばし読んだだけ。

とは言っても古い。著者は今読んでも通じる内容ばかりだと言っているが、それはうまく本質だけを抜き出せばそうと言ってるだけで、説明に登場する言葉が古いので現代人が見て分からない。計算機が安価でインターネットの普及といった当時と違う現代に当てはめ直す必要があるし、探せば既にありそう。また今となっては常識化した内容なので、別な本で既に見聞きしたようなことばかりでもある。

後半が加筆部分になってて、その中でも18章が、最初に書いてから9年が経過して、言った内容が正しかったかどうか精査するという内容なのだが、ちょうど要約になってるので良かった。

[umemeさんの感想 · 2021年12月29日]

論旨は一貫している。
ソフトウェア開発は本質的困難と偶有的困難を分離して考えるべき。本質的作業はソフトウェアを構成する概念的な構造体を作ることで、偶有的作業はそれをプログラミングで実現すること。偶有的な作業が9割を占める場合はこれを改善して効果が見込めるが、実際はそうではないので本質的な作業に目を向けるべき。高水準言語、人工知能やオブジェクト指向などが解決策になりうるが、銀の弾のようになんでもひとつで解決できるものはない。


全体
2021年においても人月の神話は信じられているし、それはSIベンダだけでなく情シスも同様。インプリメンテーションは単純作業ではなく、十分に副次的産物として偶有的困難、つまりバグを生み出す。
バグの発生や要件の修正は必ず発生して一番コストがかかるものということをしっかりと認識し、ブループリントではなく現実的な計画と実行を念頭におくこと、人に説明して合意を得ること、これが今でも有効であり無視されているポイントだと感じる。

[ノートリアスさんの感想 · 2020年5月1日]

　元々はコンピュータープログラミングをする人や、アプリケーション開発のプロジェクト管理をする人の為の本だが、思いのほか面白かったのでたまに読んでいる。
　内容的には難しい（というか専門外）な部分が多いのだが、ところどころにある引用された警句の選び方も秀逸だが、中身も面白い。
---
人と月が交換可能になるのは、多くの作業者の間でコミュニケーション（意思疎通）を図らなくても、仕事が分担できる場合だけである。
～第２章　人月の神話　より抜粋～
---
　著者は、ＩＢＭで名機「システム/３６０」の開発をしたプログラムエンジニアである。そしてこの本は「大規模プロジェクト」を率いる事にまつわる様々なレクチュアが、軽妙な語り口を交えつつ書かれている。
---
命題４．１
　コンセプトの完全性こそ、システムデザインのおいてもっとも重要な考慮点である。
命題４．３
　コンセプトの完全性を得るには、デザインが一人ないしは互いに意見が同じ少人数の頭脳グループで考え出さなければならない。

[hirocsさんの感想 · 2019年8月15日]

”業界的には超有名本。
「銀の弾丸」のくだりを知りたくて、長らく刺したままだった本棚から取り出して読んだ。

人月という単位にひそむ誤解、狼人間を退治する魔法の弾丸などない、という本書の命題のほかに、以下の主張に出合えたのが収穫だった。
・形式化した小さいセットの文書の作成が大切
・アーキテクト、デザイナーの育成の具体的な方法
・パッケージソフトをコンポーネントとして活用することこそ本質的な解決につながる（？）

特に３番目は MPI というインタフェースについての記述もあり、何らかの形で活かしていきたい。

＜読書メモ＞
・図1.1 プログラミングシステム製品の進化（p.5）
　プログラムをより有益なものにするには、方法が２つある。ただし、費用も余分にかかる。それが図の協会によって表されている。
　水平線を下へ移動すると、プログラムはプログラミング製品になる。これは、だれでもテスト・修正・拡張が可能なプログラムのことである。（略）
　図の境界線を横へ移動すると、プログラムはプログラミングシステムの中のコンポーネントになる。これは、相互に関連するプログラムが集まったもので、それぞれの機能が調整され、形式が統制され、まとまって、大きな仕事をするための全体的な機構を構成する。（略）
　図1.1の右下がプログラミング製品を表している。これは上記すべての点で左上の単純なプログラムとは異なっており、そのコストは9倍にもなる。しかし、たいていのシステムプログラム開発がめざしているこうした製品は、実に有益なものだ。

★プログラム開発は、多くの人々が目的達成のため、もがき苦闘するタールの沼であるとともに、また独自の喜びと苦悩を伴った創造的活動でもある。多くの人々にとって、喜びが苦悩よりはるかに勝っているのであり、本書はそういう人のためにタールを渡る掛け橋を提供しようとするものである。（p.9）

・スケジュールに時間的余裕がないことが原因でうまくいかなかったソフトウェアプロジェクトは、それ以外の原因で失敗したプロジェクト全部を合わせたものよりも多い。時間の余裕がないことがしばしば惨憺たる結果の原因になるのはなぜだろうか。
　（略）この見積り技術は、努力と進捗とを誤って混同し、「人」と「月」が相互に交換可能だという仮定を隠していることだ。（p.12）

★第二の誤った考え方は、見積りとスケジューリングに使われる仕事の単位、すなわち「人月」そのものである。コストは実際に人数と月数の積に比例する。が、進捗ははそうではない。したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月とは、人と月とが互いに交換できるという意味だからである。（p.14）
　＃人月という単位にひそむ、そもそもの誤解。

・ブルックスの法則をひと言で述べると、
　　遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ
　ということになる。
　このことは人月の神話性を払拭することにもなる。プロジェクトの月数は順次的制約に依存している。そして、要員の最大数は独立したサブタスクの数に依存する。（p.23）

★ソフトウェアプロジェクトのための文書（p.100）
　賢明なマネージャーは、少なくとも、形式化した小さいセットの文書をすぐに作成し、自身のデータベースとして使えるようにする。それから、他のマネージャーと同じような文書が必要になる。
　　何を：目的　?　これが定義するものは、満たすべきニーズ、目標、必要となるもの、制約事項、それに優先順位だ
　　何を：製品仕様書　?　これは提案書として始まり、最終的にはマニュアルと内部文書の作成になる。処理スピードとプログラムスペースに関する仕様書が重要な部分だ。
　　いつ：スケジュール
　　いくら：予算
　　どこで：スペース配分
　　だれが：組織図

★鋭いマイルストーンは、実際チームに役立つものであり、まさにマネージャーが期待するものだ。ファジーなマイルストーンは、事をなすのに一層の重荷となる。実のところ、やる気を擂り潰すのは「ミルストーン（ひき臼）」なのだ。なぜなら、これが取り返しがつかなくなるまで時間の損失をごまかし続けるからだ。そして、とめどなく遅れていくスケジュールは「やる気殺し」とも言うべきものだ。（p.143）

★ソフトウェア開発作業における本質的な部分、すなわち、非常に複雑な抽象的な概念構造体を作り上げることについて議論する時が来たように思われる。私が提案することは次のような内容である。
　●購入できるものをあえて構築しないようにするための大市場の利用。
　●ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。
　●実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的（系統的）に成長させること。
　●若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。
　（p.166)

・ソフトウェア問題の本質を衝く攻略、つまりこうした複雑な概念構造物の定式化を検討しなければならない。幸いなことに、その中には大いに見込みのあるものも含まれている。（p.183-）
　●購入対自主製作
　●要件の洗練と迅速プロトタイピング
　●漸増的開発　?　ソフトウェアを構築ではなく、育成する
　●偉大なデザイナー

★偉大なデザイナーはどう育てたらよいかって？長々と説明する余裕はないが、次のようないくつかの段階は明らかだろう。
　●できるだけ早期にトップデザイナーを体系的に認定する。往々にして最優秀の者がもっとも経験を積んだ者とは限らない。
　●有望な人材の育成を責任を持って行うキャリアアドバイザーを任命し、綿密なキャリアファイルを保持する。
　●有望な人材に対するキャリア開発計画を考案し、それを維持し続ける。この際、トップデザイナーと慎重に「弟子」たちを選択したり、正式の高等教育機関への派遣留学や短期講座を含めたりする。計画中には、一人でデザインしたり、技術的リーダーシップをとったりするという課題をいくつか設ける。
　●育成中のデザイナーが互いに交流・刺激し合う機会を与える。
　（p.190）

・私たちは、再利用を妨げているものは、生産者側の問題ではなく、消費者側にあると推測している。ソフトウェアエンジニア、つまり標準化されたソフトウェアコンポーネントの潜在的消費者が、自分のニーズに合ったコンポーネントを見つけ、それを検証するコストが、新たにコンポーネントを書くよりも高くつきそうだと認めた場合、そっくり同じ新しいコンポーネントが書かれることになるだろう。私たちの観察では上記のことが認められる。再構築に実際かかるコストがどれくらいかは、問題はないのだ。
　＃これ、プログラムに限らない。自分がやった方が早い病。JPL バン・スナイダー氏の言葉。

★ソフトウェア開発は概念上の骨の折れる仕事だと言い、魔法のような解決策は身近にはないと言った。そして、専門家にとっては、革命的な改善をただ待ったり、期待するのではなく、発展的改善を検証する時が来たのだと言っていたのである。（p.213-214）

・1975年版の真髄??当時私が正しいと考えていた主張、すなわち事実と経験から得た一般論??を、意味を変えることなく抜き出して概略を示した。（p.218-）

・中心になる主張
　?コンセプトの完全性とアーキテクト（p.245）

・アーキテクトの持っている利用者のイメージは、意識的であれ無意識的であれアーキテクチャの決定に影響を及ぼすので、デザインチームにとって単一で共通のイメージにたどりつくことは必要不可欠だ。それには、以下のように予想される利用者群の属性を書きだしてみなければならない。
　●だれか
　●何を必要としているか
　●自分たちに何が必要だと考えているか
　●何を望んでいるか
　（p.249）

★購入して構築する??パッケージソフトをコンポーネントとして（p.276）
・これこそ本質を攻略するものだ
　＃お！？ そうなの？
・パッケージソフトウェア利用者は、次の４つのレベルに分けることができる。（p.278）
　●そのままの利用者。（略）
　●メタプログラマ。提供されたインターフェースを使用し、エンドユーザーの手間を省くことを主に目的として、テンプレートや関数を単一のアプリケーションのために構築する。
　●外部機能作成者。アプリケーションに手作りで機能を追加する。本質的にその手作りの機能は、汎用言語で書かれたコードモジュールを切り離すために呼び出す新しいアプリケーション言語プリミティブだ。（略）
　●１つあるいは特に複数のアプリケーションをより大きなシステムのコンポーネントとして使用するメタプログラマ。今日このプログラマのニーズはほとんど満たされていない。このような使用方法は、新しいアプリケーション構築の際、実質的効果を上げるのに有望なものでもある。
　＃４番目に向けた策が有効？

・最後に挙げた利用者にとって、パッケージアプリケーションには補足的な文書作成がなされているインタフェース、すなわちメタプログラミングインターフェース（MPI）が必要である。（p.279）


＜きっかけ＞
　新装版が出ていたのを本屋で見つけて購入…だったかな。
　読んだのは、銀の弾丸のくだりについて Facebookでやりとりしたのがきっかけ。”

[cheercheapさんの感想 · 2018年12月1日]

SEが仕事する際のマネジメントの古典。
外国人はこういうの書くのうまいよなぁ