|
（約4000字）
まず、安全上の問題は実質的にほとんどなく、過度に大騒ぎする必要はまったくないことを先にお断りしておきます。
・時事通信社「緊急停止装置に不具合＝１５００両、ソフト設計ミス−ＪＲ東日本」（2014/10/6）
http://www.jiji.com/jc/zc?k=201410/2014100600643
> 装置の制御ソフトウエアの設計ミスが原因とみられ、１９９８年から続いていた。
> 同社によると、不具合があった車両は同社が保有する先頭車両の３分の１に当たる１５４８両。
・産経新聞「なぜかタイマーがリセット…ＪＲ西５３０両の緊急列車停止装置１分以上作動遅れの可能性 １１年間不具合に気付かず」（2014/10/8）
http://www.sankei.com/west/news/141008/wst1410080067-n1.html
> 運転台付きの車両２７６６両のうち５３０両
> ＪＲ東日本で６日、同様の不具合が見つかったこと受け、ＪＲ西が調査し発覚した。平成１５年度に導入していたが、約１１年間この不具合に気付かなかった。
・共同通信「停止装置不備、首都圏の私鉄でも 小田急、西武、東武、京成の４社」（2014/10/10）
http://www.47news.jp/CN/201410/CN2014101001001809.html
> 国土交通省は全国の地方運輸局などを通じ、同じ問題がないか鉄道各社に調査を要請中。
> 不備があった小田急１９６両、西武２１６両、東武１０２両、京成３８両は改修される。
・JR東日本「一部車両においてEB装置のブザー鳴動開始までの時間が延びる事象について」（2014/10/6）
http://www.jreast.co.jp/press/2014/20141003.pdf
> ３．原因
> TIMS（列車情報管理装置）内のEB装置を制御するソフトウェアが、ATCやATS-Pによるブレーキが自動的に動作した場合などに、運転士が操作した場合と同様の認識をする内容となっているため。
・同「一部車両においてEB装置のブザー鳴動開始までの時間が延びる事象について（続報）」（2014/10/9）
http://www.jreast.co.jp/press/2014/20141006.pdf
・新京成電鉄「ＥＢ装置搭載車両におけるブザー鳴動開始時間が延びる事象について」（2014/10/10）
http://www.shinkeisei.co.jp/topics/detail.html?news_id=712
・北総鉄道「一部車両においてＥＢ装置のブザー鳴動開始までの時間が延びる事象について」（2014/10/11）
http://www.hokuso-railway.co.jp/pc/topics.php?catid=1&infoid=119
・相模鉄道（相鉄）「ＥＢ装置のブザー鳴動開始までの時間が延びる事象について」（2014/10/14）
http://www.sotetsu.co.jp/news_release/pdf/141014_02.pdf
・名古屋鉄道（名鉄）「一部車両においてEB装置のブザー鳴動開始までの時間が延びる事象について」（2014/10/14）
http://www.meitetsu.co.jp/info/2014/__icsFiles/afieldfile/2014/10/14/141014_EB.pdf
各社とも「EB装置のブザー鳴動開始までの時間が延びる事象」と判で押したように＝これが固有名詞であるかのように記載していますが、メーカーに責任のあるトラブルであるため当然です。おそらくは、プレスリリースの文面のいくらかはメーカー側が用意しているのでしょう。
・＠IT「仕事を楽しめ！ エンジニアの不死身力（17）：「潜在バグはある」という意識でトラブル解決に臨む」（2011/10/14）
http://www.atmarkit.co.jp/ait/articles/1110/14/news153.html
http://www.atmarkit.co.jp/ait/articles/1110/14/news153_2.html
> 「バグや仕様書の不具合があってもいい」と開き直っているわけでは決してありません。バグをなくすためにベストを尽くしますが、それでも見つけられないバグは現実にあります。この現実をきちんと認識することがポイントです。
> もちろん、トラブルの程度によってはこんな悠長なことは言っていられないでしょう。
自動改札機の不具合（[2868],[2869]）も記憶に古くない（ただちに新しいとまではいえない）ところです。
・日経BP ITpro「PASMOとの相互接続時には12億通りもの運賃を検証した」（2007年7月6日）（再掲）
http://itpro.nikkeibp.co.jp/article/Interview/20070706/276983/
テストの高品質化のためには、いかにして条件を少なくできるかも重要で、何の問題意識も持たず、いつまでも「12億通り検証しました」といっていてはだめでしょう。運賃制度に手を付けないままICカード出改札システムを構築するというのは「悪夢」そのものといえます。
・[2979]
> [2978]で述べました「タイミングやシーケンスだけ」というのは、こういう「一定時間下りたまま＝こしょう」という類の愚直なロジックのことを指しています。まさか先進的なATACSによる先進的な制御にあたって、そんなことはいまさらしていないだろうと思いつつ、（組み込み系でありがちな）ゼロベースで設計するとうっかり、ということもあるかなぁ、と心配になったりします。
[2978],[2979]を書いた時点ではすっかり忘れていましたが、EB装置のことも頭の片隅にあったと思われます。いわゆる「組み込み系」で、体系的なマネージメントが確立してきたのは比較的最近のことでしょうし（それも確立したといいきれるかは微妙ですが）、16年前にはかなり行き当たりばったりな開発をしていた（と、いまふりかえればいえる＝当時としてはベストを尽くしていたに違いないですが）はずです。
その昔、EB装置の導入が急がれた時点では、EB装置をいち早く導入することだけが考えられたと思います。そして、一度、EB装置が「あたりまえのもの」になった後は、EB装置やその周辺にはなるべく手を付けずに他の装置を開発するという手法が取られてきたはずです。各々に正しい手法ではありますが、結果として今回のような不具合が16年も表面化しないということにつながりました。
※ATACSによる踏切制御でも、踏切側の既存の設備をなるべく触らないようにすることで、ATACSによる制御をいち早く導入できるわけですが、踏切側から見てATACSが軌道回路に見えるとすれば、EB装置から見て自動ブレーキが運転士の操作に見えることとよく似ています。
今回の表面化に至った直接のきっかけが何であったのか、に興味がありますが、いずれ公表されるのでしょうか。
特定の条件下でのみ不具合が起きるという状況は、鉄道以外の一般的なソフトウェアでいえば、脆弱性（セキュリティホール）に近い性質があると思います。
・日経バイト「特集「携帯・家電に忍び寄るネット・セキュリティの闇」(3) パソコンの悪夢が今 組み込みの世界に」（2005/11/9）
http://itpro.nikkeibp.co.jp/article/COLUMN/20051104/223995/
> 「たとえネットワークにつながってもファイアウォールの内側にいるので，それほど危険ではない」「内部構造がブラックボックスなので攻撃されにくい」「日本の組み込み技術者は優秀なのでバグは少ない」「パソコンと異なり，稼働しているアプリケーションが少なくスキがない」「わざわざ組み込み機器を狙わない」というのがその主張だ。どれも一理あるが，現実はそれほど楽観できない。
> 「内部構造がブラックボックスなので攻撃されにくい」というのも，かつては真実だったかもしれないが，もはや過去のことになりつつある。
> 組み込み機器は汎用的なOSとマイクロプロセッサで作られつつあるのだ。そうなれば内部構造はブラックボックスではなくなる。汎用の部品に脆弱性があれば，それを使っているすべてのシステムが影響を受ける。
> コード行数が増えれば増えるほど，バグすなわちセキュリティ・ホールが開く確率は高くなるからだ。「現在の携帯電話のコード行数は数百万行ある。これは20年前にメインフレームで動作していた銀行のオンライン・システム並みの行数」（インターナショナル・ネットワーク・セキュリティの勝野氏）である。
コードの行数だけをもっていいきれるものでもないですが、概ね、かつての業界が直面してきた課題に対して、20年の時隔をもって、組み込み系でも順番に課題に上がってくる、という「いつかどこかで見た構図」というものがあるように思います。つまり、この先にどんな課題があるかも、それに対してどんな解決策があるかも、既にわかっているのです。
より詳しく学びたい人に最適と思われる記事を以下に示します。
・「ソフトウェアテストの30年前と30年後（前編）〜テストの根幹は30年前に書かれた JaSST'12 Tokyo」（2012/2/1）
http://www.publickey1.jp/blog/12/303030_jasst12_tokyo.html
> その後、さっきのブルックス氏がOS/360の開発で経験したことを書いた「ソフトウェア開発の神話」（現「人月の神話」）が出版。遅れているプロジェクトに助っ人を入れるとさらに遅れる、という有名な「ブルックスの法則」などが書かれていて、強烈なインパクトを残した。
> ソフトウェア開発も、プログラミング言語はJavaなど高級言語になったが、生産性は1カ月約1000ステップとあまり変わっていない。プロジェクト管理技術もあまり進歩していなくて、いまだに「神話」がそのままあてはまる。
| 