ANAシステムトラブルを考える．
昨日，富山へ1泊で出張だったため，もろに，全日空のシステムトラブルに巻き込まれた．
知人から，「あなたは，出張が大いので，ひょっとして，テレビを眺めていたら映るかも？ と思ってテレビを見ていた」と言われたのですが，はい．その通りです．私は空港にいました．ただし，ずっと羽田にいたわけではなく，払い戻しを受け，そのままタクシーで東京駅へ．どうにか，列車を乗り継ぎ，その日のうちに，富山まで4時間弱をかけ，たどり着いたわけだ．
今回の事件について，いろいろとWebを見た．メインフレーム上でFortranで動いていた既存のシステムが，PCベースのシステムに移行中で，トラブルを起こしたらしく，「やはり，安定性が求められる場所には，メインフレームでなくては．．」という意見が，あちらこちらで出るのではないだろうか．
自治体の行政システムも以前はメインフレームだったけど，今は多くがPCベースに移行した．電話等のライフラインに近い基幹システムも同じ傾向で，メインフレーム派は，なんとか巻き返しをしたいところだろう．実際，メインフレームからPCベースのシステムへの移行段階で，今回のANAのようなシステムトラブルが多発することは大いに予想できる．そして，そのたびに，「やはり，メインフレームが」という意見が出されるのだろう．
正直に言えば，製造現場を周り，今は農業にも取り組んでいる立場からすると，現在のインターネットを取り巻くテクノロジーのいい加減さを実感することが大い．データ転送の仕組みを考えてみると，実感される方も多いのではないだろうか．製造業分野の方に，「インターネットは難しくて．．」と言われると，「皮肉？？」と思うことすらある．実際，ものづくりの技術蓄積と奥深さというのは，ITをやっている人には想像がつかないものであるし，それは，人間が伝統的に培ってきた行為や制度にしても同じ．どうも，IT
関連の人は，これらを軽視する傾向が気になる．もちろんトラブルが少ない方がよいのだが，今のITの技術レベルでは，また同種のトラブルが起こるのだろう．だから，トラブルからどうやって対処するかを考えなければいけない．今回は，そのよい教訓になったのではないか．
もちろん，「トラブルが起きて当たり前」では駄目で，起きないような努力はすべき．そのうえで，万一の場合を考えておかなければいけないわけだ．ここで大事なのが，もう何度も書いている「現場の大切さ」ということ．現場をふまえたシステム設計運用をしていれば，対処ができる．今回のANAのトラブルについて，私が直面して気になった点は，「全く，トラブルが起こることを想定していない，万一の際の現場というものを意識せずにシステム設計運用がなされていたのではないかという事だ．
1. チケットレスサービスを選択していた乗客は，基本的に，その場でキャンセル手続きを取らなければいけなかった
2. 飛行場に，現在のトラブル状況を大きく示すようなサインが，新たに設けられてはいなかった
という点がまず自分自身の経験の中で気になった点である．もちろん，私は，ANAの基幹システムについて，全く把握していないので見当違いかもしれないが，それはあしからず．
まず，上述1点目だが，携帯でチェックインできるチケットレスサービスを選択する客は，ANAが優良顧客と位置づける，乗降回数が多いビジネス客が主体だ．これらビジネス客は，スケジュールを非常に重視する．時間が惜しいから飛行機を利用している．それなのに，時間がたくさんある観光客は，チケットレスでないので，後から郵送でキャンセル処理ができるのに，チケットレスサービス利用客はその場で並んでキャンセル処理をしなければいけない．欠航であれば，搭乗できないのが明らかなわけで，もっと迅速な処理ができたのではないだろうか．これは，システム設計の問題でもあるし，オペレーションの問題でもある．
次に，2点目についてだが，これは，今のIT社会がもたらした弊害なのかもしれない．きれいに整った空間に，張り紙や立て札を立てるという発想がないのだろうか．私が空港に到着すると，そこには，人が溢れていた．彼らの怒りや雑談の声がノイズとなり，館内放送は非常に聞きづらい状況だった．飛行機の搭乗案内の電子掲示板を見ると，「欠航」の文字が．しかし，そこでは理由がわからない．結局，携帯電話からネットにつなぎ，状況を把握した．大学が麻疹による休講を大きく校門前に張り出したように，トラブル発生に関する概要説明が，目立つところに張られなかったのは何故なのか．あるいは，どこかに行けば張ってあったのかもしれないが，少なくとも，私が東京駅まで乗車したタクシーの運転手は，朝から羽田にいたのにもかかわらず，状況を正確には把握していなかった．ITが普及すると，物理的な情報伝達が弱くなるのだろうか．張り紙を増やすのはたいした手間ではなく，非常に有効な方法である．ようは，ITだけに頼るのでは満足に対処が進まない状況がこのようなトラブルの際にはあるということだ．
これら2つのことは，非常に小さな話である．ただ，どちらも，現場を知らない方々が，机上で議論をして設計構築したシステムでは，同種の問題が，繰り返し発生しかねない話ではないだろうか．
今回のトラブルは概ね半日で復旧し，ANAの信頼は，根底から覆されたわけではない．ぜひ，今回のトラブルを教訓にしてほしい．今のITに関与している人の多くは，現在のインターネット関連技術を過信しているように思う．もう一度，現場に立ち返る勇気，努力を忘れないことが，万一のトラブルを迅速かつ的確に乗り切ることにつながるのだと思う．
- 日時：2007年05月29日 01:19
