人月の神話 新装版 の商品レビュー

フレデリック・フィリップス・ブルックス(著者),滝沢徹(訳者),牧野祐子(訳者),富澤昇(訳者)

2026/03/08

かなり前からソフトウェア開発の名著といわれてる本。そういえば読んだことないなと思って読んでみた。
原著の初版が発売されたのが1975年。その頃のソフトウェア開発がどういうものだったのか分からないのでイメージしづらいところはあるのだけど、根本的なことは変わらないのだろうなと思った。

ソフトウェア開発においてコミュニケーションは大事だし、その分のコストをかける必要があるということなんだろうなと思った。自分はコミュニケーション能力が低いこともあって避けがちなのだけど、なんとかしていきたいと思う。

文書もやっぱり必要なんだろうなと思う。ちなみに、原著の初版がでたのはインターネットのない時代だけど、今だったらインターネットに公開するのがいいとのこと(といても、それも1996年の意見)

『第13章 全体と自分』に書いてあった、プログラムを書ける人に言ったことへの返答「それぐらいなら私にもできるし、だれだってできるさ。でも、実際にきみが書いたとしたら、ちゃんと動くのかね？」という言葉にグサッときた。今やってるプロジェクトのプログラムは、うまく動く自信がないから余計に…。

フローチャートを書くことに否定的な話は、ちょっと面白かった。確かに、言われてるほどフローチャートってみないよなと思う(納品のために作成したことはあるけど)。
そもそも、今はGUIのシステムだろうし、それでフローチャートって書けないだろうし。

銀の弾に期待することについて、人工知能がその一つとあったけど、今だともしかしたら生成AIがだいぶ銀の弾に近づいているのかもしれない。
生成AIについてどう思ってるのだろうと思ったら、エピローグで1944年時点で13歳とあり、Wikipediaで知れべ手見るとChatGPTが登場する少し前の2022年11月18日に亡くなったとのこと(91歳まで生きたそう)。AIにどこまで期待していたのだろう。

なお、著者によると「ソフトウェア会社は、会社の成功・発展には偉大なデザイナーが偉大なマネージャーと同じくらい重要だ」とのこと。
自分自身はデザインってよく分からないのだけど、デザインは重要なんだろうなと、最近は思うようになった。ただ、デザイナでもないのでデザインセンスを求めないでほしいと思う。

2025/12/01

1.イシュー型の本
「人と月は交換不可能」という一点を徹底して掘り下げる本だった。これは現場で常に痛感するテーマであり、ただの経験則ではなく体系立てて論じられていることで納得感があった。(けど、全部読まなくても結論はわかる)

2.再教育コストの重さ
この本でも言及されていた“再教育コスト”の視点は、現場でも痛感している。私が携わってきたプロジェクトでも、システムの要件が複雑で、正確にシステム化するには深い理解が必要だった。期限が迫るなか追加要員を調達しても、システム理解が追いつかず、結局戦力にならないどころか足を引っ張ることすらある。
「どのような要員なら戦力になるのか」を、マネージャークラスはもっと真剣に考えてほしいと何度も思った。

3.解決策のなさ
結局のところ、問題が明確にされても抜本的な解決策は提示されない。だからこそ“神話”として繰り返されるのだろう。むしろプロジェクトの意思決定層にこの本を読ませること自体が、唯一の解決策かもしれない。

結局、私たちは“銀の弾”を探しながら、“タールの沼”に沈み、“バベルの塔”を建てようとしているのだ。

2025/04/01

システム開発に関する古典。
システム開発の見積もりを、人月を使って計算することに警鐘をならす記述が有名だが、それ以外にもウォーターフォールに対する早く失敗する手法の提案(現代のアジャイルに通ずる)だってり、失敗する組織に共通する点はコミュニケーション不足であることを指摘したり、50〜60年前から人は同じような悩みと向き合ってきたのだと感じた。

2025/03/24

