- share :
- 失敗やヒヤリとした経験を報告してほしいと伝えているのに上がってこない
- 報告フォームやチャットといったデジタルツールを用意しても使われない
多くの職場が抱えるこの種の悩みは、「報告する人の勇気や配慮が足りない」「」と受け止められがちです。
しかし航空の世界には、危うい経験が社内で共有されていたのに、その情報が活かされないまま、別の会社の便で同じ誤解による事故が起きた例がありました。この事例では、先行便の経験は確かに社内で共有されていたにもかかわらず、事故を防げなかったのです。
本記事では、この事故をきっかけに米国が作った航空安全の報告制度を例に、失敗の報告が集まり、活きる条件を解説します。欠けていたのは個人の勇気ではなく、会社の壁を越えて届く回路でした。報告を「検索できるデータ」に変えたこの仕組みは、フォームやチャットで失敗を集めやすくなった今の職場にも通じる話です。
【本記事の要点】
- 事故の約6週間前に同じ誤解を経験した別会社の便の情報は、その会社の中で共有されていた。欠けていたのは勇気ではなく、会社の壁を越える回路である
- NASAの報告制度は、報告の受け手を処分する側から分け、識別情報の扱いと免責の境界を決めた
- NASAは、集めた報告を警報や検索できるデータなどの出口で現場へ戻した。報告の件数は、自発報告にもとづく数として読む
- 報告が集まる条件は、入力画面の外、つまり報告を受け取る人とその後の行き先にある。デジタルで書きやすくなった今こそ、書かれた失敗が検索できるデータとして誰に届くかが問われる
同じ誤解を経験した便の情報は、事故の6週間前に社内で共有されていた
危うい経験が社内で共有されていたのに、同じ誤解による事故が起きたのはなぜでしょうか。この章では、1974年のTWA514便の事故を例に、先行便の経験が社内で共有されていた経緯と、そこに欠けていたものを整理します。
先行便の経験は、社内で共有されていた
1974年12月1日、TWA514便がワシントン・ダレス空港への計器進入中に山へ衝突し、搭乗者全員が亡くなりました。事故機の乗員は、管制から受けた進入の許可の意味を取り違え、本来より早い段階で1,800フィートまで降下していたのです。
NASAの資料によると、約6週間前に、事故機とは別の航空会社の便が、同じ進入方式で同じ混乱に直面しています。この先行便の経験は、先行便の会社の中で、ほかの操縦士にも共有されていました。それにもかかわらず、別の会社の便による事故は起こってしまったのです。
出典・参照:
欠けていたのは、会社の壁を越える回路だった
当時の航空界に足りなかったのは、一社の経験を、他社を含む航空界全体へ流す仕組みでした。失敗の情報は先行便の会社の中に存在していても、別の会社の乗員が引き出せる形では存在していなかったのです。
この事故を受け、米国の連邦航空局(FAA)は、米国航空宇宙局(NASA)に、報告を集める制度の構築と運営を依頼しました。航空会社や、取り締まりを担うFAA自身から切り離された第三者に、報告の受け手を移したのです。この制度の運用は1976年4月15日に始まりました。
失敗の報告が集まらない原因を、個人の勇気や職場の雰囲気に求める前に、報告された失敗がどこまで届いているのかを確かめる視点。まずは、その仕組みを作ることの重要性が分かる事例ではないでしょうか。
報告の価値は、書かれた場所ではなく、ほかの人の判断に使われる場所で決まるのです。
出典・参照:
NASAの航空安全報告制度は、匿名フォームと何が違うのか
NASAの航空安全報告制度(Aviation Safety Reporting System、以下ASRS)が変えたのは、入力画面ではなく、報告の「行き先」でした。では、実際にはどのような手法が取られたのでしょうか。
処分する側と、受け取る側を分けた
報告を受け取るのは、規制と取り締まりを担うFAAではなく、NASAです。FAAは、ASRSへの報告を取り締まりに使わないと約束しており、NASAは分析のあと、報告者を特定できる情報を取り除いたうえで報告を扱います。NASAは取り締まりを担う立場から切り離されているため、報告者は、書いた内容が処分の材料にされないと見込んで報告できる。この構造が重要だったのです。
出典・参照:
完全な匿名ではなく、聞き取りのあとで識別情報を消す
ただし、ASRSは、最初から完全な匿名で受け付ける仕組みだったわけではありません。報告には報告者を特定する欄があり、分析官が不明な点を確認するために連絡できます。確認が済んだ後、NASAの側で人物と組織の名前を取り除き、日時など識別につながる情報も一般化するか削除します。データベースに入る報告は、この処理を経たもので、共有されるデータには誰が書いたかが残りません。
完全な匿名では、分析官が問い返せず、原因を分析できません。かといって、実名のまま上司に直接届ければ、報告をためらう人が出てくることも予想されます。これを避けるために、ASRSは、誰が、いつまで、何のために識別情報を持つのかを決めることで、この間を取ることにしたのです。
なお、上げられた報告は、経験を積んだパイロット、管制官、整備士などの分析官が、少なくとも2人で読むと決められています。
出典・参照:
免責は条件つきで、境界が明確
FAAは、ASRSへの報告や、そこから得た情報を、原則として取り締まりに使わない方針です。ただし、無条件ではありません。民事罰や資格停止が科されないのは、次の条件をすべて満たす場合です。
| 条件 | 内容 |
|---|---|
| 故意でないこと | 違反が意図的でない |
| 重大事案でないこと | 犯罪、事故、資格や能力の不足を示す行為に当たらない |
| 過去の違反認定 | 直前5年間に、FAAの違反認定を受けていない |
| 報告の期限 | 違反または認識から10日以内に、書面をNASAへ出している |
犯罪に関する情報は司法省とFAAへ、事故に関する情報はNTSB(米国の運輸安全委員会)とFAAへ回され、このときの識別情報は消されることはありません。法令などが義務づけている報告の代わりにも、ASRSへの報告は使えません。
しかしこういった境界が先に示されていることで、報告者は何が守られ、何が守られないのかを知ったうえで報告書を書けるのです。守る範囲を限ったことが、約束の信頼につながっていると考えてよいでしょう。
ここまでの要素を、本記事では「行き先」と呼びます。誰が報告を受け取り、何には使わず、識別情報をいつ消し、集めた後に何へ変えて現場へ戻すか、という取り決めの組み合わせです。
出典・参照:
集まった報告は、どう現場に戻されたのか
集めた報告は、その後どのように現場へ戻されたのでしょうか。この章では、ASRSが報告を現場へ返す出口と、報告を探せるデータにした意味、件数の読み方を整理します。
警報、検索できるデータ、ニュースレターという出口
ASRSは報告を保管するだけではありません。分析官が危険を見つけると、それを是正できる立場の組織に警報として伝えます。警報のほかにも、報告は次の形で現場へ戻されます。
| 出口 | 内容 | 主な使い手 |
|---|---|---|
| 月刊ニュースレター | 報告にもとづく情報を毎月届ける | パイロット、管制官など |
| 検索依頼への回答 | 指定されたテーマの報告を、データベースから探して提供する | 政府、産業界、大学 |
| 運用支援 | 関連データを集めて渡す | FAA、NTSB |
| テーマ別の研究 | 研究を公表する(60を超える) | 各分野の担当者 |
NASAの2026年4月の発表では、受け取った報告は累計230万件を超え、警報は8,150件を超えています。NASAは、ASRSの情報が、乗員同士の連携を整える訓練や、操縦室での不要な会話を制限するルール、衝突を避ける装置などの検討に役立ったと説明しています。ここで言えるのは、危険の情報が現場と規則づくりの双方に届いたという範囲です。
なかでも注目に値するのは、報告を「読むもの」から「探せるデータ」に変えた点です。
ASRSは、自由な文章で書かれた報告に分類をつけ、オンラインのデータベースとして検索できる形にしています。230万件もの文章を人が1つひとつ読んで参考にすることは現実的ではありません。分類されたデータになっているから、後から別の会社の誰かが、自分と同じ型の失敗の報告を数ある中から探し出せるのです。
事故の前に先行便の経験が会社の壁を越えられなかった問題は、報告をデータとして蓄積し、検索で引けるようにしたことで解かれたのです。
出典・参照:
件数の読み方
報告の件数は、危険度の指標ではありません。ASRSの報告は自発的に出されたもので、統計的な抽出によらないため、実際に起きた事象の総数との関係をNASAは確定できないとしています。件数の増減は、事故の増減や安全性の変化を示す数字としては使えないのです。
一般企業の場合でも、自社の報告を件数ではなく、集まった報告が何に変わったかで見るほうが実態に合うでしょう。
出典・参照:
まとめ:失敗の報告が集まる条件は、入力画面の外にある
失敗の報告が集まる条件は、入力画面の外にあります。事故の約6週間前に同じ誤解を経験した便の情報は、その会社の中で共有されていました。それでも、別の会社の便で同様の事故が起こってしまったのです。このとき足りなかったのは個人の勇気ではなく、会社の壁を越えて経験が「教訓」として届く回路でした。
- 受け手を処分する側から分ける
- 聞き取りのあとに識別情報を消す
- 免責の条件を明確にする
NASAの報告制度は、こうしたことを明確にしたうえで、集めた報告を、警報や、分類された検索できるデータとして現場に戻す設計にしたのです。
一般企業の職場でも、今やフォームやチャットのおかげで、失敗を「書く」ことはずっと簡単になりました。だからこそ、書かれた失敗が、データとして誰の画面に届き、そこで何に変わるのかが、成果を分けるのではないでしょうか。
貴社の現場で起こった失敗の報告は、いまどこへ行っているでしょうか。ほんの少し、そのことに目を向けてみてはいかがでしょう。
執筆者
DXportal編集長
町田 英伸
自営での店舗運営を含め26年間の飲食業界にてマネージャー職を歴任後、Webライターとして独立。現在はIT系を中心に各種メディアで執筆の傍ら、飲食店のDX導入に関してのアドバイザーとしても活動中。『DXportal®』では、編集長としてすべての記事の企画、及び執筆管理を担当。特に店舗型ビジネスのデジタル変革に関しての取り組みを得意とする。「50s.YOKOHAMA」所属。


