見出し画像

「失敗のプロフェッショナル」、航空業界に学ぶ不具合再発防止

「失敗の科学」で注目を浴びた航空業界の事故振り返り


各業界の失敗例をもとに、どのようにしてそれらを再発防止や改善したかを紹介した失敗の科学という本がある。
その中で紹介されている航空業界は業界全体で事故を報告・検証・共有する仕組みが非常に高いレベルで実現している。
今回は航空業界での障害発生から報告までの特筆すべきポイントを紹介しつつ、システム開発における不具合振り返りへの活かし方を紹介しようと思う。

航空業界はトップクラスの原因追及の仕組みが整備されている


航空業界は他の産業に比べて非常に厳格な安全管理が求められており、、迅速な対応と再発防止の仕組みが確立されている。これを支えているのが国際民間航空機関(ICAO)や各国の航空安全機関との連携である。
考え方はIT業界で参考になる要素も多く紹介しようと思う。

1. 事故発生時、事故の報告が義務付けられる。ただし、責任や賠償のためではない


事故や重大なインシデントが発生すると、ICAO(国際民間航空機関)のAnnex 13(航空事故およびインシデントの調査に関する規定)に基づき、
・30日以内に予備報告書

12か月以内に最終報告書
の提出が義務付けられている。
各国の調査機関(例:アメリカのNTSB、日本のJTSB)が調査を進める。

初動で提出が求められるのはICAO Doc 9756 Part III(航空事故およびインシデント調査マニュアル)で定義された下記。
調査が進行中であることを知らせることが目的。

予備報告書の項目(事故発生後30日以内に提出)

  1. 事故の詳細:

    • 事故の発生日時、現地時間およびUTC。

    • 事故現場の位置情報(座標、標高、地形など)。

    • 出発地、目的地、中継地点。

    • フライトプランや航空交通サービス(ATS)によるレーダーデータ。

  2. 気象データ:

    • 当時および航路上の気象条件(気温、視程、風など)。

    • 異常な気象要因(着氷、ウィンドシア、火山灰の影響など)。

  3. 技術データ:

    • 航空機の性能データ(速度、高度、エンジンの動作状況など)。

    • 航空機の整備履歴および運行履歴。

    • フライトレコーダーからのデータ解析、機体やシステムコンポーネントの現場調査。

  4. 人的要因:

    • 乗員の身体的・精神的な状態の確認。

    • 生存者や整備担当者、目撃者へのインタビュー。

    • 適用される場合、遺体解剖の結果やボイスレコーダーの解析

何より大事なのは、事故調査の目的は事故やインシデントの再発を防止することであり、責任や賠償のために行うものではないことを明言していること。

2024年1月に羽田空港で起きた衝突事故においても、日本の航空業界で最大の団体「JFAS(航空安全推進連絡会議)」が出した緊急声明にもこの考え方が現れている。

日本では、運輸安全委員会の事故調査結果が刑事捜査や裁判証拠に利用されています。これらの行為は、明らかな犯罪の証拠がある場合を除き、調査結果を利用することを禁止する国際民間航空条約(ICAO)の規定から逸脱した行為であり容認できるものではありません。

今般の航空機事故において最も優先されるべきは事故調査であり、決して刑事捜査が優先されるものではないこと、またその調査結果が、再発防止以外に利用されるべきではないことをここに強く表明するものです。

JFAS- 2024年1月2日に東京国際空港で発生した航空機事故に関する緊急声明

2. フライトデータレコーダー(ブラックボックス)で事故の瞬間まで徹底解明


飛行機にはフライトデータレコーダー(ブラックボックス)という、超高耐久で事故の数秒までのデータを記録するデバイスが積まれている。
記録されるのは下記の情報で、コックピット内の会話まで記録されている、

・飛行機の速度
・高度
・エンジンのパフォーマンス
・操縦桿やスロットルの位置
・機体の姿勢や方位
・コックピット内の会話や音声
・無線通信の内容

驚くべきはその耐久性で、
・3400G(重力加速度の3400倍)の衝撃に耐えられる
・1100℃の高温に1時間耐えられる構造
・6000メートルの深海でもデータを保護できる防水性
ようになっている。

この高性能デバイスにより、大きな事故が起きた場合でも事故直前までの記録を確認することができ、事故におけるフライトの全体像を再現できる。

3.原因究明は多面的に。人的・組織的な要素も検討する


ICAOのAnnex 13には、技術的な問題だけでなく、パイロットの訓練不足や疲労、航空会社の運航手順の不備といった人的・組織的な要素も徹底的に検討しなければならないと規定されている。これにより、複合的な原因が解明され、再発防止策が効果的に講じられる。

最終報告書の内容(12か月以内に提出が推奨)

1. 事故の原因:

  • 事故原因の特定(技術的要因、人的要因、環境要因など)

  • 事故に寄与した要因(整備ミス、パイロットエラー、設計欠陥など)

2. 技術データの詳細分析:

  • フライトデータレコーダー(FDR)のデータ解析(速度、高度、エンジン状態、機体の動作)

  • コックピットボイスレコーダー(CVR)の音声解析(パイロットの会話、アラーム音など)

  • 機体やシステムコンポーネントの異常に関する分析

3. 人的要因の詳細分析:

  • パイロットや整備士の訓練状況や勤務状態の評価

  • 乗員の心理状態や疲労の確認

  • パイロットの意思決定や操作ミスの要因分析

