What is *The Phoenix Project* by Gene Kim about?

*The Phoenix Project* is a business novel that follows IT manager Bill Palmer as he rescues Parts Unlimited from collapse by overhauling chaotic IT operations. Through DevOps principles like automation, collaboration, and workflow optimization, Bill transforms unplanned work, bottlenecks, and siloed teams into a streamlined system. The book uses a fictional narrative to teach real-world strategies for aligning IT with business goals.

Who should read *The Phoenix Project*?

This book is ideal for IT professionals, DevOps engineers, and managers seeking to improve organizational efficiency. It’s also valuable for executives navigating digital transformation, as it illustrates how broken processes hinder innovation. Gene Kim’s storytelling makes complex concepts like continuous delivery and systems thinking accessible to non-technical readers.

Is *The Phoenix Project* worth reading?

Yes—it’s a foundational DevOps text with over 1 million copies sold. The novel format simplifies technical ideas like the Three Ways of DevOps and the Theory of Constraints, offering actionable insights for reducing IT bottlenecks. Its Shingo Publication Award and enduring relevance in tech education underscore its impact.

What are the key concepts in *The Phoenix Project*?

- **The Three Ways**: Flow (optimizing workflows), Feedback (rapid issue resolution), and Continual Learning (experimentation). - **Theory of Constraints**: Identifying bottlenecks like Brent, the overburdened engineer. - **Unplanned work**: How reactive firefighting derails strategic projects.

How does *The Phoenix Project* use the Theory of Constraints?

The book applies Eli Goldratt’s theory by depicting Brent as a bottleneck—his unique skills cause delays when overloaded. By redistributing Brent’s responsibilities and documenting solutions, the team increases throughput. This mirrors Goldratt’s focus on aligning resources with systemic goals.

What is the significance of Brent’s role in the story?

Brent symbolizes single points of failure in IT systems. His constant firefighting highlights the risks of tribal knowledge and poor documentation. Resolving his overload through cross-training and escalation protocols becomes pivotal to Parts Unlimited’s turnaround.

How does *The Phoenix Project* address unplanned work?

Unplanned work—like constant server outages—consumes 90% of IT’s capacity, stifling innovation. The solution involves prioritizing planned work, creating escalation policies, and using Kanban boards to visualize workflows. This shift enables the team to focus on strategic initiatives like the Phoenix rollout.

What are the Three Ways of DevOps in *The Phoenix Project*?

1. **Flow**: Streamlining deployments to accelerate value delivery. 2. **Feedback**: Implementing monitoring to quickly detect issues. 3. **Continual Learning**: Cultivating a culture of experimentation and blameless post-mortems.

フェニックスプロジェクト

IT、DevOps、そしてビジネスを勝利に導くための物語

ジーン・キム、ケビン・贝尔、ジョージ・スパッフォード

3.38(8 Reviews)

『フェニックスプロジェクト』の概要

ITにとっての最悪の悪夢が、DevOps文化に革命をもたらした魅力的なビジネス小説となりました。50万部以上を売り上げた『The Phoenix Project（邦題：フェニックスプロジェクト）』は、世界中のテックチームの運営方法を変革しました。ティム・オライリーは、本作を「失敗したすべてのITプロジェクトにとっての必読書」と呼んでいます。

語り方を選ぶ

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

フェニックスプロジェクトの同じアイデアを、あなたに合う声・深さ・ペースで学べます。いつでも切り替えられます。

第1章

When IT Becomes a Battleground: The Phoenix Project's Wake-Up Call

In a world where technology drives business success, The Phoenix Project stands as a landmark novel that transformed how organizations think about IT operations. Published in 2013 by Gene Kim, Kevin Behr, and George Spafford, this business novel has sold over 400,000 copies and become required reading in MBA programs, computer science departments, and corporate boardrooms worldwide. Its influence extends beyond IT departments-even Wall Street Journal has recognized its impact on modern business practices. The book follows Bill Palmer, an IT operations manager suddenly promoted to VP, as he navigates a perfect storm of technical disasters that threaten to sink his company. Through his journey, readers discover powerful principles that bridge the gap between IT operations and business value-principles that have since sparked the global DevOps movement transforming how companies deliver technology.

第2章

