• はじめに

序章　「間違った失敗」が起こる構造

• 0.1　失敗には，「間違った失敗」と「正しい失敗」がある
• 0.2　「間違った失敗」が生まれる構造
  • 「間違った失敗」は3つに区分される
  • 「間違った失敗」から「正しい失敗」へ
• 0.3　「間違った失敗」の原因は「摩擦」である

第1章　「間違った批判」から生まれる「間違った失敗」

• 1.1　「ゼロリスク」が優先度判断を狂わせ，間違った失敗へ導く
  • システム障害を起因とした内部品質の軽視による間違った失敗
  • 見積りの不確実性への誤認識による間違った失敗
  • 「不安の定量化」によって，エンジニアの開発時間をなくしてしまう失敗
• 1.2　人を増やせば早くなるという認識が招く予算投入の失敗
  • 作れば作るほど，人員投入による効果は薄くなる
  • 採用の質と育成のバランス
• 1.3　仮説検証にならない実験を繰り返して疲弊する失敗
  • モチベーションや愛着が低下する
  • 「捨てられない」失敗

第2章　「間違った失敗」から「正しい失敗」へ

• 2.1　「正しい失敗」はなぜ必要か
  • 失敗とリカバリーのエンジニアリング
  • 正しい失敗を受け入れる文化の構築
• 2.2　「隠された失敗」から「透明性のある失敗」へ
  • 課題は時間が経過すればするほど複雑化し膨張していく
  • 透明性の確保がもたらす効用
  • 隠された失敗は超大作な失敗を作る
  • 成功ではなく失敗したことを報告して透明性を上げる
  • エンジニアは，説明責任を果たすことで透明性を作っていく
  • 説明責任❶──見積り予測のズレをリカバリーするのは難しいので，早期に報告する
  • 説明責任❷──コミットメント（約束）と予測を分ける
  • 説明責任❸──見積り（予測）は4つの価値を理解する
  • 説明責任❹──隠された失敗をしないために，開発優先度を理解してもらう
  • 説明責任❺──障害対応時は，チーム外へ連絡・報告・相談を行う役割を作る
• 2.3　「繰り返される失敗」から「学べる失敗」へ
  • 仮説は検証して初めて学びになる
  • 仮説検証ループの導入
  • ループは逆回転で思考する──計画ループと実行ループ
  • 障害の再発防止策から逃げない──ポストモーテムから失敗を学ぶ
• 2.4　「低リスクなムダな失敗」から「リスクを取った学べる失敗」へ
  • 小さく作ればよいというものじゃない
  • 工数や実装難易度でMVPをスライスしない
• 2.5　正しく失敗できれば，失敗をコントロールできる
  • 「隠された失敗」→「透明性のある失敗」──課題解決にかかる時間をコントロールできる
  • 「繰り返される失敗」→「学べる失敗」──再利用できないムダな時間をなくすことができる
  • 「低リスクなムダな失敗」→「リスクを取った学べる失敗」──ムダな学習時間を短縮できる

第3章　「正しい失敗」は技術革新によって作り出された

• 3.1　チームサイズの変化
• 3.2　チームサイズのスパン・オブ・コントロール
• 3.3　クラウドとコンテナ技術の発展
• 3.4　セクショナリズムとDevOps
• 3.5　マイクロサービスとコンウェイの法則が，スモールチームとシステムのあり方を定義した
• 3.6　フルサイクルでのエンジニアリングが可能に

第4章　「間違った失敗」の背景にある「関係性の恐怖」

• 4.1　エンジニアの「できない」という言葉の意味
  • ❶ほかのタスクをしているので「できない」
  • ❷今の機能では「できない」
  • ❸何かしらの制約で「できない」
  • ❹時間がかかるので「できない」
  • ❺今のチームスキルだと「できない」
  • ❻やるべきではないと思っているから「できない」
  • 「できない」を「できる」に置き換える
  • 改善を提案する人を冷めさせない
  • 否定から入るのをやめる
• 4.2　アイコンと音声で関係性を作る時代
  • リモート環境下でのマネジメントの難しさは情報量の違い
  • 「つながっているが孤独な関係性」に陥らないようにする
