2012年01月12日

◆ エラーの回避路

 エラーが起こったときも安全であるようにすることを「フェイルセーフ」という。
 それとは別に、エラーが起こったときに問題を回避するように、あらかじめシステムを設定することができる。(エラー時の回避路を用意しておく。) ──

 フェイルセーフという概念は、すでに知られている。これは、エラーが起こったときも安全であるようにすることだ。
 端的な例は、原発事故だ。津波が襲ったときにも原発を安全にするように防潮堤や建屋を整備しておけば、万一の津波にも対処できる。
 同様に、JR西の事故では、電車が脱線しそうになったときに自動的にブレーキをかけるシステムとしてATSというものがある。これもフェイルセーフとして認識できるだろう。

 ただし、フェイルセーフのシステムは、一般に、金がかかる。浜岡原発で津波対策の防潮堤には 1000億円がかかる。JR西の例ではATSの整備にやはり数百億円ぐらいの金がかかるだろう。どちらも金がかかる。
 これがフェイルセーフによくある難点だ。(必ず金がかかるというわけではないが、対策が大規模になることが多いので、金がかかる。)

 ──
 
 さて。次の事例が報告された。
 大学入試センター試験で、受験生の一部で混乱が生じている。従来は試験場で入試科目を自由に選択できたが、それだと問題が生じたので、受験科目を事前申請する方式に変えられた。ところが、事前申請で、受験生がミスをすることがあった。外国語の科目を「受験する」のつもりで「受験しない」という記号を記入してしまった。内容確認の葉書で気づいたので、訂正を申請した。しかしその訂正の申請が反映されていない。受験票には、「受験しない」のままになている。そこで試験日の前に「受験する」に変更してくれと申し込んだが、事務局では「そんなことできません」というばかり。
( → 朝日新聞・夕刊 2012-01-12。要旨。)(ネットにはない。紙の新聞だけ。)
 さて。この事例でも、エラーが生じている。では、このエラーでは、どう対処すればいいか? 何らかのフェイルセーフのシステムを用意すればいいか? いや、そうではあるまい。

 ──

 ここで、ソフトウェアのプログラミングに話は飛ぶ。次の構文がある。
   On Error Goto XXXX

 これは「エラーが起こったら、XXXX というところへ飛べ」ということだ。では、その意味は? 
 「エラーが起こったときにはどうすればいいか、ということを、あらかじめシステムに組み込んでおく」

 ということだ。
 このような措置を取ってあれば、エラーが起こっても、何も問題はなくプログラミングは遂行される。一方、このような措置を取ってなければ、プログラミングは暴走する(もしくは終了する)。……その場合は、「バグ」と呼ばれる。

 ──

 ここまで見れば、わかるだろう。先の受験生の事例では、システムにエラーが起こった場合の措置が組み込まれていないのだ。つまり、システムにバグがあるのだ。そのバグのせいで、受験生はきちんと受験することができなくなってしまった。(この事例でいうと、東大を受験するつもりだった一浪生が、どの国立大も受験できなくなってしまった。外国語はどの国立大学でも必須だからだ。……そもそもそれほど深刻な被害をもたらす「外国語を受験せず」なんていう項目を、安易に用意しておくのも呆れるが。)

 ──

 ともあれ、今回の受験生の事例を見ると、物事を一般化して認識できる。それは「フェイルセーフ」という発想とは別の安全対策がある、ということだ。その安全対策は、「 On Error の対策」とも言える。日本語にするなら、「エラー時の回避路」とでも言えばいいだろうか。
 エラーというものは、一般に、不可避だ。どこかで何らかのエラーが起こることがある。それでも、「エラーが起こったら致命的になる」というのでは、そのシステムは良いシステムではない。いったんエラーが起こったら、本来の正規の経路とは別に、回避路をたどって、無事にプログラミングを終了するようにできるよう、システムをうまく設定しておくといい。起こるべきエラーをあらかじめ想定して、そのエラーへの対処を用意しておくといい。

 そして、それが最も成功した例が、「はやぶさ」だ。どういうエラーが起こるかはすべて予想することはできなかったが、おおまかに「たとえこれが駄目になってシステム全体は致命的にならないように」というふうに、システムが多重に安全措置を取っておいた。
 そして、そういう措置をきちんと用意しておけば、あとでこう言えるのだ。
 「大丈夫だ。こんなこともあろうかと」
 


 [ 付記 ]
 ま、簡単に言えば、こうだ。
 「プログラミングにおけるシステム設計の方法を、一般の制度設計にも援用せよ。特に、エラー時のエラー回避の方法を、きちんと整備せよ」
 そして、これができていれば、JR西の事故も起こらなかったはずなのだ。ATSの整備という巨額の費用のかかることをしなくても、「運転手が小さなエラーをしたときには、そのための制度を用意しておく」というだけで、事故は防げた。
 実際には、それとは逆で、「運転手が小さなエラーをしたときには、運転手が一か八かのギャンブルをするように仕向ける」という非常に危険な制度を用意しておいた。これが事件の根本原因である。そしてギャンブルの結果が裏目に出た。
( ※ 事故の詳しい背景は、「泉の波立ち 2012-01-12」を参照。)



 【 関連サイト 】

  → はやぶさの動画 (こんなこともあろうかと)
 
  → 東電 「津波は想定を超えたので……」
posted by 管理人 at 19:37| Comment(4) | 安全・事故 | 更新情報をチェックする
この記事へのコメント
>内容確認の葉書で気づいたので、訂正を申請した。
その申請は届いているのでしょうか
不配の可能性が否めないメールや普通郵便で申請したのなら受験生のミス

>そこで試験日の前に「受験する」に変更してくれと申し込んだ
遅すぎますね

○日までに変更通知が来ないなら再申請
受験票が届いた時点で再申請
という当たり前のエラー処理が想定外だったのでしょうか
試験日の前の変更申し込み=一か八かのギャンブル
ですよね

受験生の方にエラー回避路が必要だったと思います
Posted by linu at 2012年01月13日 10:14
>>そこで試験日の前
>遅すぎますね

 記事では明確でありませんでしたが、試験日の直前じゃなくて、かなり前であるようです。何日(何十日?)も前に訂正を申し込んでいるのに、訂正を拒まれたらしい。
 受験生のせいじゃないようです。

> 受験生の方にエラー回避路が必要だったと思います

 エラー回避路がなかったことが問題だ、という趣旨で本項を述べています。受験生も同様。うっかりだったわけではない。うっかりは最初だけ。そのあとは最善を尽くしたが、受け入れてもらえなかったらしい。
Posted by 管理人 at 2012年01月13日 21:07
大学入試センター試験は、14日からだそうです。
 システムに問題があることは 11日の段階でわかっていたのだが、それでも対処ができないまま、14日の本番を迎えることになりそうです。
 受験生がどうにかすればいい、という問題じゃない。訂正の受付窓口が存在しないシステム自体に問題がある。
Posted by 管理人 at 2012年01月13日 21:08
問題が起こったときにどうするべきかを、あらかじめ想定しておくことで、いざというときに対処できる。

その実例。

 → ニューヨーク・フィルの「iPhone 着信音事件」、その時指揮者は?
 http://www.newsweekjapan.jp/reizei/2012/01/iphone.php
Posted by 管理人 at 2012年01月13日 21:10
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

※ブログオーナーが承認したコメントのみ表示されます。
過去ログ