搭乗システムの大規模障害に見舞われた全日本空輸(ANA)。2008年9月14日に起きたこのトラブルの後、ANAは二つの再発防止策に着手した。

 その一つは、システムに登録してあるセキュリティ関連の設定情報を、毎年1回確認するルールを導入したことだ(図2)。障害が発生した原因が、設定情報の確認漏れにあることを受けての取り組みである。

図2●ANAが取り組んでいるトラブル再発防止策
図2●ANAが取り組んでいるトラブル再発防止策
2008年9月14日に発生した搭乗システムの障害をきっかけに、セキュリティに関する設定情報のチェックや障害監視の体制を改めた
[画像のクリックで拡大表示]

 2008年9月14日の障害時、全国の空港のロビーに設置したチェックイン端末がサーバーに接続できない状況になっていたという。チェックイン端末からサーバーへの接続可能な期限が切れていたからだ。今後は、障害につながりそうな設定情報については逐一確認していく。従来、システム稼働後に設定情報をチェックするルールは特になかった。

 もう一つは、障害監視体制の強化だ。トラブルが起きる前から24時間体制で監視していたが、運用管理責任者は1人だけだった。これをトラブル後に2人体制にした。

 運用管理を担当するのは、情報システム子会社である全日空システム企画のベテラン技術者である。「大規模障害時には関係部署から問い合わせが殺到する。24時間2人体制で応対スピードを高める」(ANAの蔵本直樹IT推進室開発推進部長)。

「徹底した品質管理でトラブルを未然防止」全日本空輸 IT推進室開発推進部長 蔵本 直樹氏
「徹底した品質管理でトラブルを未然防止」
全日本空輸 IT推進室開発推進部長 蔵本 直樹氏

 さらにANAは楽天証券と同様、「システムの品質を向上させることが、トラブル予防につながる」(蔵本部長)として、システム開発のレビュー体制を強化した。システム開発のチェックポイントを、「企画」「分析・計画」「外部設計」「内部設計」「詳細設計」「単体テスト」「機能・統合テスト」「システムテスト」「ユーザー受け入れテスト」「稼働」という10段階に細分化した。

 全日空システム企画の品質管理部門が、各チェックポイントで作成するドキュメントの内容を精査。各フェーズでの成果物に品質面での問題がないかどうかを調べる。ANAは外部のコンサルティング会社と共同でこのルールを策定した。2010年4月以降の新規システムの開発案件に全面適用している。

 ANAの取り組みで注目すべき点がほかにもある。システム担当者全員が過去のトラブルの教訓を忘れないように、トラブルが発生した日のニュース映像を録画したDVDを活用しているのだ。

過去に発生したトラブル
全国の空港の搭乗システムの端末が、認証サーバーの接続期限が切れたため、 2008年9月14日に障害が発生。63便が欠航し、乗客約6万8000人に影響が出た。
(日経コンピュータ2008年10月1日号ニュース)

 映像には、欠航によって乗客が混乱している空港の様子が鮮明に残っている。ANAのIT推進室や全日空システム企画の各部門は、楽しい内容とはいえないDVDの“鑑賞会”を定期的に開く。「トラブルが発生した当時に在籍していなかった若手職員にも、トラブルの教訓を引き継ぎ、再発防止に役立てる」。蔵本部長は狙いを話す。