出版書誌データベース

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

はじめに

■序章　「間違った失敗」が起こる構造
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」の法則
プロジェクト管理・マネジメント
品質管理・リスク管理
組織構造・設計原則

おわりに
索引

著：石垣 雅人
合同会社DMM.com。 DMM.comにエンジニア職で新卒入社し、プロダクトマネージャーを経て2020年、DMM.comの入口である総合トップなどを管轄する総合トップ開発部の立ち上げを行い、部長を務める。現在は、DMM.comの4,507万（2024年2月時点）会員のID基盤を中心に複数のプラットフォーム基盤を扱う部署の部長を務めながら、DMM全体のエンジニア・デザイナー・PM組織の組織課題を解決する部署も兼務している。 著書に『DMM.comを支えるデータ駆動戦略』（マイナビ出版、2020年）がある。