What is *Lean Software Development* by Mary Poppendieck about?

*Lean Software Development* adapts Toyota’s Lean manufacturing principles to software engineering, focusing on eliminating waste, delivering customer value faster, and fostering continuous improvement. It outlines seven core principles, including amplifying feedback, delaying commitment, and empowering teams, to optimize workflows and create high-quality software. The book blends case studies, exercises, and actionable strategies for streamlining development processes.

Who should read *Lean Software Development*?

This book is ideal for software developers, project managers, and IT leaders seeking to reduce inefficiencies and enhance product quality. It’s also valuable for Agile practitioners looking to integrate Lean thinking into iterative workflows, as well as anyone interested in customer-centric, waste-free development methodologies.

Is *Lean Software Development* worth reading in 2025?

Yes. Despite being published in 2003, its principles on waste reduction, rapid feedback, and systems thinking remain foundational in modern DevOps and Agile practices. The focus on adaptability and customer value aligns with current trends like CI/CD and MVP-driven development, making it a timeless resource.

What are the 7 core principles of Lean Software Development?

1. **Eliminate waste** (non-value-adding activities). 2. **Amplify learning** through iterative feedback. 3. **Decide as late as possible** to retain flexibility. 4. **Deliver as fast as possible** to accelerate learning. 5. **Empower teams** to make decisions. 6. **Build integrity in** via continuous testing. 7. **Optimize the whole system**, not individual parts.

How does Lean Software Development reduce costs?

By cutting waste (e.g., unused features, delays), minimizing rework through early feedback, and simplifying code to lower maintenance costs. Lean’s focus on incremental delivery prevents overinvestment in unvalidated ideas, ensuring resources align with actual customer needs.

What role does customer feedback play in Lean Software Development?

Customer feedback loops are central. Teams release minimal viable products (MVPs) early, gather user insights, and iterate rapidly. This ensures alignment with market demands, reduces the risk of building unnecessary features, and builds trust through responsive development.

How does *Lean Software Development* differ from Agile methodologies?

While both emphasize iterative delivery, Lean prioritizes **waste reduction** and **end-to-end value streams**, whereas Agile focuses on collaboration and adaptability. Lean introduces manufacturing-inspired concepts like *just-in-time decision-making*, whereas Agile frameworks (e.g., Scrum) structure workflows via sprints and roles.

What real-world examples illustrate Lean Software Development?

The book cites cases where teams: - Shortened release cycles from months to weeks by eliminating bureaucratic approvals. - Reduced bug-fixing costs by 60% through automated testing. - Improved customer satisfaction by involving users in prioritization workshops.

リーンソフトウェア開発と組織改革

コンセプトから収益化まで

メアリー・ポッペンディーク

4.18(1065 Reviews)

『リーンソフトウェア開発と組織改革』の概要

2003年以来、ソフトウェア開発に革命をもたらしてきた「リーン・ソフトウェア開発」は、テック大手の製品開発のあり方を変貌させました。ポッペンディーク夫妻による「無駄の排除」の原則は、ウォーターフォールからアジャイルへの業界全体の転換を促しました。なぜこの手法は、世界中のソフトウェアリーダーにとっての必読書となったのでしょうか？

語り方を選ぶ

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

リーンソフトウェア開発と組織改革の同じアイデアを、あなたに合う声・深さ・ペースで学べます。いつでも切り替えられます。

第1章

The Lean Revolution: How Toyota's Manufacturing Principles Are Transforming Software Development

Ever wonder why some software projects deliver elegant, user-friendly systems while others become bloated, buggy nightmares? The answer might come from an unexpected source: automobile manufacturing. When Mary Poppendieck returned to software development after years in manufacturing leadership at 3M, she was shocked to find the industry dominated by heavy process definition and detailed front-end planning-approaches that contradicted everything she'd learned about lean manufacturing. This revelation led her and her husband Tom to write "Lean Software Development: An Agile Toolkit," a groundbreaking work that has influenced countless development teams since its publication. The book has become required reading in many technology companies, with executives at firms like Spotify and Netflix citing its principles as foundational to their development approaches. Even tech giants like Google and Microsoft have incorporated these lean principles into their development practices, demonstrating the book's enduring relevance in an ever-changing technology landscape.

