What is *The Mythical Man-Month* about?

*The Mythical Man-Month* by Frederick P. Brooks explores software engineering challenges, arguing that adding personnel to delayed projects worsens timelines due to communication overhead. It emphasizes modular design, team coordination, and conceptual integrity, drawing from Brooks’ experience managing IBM’s OS/360. Key themes include Brooks’ Law (“more people = slower progress”) and strategies to manage complexity in large-scale projects.

Who should read *The Mythical Man-Month*?

Software project managers, engineers, and product leads will benefit from Brooks’ insights on team dynamics, estimation, and system design. It’s also valuable for those studying software engineering history or managing complex technical initiatives. While rooted in 1970s IBM projects, its principles remain relevant for modern agile and DevOps environments.

What is Brooks’ Law in *The Mythical Man-Month*?

Brooks’ Law states that adding manpower to a late software project delays it further. New hires require training and increase communication paths, creating inefficiencies. This counterintuitive idea highlights why throwing resources at deadlines often backfires, emphasizing the need for better planning over staffing fixes.

How does *The Mythical Man-Month* address software design?

Brooks advocates for **modular design** to reduce complexity, enabling parallel workstreams and easier debugging. He stresses **conceptual integrity**—ensuring a unified vision across components—to avoid disjointed systems. These principles underpin modern practices like microservices and API-first development.

What are the key criticisms of *The Mythical Man-Month*?

Critics note its examples feel outdated (e.g., waterfall-era IBM projects) and that modern tools (Git, CI/CD) mitigate some coordination challenges. However, Brooks’ core arguments about team dynamics and estimation remain widely accepted, making the book a foundational but debated text.

How does *The Mythical Man-Month* apply to remote teams?

Brooks’ emphasis on communication aligns with remote work challenges. He warns against fragmented collaboration, recommending clear documentation and structured meetings—principles mirrored in async workflows and tools like Slack. Remote leads must still balance team size and coordination costs.

What is the “tar pit” metaphor in *The Mythical Man-Month*?

The “tar pit” essay likens software development to prehistoric creatures trapped in sticky tar: initial progress seems easy, but systems grow entangled, slowing momentum. Brooks uses this to illustrate how complexity escalates, urging teams to prioritize simplicity and avoid over-engineering.

How does *The Mythical Man-Month* compare to modern agile methods?

While Brooks predates agile, his focus on iterative planning and modularity aligns with Scrum and DevOps. However, he cautions against excessive flexibility, advocating for upfront architectural clarity—a contrast to agile’s embrace of changing requirements.

人月の神話

ソフトウェアエンジニアリングに関するエッセイ

フレデリック・ブルックス

5(1 Reviews)

『人月の神話』の概要

なぜソフトウェアプロジェクトは失敗するのでしょうか？ブルックスによる1975年の伝説的名著は、「遅れているプロジェクトに人員を追加すると、さらに遅れる」という、直感に反する原則を明らかにしています。この原則は、今なおAmazonのようなテック大手に影響を与え続けています。ジェフ・ベゾスにAWSでのスケーリングを再考させた一冊です。

語り方を選ぶ

1冊の本。さまざまな聴き方。

人月の神話の同じアイデアを、あなたに合う声・深さ・ペースで学べます。いつでも切り替えられます。

第1章

When Software Engineering Meets the Tower of Babel

The year is 1975. A young IBM engineer sits at his desk, reflecting on the monumental challenges he faced while leading the development of OS/360, one of the most ambitious software projects of its era. His name is Frederick P. Brooks Jr., and he's about to publish a book that will fundamentally change how we think about software development. "The Mythical Man-Month" would go on to become required reading for generations of software engineers, with tech luminaries from Bill Gates to Jeff Bezos citing its profound influence on their thinking. Even decades after publication, this slim volume continues to sell over 10,000 copies annually-a testament to its enduring wisdom in an industry where most technical books become obsolete within years, if not months. What makes this book so special? Perhaps it's that Brooks identified the timeless human elements of software development that transcend technological change, or maybe it's his rare combination of academic rigor and practical experience. Whatever the reason, few technical books have achieved such cultural permanence in the software engineering world.

第2章

The Tar Pit: Why Software Projects Get Stuck

