「正しく」失敗できるチームの作り方〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly

1 Masato Ishigaki  Fed. 25, 2025  「正しく」失敗できる  チームの作り方  〜リアルな事例から紐解く失敗を恐れない組織とは〜 

2 About me  石垣雅人  合同会社 DMM.com    ・著 :
『正しく』失敗できるチームを作る（技術評論社, 2025）   ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版, 2020）   ・連載中 : 『開発生産性の多角的視点』（CodeZine）   ・連載中 : 『スモールチームが武器になる時代へ』（ProductZine）   ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方』（NewsPicks）    2

3 書籍紹介  3

“「失敗」と聞いて、思い浮かぶものは何でしょうか。   成功するのに必要な過程ととらえる人もいるでしょうが、ネガティブな感情を持つ人も多いでしょう。   いくら上司や周りの人から「失敗を気にせずに挑戦してほしい。責任は私が取るから」と言われても、   どう責任を取ってくれるのかわからないし、そもそもどういう責任が生まれるかもわからない。    
失敗し続けたら評価が下がりそうだし、周りの人からの自分に対する視線も気になる。  成功し続けたほうがはるかに楽しいし、失敗したことを報告するのも躊躇してしまう。   精神的にもしんどいし、失敗するという恐怖に向かって走ることは楽しくない。   〜    4 どんな本か「はじめに」から引用  ※あまり組織論にならずに現場の生々しさを   人とプロセスに焦点を当てている   本書は、主にソフトウェア開発を行うチームの失敗について書かれた本であり、   そこからの立ち直り方を記した、レジリエンスエンジニアリングの本です。” 

5 Table of Contents  序章　「間違った失敗」が起こる構造   第1章　「間違った批判」から生まれる「間違った失敗」   第2章　「間違った失敗」から「正しい失敗」へ  
第3章　「正しい失敗」は技術革新によって作り出された   第4章　「間違った失敗」の背景にある「関係性の恐怖」   第5章　構造を動かす──「恐怖」と向き合う技術❶   第6章　文化を醸成する──「恐怖」と向き合う技術❷   第7章　プロセスを作る──「恐怖」と向き合う技術❸   付録　ソフトウェア開発の失敗「20」の法則    

第3章　「正しい失敗」は技術革新によって作り出された   第4章　「間違った失敗」の背景にある「関係性の恐怖」   第5章　構造を動かす──「恐怖」と向き合う技術❶   第6章　文化を醸成する──「恐怖」と向き合う技術❷   第7章　プロセスを作る──「恐怖」と向き合う技術❸   付録　ソフトウェア開発の失敗「20」の法則     論点整理と  間違った失敗の事例   技術革新の歴史的な話   人と人  人とチームの話  失敗と向き合う技術  Howの部分 

7 今日話す箇所（人に寄せた部分）  序章　「間違った失敗」が起こる構造   第1章　「間違った批判」から生まれる「間違った失敗」   第2章　「間違った失敗」から「正しい失敗」へ   第3章　「正しい失敗」は技術革新によって作り出された  
第4章　「間違った失敗」の背景にある「関係性の恐怖」   第5章　構造を動かす──「恐怖」と向き合う技術❶   第6章　文化を醸成する──「恐怖」と向き合う技術❷   第7章　プロセスを作る──「恐怖」と向き合う技術❸   付録　ソフトウェア開発の失敗「20」の法則     論点整理と  間違った失敗の事例   技術革新の歴史的な話   人と人  人とチームの話  失敗と向き合う技術  Howの部分  概要をさらいながら、具体的な解決策は本書にて。  頭の地図を作ることに重きを置きます。 

非連続な成長の裏には失敗がある 

「失敗から学ぶべき」は、みんなわかってる  ただ、邪魔をする社会心理的な話    認知的不協和  無意識的に自分の信念と反する事実に直面すると強い苦痛を感じる。自分の信念を否定して新たな事実を受け入れるのは、容易ではなく自分の無能さを認めることは非常に困難     確証バイアス 
自分の信念や仮説を支持する情報だけを探し出し、反する情報を無視する傾向。レコメンド社会でさらに加速  