第2章

Eliminate Waste: The Foundation of Lean Thinking

Imagine spending months meticulously documenting requirements for software that, once built, doesn't actually solve the customer's problem. This scenario represents one of the most fundamental forms of waste in software development-effort that creates no value. The concept of eliminating waste originated with Toyota's Taiichi Ohno in the late 1940s when he faced the challenge of manufacturing affordable cars in small quantities for the Japanese market. Ohno defined waste broadly as anything not directly creating customer value. In software development, this translates to seven specific types of waste: partially done work, extra processes, extra features, task switching, waiting, motion, and defects. Partially done work is particularly insidious-unintegrated code sitting in development represents investment without return and carries the risk of becoming obsolete before delivery. Documentation that no one eagerly awaits represents extra process waste. "Just in case" features create code that must be maintained but may never be used. Task switching between multiple projects creates significant overhead-studies show that developers lose productivity every time they change context, making two sequential two-week projects faster to complete than two projects done in parallel over four weeks. Waiting-for approvals, testing, or deployment-prevents customers from realizing value and reduces an organization's ability to respond to market needs. Motion waste occurs when developers must seek answers from distant experts rather than having them nearby. And defects create waste proportional to their severity multiplied by detection time-a critical defect found immediately creates minimal waste, while a minor defect undiscovered for weeks creates much more. To combat these wastes, lean practitioners use value stream mapping-a technique that visualizes the flow from customer request to delivery, revealing where value is added and where waste occurs. By physically following a customer request through your organization and measuring time spent in each step, you can identify bottlenecks and streamline processes. Traditional value streams often show that only a small percentage of time is spent on value-adding activities, with the rest consumed by waiting and handoffs. One organization transformed their development process from a year-long cycle with only 33% value-adding time to a three-month process with most time spent adding value. Key improvements included weekly approval meetings, dedicated staffing, incremental development, and early deployment planning-all focused on rapid customer response. The journey to eliminating waste begins with learning to see it. As you examine your development process, ask whether each activity directly contributes to customer value. If not, it's a candidate for elimination or streamlining. Remember, waste isn't just inefficiency-it's anything that doesn't directly contribute to solving the customer's problem.

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

『リーンソフトウェア開発と組織改革』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第3章

Amplify Learning: Software Development as Knowledge Creation

