「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術

はじめに

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

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

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

■第3章　「正しい失敗」は技術革新によって作り出された
3.1　チームサイズの変化
3.2　チームサイズのスパン・オブ・コントロール
3.3　クラウドとコンテナ技術の発展
3.4　セクショナリズムとDevOps
3.5　マイクロサービスとコンウェイの法則が、スモールチームとシステムのあり方を定義した
3.6　フルサイクルでのエンジニアリングが可能に

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

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

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

■付録　ソフトウェア開発の失敗「20」の法則
プロジェクトの失敗率は、約68％
頭の片隅に置いておく「20」の法則
プロジェクト管理・マネジメント
品質管理・リスク管理
組織構造・設計原則

おわりに
索引