「正しく」失敗できるチームを作る ──現場のリーダーのための恐怖と不安を乗り越える技術（技術評論社） [電子書籍]

「正しく」失敗できるチームを作る ──現場のリーダーのための恐怖と不安を乗り越える技術（技術評論社） の 商品概要

• 「失敗」と聞いてネガティブな感情を持つ人もいるかもしれません。しかし，ソフトウェア開発の進化は，失敗を許容するテクノロジーの進化です。DevOpsやアジャイルといった武器とともに，「正しく」失敗し，トライ&エラーを繰り返すことが必要です。開発チームは，あえて失敗を作り出し，積極的に失敗を共有し，メンバーの失敗を心から許容することが必要です。
  しかし，現実の開発現場には残念ながら「間違った失敗」があふれています。それを「正しい失敗」へと転換することが本書のテーマです。「隠された失敗」から「透明性のある失敗」へ。「繰り返される失敗」から「学べる失敗」へ。「低リスクなムダな失敗」から「リスクをとった学べる失敗」へ。「間違った失敗」を生み出す恐怖と不安を乗り越える技術を，構造，文化，プロセスといった幅広い側面から紹介します。
  

• 目次

  ■序章 「間違った失敗」が起こる構造
  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」の法則
  

「正しく」失敗できるチームを作る ──現場のリーダーのための恐怖と不安を乗り越える技術（技術評論社） の商品スペック