• 4.3　議論で黙って静かにしていることは合意ではない
• 4.4　「他責思考」による傍観者効果が失敗を作る
  • 多元的無知と傍観者効果の関連性。そして他責思考なチームへ
  • 圧倒的当事者意識で他責思考から抜け出す
• 4.5　逆に「自責思考」も失敗を作る
  • 「任せられない」という呪縛──新卒3年目でリーダーになったとき
  • 自責には，自己叱責と自己責任がある
• 4.6　間違った目標設定と評価制度が失敗を作る

第5章　構造を動かす──「恐怖」と向き合う技術❶

• 5.1　「構造」「文化」「プロセス」で「失敗を生む恐怖」に立ち向かう
  • 構造を動かす
  • 文化を醸成する
  • プロセスを作る
  • 模範解答の再現ではなく，失敗からアップデートしていく
• 5.2　構造を変えてフォース（流れ・力学）を作る
  • コンウェイの法則の功罪
• 5.3　Dynamic Reteamingパターンで構造変化をとらえる
  • 貧困の罠（Poverty Trap）と硬直の罠（Rigidity）
• 5.4　5つのパターンで変化をつける
  • ❶One-by-Oneパターン（一人ずつ）
  • ❷Grow-and-Splitパターン（成長と分割）
  • ❸Isolationパターン（隔離）
  • ❹Mergingパターン（マージ）
  • ❺Switchingパターン（切り替え）
  • リチーミングのアンチパターン
  • メンバーの納得度と自由度のバランス
• 5.5　構造に人をアサインできるか
  • 枠に耐え得る人材がいるか
  • 兼務祭りにならないか
  • 採用はできるのか
• 5.6　裁量と権限を作り，レポートラインをつなぐ
• 5.7　構造による力学＝リズムが生まれる

第6章　文化を醸成する──「恐怖」と向き合う技術❷

• 6.1　失敗を受け入れるマインドセット
  • 失敗を非難しないためのしくみづくり
• 6.2　始める前に失敗する──fail fast（早く失敗）ではなくfail before（事前に失敗）
  • 失敗を想定内の出来事にする
• 6.3　「知」の体系を理解し，学習棄却（unlearning）を行う
  • 暗黙知と形式知
  • SECIモデルの各フロー
  • 小さくSECIモデルを回し，レジリエンスエンジニアリングを実現する
• 6.4　マネージャーは「失敗」という言葉をリフレーミングする
  • 「称賛」は人を褒める，「失敗」は事象を指摘する
• 6.5　何度説明しても伝わらないように「伝えていないか」
  • 「1：N」と「1：1」の伝え方の違い
  • 伝え方の具体例
• 6.6　問題がないチームには，問題がある
  • 「心理的安全性が高い」は，ほとんどが虚像である
  • 快適ゾーンから，学習および高パフォーマンスゾーンへ
• 6.7　ピープルマネジメントは，型でマネージする
  • ピープルマネジメントの型
  • 目標→アサインする業務→関与方法はセットで定義する
  • 関与方針の具体例

第7章　プロセスを作る──「恐怖」と向き合う技術❸

• 7.1　失敗の原因は人ではなく，「しくみ」の欠如
  • ルールとしくみの違い
  • しくみ＝フィードバック制御で自動制御する
  • 失敗からの学びを強化させる3つのしくみ
• 7.2　失敗を正しく記録する
  • 失敗を組織の資産にする
  • 観測できないことは改善できない
• 7.3　ソフトウェア開発の工数予測と実測のデータ
  • リードタイム視点でのプロセス改善
  • VSMは失敗の記録には向かない
  • 財務諸表に近い開発生産性データをトラッキングする
  • 「いまの開発チームは優秀なのか？」という疑問には2種類ある
  • 類推見積りを導入する
• 7.4　仮説検証の失敗・成功のデータ
  • ステップ1：事業やサービスをシステム思考で構造化していく
  • ステップ2：構造化したものをKPIモデルに落とし込み，事業の勝ち筋が予測できる変数を理解する
  • ステップ3：勝ち筋の変数に対して仮説を考え，施策に優先順位をつけて学習サイクルを回す

付録　ソフトウェア開発の失敗「20」の法則

• プロジェクトの失敗率は，約68％
• 頭の片隅に置いておく「20」の法則
• プロジェクト管理・マネジメント
• 品質管理・リスク管理
• 組織構造・設計原則

• おわりに
• 索引