Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
根本原因分析で「改善力」を上げよう
Search
うきぐも / すずき
June 03, 2025
Technology
91
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
根本原因分析で「改善力」を上げよう
某社の社内勉強会で使おうとして作ったはいいものの、結局しゃべっていない資料です。作った本人ですら存在を忘れていました。供養しておきます。
うきぐも / すずき
June 03, 2025
More Decks by うきぐも / すずき
See All by うきぐも / すずき
UQAMのその先
ukigmo_hiro
0
34
プロンプトウェアアーキテクチャ
ukigmo_hiro
0
100
UQAM(Usage-model-driven QA Methodology)の紹介
ukigmo_hiro
0
360
「改善」ってこれでいいんだっけ?
ukigmo_hiro
0
740
「改善」ってこれでいいんだっけ? Full ver.
ukigmo_hiro
0
350
MDR(Model-Driven Retrospective)のススメ
ukigmo_hiro
1
110
三幕構成を使いこなす ~創作の旅路を支える地図~
ukigmo_hiro
1
460
eラーニングコンテンツのチェックリストをVSTePで作ってみたの
ukigmo_hiro
1
400
Other Decks in Technology
See All in Technology
[JAWS-UG彩の国埼玉#12]そろそろ準備する?re:Invent2026をやさしく解説 / reinvent2026-sainokuni
sh_fk2
1
410
AI コーディングと人間の認知スループット / CTO Night & Day 2026 Morning Session / AI Coding and Human Cognitive Throughput
prog893
5
1.5k
企画を Software Factory-ready にする——開発が高速になったとき、PdMの仕事はどう変わったか
yachibit
1
230
Temporal 最高!でも改めて「日付」について調べたら人類の負債すぎる件
riyaamemiya
0
230
CSS2026:OWS研究会・招待講演「世界観を、実装する」
atsush1_sada
2
270
React改造してみた
tsukina_7mochi
0
160
Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜
occhi
1
1.1k
僕のハーネスを紹介します
watany
5
1.6k
DevelopersIO 2026 Tokyo 現時点の衛星通信サービスの現状を整理してみる
maroon1st
0
270
Gemini Intelligence 入門 ― AppFunctions と Gemini Nano
takuroabe
0
370
sue445's proposals 2026
sue445
0
140
AWSDirectConnectの構築の進め方を整理してみた
masa_my
1
170
Featured
See All Featured
A designer walks into a library…
pauljervisheath
211
25k
New Earth Scene 8
popppiees
4
2.7k
Code Review Best Practice
trishagee
74
20k
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
Bash Introduction
62gerente
615
220k
Designing for Performance
lara
612
70k
Side Projects
sachag
456
43k
ラッコキーワード サービス紹介資料
rakko
4
5.4M
How to Talk to Developers About Accessibility
jct
2
590
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.7k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
790
Making the Leap to Tech Lead
cromwellryan
135
10k
Transcript
すずき 根本原因分析で 「改善⼒」を上げよう
改善が⼤事だと知ってはいるけれど…… • 改善の重要性は“⽿タコ” ▪ 完璧を⽬指すより 早く失敗して早く改善した⽅がいい!(Fail Fast) ▪ ふりかえり会やポストモーテムで スクラムチームを強くしよう!
• 具体的な「改善のやり⽅」は誰も教えてくれないから 実はよくわかっていない ▪ 「次からはもっとがんばってもっと気を付けます」 といった改善施策を⽴てがち ▪ 結局なぜなぜ分析は良いの?悪いの? • なぜ?を5回繰り返すといいらしい? • パワハラに繋がるからやめた⽅がいい? 2
改善施策の開発は「根本原因分析」がキモ • 改善施策もソフトウェア同様「開発する」必要がある ▪ 根本原因が何なのか考え抜いて 改善施策の要求分析を⾏う ▪ どういう活動で根本原因に対処するのか議論し 改善施策を設計する ▪
具体的なやり⽅‧頻度‧参加者/担当者‧フォーマットなどを決めて 改善施策を実装する • 改善施策もソフトウェア同様 要求分析の良し悪しが最終形の良し悪しを8割⽅決める ▪ 改善施策の要求分析は特に「根本原因分析」と呼ばれる ▪ 「良い根本原因分析とは?」が今回の主題です 3
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 2. ⾒落とされがちな ⽔平分析 3. 意外と⼤事な マインドセット
4
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 2. ⾒落とされがちな ⽔平分析 3. 意外と⼤事な マインドセット
5
「なぜなぜ分析」を正しく使おう • 「なぜ?」を繰り返して真因を追及する 根本原因分析⼿法のひとつ ▪ 実は Why Why Analysisとして海外でも知られている ▪
「なぜ?」に回数制限は存在しない ▪ 吊るし上げやパワハラの道具ではない • シンプルなようで奥が深く いくつかのアンチパターンが存在する A. 無意味なルート B. 深度不⾜ C. 哲学化 6
なぜなぜアンチパターン A. 無意味なルート 7 ⼯場で転んで ケガをした ⾜腰が弱いから 運動不⾜だから ✖ ⽬的からかけ離れた
意味のないルート
なぜなぜアンチパターン A. 無意味なルート 8 ⼯場で転んで ケガをした ⾜腰が弱いから 運動不⾜だから ✖ ⽔たまりで
滑った 蛇⼝のパッキンが 劣化していた 〇 ⽬的に合致した 意味のあるルート
なぜなぜアンチパターン B. 深度不⾜ 9 ⼯場で転んで ケガをした ⽔たまりで 滑った 蛇⼝のパッキンが 劣化していた
改善施策 設計 パッキンを交換しよう ✖ もしも再発したら? 今の深度では「再交換」のように 同じことを繰り返す未来が⾒える → 根本原因にまだ辿り着いていない
パッキン交換の ルールを作ろう なぜなぜアンチパターン B. 深度不⾜ 10 ⼯場で転んで ケガをした ⽔たまりで 滑った
蛇⼝のパッキンが 劣化していた 改善施策 設計 交換の頻度が 決まっていなかった 〇 もしも再発したら? ルールが間違っていたなら修正しよう 忘れてたならリマインダを設定しよう
なぜなぜアンチパターン C. 哲学化 11 ⼯場で転んで ケガをした ⽔たまりで 滑った 蛇⼝のパッキンが 劣化していた
交換の頻度が 決まっていなかった ⼈間は愚かなので 標準化を怠った ✖ 深度が深すぎると それはそれで意味がない
なぜ?をちょうどいい深さで⽌める • 「なぜ?」の繰り返しで価値のありそうなルートを進み 浅すぎず深すぎずで⽌める技術が必要 ▪ ▪ 改善施策を設計‧実装できる深さ ▪ ▪ 将来
再発しても同じことが繰り返されない深さ • 魔法の呪⽂「もしも再発したら?」 ▪ ▪ ナレッジとして集積する価値のある深さ (i.e. ソフトウェアトラップ分析) • バグやインシデントの真因には ⼈間の間違いを誘発するような罠の存在がある という考え⽅ - e.g. アンケートで数字の⼩さい⽅の扱いがポジティブ/ネガティブ混在していると e.g. 集計システム開発にてバグを作りこみやすい - e.g. 割り込み先から帰ってきたら割り込み元の状態が変わっているケースがまれによくある - e.g. 備考欄の情報はバグの温床になる e.g. (補⾜的に書く必要があるにもかかわらず本⽂に含められない程度には整理されていないため) 12
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 ▪ パワハラの道具ではないし回数制限も存在しない ▪ 無意味なルート‧深度不⾜‧哲学化といったアンチパターンに気を付けよう 2. ⾒落とされがちな
⽔平分析 3. 意外と⼤事な マインドセット 13
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 ▪ パワハラの道具ではないし回数制限も存在しない ▪ 無意味なルート‧深度不⾜‧哲学化といったアンチパターンに気を付けよう 2. ⾒落とされがちな
⽔平分析 3. 意外と⼤事な マインドセット 14
垂直と⽔平 両⽅向の分析を駆使しよう • 根本原因分析には 垂直分析と⽔平分析の2種類が存在する ▪ 垂直分析:「なぜ?」を使って真因を追及するやり⽅ i.e.なぜなぜ分析 ▪ ⽔平分析:「他には?」を使って根本原因分析の網羅性を上げるやり⽅
15 ⼯場で転んで ケガをした ⽔たまりで 滑った 蛇⼝のパッキンが 劣化していた 清掃が 不⼗分だった 負傷者は ⾛っていた 短納期作業を 強いられて焦った
垂直/⽔平分析で原因のモデリングをしよう • 品質管理の分野で 特性要因図(Fishbone Diagrams)と呼ばれるクラシックな記法がある ▪ 「⽇本の品質管理の⽗」こと東⼤の故⽯川馨名誉教授が 問題解決やナレッジ共有のために開発 ▪ QC7つ道具のひとつに数えられる
• Quality Control; 品質管理 ▪ 引⽤元: 特性要因図 16
垂直/⽔平分析で原因のモデリングをしよう • 安全⼯学や信頼性⼯学の分野で 故障の⽊解析(FTA:Fault Tree Analysis)と呼ばれるクラシックな記法がある ▪ 引⽤元: 故障の影響解析(FMEA)と、故障の⽊解析(FTA)の活⽤ 17
垂直/⽔平分析で原因のモデリングをしよう • FFD(Failure Flow Diagram)と呼ばれる記法を提案している⼈も居る ▪ 下図はアリアン5ロケットの爆発事故に関するFFDの例 • 参考: 失敗事例
> アリアン5型ロケットが制御不能で40秒後に爆発 , 「5億ドル?!を吹っ⾶ばした、たった1つのバグ!」について調べた 18 アリアン5ロケットが 爆発した 座標計算システムの オーバーフロー 旧型⽤コードを そのまま流⽤してOKと 誤解 機能が変わらないとき パラメータの変更要件を ⾒逃しやすい 実⽤中のコードには バグが無いという先⼊観 節約しろという エラい⼈からの圧⼒ インシデント バグ エラー (⼈間の誤り) トラップ ブースター (改善しにくい外的要因)
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 ▪ パワハラの道具ではないし回数制限も存在しない ▪ 無意味なルート‧深度不⾜‧哲学化といったアンチパターンに気を付けよう 2. ⾒落とされがちな
⽔平分析 ▪ 「他には?」を考えて根本原因分析の網羅性を上げよう ▪ 垂直分析と⽔平分析の併⽤時には モデリングした⽅が頭の中が整理される 3. 意外と⼤事な マインドセット 19
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 ▪ パワハラの道具ではないし回数制限も存在しない ▪ 無意味なルート‧深度不⾜‧哲学化といったアンチパターンに気を付けよう 2. ⾒落とされがちな
⽔平分析 ▪ 「他には?」を考えて根本原因分析の網羅性を上げよう ▪ 垂直分析と⽔平分析の併⽤時には モデリングした⽅が頭の中が整理される 3. 意外と⼤事な マインドセット 20
意外とマインドセットも重要 • 品質管理はマインドセットと⼿法の両輪がキモ ▪ マインドセットが浸透している状態を 「品質⽂化が醸成されている」と呼ぶ⼈も居る • 垂直分析(なぜなぜ分析)‧⽔平分析はあくまで⼿法/道具 ▪ 悪意を持って使えば⼈を傷つけるし
正しく使えばみんなをハッピーにしてくれる • TQM(Total Quality Management: ⽇本的な総合的品質管理)では 多くのマインドセットが重視されている ▪ 根本原因分析や改善活動に効いてきそうなものだけピックアップして かつデフォルメしてお伝えします 21
根本原因分析と改善に必要なマインドセット 1. PDCAとSDCA ▪ 改善サイクルPDCAと標準化サイクルSDCAとを交互に回して がんばらなくても改善後のパフォーマンスを出せるようにしていく • StandardizeのS 2. ディタッチメント
▪ 成果物/結果とそれを⽣んだ⼈とを「分離」して扱う • ✖ 私の運動神経が悪いから⽔たまりで滑って転んだんです • ✖ 私がぼーっとしてるのが悪いんです • ✖ お前は普段からぼーっとしてるからミスを⾒逃すんだ 3. 5ゲン主義 ▪ 現場‧現物‧現実‧原理‧原則 ▪ 具体例から始めて机上の空論化を防げ でもその後は抽象化して横展開可能なナレッジに昇華させろ • これが⾔えないと卒業できない⼤学研究室があったとかなかったとか…… 22 引⽤元: PDCAサイクル とは?
「良い根本原因分析」の三種の神器 1. 誤解されがちな なぜなぜ分析 ▪ パワハラの道具ではないし回数制限も存在しない ▪ 無意味なルート‧深度不⾜‧哲学化といったアンチパターンに気を付けよう 2. ⾒落とされがちな
⽔平分析 ▪ 「他には?」を考えて根本原因分析の網羅性を上げよう ▪ 垂直分析と⽔平分析の併⽤時には モデリングした⽅が頭の中が整理される 3. 意外と⼤事な マインドセット ▪ PDCAとSDCA‧ディタッチメント‧5ゲン主義 23
24 おまけ -⾊んなPDCA- 引⽤元: ‧左 https://x.com/hpeo_it/ status/18167245195555 96687/photo/1 ‧右 https://x.com/nhk_net
history/status/1120217 791007563778/photo/1