Software development is a treacherous endeavor. Like prehistoric beasts trapped in tar pits, large-system programming projects have ensnared countless talented teams who, despite heroic struggles, rarely meet their goals, schedules, or budgets. The difficulty comes not from any single problem but from the accumulation of interacting factors that gradually slow progress to a crawl. What makes software development so challenging? For one, we consistently underestimate the complexity of what we're building. A simple program that runs on its developer's machine is vastly different from a programming systems product ready for public use. To become a programming product, a program must be generalized, thoroughly tested, and extensively documented-costing at least three times as much as a debugged program. To become a programming system component, it must conform precisely to interfaces, use only allocated resources, and be tested with all other components in all combinations-again tripling the cost. A programming systems product, combining both sets of requirements, costs nine times as much as a simple program. Yet despite these challenges, programming offers unique joys that keep us coming back. There's the sheer delight of making things-the programmer is a creator, building castles in the air through pure imagination. There's the pleasure of crafting something useful to others. There's the fascination of creating complex, interlocking objects and watching them work harmoniously. There's the perpetual learning that comes from constantly encountering new problems. And perhaps most distinctively, there's the joy of working in such a tractable medium-pure thought-stuff that takes any shape we can imagine. But these joys come with corresponding woes. Programming demands perfection-one character wrong and the magic fails. This requirement for absolute precision is perhaps the hardest adjustment for new programmers. We must work toward objectives set by others, with resources and information they provide. We depend on others' often poorly designed and documented programs. After the excitement of designing grand concepts comes the tedium of finding small bugs. Debugging converges linearly-the last bugs take longer than the first. And our work may become obsolete even before completion as colleagues pursue newer ideas. The tar pit is real, but understanding its nature is the first step toward navigating it successfully.

聴きながら、すべての言葉を目で追えます

『人月の神話』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第3章

The Mythical Man-Month: Why Adding People Makes Projects Later

"Adding manpower to a late software project makes it later." This counterintuitive statement, now known as Brooks's Law, strikes at the heart of one of software management's most persistent myths: that men and months are interchangeable. The man-month as a unit of measurement is a dangerous myth that has led countless projects astray. It implies that people and time can be traded for each other, that four programmers can accomplish in one month what one programmer could do in four. This might be true if tasks could be perfectly partitioned with no communication needed between workers-like harvesting wheat or picking cotton. But software development isn't like that. When tasks require complex coordination, communication overhead increases geometrically with team size. If each part of a task must be separately coordinated with each other part, the effort increases as n(n-1)/2. Adding more people increases this coordination burden dramatically. Three workers require three communication channels; seven workers require twenty-one channels. The added communication burden can quickly outweigh any productivity gains from division of labor. Consider what happens when you add people to a late project. New team members aren't immediately productive-they need time to learn the system, understand the goals, and get up to speed. During this ramp-up period, they actually make negative contributions because they divert time and attention from experienced team members who must train them. The work must be repartitioned, interfaces redefined, and some completed work may be lost in the transition. All of this creates a regenerative cycle where adding people makes the project later still. Our estimation techniques remain poorly developed, confusing effort with progress and assuming all will go well. But large programming efforts consist of many chained tasks, making the probability of everything going well vanishingly small. Most software projects fail from lack of calendar time than all other causes combined. Proper scheduling should allocate one-third for planning, one-sixth for coding, and fully half for testing-much more than typically allowed but reflecting reality. The number of months depends on sequential constraints, while maximum manpower depends on independent subtasks. Recognizing these realities is essential for realistic project planning. Think of it this way: nine women can't deliver a baby in one month. Some tasks simply cannot be accelerated by adding more people.

第4章

The Surgical Team: Organizing for Excellence