4. 安全提言:

  • 再発防止のための具体的な対策(訓練プログラムの見直し、機体設計の改善など)

  • 業界全体に適用される運航手順や安全管理体制の改良案

4. 事故後の改善策は世界中で即時共有


事故調査の結果は、ICAOのADREPシステムを通じて、全世界の航空会社や製造業者に即時に共有される。ADREP(Accident/Incident Data Reporting System)は、事故データを一元的に管理し、各国の航空機関が事故原因や再発防止策を共有できる国際的なシステムである。これにより、同様の事故が再発しないように、各国の航空業界が統一した対策を取ることが可能となる。


まとめ

航空業界は、事故が発生した際に「誰に責任があるか」ではなく「なぜ事故が起きたか」を優先して徹底的に調査し、その結果を全世界で迅速に共有する仕組みを整備している。
具体的には
・事故発生後に各国が即座に行うべき報告や調査の流れ: ICAOのAnnex 13
・詳細な事故状況を確実に収集する: フライトデータレコーダー(ブラックボックス)
・事故の調査結果の集約、世界展開のためのシステム: ADREP
が整備されており、業界全体で原因追及と再発防止が行える仕組みが整備されている。

システム開発に活かす、不具合対応の4原則


航空業界での事例を紹介してきたが、システム開発でもそのまま参考になる要素になっている。
各項目ごとに紹介していく。

1.不具合発生時、即座に状況報告しているか。責任追及していないか


サービスの本番で不具合があった時、速やかに
・発生した事象、環境
・影響範囲
を組織内で報告できているかが、原因追及のための初動としてとても大切である。
その中でも
事故調査の目的は事故やインシデントの再発を防止することであり、責任や賠償のために行うものではない
ことがキーポイントとなる。
本番不具合が発生したということ自体、関係者にとってはストレスなことで、組織に文化として根付かせるのは大変なこと。
まして責められてしまうと不具合を隠す慣性が働いてしまう。
もし組織内に不具合の即時報告の仕組みがあるのに文化が根付いていないとしたら、不具合の責任を追及する雰囲気になっていないかを確認することが必要。

2.プロダクトに「ブラックボックス」はあるか。不具合を詳細に再現可能なログがあるか


発生した不具合を正しく確認、検証するにはユーザー・システムログが正しく詳しく出力されていることが重要になる。

・ユーザー行動を時系列で終える行動履歴ログが出力されているか
・出力されたエラーには、具体的なエラー内容やパラメータが出力されているか
・システムの各コンポーネントの状態がモニタリングできる状態になっているか
・重篤な障害時でもエラーが出力されるか

など、プロダクトのブラックボックスの性能が十分な水準にあるか点検してみるのも必要である。

3.不具合の原因究明において、人的・組織的原因も含め深く振り返れているか


複数のチームを見てきた中で、不具合発生数が芳しくないチームは原因振り返りの観点の幅、深さに課題があることが多い。
ある程度経験したりフィードバックを受けないと原因振り返りの練度を上げるのは難しいため、私が中に入って不具合振り返りの報告を聞いてフィードバックすることも多い。

私がよく指摘するのは下記観点である。

エラーの直接的な技術原因のみを振り返り、そこだけを直している
 ではなぜその事象が起きたのか、もっと上流の実装に問題はないか
 設計に問題があるのではないか
・実装/運用のワークフローの観点で振り返りができていない
コードレビューが行えているか。観点漏れはないか
 作業フロー上ヒューマンエラーが起きやすい仕組みになっていないか
 など、技術的観点以外で不具合を引き起こした原因があることが多い。
・メンバー構成と担当に課題がある
 最近メンバーの入れ替わりがあり、今までやっていたフローが抜け落ちた
 経験が浅いメンバーが多く、ノウハウの共有が追いついていない
 フローに関わるエンジニア以外のメンバーが人手不足で回っていなく
 ミスが起こりやすい
 など、体勢に起因する課題も多くある

自分たちで深く振り返るように頑張るのも大事だが、一番効果的なのは
振り返りの品質を深い観点でフィードバックしてくれる人を立て、定期的に壁打ちすること
だと思っている。
私がとあるゲームのバックエンドリーダーをやっていた時、
・不具合が発生するたびに事象と再発防止策をまとめる
・月に1回、ゲーム事業部のCTOに不具合を報告する
・再発防止策が再発防止策になっていないとボコボコにされる
・次は絶対精度高くやろうと振り返りを頑張る
のサイクルの中で、個人もチームも振り返りの精度を上げていった。

4. 振り返り結果を組織全体に共有しているか


振り返りは得てして、不具合に関係した少数のエンジニア内に閉じてしまうことが多い。
原則、チーム全体・会社全体に不具合の振り返り結果を共有することが大事。

・視野の狭い振り返りになっていた時に指摘をもらえる
・プロダクトに関わる人が、何が起きていて次はどうしていけば良いか分かる
・関連した業務・プロダクトを行っている人が、似た不具合を起こさないための糧になる

など、組織レベルでの不具合再発防止を行うためには振り返りの共有が大事である。

まとめ: 不具合はすぐに共有できる文化を、振り返りは多角的に


不具合再発防止できるチームを作るにあたり、
・すぐに報告する文化をつけるのが大事。そのためのに責任追及ではなく原因追及に重きを置くことを宣言する
・原因の振り返りは直接的な原因だけでなく、人や組織の観点でも振り返る
・振り返りの精度を上げていくために、壁打ちの相手を確保する

のが良い。


いいなと思ったら応援しよう!