Software development isn't a production process-it's fundamentally about learning. While manufacturing focuses on following established recipes with minimal variation, development creates the recipe through exploration and discovery. This distinction is crucial because applying production-oriented practices to development often leads to failure. Quality in software requires both perceived integrity (delighting customers through balanced functionality) and conceptual integrity (a cohesive system design). Unlike manufacturing, which defines quality as conformance to requirements, software quality means fitness for use-even as problems and needs evolve. Research by Raymonde Guindon challenges the notion that good programmers work in a structured, top-down manner. When tackling ill-defined problems, experienced designers move fluidly between examining scenarios, clarifying requirements, high-level solution development, and detailed design of difficult elements. This unstructured approach is necessary for understanding complex problems. Problem-solving requires generating information through experimentation. In software, two schools exist: making everything perfect the first time versus rapid try-it, test-it, fix-it cycles. For ill-structured problems, the latter typically works better. As Edward Yourdon noted, programming logic often needs multiple revisions to achieve elegance, just like professional writing requires multiple drafts. Feedback transforms systems from rigid to responsive. Even Winston Royce, whose work became associated with the waterfall model, recognized in 1970 that early feedback through prototyping was essential. When software projects struggle, increasing feedback-not imposing more rigid sequential processes-is typically the most effective solution. Iterations are as fundamental to lean development as small batches are to lean manufacturing. An iteration is a useful increment of software designed, programmed, tested, integrated, and delivered during a short, fixed timeframe. Unlike sequential development, iterations provide dramatic increases in feedback between customers and developers, expose design problems early, and build change-tolerance into the system. Effective iteration planning focuses on implementing coherent feature sets that deliver meaningful business value but are small enough to complete within a single iteration. Features come from customers as use cases, stories, or backlog items. At the beginning of each iteration, the development team estimates the difficulty level of features while customers decide which are most important given their cost. A key strategy for achieving convergence is working on top-priority items first, letting low-priority items fall off the list. Since studies show 45% of features in typical systems are never used and 19% rarely used, negotiable scope makes sense. By delivering highest-priority features first and measuring team velocity, projects become more predictable, not less. Set-based development offers an alternative to traditional point-based approaches by working with multiple options simultaneously and gradually narrowing possibilities. Rather than committing to a single solution early, set-based development encourages creating multiple alternative solutions to difficult problems. While seemingly wasteful, this approach often leads to better solutions faster. When tackling difficult problems, resist jumping to solutions and instead keep constraints visible so the team can discover design intersections that work for all concerned. Through repeated meetings where unworkable ideas are eliminated, novel solutions often emerge that no one would have conceived initially.

第4章

Decide as Late as Possible: Maintaining Options in an Uncertain World

In the 1980s, U.S. automakers waited for "frozen" designs before cutting dies for new car bodies, resulting in costly changes when designs inevitably shifted. Japanese manufacturers, however, used concurrent development-starting die production simultaneously with car design. Die engineers anticipated solutions, maintained constant communication with body engineers, and used techniques allowing late changes. This approach reduced change costs significantly and produced better dies. Similarly, sequential software development forces depth-first approaches that lead to costly mistakes by committing to detailed decisions too early without understanding high-level consequences. Concurrent software development, typically through iterative approaches, allows breadth-first exploration that discovers major problems early. Starting programming after high-level conceptual design, even while detailed requirements are still evolving, provides insurance against costly mistakes. Options thinking applies the concept of "satisfaction guaranteed" to software development. HP discovered that delaying printer electrical configuration until warehouse delivery saved $3 million monthly despite higher unit costs, by perfectly matching supply to demand. Economist Enrico Zaninotto explained that just-in-time systems control complexity by minimizing irreversible actions, contrasting with mass production's approach of limiting options. Microsoft demonstrated perfect options thinking at the 1988 Comdex trade show with their seemingly confused strategy-simultaneously offering DOS, early Windows, OS/2, UNIX, and applications for multiple platforms. While competitors committed to single platforms, Gates hedged his bets across operating systems. By developing expertise in both operating systems and applications while letting the market determine winners, Gates kept choices open until uncertainty resolved. The debate between predictive and adaptive processes centers on when decisions should be made. Predictive approaches specify requirements and design upfront, assuming a stable world. Adaptive approaches create options that delay decisions until customer needs are clearer and technologies mature. Agile development isn't unplanned-plans enhance flexibility-but avoids prespecifying detailed actions based on speculation. Concurrent development means delaying commitment until the "last responsible moment"-the point where not deciding eliminates important alternatives. This isn't procrastination but requires disciplined tactics: sharing partial design information, enabling direct worker collaboration, and developing change absorption capabilities. Expert developers know how to delay commitments and repair errors before they cause problems, unlike amateurs who overcommit early. Problem-solving strategies come in two forms: breadth-first (like a funnel) and depth-first (like a tunnel). Depth-first approaches make early commitments and quickly reduce complexity, making them attractive to novice designers. However, they risk narrowing focus too soon and incur high change costs if redirection becomes necessary. Breadth-first approaches delay commitments and work better when business domains are evolving. Gary Klein's research on emergency responders revealed that experienced professionals rarely make conscious decisions-they simply know what to do based on pattern recognition and mental simulation. This intuitive decision-making approach, built on experience and situational training, proves highly successful. Rational, deliberative decision-making is actually the fallback approach used only when experience is inadequate. The U.S. Marines specialize in chaos, with everything geared toward high-speed, complex environments. Their approach includes rapid but thorough planning focused on understanding situations rather than predicting outcomes. Once engaged, organizational structure collapses, with frontline personnel making decisions based on current information. Leaders communicate clear intent while leaving details to those on the ground.

