2007年05月29日

ANAのコンピュータトラブルとリスクマネジメント

 5月26日ごろにANAのホストコンピュータトラブルが発生し、5月27日のANA全便が欠航となるトラブルが発生し、7万人の乗客に影響を与えた。一番痛いのは、航空運賃の払い戻し、補償などで数十億円に上る損失を発生させたことだと思われます。これは、経営判断の問題だけではありません。システムの開発企業だけでなく、航空会社の経営者も、技術の考え方をある程度理解していないところに起因していると考えられます。

 今回のトラブルの原因は、ホストコンピュータを更新しようとしてそのデバッキングがうまくいかなかったことだとされています。ほぼ、1日が経過してから、元のプログラムに戻して復旧させたことになっています。ここに、経営者としての技術分野への見識、エンジニアとしての仕事の進め方など大きな問題点がいくつか隠されているようです。一部の取材記録には、実際に試して見なければわからないとか開き直ったコメントもあるようです。

 ところで、ジェットコースターの車軸の金属疲労が原因で脱線し人の命を奪ったり、ガス湯沸かし器やガスファンヒーターでCO中毒で死亡事故を発生させたり、数社のシュレッダーメーカーで指切断事故を発生させたのはつい先日の出来事でした。本来は設計段階で予防保全を実施するのがよいのですが、ある程度の事故の可能性を予測したリスク分析を実施して、その対応まで踏み込む必要性があることです。これは、技術者教育の基本的問題でもあると考えられます。

 問題点の1つ目は、プログラム更新の計画スケジュールにコンテンジェンシープランが入っていなかったと言わざるを得ないことです。社会的に影響の大きな問題になる可能性の高いテーマであるはずです。2つ目は、デバッキングの方法です。現場のプログラム運用の中で、約10時間もデバッキングしていまったということです。3つ目は、最近のジェットコースターの事故、携帯電話会社のトラブル、銀行のATMのトラブルなど他の失敗の教訓を学んでいないということです。つまり、MOT(技術経営)やリスクマネジメントの教育の欠如ではないでしょうか。

 
<スピード発想術書籍URL>
 http://gihyo.jp/book/2010/978-4-7741-4106-0
<ぷろえんじにあHP>
 https://www.proengineer-institute.com/

40の発明原理の使い方:
 方法 A: 根本原因や真の目的を熟考後、オズボーンのチェックリストと同様に、発明原理の No1〜No40 を順番にスキャンしてそこからヒントを得てアイデアを発想する。

 方法 B: 矛盾マトリクスから「改善したいパラメータ」と「悪化するパラメータ」の交点の発明原理をヒントにアイデアを発想する。(適用事例を参照

 但し「図解これで使えるTRIZ/USIT」から出版社の許可を得て転載しています。


40の発明原理No26代替原理(表をクリックで拡大)
26.gif

40の発明原理リスト(表をクリックで拡大)
z.gif


【関連する記事】
posted by proengineer at 00:02| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:


この記事へのトラックバック
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。