The Perfect Storm: When Everything Falls Apart

Bill Palmer is having the worst day of his professional life. Reluctantly promoted to VP of IT Operations at Parts Unlimited, an automotive parts manufacturer and retailer, he's immediately thrust into crisis mode. The company's critical Phoenix Project-an e-commerce initiative meant to restore profitability-is years behind schedule and millions over budget. The payroll system has mysteriously crashed, threatening to leave thousands of employees unpaid, with the finance department already fielding panicked calls from workers living paycheck to paycheck. And the CEO, Steve Masters, has just informed him that if they don't turn things around in 90 days, the board might outsource the entire IT department to an offshore provider, potentially affecting hundreds of jobs. As Bill races to understand the payroll failure, he discovers a chaotic IT environment where changes happen without proper controls or documentation. A security-related "tokenization" application was rushed into production without adequate testing, corrupting employee data across multiple systems and creating inconsistencies between HR and payroll databases. The storage area network (SAN) is displaying cryptic error messages in Japanese characters after a failed firmware upgrade, which was attempted during peak business hours without proper backup procedures in place. The company's most knowledgeable engineer, Brent, is constantly pulled in different directions by competing priorities from various departments, creating a critical bottleneck that affects every project and system maintenance task. The situation deteriorates further when Bill learns the company faces 952 IT general control deficiencies in their SOX-404 audit, including two potential material weaknesses that could trigger SEC reporting issues and impact investor confidence. The audit findings reveal missing change management procedures, inadequate access controls, and insufficient disaster recovery planning. With Phoenix deployments causing repeated store system outages affecting retail operations across multiple time zones, customer credit card data being leaked through unsecured development environments, and the board considering splitting up the company to salvage shareholder value, Bill finds himself in an impossible position-trying to keep critical systems running while simultaneously transforming how IT operates. What makes The Phoenix Project so compelling is how accurately it portrays the dysfunctional relationship between IT and business that exists in countless organizations. The firefighting mentality that prioritizes quick fixes over sustainable solutions, the blame game between development and operations teams, the impossible demands from business units who don't understand technical constraints, and the mounting technical debt from years of shortcuts-these aren't fictional problems but daily realities for IT professionals worldwide. The book resonates deeply with its readers because it reflects common experiences: the late-night emergency calls, the stressed-out teams, the technical decisions made under pressure, and the constant struggle to balance innovation with stability. As one reader commented after finishing the book, "It's like they've been hiding in our building, documenting our daily struggles."

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

『フェニックスプロジェクト』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第3章

The Four Types of Work: Revealing the Hidden Factory

During a pivotal chance meeting with Erik Reid, a seasoned manufacturing expert and potential board member, Bill receives his first fundamental lesson in understanding IT operations. Erik takes Bill on an enlightening visit to the company's manufacturing plant, using this tangible environment to demonstrate why IT is failing - it doesn't recognize or properly manage the four distinct types of work flowing through its "factory." This manufacturing analogy becomes the cornerstone for understanding IT operations in a new light. Standing on a catwalk overlooking the bustling factory floor, Erik delivers a masterclass in how manufacturing was revolutionized by controlling work-in-process inventory through three key principles: Theory of Constraints (focusing on identifying and addressing bottlenecks), Lean production (eliminating waste and improving flow), and Total Quality Management (ensuring quality at every step). He introduces his transformative "Three Ways" philosophy: first, creating fast flow from Development to Operations to deliver value quickly; second, shortening and amplifying feedback loops to identify and fix quality issues early; and third, fostering a culture of continuous experimentation and learning to improve processes systematically. As Bill implements a new change management process using a visual system of index cards on a board - a simple but effective Kanban-style approach - he experiences a crucial epiphany. The first three types of work emerge clearly: business projects (strategic initiatives like Phoenix), internal IT projects (infrastructure improvements and technical debt reduction), and changes to existing systems (updates, patches, and modifications). However, it takes a severe crisis - a major credit card processing outage - for Bill to fully grasp the fourth and most insidious type: unplanned work, the firefighting that consumes resources and derails planned activities. This unplanned work, as Erik later emphasizes, is "the most destructive type of work" in any IT organization. Like matter meeting antimatter, it completely obliterates planned work with devastating efficiency. Each emergency pulls key resources like Brent, the indispensable engineer, away from critical projects, creating a vicious cycle where important strategic work never reaches completion. The constant interruptions not only delay projects but also create additional technical debt that generates more unplanned work in the future. The novel masterfully illustrates how unplanned work isn't merely an inconvenience - it's a glaring symptom of deeper systemic problems in the IT value stream. When Bill implements a "Brent protection plan" to shield his key engineer from interruptions and keep him focused on Phoenix, the change management board reveals another disturbing reality: sixty percent of scheduled changes aren't completing successfully, creating a growing backlog of work-in-process (WIP). Erik describes this accumulation as "the silent killer" - a mounting technical debt that threatens to overwhelm the entire system. Through these experiences and challenges, Bill learns that effectively managing IT requires understanding and controlling these four work types, just as manufacturing plants must meticulously control their inventory and production flow. This framework provides readers with a powerful analytical tool to examine their own IT operations and identify where constraints are creating bottlenecks that impede progress and efficiency. The parallel between manufacturing and IT operations becomes increasingly clear: without proper work management, both systems will inevitably face declining productivity and mounting chaos.