『リーンソフトウェア開発と組織改革』をもっと深く楽しむ

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

第5章

Deliver as Fast as Possible: Speed as Competitive Advantage

Companies like Federal Express, L.L.Bean, and LensCrafters transformed their industries through rapid delivery capabilities. Rapid delivery benefits both customers and businesses. Customers gain increased flexibility, the ability to delay decisions, and quicker gratification. Businesses reduce risk by delivering before customers change their minds, minimizing work-in-process inventory that might become obsolete, and uncovering problems sooner. Rapid delivery requires everyone to know what they should be working on at all times. In fast-moving environments, central command structures are too slow; instead, local signaling and commitment mechanisms must coordinate work by letting customer needs pull the work rather than schedules pushing it. MRP (material requirements planning) systems failed when used for shop floor scheduling because they were "nervous"-the slightest change would completely reorganize the entire schedule. Just-in-time manufacturing solved this through pull systems using kanban, where work is triggered by downstream customer needs. When parts are used, kanban cards signal upstream workstations to produce replacements. Software pull systems start with short iterations based on customer input. Features are written on index cards (like kanban cards) which developers choose from a "To Do" area, move to "Checked Out" while working, and finally to "Tests Passed" when complete. Daily 15-minute team meetings help coordinate work, with each member sharing yesterday's accomplishments, today's plans, and where help is needed. Information radiators are visual controls that make work self-directing by showing what's happening, what needs doing, and what problems exist. These include kanban boards showing work status, burn-down charts tracking progress, and visible lists of problems, improvement ideas, and refactoring candidates. Bottlenecks in development can be addressed through queuing theory, which focuses on reducing cycle time (the total time from entering a process to completion). Queuing theory shows that: 1) Work-in-queue directly correlates to cycle time; 2) Variability increases cycle time; 3) Larger batch sizes increase cycle time; 4) Higher utilization increases cycle time non-linearly; 5) With high variability, even moderate utilization causes delays. Resources at full utilization dramatically increase cycle time. When managers try to keep testers or developers 100% busy, they create growing backlogs and longer delays. Small batches move through systems much faster than large ones, especially at high utilization. Unlike computer servers that are never run at full capacity, software teams are often overloaded, creating bottlenecks that harm the entire value stream. Traditional cost analysis often fails to account for the value of delivering software faster. By creating economic models that show the impact of delay on profitability, teams can make better decisions about investments in tools and process improvements. The cost of delay is frequently the highest leverage point in product development economics, with delays causing significant market share and revenue losses that far outweigh development cost overruns.

第6章

Empower the Team: Unleashing Human Potential