Large individual differences in programmer productivity create a fundamental dilemma for software projects. Studies by Sackman, Erikson, and Grant revealed astonishing variations among experienced programmers-averaging 10:1 on productivity measurements and 5:1 on program speed and space measurements. This suggests a $20,000/year programmer might be ten times as productive as a $10,000/year one, with no correlation between experience and performance. While everyone favors small, sharp teams of exceptional people, the question remains: how does one build large systems on a meaningful schedule? A 10-person team, even if seven times more productive than average programmers, would take 10 years to build something like OS/360-by which time it might be obsolete. Harlan Mills proposed organizing programming teams like surgical teams rather than hog-butchering teams. Instead of everyone cutting away at the problem, one person does the cutting while others provide support to maximize effectiveness. This approach maintains the conceptual integrity of few minds while bringing many hands to bear. The surgical team includes: • The surgeon (chief programmer) who defines specifications, designs, codes, tests and documents the program • The copilot who shares design thinking but isn't responsible for code • The administrator who handles non-technical matters • The editor who refines documentation • Secretaries for administrative support • A program clerk who maintains technical records • A toolsmith who ensures adequate computing services • A tester who creates test cases • A language lawyer who masters programming language intricacies This structure meets the goal of having ten people contribute while the system remains the product of essentially one mind. Unlike conventional teams where partners divide work and negotiate differences, the surgeon-copilot team both know all the design and code, with the surgeon making final decisions unilaterally. This eliminates both division of problem and equal-partner conflicts. The specialized functions of other team members create a radically simpler communication pattern. The surgical team concept can scale to large projects by coordinating multiple teams. With each team's conceptual integrity improved by reducing design minds by a factor of seven, 200 people might require coordinating only 20 minds-those of the surgeons. This coordination still requires separate techniques, including a system architect who designs from the top down, maintaining a sharp distinction between architecture and implementation. This approach recognizes that the best programmers are not marginally better than average ones-they are an order of magnitude better in terms of productivity, creativity, and error rates.

『人月の神話』をもっと深く楽しむ

毎日の新しい気づきを10万件以上のレッスンから
言葉をハイライトして音声と同期
ライブラリを保存して、どの端末からでも利用

第5章

Conceptual Integrity: The Essential System Quality

Most programming systems reflect worse conceptual disunity than cathedrals built over centuries. While cathedrals suffer from succession of builders across generations, software suffers from separation of design into many tasks done by many people simultaneously. I contend that conceptual integrity is the most important consideration in system design-more important than features, efficiency, or even correctness. It's better to omit certain anomalous features but reflect one set of design ideas than to include many good but uncoordinated ideas. Like Reims Cathedral, whose unity was achieved through eight generations of builders sacrificing individual ideas for pure design, software requires similar self-abnegation to achieve integrity. A programming system's purpose is making computers easy to use through languages and facilities that are themselves programs. But these come at a price: the external description grows ten to twenty times larger than that of the computer system itself. Ease of use improves only if time gained in functional specification exceeds time lost learning the system. The ratio of function to conceptual complexity is the ultimate test of system design-neither function alone nor simplicity alone defines good design. OS/360 excels in function but not simplicity; the PDP-10 Time-Sharing System excels in simplicity but lacks comparable function. Both are unbalanced when ease of use becomes the criterion. Conceptual integrity demands design from one mind or a small group of resonant minds. This creates tension with the need for many hands to meet schedules. Two solutions exist: separating architecture from implementation, and structuring teams as discussed earlier. Architecture-the complete specification of user interface-must be distinguished from implementation-how that interface is realized. The architect serves as the user's agent, while implementers have equally creative but different work. Far from stifling creativity, architectural constraints actually focus implementers' inventiveness on unsolved problems. The architect works against budget constraints, getting early feedback from builders. When estimates exceed budgets, the architect must either cut the design or suggest cheaper implementations. The latter approach requires delicacy-the architect must remember the builder has creative responsibility for implementation, be prepared to suggest viable alternatives without dictating them, communicate privately, and forego credit. An architect's first system tends to be spare and clean, built with restraint born of uncertainty. During this process, many embellishments are set aside for "next time." The second system becomes the most dangerous one-the architect, now confident, incorporates all previously abandoned frills, resulting in an over-designed "big pile." OS/360 exemplifies this as a second system for most designers, showing both embellishment (26 bytes dedicated just to handle December 31 on leap years) and refinement of techniques made obsolete by changing assumptions. To avoid this effect, architects must exercise discipline, assign values to functions (memory/time costs), and managers should insist on senior architects with at least two systems of experience.

第6章

Communication: The Essence of Project Management