第4章

The Phoenix Disaster: When Deployment Becomes a Death March

The Phoenix deployment scenes provide some of the book's most visceral moments, capturing the anxiety and chaos familiar to anyone who's participated in a high-stakes software release. Despite Bill's improvements to change management processes, the Phoenix deployment becomes a nightmare that keeps the team working through the night, highlighting how even well-intentioned processes can fail catastrophically under pressure. What begins as a scheduled four-hour deployment stretches into a crisis when the database migration fails after completing only thirty percent of the required steps. The team discovers that Brent had made an undocumented production database change weeks earlier for one of Sarah's business intelligence modules, creating a conflict with Phoenix's changes. This seemingly minor oversight cascades into a major crisis, requiring the team to manually rename database columns affecting hundreds of files and support scripts. The situation is further complicated by the tight timeline, with stores opening in mere hours and millions in potential revenue at stake. The scene perfectly captures the tension between Development and Operations that plagues many organizations. Chris's development team creates code without understanding operational realities, while Operations lacks visibility into what's changing until it's too late. This disconnect manifests in multiple ways: developers testing in environments that don't match production, changes being made without proper documentation, and a lack of automated testing to catch conflicts early. The result is a system so fragile that each deployment becomes a high-risk event requiring heroics to succeed. The human cost of this dysfunction becomes evident as the team struggles through the night. Brent's undocumented changes, though well-intentioned, reveal the dangers of tribal knowledge and the absence of proper change management protocols. The development team's frustration with operations' "bureaucracy" and operations' distrust of development's "reckless" changes exemplify the cultural divide that exists in many IT organizations. What makes this scenario so compelling is how it demonstrates the consequences of poor flow in the IT value stream. Without proper environment parity between development, testing, and production, without automated testing, and without small, frequent deployments, each release becomes increasingly dangerous. The Phoenix deployment illustrates how large, infrequent releases amplify risk exponentially. As Erik later explains, large batch sizes create high variability that cascades through systems, resulting in long lead times and poor quality. The team's reliance on manual processes and heroic efforts becomes a self-perpetuating cycle, making each subsequent deployment more risky. The Phoenix disaster serves as a turning point in the narrative, forcing the organization to confront fundamental questions about how they deliver technology. It illustrates that deployment problems aren't just technical issues but symptoms of organizational dysfunction that requires rethinking the entire development and operations relationship. This crisis becomes the catalyst for implementing DevOps practices, including automated testing, continuous integration, and improved communication channels between teams.

『フェニックスプロジェクト』をもっと深く楽しむ

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

第5章

The Three Ways: A New Philosophy for IT