The NUMMI case study demonstrates the power of self-determination. When Toyota took over GM's failed Freemont plant in 1984, they rehired the same workers but transformed the culture by having teams design their own work procedures. Within two years, productivity doubled, quality soared, and worker satisfaction dramatically improved. The key difference: rather than engineers dictating procedures, workers used stopwatches to design their own jobs, with management serving as coaches and trainers. Most organizational improvement programs fail because they impose change from above. GE's Work-Out program succeeded by inverting this model-workers propose improvements while managers must make immediate yes-no decisions on their ideas. The program empowers those closest to the work to identify process barriers and implement solutions, with management's role shifting to enabling rather than directing. 3M's remarkable innovation success stems from William McKnight's organizational design that nurtures self-organizing teams. For over 75 years, the company has maintained its competitive edge through a simple formula: scientists spend 15% of their time on projects of their choosing, product champions recruit volunteer teams around compelling ideas, and managers serve as sponsors who protect these initiatives. Intrinsic motivation requires four essential building blocks: belonging, safety, competence, and progress. Belonging emerges when teams have clear shared goals and win or lose together, without individual competition. Safety requires an environment where mistakes are tolerated as part of learning and growth, avoiding what the U.S. Army calls a "zero defects mentality" that kills initiative. People need to believe they're capable of doing good work and be part of something successful. Software development requires discipline-version control, coding standards, build processes, and automated testing-for work to proceed smoothly. Competence comes from knowledge, skill, positive feedback, high standards, and meeting difficult challenges. Even highly motivated teams need to feel they've accomplished something, which reaffirms purpose and keeps everyone energized. This is a compelling reason for iterative development-teams regularly put their work in front of customers and get feedback. Projects need meaningful, visible measurements showing progress toward goals. Leadership differs fundamentally from management-as John Kotter notes, "No one has yet figured out how to manage people effectively into battle; they must be led." At 3M, every major new product development is led by a "champion" who writes the initial concept, gathers management support, recruits the team, and interprets the product vision. Similarly, Toyota's chief engineers study target markets, establish designs, set schedules, and take complete responsibility for vehicle performance. Research by Bill Curtis found that large systems typically have a single or small team of "exceptional designers" who assume primary design responsibility. These master developers lead through superior knowledge rather than formal authority. They deeply understand both customers and technical issues, are consumed with their systems' success, and become communication focal points.

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

『リーンソフトウェア開発と組織改革』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第7章

Build Integrity In: Creating Cohesive Systems That Delight Users

In the late 1980s, Harvard's Kim Clark found that the key differentiator between average and high-performing companies was product integrity, which has two dimensions: perceived integrity and conceptual integrity. Perceived integrity means the product achieves a balance of function, usability, reliability, and economy that delights customers. Conceptual integrity means the system's central concepts work together as a smooth, cohesive whole. Perceived integrity is in the eyes of the beholder-it's when software suits users so well they feel the designer must have been "inside their head." Google exemplifies this with its speed, clean results display, and forgiving nature with typos. Conceptual integrity means a system's components match and work well together, with the architecture balancing flexibility, maintainability, efficiency, and responsiveness. According to Clark and Fujimoto, integrity is achieved through excellent information flow. Perceived integrity reflects the quality of information flow from customers to developers, while conceptual integrity reflects the upstream/downstream technical information flow within the development team. Perceived integrity requires direct communication between customers and developers. Traditional sequential development fails because customer requirements pass through multiple layers of documentation and handoffs, losing critical information. Instead, companies that achieve perceived integrity keep customer values directly in front of technical decision-makers. Model-driven design creates a domain model that both customers and developers understand and use directly. Eric Evans advocates using a "ubiquitous language" where everyone uses the same terminology, typically drawn from the customer domain. Effective models include conceptual domain models capturing key entities and relationships, glossaries defining consistent terminology, use case models showing dynamic system behavior, and qualifiers describing performance requirements. Software architecture typically begins with standard architectural layers that provide a solid foundation. The basic layers include presentation (user interface), domain (business logic), and data source (persistence, messaging). Lower layers shouldn't depend on higher ones, allowing each layer to be tested independently. This layering creates high cohesion within layers and separation of concerns between them-fundamental architectural patterns that achieve system integrity. Engineering historian Henry Petroski shows that design improvement comes from starting with something that works, learning from its weaknesses, and making improvements. Complex systems have effects not fully understood at design time, making suboptimal choices inevitable. This contradicts fears that iterative development produces ineffective architecture. Like lean manufacturing's continuous improvement philosophy, software systems require ongoing refinement by developers. Testing in software development serves similar purposes as in manufacturing: ensuring each component works correctly and the whole system functions as intended. Tests play five crucial roles: they communicate how things should work, provide feedback on whether the system works correctly, create scaffolding for safe changes throughout development, document how the system was actually built, and enable safe maintenance of production systems.

