人月の神話

記事ごとの説明は、記事本文のうちこの本に触れた部分をAIが要約したもので、筆者の原文ではありません。

• 【Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本】を段階的にまとめた Qiita · JunyaShibato · 2019年12月 · いいね 2,559
• AIがコードを書く時代に、『人月の神話』が突きつける本質的な問い Zenn · 石田 大起 · 2026年5月 · いいね 18

  Martin Fowler氏のブログ記事をきっかけに本書を読み返し、AIコーディング時代に照らして考察している。ブルックスの法則、概念的整合性、「銀の弾などない」の本質的複雑性と偶有的複雑性の区別を取り上げ、AIが減らしたのは偶有的複雑性だけで、設計判断や概念的整合性を守る役割は人間に残ると述べている。

• プログラマのモチベをアゲる本 7選 Qiita · Shaun Mackenzie · 2019年10月 · いいね 9

  本書を大規模開発プロジェクトにおけるソフトウェア工学を扱う本として紹介している。初版が1975年の古典とされる一方、今日のソフトウェア開発にも当てはまる内容が多いと評価している。

• @kazuo_reve「マネージャー・リーダーの私にとって有益な知見が得られた書籍」への謝辞 Qiita · Dr. Kiyoshi Ogawa · 2021年9月 · いいね 6

  有澤先生の「ソフトウェア工学」を読んでブルックスがソフトウェア工学の大家だと知り、本書はそれ以前から読んでいたかもしれないと振り返る。プログラマには当たり前のことが書かれていて納得感があり、両者の記述が一致すると気づいたのは数年後だったという。仕事で行き詰まったときに読み返すとよいとし、ソフトウェアを書かずに現場の役に立とうとする人や、現場の意見を聞く前の管理者・大学教員に勧めている。何がわかったかがリトマス試験紙になるとも述べている。

• 参照にされがちな技術書3選 Qiita · azukiazusa · 2019年11月 · いいね 2

  技術書で参照されることが多い本を独断と偏見で紹介する中で、初版が1975年の古典として本書を挙げ、技術書の世界ではブルックスの名が広く知られていると述べている。遅れているソフトウェアプロジェクトに人員を加えるとさらに遅れるという理論や、9人の妊婦を集めても1か月で出産できないというたとえが、技術書で頻出するとしている。参照先の本を先に知っておくと理解しやすいという記事の趣旨から、技術書を読み始めたい人に向けた紹介である。

• ITエンジニアのバイブル『人月の神話』を読んだ - 銀の弾丸を打て 企業テックブログ · paiza · 2022年1月

  ソフトウェア開発で起こりがちな問題の要因や困難さを分析した本で、特に「人月」の概念が意味をなさないことが説かれていると紹介している。章題は抽象的だが、新装版は第18章で概略が分かるため、まずそこから読むとよいとする。1975年刊行で現代では参考にならない箇所もあるので、読み飛ばしてよいとしている。

• 年末年始に読むオススメ本 企業テックブログ · ネクストスケープ · 2017年12月

  この本で提示された問題は、原文の初版から40年以上が経った今も開発現場の主要な問題であり続けていると述べている。IT業界で知識の陳腐化は速いと言われるが、20年以上前の本でも有効性を失っていないと感じたとしている。

• プロジェクトを炎上させないために、新人PMが読むべき書籍5冊 企業テックブログ · paiza · 2017年6月

  3人で5ヶ月の15人月の案件に15人を投入しても1か月では終わらず、ほとんどの場合は炎上するという例を示し、人月が見積りの単位として危険な神話であることを説明している。遅れているプロジェクトに人を追加するとさらに遅れるというブルックスの法則も紹介されているとし、ソフトウェア開発の難しさを説いた今も読まれる古典だと位置づけている。

• ITエンジニアの価値を貶める『人月商売』の功罪 企業テックブログ · paiza · 2014年7月

  人月が見積りとスケジューリングに使われる単位であることを説明する中で、この本の一節を引用している。コストは人数と月数の積に比例するが進捗はそうではなく、人と月は互いに交換できないという指摘である。3人で5ヶ月の仕事を15人で1ヶ月にはできず、炎上しがちだとし、人月という言葉がそれを誤解させる点を約40年前の1975年に指摘した本として紹介している。