STORY SO FAR
前回「海底の残骸は何を語ったのか｜捜索・回収・復元で事故原因を確かめる」で確認した論点を受け、この回ではロジャース委員会は何を明らかにしたのか ｜ 技術事故から組織事故へはどのような仕組みで成立・進行したのか。を扱う。
チャレンジャー事故の物理的な原因は、右側Solid Rocket Motorのaft field jointにおけるpressure seal failureだった。
そこまでは、CASE052-03からCASE052-05で見てきた。
低温下でOリングの応答が遅れる。
joint rotationによってseal gapが広がる。
primary O-ringが十分に密封できず、高温gasが外へ漏れる。
約59秒後にplumeが再び顕在化し、External Tankを損傷する。
73秒台にvehicle全体が構造破壊へ進む。
そして海底から回収されたright SRB hardwareには、そのfailure scenarioと一致するburn-throughが残っていた。
物理的なcauseだけなら、ここで事故調査を終えることもできる。
「Oリングとfield jointの設計が悪かった。新しいjointへ変更すればよい」
そう結論づけることは可能だった。
しかしRogers Commissionは、そこで止まらなかった。
なぜなら事故以前から、joint rotationは知られていた。
Oリングerosionも知られていた。
blow-byも起きていた。
secondary O-ringが完全なredundancyではないことも認識され、field jointはCriticality 1へ変更されていた。
それでもShuttleは飛び続けた。
さらに事故前夜には、低温条件での打上げに対してMorton Thiokolの技術者から明確な懸念が出ていた。
それでも最終的にlaunch recommendationはGOへ変更され、その途中経過は主要な上位decisionmakerへ十分に伝わらなかった。
そこでCommissionが問うたのは、
「何が壊れたのか」
から、
「なぜ、壊れる可能性を示す情報が存在したのに、systemは飛行を止めなかったのか」
だった。
この問いに入った時点で、チャレンジャー事故は単なるhardware failureではなくなる。
設計。
試験。
異常処置。
Flight Readiness Review。
contractorとNASAの関係。
problem reporting。
safety organization。
flight rate。
management communication。
それらを含む組織システム全体が調査対象になる。
CASE052-06では、Rogers Commissionが明らかにした「技術事故の背後の事故」を追う。
先に結論｜なぜ「組織事故」と呼べるのか
チャレンジャーを組織事故として読む理由は、事故原因が「管理職が技術者を無視したから」という一点にあるのではない。
もっと広い。
第一に、危険なhardware conditionが事故以前から複数回観測されていた。
第二に、その異常は最初から正常とみなされたわけではなく、解析・試験・reviewを経る中で「飛行可能なrisk」として扱われるようになった。
第三に、field jointはCriticality 1、つまり単一故障でvehicleとcrewを失い得るitemだったのに、実際のFlight Readiness Review資料ではsecondary O-ringをあたかもredundant sealのように扱う説明が残った。
第四に、Oリングerosionやblow-byのtrendは、system-level safety functionとして十分に集約・分析されなかった。
第五に、1月27日のteleconferenceには、独立したSafety, Reliability and Quality Assuranceの代表が参加していなかった。
第六に、前夜のNO GO recommendationと継続するengineering oppositionが、最終的な上位decisionmakerへ完全な形では届かなかった。
第七に、NASA内部では高いflight rateへの圧力が増す一方、安全・信頼性・品質保証部門の能力は弱くなっていた。
つまり、事故を止めるはずだった複数の防護層が同じ方向へ弱くなっていた。
hardwareに異常が出る。
engineeringが解析する。
program managementがreviewする。
safety organizationが独立して監視する。
Flight Readiness Reviewで上位へ上げる。
必要ならlaunch constraintを維持する。
本来なら、このどこかで止まるはずだった。
しかし51-Lでは、各段階が「次の段階が止める」状態ではなく、異常を飛行可能なものとして処理する方向へ動いた。
それがSYSTEM事故としてのChallengerである。
Commissionは事故原因を二層に分けた
Rogers Commission Reportの構成自体が、この事故をどう見たかを示している。
Chapter IVは物理的なCause of the Accident。
そこではright Solid Rocket Motor aft field jointのseal failureを原因として特定した。
Chapter VはThe Contributing Cause of the Accident。
ここでは打上げ判断とcommunication failureを扱う。
Chapter VIはAn Accident Rooted in History。
ここではjoint design、testing、O-ring anomalyの過去、NASAとThiokolが問題へどう対応したかを遡る。
Chapter VIIはThe Silent Safety Program。
ここではSafety, Reliability and Quality Assurance組織が、なぜ安全上のcheck and balanceとして十分に機能しなかったかを扱う。
つまりCommission自身が、
physical cause
↓
判断-making cause
↓
historical/organizational cause
↓
safety oversight failure
という複数層で事故を説明した。
「Oリングが原因だった」と「組織が原因だった」は競合する説明ではない。
前者はfailure mechanism。
後者は、そのfailure mechanismが事故に至るまで放置・許容された理由を説明する。
問題は設計段階から始まっていた
Chapter VIの結論は厳しい。
Commissionは、Challenger事故のgenesis、つまり発端はright Solid Rocket Motor jointのfailureそのものより前にあり、joint designに関する判断と、試験で得られた事実へNASAとThiokolが十分対応しなかったことに始まるとした。
field jointでは、pressureによってtangとclevisのgapが広がるjoint rotationが起きる。
その影響でsecondary O-ringのredundancyが保証できないことは、事故以前から分かっていた。
それでもjoint designは使用され続けた。
ここで重要なのは、
「設計者が危険性をまったく知らなかった」
のではない点である。
知識は段階的に増えていた。
しかし、新しい知識が得られるたびにdesign baselineそのものを停止・再構築するのではなく、
解析する
↓
marginを探す
↓
waiverやreviewを通す
↓
飛行を続ける
という方向へsystemが適応していった。
この適応自体が直ちに不正だったわけではない。
complex engineering systemでは、試験や運用から得られたanomalyを評価し、許容可能かを判断することは日常的に必要である。
問題は、その許容判断が繰り返される中で、元のdesign requirementと実際のriskの差が見えにくくなったことである。
erosionは最初から「正常」ではなかった
Oリングerosionが最初に見つかった時、それはdesign expectationからのdeviationだった。
本来、Oリングは燃焼gasをjoint外へ漏らさないsealである。
erosionやsoot blow-byは、「完全に期待どおりのseal behaviorではない」ことを示す。
しかし飛行は成功して帰ってきた。
そこでengineeringは、
どれだけerosionしたのか
どれだけmaterialが残っているのか
testでどこまでsealできたのか
secondary O-ringは機能するか
を評価した。
その結果、
「erosionは発生しているが、観測された範囲ならseal capabilityにはmarginがある」
という説明が作られていった。
Appendix Hには、Oリングの「maximum possible erosion」を解析し、testでそれ以上のsimulated erosionでも高圧をsealできたためacceptableとする考え方が示されている。
問題は、その評価の前提にある。
CASE052-03で見たように、erosion depthのmarginは、
Oリングが適切にseatしたあとに表面が削られる
という故障形態には意味がある。
しかしblow-byのように、
Oリングが十分にseatする前にhot gasが通過する
場合には、同じmargin logicでは安全性を説明できない。
つまり、異常の種類が変化しても、過去の「erosionは許容可能」という説明が残り続けた。
「前回飛べた」は安全証明ではない
CommissionがChapter VIで最も強く批判した部分の一つが、過去の成功の使い方だった。
異常を伴って飛行した。
しかし事故にはならなかった。
その経験を、
「異常があっても今回は偶然助かった」
と読むのか、
「異常があっても飛べることが実証された」
と読むのか。
この二つは正反対である。
FeynmanはCommission hearingの中で、この考え方をRussian rouletteに例えた。
前回triggerを引いて弾が出なかったからといって、次回のriskが下がるわけではない。
しかし組織運用では、successがrisk acceptanceの根拠になりやすい。
flight with erosion
↓
任務 success
↓
erosion is manageable
↓
next flight accepted
↓
another anomaly
↓
still no catastrophe
↓
acceptable range expands
という循環ができる。
Commissionは、NASAとThiokol managementがerosionとblow-byを「unavoidable and an acceptable flight risk」として受け入れるようになったと結論づけた。
ここで重要なのは、
「誰かが正式に『安全基準を下げよう』と決めた」
という話ではないことだ。
個々のreviewでは、それぞれtechnical rationaleが作られている。
だからsystem全体としてrisk toleranceが変化していても、一つ一つの判断は局所的には合理的に見える。
「normalization of deviance」という言葉はCommissionの言葉ではない
チャレンジャー事故を語るとき、「normalization of deviance」という言葉がよく使われる。
日本語では「逸脱の正常化」「逸脱の常態化」などと訳される。
ただし、これはRogers Commissionが1986年のReportで使った公式用語ではない。
社会学者Diane Vaughanが、その後の膨大な資料調査をもとに1996年の著書『The Challenger Launch Decision』で体系化した分析概念である。
Vaughanの分析では、NASAの人々が単純にruleを破って危険を無視したのではなく、過去のexperience、engineering analysis、organizational cultureの中で、本来deviationだった現象を徐々にacceptable behaviorとして再分類していった過程が重視される。
この概念は、CommissionのChapter VIにある、
「erosionとblow-byが繰り返されながらacceptable flight riskとして受け入れられた」
というfindingと非常に相性がよい。
しかし、両者は同一ではない。
Rogers Commission：
1986年の事故調査として、design、判断 過程、communication、安全組織の問題を認定。
Vaughan：
それらを含む資料を後年、組織社会学の枠組みで再分析。
この区別を維持した方が、歴史的にも正確である。
Criticality 1なのに、なぜ「redundant seal」と説明されたのか
field jointは1982年にCriticality 1へ変更されていた。
Criticality 1とは、単一故障がcrew、vehicle、任務 lossへ直接つながり得ることを意味する。
つまりsecondary O-ringを独立した完全backupとして数えてはいけない。
ところがAppendix Hが追跡したFlight Readiness Review資料には、その後もsecondary O-ringを「redundant seal」と説明するchartが存在した。
これは単なる単語の間違いに見えるかもしれない。
しかしsafety systemでは重要である。
正式分類がCriticality 1。
review presentationではredundant seal。
この二つが同時に存在すると、risk perceptionが変わる。
「single-point catastrophic failure item」
として見る場合と、
「primaryが駄目でもsecondaryがある」
として見る場合では、同じerosion dataの意味が違う。
Commissionは、このようなcriticalityの扱いがproblem reportingの中で正しく反映されていなかったことをChapter VIIでも問題にした。
事故から5週間後でさえ、Marshallのproblem reporting systemではSolid Rocket Motor field jointのcriticalityが適切に文書されていなかったと指摘している。
つまり問題は、技術者がCriticality 1という言葉を知らなかったことではない。
systemの別々の文書・review・組織で、その意味が同じ強さで保持されていなかったことだった。
Flight Readiness Reviewはなぜ止められなかったのか
Space Shuttleには正式なFlight Readiness Review、FRR 過程があった。
contractor。
project。
Marshall Center Board。
Level II。
Level I。
複数階層でvehicle readinessをreviewし、flightへ進むか判断する。
仕組みだけ見れば、重大なissueが上位へ上がるための多段階gateが存在していた。
しかしSTS-51LのFRR 過程では、SRM joint O-ring erosionに関する懸念がlaunch blockerとして上位reviewへ出ていなかった。
Appendix Hが追跡した資料を見ると、Oリング問題そのものは過去のFRRで説明されていた。
しかし説明の仕方は徐々に、
anomaly
↓
analysis
↓
acceptable erosion
↓
acceptable risk
という形へ変化していった。
1984年のLevel I FRRでは、joint seal reviewに関するaction itemが出たが、「Outside the Flight Readiness Review」とされ、次flight前に完了しなければならない事項にはならなかった。
これも形式上は合理的に見える。
飛行を止めるほどではないaction。
しかし同じような扱いが積み重なると、
「未解決だが飛べる問題」
がsystem内に蓄積する。
本来FRRは、そうしたriskを上位で統合評価するための仕組みだった。
ところが51-Lでは、最終的にOリング問題は「既知で管理されているproblem」の側へ分類され、事故前のFRRで重大constraintとして表に出なかった。
1月27日のNO GOがなぜ上へ届かなかったのか
概念図。個々の発言を完全な会議録として再現するものではなく、Rogers Commission Chapter V/VIIのfindingを可視化したもの。
CASE052-02で見たとおり、1月27日夜のteleconferenceでは、Thiokolは一度、低温条件でのlaunchを推奨しない立場を示した。[7]
その後、Thiokol内部のcaucusでmanagementが再検討し、company recommendationはGOへ変わった。
一部engineersは反対を維持した。
しかしNASAの上位decisionmakerへ伝わったのは、最終的なGO recommendationだった。
CommissionはChapter Vで、この打上げ判断をflawedと結論づけた。
最終decisionmakerは、
recent O-ring/joint problem history
Thiokolのinitial written no-launch recommendation
management reversal後も続いていたengineer opposition
Rockwellのice concernの強さ
を十分に知らなかった。
ここで、communication failureの意味を正確に捉える必要がある。
「情報がどこにも存在しなかった」
のではない。
情報は存在した。
Thiokol engineersは知っていた。
Thiokol managementは知っていた。
Marshallの一部personnelは知っていた。
しかし、最終判断をする人に、問題の履歴と不確実性を保持したまま届かなかった。
つまり情報の「有無」ではなく、
information routing
information compression
escalation criteria
の問題だった。
最終状態だけを伝える危険
大規模projectでは、上位managementへすべてのraw dataを上げることはできない。
情報は要約される。
technical issue
↓
reviewed
↓
resolved
↓
GO
というstatusに圧縮される。
通常はそれで組織が動く。
しかしcritical safety issueでは、この圧縮が危険になる。
「最初から問題なしでGO」
と、
「専門家の重大なNO GOが出たが、management review後にGO」
は同じGOではない。
後者には、
反対理由
未解決のuncertainty
推奨変更の根拠
dissenting opinion
という履歴がある。
この履歴が失われると、上位decisionmakerはriskの質を評価できない。
Challengerの前夜に起きたのは、このinformation compression failureだった。
CommissionがMarshallの「management isolation」を問題にした理由
Chapter VとRecommendation Vでは、Marshall Space Flight Centerのproject managementについて「management isolation」の傾向が問題にされた。
これはMarshall全体の人々が意図的に情報を隠した、という単純な意味ではない。
Commissionが問題にしたのは、potentially serious problemをprogram-wideにforwardするより、Marshall内部で解決しようとする傾向だった。
SRBはMarshallのproject responsibilityだった。
そのためbooster issueは、まずMarshallとcontractorの技術・管理系統で処理される。
専門性という意味では合理的である。
しかし重大なflight safety issueがその系統内で「解決済み」とされれば、
Level II program management
Level I
astronaut side
other Shuttle elements
へ、問題のfull historyが共有されない可能性がある。
Commissionは、Marshallが「systemの一部として他組織とinterfaceしながら任務 safetyを作る」必要に対し、内部完結傾向が強すぎたと評価した。
Safety organizationはどこにいたのか
Chapter VIIの題名はThe Silent Safety Programである。
Commissionが何時間ものtestimonyを聞いて驚いたのは、1月27日の打上げ判断に関する証言の中で、NASAのsafety staffがほとんど登場しなかったことだった。
ThiokolとMarshallのteleconferenceにSafety, Reliability and Quality Assurance representativeはいなかった。
1月28日のMission Management Teamにも、safety representativeはいなかった。
これは、
「NASAに安全部門が存在しなかった」
という意味ではない。
組織としては存在した。
問題は、critical 判断に参加し、independent checkをかける実効力が弱かったことである。
Commissionは、本来のSR&QAには、
equipment status monitoring
design validation
problem analysis
system acceptability
hazard assessment
risk evaluation
を担うwatchdog roleがあると整理した。
51-Lでは、そのwatchdogが判断 chainへ十分入っていなかった。
safety部門が独立していなければ何が起きるか
Commissionは、KennedyとMarshallの一部Safety, Reliability and Quality Assurance組織が、監視対象となるprogram organizationの下に置かれていたことも問題視した。
安全部門の役割は、programが「飛ばしたい」と考えているときでも、
証拠は十分か
hazardは閉じているか
criticalityは正しいか
trendは悪化していないか
を独立して問い直すことにある。
ところが同じline managementの中に強く組み込まれると、
schedule
cost
任務 objective
technical performance
とsafety judgmentの独立性が弱くなる可能性がある。
必ずしも誰かが圧力をかけなくても、同じgoal 構造を共有するだけでcheck functionは弱くなり得る。
このためCommissionはRecommendation IVで、NASA Administratorへ直接報告書する独立性の高いOffice of Safety, Reliability and Quality Assuranceを設けるよう勧告した。
誰もOリングのtrendを一枚にしなかった
Chapter VIIで特に重要なのがtrend analysisである。
Oリングanomalyは各flightごとには記録されていた。
しかしprogram-wideなtrendとして十分に集約されなかった。
Commissionは、1984年1月以降、field joint O-ring anomalyのpatternが明らかに変化したと指摘している。
初期9 flightsではfield joint anomalyは1回だった。
その後、10回目の任務からChallengerまでの期間では、半数を超える任務でfield joint O-ringのblow-byまたはerosionが見られたとCommissionは整理した。
個別flightだけを見ると、
今回もerosion
今回もsealした
今回も任務 success
で終わる。
しかし時系列で並べると、
発生頻度が増えている
低温との関係が疑われる
field jointでもblow-byしている
という別のpictureになる。
MarshallのReliability and Quality Assurance責任者Wiley BunnはCommissionで、dataは持っていたが適切にassembleして見れば「pageから飛び出してくる」ほどtrendが明白だったという趣旨を認めている。
data shortageではない。
data integration failureだった。
「問題報告」があってもsystemは安全にならない
安全管理では、報告書を作ること自体が目的になりやすい。
anomaly 報告書。
waiver。
action item。
Flight Readiness chart。
Critical Items List。
Challengerでは、documentationは大量に存在した。
それでも事故は起きた。
Commission Chapter VIIのfindingsには、
problem reporting requirementが明確でない
critical informationが適切なmanagement levelへ届かない
trend analysisがほとんど行われていない
criticalityが正しく表現されていない
という問題が並ぶ。
つまり、
「記録がある」
と
「安全情報として機能している」
は別である。
記録は、誰かが読む。
比較する。
trendを見る。
escalateする。
constraintへ変える。
解決するまでcloseしない。
そこまで動いて初めてsafety systemになる。
flight rateは事故原因だったのか
Challenger事故を、
「NASAが打上げ回数を増やしたかったから安全を犠牲にした」
と一文で説明するのも不正確である。
Rogers Commissionは、1月28日の打上げ判断が外部政治圧力によって強制されたとは結論づけていない。
しかし、Shuttle system全体がaccelerating flight scheduleの要求を受けていたことは明確に問題視した。
Chapter VIIでは、flight rateが増える一方でMarshallのSafety, Reliability and Quality Assurance workforceが減少し、任務 safetyへ悪影響を与えたとfindingに書いている。
Chapter VIIIでも、1985年末から1986年にかけてsystem capabilityが予定flight rateを支える限界へ近づいていたことが示される。
schedule pressureは、
「誰かが1月28日に無理やりlaunch buttonを押させた」
という形で作用したわけではない。
より長期的に、
未解決問題を抱えたまま次flightへ進む
action itemを次へ送る
hardware issueを運用で管理する
review timeを圧縮する
safety resourcesが追いつかない
というsystem conditionを作る。
production pressureは、個別判断の命令ではなく、organizational environmentとして作用する。
Feynmanが見つけた「1/100」と「1/100,000」の距離
Richard FeynmanのAppendix Fには、NASAのrisk perceptionを象徴する数字が出てくる。
Shuttleがvehicleとhuman lifeを失うfailure probabilityについて、Feynmanが聞いたestimateには大きな幅があった。
roughly 1 in 100
から
1 in 100,000
である。
Feynmanによれば、高いfailure probability、つまり危険側のestimateはworking engineersから出やすく、非常に低いfailure probabilityはmanagement側から出ていた。
ここで注意しなければならない。
「NASA engineeringの正式計算が1/100で、NASA managementの正式計算が1/100,000だった」[7]
という意味ではない。
Feynmanがinterviewや調査を通じて観察したrisk estimateの隔たりである。
しかし彼が問題にしたのは、まさにその隔たりだった。
同じhardwareを扱う組織の中で、
working levelはかなり危険なsystemと見ている。
上位側では極めてreliableなsystemと見ている。
もしrisk perceptionが2〜3桁ではなく3桁以上離れているなら、管理上の判断の前提が一致していない。
Feynmanは、1/100,000なら毎日Shuttleを打ち上げても300年程度に一度のlossという規模になると指摘し、そのような高い信頼性へのmanagement faithを疑問視した。[4]
なぜmanagementはsystemを安全だと信じやすくなるのか
大規模技術systemでmanagementが非合理だから、という説明だけでは足りない。
成功実績は強い。
ShuttleはChallengerまで24回飛び、catastrophic failureを起こしていなかった。
毎回多くのanomalyがあっても、任務は帰還する。
するとorganizationには、
engineering anomaly
と
任務 failure
の間に大きな距離があるように見える。
Oリングがerosionした。
でも帰ってきた。
tileが損傷した。
でも帰ってきた。
sensor anomalyが出た。
でも任務 successだった。
success recordは、systemがrobustである証拠にも見える。
しかしhigh-risk systemでは、24回のsuccessだけでcatastrophic probabilityの低さを十分証明することはできない。
しかもその24回の中にnear missやdegraded safety marginが混ざっていれば、単純なsuccess countはriskを隠す。
Feynmanが批判したのは、このsuccess historyをengineering uncertaintyより強い証拠として扱う姿勢だった。
「engineer vs manager」の物語だけでは足りない
チャレンジャー事故は、しばしば
勇敢なengineer
対
無責任なmanager
という構図で語られる。
1月27日のThiokol caucusを見ると、その構図には事実的根拠の一部がある。
BoisjolyやThompsonらはlaunchへ反対した。
managementはcompany recommendationを反転させた。
Commissionも、このreversalを強く批判している。
しかし事故全体をそれだけで説明すると、同じsystemが別の人員でも再発する可能性を見落とす。
erosionをacceptableとしたreviewにはengineersも関わっている。
Flight Readiness Reviewには複数階層のtechnical organizationが関わっている。
anomalyを管理可能と判断するrationaleは、単なる命令ではなくtechnical analysisとして積み上がった。
Vaughanの後年研究が重要なのもここである。
彼女はChallengerを、悪意ある少数のmanagerによる単純なrule violationではなく、通常のorganizational 過程の中でrisk perceptionが形成される事故として再分析した。
SYSTEM事故として読むなら、
悪い個人を交換する
だけでは再発防止にならない。
information flow
review rule
risk acceptance criterion
independent safety authority
dissent preservation
trend analysis
を設計し直す必要がある。
「安全担当が会議にいない」は何を意味するのか
産業設備に置き換えると分かりやすい。
重大なsafety interlockに既知の不具合がある。
maker engineerは条件付きで停止を推奨する。
production側は稼働したい。
management reviewで運転継続になる。
この会議に、
safety officer
quality assurance
independent reviewer
がいない。
しかも「最初は停止推奨だった」という履歴が上位責任者へ残らない。
さらに過去の類似不具合を横断的にtrend化する担当も機能していない。
個々の人が誠実でも、systemとして危険である。
NASAのChapter VIIでCommissionが「silent」と表現したのは、この意味である。
安全機能は組織図に存在するだけでは足りない。
critical 判断で声を持つ必要がある。
組織のSafety Integrityをどう考えるか
制御システムには、fail-safeやredundancyという考え方がある。
組織にも似た考え方が必要である。
Engineeringがriskを見落としたら、Reliabilityがtrendで拾う。
Project managementが進行を優先したら、Safetyが独立して止める。
contractor内で反対意見が消えたら、NASA側のreviewが履歴を確認する。
Marshall内で解決済みになっても、Level II/Level Iがcritical historyを受け取る。
一つの層が失敗しても、別の層が止める。
これがorganizational redundancyである。
Challengerでは、複数層があった。
しかし独立性が弱く、同じ情報圧縮とrisk acceptanceの影響を受けた。
hardware側で二本のOリングが同じjoint rotationと低温へ依存していたのと似ている。
組織側でも、
複数reviewが存在すること
と
独立した防護層が存在すること
は同義ではない。
Commissionの勧告が「Oリング交換」で終わらなかった理由
Rogers Commission Recommendation Iは、Solid Rocket Motor joint and sealのredesignを要求した。
しかし勧告はそれだけではない。
Recommendation II：
Shuttle Management Structure。
Recommendation III：
Criticality Review and Hazard Analysis。
Recommendation IV：
Safety Organization。
Recommendation V：
Improved Communications。
さらにLanding Safety、Launch Abort and Crew Escape、Flight Rate、Maintenance Safeguardsまで続く。
これは事故調査の結論そのものである。
原因が単なるOリング材質なら、
Oリングを替える
jointを直す
だけでよい。
しかしCommissionは、
誰が判断するか
critical itemをどう分類するか
problemをどう報告するか
safety organizationを誰の下に置くか
launch constraintをどう解除するか
flight rateをどう設定するか
まで変更を求めた。
つまりofficial investigation自身が、Challengerをsystem-level accidentとして扱った。
Commissionが求めた「Improved Communications」
Recommendation Vでは、Marshall project managersのmanagement isolationを直接取り上げた。
さらに、
launch constraintの設定・解除policyを明確化する
Flight Readiness ReviewとMission Management Team meetingを記録する
flight crew commanderまたはrepresentativeをFRRに参加させる
などが勧告された。
これは単に「もっと会話しましょう」というrecommendationではない。
communicationを過程として設計し直す提案である。
誰が参加するか。
誰のdissentを残すか。
constraintを誰が解除できるか。
判断 recordを残すか。
communication failureを「性格」ではなく「system specification」の問題として扱っている。
検証ポイント｜Rogers Commissionが認定した組織側の問題
| 項目 | Commissionの整理 |
|---|---|
| Physical cause | right SRM aft field joint pressure seal failure |
| Launch 判断 | flawed |
| 情報伝達 | incomplete / sometimes misleading informationで打上げ判断が行われた |
| Thiokol | initial NO GO後にmanagementがpositionをreversal。engineer oppositionは残った |
| 上位decisionmaker | initial no-launch recommendationや継続するengineering oppositionを十分把握せず |
| O-ring history | erosion / blow-byが繰り返され、acceptable flight riskとして受容された |
| Joint understanding | NASA/Thiokolとも事故前にseal mechanismを完全には理解していなかった |
| Criticality | field jointはCriticality 1だが、review資料にはsecondaryをredundant sealと扱う表現が残った |
| Trend analysis | O-ring erosion / blow-byについてlittle or no trend analysis |
| Safety participation | Jan.27 teleconferenceにSR&QA representativeなし |
| Mission Management Team | safety representativeなし |
| Safety organization | staffing reduction、independence不足、problem reporting不備 |
| Flight rate | accelerating scheduleに対しsafety capabilityが弱化 |
| Feynman observation | catastrophic failure risk estimateにroughly 1/100〜1/100,000の大きな認識差 |
| Commission response | designだけでなくmanagement / criticality / safety / communications / flight rate等を改革対象化 |
事故を「組織文化」で説明しすぎる危険
一方で、「NASAの文化が悪かった」という抽象論だけにすると、逆に何も説明しなくなる。
cultureは部品番号のように交換できない。
具体的なfailure pathへ落とす必要がある。
Challengerの場合なら、
Criticality 1がreviewでredundantに見える表現へ薄まる。
anomaly dataがflightごとに閉じ、trendへ集約されない。
launch constraintの解除条件が弱い。
NO GOからGOへの変更履歴が上位へ十分上がらない。
Safetyがcritical teleconferenceに入っていない。
FRR actionが「次flightまでに必須」ではない扱いになる。
こうした具体的な過程 failureを束ねたものがorganizational problemである。
「culture」という言葉は、その結果として使うべきで、原因分析の代わりに使うべきではない。
Challengerから見えるSYSTEM事故の形
ここまでを一つのchainにすると、事故の姿が見える。
joint designにdynamic weaknessがある
↓
secondary redundancyが限定的だと分かる
↓
Criticality 1になる
↓
実飛行でerosionが出る
↓
解析でmarginが示される
↓
飛行継続
↓
別flightでblow-by
↓
それでも任務 success
↓
acceptable riskとして扱われる
↓
trendはsystem-levelで十分可視化されない
↓
低温flight experienceの外へ出る
↓
engineersがNO GO
↓
management reviewでGO
↓
反対履歴が上位へ完全には伝わらない
↓
independent safety voiceが判断 chainにいない
↓
launch
↓
joint seal failure
↓
vehicle loss
このchainには、一つの「悪い判断」だけではなく、長期間の小さな判断が含まれている。
だからChallengerは、一夜の判断だけを研究しても足りない。
事故前数年のorganizational memoryまで見なければならない。
次回｜NASAは事故後に何を変えたのか
Rogers Commissionは、事故原因をhardwareとorganizationの両方に広げた。
次のCASE052-07では、そのfindingが実際に何へ変換されたのかを見る。
Solid Rocket Motor jointはどうredesignされたのか。
secondary O-ringは本当にbackupとして成立する構造へ変わったのか。
criticality reviewはどうやり直されたのか。
Safety, Reliability and Quality Assuranceはどこへ置かれたのか。
launch constraintとcommunicationはどう変更されたのか。
そして32か月の停止後、NASAはどの条件を満たしてSTS-26でReturn to Flightしたのか。
「事故から学んだ」という言葉ではなく、
何を設計変更し、
何を組織変更し、
何をverificationしたのか
を具体的に追う。
FACT CHECK｜出典・参考資料
- [1] Presidential Commission on the Space Shuttle Challenger Accident, Report, Chapter V: The Contributing Cause of the Accident
- [2] Presidential Commission on the Space Shuttle Challenger Accident, Report, Chapter VI: An Accident Rooted in History
- [3] Presidential Commission on the Space Shuttle Challenger Accident, Report, Chapter VII: The Silent Safety Program
- [4] Presidential Commission on the Space Shuttle Challenger Accident, Volume II, Appendix F: Personal Observations on Reliability of Shuttle, Richard P. Feynman
- [5] Presidential Commission on the Space Shuttle Challenger Accident, Volume II, Appendix H: Flight Readiness Review Treatment of O-ring Problems
- [6] Presidential Commission on the Space Shuttle Challenger Accident, Recommendations
- [7] Diane Vaughan, The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, 1996 — secondary scholarly framing; not Rogers Commission terminology
チャレンジャー事故｜なぜ打ち上げは止められなかったのか 第6回 全8回 全8回を見る
- 01 チャレンジャー事故｜チャレンジャー号事故とは？｜STS-51Lはなぜ73秒で失われたのか
- 02 チャレンジャー事故｜なぜチャレンジャーは寒波の朝に打ち上げられたのか｜延期・低温・前夜の電話会議
- 03 チャレンジャー事故｜Oリングはなぜ密封に失敗したのか｜固体ロケットブースター継手の構造
- 04 チャレンジャー事故｜打上げ後73秒に何が起きたのか｜映像とテレメトリで追う機体崩壊
- 05 チャレンジャー事故｜海底の残骸は何を語ったのか｜捜索・回収・復元で事故原因を確かめる
- 06 チャレンジャー事故｜ロジャース委員会は何を明らかにしたのか｜技術事故から組織事故へ
- 07 チャレンジャー事故｜NASAは事故後に何を変えたのか｜SRB再設計・安全改革・STS-26復帰
- 08 チャレンジャー事故は何を残したのか｜SYSTEM事故として読む技術と組織の教訓