第8章

See the Whole: Systems Thinking in Software Development

Systems thinking examines organizations as interconnected systems where the whole is more than the sum of its parts. The best system depends not on individual component performance but on how well parts work together. When analyzing organizations through system dynamics, computer simulations often reveal unintended consequences of seemingly sound policies. Like Lance Armstrong winning the Tour de France while winning few individual stages, optimizing every component of a system often produces poor overall results. Breaking large jobs into smaller tasks creates a temptation to optimize each task separately, but this rarely maximizes system performance. When measurements focus on local optimization, they can harm system-wide performance. For example, a testing department measured on "applied ratio" (percentage of available hours charged to other departments) keeps staff numbers low and maintains large backlogs to ensure high utilization. This forces customer departments to wait longer for testing, increasing cycle times, reducing feedback, and ultimately producing lower quality products with more defects-which ironically increases the testing workload further. DeMarco and Lister warn that measuring knowledge worker performance "courts dysfunction." Rob Austin's theory explains why: people optimize whatever metrics are used to evaluate them. Since it's impossible to measure everything important in knowledge work-especially with unique efforts under uncertainty-partial measurements inevitably lead to suboptimized behavior. The solution isn't more granular measurement but more aggregated measurement-moving up a level rather than down. Like Nucor measuring group productivity instead of individual performance, or 3M measuring business profitability rather than development costs. The sharp division between firms presents a significant barrier to agile development. Traditional wisdom suggests airtight contracts are the only protection when working across company boundaries, but Toyota pioneered a better approach. By 1998, suppliers rated Toyota as the most trusted automaker in America, scoring twice as high as General Motors. This trust wasn't based on personal relationships but on "fairness, stability, and predictability of Toyota's routines and processes." Toyota recognized that strong supplier networks served its interests better than short-term gains from exploiting suppliers. Four types of contracts work well with agile development: time-and-material contracts with highest priority features first, multistage contracts using master contracts with work orders per iteration, target-cost contracts that give teams freedom to limit scope to meet cost targets, and shared-benefit contracts that allow for mutual adaptation. The common thread is that all avoid fixing scope in detail. This approach challenges conventional wisdom that rigid scope control protects organizations, when in reality it tends to expand scope and increase costs.

『リーンソフトウェア開発と組織改革』をもっと深く楽しむ

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

第9章

Finding Balance: Applying Lean Principles Thoughtfully

Lean principles should be applied with balance rather than absolutism. Eliminating waste doesn't mean eliminating all documentation; amplifying learning isn't constant mind-changing; deciding late isn't procrastination; delivering fast isn't rushing; empowering teams doesn't abandon leadership; building integrity isn't big upfront design; and seeing the whole doesn't ignore details. Practices successful elsewhere shouldn't be blindly adopted-teams must translate lean principles into practices appropriate for their specific environment, considering factors like system criticality, probability of change, and user interface needs. While lean principles work best with senior leadership support, they can be applied at any organizational level. Rather than waiting for top-down implementation, practitioners should "practice the Art of the Possible" by understanding lean thinking, creating coalitions of like-minded colleagues, addressing resistance by uncovering underlying fear and belief systems, accommodating unavoidable bureaucracy with minimal waste, taking initiative when faced with indifference, and acting quickly when given support. For large companies with existing improvement programs like Six Sigma or CMM, leverage rather than fight these initiatives, recognizing they were likely implemented to address past problems and may now be causing overcompensation. For small companies concerned with establishing discipline without overwhelming resources, start with basic professional hygiene (version control, coding standards, build automation, testing), hire skilled people, and maintain focus on doing one thing exceptionally well. When difficulties arise, apply the "see the whole" principle through three high-leverage practices: stopping everything to find and fix root causes when problems appear, identifying and focusing efforts on removing the biggest constraint, and moving focus up one level to optimize the entire system rather than individual components. Lean principles have been proven across many disciplines and will work for software development when properly applied. Proper application means employing all lean principles and using thinking tools to translate them into appropriate agile practices for each environment. The warranty becomes invalid if practices are transferred directly from other disciplines without thoughtful adaptation, or if the principles of empowering teams and building integrity are ignored.