The Tower of Babel, mankind's second major engineering undertaking after Noah's ark, failed despite having a clear mission, ample manpower, materials, time, and adequate technology. The project collapsed due to two critical deficiencies: communication and organization. Without effective communication, coordination failed, leading to disputes and group jealousies that eventually caused the clans to separate. In modern projects, schedule disasters, functional misfits, and system bugs arise because teams don't know what others are doing. As work progresses, teams modify functions, sizes, and speeds of their programs, changing assumptions about inputs and outputs. For example, one implementer might reduce a function's speed based on usage statistics, while another team critically depends on that speed-creating a major specification change requiring system-wide consideration. Teams must communicate through multiple channels: informal telephone calls, regular project meetings where teams give technical briefings, and a formal project workbook that structures all project documents-objectives, specifications, technical standards, and administrative memos. For large projects like OS/360, each programmer received a complete workbook, with timely updates critical. When the physical workbook grew to five feet thick with daily changes averaging 150 pages, they switched to microfiche, saving space and reducing interfiling problems. With n workers on a project, there are potentially (n2-n)/2 communication interfaces and almost 2^n possible teams requiring coordination. For effective programming organization, any subtree needs six essentials: a mission, a producer (who assembles the team and manages resources), a technical director (who provides conceptual integrity), a schedule, division of labor, and interface definitions. The project manager's best ally is the independent product-testing organization that checks against specifications and acts as devil's advocate. Every development organization needs such an independent technical auditing group to maintain honesty. The product tester serves as surrogate customer, finding places where design decisions weren't properly understood or implemented. Despite precise specifications, countless architectural interpretation questions arise during implementation. It's essential that implementers call architects with questions rather than guessing. These answers become architectural pronouncements that must be shared with everyone. A practical solution is the telephone log-architects record all questions and answers, then concatenate and distribute these logs weekly to all users and implementers. Though informal, this mechanism provides quick and comprehensive communication. Communication and organization are critical for success-the Tower of Babel was perhaps the first engineering fiasco, but these techniques demand as much experienced competence from the manager as the software technology itself.

聴きながら、すべての言葉を目で追えます

『人月の神話』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第7章

The Essence of Programming: Data Representation

Program space is a principal cost, even for proprietary software. The system designer allocates hardware resources to resident-program memory when it provides more user value than spending on other hardware. Size control requires both technical and managerial attention. No amount of budgeting makes programs small-that requires invention and craftsmanship. The first area involves trading function for size, with a key policy question: how much choice should users have? Fine-grained options cost space compared to monolithic designs. For systems spanning memory sizes, a limiting effect occurs: small systems require small modules and overlay areas, forcing constraints that hurt performance even in larger configurations. The second area involves space-time trade-offs-generally, more space means faster execution. Managers should ensure programmers are trained in language-specific techniques and provide a technology notebook with both quick and squeezed versions of common functions like sorting and searching. Beyond craftsmanship lies invention, where lean, fast programs are born through strategic breakthroughs rather than tactical cleverness. While occasionally these come from new algorithms like the Fast Fourier Transform, more often breakthroughs emerge from reimagining data representation. "Show me your tables, and I won't usually need your flowcharts; they'll be obvious." Examples abound: an IBM 650 console interpreter that saved space by building an interpreter for the interpreter; Digitek's Fortran compiler using dense internal representation to avoid external storage. When space-constrained, the programmer should step back from code and contemplate data. Representation is the essence of programming. The way we organize and structure our data fundamentally shapes the algorithms we can apply and the efficiency with which our programs run. A well-chosen representation can make a complex problem simple, while a poor one can make even simple tasks cumbersome. Consider how different data structures affect algorithms: a problem that might require complex recursive traversal with one representation becomes a simple table lookup with another. The choice between arrays, linked lists, trees, hash tables, or more specialized structures can make orders of magnitude difference in both space and time efficiency. This principle extends beyond low-level data structures to the entire conceptual model of a system. How we represent the core abstractions in our domain-whether it's a document editor, a financial system, or a game engine-determines what operations are natural and efficient, and which are awkward and costly. The most profound design insights often come not from clever coding but from reconceptualizing the problem through a different representation. When faced with seemingly intractable complexity, the master programmer doesn't immediately dive into algorithmic optimization but steps back to reconsider how the data is structured and organized.

第8章

Plan to Throw One Away: Embracing Iteration