11 「反証可能性」から見る失敗の重要性  引用 : Wikipedia  「真の無知とは知識の欠如ではない。学習の拒絶である」  by 哲学者カール・ポパー   
科学の本質は「絶対的な真実の証明」ではなく「間違ったものを排除していくプロセス」にある。逆に反証可能性がないもの（運命で決まっている等）は科学的ではない    つまりは間違っているかもしれないとテストできることが大事   失敗しないと何が正しいかわからないままになる     反証可能性を担保するには、失敗から生まれる事象こそ一番の学習材料であるということです。  

12 ソフトウェア開発の進化にメンタルの進化が追いついていない  DevOps  ・失敗は避けられないもので、早期に発見し迅速に回復する（CI/CD）     XP（エクストリームプログラミング）  ・５つの価値観の内「勇気」がある。変更（失敗）を受け入れながら大胆な変更を行う。ビビっていると小さく小さくまとまろうとする   
→ ソフトウェア開発の時流として不確実性の中で失敗を繰り返しながら適応できるにも関わらず、それを組織全体の「価値観」として持ち込めていない    なぜなら、組織は「理解があるエンジニア」だけではないから  

なぜ、そんなことが起こってしまうのかを構造的にとらえる    だいたい同じパターンで失敗する  “お決まりの失敗”を作る「行動パターン」を見つける  　  ※一般システム理論的な考え方  

“お決まりの失敗”を作る「行動パターン」を見つける  自分がいるチームを観察して見つける（パターンランゲージ）    書籍で出している例（リアル）  ① 「ゼロリスク」が優先度判断を狂わせる失敗  ② 人を増やせば早くなるという間違った予算投入の失敗  ③ 「捨てられない」失敗
── ソフトウェアの蓄積コストと運用を忘れない ──      

“お決まりの失敗”を作る「行動パターン」を見つける  自分がいるチームを観察して見つける（パターンランゲージ）    書籍で出している例（リアル）  ① 「ゼロリスク」が優先度判断を狂わせる失敗  ── 「システム障害を起因とした内部品質の軽視による間違った失敗」──   ──
「見積もりの不確実性へのご認識による間違った失敗」──    ② 人を増やせば早くなるという間違った予算投入の失敗  ③ 「捨てられない」失敗 ── ソフトウェアの蓄積コストと運用を忘れない ──   

① 「ゼロリスク」が優先度判断を狂わせる失敗  ── 「システム障害を起因とした内部品質の軽視による間違った失敗」──   ソフトウェア  ソフトウェアは、ず〜と(24/365) 動くべきという誤解  PMや違うチーム  私たち 
不具合が起きてるから  すぐに直して！  手を止めて対応する  （深夜1時） 

① 「ゼロリスク」が優先度判断を狂わせる失敗  ── 「システム障害を起因とした内部品質の軽視による間違った失敗」──  

① 「ゼロリスク」が優先度判断を狂わせる失敗  ── 「見積もりの不確実性へのご認識による間違った失敗」──   見積もり  見積もりと実装スケジュールは必ず一致するという誤解  PMや事業責任者  私たち  なぜ、見積もり通りに 
開発が進まないんだ！  実際に開発してみないとわからないことが色々あるんだよな... 

引用: IPA 「IT企業4,564プロジェクトプロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果」  計画より上回っている   計画より下回っている   19
① 「ゼロリスク」が優先度判断を狂わせる失敗  ── 「見積もりの不確実性へのご認識による間違った失敗」──  

20 ① 「ゼロリスク」が優先度判断を狂わせる失敗  ── 「見積もりの不確実性へのご認識による間違った失敗」──   二つを分ける  見積りを約束としない 

「行動パターン」の例が、沢山のっています 

“お決まりの失敗”「行動パターン」の次は  それがどういった「結果」になっているかをグルーピング 

1. 「隠された失敗」→「透明性のある失敗」へ  2. 「繰り返される失敗」→「学べる失敗」へ  3. 「低リスクなムダな失敗」→「リスクを取った学べる失敗」へ  間違った失敗を3つに分類して「正しい失敗」へ 

さらに分解する  「しても良い失敗」と「してはいけない失敗」 

1. 「隠された失敗」から「透明性のある失敗」へ  i. 課題は時間が経過すればするほど複雑化して膨張していく   ii. エンジニアは説明責任を果たすことで透明性を作っていく   2. 「繰り返される失敗」から「学べる失敗」へ 
i. 障害の再発防止策から逃げない〜ポストモーテムを最大限活用する〜   ii. 仮説は検証して初めて学びになる（学習せず仮説を量産しても意味がない）   3. 「低リスクなムダな失敗」から「リスクを取った学べる失敗」へ  i. 小さく作ればよいというものじゃない（小さく失敗のアンチテーゼ）   ii. 工数や難易度でMVPをスライスしない   間違った失敗を3つに分類して「正しい失敗」へ 