★★★★★

『リーンソフトウェア開発と組織改革』を最後まで読み終えました

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

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

jayallen

『リーンソフトウェア開発と組織改革』の主要テーマ

waste elimination
value stream mapping
knowledge creation
rapid feedback loops
software integrity

『リーンソフトウェア開発と組織改革』の名言

Amplify learning.
Decide as late as possible.
Deliver as fast as possible.
See the whole.
Software development isn't a production process-it's fundamentally about learning.

『リーンソフトウェア開発と組織改革』の登場人物

Mary PoppendieckAuthor and former 3M manufacturing leader
Tom PoppendieckCo-author and husband of Mary Poppendieck
Taiichi OhnoToyota executive who defined the concept of waste
Raymonde GuindonResearcher of programmer problem-solving behavior
Winston RoyceComputer scientist associated with software models

著者について

メアリー・ポッペンディークは、リーン生産方式の原則をソフトウェア工学に適用した先駆的な著作であり、彼女をこの分野の第一人者として確立させた『リーンソフトウェア開発〜アジャイル開発のための標準手法〜』の共著者です。

元プログラマーでありプロジェクトマネージャーでもある彼女のキャリアは、実践的な技術的専門知識と革新的なマネジメント手法を橋渡しするものであり、効率性、無駄の排除、そしてアジャイルなコラボレーションという同書の核となるテーマを反映しています。

トム・ポッペンディークと共に、彼女はこれらの概念を『リーンソフトウェア開発実践ガイド〜「コンセプトからキャッシュまで」を最大限に加速する方法〜』や『リーディング・リーンソフトウェア開発〜「結果」を出すための「プロセス」のつくり方〜』へと発展させ、この分野におけるパイオニアとしての地位を確固たるものにしました。彼らのワークショップや世界各地のアジャイルカンファレンスでの講演は、リーン思考を通じて最適化されたワークフローを提唱し、大手IT企業からスタートアップに至るまで多大な影響を与えてきました。

『リーンソフトウェア開発』は2004年にSoftware Development Productivity Awardを受賞し、現在も現代のアジャイル手法の礎石として、多言語に翻訳され、学術界と産業界の両方で広く引用され続けています。

リーンソフトウェア開発と組織改革の要約をダウンロード

リーンソフトウェア開発と組織改革の要約をPDFまたはEPUBで無料でダウンロード。印刷やオフラインでいつでもお読みいただけます。

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

Lean architecture for agile software development

James O. Coplien & Gertrud Bjørnvig

Lean Impact

Ann Mei Chang

Lean UX

Jeff Gothelf

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren

Learning Agile

Andrew Stellman & Jennifer Greene

Breaking Free From Software Development's Tar Pit の書籍表紙

14 sources

Breaking Free From Software Development's Tar Pit

Lean Six Sigma

Michael L. George

Lean Product Playbook

Dan Olsen

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

学習プラン

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 セクション

学習プラン

Learn software dev

This comprehensive learning path takes you from programming beginner to professional software engineer, covering everything from writing your first line of code to making architectural decisions for large-scale systems. It's ideal for career changers entering tech, self-taught programmers looking to formalize their skills, or junior developers aiming to reach senior-level expertise. The structured progression ensures you build both technical proficiency and the professional mindset needed to succeed in modern software development teams.

4 h 50 m•4 セクション

