概要

開発チームの「間違った失敗」を構造・文化・プロセスで「正しい失敗」へ転換する

想定読者

ソフトウェア開発チームのリーダー・マネージャーで、心理的安全性を高めたい、または失敗を学習に結びつけたい立場にある人

こんな人には向いていない

• 技術的なツールやフレームワークの具体的な使い方を求めているエンジニア
• すでに心理的安全性の高いチームを運営しており、組織文化が定着している環境にいるリーダー
• DevOps・アジャイルの概念を初めて学ぶ段階にある人(本書はそれらを前提としている)

読了後にできるようになること

• 「間違った失敗」と「正しい失敗」の構造的な違いを分類・定義できる
• 隠蔽される失敗が生まれるチームの関係性の恐怖メカニズムを説明できる
• DevOps・アジャイルが「失敗を許容するテクノロジー」として機能する仕組みを理解できる
• 構造面での改善アプローチ(チームの意思決定フロー・情報共有の設計)を実践できる
• 文化醸成とプロセス整備それぞれの具体的な打ち手を区別して選択できる
• 繰り返される失敗を「学べる失敗」へ昇格させるための観察・振り返り技法を活用できる

本書のキー概念(章解説)

• 序章:「間違った失敗」が起こる構造 — 本書全体の問題設定。チームで繰り返される失敗パターンを類型化する導入
• 第 1 章 第1章:「間違った批判」から生まれる「間違った失敗」 — 批判文化とブレームカルチャーがどう失敗の隠蔽を生むかを解説
• 第 2 章 第2章:「間違った失敗」から「正しい失敗」へ — 失敗の質を変えるための概念的フレームワーク。本書の核心
• 第 3 章 第3章:「正しい失敗」は技術革新によって作り出された — CI/CD・カオスエンジニアリング等の技術的背景と「正しい失敗」の関係を整理
• 第 4 章 第4章:「間違った失敗」の背景にある「関係性の恐怖」 — 心理的安全性の観点から失敗隠蔽の根因を掘り下げる
• 第 5 章 第5章:構造を動かす──「恐怖」と向き合う技術❶ — 意思決定フローや情報共有の設計など、構造的な打ち手の具体例
• 第 6 章 第6章:文化を醸成する──「恐怖」と向き合う技術❷ — 心理的安全性を日常業務に根付かせるための文化づくりのアプローチ
• 第 7 章 第7章:プロセスを作る──「恐怖」と向き合う技術❸ — 振り返り・インシデント対応・学習ループをプロセスとして定着させる方法
• 第 8 章 付録:ソフトウェア開発の失敗「20」の法則 — 現場でよく見られる失敗パターンの網羅的リファレンス。日常のレトロスペクティブで参照しやすい

ハイライト

• DevOpsやアジャイルといった武器とともに、「正しく」失敗し、トライ&エラーを繰り返すことが必要です。開発チームは、あえて失敗を作り出し、積極的に失敗を共有し、メンバーの失敗を心から許容することが必要です。(本書の中心テーゼが最も端的に表れている箇所。「失敗を作り出す」という能動的な姿勢が独自性を示している)
• 「隠された失敗」から「透明性のある失敗」へ。「繰り返される失敗」から「学べる失敗」へ。「低リスクなムダな失敗」から「リスクをとった学べる失敗」へ。(失敗の3類型変換を簡潔に提示しており、本書の問題意識の輪郭を30秒で把握できる)

編集メモ

Qiita 言及0件 / 楽天ランキング履歴なし。2025年2月刊行の新刊であり外部シグナルの蓄積がまだ少ない段階のため supplementary と判定

読む前に押さえておきたいこと

• アジャイル開発またはDevOpsの現場経験(概念だけでなく実際にチームで運用した経験があること)
• スクラムのスプリントレトロスペクティブや振り返りの場をリードした経験
• 心理的安全性(Amy Edmondson の概念)の基本的な理解

学習のコツ

• 序章と第2章を先に読むと「間違った失敗 vs 正しい失敗」の分類軸が定まり、第5〜7章の打ち手の選択理由が理解しやすくなる
• 第3章はDevOps・CI/CD経験者なら既知の内容が多いため、流し読みして第4章の心理面の分析に時間を割くと効率が良い
• 付録の「失敗20の法則」は通読後にチームのレトロスペクティブのチェックリストとして再利用できる
• 第5・6・7章は「構造→文化→プロセス」の順に独立して参照できるため、チームの課題感から逆引きして読む使い方も有効