失敗学
https://gyazo.com/2f0ccf23f6fd507ba6a2750e9ec83d45
https://gyazo.com/41563a710b36f5a1f24e85626dcef755
参考文献
失敗とは
人間が関わってひとつの行為を行ったとき、
はじめに定めた目標を達成できないこと
望ましくない、予期せぬ結果が生じること
工学や複雑系科学の用語が分かる人向けのまとめ
なんらかの目標のために一体となって働く組織やチームは、人間を構成要素とした「システム」である システムは、生み出した結果を再入力してフィードバックさせなければ、適応的な変化（学習・成長）ができない このことを無視した適切なフィードバック機構のない組織の存在が、悲惨な失敗が繰り返されるひとつの大きな原因である
失敗に対する基本的な姿勢
失敗は学習し成長するチャンスである
失敗が起きてしまった際、失敗から何らかの教訓を探り出すことが一番誠実な態度である
失敗を個人的な問題に帰してはならない
人間のやる気や熱意や誠意や根性や注意力や判断力に頼っても失敗が改善されることはない
https://gyazo.com/5a709284ae0a763bbd022546b1404629
人間という生物の限界や欠陥を想定していない、組織の枠組みや仕組みが悪いと考えるべきである
失敗情報の収集
失敗という事象に関する情報の特徴
失敗情報は人に伝わりにくい
失敗情報は伝達されていくなかで減衰していく
失敗情報は隠れたがる
失敗情報は単純化したがる
組織には、普段から小さなミスや失敗を積極的に報告し共有する文化が必要不可欠
失敗が起こった経緯と状況について日常的なデータ収集を行う習慣を持っている必要がある
失敗が起こることを前提として認めて様々なデータを測定し記録しておく
まずはノートからでもできる
どんなミスをしたのか
なぜミスが起きたのか
ミスを防ぐためにはどんな対策が考えられるか
極端だが理想的な例
鉄道の運転状況記録装置
交通事故自動記録装置
交差点等に設置されている事故を記録するための監視カメラ
組織（チーム）の上下関係や、非難を恐れる組織文化によって隠蔽が起きがち
匿名で報告できるようにする
部下に上司の間違いを指摘する権限を与える
間違いを積極的に報告・指摘するスタッフを、組織が守ると保障する
失敗の主な原因
無知
不注意
手順の不順守
誤判断
調査・検討の不足
制約条件の変化
企画不良
価値観不良
組織運営不良
未知
失敗の原因調査と改善
深刻な失敗が発生した際には、調査に関して充分な権限を持つ原因究明の第三者組織をつくる必要がある
調査メンバーには、失敗原因の分析に関する専門知識が必要となる
SHELモデル
失敗の経緯に関するあらゆる証拠を徹底的に調査する
証言を集める
証言をしても組織内で不利な立場にならないという保障が必要
証言をしても法的に不利にならないという保障が必要
究明された原因を未然に防ぐための施策を考案し実施する
教訓は可能な限りわかりやすく要点をまとめてある必要がある
教訓は可能な限り多くの人に伝わるように公開される必要がある
マシンフロンティア
人間、機械、コンピューターなどが一体となって働いている極めて複雑なシステム＝マシンフロンティア
巨大なシステムは、常にいくつかは不調がある
巨大なシステムは、日々なんらかのトラブルを起こしている
普段は不調やトラブルはシステムの冗長性のなかに抑えられているが、一つのミスが別のミスに繋がる連鎖反応を起こすと、問題がシステム全体へと波及し、制御不能に陥る ミスの連鎖を断ち切るためには、ニアミス情報の積極的な共有が重要 マシン内部の詳細な状態が人間から把握できなくなってしまうと、制御不能な状態から回復することが極めて困難になる
多重に冗長化された単純明快な計器が必要
計器は最悪の異常事態が起こる事を前提に設計されていなければならない
「実際には330℃になっているのに140℃までしか表示されない温度計」のような計器で大惨事が起こる
温度計の設計不良によって発生した事故
スリーマイル島原発事故
アポロ１３号酸素タンク爆発事故
「最適化」vs「満足化」
満足化：計器の不具合などで情報が完全に揃わない中でも、実行可能な即効性のある解決策を探る
失敗や欠陥を前提とした厳しい安全訓練が重要になる
複雑なシステムの故障や事故では、複数の問題が同時に噴出することがとても多い
訓練も、想定しうる最悪の事態が起きる前提でやるべき
非常時に適切な対応をするためには、自分の担当分野以外のことも知っておかなくてはならない
失敗を前提とした学習・成長方法
そもそも人間は自分の失敗やミスを素直に認められないという心理的な傾向がある
矛盾する認知を抱えた際に、自身の認知を歪めたり、態度や行動を変更することで解消しようとしてしまう
仮説や信念を指示する事実ばかり集めてしまい、反証する事実を集めようとしない、無視してしまう
明らかに仮説と反する異常な事実が現れても、最初にこれと思い込んだ考えから思考を切り替えることが難しい
→成長するためには、積極的に失敗を試みるしかない
「暗闇の中でのゴルフ」
ボールがどこに飛んでいったかわからないままでは、いくら練習しても上達するわけがない
どんな仮説でもいいというわけではない。仮説には反証可能性が必要である カール・ポパー「どのような手段によっても間違っている事を示す方法が無い仮説は科学ではない」
適切な方法で検証されていない仮説は正しいか正しくないか（効果があるのかないのか）未知である
ただ「何かを試してみる」→「結果どうなるか見る」だけでは充分な仮説検証とは言えない
何もしなくても変化が起きる可能性を考慮しなければならない
ある仮説に従って、操作群（介入群）と非操作群（対照群）を作って、結果にどのような影響が出るかを観察し検証する
https://gyazo.com/a1fd9d06520a811ba19dd7af160a69a4
盲検法
参加者に自分が介入群と対照群どちらであるかを分からないようにする検証手法
参加者に加えて、研究者自身にも誰が介入群で誰が対照群なのかを分からないようにする検証手法
「異常があれば生産ラインを止める」
「その場ですぐにミスの原因を調べる」
「二度と同じミスが起きないような改善を行う」
製造工程の品質を改善するための方法
ものづくりをしていれば異常（不良ができる、機械の故障、作業ミスなど）が起きるのは当たり前
「異常が何もない」ということはむしろ「異常を隠している」のではないかと考える
1つの大きな目標を達成するために100個、1000個の小さな改善を積み重ねる
https://gyazo.com/9a0fe6d9b64ad940fc0baca256b9ad2f
「構築」「計測」「学習」のプロセスを短期間で繰り返す
構築
顧客層を想定して仮説を立ててビジネスアイデアを練り、実用最小限の製品(MVP: Minimum Viable Product)をつくる
計測
MVPを顧客層の中でも特に流行に敏感な一部の人々へ見せて、反応を調べる
客観的な指標があると良い
学習
反応をもとにMVPを改善する
最初に立てた仮説が誤りだと気づいた場合、方針転換をして構築の段階からMVPを作り直す
失敗するテストを書く
テストに通るような最小限のコードを書く
コードの重複を無くすなど、きれいに整える
整えた後のコードもテストに通ることを確認する
事前検死
プロジェクトの開始前に、プロジェクトが失敗したと仮定して、「なぜうまくいかなかったのか？」を事前に検証する
プロジェクトが失敗したつもりで、メンバーが思いつく失敗の理由を挙げる
失敗の理由が思いつかなくなるまで行う
リストアップされた理由に対処するための改善を行う
社会を発展させた三大事故
第三者組織による報告書が公開されている重大な事故
JAXAによる日本語版
非公式日本語版
失敗まんだら
https://gyazo.com/81a28428173ad830d323d9a14446c045
https://gyazo.com/e39882b9a3d25d341baa0a693eb0073b
https://gyazo.com/02dfdf11b0dcc177d2161ef9fb0cd362
失敗に関する情報源
失敗学会
参考文献