課題は時間経過とともに複雑化して膨張する 

失敗は隠されがち  1. 課題が隠されると超大作の失敗になりがち  a. 期日の1日前に「1ヶ月間後ろ倒しになります」   b. できあがったものが想定と違う（途中報告がほぼなし）   c.
課題の認識合わせをせずに結合して根本から作り直し。3ヶ月間後ろ倒し   2. 若手PdMの成果報告  a. 良い結果のみを力を込めて資料作成の報告・可視化してしまう   b. 施策のスケールがどんどん小さくなる（スケールがでかい＝失敗確率UP）   これらを隠さず、透明性を上げる方法は本書にて 

透明性のある失敗へ 

“ Only by redefining failure will we unleash progress, creativity
and resilience.”    人は失敗を再定義することでのみ、「進歩」と「クリエイティビティ」「レジリエンス」を解き放つことができる   ===  競争優位性が高くなる昨今、  成功と失敗の学習からスピード感の獲得が必須。   失敗から学ぶ体力（レジリエンス）を身に着け、   転びながら進んでいくのが一番手っ取り早い。   失敗とリカバリーのエンジニアリングが必要。      「正しい失敗」はなぜ必要か 

- 「隠された失敗」→「透明性のある失敗」  - 課題解決にかかる時間をコントロールできる  - 「繰り返される失敗」→「学べる失敗」  - 再利用できないムダな時間をなくすことができる  - 「低リスクなムダな失敗」→「リスクを取った学べる失敗」 
- ムダな学習時間を短縮できる（ただ小さく作って学習を繰り返しても意味がない）  「正しい失敗」をすれば失敗をコントロールできる 

「間違った失敗」が起こる原因について考えてみる 

ソフトウェア開発は、エンジニアリングの技術的な側面だけでは成り立っておらず、   「関係性」の構築という、チーム内での集団活動の泥臭い部分が大きな成功要因となる     開発の失敗は、人と人の関係性摩擦で起きる  自分  上司・PM/CS  事業責任者  「評価されたい」「良いものを作りたい」
「開発に集中したい」「売れるものにリソースを使いたい」  「すぐできないって言われる」  「議論で黙っているから何を考えているかわからない」 

ソフトウェア開発は、エンジニアリングの技術的な側面だけでは成り立っておらず、   「関係性」の構築という、チーム内での集団活動の泥臭い部分が大きな成功要因となる     開発の失敗は、人と人の関係性摩擦で起きる  自分  上司・PM/CS  事業責任者  「評価されたい」「良いものを作りたい」
「開発に集中したい」「売れるものにリソースを使いたい」  「すぐできないって言われる」  「議論で黙っているから何を考えているかわからない」  ・入口としての「対人関係の難しさによる関係性の失敗」  ・出口としての「間違った評価制度と対となる目標設定の失敗」 

エンジニアの「できない」という言葉の意味  ❶ ほかのタスクをしているので「できない」  ❷ 今の機能では「できない」  ❸ 何かしらの制約で「できない」  ❹ 時間がかかるので「できない」  ❺
今のチームスキルだと「できない」  ❻ やるべきではないと思っているから「できない」  1.「これ、できそうですか？」 2.「ちょっと厳しいですね」  上司や他チーム  

「できない」を「できる」に置き換える  やってはいけないのは、改善を提案する人を冷めさせないこと  否定から入るのをやめる  (システムをよく知っているからこそ、一般論が通用しなくなってくる) 

こうした関係性をアイコンと音声で作る時代へ    メンバーが何を考えているのかがわからない    ・テキストベースだと言い方がキツくなり、ハレーションが生じやすい  • 顔が見えないため、メンバーのメンタルコントロールが難しくなる  • 会議での反応が薄く、理解・納得しているのかがわからない  •
無音のとき、深く考えているのか、ただ黙っているのかの区別がつかない   

議論で黙って静かにいることは合意ではない  https://lamanufacturedidees.org/2021/05/04/ingold-tim/   「黙っている = 合意しません」になる    会議ツールで「空虚」に話しかけるのは  メンタルに来る  →「繋がっているが孤独な関係性」に陥る 
  ティム・インゴルド氏の『応答、しつづけよ。』  「生きるとは、世界と応答しつづける過程そのものである。   

