STORY SO FAR
前回「ロジャース委員会は何を明らかにしたのか｜技術事故から組織事故へ」で確認した論点を受け、この回ではNASAは事故後に何を変えたのか ｜ SRB再設計・安全改革・STS-26復帰の後に何が変わり、何が残ったのか。を扱う。
1986年1月28日のチャレンジャー事故後、スペースシャトルは飛ばなくなった。[1]
次にShuttleが宇宙へ戻るまで、32か月かかった。
その間にNASAが行ったのは、壊れたOリングを別のOリングへ交換する程度の修理ではない。
Rogers Commissionは、事故の直接原因をright Solid Rocket Motor aft field jointのpressure seal failureと認定した。
しかし同時に、
joint design
Criticality review
hazard analysis
Shuttle management 構造
Safety, Reliability and Quality Assurance
problem reporting
launch constraint
Flight Readiness Review
crew escape
flight rate
maintenance
までを改革対象にした。
だからReturn to Flightに必要だったのも、単一部品の修正ではなかった。
hardwareを変える。
そのhardwareが本当に安全だとtestで証明する。
既知のcritical itemをすべて見直す。
安全部門を独立させる。
重大な異論やconstraintを上位managementへ上げる仕組みを作る。
maintenanceとtrend dataを一つのsystemで見えるようにする。
そして、Shuttleへ依存しすぎたflight rateそのものを見直す。
NASAの後年資料では、Return to Flightへ向けて200を超える変更がShuttle systemへ加えられたとされている。
その象徴が、事故原因となったSolid Rocket Motor field jointの全面的なredesignだった。
しかし本当に重要なのは、
「新しいOリングを入れたから飛べた」
のではなく、
「事故原因として認定されたfailure pathに対して、hardware・verification・organization・判断 過程を同時に作り直した」
ことである。
CASE052-07では、Rogers Commissionの勧告が具体的に何へ変わり、1988年9月29日のSTS-26へどうつながったのかを見る。[6]
先に結論｜NASAは何を変えたのか
事故後の主要変更は、六つの層に分けられる。
第一はSolid Rocket Motorの再設計。
field jointにcapture featureを追加してjoint rotationを抑え、Oリングが常にpositive squeezeを持つようgeometryを変更した。
primaryとsecondaryに加えて第三のOリングを追加した。
zinc chromate puttyを中心とした旧thermal protectionを見直し、insulation構造を変更した。
field jointにはheaterとweather sealを設け、seal temperatureを75°F以上に維持する設計へ変えた。
第二はverification。
subscale testだけではなく、full-scale hardwareを使ったjoint test、structural test、full-duration static firingを実施した。
温度、pressure、external load、seal flawなど、事故時に問題となった条件を意図的にtestへ入れた。
第三はcriticalityとhazard review。
Criticality 1、1R、2、2R itemとhazard analysisをShuttle全体で再評価した。
「昔からそう分類されているから正しい」ではなく、故障形態と実hardwareに照らしてbaselineを作り直した。
第四はmanagementとcommunication。
National Space Transportation System、NSTSのProgram Director権限を強め、centerごとの縦割りを減らした。
launch constraintの設定・解除をformal 過程化し、FRRとMission Management Teamでの判断 recordを残す方向へ変えた。
第五はindependent safety。
NASA Administratorへ直接報告書できるSafety, Reliability, Maintainability and Quality Assurance組織を新設し、independent assessmentとtrend analysisを担わせた。
第六はShuttle運用そのもの。
crew escapeを改善し、Launch and Entry Suitを復活させ、flight rateをsystem capabilityに合わせる方向へ変更した。
STS-26は、この六つの層を一定程度実装・verificationした後の最初のflightだった。
Commissionの第一要求は「jointを変えろ」だった
Rogers Commission Recommendation Iは曖昧ではない。
faulty Solid Rocket Motor joint and seal must be changed.
事故原因となったjointとsealは変更しなければならない、とした。
さらにCommissionは、単に新しい部品を付ければよいとは言っていない。
新しいjointは、
fully understood
tested
verified
でなければならない。
jointの構造とseal integrityはcase wallに劣らないこと。
dimensional tolerance。
transportation。
handling。
assembly。
inspection。
environment。
internal pressure。
reuse。
flight load。
water impact。
こうした条件に対して、joint integrityが過度に敏感であってはならない。
そしてcertification testは、actual launch configurationをできるだけ再現し、temperatureを含むfull operating rangeで行うべきだとした。
これはCASE052-03で見た旧jointの弱点を、そのままreverse specificationへしたような要求である。
旧jointは、
寸法に敏感。
温度に敏感。
assembly conditionに敏感。
pressure-induced deflectionに敏感。
Oリングpressure actuation timingに敏感。
だった。
Commissionは、その「敏感さ」をdesignから取り除けと要求した。
capture featureは何を変えたのか
redesigned field jointの中心がcapture featureである。
旧jointではtangがclevisへ入り、pinで結合される。
motor pressureが上昇するとcaseが膨張し、tangとclevisが相対的に動く。
その結果、O-ring sealing gapが広がるjoint rotationが起きた。
redesignでは、tangとclevisの端部にpositive metal-to-metal interferenceを作るcapture latchが追加された。
これによってpressureやstructural loadがかかったときのrelative deflectionを機械的に制限する。
つまり旧設計のように、
jointが大きく開く
↓
Oリングが急いで追従する
ことへ依存しにくくした。
安全設計として重要なのはここである。
旧designは、
「jointが動いた後にsealが追いつく」
ことへ依存していた。
新designは、
「jointそのものを動きにくくする」
方向へ変わった。
制御で補正する前に、mechanical 故障形態を減らす。
より上流の対策である。
Oリングは「pressure actuation必須」から外された
旧jointでは、Oリングがsealするためにmotor gas pressureによるpressure actuationが重要だった。
joint gapが広がる。
Oリングへ圧力が届く。
Oリングが動く。
seal surfaceへ押し付けられる。
この時間関係が崩れるとblow-byが起きる。
redesigned jointでは、capture featureとshimでsealing gapを制御し、Oリングへ常にpositive compression、positive squeezeが残るよう設計された。
NASAのimplementation 報告書では、O-ring grooveも変更され、Oリングが完全圧縮された状態でもgroove容積の90%を超えて占有しないようにした。
その結果、
pressure actuationを利用できるが、
pressure actuationがなければsealできない設計にはしない
という方向へ変えられた。
これは非常に大きい。
old jointではgas pressureそのものがseal成立の一部だった。
new jointでは、静的・動的geometryの段階でseal contactを保持しやすくした。
第三のOリングは何のためだったのか
redesignでは第三のOリングが追加された。
しかし、
「二本で失敗したから三本に増やした」
と理解すると不正確である。
NASA implementation 報告書では、追加Oリングはprimary O-ringを適切な方向へseatさせる役割と、internal insulationがbreachした場合のthermal barrierとして説明されている。
つまり単純な直列三重redundancyではない。
primaryとsecondaryのseal integrityを高めるためのjoint system全体の一部である。
数を増やすより、
joint deflection
groove geometry
squeeze
thermal protection
leak check
と組み合わせてfailure pathを変えたことが重要だった。
putty依存もやめた
旧jointではzinc chromate puttyがthermal barrierとして使われていた。
しかしCASE052-03で見たように、puttyはgas path形成やpressure actuation delayの要因にもなり得た。
redesignではinternal insulation 構造を変更し、deflection relief flapを使う方式へ移した。
後年のredesigned SRM、RSRMではJ-shaped insulation featureなどを使い、hot gasがmetal jointやOリングへ届く前にthermal pathを制御する設計へ発展した。
重要なのは、
「sealの前に置いた材料が、条件次第でseal timingを変えてしまう」
という不確実性を減らしたことである。
thermal protectionとpressure sealを、よりpredictableな構造へ分離しようとした。
field joint heaterは「寒い日は祈る」をやめる装置だった
事故前夜の大きな問題はtemperatureだった。
旧jointでは、外気温とcase temperatureによってOリングresiliencyが大きく変わる。
しかしactual O-ring temperatureを安全領域へ積極的に制御するsystemはなかった。
redesignではfield jointにexternal heaterが追加された。
NASA implementation 報告書では、heaterとintegral weather sealによってfield joint seal temperatureを75°F以上に維持するとしている。
約24℃である。
これは単なる冬対策ではない。
environmental conditionを「予報して判断する」だけではなく、
hardware側でcritical parameterを管理する
方向への変更である。
旧systemでは、
明朝は寒い
↓
Oリングは何度になるか
↓
経験範囲外か
↓
飛ぶか止めるか
を人間が議論した。
新systemでは、
seal temperatureをdesign-controlled rangeに保持する
というengineering controlを追加した。
安全hierarchyで言えば、判断手順だけでなくphysical mitigationを入れたことになる。
weather sealはwater intrusionも抑えた
field joint heaterにはweather sealも組み込まれた。
これは温度保持だけでなくwater entryを防ぐ。
事故調査では、joint内部にwaterやiceが存在した可能性も検討された。
water intrusionがChallengerの直接原因だったと確定されたわけではない。
しかしdesign sensitivityを減らすというCommission requirementから見れば、
外部環境からwaterが入り得るpathを減らす
ことは合理的な変更だった。
redesignは「今回の唯一のfailureを直す」のではなく、
事故調査で見つかったpotential vulnerabilityをまとめて潰す
方向で進められた。
leak checkも「組んだ後に本当にsealできているか」へ変わった
redesignではadditional leak check portも追加された。
目的は、
assembly後にleakがない
primaryとsecondary O-ringがproper sealing positionにある
ことをverificationするためである。
巨大なrocket motorでは、assembly 過程そのものがriskになる。
case segmentは完全な真円ではない。
transportやstorageでgeometryが変わる。
stacking時にOリングを傷つける可能性がある。
そのためground support equipmentもredesignされた。
guide。
round-out ring。
case diameter measurement。
leak test capability。
transportation pallet。
lifting beam。
NASAはjoint hardwareだけでなく、
「安全なjointを毎回同じ品質で組み立てられるか」
までReturn to Flight条件に含めた。
redesignはfield jointだけではなかった
事故原因はfield jointだった。
それでもNASAはSolid Rocket Motor全体を見直した。
nozzle-to-case joint。
nozzle metal parts。
ablative component。
factory joint。
igniter。
ground support equipment。
これらにもdesign changeが入った。
nozzle-to-case jointではradial boltを追加し、joint gap openingを減らした。
insulationとseal configurationも変更した。
factory jointにもfield jointと類似したmargin improvementが加えられた。
なぜ直接原因でない部分まで変えたのか。
Rogers Commissionが求めたのは、
事故箇所だけのpatch
ではなく、
SRM joint and seal system全体がdesign envelopeで理解・verificationされている状態
だったからである。
「設計した」だけではReturn to Flightできなかった
重大事故後のredesignで最も危険なのは、
drawingを変更した
analysisでOKになった
だから次へ進む
ことである。
Commission Recommendation Iはindependent oversightとverificationを要求した。
NASAはSRM Redesign Project PlanとDevelopment and Verification Planを作り、
laboratory test
component test
subscale firing
full-scale simulator
structural test
full-duration static firing
を組み合わせた。
joint environment simulatorでは、
最大pressure
pressure rise
temperature extreme
intentional flaw
flight load
を入れてseal performanceを確認した。
full-scale motor static firingも複数計画された。
事故時に問題となったtemperatureとdynamic loadを、certification側へ意図的に入れたのである。
「低温でも大丈夫」ではなく「低温条件をtestする」
事故前の問題は、低温側のdataが十分でないままGO/NO GOを議論したことだった。
Return to Flightでは、同じ曖昧さを残さないことが重要だった。
redesign verificationではlow/high temperatureでのseal behaviorがtest objectiveとして明示された。
さらにfull-scale motor firingではflight dynamic loadとthermal environmentを与える計画が組まれた。
後年NASA資料では、Return to Flightまでに複数のfull-scale static testsが行われ、hot/cold specification boundsやExternal Tank attachment由来のside loadまで含めてverificationしたと整理されている。
事故前は、
「この条件で本当に大丈夫か」
という問いにlimited flight historyで答えようとした。
事故後は、
「その条件をground testで再現し、故障形態を直接叩く」
方向へ変えた。
independent oversightをdesign 過程へ入れた
Commissionは、SRM redesignをNASAとcontractorだけで閉じないよう要求した。
National Research CouncilにIndependent Oversight Panelを作り、NASA Administratorへ直接報告書させた。
panelは、
design criteria
analysis
certification plan
verification test
material specification
quality assurance
manufacturing
までreviewした。
さらにNASAは他のsolid rocket motor企業にもdesign critiqueを依頼した。
Aerojet。
Atlantic Research。
Hercules。
United Technologies。
つまり事故を起こした既存teamだけで「直しました」と自己承認するのではなく、outside expertiseを意図的に入れた。
これはtechnical redesignであると同時に、review 構造のredesignでもある。
Criticality 1を全部見直す
Rogers Commission Recommendation IIIは、SRBだけに限らなかった。
Shuttleと主要contractorに対し、
Criticality 1
1R
2
2R
itemとhazard analysisをすべてreviewするよう要求した。
FMEA、Failure Modes and Effects Analysis。
Critical Items List。
Hazard Analysis。
これらを再評価する。
なぜか。
Challengerでは、field jointがCriticality 1へ変更されていたのに、review presentationではsecondary O-ringをredundant sealのように扱う場面が残っていた。
classificationが存在しても、実際の判断 過程でその意味が薄れれば意味がない。
事故後のreviewは、
criticality label
actual 故障形態
hazard
waiver
corrective action
を再接続する作業だった。
National Research CouncilのAudit Panelも、そのadequacyを独立確認する役割を与えられた。
safety organizationはNASA Administratorへ直接報告書する形へ
CASE052-06で見た最大の問題の一つが、Safety, Reliability and Quality Assuranceの弱さだった。
Rogers Commission Recommendation IVは、
NASA Administratorへ直接報告書する
独立したOffice of Safety, Reliability and Quality Assuranceを作る
ことを求めた。
NASAはOffice of Safety, Reliability, Maintainability, and Quality Assurance、SRM&QAを新設した。
Associate Administratorを置き、NASA Administratorへ直接報告書するlineを作った。
目的は、
program managementがGOと言っているときでも、
別lineからindependent assessmentを上げられる
ようにすることだった。
NASA Management Instructionでは、
design
development
manufacturing
procurement
test
operations
を独立評価するcheck-and-balance functionが定義された。
重要なのは、「安全担当を増やした」だけではない。
reporting lineを変えたことである。
trend analysisを正式な安全機能へ戻す
事故前、Oリングerosionとblow-byのdataは存在した。
しかしprogram-wide trendとして十分に使われなかった。
事故後SRM&QAには、
problem reporting
problem resolution
trend associated with flight safety
のdirection responsibilityが与えられた。
さらにSystem Integrity Assurance Program、SIAPが作られ、program-wideなdata visibilityを強化した。
その中核の一つがPCASS、Program Compliance Assurance and Status Systemだった。
このdatabaseでは、
problem data
trend
risk 判断
hazard
critical item history
FMEA/CIL data
launch constraint
などをprogram managementとsafety側から確認できる構想が作られた。
事故前は、
dataはあるが一枚にならない
ことが問題だった。
事故後は、
critical dataを一つのmanagement information systemで見えるようにする
方向へ変えた。
launch constraintを誰が解除できるかもformalizeした
Challenger事故では、「問題を誰が知っているか」だけでなく、
誰がflight constraintとして扱うか
誰が解除できるか
が曖昧だった。
NASAはReturn to Flightのmanagement restructureで、launch constraint 過程をformalizeした。
project managerなどがconstraintをrecommendする。
SRM&QAなど他組織からもrecommendできる。
Deputy Director, NSTS Programが評価する。
Director, NSTSがestablishment、removal、waiverをapproveする。
そして各任務のFRRでreviewする。
これによって、
「担当project内で解決済みになったので上へ行かない」
状態を減らそうとした。
FRRは「GOと言う会議」ではなく署名責任を持つ場へ
Return to Flight後のFlight Readiness Reviewでは、project managerとelement contractorがCertificate of Flight Readinessへsignする仕組みが強化された。
hardware status。
processing problem。
resolution。
launch constraint。
open item。
それらを踏まえてreadyをcertifyする。
さらにL-1のMission Management Teamでも各projectとcontractorがreadiness endorsementを行う。
SRM&QA personnelもFRR、L-1、その他key 判断 meetingへ参加する。
proceedingsはrecordされ、formal minutesが残る。
これは51-L前夜の教訓へ直接対応している。
NO GOがあった。
GOへ変わった。
しかし上位にはhistoryが十分残らなかった。
事故後は、判断 historyそのものをsystem recordへ残す方向へ変えた。
Shuttle management 構造も作り直された
Rogers Commissionは、Marshallなど各center projectがcenter managementへ強く結び付き、National STS Program Managerを重要情報がbypassする構造を問題にした。
事故後、NASAはNSTS Program management 構造を変更した。
Director, NSTSをNASA Headquartersへ置き、Associate Administrator for Space Flightへ直接報告書させた。
program budgetやrequirementsを含む全体責任を強化した。
JSC、KSC、MSFCの各projectもprogrammaticallyにNSTS chainへ接続された。
狙いは、
centerの局所最適
より
Shuttle system全体のflight safety
を優先できる構造にすることだった。
MarshallでSRB issueが「解決済み」になった瞬間にprogram全体から消えることを防ぐ。
management isolationへの対策である。
Space Flight Safety Panelも作られた
NASAはSpace Flight Safety Panelも設置した。
chairはastronaut Bryan O’Connor。
panelはSafety, Reliability, Maintainability and Quality Assurance側へ報告書し、crewを伴うspace flight programのflight safetyを監視する役割を持った。
astronaut。
flight director。
Marshall 任務 manager。
Kennedy test director。
など異なるoperational perspectiveを入れた。
Challenger以前にもsafety organizationは存在した。
事故後の変更は、
「組織図にSafetyを置く」
だけでなく、
判断 chainとoperational reviewへ直接関与させる
ことにあった。
crew escapeも変わった
Challenger accidentはSRB joint failureを起点とした。
しかしcrew survivalの観点では、別の問題も明らかになった。
Orbiterは上昇中のすべてのfailure conditionでcrewをescapeさせられるvehicleではなかった。
Rogers Commission Recommendation VIIはlaunch abortとcrew escape能力の見直しを要求した。
Return to Flightでは、controlled gliding flightなど限定された条件でcrewがbailoutできるよう、side hatchから安全に離れるためのescape pole systemが追加された。
またcrewはLaunch and Entry Suit、LESを着用するようになった。
これは「Challengerと同じfailureが起きても脱出できるようになった」という意味ではない。
SRB powered ascent中のcatastrophic breakupからcrewを確実に救うsystemが完成したわけではない。
改善されたのは、一定条件でのescape envelopeとpersonal protectionである。
ここは過大評価してはいけない。
「Shuttleをもっと飛ばす」前提も見直された
Rogers Commission Recommendation VIIIはflight rateそのものを問題にした。
Shuttleを国家の主要launch capabilityとして使いすぎたことで、flight rateを上げるpressureが生まれた。
Commissionは、
NASA resourcesに合ったflight rateにする
single launch capabilityへの依存を減らす
よう勧告した。
事故後、NASAはFlight Rate Capability Working Groupを設置し、
processing capacity
workforce
software delivery
crew training
spares
facilities
unscheduled work
を含めてsustainable rateを評価した。
同時に、Department of Defense payloadなどの一部をexpendable launch vehicleへ戻し、ShuttleとELVを組み合わせるmixed fleetへ政策が動いた。
これはtechnical redesignではない。
任務 demand側を減らす安全対策である。
安全性を上げる方法は、machineを強くするだけではない。
systemへ掛かるproduction pressure自体を下げることも含まれる。
maintenanceも「一機ごとの経験」からprogram dataへ
Recommendation IXではmaintenance safeguardも見直された。
Criticality 1 itemでは、maintenance・inspection・trend managementを特に厳格にする。
NASAはSystem Integrity Assurance Programを作り、
configuration
inspection
maintenance
operations
analysis
logistics
を一つのflight readiness 過程へ統合した。
PCASSでは、
anomaly
risk 判断
hazard
critical item history
故障形態
launch constraint
を追跡し、SRM&QAがindependent trend analysisを行えるようにした。
事故前のOリング問題は、
各flightで記録されていた
しかし横断trendが弱かった
ことが致命的だった。
Return to Flightでは、data retentionとvisibilityも安全設計の一部になった。
「200以上の変更」は全部事故原因だったわけではない
NASAの後年資料では、Return to FlightまでにShuttle systemへ200を超える変更が加えられたと説明されている。
ここで、
「Challengerには200個以上の欠陥があった」
と理解してはいけない。
事故原因はright SRM field jointと、その背景のorganizational failureへ収束している。
200以上という数字は、事故後のstand-downを利用して、
SRB
Orbiter
Main Engine
crew escape
operations
software
processing
inspection
などShuttle system全体を広く改善した結果である。
Return to Flightは、
原因箇所を直すcorrective action
と、
system-wideなreliability/safety enhancement
を同時に行ったprogramだった。
DiscoveryがReturn to Flight vehicleに選ばれた
Return to Flight 任務にはDiscoveryが選ばれた。
Discoveryは事故時点までに6回の任務を経験していた。
1986年10月30日、Vehicle Assembly BuildingからOrbiter Processing Facilityへ移され、Return to Flight向けのmodificationとprocessingが本格化した。[6]
NASAは任務 designationをSTS-26とした。
crewは、
Commander Frederick H. Hauck
Pilot Richard O. Covey
Mission Specialist John M. Lounge
Mission Specialist David C. Hilmers
Mission Specialist George D. Nelson
の5人。
NASA資料では、Apollo 11以来となるall-veteran crewとして編成された。
Return to Flightで「新しい乗員を試す」のではなく、全員がspaceflight experienceを持つcrewを選んだ。
これはhardware redesignとは別のoperational risk reductionだった。
STS-26までの準備は一直線ではなかった
事故後、NASAがdesignを直してすぐ1988年へ進んだわけではない。
testで新しい問題も見つかった。
full-scale firing。
qualification。
Orbiter modification。
wet countdown demonstration。
Flight Readiness Firing。
software simulation。
Terminal Countdown Demonstration Test。
それらを積み重ねた。
1988年8月4日のFlight Readiness Firing attemptは、main engine ignition直前にfaulty valveでabortされた。
NASAはその場で予定どおり進めず、valveを交換した。
8月10日に22秒間のmain engine firingを成功させた。
この小さな事例もReturn to Flightの意味をよく示す。
「予定日に戻す」ことより、
異常が出れば止める
直す
再verificationする
ことが優先された。
1988年9月13〜14日｜Flight Readiness Review
STS-26のFlight Readiness Reviewは9月13〜14日に行われた。
そこでNASA managementは、Discovery、SRB、External Tank、Main Engine、payload、ground systemなどのreadinessをreviewした。
launch日は9月29日に設定された。
Challenger以前にもFRRは存在した。
違いは、そのmeetingの制度だけではない。
その背後に、
redesigned joint
full-scale verification
Criticality review
new SRM&QA
formal launch constraint 過程
recorded 判断 過程
system-wide modification
が積まれていたことである。
Return to FlightのGOは、旧systemと同じ「GO」という単語でも、そこへ至る証拠 chainが違っていた。
1988年9月29日｜DiscoveryがPad 39Bから上がる
STS-26のlaunchは1988年9月29日。
場所は、Challengerと同じKennedy Space Center Launch Pad 39Bだった。
bad windなどで約1時間半遅れた後、Discoveryは打ち上げられた。
約73秒。
Challengerが失われた時刻を通過する。
しかしReturn to Flightで技術者が本当に注目していた節目の一つは、その後だった。
約2分でredesigned Solid Rocket Boostersがburnoutし、予定どおりseparationした。
その後DiscoveryはMain Engineで上昇を続けた。
約8分半でMain Engine cutoff。
External Tank separation。
orbit insertion。
Shuttleは再び有人宇宙飛行へ戻った。
NASAの後年記事では、回収されたSTS-26のSRBをinspectionした結果、redesigned field jointsは意図どおり機能していたとされている。
STS-26は何を運んだのか
Return to Flightはtest flightだけではなかった。
primary payloadはTDRS-3。
Tracking and Data Relay Satelliteである。
これは皮肉でも象徴でもなく、Shuttle programをoperational 任務へ戻すための実用任務だった。
crewはTDRS-3とInertial Upper Stageをdeployし、satelliteはgeosynchronous orbitへ送られた。
任務は4日間。
DiscoveryはEdwards Air Force Baseへ着陸した。
Return to Flightとは、
「一度飛んで帰る」
だけでなく、
任務 objectiveを持つoperational Shuttle systemへ戻る
ことだった。
「Return to Flight＝安全問題の解決」ではない
ここは慎重に見る必要がある。
STS-26が成功した。
redesigned SRBも正常に働いた。
だからChallengerで指摘されたすべての組織問題が永久に解決した。
そうは言えない。
事故後改革は、その時点で認識された故障形態とorganizational weaknessに対して具体的な対策を入れた。
しかしcomplex organizationでは、
procedureを作る
officeを作る
databaseを作る
だけでriskが永久に消えるわけではない。
過程は時間とともに変質する。
schedule pressureも戻る。
成功が積み上がればrisk perceptionも変わる。
後年のColumbia事故が示した問題とChallengerを単純に同一視するべきではないが、「事故後改革があること」と「組織が恒久的に安全であること」が別である点は重要である。
CASE052-07の目的は、
NASAは何も変えなかった
と批判することでも、
改革ですべて解決した
と称賛することでもない。
具体的に何を変えたかを確認することである。
Rogers Commission勧告とNASA対応を対応づける
| Commission Recommendation | NASAの主な対応 |
|---|---|
| I SRM Design | field joint全面redesign、capture feature、O-ring/groove変更、第三O-ring、insulation変更、heater/weather seal、full-scale verification、independent oversight |
| II Management Structure | Director NSTSを中心にprogram reporting lineを再編、center/projectをprogrammatic chainへ接続 |
| III Criticality / Hazard | FMEA、Critical Items List、hazard analysisをShuttle全体で再review |
| IV Safety Organization | SRM&QAを新設し、Associate AdministratorがNASA Administratorへ直接報告書 |
| V Communications | launch constraint formalization、FRR/MMT記録、crew participation、SRM&QA participation |
| VI Landing Safety | tire/brake/nosewheel等を含むlanding safety review |
| VII Abort / Crew Escape | crew escape pole、Launch and Entry Suit、abort/escape review |
| VIII Flight Rate | sustainable flight rate review、manifest control、mixed Shuttle/ELV policy |
| IX Maintenance | System Integrity Assurance Program、PCASS、critical item trend/maintenance visibility強化 |
検証ポイント｜Return to Flight
| 項目 | 確認内容 |
|---|---|
| Challenger accident | 1986年1月28日 |
| Rogers Commission Report | 1986年6月 |
| SRM redesign中心 | capture feature、positive O-ring squeeze、third O-ring、insulation redesign、field-joint heater/weather seal |
| Heater design 標的 | field joint seal temperature 75°F以上 |
| Verification | component/subscale/full-scale test、structural test、full-duration static firing |
| Independent SRM oversight | National Research Council panel |
| Criticality review | Criticality 1/1R/2/2Rおよびhazard analysisを再評価 |
| Safety組織 | Office of Safety, Reliability, Maintainability and Quality Assurance |
| Safety reporting | Associate AdministratorからNASA Administratorへの独立reporting line |
| Management | NSTS program reporting 構造を再編 |
| Communication | launch constraint、FRR/MMT、判断 documentationをformalize |
| NASA資料のsystem modifications | 200超 |
| Return to Flight vehicle | Discovery |
| Mission | STS-26 |
| Crew | 5人、全員spaceflight veteran |
| Launch | 1988年9月29日、KSC Pad 39B |
| Stand-down | 約32か月 |
| Mission duration | 約4日 |
| Primary payload | TDRS-3 |
| SRB postflight | recovered redesigned field jointsは正常機能と評価 |
技術事故後の「正しい直し方」は何か
ChallengerのReturn to Flightは、重大事故後のcorrective actionを考えるうえで参考になる。
故障した部品だけを見る。
部品を交換する。
再起動する。
それでは不十分だった。
なぜその部品が壊れたか。
なぜそのdesignが承認されたか。
なぜ既知anomalyがflight constraintにならなかったか。
なぜtrendが見えなかったか。
なぜ上位decisionmakerへ反対履歴が届かなかったか。
なぜsafety organizationがcritical 判断に入っていなかったか。
そこまで遡る。
そして対策も同じ階層へ入れる。
hardwareにはcapture featureとheater。
verificationにはfull-scale test。
critical itemにはFMEA/CIL review。
organizationにはindependent SRM&QA。
判断にはformal launch constraint。
informationにはPCASSとrecorded review。
operationsにはsustainable flight rate。
事故原因の階層と、corrective actionの階層を対応させる。
ここにReturn to Flightの本質がある。
「再発防止」は一つの安全装置では作れない
CASE052-03では、二本のOリングが同じjoint rotationと低温へ依存していれば、数だけ増やしても完全なredundancyではないと見た。
組織改革も同じである。
Safety Officeを一つ作る。
ruleを一つ追加する。
meetingを一つ増やす。
それだけでは弱い。
hardware
verification
independent review
criticality
communication
maintenance
trend
operations
が互いに独立したdefense layerとして働く必要がある。
事故後NASAが行った変更は、この多層化を目指したものだった。
次回｜チャレンジャー事故は何を残したのか
ここまででCASE052は、
事故全体像
打上げ判断
Oリングとfield joint
73秒の破壊
海底残骸
Rogers Commission
Return to Flight
まで進んだ。
最後のCASE052-08では、個別事実をもう一度長く繰り返すのではなく、シリーズ全体をSYSTEM事故としてまとめ直す。
Challengerを、
「寒かったからOリングが壊れた事故」
で終わらせると何を見落とすのか。
technical uncertaintyを誰が持つのか。
successful past performanceをどうriskへ反映するのか。
dissentをどう保存するのか。
redundancyは本当に独立しているのか。
safety organizationをどこへ置くのか。
そして重大事故後に、
hardwareだけでなく判断 systemそのものをどうredesignするのか。
チャレンジャー事故が現在までengineering、safety、organizationの教材として残る理由を、最後に一つの構造へまとめる。
FACT CHECK｜出典・参考資料
- [1] NASA, Implementation of the Recommendations of the Presidential Commission on the Space Shuttle Challenger Accident, Recommendation I: Solid Rocket Motor Design
- [2] NASA, Implementation of the Recommendations, Recommendations II and V: Shuttle Management Structure and Improved Communications
- [3] NASA, Implementation of the Recommendations, Recommendation III: Criticality Review and Hazard Analysis
- [4] NASA, Implementation of the Recommendations, Recommendation IV: Safety Organization
- [5] NASA, Implementation of the Recommendations, Recommendations VIII and IX: Flight Rate / Maintenance Safeguards
- [6] NASA, STS-26 Return to Flight historical records
- [7] NASA, STS-26 Press Kit / Solid Rocket Motor Redesign
チャレンジャー事故｜なぜ打ち上げは止められなかったのか 第7回 全8回 全8回を見る
- 01 チャレンジャー事故｜チャレンジャー号事故とは？｜STS-51Lはなぜ73秒で失われたのか
- 02 チャレンジャー事故｜なぜチャレンジャーは寒波の朝に打ち上げられたのか｜延期・低温・前夜の電話会議
- 03 チャレンジャー事故｜Oリングはなぜ密封に失敗したのか｜固体ロケットブースター継手の構造
- 04 チャレンジャー事故｜打上げ後73秒に何が起きたのか｜映像とテレメトリで追う機体崩壊
- 05 チャレンジャー事故｜海底の残骸は何を語ったのか｜捜索・回収・復元で事故原因を確かめる
- 06 チャレンジャー事故｜ロジャース委員会は何を明らかにしたのか｜技術事故から組織事故へ
- 07 チャレンジャー事故｜NASAは事故後に何を変えたのか｜SRB再設計・安全改革・STS-26復帰
- 08 チャレンジャー事故は何を残したのか｜SYSTEM事故として読む技術と組織の教訓