羽田空港の管制はなぜ止まったのか？：何かがおかしいIT化の進め方（19）（3/3 ページ）

[公江義隆，＠IT]

ケーススタディ――皆さんの会社は大丈夫ですか？

　さて、羽田空港の話に戻そう。事故を起こした電源回路は、管制用レーダーなど空港の重要機能を担う機器用に、電力会社からの2系統の引き込みと2系統のCVCF（バッテリバックアップによる無停電装置）と非常用発電機からなる、コンピュータセンターの電源回路などでおなじみの構成のようである。新聞報道では、「電源ダウン時には空港事務所内の配電盤の日常点検作業が行われていた」や「非常用電源に切り替わったが、当時ブレーカーの交換工事が行われていた」とある（新聞・TVなどの報道以外に情報を持たないので、以上はこの範囲での話である）。

　今回の事故を参考に（真偽のほどは別として）、一般的にありそうな話として、ケーススタディ風に以下にまとめてみた。皆さんは何が問題だと思いますか？

　日常点検作業でブレーカー交換の必要性が見つかり、電気を止めてブレーカーの交換工事を行った。電気が止まると当然、警報が出て非常用電源（バッテリ）に切り替わる（ここまでは正常のようだ）。バッテリは50分しか持たないので、本当の停電だった場合には、このときに出た警報に従って担当者が非常用発電機の起動を行う手順なのだろう。

　点検や工事のために電気回路をいじる際には、そのために警報が何度も出ることがよくある。点検・工事を行っていることを知っていた監視室の担当者は、警報が出ているのが工事のためと判断して、特に注意を払わなかったとしても、責めるのは酷かもしれない（注1）。不幸にしてブレーカーの取り替え工事は、50分では終わらなかった。さらに監視室の担当者は、バッテリに切り替わっていることを認識していなかった。50分後バッテリは放電し尽くした。そして、起こるべきことが起こった……というケースである。

　このとき、すでに着陸体制に入っていた飛行機は目視で滑走路に着陸した。視界不良時であったら大惨事につながっていたかもしれない。羽田空港のケースでは、50便が欠航、22便が他空港に振り替え着陸、338便が30分以上の遅れ、延べ8万3000人が影響を受けた。

現場で点検・工事を行ったのは恐らく、この施設の電源系統全体がどのようになっていて、バッテリが50分しか持たないことを関知する立場にない外部の業者だろう。監視室のオペレーターは、マニュアルに従った行動が義務付けられているのが普通だ。自分で臨機応変に考えて行動するようには訓練されていない場合が多い。

　今回の点検・工事は、いままで何の問題もなく、以前から何度も日常的に行われてきた作業である。設備管理の責任者は、全体を知ることのできる立場ではある。しかし、点検のたびに内容を確認し、万一を想定して種々の手順を考えて担当者に衆知徹底が必要な大工事ではなかったし、リストラが進み効率化が要求される中で、全体と詳細をともに把握できている人はもはやどこにもいない――詳細を知っているのは現場の担当者や業者だが、彼らは自分が担当する部分だけしか分からない（注2）という事態になっていたのではないだろうか。

　問題を少し一般化すれば、担当者がほかとは関係ないと思い、それぞれの担当範囲の判断でこなしてきている「日常に埋没した作業」で、ほかとのわずかな意識の食い違いや慣れからくる油断（注3）が大問題を引き起こした例である。このようなことはIT分野でも方々にありそうである。

　皆さんの会社では、どうされていますか？

---

（注1）

　高価な美術品を狙う盗賊が、その美術品に近づくと出る警報を何度も作動させ、そのたびに駆け付ける警備員がついに頭にきて、警報装置の故障と判断して警報装置のスイッチを切ってしまうのを待って、悠々と盗みを成功させるという外国映画があった。

---

（注2）

　全社の情報システムの全容を把握できているといい切れる企業は、いまどのくらいあるであろう。

---

（注3）

　複数要因が重なり合っている場合には、理論上の発生確率が低く、本来なら起こらないはずの事故が実際にはよく起こる。例えば、それぞれの発生確率が、1000分の1である3つの事象が同時に起こらないと事故が発生しないという問題があったと仮定しよう。