Software development, like chemical engineering, requires intermediate steps between laboratory and production. Yet programmers repeatedly plunge into building customer-deliverable software on tight schedules, ignoring this principle. The first system built is rarely usable-too slow, too big, or awkward. The real question isn't whether to build a throwaway system, but whether to plan for it or promise the throwaway to customers. Chemical engineers use pilot plants as an essential intermediate step between laboratory processes and full factory implementation. Programming system builders have been exposed to this lesson but haven't learned it. All large-system experience shows that discard and redesign will happen, especially with new concepts or technologies. Delivering a prototype to customers creates user agony, distracts developers, and damages the product's reputation. Once we accept that pilot systems must be discarded and redesigns are inevitable, we must face the phenomenon of change itself. The first step is accepting change as a way of life rather than an annoying exception. Programmers deliver satisfaction of user needs rather than tangible products, and both actual needs and perceptions of them evolve as programs are built and used. While hardware products have tangible existence that contains change requests, software's tractability and invisibility expose it to perpetual requirement changes. Though not all changes should be incorporated-thresholds must rise as development proceeds-changes in both objectives and development techniques are inevitable. Designing systems for change involves well-known techniques: careful modularization, extensive subroutining, precise interface definitions, and complete documentation. Less obviously, standard calling sequences and table-driven techniques should be used wherever possible. High-level languages and self-documenting techniques reduce errors from changes. Quantization of change is essential-every product should have numbered versions with schedules and freeze dates. Program maintenance differs fundamentally from hardware maintenance-it's not about cleaning or repairing deterioration but fixing design defects and adding functions. Maintenance typically costs 40% or more of development costs, with more users finding more bugs. The fundamental problem: fixing a defect has a 20-50% chance of introducing another. Repairs are often made by junior programmers who don't understand system-wide ramifications, requiring extensive regression testing. Lehman and Belady's research shows that while the total number of modules increases linearly with each release, the number of affected modules increases exponentially. Repairs destroy structure, increasing entropy until fixing ceases to gain ground-each forward step matched by a backward one. Systems programming is entropy-decreasing, while maintenance is entropy-increasing. Even the most skillful maintenance only delays the inevitable slide into unfixable obsolescence. The lesson is clear: plan to throw one away, you will anyway. But make that throwaway deliberate and learn from it, rather than delivering it to customers and suffering the consequences.

『人月の神話』をもっと深く楽しむ

毎日の新しい気づきを10万件以上のレッスンから
言葉をハイライトして音声と同期
ライブラリを保存して、どの端末からでも利用

第9章

No Silver Bullet: The Inherent Complexity of Software

There is no single development in technology or management that promises even one order-of-magnitude improvement in software productivity, reliability, or simplicity within a decade. While hardware has seen extraordinary gains, software development remains inherently difficult due to its essential complexity. Software construction involves both essential tasks (creating complex conceptual structures) and accidental tasks (representing these abstractions in programming languages within constraints). Most productivity gains have come from removing artificial barriers to the accidental tasks. However, addressing the essential complexity of software requires different approaches. Software's inherent nature makes silver bullets unlikely. The anomaly isn't that software progress is slow but that hardware progress is exceptionally fast. Software's essence is a construct of interlocking concepts-data sets, relationships, algorithms, and function invocations-that is abstract yet precisely detailed. The true difficulty lies in specifying, designing, and testing this conceptual construct, not merely representing it. Four inherent properties make software development inherently difficult: • Complexity: No two parts are alike, and scaling is nonlinear • Conformity: Software must adapt to arbitrary human institutions and interfaces • Changeability: Software is malleable and embodies functions that face pressure to evolve • Invisibility: Software has no inherent spatial representation, consisting of multiple superimposed directed graphs that resist visualization These essential difficulties cannot be abstracted away without losing the essence of software itself. The most productive advances in software development have addressed accidental rather than essential difficulties. High-level languages delivered at least a five-fold improvement in productivity by freeing programs from machine complexities. Time-sharing preserved immediacy of thought by eliminating slow turnaround times. Unified environments like Unix and Interlisp improved productivity by enabling programs to work together through integrated libraries and standard formats. While no technological breakthrough promises magical hardware-like results, several approaches do address software's conceptual essence: • Buy, don't build: The mass market for software has created affordable off-the-shelf packages • Requirements refinement through rapid prototyping: Build simulations of key interfaces to test conceptual structures • Incremental development: Start with a minimal running system and grow it bit by bit • Cultivate great designers: The best designers produce structures that are faster, smaller, simpler-approaching an order of magnitude better than average The most radical solution is not to build software at all but to buy it-the mass market for software has created affordable off-the-shelf packages that effectively multiply developer productivity. Rather than building software, we should grow it incrementally-starting with a minimal running system and fleshing it out bit by bit. This top-down approach allows easy backtracking, early prototypes, and the morale boost of always having a working system. Most importantly, we must cultivate great designers. While good design practices can be taught, the difference between good designs and great ones comes from creative individuals. Organizations must recognize and nurture these talents just as they do management prospects.

