今日（2009年9月9日）の朝早くに東京メトロ東西線で始発電車に保守車両が衝突する事故があったようです。原因は保守車両（Aとする）が脱線事故を起こして動けなくなったことにより保守車両（Bとする）が本来帰るべき場所に帰れなくなったことだそうです。それによりBの保守車両は想定と異なる場所に向かって進むことなったのですが、漏水事故で本来いるはずの位置と異なる場所にいた始発電車に衝突してしまったとのことでした。なお始発電車のダイヤを守るために社内規定を上回って（時速35キロメートル→40キロ）運転していたとのことです。

先週（2009年9月3日）には成田エクスプレスが同様に保守車両に接触しています。こちらはサービス状態の線路の隣で工事していた車両の運転ミスだそうです。リモコンでの操縦だったそうです。

工事車両による鉄道事故というのは珍しいことではないようで、外国の事例になりますが2009年8月27日にはトルコで停車中の工事車両に急行電車が衝突し、4人が亡くなっています。

• 2009年9月7日には名鉄名古屋本線矢作橋駅の近くで列車が工事用の柵に接触
• 2009年3月17日には天竜浜名湖鉄道原田駅の近くで列車と工事用のショベルカーが接触
• 2009年2月27日には近鉄大阪線の東青山駅の近くで工事の際にレール切替装置の撤去が忘れられ、想定外の路線に進入した車両がカーブを曲がりきれず脱線
• 2007年11月18日にはJR東海道新幹線京都駅の近くで列車が工事ミスにより指定位置と異なる場所に設置された信号機に接触
• 2006年5月10日にはＪＲ関西本線の河内堅上－三郷間で列車が線路上に放置されていた保線作業用台車と接触
• 2005年5月28日にはJR東海道線の尼崎駅近くで列車が工事終了後に撤去するのを忘れられてしまった看板と接触
• 2003年10月6日にはJR京浜東北線の大森―大井町駅間で列車が線路内にあった工事用重機の鉄製ショベル部分と接触

そして私の記憶にある最大の事故といえばドイツのトランスラピッドの事故です。こちらは2006年9月22日にいわゆるリニアモーターカーであるトランスラピッドが磁気で浮上して時速200キロメートルで工事用車両に衝突して20名以上が亡くなったという事故です。失敗知識データベースによるとこの事故の原因のひとつとしてこんなことが挙げられています。

２．保守車両がリニアモーターカー走行軌道上にいる場合の自動停止システム（上記人的ミスのカバーのため）がなかった。
リニアを運行していたIABG社は数年前、現場から「保守車両にも安全対策を施すべきだ」との提案を受けながら、衝突防止装置など安全策を実施しなかった。同社は「監督官庁である州に認めてもらえなかった」と釈明した。

おそらく今朝の東西線の事故は工事用保守車両が始発電車の位置を知ることができなかったのではないかと思います。もしくは焦りなどの要因で知るための余裕がなかったのかもしれません。

また成田エクスプレスの事故ではリモコン操作による空間認識の薄れなどが原因で工事車両が線路に突き出していることがわからなかったのかもしれません。

いずれにせよ、後から「列車の位置を知る装置があれば」ですとか「工事車両が飛び出ないようにフェンスやセンサーをつければ」ということは簡単に言えるのですが、最初からそれをやるのはとても難しいことです。また精神面での引き締めを求めることもよく言われますがそれで済んだら世の中から事故という事故はなくなっているでしょうから、監視要員を増やすですとか、機械に任せられるものは機械に任せるということが（両方眠くならない程度に）正しい対処ではないかと思います。

さてこういった事例を蚊帳の外からつっついても仕方ありませんので情報システムの世界に置き換えて考えてみますと、様々な教訓を得ることができます。

「工事」のような作業はシステムの運用でもよく発生するもので、破損したディスクを交換するためにバックアップを取るですとか、バージョンアップのために待機系に本番プログラムを移しておくということがあります。

例えば東西線の事故では「想定外の車両移動」と「本来いる場所でないところに始発電車がいた」という2つの事象が原因に関わっていそうな感じです。システムの作業でもテークオーバーやバックアップなどで想定外のファイル移動やマウントの変更が発生します。また、プライベートなPC作業を含めれば、ファイルのコピー時に「データがないと思っていた」場所を指定して上書きしてしまったというミスをしたことのない人はいないといっても過言ではないでしょう。ええ、つい最近やりましたから。プライベートですけど。

しかし最近のJavaやVBで作られたプログラムが容易にOSをクラッシュさせられないように、情報システムの世界もかなり色々な方面で安全になってきています。同様に鉄道も通常運転中の事故というと機械の故障と不可抗力な事故（自殺など）がほとんどであるようです。そのため、鉄道では工事に起因する事故が多くなっているように感じられますし、情報システムではリリースや計画外の保守作業に伴う障害が増えているように感じるのかもしれません。

もちろんダイヤ遵守への過剰な期待が東西線のような「焦り」によるミスを引き起こすことを忘れてはならないでしょう。これについては、情報システム業界としてはお客様に対して余裕をもった作業計画を提示し、ダメそうな場合は作業完了予定時刻の何時間前に一報入れるなどの対応策を事前に固めておくことだと思います。

東京メトロや山手線ではホームドアの設置が進められており、ホームからの転落事故を減らせるのではないかと思います。こういったことは一気にすべてを改善するのは難しいかもしれません。しかし日々の事故について原因の究明と改善策を積み重ねることで、人と鉄道システムや人と情報システムがうまくつきあっていけるポイントを探っていけるのではないかと思います。自分はその小さな一歩としてこういった鉄道の事故などにも興味を払うようにしています。