At the heart of The Phoenix Project is Erik Reid's "Three Ways" philosophy-principles that provide a framework for understanding how to improve IT performance. These principles, drawn from Lean manufacturing, become Bill's guide for transforming Parts Unlimited's dysfunctional IT department. The First Way focuses on optimizing flow from left to right-from Development to Operations to customers. Bill implements this by making work visible through kanban boards, limiting work-in-process, reducing batch sizes, and identifying constraints like Brent. When Patty creates a service request board with columns for "Ready," "Doing," and "Done," she transforms laptop replacements from an unpredictable process to one with consistent, reliable delivery times. The Second Way emphasizes creating fast feedback loops from right to left. Bill implements this by improving incident response procedures, conducting blameless postmortems, and implementing monitoring systems that detect problems before customers notice. When John suggests integrating security teams with development rather than inspecting security after deployment, he's applying Second Way principles to shift quality earlier in the process. The Third Way focuses on creating a culture of continual learning and experimentation. This manifests when the team implements "Chaos Monkey" exercises that randomly kill processes to ensure system resilience, and when they adopt a scientific approach to improvement with explicit hypotheses and experiments. Erik's insistence that "practice creates habits that lead to mastery" reflects this principle. What makes the Three Ways powerful is how they provide a coherent philosophy that addresses both technical and cultural aspects of IT transformation. They're not just abstract concepts but practical guides for action that Bill applies throughout his journey. When he protects time for infrastructure improvements, he's applying the Third Way. When he implements change management processes, he's applying the First Way. When he improves monitoring to detect problems earlier, he's applying the Second Way. The Three Ways have since become foundational concepts in the DevOps movement, providing organizations with a framework for understanding how to improve their technology value streams. They've proven applicable across industries and technology stacks, from startups to enterprises, from web applications to mainframes.

第6章

Breaking Down Silos: The Birth of DevOps at Parts Unlimited

