STORY SO FAR
前回「NASAは事故後に何を変えたのか｜SRB再設計・安全改革・STS-26復帰」で確認した論点を受け、この回ではチャレンジャー事故は何を残したのか ｜ SYSTEM事故として読む技術と組織の教訓の後に何が変わり、何が残ったのか。を扱う。
1986年1月28日、スペースシャトル・チャレンジャーは打上げから約73秒で失われた。[4]
事故原因を一文にすれば、
「右側Solid Rocket Motorのfield jointでOリングsealが機能せず、高温gasが漏れた」
となる。
これは正しい。
しかし、これだけで事故を理解したことにはならない。
なぜなら事故以前から、field jointの問題は完全に未知ではなかったからである。
joint rotationは知られていた。
secondary O-ringが完全なredundancyではないことも知られていた。
Oリングerosionは複数回起きていた。
blow-byも確認されていた。
field jointはCriticality 1へ分類されていた。
低温への懸念も事故前夜に明確に示された。
それでもflightは続いた。
そして1月28日、過去のflight experienceよりはるかに寒い条件でChallengerは打ち上げられた。
この事実を含めると、事故の問いは変わる。
「なぜOリングが壊れたのか」
だけではない。
「なぜ、壊れる可能性を示す情報を持ったsystemが、flightを止められなかったのか」
になる。
Rogers Commissionの調査も、技術原因から始まり、打上げ判断、communication、management、安全組織、flight rateへ広がった。
NASA自身も事故後、Solid Rocket Motor jointだけでなく、Criticality Review、Safety Organization、management 構造、communications、crew escape、maintenance、flight rateまで改革対象にした。
つまり事故調査と再発防止の両方が、
Challengerは単一部品事故ではない
ことを示している。
CASE052の最終回では、8本の記事で追ってきた事実を、SYSTEM事故という一つの構造へまとめる。
先に結論｜Challengerから残った最大の教訓
Challenger事故から残った最大の教訓は、
「技術的に危険なものは、誰かが知っているだけでは安全にならない」
ということである。
危険を示すdataが存在する。
engineerが懸念を持つ。
報告書が作られる。
Criticality 1と分類される。
会議が開かれる。
それでも、それらが適切な判断基準へ変換されなければsystemは止まらない。
安全には少なくとも、
正しいhardware
正しいverification
異常trendの可視化
dissentを保存するinformation flow
独立したsafety authority
riskを上位へescalateするrule
system capabilityに合ったoperation
が同時に必要である。
どれか一つがあるだけでは足りない。
Challengerでは、複数の防護層が存在していた。
しかしそれらは十分独立していなかった。
hardware側ではprimaryとsecondary O-ringが同じjoint rotationと低温条件へ依存していた。
organization側ではEngineering、Management、FRR、Safetyが存在しながら、同じrisk acceptanceとinformation compressionの影響を受けた。
二本あることと、冗長であることは同じではない。
複数部署があることと、独立した防護層があることも同じではない。
これがChallengerをSYSTEM事故として読むときの中心になる。
第一の教訓｜「直接原因」と「事故原因」は分けて考える
事故調査ではdirect causeが必要である。
どこが最初に壊れたのか。
何がvehicle lossを開始したのか。
ChallengerについてRogers Commissionの結論は明確だった。
右Solid Rocket Motorの下部field jointでsealが破壊され、hot gasが外へ漏れた。
この物理原因は曖昧にしてはいけない。
一方で、
「direct causeが分かった」
ことと、
「事故原因をすべて理解した」
ことは同じではない。
たとえば工場設備で、shaftが破断して機械が停止したとする。
直接原因はshaft fracture。
しかし調べるべきことは、
なぜ疲労亀裂が発生したか
なぜinspectionで見つからなかったか
過去に振動上昇はなかったか
alarm thresholdは適切だったか
異常報告は誰へ届いたか
停止判断はなぜ行われなかったか
まである。
Challengerでも同じだった。
Oリングを物理原因として確定した後、Commissionは、
打上げ判断
joint history
management
safety organization
へ調査を広げた。
direct causeを消すのではなく、その外側へcause hierarchyを拡張したのである。
第二の教訓｜未知より「既知だが許容された異常」の方が危険なことがある
重大事故は、誰も想像していなかった未知failureから起きるとは限らない。
ChallengerのOリングerosionは、事故当日に初めて現れた現象ではなかった。
過去flightで繰り返し観測されていた。
blow-byもあった。
それでも任務は成功した。
ここでorganizationは難しい判断を迫られる。
異常があるたびにsystemを全面停止すれば、complex systemは運用できない。
現実には、
anomalyを評価する
marginを計算する
testする
riskをacceptする
運用を続ける
必要がある。
問題は、過去の成功がrisk評価を歪めるときである。
「異常があったが壊れなかった」
という事実は、
「その異常は安全だった」
ことを自動的には意味しない。
Rogers Commissionは、NASAとThiokolがOリングerosionとblow-byを「unavoidable and an acceptable flight risk」として受容するようになったと結論づけた。さらに、前回問題なく飛べたことを次回のrisk低下と見る姿勢を批判した。
成功は安全性の証拠になり得る。
しかしnear missを含む成功を無条件に「安全実績」へ数えると危険である。
第三の教訓｜「データがない」は安全の証明ではない
事故前夜のteleconferenceで問題になったのは、低温とOリング性能のdataだった。
Thiokol engineeringは、過去に経験したOリング温度より低い領域へ入ることを危険視した。
NASA側は、53°F未満でfailureするという明確なdataが十分ではないと問い返した。
ここで判断の方向が変わる。
安全であることが確認できていない。
だから止める。
という考え方と、
危険であることが証明できていない。
だから進める。
という考え方は正反対である。
high-risk systemで重要なのは、
「未知領域へ拡張するとき、立証責任をどちら側へ置くか」
である。
Challengerでは、この立証責任が事故前夜の議論の中で反転した。
不確実性は中立ではない。
systemのcriticalityが高ければ、不確実性そのものをriskとして扱う必要がある。
第四の教訓｜正式な分類があっても、意味が組織内で保持されなければ機能しない
field jointはCriticality 1だった。
単一failureがcrew、vehicle、任務 lossへつながり得る。
これは非常に強い分類である。
しかしCASE052-06で見たとおり、その後のreview資料にはsecondary O-ringをredundant sealのように扱う表現が残っていた。
正式databaseではCriticality 1。
presentationではredundant。
この二つが共存すると、同じhardwareを見てもrisk perceptionが変わる。
重要なのはlabelの有無ではない。
Criticality 1なら、
どの会議でもCriticality 1として扱われるか
anomaly発生時に自動的に上位へ上がるか
waiverに誰が署名するか
flight constraintに変換されるか
解決前にcloseできないか
まで必要になる。
classificationは判断 behaviorへ変換されて初めて安全機能になる。
第五の教訓｜異論は「解決」するだけでなく「保存」しなければならない
Challenger事故前夜、Thiokolのcompany recommendationは変化した。
最初はNO GO。
その後、management caucus。
最終的にGO。
しかし一部engineersの反対は残った。
このとき上位NASA managementへ届いたのは、主に最終的なcompany positionだった。
「GO」という最終statusだけを見ると、
専門家が検討して問題を解決した
ように見える。
しかし履歴を含めれば、
重大なNO GOが出た
↓
dataの解釈を巡って議論
↓
management review
↓
GOへ変更
↓
一部technical dissentは残存
である。
同じGOでも意味が違う。
critical 判断では、
最終結論
だけでなく
反対理由
不確実性
推奨変更理由
未解決事項
を保存する必要がある。
「dissentが存在した」というmeta-data自体が安全情報になる。
NASAが事故後、FRRやMission Management Teamの記録、launch constraint、readiness certificationをformalizeしたのは、この問題への対応でもあった。
第六の教訓｜安全部門は「存在」ではなく「独立性」で評価する
Challenger以前にもNASAにはSafety, Reliability and Quality Assuranceが存在した。
問題は、存在していたかどうかではない。
1月27日のcritical teleconferenceに参加していたか。
Mission Management Teamに独立したsafety voiceがあったか。
program managementとは別のreporting lineからriskを上げられたか。
trend analysisを独立して行っていたか。
という実効性である。
事故後NASAは、Administratorへ直接報告書するSafety, Reliability, Maintainability and Quality Assurance組織を整備した。
これはorganization chartの変更に見える。
しかしsafety engineeringの観点では、independence designである。
設備で非常停止回路を通常PLCのsoftwareだけに依存させないのと同じように、organizational safety functionもproduction goalと完全に同一の判断 pathへ依存させない。
independent layerであることに意味がある。
第七の教訓｜trendは「一件ずつ見る」と消える
Oリングanomalyは記録されていた。
dataが完全になかったわけではない。
問題は、flightごとのissueとして閉じていたことである。
一件だけ見る。
erosionはこの程度。
marginあり。
close。
次flight。
またerosion。
marginあり。
close。
これを繰り返すと、各判断は合理的に見える。
しかし時系列で並べれば、
発生頻度が増えている
blow-byが出ている
低温側で悪化している
field joint anomalyが増えている
という別のpictureが見える。
Rogers Commissionは、Oリング問題について十分なtrend analysisが行われていなかったことを批判した。
重大事故のleading indicatorは、一件の大きなfailureではなく、小さなanomalyの分布変化として現れることがある。
だからtrend analysisはreportingとは別の機能である。
「全部記録してある」
だけでは安全ではない。
比較されなければ、dataはmemoryにならない。
第八の教訓｜冗長性は「数」ではなく「独立性」で判断する
field jointにはprimaryとsecondary O-ringがあった。
二本ある。
しかしjoint rotationが起きれば、二本とも同じgeometry changeの影響を受ける。
低温なら二本とも同じ環境条件を受ける。
primaryが失敗する条件がsecondaryの能力も弱くする。
だから完全独立のredundancyではなかった。
これはorganizational systemにもそのまま当てはまる。
Engineering review。
Management review。
Flight Readiness Review。
Safety review。
会議が四つある。
しかし、
同じdata summaryを見る
同じsuccess historyに影響される
同じschedule pressureを受ける
dissent historyが途中で失われる
なら、四層は独立していない。
multiple layersとindependent layersは違う。
安全設計では、
同時に壊れる共通原因は何か
を必ず考える必要がある。
第九の教訓｜「人間の判断」を減らす設計も必要
事故前夜、低温条件を巡って長い議論が行われた。
Oリングは何度になるか。
53°Fより低い意味は何か。
dataは十分か。
secondaryはsealするか。
最終的に人間の判断へ依存した。
事故後のSRB redesignでは、field joint heaterが追加された。
seal temperatureを75°F以上へ維持する設計だった。
これは象徴的である。
「寒い条件で飛んでも大丈夫かを毎回議論する」
のではなく、
「critical sealを安全なtemperature rangeへhardware側で維持する」
方向へ変えた。
安全hierarchyでは、administrative controlよりengineering controlの方が強い場合が多い。
procedureで人間へ注意させるより、危険条件そのものをdesignから排除する。
Challengerのredesignはその考え方を示している。
第十の教訓｜事故後の対策はfailure hierarchyと同じ階層に入れる
もし原因分析が、
Oリングが壊れた
で終われば、対策も
Oリングを強くする
で終わる。
しかしChallengerでは原因が複数階層にあった。
hardware：
joint rotationとseal failure。
verification：
flight-like conditionでの理解不足。
information：
anomaly trendが見えない。
判断：
NO GO履歴が上位へ十分届かない。
organization：
independent safetyが弱い。
operations：
flight rateがsystem capacityを圧迫する。
だから事故後のcorrective actionも複数階層へ入った。
capture featureとheater。
full-scale verification。
Criticality Review。
SRM&QA。
formal launch constraint。
FRR/MMT documentation。
maintenance/trend database。
flight rate見直し。
Rogers Commissionは9項目のrecommendationを出し、NASAのimplementation 報告書も技術変更だけでなく、procedure、communication、organizationの変更を並列に扱っている。
事故原因の深さと、corrective actionの深さを揃える。
これが再発防止の基本になる。
Challengerを「悪い管理職の事故」にしない
事故を理解しやすくするためには、人物を中心にした物語は強い。
engineerが反対した。
managerがGOへ変えた。
その結果事故が起きた。
この構図には事実が含まれている。
しかし、シリーズ全体をそこへ縮めると問題がある。
事故以前のerosion acceptanceは、一夜のcaucusだけでは説明できない。
Criticality 1の扱いも説明できない。
FRRで問題がconstraintにならなかったことも説明できない。
trend analysis不足も説明できない。
safety organizationの独立性も説明できない。
flight rateとresource pressureも説明できない。
つまり、
悪い人が間違えた
だけではSYSTEM failureの再発を防げない。
同じ構造が残れば、人を替えても似た判断が生まれる可能性がある。
重要なのは、
善悪
ではなく
判断 architecture
を見ることである。
ただし「SYSTEM事故」は個人責任を消す言葉でもない
逆方向の誤解にも注意が必要である。
「SYSTEM事故だから誰も悪くない」
という意味ではない。
個々の判断は存在する。
誰がrecommendationを変更したか。
誰がlaunch constraintを上げなかったか。
誰がinformationをforwardしなかったか。
それぞれ検証できる。
SYSTEM analysisは個人行動を消すためではなく、
なぜその行動がsystem内で成立し、
なぜ別の防護層が止めなかったか
まで見る方法である。
個人責任とsystem causeは排他的ではない。
「normalization of deviance」をどう使うべきか
Challengerとともによく語られる言葉が、normalization of devianceである。
これはRogers Commission Reportの公式用語ではない。
社会学者Diane Vaughanが1996年の『The Challenger Launch Decision』で体系化した後年の分析枠組みである。NASAのbibliographyも同書をChallenger 打上げ判断とhigh-technology riskを分析した主要研究として挙げている。
この概念をChallengerへ使う意味は、
「NASAの人々が規則違反を平然と繰り返した」
と単純化することではない。
本来deviationだった現象が、
analysisされる
↓
任務 successする
↓
acceptableと判断される
↓
次のbaselineになる
という過程で、organization内部の「正常」の範囲が変わることにある。
Rogers Commissionの表現に戻れば、
erosion and blow-by were accepted as unavoidable and an acceptable flight risk
というfindingが、後年のVaughanの分析と接続する。
重要なのは用語ではなく、異常が正常へ再分類されるmechanismを見ることである。
Challengerの教訓は「安全文化」だけでは少し抽象的すぎる
NASAは現在もChallengerをSafety Cultureの重要事例として扱っている。NASAのSafety and Mission Assurance資料はRogers Commissionを重要incidentとして位置づけ、事故をtechnical failureだけではない安全上の学習材料として残している。
ただし、
「安全文化を大切にしよう」
だけでは実務へ落ちない。
具体化すると、
Criticality 1 issueは自動escalationする。
dissentを記録する。
NO GOからGOへの変更には根拠と承認者を残す。
trend reviewを定期実施する。
safety組織をproduction lineから独立させる。
experience envelope外では追加verificationを要求する。
success without catastropheをsafe 証拠と同一視しない。
unknown conditionをGO根拠にしない。
こうしたruleになる。
cultureは、行動仕様へ変換されて初めてsystemになる。
成功実績は「安全marginを使っていない」証拠ではない
ChallengerまでShuttleは24 missionsを完了していた。
事故を起こさなかった。
これは重要な実績である。
しかし、その中にはOリングerosionやblow-byがあった。
つまり結果として任務 successでも、内部ではsafety marginを消費していたflightが存在した。
ここから一般化できる教訓がある。
成功した。
だから正常だった。
とは限らない。
systemが成功するには、
十分marginがあって成功する
場合と、
marginを大きく消費しながら偶然thresholdを越えず成功する
場合がある。
outputだけを見れば両方SUCCESSである。
安全管理では、その違いを見る必要がある。
near miss。
degraded mode。
temporary recovery。
unexpected intervention。
これらも成功flightの中へ隠れる。
「事故がなかった期間」を安全KPIにしすぎない
工場でも、
無災害○○日
停止事故ゼロ
重大クレームゼロ
は分かりやすいKPIである。
しかしlagging indicatorだけを見るとChallenger型のriskを見落とす。
必要なのはleading indicatorである。
anomaly count。
waiver count。
temporary fix duration。
Criticality 1 open issue。
dissent count。
inspection escape。
repeated alarm。
trend slope。
経験範囲外operation。
Challengerでは事故前にleading indicatorが存在した。
catastrophic lossというlagging indicatorはゼロだった。
そのためsuccess historyが強く見えた。
SYSTEM事故を防ぐには、「事故が起きたか」より前のsignalを管理する必要がある。
Challengerは「宇宙開発だから特別」ではない
Space Shuttleは極端にcomplexなsystemだった。
巨大なenergy。
極低温propellant。
solid rocket motor。
supersonic flight。
human crew。
確かに特殊である。
しかし事故構造は、一般のengineering systemにも現れる。
既知anomalyがある。
temporary assessmentでoperationを続ける。
過去に問題なかった。
formal classificationはcriticalだが、現場の感覚ではmanageableになる。
dataはあるがtrend化されない。
maker engineerは懸念する。
managementはproduction continuityも考える。
最終statusだけが上位へ伝わる。
safety reviewは形式化する。
これは宇宙開発だけの構造ではない。
化学plant。
鉄道。
航空。
発電所。
医療機器。
industrial automation。
software infrastructure。
どこでも起こり得る。
だからChallengerは40年以上経っても教材として残る。
制御設備へ置き換えると何が見えるか
例えば安全扉のinterlockで、過去に一度接点chatterが出たとする。
machineは停止した。
調べる。
再現しない。
運転再開。
次に別lineで似たchatter。
また停止。
しかし事故なし。
「接点は時々chatterするが、PLC logicが吸収する」
という理解になる。
その後、
PLC filter timeを延ばす。
operator procedureを追加する。
maintenance checkを増やす。
運転は続く。
しかし本来のrequirementが、
door unsafe状態では必ずsafety output OFF
なら、問うべきことは違う。
なぜchatterするのか。
safety contact自体の故障形態は。
standard requirementを満たしているか。
同じcommon causeでsecondary channelも失わないか。
bypass historyは。
trendは。
誰が運転継続をapproveしたか。
Challengerの教訓は、この「requirementへ戻る」姿勢である。
大事故後のredesignで最も重要なのは「同じ問いを次回しなくてよくする」こと
事故前夜、NASAとThiokolは低温とOリングについて議論した。
このtemperatureで大丈夫か。
dataは足りるか。
secondaryは働くか。
約2年半後、Return to Flight用SRBにはfield-joint heaterが付いた。
seal temperatureをdesign-controlled rangeへ持っていく。
ここにcorrective actionの強さがある。
次のlaunchで、
「今夜は寒いが、このOリングは大丈夫か」
という同じ議論を繰り返さなくてよい。
procedure improvementは重要である。
しかし最も強い再発防止の一つは、
事故を生んだ判断そのものを不要にするdesign
である。
NASAは本当に事故から学んだのか
この問いには単純なYES/NOでは答えられない。
NASAは事故後、実際に大規模な変更を行った。
SRM redesign。
full-scale certification。
management restructure。
independent safety organization。
Criticality review。
communication reform。
crew escape。
maintenance/trend system。
flight rate見直し。
そしてSTS-26は成功した。
NASA History Officeは、事故調査がtechnical causeからorganizationと判断-makingへ広がり、Return to Flightでは安全上の勧告とorganizational restructuringが大きな課題になったと記録している。
一方で、
事故後に改革した
という事実と、
organizationが永久に同じfailure patternから免疫を得た
ことは同じではない。
過程は維持しなければ劣化する。
独立性も維持しなければ弱くなる。
successが積み上がれば、再びrisk perceptionは変化する。
だから「学んだか」は、一度の制度変更ではなく、日々の判断 behaviorで評価される。
Challengerのlegacyは事故そのものだけではない
NASAのChallenger remembrance資料は、事故のlegacyとしてRogers Commissionがtechnical causeだけでなくsystemic organizational and cultural elementsを明らかにしたことを挙げている。
さらにReturn to Flightでは、200を超えるShuttle systemの変更、SRB field joint redesign、crew escape改善、安全・management構造の強化が行われた。
つまりChallengerが残したものは、
悲劇の記憶
だけではない。
事故調査の方法。
technical dissentの扱い。
criticalityの意味。
risk acceptanceの危険。
trend analysis。
independent safety。
verification。
Return to Flightの考え方。
これらもlegacyである。
SERIES SYNTHESIS｜8本を一つの事故構造へ戻す
CASE052-01では、Challenger事故の全体像を見た。
CASE052-02では、低温への懸念がありながらlaunch recommendationがNO GOからGOへ変わる判断 過程を追った。
CASE052-03では、field jointがdynamic systemであり、低温・joint rotation・pressure actuationの時間関係によってOリングsealが失敗するmechanismを見た。
CASE052-04では、0.678秒の煙から58.788秒のplume、External Tank損傷、73秒台のvehicle breakupまでを追った。[4]
CASE052-05では、海底から回収されたright SRB hardwareが映像上のfailure locationと一致し、physical causeを物証で裏付けた。
CASE052-06では、Rogers Commissionがerosion/blow-byの受容、communication、Safety Organization、trend analysis、risk perceptionを問題にしたことを見た。
CASE052-07では、NASAがcapture feature、heater、full-scale verification、SRM&QA、Criticality Review、formal launch constraintなどを実装してSTS-26へ戻った過程を追った。
八つを一つにすると、事故は次のchainになる。
design sensitivity
↓
known anomaly
↓
successful flights
↓
risk acceptance
↓
trend visibility不足
↓
experience envelope外の低温
↓
engineering NO GO
↓
recommendation reversal
↓
dissent historyのattenuation
↓
launch
↓
field joint seal failure
↓
hot-gas leak
↓
External Tank failure
↓
vehicle breakup
↓
physical investigation
↓
system-level reform
このchainのどこか一つだけを切り取ると、Challengerの意味は小さくなる。
全体をつなぐことで、SYSTEM事故になる。
検証ポイント｜ChallengerをSYSTEM事故として読むための固定事項
| 層 | 固定する事実 |
|---|---|
| Physical cause | right SRM aft field joint pressure seal failure |
| Environmental condition | launchはShuttle史上それまでより著しく低いtemperature condition |
| Known precursor | O-ring erosion / blow-byは事故以前から複数回観測 |
| Criticality | field jointは事故以前にCriticality 1 |
| Decision | Thiokol initial NO GO → management review → company GO、一部engineering dissent残存 |
| Information | 上位decisionmakerはinitial no-launch recommendationと継続dissentを十分把握せず |
| Safety | Jan.27 teleconferenceにSR&QA representative不在 |
| Trend | CommissionはO-ring anomalyのtrend analysis不足を指摘 |
| Commission finding | erosion/blow-byがacceptable flight riskとして受容された |
| Later scholarship | “normalization of deviance”はDiane Vaughanによる後年の分析概念 |
| Reform | SRM joint redesignだけでなくmanagement / criticality / safety / communication / flight rate / maintenanceを改革 |
| Return to Flight | STS-26、Discovery、1988年9月29日 |
| Legacy | technical failureとorganizational 判断を分離せず、多層の防護systemとして安全を設計すること |
最後に｜「壊れた部品」より「止められなかったsystem」を見る
事故が起きた後、壊れた部品は見つけやすい。
焼けたjoint。
破断したshaft。
溶着したcontact。
ruptureしたpipe。
error log。
そこから調査は始まる。
しかしSYSTEM事故で本当に難しいのは、その一歩前である。
異常はいつ最初に見えていたのか。
誰が知っていたのか。
どの会議で扱われたのか。
なぜ許容されたのか。
過去の成功はrisk評価へどう使われたのか。
反対意見は残ったのか。
独立したsafety layerは働いたのか。
同じ故障形態を受ける「見かけの冗長性」はなかったか。
そして、次回同じ判断をしなくて済むようdesignを変えられるか。
Challengerの右SRB aft field jointは、事故後にredesignされた。
NASAのmanagementとsafety 過程も変更された。
Discoveryは1988年9月29日にReturn to Flightした。[5]
それでもChallengerが今も研究される理由は、
一つのOリングが壊れた事故だったから
ではない。
危険を示す情報が存在し、複数の専門家と複数のreview systemが存在していても、organization全体として事故を止められないことがある。
その事実を、極めて具体的なhardware failureとともに残したからである。
安全とは、
部品が壊れないこと
だけではない。
壊れる可能性を示す弱いsignalを拾い、
それを消さず、
必要な人へ届け、
不確実なら止め、
必要なら設計そのものを変える。
そこまで含めたsystemの能力である。
チャレンジャー事故が残した最も重要な問いは、今も変わらない。
「異常を知っているsystemは、本当にその異常で止まれるように設計されているか。」
FACT CHECK｜出典・参考資料
- [1] Presidential Commission on the Space Shuttle Challenger Accident, Report, Chapters IV–VII
- [2] Presidential Commission on the Space Shuttle Challenger Accident, Recommendations
- [3] Presidential Commission on the Space Shuttle Challenger Accident, Volume II, Appendices F and H
- [4] NASA, Implementation of the Recommendations of the Presidential Commission on the Space Shuttle Challenger Accident
- [5] NASA History, Return to Flight after Challenger
- [6] NASA, Remembering Challenger and Her Crew
- [7] NASA Safety and Mission Assurance, Safety Culture / Significant Incidents
- [8] Diane Vaughan, The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, 1996 — later scholarly analysis, not Rogers Commission terminology
チャレンジャー事故｜なぜ打ち上げは止められなかったのか 第8回 全8回 全8回を見る
- 01 チャレンジャー事故｜チャレンジャー号事故とは？｜STS-51Lはなぜ73秒で失われたのか
- 02 チャレンジャー事故｜なぜチャレンジャーは寒波の朝に打ち上げられたのか｜延期・低温・前夜の電話会議
- 03 チャレンジャー事故｜Oリングはなぜ密封に失敗したのか｜固体ロケットブースター継手の構造
- 04 チャレンジャー事故｜打上げ後73秒に何が起きたのか｜映像とテレメトリで追う機体崩壊
- 05 チャレンジャー事故｜海底の残骸は何を語ったのか｜捜索・回収・復元で事故原因を確かめる
- 06 チャレンジャー事故｜ロジャース委員会は何を明らかにしたのか｜技術事故から組織事故へ
- 07 チャレンジャー事故｜NASAは事故後に何を変えたのか｜SRB再設計・安全改革・STS-26復帰
- 08 チャレンジャー事故は何を残したのか｜SYSTEM事故として読む技術と組織の教訓