　理屈では、この事故の発生確率は10億分の1である。これは1日1回を毎日、50年間続けたとしても、10億分の2万弱の確率（約0.002％）にしかならない。しかし、現実には大変危ない状況になっている場合がよくある。複数要因が重なって大変危なくなる例として、交通量の少ない交差路での出会い頭の衝突事故を考えてみる。

　早朝の通勤時に横路から出てくるドライバーのA氏は、この交差路で車や人に出くわしたことは、いまの会社に勤めだしたこの十数年間に1度もない。その結果、一時停止もしなくなり、この場所における注意力も落ちている。この場合、ほかの条件次第で事故を起こす可能性は1000分の1どころか、限りなく1に近い。歩道を猛スピードで走り抜ける新聞配達の自転車は、左右の確認などしない。車は止まってくれるものと思っている。ここでも確率は1に近い。理屈で10億分の1と思っていても、実際には1000分の1、タイミングさえ合えば必ず事故が起こる状況になっている。しかし、誰もそのようには意識していない。

---

profile

公江 義隆（こうえ よしたか）

ITコーディネータ、情報処理技術者（特種）、情報システムコンサルタント（日本情報システム・ユーザー協会：JUAS）

元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業（経済産業省）、沖縄型産業振興プロジェクト（内閣府沖縄総合事務局経済産業部）、コンサルティング活動などを通じて中小企業のIT課題にかかわる

「何かがおかしいIT化の進め方」バックナンバー

• IT関係者は、原発事故から何を学ぶべきか
• 優れたシステムを作るための“思考力、人間力”とは？
• “影”から目を背けてきた原発とIT
• 他山の石――政治を顧みて学ぶマネジメントの在り方
• 「想定外」から脱却できる、真の対策を
• 失敗は成功のもと、成功は失敗のもと
• いまあらためて確認したい、情シスのイロハ（後編）
• いまあらためて確認したい、情シスのイロハ（前編）
• 持続可能社会とITシステムはどう在るべきか（後編）
• 持続可能社会とITシステムはどう在るべきか（前編）
• 新型インフルエンザ対策に学ぶ組織の在り方
• 変化の中で、自らを制御できるものが生き残る
• “変化”を模索する世界（後編）
• “変化”を模索する世界（前編）
• “変化”は外からやってくる（後編）
• “変化”は外からやってくる（前編）
• その考え、本当にあなた自身のものですか？
• 事の本質を見極めよう
• 適材適所の人材育成をしよう
• コンプライアンスを語る前に考えてみること
• “シックオフィス”で健康を損なっていませんか？
• ゆでガエルになる前に情報子会社は経営の見直しを
• ディスカッションテーマのおもちゃ箱（2）
• ディスカッションテーマのおもちゃ箱（1）
• 有能なプロジェクトマネージャを育てるには（3）
• 有能なプロジェクトマネージャを育てるには（2）
• 有能なプロジェクトマネージャを育てるには（1）
• SOX法とコンプライアンスとIT
• リーダーシップを発揮するにはどうすれば？（後編）
• リーダーシップを発揮するにはどうすれば？（前編）
• 情報システム部は、もう役割を終えてしまったのか？
• 阪神大震災10年目に考えること、するべきこと（後編）
• 阪神大震災10年目に考えること、するべきこと（前編）
• “気付き”のコミュニケーション――機能や仕組みの説明は理解に結び付かない
• JR脱線事故からマネジメントを学ぶ
• 羽田空港の管制はなぜ止まったのか？
• IT徒然草――コストと利便性を追い求めて失うもの
• 理想的な上司と部下の関係とは――部下の育成方法
• 続・いまのIT組織でいつまでやっていきますか？
• いまのIT組織でいつまでやっていきますか？
• ITの動向や他社の状況を、気にし過ぎていませんか？
• IT化と投資の“正しい”関係とは？（後編）
• IT化と投資の“正しい”関係とは？（中編）
• IT化と投資の“正しい”関係とは？（前編）
• ブレークタイムでの話題製品と情報化のコンセプト
• “誰にでもやさしい”ITは良いことなのか？
• ブレークタイムに“設計思想”を語り合おう
• 仕事への取り組み方は最初の数カ月で決まる！
• 優秀なスタッフを育てる職場環境とは
• 全社IT最適化のカギは「データ体系の統一」