asahi.comによる首都圏改札機トラブルの解説を読んで

ご覧になった方も多いと思うが、10月28日13時のasahi.comの記事に首都圏改札機に関する事象の詳細が書かれている（「１文字分のミスで大トラブルに　首都圏改札機トラブル」）。この記事の内容を信じるならば、先日の首都圏改札機の事象は改札と窓口処理機の両方で起きているそうだ。私は事実を確認していないし、あくまで記事の文面からの推測ではあるが、次のような状況が起こっていることが推測される。

改札機での不具合と窓口端末の不具合は類似のものであり、問題を起こす入力データが時間差で（先に改札機、後で窓口端末）与えられたため、不具合が時間差で起こっているそうだ。

これ以降は全て私個人の憶測であり、今回の事象に関わった方々は既に実施されていたり、検討済の話だと思う。ここでは、今回の事象をきっかけとして、一般論としての話を書くことにする。こういう考えもあるという例示として読んでいただけると幸いである。

類似した2度の不具合が連続して起きてしまうような事象では、短期間でFMEAのような故障モード影響解析や（今回の場合）ソースコードの静的解析が実施されれば、2回目の不具合の発生を防げる可能性がある。たとえば、最初に改札機での不具合を確認、修正した際にシステムの他の部分のソースコードに対して静的解析手法（たとえばキーワード検索やコードクローン分析）を適用することにより、検出できていた可能性がある。ソフトウェアのFMEAについては、電気通信大の西先生が各所で講演されているので参考になるだろう。

私自身の経験からも感じるが、類似バグの検索を迅速に実施することは想像以上にたいへんである。理由の1つは類似バグの存在と同等もしくはそれ以上にデグレードのリスクが気になるからではないかと思う。1つバグを直して修正確認のテストを実施したからといって、デグレード（デグレードについてはこちらを）していない保障はないからである。その傾向はリリース後であればなおさらであり、類似バグをくまなくさがすよりは、回帰テストを重点的に実施したいのは開発者や開発チームの人情として当然だろう。FMEAに関するドキュメントでもFMEAチームを別部隊として編成することを記述しているものもある。

デグレードの確認は本人やチームで担当するとして、他のメンバやチームが類似バグをさがすようなプロセスとしてみるのはどうだろうかと思う。結局は身が入らない、類似バグをさがすにも限界がある、という結論になるかもしれないが、手分けをすることにより、手分けしないときと比較して、集中して作業ができるのではないかと思う。障害対応時に1人で複数のことを同時にやらないことを鉄則としているところは多いのではないだろうか。

なお、今回、たまたま改札システムの事象を挙げているだけで、このエントリは今回の話に限った話ではない。RFIDを用いたシステム開発や国際標準策定という形で関わっていた中で知る限りでは、強烈なラッシュ時にも安定した信頼性、スループットを提供している組込み型端末、バックエンドのエンタープライズシステム、及び、それらをつなぐネットワークから構成される巨大システムを毎日安定して運用保守できているのは開発者の方々の涙ぐましい努力のおかげであり、大きなトラブルにつながらなかったのは、柔軟な対応をされた鉄道会社の方々の日々の鍛錬の賜物であることは紛れもない事実であることを付け加えておきたい。