★★★★★

『人月の神話』を最後まで読み終えました

100万人以上の学習者に愛用されています

“23日間、毎日使い続けています。今では日課の一部です。”

jayallen

『人月の神話』の主要テーマ

brooks's law
software project estimation
communication overhead
systemic complexity
man-month myth

『人月の神話』の名言

The bearing of a child takes nine months, no matter how many women are assigned.
How does a project get to be a year late? ... One day at a time.
Plan to throw one away; you will, anyhow.
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.

『人月の神話』の登場人物

Frederick P. Brooks Jr.Author and former IBM OS/360 project leader

著者について

フレデリック・フィリップス・ブルックス・ジュニア（Frederick Phillips Brooks Jr.、1931年–2022年）は、アメリカの計算機科学者であり、ソフトウェアプロジェクト管理とシステムアーキテクチャにおける先見の明のある人物としての地位を確立した記念碑的著作『人月の神話：ソフトウェア工学の教訓（The Mythical Man-Month: Essays on Software Engineering）』の著者です。

ハーバード大学で博士号を取得し、IBMのベテランであったブルックスは、画期的なIBM System/360とそのソフトウェアOS/360の開発を主導しました。これらの経験は、スコープクリープやチームの調整といったソフトウェア工学の課題に関する彼の分析に直接反映されました。遅れているプロジェクトに人員を追加するとさらに遅れるという、彼の影響力のある「ブルックスの法則」はここで生まれました。

ブルックスはノースカロライナ大学の計算機科学科を創設し、20年間にわたり学科長を務めながら、インタラクティブ・グラフィックスやバーチャルリアリティの研究を推進しました。『人月の神話』以外にも、『コンピュータ・アーキテクチャ：概念と進化（Computer Architecture: Concepts and Evolution）』や『デザインのデザイン（The Design of Design）』といった決定的なテキストを共著しています。1999年には計算機科学の最高栄誉であるA.M.チューリング賞を受賞し、彼の業績は今なお計算機科学のカリキュラムの基礎となっています。4つの新しいエッセイが追加された『人月の神話』の20周年記念版は20以上の言語に翻訳されており、1975年の初版から数十年を経た今もなお、ソフトウェア工学の実践に影響を与え続けています。

人月の神話の要約をダウンロード

人月の神話の要約をPDFまたはEPUBで無料でダウンロード。印刷やオフラインでいつでもお読みいただけます。

他のユーザーのお気に入り

Making Things Happen

Scott Berkun

Software Engineering Deep Dive: Timeless Wisdom の書籍表紙

7 sources

Software Engineering Deep Dive: Timeless Wisdom

Inspired

Marty Cagan

Business Adventures

John Brooks

Effective Programming

Jeff Atwood

Myth of Multitasking, Second Edition

Dave Crenshaw

The one minute manager

Kenneth H. Blanchard

The Estimation Trap: Why Engineers Can't Predict Work の書籍表紙

3 sources

The Estimation Trap: Why Engineers Can't Predict Work

この本に関するよくある質問

学習プラン

Master One Project to Prevent Burnout

In an era of constant connectivity, professionals often mistake busyness for productivity, leading to chronic exhaustion. This plan is designed for high-achievers and creative professionals who need to reclaim their focus and prevent burnout by mastering the power of single-project excellence.

4 h 22 m•4 セクション

学習プラン

The Management Shadow: Taleb/Kahneman/Greene

