【5分】始める前に失敗する ── fail fast（早く失敗）ではなくfail before（事前検死） ──

社内資料

Transcript

1. 始める前に失敗する
 ── fail fast（早く失敗）ではなくfail before（事前検死） ── 
 
 1 Masato Ishigaki
 Nov. 14, 2024

2. 2 About me
 石垣 雅人
 合同会社 DMM.com
 プラットフォーム開発本部 第1開発部 部長 
 ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版） 
 ・連載中 : 『開発生産性の多角的視点』（CodeZine） 
 ・連載中 : 『スモールチームが武器になる時代へ』（ProductZine） 
 ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』（NewsPicks）
 
 https://github.com/i35-267/resume/ 
 
 2
3. 小さく”失敗”してほしいが、感情が邪魔をする
 3 https://speakerdeck.com/pf_businessdivision/platform-business-division-recruitment?aslide=36
4. fail fast（早く失敗）も大事だけど、
 fail before（事前検死）もやってみる
 
 技術革新はfail fastを実現してきたが、
 人の感情制御はfail beforeでどうにかする
 4 失敗を恐れないために

5. 5 失敗を予測可能変数にする
 企画
 設計
 開発
 QA
 ・市場リサーチ結果がなく、何をもってこの企画の成功なのかがわからない失敗 
 ・ステークホルダーの合意を取らずに進めて、あとあとドンデン返しにあう失敗 
 リリース
 ・影響範囲が広く、正しく見積もれているかわからない失敗 
 ・技術選定が不安で、後々スケーラビリティーやパフォーマンスが心配である失敗 
 ・PdM, PMとコミュニケーションがうまく取れずに手戻りが多い失敗 
 ・タスク管理がざっくりすぎて、重要な機能が開発できていない失敗 
 ・テストケースの漏れでクリティカルなバグが検出されないまま進行する失敗 
 ・本番環境とQAを行う環境に差分がある失敗 
 ・リリース手順が明文化されてなかったり、自動化されていない失敗 
 ・リリースしたあとに想定外の負荷に耐えきれずにすぐにロールバック失敗 

6. 6 失敗を予測可能変数にする
 ── プロセスに組み込む── 
 企画
 設計
 開発
 QA
 リリース
 事前検死
 fail before
 プロジェクトが完全な失敗を想像したとして、 
 その原因を議論する。みんなで一度絶望する。 予想通り
 予想外
 →学習

7. No.
 ステップ 
 説明
 1
 シナリオの設定 
 プロジェクトが完全な失敗を想像し、その原因を探る。より具体的な失敗シナリオを設定し、そのシナリオに基づ いて議論を進める 
 2
 ブレインストーミング 
 そのプロジェクトに関わるメンバー全員で考え得るすべての失敗原因を洗い出す。異なるバックグラウンドや役割 を持つメンバーの意見を集め、包括的なリスク評価を行う 
 3
 リスクの評価とプライオリティ 
 洗い出した失敗原因を評価し、特に重大なリスクに対して優先順位を付ける。リスクの発生確率と影響度を評価 し、最も重大なリスクから対策を講じる準備を始める 
 4
 対策の検討 
 優先順位の高いリスクに対して具体的な対策を検討し、実行可能なプランを立てる。もとの計画を見なおし、必要 に応じて修正するリスクを最小化するための具体的なアクションプランを作成する 
 5
 結果の共有 
 検討した対策とその理由をチーム全体で共有し、全員が理解し合意することを確認する。ここで認識と合意を 取っておくことで対策の実行がスムーズになる 

8. 8 便利なものを使ってもよし
 https://note.com/fladdict/n/ne3459b681403
9. あくまでも議論のたたき台として

10. 失敗は一番はじめにしておく
 eof.

11. Appendix - マシュー・サイド (著), 有枝 春 (翻訳) 「失敗の科学」（ディスカヴァー・トゥエンティワン、 2016） - エイミー・C・エドモンドソン (著)「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」（英治出版、 2021） - 戸部良一、寺本義也、鎌田伸一、杉之尾孝生、村井友秀、野中郁次郎著『失敗の本質 ──日本軍の組織論的研究』中央公論新社、 1991年