「繋がっているが孤独な関係性」に陥らない  休職に至る前に「繋がっているが孤独」になる     そうならないためにリアクションを多めにする   - 明確なフィードバックを促す  - 直接伝える。相槌でもよい 
- ラウンドロビン形式を導入する  - 話を振る  - 非言語的なフィードバック  - チャットを使いサムズアップ👍   

https://jp.pinterest.com/pin/620652392410381363/ なぜ、人はリアクションしないのか  議論で黙って静かにしていることの背景には、以下2点が影響   - 傍観者効果（BystanderEffect）  - 他の人が行動しないのと見て自分も行動しない現象  - 「他の人が対応してくれるだろう」「自分よりも適任がいる」 
- ゆえにElephant in the Room（部屋の中の象）が発生    - 多元的無知（PluralisticIgnorance）  - 本当は誰もそう思っていないのに「みんながそう望んでいる」と信じ込んでしまう現象  - ex. 童話の「裸の王様」誰もおかしいことを指摘しないから「自分だけ服が見えていないのかもしれない」と錯覚  リモート環境の増加によって見えないため顕著になった 

多元的無知の例 

「他責思考」なチームの出来上がり  これだと頻繁に「隠された失敗」が起きやすくなる  ※ここから抜け出す方法は本書にて 

逆に「自責思考」も失敗を作る  リーダーのフェーズとして、うまく「任せるコツ」を  つかまなければいけない時期が来る  →「自分でやったほうが早い」「マイクロマネジメントでしかチームが上手く動かない」（「隠される失敗」や「繰り返される失敗」が起きる）    すべての問題を自責思考で自分で抱え込むと  自分自身がボトルネックになる（人数スケールの問題）    「任せられない」「罰ゲーム」からどう抜け出すか 
→ マネジメントを極めればマネジメントしなくてよいというマインドを持つ   → なぜならマイクロマネジメントに頼らなくてもよくなるから余裕ができるからプレイヤーとしても活動できる  ※詳しくは本書にて 

自責には、自己叱責と自己責任がある  自己叱責  すべての原因を自分に求める傾向。  「自分が悪い」「自分はダメだ」という自己否定的な感情を伴いやすく、ネガティブなメンタル状態に陥りやすくなる  マネージャーでも「人」と「コト(役割)」を分けて無力感にならないように。やったことのネガティブフィードバックを自分ではなく役割のほうへ向ける    自己責任  自分の行動に対して覚悟を持って取り組む姿勢。 
失敗や問題が発生しても「なぜ起こったのか」を冷静に分析し、客観的に原因をとらえます。ここには過度なネガティブ感情がほとんど伴わず、失敗を単なる挫折とせず、興味深い改善のための学習機会としてとらえることが可能になります    → リーダーが作り出す失敗から抜け出すには自己叱責から自己責任へ切り替えること   

失敗に向き合い、改善する組織を作るには  第5章　構造を動かす  ──「恐怖」と向き合う技術❶  第6章　文化を醸成する  ──「恐怖」と向き合う技術❷  第7章　プロセスを作る  ──「恐怖」と向き合う技術❸  今日はここだけ  仕組みとルールの違いと  
フィードバック制御の話。   そして、記録することの大事さ  

固定型マインドセット   知性や才能が生まれつき決まっているととらえる考え方      失敗に向き合うマインドセット  失敗の受け止め方の違いにおいて、この 2つのマインドセットの間にあるであろう  
「失敗に対しての恐怖」を組織としてどう崩せる技術（後天的に鍛える）を持っておくか  成長型マインドセット   知性や才能が努力によって伸びるという考え方    失敗したときに、脳内で何が起こっているのかを観察する調査  ERN反応・・失敗に気づいた際の反応   Pe対応・・失敗から学ぼうとする反応   失敗を無視する傾向（Pe↓）  失敗に興味津々（Pe↑） 

失敗を非難しない文化（仕組みづくり）  1. 「事前検死（pre-mortem）」を行う  2. 「知」の体系を理解し、学習棄却（ unlearning）を行う  3. 失敗をリフレーミングする 