図書館で借りた。
コンピュータサイエンスの、ソフトウェア工学あたりでは有名な名著だ。人月とは「ひと月あたり、技術者1人働いた分の開発量」を表す単位で、業界では古くから「○○人月の開発量」と言ったりして使われてきた。なので、一昔前の経営者は「じゃあ、人を増やせば早く完成するんだな？」と言ってきた。本書は、それに対する「そんな単純じゃないんですよ」をより噛み砕き、解説された本だ。
洋書あるなるなテイストで、どこか物語調と言うか、読み進めないと全体像が掴めない印象がある。いっぱしの技術者なら読み慣れていると思うし、私自身「あぁ、またこのテイストね」と感じるが、ど～も慣れないのが個人的な感想だ。なので、名著と呼ばれているほど興味深くは読み進められなかったかな。
とはいえ、言わずもがな名著だし、私自身所属する企業でも未だに「～人月だから、人を増やせばxヶ月で終わるはずだ」なんて議論が管理職間で言われていて、「んなわけねぇだろ」と内心ツッコんでいる日々だ。内容自体は広くエンジニアに関わらず多くの人が知るべき内容だし、お勧めしたい本だ。

2025/02/20

ソフトウェア構築では本質部分と偶有部分あり。それが出発点
本質部分の概念構造体の作成に困難あり
プログラミングは変化を意識する。抽象概念を現実の力に変換し、外界に働きかけ変えてしまう、現代の魔法

2024/10/19

システム開発における人月にまつわる誤解。無理解。そこに警鐘を鳴らすのが本書である。
システムは工数を考えれば、ひとりではできないことがほとんどだろう。
人をかければ楽になる。直観的な認識は概ねこうだろう。例えば田植えを例にする。人がいればいるほど早く終わる様に見える。
しかし、熟練者とそう出ないものの差はある。上手く植えないとそもそも流されたり芽が出ない。まっすぐ植えないと稲刈りで苦労する。様々な問題が実はある。しかし、農業は懐が深い。そんなことは些細なこととして片付けられる。結局は米が収穫出来れば良い。数の大小、品質の工程はある程度むしできる。
システム開発ではこうはいかない。システムには冗長性がない。あっても、それはシステムの安定運用のものだったりする。つまりそれをひとつの塊と見れば独自のきのうでおる。つまり、どれが欠けても、上手くいかないのだ。
この本ではこのシステム開発特有の、チーム開発に置ける人月、つまりどんな力量の人をどれだけ働かせるか。そこで起こる誤解とベストプラクティスを述べたものである。
一度でも経験し、かつ失敗したのであれば必要性は理解しているかもしれない。しかし、システム開発では、その環境のバリエーションが意外に多い。以前の伝家の宝刀は、今回は役に立たない。むしろ、災厄の原因になることもある。
この本で本質を学ぶことは、とても大切である。

2024/08/26

なんでプロジェクトがどんどん炎上していくのかがわかった
最近のアジャイル開発の感覚とはずれるかもしれないが、プロジェクトの本質的な部分は参考になる

2024/08/25

プログラマーに向けて
プログラムを効率よく、簡単に作る方法（怪物を倒す銀の弾丸）などないと主張する書籍

教養として読んでおこうと思ったけど
内容が具体的過ぎて殆ど理解できなかった。

人月の神話というのは
⚫︎人月というような表現で
工数を見積もるが、人が作業する以上
キャッチアップやコミュニケーションのコストが発生するため、人を増やした分だけ線形に工期を減らせる訳ではない（逆も然り）という意味で人月という考え方は神話だと言っている。

自分とは直接関わらないが、よく仕事でスケジュールの遅延とかその手当のための人員増加の話を耳にする。その際は鵜呑みにせず聞き流したい。

2024/05/06

ソフトウェア開発など縁がなく読み通すのが難解だったが、チームでプロジェクトを遂行する。あるいはチームで物を作りあげると前提を組み替えれば読める内容ではあった。この本を消化させるには多少なりとも経験が必要だと思うし、経験後に再読すれば腹落ち感も違うはずなので業務の中で場数を踏める機会を見つけ再挑戦してみたい。

2023/04/04

古典的な名著なだけあって面白かった
分かりにくい訳語についても、本の後半尾に訳者による解説があるため理解の助けになる

まだ新卒のシステムエンジニアだが疑問に思っていたことが昔から変わらないことという答え合わせになったのが本書だった

昨今の発展が目覚ましい生成モデルが『銀の弾』になり得るのか、そして『タールの沼』を越える魔法の絨毯になり得るのか
期待しながら生きていきたい