One of the book's most powerful themes is the transformation of adversarial relationships between Development and Operations into collaborative partnerships. This journey begins with a painful recognition of the "core, chronic conflict" between these groups: Development is incentivized to deliver changes quickly, while Operations is rewarded for stability and uptime. This fundamental tension manifests in numerous ways, from blame-shifting during outages to resistance against new deployments, creating a toxic environment that ultimately harms the business. The breakthrough comes when Bill, Chris, Wes, and Patty form the "Unicorn" SWAT team to deliver critical revenue-generating features faster than the main Phoenix project allows. By bringing together developers, operations staff, QA, and security from the beginning, they create what Erik later describes as a "super-tribe" that transcends traditional silos. This cross-functional team structure proves revolutionary, allowing them to address problems holistically rather than throwing issues "over the wall" between departments. The novel brilliantly illustrates how this collaboration transforms their work. When the team maps out their deployment process, they discover over a hundred steps spanning Development and Operations, with most having problems in previous launches. The mapping exercise reveals shocking inefficiencies: manual handoffs, inconsistent environments, and redundant approval processes that added weeks to delivery times. Together, they identify environment availability and deployment packaging as key constraints and develop solutions that benefit both groups, including automated environment creation and standardized deployment procedures. The results are dramatic: the Unicorn team progresses "remarkably well" with a clean code base decoupled from Phoenix. Brent and William create build procedures that simultaneously generate identical development, QA, and production environments-something unprecedented that allows developers to be productive immediately. These standardized environments eliminate the common "it works on my machine" problem and reduce deployment failures by 60%. Sprint intervals shrink to two weeks, allowing faster planning and execution, while deployment times decrease from days to hours. What makes this transformation believable is that it doesn't happen overnight or without resistance. Wes initially resists security's involvement, viewing it as another bureaucratic hurdle. Developers are skeptical about operations' concerns, dismissing them as overly cautious, while operations sees developers as reckless. The cultural differences between groups (Bill describes developers as "indie musicians" compared to operations' disciplined approach) create tension and miscommunication. However, through shared goals, joint problem-solving sessions, and accumulated successful deployments, these groups gradually learn to work together effectively. This journey from silos to collaboration mirrors the real-world emergence of DevOps as a movement that bridges traditional IT divides. The novel shows that DevOps isn't just about tools or processes but about creating a shared understanding and responsibility for delivering technology that serves business needs. The transformation at Parts Unlimited demonstrates how breaking down organizational barriers, aligning incentives, and fostering a culture of collaboration can lead to dramatic improvements in both speed and reliability of software delivery.

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

『フェニックスプロジェクト』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

第7章

From Months to Minutes: The Deployment Revolution

Perhaps the most radical concept Erik introduces is the idea of performing ten deployments per day-a goal that initially seems impossible to Bill. When Erik reveals that companies like Flickr were achieving this back in 2009, deploying at rates a thousand times faster than industry standards, it challenges fundamental assumptions about how software should be delivered. Other tech giants like Amazon and Google were also pushing thousands of changes into production daily, demonstrating that rapid deployment wasn't just theoretical but achievable at scale. The novel traces Bill's journey from skepticism to understanding as he learns how to create a "deployment pipeline" where everything-not just code but everything needed to build environments-goes into version control. This includes database schemas, configuration files, environment variables, and even documentation. The entire environment creation process must be automated to reduce setup times and eliminate errors. This approach, known as "Infrastructure as Code," ensures that environments can be recreated consistently and reliably, eliminating the "works on my machine" syndrome that plagues many development teams. This transformation becomes real when the Unicorn team adopts these practices. They start with weekly deployments and progress toward daily releases, with smaller batch sizes enabling quick changes and A/B testing. By breaking down large releases into smaller, more manageable chunks, they reduce risk and complexity. This dramatically improves their market responsiveness, allowing them to experiment with customer promotions and quickly adapt based on results. The team implements feature flags to control feature rollouts and dark launches to test new functionality with minimal risk. The Thanksgiving promotion demonstrates both the power and challenges of this approach. The unprecedented response crashes their e-commerce systems, but their improved processes allow them to quickly implement solutions: adding servers, optimizing database queries, and moving large graphics to a content distribution network. The team's ability to make rapid, controlled changes enables them to respond to the crisis in real-time. By Monday, they've not only resolved the crisis but helped create the company's first profitable quarter in over a year, proving the business value of their new deployment capabilities. What makes this storyline compelling is how it connects technical practices like continuous integration, automated testing, and infrastructure as code to business outcomes like faster time to market and increased revenue. The novel shows how automated testing at all levels - unit, integration, and performance - creates a safety net that enables rapid change. It demonstrates that deployment frequency isn't just a technical metric but a competitive advantage that allows organizations to respond more quickly to market changes and customer needs. The ability to deploy quickly becomes a key differentiator in the market, enabling companies to outmaneuver competitors and better serve customers. This message has resonated deeply with organizations struggling with slow, painful deployment processes. The novel's vision of rapid, reliable deployments has inspired countless IT transformations, with companies across industries working to reduce their deployment lead times from months to minutes. Success stories from diverse sectors - from financial services to retail - show how these principles can be applied beyond just software companies, creating a new standard for operational excellence in the digital age.

第8章

Beyond Technology: The Human Side of Transformation

While The Phoenix Project contains plenty of technical detail, its most powerful insights concern the human aspects of IT transformation. The novel explores how trust, leadership, and organizational culture determine whether technology initiatives succeed or fail. This theme emerges powerfully during an off-site meeting where Steve asks everyone to share personal histories to build trust. Chris reveals his struggle with infertility and premature twins. Wes shares his failed relationships and weight issues. Patty discloses her background as a touring musician with an arrest record. Bill reluctantly discusses his alcoholic father and his determination to be a better parent. These vulnerable exchanges transform the team's dynamics, creating psychological safety that enables honest communication about work challenges. This high-trust environment becomes essential when they later need to make difficult decisions about project priorities and resource allocation. The novel also explores different leadership styles through characters like Steve (the demanding but ultimately supportive CEO), Sarah (the politically savvy but self-interested SVP), and Bill himself, who evolves from a reluctant leader to someone capable of challenging executives when necessary. When Bill stands up to Steve during the invoicing crisis, declaring "I can't be held responsible for this FUBAR situation," it represents a crucial moment in his leadership development-one where he establishes boundaries around what his team can reasonably accomplish. Perhaps most importantly, the book examines how organizational culture shapes technology outcomes. Erik introduces Bill to Dr. Ron Westrum's three organizational culture types: pathological (fear-based), bureaucratic (rule-based), and generative (mission-focused). The novel shows Parts Unlimited's journey from a pathological culture where problems are hidden and blame is assigned, toward a generative culture where information flows freely and failures become learning opportunities. This transformation is evident in how the team handles incidents. Early in the book, outages trigger finger-pointing and defensiveness. By the end, they've implemented blameless postmortems and rehearsed procedures that allow them to respond calmly and effectively to problems. When John evolves from a security obstructionist to a collaborative partner who integrates security into daily work, it represents a cultural shift that improves both security outcomes and development speed.

『フェニックスプロジェクト』をもっと深く楽しむ

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

第9章

The Phoenix Rises: Transformation and Triumph

The novel's final chapters show how Parts Unlimited's IT transformation drives broader business success. The Unicorn project's promotions break sales records, leading to the company's first profitable quarter in over a year. The board withdraws its proposal to split the company, and analyst firms raise the stock price targets. What makes this conclusion satisfying is that it doesn't present a perfect ending-challenges remain, and new problems emerge. When their largest competitor starts offering custom build-to-order kits, the team must confront another constraint: their outsourced mainframe manufacturing resource planning system. Rather than accepting this limitation, they propose breaking the outsourcing contract early to bring the application back in-house-an audacious but necessary step to maintain competitive advantage. The novel ends with Steve offering Bill an unexpected opportunity: a two-year fast track with rotations through various business functions, potentially leading to the COO position. Steve's reasoning captures the book's central insight: "In ten years, every COO will come from IT backgrounds because they truly understand how the company works." This prediction-that technology leadership is becoming business leadership-has proven increasingly accurate in the years since the book's publication. Erik's final appearance brings the story full circle. The mysterious mentor reveals he plans to become a major investor in Parts Unlimited, believing their IT transformation predicts business success. His request that Bill write "The DevOps Handbook" to help improve the lives of IT workers everywhere breaks the fourth wall in a meta-reference to the actual companion book that Gene Kim later published. The Phoenix Project's enduring appeal lies in how it transforms abstract technical concepts into a human story of struggle and redemption. Through Bill Palmer's journey, readers see not just how to implement DevOps practices but why they matter-how they can reduce the stress, overtime, and frustration that plague IT departments while simultaneously improving business outcomes. As the novel concludes with Bill facing a new situation with "newfound calm and inner peace," it offers a hopeful vision: that by applying the right principles, organizations can transform IT from a source of frustration and constraint into an engine of innovation and competitive advantage. This message continues to resonate with readers worldwide, making The Phoenix Project not just a novel about IT transformation but a roadmap for business success in the digital age.

★★★★★

『フェニックスプロジェクト』を最後まで読み終えました

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

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

jayallen

『フェニックスプロジェクト』の主要テーマ

devops movement
theory of constraints
it operations management
lean manufacturing principles
technical debt reduction

『フェニックスプロジェクト』の名言

Unplanned work is 'the most destructive type of work' in any IT organization.
It's like they've been hiding in our building, documenting our daily struggles.

『フェニックスプロジェクト』の登場人物

Bill PalmerIT operations manager promoted to VP
Steve MastersCEO of Parts Unlimited
BrentBrilliant engineer and critical bottleneck
Erik ReidBoard member candidate and manufacturing expert

著者について

ジーン・キム、ケビン・ベア、ジョージ・スパッフォードは、ITおよびDevOps分野における画期的な著作である『The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win』（邦題：『フェニックス・プロジェクト：IT、DevOps、そしてビジネスを成功させるための物語』）の共著者です。

ベストセラー作家でありDevOpsの思想的リーダーであるジーン・キムは、ITのベストプラクティスを推進する中心的な組織であるTripwire社とIT Revolution社を設立しました。ビジネスフィクションと技術的洞察を融合させたこの小説は、IT変革、継続的改善、そしてテクノロジーと組織目標の整合といったテーマを掘り下げており、これらはキムによるハイパフォーマンスなテックチームに関する20年間の研究に基づいたコンセプトです。

キムの専門知識は、『The DevOps Handbook』（邦題：『DevOpsハンドブック』）や『Accelerate: The Science of Lean Software and DevOps』（邦題：『LeanとDevOpsの科学』）でもさらに発揮されており、これらは『フェニックス・プロジェクト』で導入された原則をさらに発展させたものです。DevOps Enterprise Summitなどのイベントで頻繁に基調講演を行っており、彼の活動は『ウォール・ストリート・ジャーナル』や『フォーブス』誌でも取り上げられています。

パデュー大学の学者であるスパッフォードは、キムの長年の協力者として学術的な厳密さをもたらしています。本書は100万部以上を売り上げ、10以上の言語に翻訳され、技術教育やビジネス教育の現場で広く活用されています。

フェニックスプロジェクトの要約をダウンロード

フェニックスプロジェクトの要約をPDFまたはEPUBで無料でダウンロード。印刷やオフラインでいつでもお読みいただけます。

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

The Unicorn Project

Gene Kim

The Devops Handbook

Gene Kim & Jez Humble & Patrick Debois & John Willis & Nicole Forsgren

Wiring the Winning Organization

Gene Kim & Steven J. Spear

Phoenix King

Aparna Verma

Empowered

Marty Cagan & Chris Jones

Making Things Happen

Scott Berkun

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren

Program

Eric Kapitulik & Jake MacDonald

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

学習プラン

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 セクション

学習プラン

Build a High-Performing Project Team

In today's fast-paced environment, the ability to rapidly align a group and lead them through conflict is a critical leadership skill. This plan is ideal for project managers and emerging leaders who need to transform individual contributors into a cohesive, high-impact unit from kickoff to completion.

1 h•3 セクション

学習プラン

The High-Growth Leadership Playbook

In fast-scaling environments, traditional management often leads to burnout and missed deadlines. This playbook is designed for high-growth leaders who need to shift from tactical oversight to strategic empowerment to sustain team performance. It provides the psychological and behavioral tools necessary to build a self-sustaining, high-energy culture.

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 セクション

学習プラン

Strategic PMO Leadership for Startups

In today's rapidly changing business landscape, PMOs leading innovative projects face unique challenges that traditional project management approaches often fail to address. This learning plan equips project managers with the startup mindset, risk management strategies, and communication skills needed to successfully navigate uncertainty while demonstrating business acumen to senior stakeholders.

3 h 24 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 セクション

学習プラン

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 Rocket Scientist's Reading Workflow

In an era of information overload, the ability to rapidly digest and apply complex technical knowledge is a competitive superpower. This plan is designed for high-performers and lifelong learners who need to master new domains quickly using engineering-grade mental models.

1 h 30 m•3 セクション

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

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

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

第3章

フェニックスプロジェクト

概要『フェニックスプロジェクト』の概要

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

When IT Becomes a Battleground: The Phoenix Project's Wake-Up Call

The Perfect Storm: When Everything Falls Apart

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

The Four Types of Work: Revealing the Hidden Factory

The Phoenix Disaster: When Deployment Becomes a Death March

『フェニックスプロジェクト』をもっと深く楽しむ

The Three Ways: A New Philosophy for IT

Breaking Down Silos: The Birth of DevOps at Parts Unlimited

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

From Months to Minutes: The Deployment Revolution

Beyond Technology: The Human Side of Transformation

『フェニックスプロジェクト』をもっと深く楽しむ

The Phoenix Rises: Transformation and Triumph

『フェニックスプロジェクト』を最後まで読み終えました

『フェニックスプロジェクト』の主要テーマ

『フェニックスプロジェクト』の名言

『フェニックスプロジェクト』の登場人物

著者について

フェニックスプロジェクトの要約をダウンロード

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

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

What is The Phoenix Project by Gene Kim about?

Who should read The Phoenix Project?

Is The Phoenix Project worth reading?

What are the key concepts in The Phoenix Project?

もっと見る

1,000,000+ curious minds.

1,000,000+ curious minds.

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

When IT Becomes a Battleground: The Phoenix Project's Wake-Up Call

The Perfect Storm: When Everything Falls Apart

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

The Four Types of Work: Revealing the Hidden Factory

The Phoenix Disaster: When Deployment Becomes a Death March

『フェニックスプロジェクト』をもっと深く楽しむ

The Three Ways: A New Philosophy for IT

Breaking Down Silos: The Birth of DevOps at Parts Unlimited

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

From Months to Minutes: The Deployment Revolution

Beyond Technology: The Human Side of Transformation

『フェニックスプロジェクト』をもっと深く楽しむ

The Phoenix Rises: Transformation and Triumph

『フェニックスプロジェクト』を最後まで読み終えました

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

もっと見る

『フェニックスプロジェクト』の概要