学習プラン

Master Agile Scrum for Small Business

This plan is essential for small business owners and team leads looking to increase efficiency without the overhead of enterprise-level systems. It provides a roadmap for transitioning from chaotic workflows to structured, high-performing Agile environments.

4 h 4 m•4 セクション

学習プラン

Digital Transformation: Systems Over Software

This plan is essential for leaders and entrepreneurs who feel stuck in reactive cycles and want to build scalable operations. It bridges the gap between simply using digital tools and architecting a business that improves itself through systems thinking.

2 h•4 セクション

学習プラン

Bridge the Business-Tech Gap

In modern software development, technical excellence is only valuable if it drives business success. This plan is designed for engineers and product leaders who want to stop being 'order takers' and start becoming strategic partners by aligning their architecture with organizational goals.

1 h 12 m•3 セクション

学習プラン

Lead 8 Plants: Principles & Management Prep

This learning plan provides a comprehensive roadmap for mastering modern manufacturing leadership and operational efficiency. It is designed for plant managers and industrial leaders seeking to implement world-class lean strategies and drive cultural transformation across complex production environments.

5 h 34 m•4 セクション

学習プラン

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 セクション

学習プラン

design leader mindset

Design leaders today must navigate beyond craft excellence to drive strategic business impact and cultural transformation. This learning plan is essential for experienced designers moving into leadership roles, current design managers seeking to elevate their strategic influence, and organizational leaders who want to build design-led cultures that foster innovation and deliver exceptional user experiences.

3 h 57 m•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がウェブ上でどのように話題になっているかをもっと見る

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

第4章

リーンソフトウェア開発と組織改革

概要『リーンソフトウェア開発と組織改革』の概要

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

The Lean Revolution: How Toyota's Manufacturing Principles Are Transforming Software Development

Eliminate Waste: The Foundation of Lean Thinking

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

Amplify Learning: Software Development as Knowledge Creation

Decide as Late as Possible: Maintaining Options in an Uncertain World

『リーンソフトウェア開発と組織改革』をもっと深く楽しむ

Deliver as Fast as Possible: Speed as Competitive Advantage

Empower the Team: Unleashing Human Potential

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

Build Integrity In: Creating Cohesive Systems That Delight Users

See the Whole: Systems Thinking in Software Development

『リーンソフトウェア開発と組織改革』をもっと深く楽しむ

Finding Balance: Applying Lean Principles Thoughtfully

『リーンソフトウェア開発と組織改革』を最後まで読み終えました

『リーンソフトウェア開発と組織改革』の主要テーマ

『リーンソフトウェア開発と組織改革』の名言

『リーンソフトウェア開発と組織改革』の登場人物

著者について

リーンソフトウェア開発と組織改革の要約をダウンロード

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

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

What is Lean Software Development by Mary Poppendieck about?

Who should read Lean Software Development?

Is Lean Software Development worth reading in 2025?

What are the 7 core principles of Lean Software Development?

もっと見る

1,000,000+ curious minds.

1,000,000+ curious minds.

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

The Lean Revolution: How Toyota's Manufacturing Principles Are Transforming Software Development

Eliminate Waste: The Foundation of Lean Thinking

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

Amplify Learning: Software Development as Knowledge Creation

Decide as Late as Possible: Maintaining Options in an Uncertain World

『リーンソフトウェア開発と組織改革』をもっと深く楽しむ

Deliver as Fast as Possible: Speed as Competitive Advantage

Empower the Team: Unleashing Human Potential

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

Build Integrity In: Creating Cohesive Systems That Delight Users

See the Whole: Systems Thinking in Software Development

『リーンソフトウェア開発と組織改革』をもっと深く楽しむ

Finding Balance: Applying Lean Principles Thoughtfully

『リーンソフトウェア開発と組織改革』を最後まで読み終えました

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

もっと見る

『リーンソフトウェア開発と組織改革』の概要