In an era of radical uncertainty, traditional management frameworks often fail because they ignore human irrationality and the impact of rare events. This plan is designed for leaders and strategists who want to master the hidden psychological and systemic forces that govern success and power.

4 h 43 m•4 セクション

学習プラン

The Creative Time Architect

Traditional productivity often fails creatives by prioritizing clock time over cognitive energy. This plan is designed for artists, writers, and builders who need to balance high-output focus with the necessary downtime for innovation.

1 h 36 m•4 セクション

学習プラン

The High-Performance Manager's Playbook

This playbook is essential for new and mid-level managers struggling to balance execution with strategic leadership. It provides the tactical tools needed to shift from doing the work to driving results through others and protecting deep work.

2 h•4 セクション

学習プラン

How to improve my time management

Modern professionals often struggle with burnout and constant distractions in an always-on world. This plan is designed for anyone looking to transition from being busy to being truly productive by mastering both biological rhythms and sophisticated organizational systems.

5 h 11 m•4 セクション

学習プラン

The One-Problem Product Blueprint

This blueprint is essential for entrepreneurs and creators who struggle with over-engineering products that nobody buys. It provides a lean framework to move from identifying raw pain points to securing paid validation with minimal wasted effort.

1 h 12 m•3 セクション

学習プラン

The Manager’s Survival Guide

In today's volatile work environment, managers face the dual challenge of driving results while protecting team well-being. This guide is essential for new and experienced leaders navigating layoffs, burnout, and the rapid rise of AI. It provides the tactical tools needed to restore trust and maintain high performance under pressure.

2 h 30 m•5 セクション

学習プラン

Energy First: The Sustainable Productivity System

Traditional time management often ignores the biological reality of human performance, leading to burnout. This system is designed for high-performers and knowledge workers who need to optimize their cognitive output while maintaining long-term health and focus.

2 h•4 セクション

コロンビア大学卒業生がサンフランシスコで開発

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

BeFreedがウェブ上でどのように話題になっているかをもっと見る

コロンビア大学卒業生がサンフランシスコで開発

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

BeFreedがウェブ上でどのように話題になっているかをもっと見る

今すぐ学習の旅を始めよう

第9章

人月の神話

概要『人月の神話』の概要

1冊の本。さまざまな聴き方。

When Software Engineering Meets the Tower of Babel

The Tar Pit: Why Software Projects Get Stuck

聴きながら、すべての言葉を目で追えます

The Mythical Man-Month: Why Adding People Makes Projects Later

The Surgical Team: Organizing for Excellence

『人月の神話』をもっと深く楽しむ

Conceptual Integrity: The Essential System Quality

Communication: The Essence of Project Management

聴きながら、すべての言葉を目で追えます

The Essence of Programming: Data Representation

Plan to Throw One Away: Embracing Iteration

『人月の神話』をもっと深く楽しむ

No Silver Bullet: The Inherent Complexity of Software

『人月の神話』を最後まで読み終えました

『人月の神話』の主要テーマ

『人月の神話』の名言

『人月の神話』の登場人物

著者について

人月の神話の要約をダウンロード

他のユーザーのお気に入り

この本に関するよくある質問

What is The Mythical Man-Month about?

Who should read The Mythical Man-Month?

What is Brooks’ Law in The Mythical Man-Month?

How does The Mythical Man-Month address software design?

もっと見る

1,000,000+ curious minds.

1,000,000+ curious minds.

1冊の本。さまざまな聴き方。

When Software Engineering Meets the Tower of Babel

The Tar Pit: Why Software Projects Get Stuck

聴きながら、すべての言葉を目で追えます

The Mythical Man-Month: Why Adding People Makes Projects Later

The Surgical Team: Organizing for Excellence

『人月の神話』をもっと深く楽しむ

Conceptual Integrity: The Essential System Quality

Communication: The Essence of Project Management

聴きながら、すべての言葉を目で追えます

The Essence of Programming: Data Representation

Plan to Throw One Away: Embracing Iteration

『人月の神話』をもっと深く楽しむ

No Silver Bullet: The Inherent Complexity of Software

『人月の神話』を最後まで読み終えました

他のユーザーのお気に入り

もっと見る

『人月の神話』の概要