# Fred Brooks ソフトウェア工学の古典『人月の神話』(The Mythical Man-Month, 1975年)の著者。「遅れているプロジェクトに人を追加しても、さらに遅れるだけだ」という命題(ブルックスの法則)、少数精鋭による小チームが多数の平均的メンバーの大チームを凌駕するという「主任外科医」モデル、「偶有的複雑性(accidental complexity)」と「本質的複雑性(essential complexity)」の区別で知られる。 ## AIエージェント時代への引用 [[Wes McKinney]] はブログ「The Mythical Agent-Month」で、ブルックスの命題群がAIエージェント時代にどう変容するかを論じた。「主任外科医」モデルは一人の有能な開発者が大量のエージェントを指揮する体制と酷似すると指摘される一方、偶有的複雑性を機械速度で解決するエージェントは同じ機械速度で新たな偶有的複雑性を生み出し、本質的複雑性には一切触れないという限界が指摘された。(Source: [[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]]) ## 『SREの探求』での参照 『SREの探求』31章「複雑なシステムのためのエレジー」は参考文献節で "The Mythical Man-Month"(1975、邦訳『ソフトウェア開発の神話』)を、コンウェイの法則を含む多くの関連内容をカバーする文献として紹介している(本文中での実質的な議論の展開はなく、参考文献リストへの掲載にとどまる)。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 31 複雑なシステムのためのエレジー]] §31.7) ## 『ソフトウェア工学の起源』での参照 Michael S. Mahoney [[@1990__CWIQuarterly__The Roots of Software Engineering]] は、1960年代のソフトウェアプロジェクト巨大化がもたらした設計・管理上の困難について、実務家たちが共有していた「恐怖譚」の代表例として『人月の神話』(1975)を挙げる ── C.A.R. Hoare が同種の逸話を1980年のチューリング賞講演「The Emperor's Old Clothes」に残したのと並ぶ例としての言及であり、本文中での実質的な議論の展開はない。(Source: [[@1990__CWIQuarterly__The Roots of Software Engineering]] §4) ## 『ネットワークシステムについて語るときに我々の語ること』での参照 第1章のコラム「『人月の神話』への敬意」は、Larry Peterson・Bruce Davieが自著のエッセイ集の編纂に着手して初めて明白になったこととして『人月の神話』の偉大さを挙げる。両者は大規模システム構築の難しさを論じたエッセイ集という点で共通するが、Brooksがソフトウェアエンジニアリング的な側面に重点を置くのに対し、Peterson・Davieは設計の側面に焦点を当てる点で異なる。ただし両者とも「実装とアーキテクチャの相互作用」という観点では明らかな(そして重要な)共通点を持つとされる。Brooksが生み出した「セカンドシステム症候群」という用語も、Peterson・Davieにとって「お馴染み」のものとして言及され、本書第4章「システム設計における判断」で再論される。『人月の神話』がBrooksのIBM System/360・OS/360でのプロジェクトマネージャ経験に根ざすのに対し、Peterson・Davieのエッセイは彼らのインターネットでの経験から引き出されており、単一企業内のエンジニアリングプロジェクトとインターネットにおける多種多様なステークホルダー間の競争的な協調とでは性質が異なる点が対比されている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] p.3) ## 『Security Engineering』第3版第27章での参照 Ross Andersonは第27章の冒頭で、Brooksが1960年代にIBM S/360メインフレームのOS開発という「世界初の本当に大規模なソフトウェアプロジェクト」を率いた経験から『人月の神話』で導いた結論——「銀の弾丸はない(there is no silver bullet)」、本質的に困難な仕事を容易にする魔法の公式は存在しない——を、セキュア開発マネジメントの出発点として引用する。Andersonはこれを、狐は多くのことを知っているがハリネズミは一つの大きなことを知っているというArchilochusの警句と重ね、セキュア開発の管理は「ハリネズミの知識」(単一の大原理)ではなく「狐の知識」(無数の小さな知恵の集積)だと位置づける。さらに第27章§27.6.1は、Brooksが記述した「主任プログラマチーム(chief programmer team)」——Harlan Millsが考案した、生産性の高いプログラマを管理職に昇進させて失うのではなく、ツールスミス・テスタ・言語弁護士に支えられた開発リードのポストを与える発想——を、1960年代から1980年代の技術企業(著者自身が1980年代に勤めた銀行のIT部門も含む)で採用されていた慣行として紹介し、Microsoft・Google・Facebook・Netflixのような「最初から超生産的なエンジニアだけを採用する」現代的アプローチと対比する。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.1, §27.6.1) ## 『ソフトウェアアーキテクチャの基礎』第22章での参照 Mark Richards・Neal Fordは第22章「効果的なチームにする」で、チームの警告サインの1つである「プロセスロス」を、ブルックスの法則としても知られる概念として紹介し、Fred Brooksが『人月の神話』の中で作った造語だと述べる。プロセスロスは、プロジェクトに人を増やせば増やすほどプロジェクトにかかる時間が増えるという考え方で、グループの潜在能力と実際の生産性の差として説明される。マージの競合が頻繁に発生することがプロセスロスの兆候の1つに挙げられている。(Source: [[@2022__OReillyJapan__ソフトウェアアーキテクチャの基礎 - Chapter 22 効果的なチームにする]] ch.22 §22.4) ## 出典 - [[@2022__OReillyJapan__ソフトウェアアーキテクチャの基礎 - Chapter 22 効果的なチームにする]](ch.22 §22.4、プロセスロス/ブルックスの法則の出典) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]](第1章コラム「『人月の神話』への敬意」) - [[@2026__NewsPicks__ソフトウェアの工業化とアーツ&クラフツ運動]](2026-03-24、広木大地による紹介・引用) - [[@2021__OReillyJapan__SREの探求 - Chapter 31 複雑なシステムのためのエレジー]](§31.7 参考文献リストに "The Mythical Man-Month" 掲載) - [[@1990__CWIQuarterly__The Roots of Software Engineering]](§4、恐怖譚の代表例として言及) - [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]](ch.27 §27.1, §27.6.1、「銀の弾丸はない」というセキュア開発管理の出発点、主任プログラマチーム)