2025年3月8日

Root Cause

JR東日本で発生した、走行中の連結器解除問題。今回は西日暮里駅付近を時速60km位で走行中に発生した事故で、昨年9月に300km台で走行中に発生した同様の分離事故に続いて2件目の事故。但し、こう言う接続部分が走行中に解除されてしまう事故は、前回が東北新幹線開通以来初めての事故だった非常に稀な事故な訳で、それが半年の間に再発したというのはかなり厳しい問題だというのは実感できます。

内容も状況も環境も違うけれど、自分も開発という仕事を何十年も続けていると、似たような経験があります。その中には以前に多様な問題対策をしたのにその後再発して、その結果「あぁ、あの時のあれはこれが原因か」と後から本来の原因が判明する事が何度かありました。例えば、とある製品を使用していると何かのタイミングで異常終了してしまう問題があり、いろいろ検証してみたところ、内部で使用している信号線にノイズが乗って異常な信号と誤認されて異常終了していることが分かったので、その信号線をシールドしたりしてノイズ対策して、その時には問題は収まったように見えました。ところが開発が進んでくると、再び同様の問題が発生。さらに問題解析をして見ると、その問題を起こした信号線に近接している他の信号線やチップからのノイズが信号線に直接乗っているので、フィルターを入れたり信号線パターンの変更やらをしてやっと解決した、みたいな事があります(かなり端折った言い方ですが)。

最初に発生した問題が、そのタイミングや程度の大きさによっては早急に解決しなくてはならず、その為に「問題現象から原因を探る」のではなく「問題現象から原因を決めてしまう」、つまり自分で原因を設定して作りだしてしまう事がありがちです。しかも、それで偶々問題の発生が消えたりすると「特定出来た」という事で、それが正解だと信じてしまう。ただ、それが根本原因でなくても、環境や条件が変われば問題発生の頻度や状況も変わるので、そこをさらに詰めないと「解決」とは言えないんですよね。最初に「2回に1回発生」していたものが、10回試しても発生しなくても、100回試したら再発するかもしれない(発生頻度の減少)。テストの時には頻繁に電源ON/OFFを繰り返して再現テストを繰り返しますが、その時にはシステムが暖まっているから安定して問題発生しないけれど、朝一に電源を入れたコールドブートの時には微妙なタイミングのズレが発生して問題が再発してしまうとか、まぁ色々な経験をしました。前回の事故が発生した時には、余りに単純な原因特定に個人的には疑問を感じていたんですが、今回は走行中の切り離し信号を無視する仕組みが入っているはずなのに切り離し操作が実行されてしまったわけで、そうなると制御するソフトウェアの問題も考えられます。

例えばありがちなのが、通常の設定を無視できるあるいは特定機能がフリーハンドになるような「テストモード」みたいな物が実装されていて、そのモードに何かの理由で入ってしまい本来通常モードでは機能しないはずが、テストモードなので機能してしまったとか。自分の経験だと、いろいろフック(Hook)トラップ(Trap)が仕込まれて「デバッグモード(Debug Mode)」みたいなものを入れて置いてソフトの開発をして、最後にはそれらを削除した形で成果物として仕上げて提供するわけですが、それが例えばコンパイルオプションの設定ミスで残ってしまったとかはアルアルの話でした。実際の連結装置やそれを制御するシステムを見たわけでは無いので、あくまで自分の経験からの推測でしかないわけですが、同じ問題が対策を適用していたはずなの再発したという事は、前回の対策は単なる「対処療法(Work-around)」であって、根本原因(root cause)の特定を今回はしっかりやらないと、また事故が再発する事になるでしょうね。こう言う場合、案外単純な部分のミスを見逃していたと言う事も多いので、早く原因特定をしてしっかりと対策適用をして、何とかG.W.までには以前の運用に戻って欲しいですよね。

0 件のコメント:

コメントを投稿