1. 「事前検死（pre-mortem）」を行う  2. 「知」の体系を理解し、学習棄却（ unlearning）を行う  3. 失敗をリフレーミングする  失敗を非難しない文化（仕組みづくり） 

fail fast（早く失敗）も大事だけど、  fail before（事前に失敗）もやってみる    技術革新は、fail fastを実現してきたが、  人の感情制御は、fail beforeでどうにかする  53
始まる前に失敗する  2007年に、ゲイリー・クライン氏が提言 

54 失敗を予測可能変数にする  ── プロセスに組み込む──   企画  設計  開発  QA  リリース 
事前検死  fail before  プロジェクトが完全な失敗を想像したとして、   その原因を議論する。みんなで一度絶望する。予想通り  予想外  →学習  失敗が起こっても想定内の事象になり誰も責めなくなる雰囲気が生まれる。逆に想定外の失敗が起きたら事前に検知出来なかったチームの課題へ  

55 「称賛」と「失敗の指摘」はベクトルを分ける  - 成果を称えるなら人を褒める、課題を指摘するなら事象を指摘する   - 褒める際は誰から言われたかが重要であり、課題については何を指摘されたかが重要である  

議論のたたき台としてGPTsを使う 

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

失敗を非難しない仕組みづくり  1. 「事前検死（pre-mortem）」を行う  2. 「知」の体系を理解し、学習棄却（ unlearning）を行う  3. 失敗をリフレーミングする 

マネージャー自身が失敗という言葉の意味を  ポジティブに変換していき、  会話の中で愚直によく使うことが一番効果がある  ※ 職位が上がってくると「良いことはわかったから課題を言ってくれ」となる    ex.  「いま、この課題を話してくれたおかげで早めに対策を打つことができて助かったよ」    
  「失敗」という言葉をリフレーミングする  失敗の考え方をリフレーミングし、失敗と不安を切り離す  

何度説明しても伝わらないように「伝えてないか」  「人は、何をどう聞き逃し、都合よく解釈し、誤解し、忘れるのか」   by 『「何回説明しても伝わらない」はなぜ起こるのか』（今井むつみ著）     ex   -
1:1と1:Nの伝え方の違い  - 1:Nはざっくり。1:1は相手の理解度に合わせて詳細に話す   - 全員ミーティングは、傍観者効果でほとんど聴いていない   この過程でよく直面する問題の一つが、  マネージャーの言葉が正しく伝わらないこと 

「問題がないチームには、問題がある」と伝える  心理的安全性が高いは、ほとんどが虚像である  ぬるま湯な可能性が高いため、できるだけ適切な目標を立てた上でモチベーション高く  常に失敗から生まれる「恐怖」と戦っているチームが正しい状態であるとも言えます    高い目標を掲げれば掲げるほど能力差分が生まれ、失敗は必然となり当たり前になる 

62 今日話す箇所（人に寄せた部分）  序章　「間違った失敗」が起こる構造   第1章　「間違った批判」から生まれる「間違った失敗」   第2章　「間違った失敗」から「正しい失敗」へ   第3章　「正しい失敗」は技術革新によって作り出された  
第4章　「間違った失敗」の背景にある「関係性の恐怖」   第5章　構造を動かす──「恐怖」と向き合う技術❶   第6章　文化を醸成する──「恐怖」と向き合う技術❷   第7章　プロセスを作る──「恐怖」と向き合う技術❸   付録　ソフトウェア開発の失敗「20」の法則     論点整理と  間違った失敗の事例   技術革新の歴史的な話   人と人  人とチームの話  失敗と向き合う技術  Howの部分  概要をさらいながら、具体的な解決策は本書にて。  頭の地図を作ることに重きを置きます。 

“恐怖を感じた時、多くの人は、その恐怖を  無視することができなくなるまで放置するか、その恐怖について考えようともせずに、恐怖から逃げようとする。  〜  「もう少し待てば状況は良くなる。時間が状況を良くしてくれる。」と楽観的で安易な考えを持って、簡単な選択をしてしまう時がある。  〜  その恐怖から逃げるのではなく、恐怖に向かって走っ
てみてほしい。逃げるよりは、  良い結果にたどり着けるはずだ。”    63 「おわりに」から引用 

「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / ...

「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Featured

Transcript

「正しく」失敗できるチームの作り方〜リアルな事例から紐解く失敗を恐れない組織とは〜 / ...

「正しく」失敗できるチームの作り方〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly