【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell

1 Masato Ishigaki  Mar. 3, 2025  「正しく」失敗できる  チームを作る  〜現場のリーダーのための恐怖と不安を乗り越える技術〜 

2 About me  石垣雅人  合同会社 DMM.com  プラットフォーム開発本部副本部長   
・連載中 : 『開発生産性の多角的視点』（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（エクストリームプログラミング）  ・５つの価値観の内「勇気」がある。変更（失敗）を受け入れながら大胆な変更を行う。ビビっていると小さく小さくまとまろうとする   
→ ソフトウェア開発の時流として不確実性の中で失敗を繰り返しながら適応できるにも関わらず、それを組織全体の「価値観」として持ち込めていない    なぜなら、組織は「理解があるエンジニア」だけではないから  

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

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

人員を増やしたくなるとき  - 大体、切羽詰まってリカバリープランがないときほど人員増加に頼るしかなくなる  - 組織もシステムもエントロピーが高い状態（ドキュメント等もない）   - そのときはオンボーディングコストも高いし、そこに割くリソースもない  
- さらに採用の質も低くなり、チームに合わない人がジョインする可能性が高い   ② 人を増やせば早くなるという間違った失敗    「隠された失敗」より  

② 人を増やせば早くなるという間違った失敗    17 作れば作るほど、人員投入による効果は薄くなる  リーマンの法則から見るソフトウェアの保守性   - リーマンの第1法則（継続的変化の法則
）  - 何もしなくても環境の変化からエコシステムは変化させなければならない（ミドルウェアやOSのバージョンアップなど）  - リーマンの第2法則（増大する複雑さの法則）  - 変更を加えるたびに複雑性は増す。減らす取り組みをしない限り常に進行する。これはエントロピーが増すとも言う  - リーマンの第3法則（自己調整の法則）  - システムはフィードバックプロセスによって変化する（ユーザーの声や利用者の増加によって） 

リプレイス  リファクタリング  膨大な予算をかけて   元に戻す   ② 人を増やせば早くなるという間違った失敗    作れば作るほど、人員投入による効果は薄くなる 

② 人を増やせば早くなるという間違った失敗    歴史が深くなればなるほど複雑化する。システムも組織も。  古くからいるメンバーは精通している状態なので不憫・変化を感じない  感じるときは、新規に参画する人がいたとき  開発  0→1  健全な  ソフトウェア 
変更容易性が低い  ソフトウェア  t 健全な  ソフトウェア  オンボーディングコストは増大する   cost

個の生産性向上と自律するAIをかけ合わせることに予算を組む   ② 人を増やせば早くなるという間違った失敗    従来  +  - 個の生産性をclineやagent等で上げる  
- チームメンバーと非同期な対象として完全自律型 AIがいる  - 人材関連費に頼らずにライセンス料に予算をかける  - リードタイムも短くできる  これから  +  - 人を採用してチーム生産量を増やす   - 人件費や採用費、ライセンス料、福利厚生費でカバー  - リードタイムは長い  ・・・ 

ソフトウェア資産の蓄積コストと運用コストを忘れない   ③ 捨てられない失敗    機能開発  作れば作るほど蓄積し、捨てない限り運用コスト（変更容易性）は上がっていく   この仮説が駄目だったら、次の仮説へ  + 
+  +  - 機能の増やす・変更することにだけリソースをかけていると、  - 同じ人件費をかけているはずなのに徐々に開発スピードは落ち、インシデントは増えていく 

追加投資なしの現状維持は、衰退を意味する   ③ 捨てられない失敗    - 「捨てられない失敗」に陥るもう一つの原因は、一度リリースされると、そのプロダクトや機能が追加投資なしで価値を生み続けると錯覚される点   -
多少の売上が上がっている、SaaSであれば数社が利用していると「動いているからもったいない」「競合が追いついてくるまでは現状維持でいこう」といった選択が、多くの運用コストを作る  - リーマンの法則にもある通り、「継続的変化の法則」によって何もしないと複雑化し衰退していく = エンジニアの負荷が上がっていく    

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

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

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）   これらを隠さず、透明性を上げる方法は本書にて 

透明性のある失敗へ 

小さく作ればよいというものじゃない  - 「小さく作ろう」「細かくリリースしよう」というリスクの軽減方法はミスリード  - MVP（Minimum Viable Product）におけるViableになっているか  - Viableの前にどのようにMinimizeされるべきかを考える  -
NGパターン  - 実装が難しそうだから、簡易的なものを作ってみよう  - 全部やると工数がかかりそうだから、少ない工数でできるやつを優先しよう  - 競合が提供している機能のコア部分だけを最小限で開発しよう  これらはすべて機能や工数をMinimizeしている  

小さく作ればよいというものじゃない  仮説を検証できているかの観点を重視する   工数や実装難易度でMVPをスライスしない  

“ 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. 童話の「裸の王様」誰もおかしいことを指摘しないから「自分だけ服が見えていないのかもしれない」と錯覚  リモート環境の増加によって見えないため顕著になった 

多元的無知の例 

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

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

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

固定型マインドセット   知性や才能が生まれつき決まっているととらえる考え方      失敗に向き合うマインドセット  失敗の受け止め方の違いにおいて、この 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でどうにかする  56
始まる前に失敗する  2007年に、ゲイリー・クライン氏が提言 

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

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

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

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

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

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

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

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

失敗の原因は人ではなく「仕組み」の欠如と捉える  トヨタ生産方式 : 「人を責めるな責めるな、しくみを責めろ」  出発点 : ルールで縛るのではなく仕組みで自動化する  - ルール  -
特定の行動や手順を収めたガイドライン  - 仕組み  - ルールが勝手に守られるようなプロセス構築  - ex.   - コードレビューは2名以上の承認が必要→ルール   - コードレビューは2名以上の承認しないとマージできない → しくみ    

失敗の原因は人ではなく「仕組み」の欠如と捉える  理論っぽくいうと「しくみ」は制御理論でいうフィードバックループで制御する  フィードフォワード制御   - 望ましい結果を得るために事前に行動を調整する方法で、ルールに似ている。たとえば「コードレビューが必要」というルールは、事前に行動を規定し、バグの発生を防ぐ働きを持っている     フィードバック制御 
- システムの出力を監視し、その結果に基づいて調整する方法で、しくみに対応する。たとえば、「Pull Requestを作成するとコードレビューが自動的に開始され、承認が2名以上でないとマージできない」という設定が挙げられる。   ・ルールは「事前に設定された目標を達成するために何をすべきか」を明確に指示する     ・しくみは「目標を達成するためにシス   テム全体がどのように動くべきか」を自動的に調整する役割 

失敗を正しく記録する  失敗を資産化する。観測できないものは改善できない  - リソースは有限であり、その中で「何を作るか」「どう作るか」が決定していきます  - そのため、いち早く成功する施策や良い機能を構築し、継続的に継続できるか  - 失敗データは、単に失敗の記録ではなく、予測データ・成功/失敗データをすべて格納し、分析可能な状態にする  -
そもそも予測していないと成功も失敗もない 

失敗を正しく記録する  ソフトウェア開発の記録  仮説検証の記録 

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

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

【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り...

【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Featured

Transcript