パスワードを忘れた? アカウント作成
5231 story

航空管制ダウンの原因はNECのバグ放置 114

ストーリー by Oliver
ダメと思ったら正直に申告を 部門より

k3c 曰く、 "3月1日に発生した航空管制システムの障害は、NECがプログラムのバグに事前に気づいていながらこれを放置していたことが原因だったとのこと(Mainichi INTERACTIVE記事asahi.com記事)。9月に更新したプログラムにデータ読み込みを中断させる機能を追加する必要があることを1月の時点で発見したにも関わらず、それまで問題なく稼働していることを根拠に国土交通相に報告せず、バグ修正もしなかったらしい。
アプリケーション開発の現場において、微細なバグを「問題なし」として放置することはたまにあることだと思いますが、バグの影響の範囲をどう判定するか、どこまでテストするのか、という判断の難しさを、今回の事象は改めて感じさせてくれます。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2003年03月12日 22時16分 (#277326)
    「バグに事前に気づいていながら、これを放置せざるをえないような
    人員配備&スケジュールになっていた」って言うのが正解のような気がするけどなぁ。

    #全然関係者じゃないので、AC。
  • by dama4slash (785) on 2003年03月12日 23時37分 (#277404)
    タレコミに紹介されている記事では、「読みこむ処理を中断する機能
    の組み込みを忘れた」とありますが、機能検討や設計の段階でそのよ
    うな機能は考えられておらず、元々仕様に無かったということはあり
    えないでしょうか?
    「確かに、『中断できたほうがいい』がそんな機能は後付けでもよい
    だろう」というような意見で〆られていたりして。その時の打ち合わ
    せ記録とかはどのように書いてあるのでしょう。

    しかし、一般の人にとってみればNECは無責任としか映らない可能
    性は高いです。現に、(真に受けすぎてはいけないと思う)投資の掲
    示板では、『富士通が悪材料を出している時にNECは隠蔽をしていた
    のか』といった感じの書き込みがありました。
    だからといって、私はNECより富士通がマシとか比較するつもりはない
    ですが。
    • by minek (14559) on 2003年03月13日 1時39分 (#277503) 日記
      >一般の人にとってみればNECは無責任としか映らない可能性は高いです。

      そうですね。一般の人の反応を考えれば、NECがとっても無責任、ですよね。

      こんな風に官公庁の発注した事業で失敗した場合に、民間企業の名前が頻繁に取りざたされるようになったのって、いつからでしょう。
      うまく動いている間は、さも、自分の業績のような顔をしている誰かが、情報公開を盾に責任逃れをしているように見えなくもないのですが。

      少し気になりました。
      親コメント
    • by Anonymous Coward on 2003年03月13日 1時27分 (#277497)
      >しかし、一般の人にとってみればNECは無責任としか映らない可能性は高いです。
      スラドをROMってると、プログラマ及びプログラミングしている人たちの考え方と一般人の差は激しいなと思うことしばし。
      購入する立場でしか無い人間の目から見ると不思議な仕様のソフト、としか映らないものを持って来られた事も何度かある。
      プログラマの人たちにとっては『重要』もしくは『問題は少ない』と感じても、現場では意味不明だったり、今回のように大問題だったりするケースが結構ある気がする。
      まあ今回のような海外までも問題を広げることは少ない、ってだけで。
      何かこの差を埋めるようなシステムOR協議会、のようなものが出来てくれることを望んでいる。
      親コメント
      • by pavo (486) on 2003年03月13日 6時29分 (#277620)
        スラドをROMってると、プログラマ及びプログラミングしている人たちの考え方と一般人の差は激しいなと思うことしばし。
        購入する立場でしか無い人間の目から見ると不思議な仕様のソフト、としか映らないものを持って来られた事も何度かある。

        その差は、プログラミングする側の中にもあるように感じています。つまり、何を重要とするか、に開きがあると感じています。プログラマ同士でも。おそらくですが、プログラミングの世界というのは、実は結構奥深いんですよ。それをひとくくりに「プログラミング」と言ってしまうものだから、問題の本質が見えにくくなっているのではないかと感じています。

        でも、アジャイルな開発プロセスで試行錯誤するようになって、その奥深さがだんだんわかりやすく整理されつつあるように(私には)思えます。この段階が過ぎれば、きっとプログラミングの世界も、より的確な言葉(これまでになかった新しい言葉がいくつも作られる必要があるかもしれません)で語られるようになるのではないでしょうか。

        そして、結果的に、システムの規模や複雑さを理解した開発体制とスケジュールが組まれるようになっていくのではないかと。。。期待しているのですが。。。。。

        本題からはそれますが、プログラミングの世界って、実は、自然言語の世界に匹敵するくらい豊かな世界なんじゃないかと思っています。そういう新しい視点?意識空間?を、人間は今作っている最中なんじゃないでしょうかね。

        親コメント
        • >本題からはそれますが、プログラミングの世界って、実は、
          >自然言語の世界に匹敵するくらい豊かな世界なんじゃないかと思っ
          >ています。そういう新しい視点?意識空間?を、人間は今作っ
          >ている最中なんじゃないでしょうかね。

          人がさまざまな情報を組み合わせたり推論したりして保持する
          データ量を減らしているのに対して、ソフトウエアの試験項目の作成をしていると、
          「こうするとこうなる」という論理を無数に登録するという作業になっています。
          脳とコンピュータでは構造が違うので、ソフトウエアの品質を上げることに多大な
          コストがかかるのは当然だし、バグがないソフトウエアを作るのは非常に
          困難だと感じてしまいます。
          親コメント
      • by Anonymous Coward on 2003年03月13日 10時28分 (#277728)
        >何かこの差を埋めるようなシステム
        そのためにSEが経営語と技術語の翻訳&両者のエージェント
        として存在するんじゃないのかと。まぁ仕事していると違う
        っぽい人が多いですけど。。。
        親コメント
        • by Anonymous Coward on 2003年03月13日 12時06分 (#277806)
          >そのためにSEが経営語と技術語の翻訳&両者のエージェントとして存在する

          最近は分業化が進んでいるため、その役割はSEという肩書きの人ではなくコンサル(コンサルタント)と呼ばれる人がやってます。
          ところが業務方面からやってきて技術方面のスキルが異様に低い人なんかも同じくコンサルと名乗ってて紛らわしいことが多いです。

          依頼するお客にその辺の区別がつくはずもなく、受けた側もとりあえず仕事として片付けるので、結果として使い物にならないシステムが出来上がったり。

          なんでコンサルなんて言葉が流行ったのかな。
          昔あったSA(システムアナリスト)の方が分かりやすかったが…でも今だとシスアドと区別つかなくなるか。
          やれやれ。

          親コメント
    • by Anonymous Coward on 2003年03月13日 11時11分 (#277763)
      >タレコミに紹介されている記事では、「読みこむ処理を中断する機能
      >の組み込みを忘れた」とありますが、機能検討や設計の段階でそのよ
      >うな機能は考えられておらず、元々仕様に無かったということはあり
      >えないでしょうか?

      無かったんじゃないですかねぇ
      というか、手入力の部分じゃないでしょうから間違わない事を前提で作られていたのでは?

      で今回データーフォーマットが変わって、異なるフォーマットのデーターが混入->問題発生と

      この部分でカードすることも必要ですが、実際はその前の段階で変換しフィルターを掛けるのが今回追加された処理だと予測すると、そこもバグってたんでしょうね

      それを既存Bugというのならちょっとつらいかも
      まぁどの部分にしてもBugはBugなんですが(苦笑)

      私的には入力が絶対正常であることを前提にしたプログラムなんて
      怖くて組めませんけど...
      他人の作ったプログラムなんて信用できませんし、自分の作ったプログラムはもっと信用できないですから(まて(笑
      親コメント
  • 想像ですが。 (スコア:2, 参考になる)

    by tux (14291) on 2003年03月13日 0時16分 (#277437)
    バグ発見→部署内で議論→実運用上ありえない→現状

    正直言ってここまではよくあることだと思います。
    (例えばドコモが無茶苦茶なデータを送ったらほとんどの携帯が
    ハングするんじゃないだろうか・・・)
    で、今回の改修により「実運用上ありえない」パターンが発生
    してしまいダウンしてしまったと。

    「次回修正」とした項目を入れ忘れてしまった事がNECのミスでしょうね。
    普通は誰かが覚えているはずなのですが、前回ミスしたのも
    バグを発見したのも外注で今回は別の外注がやったとかも
    ありえるし。(^^;)

    #異常系の試験ってどうしても後回しになりますよね…;
    • by tomatsu (2545) on 2003年03月13日 1時05分 (#277474)
      という事を主な理由として、潜在的なバグ改修を行わない、という考え方は、一般的に、真っ当なものなのでしょうか。

      政治の場でも、セキュリティ対策でも、何でも。「あり得ない事」などと簡単に言い切ってしまって後になって痛い目にあう、という事を何度と無く目にしていると、とても正常な判断が出来る人間が説明する理由ではないなあ、と感じてしまうのです。

      実際には、放置していて結果として何も問題が起きない事の方が「とても多い」でしょうけども、それが「事実上あり得ないという理由が真っ当なものである根拠」になるとは思えません……。
      親コメント
      • バグ改修の優先度 (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2003年03月13日 1時27分 (#277496)
        >実運用上あり得ないという事を主な理由として、潜在的なバグ改修を行わない、という考え方は、一般的に、真っ当なものなのでしょうか。

        バグ改修を行わない、のではなく、バグ改修の優先順位を下げる、という判断がなされただけではないかと思います。

        バグ改修を行うためには、発注元の了解を取り付けることが必要になりますが、その際、リリース前に検証したにもかかわらず、なぜそんなことが発生したのだ、という議論だけが先行して、実際のバグ改修がなかなか始まらないことがあります。また、そういった理由から、いったんリリースしてしまった後のバグ改修はあまり回数を行うことができない、といった負のバイアスが現場にかかるのも事実です。

        そのため、いそぎでないバグ改修であれば次のリリースに含めて対応しようとする方向になるのも不思議ではありません。また、このバグが発見されるのが、その次のリリースのための機能追加の最中だったりしたら、そんな時期に検証のリソースはさけないため、とりあえず次のリリースまでもってくれ、と祈ることになるのでしょう。

        やれやれ、なんかやりきれないな。
        親コメント
      • by tux (14291) on 2003年03月13日 1時44分 (#277504)
        日進月歩なものほどその傾向が強いのではないでしょうか。
        今回は特にあと2ヶ月でバージョンアップすることは
        決まっていたでしょうから。

        現場の人間としてはなおせる物ならすぐになおしたいんでしょうが
        会社間レベルとかになってくると「事を荒立てない」という要素が
        一番強かったりする。。。。

        インフラと電化製品を一緒にするなという声が聞こえてきそうですが
        末端の外注、子会社レベルになると机を並べていたりするわけで。(^^;)

        #書いててやるせなくなってきますが
        #他コメントにもあるように現状はこんなもん;
        親コメント
      • by honey (7377) on 2003年03月13日 2時42分 (#277535)
        「このケースは実運用上あり得ないので問題はありません。」というのは、
        プログラムの不具合やテスト条件の不備を指摘したときにとてもよく聞く台詞です。
        実際には、その「あり得ない」ケースが実によく発生します。
        手抜きの言い訳ぐらいにしかとらえていません。
        親コメント
    • by nekopon (1483) on 2003年03月13日 7時44分 (#277638) 日記

      参考というか茶々というか。Jargon file から"Can't happen" [jargon.net]

      親コメント
  • by j_NY (14415) on 2003年03月13日 1時06分 (#277478)
    同感です。
    全然根拠のない予想ですが、ある人のうっかりミスとかNECの企業体質の問題とか、そういうものではないような・・・
    今のシステム開発の限界というか、うまく言葉にできませんが、現場の人間に話を聞けば、
    「あんな現場じゃ起こって当たり前だよ」
    とかいう言葉が返ってきそうで。

    みずほの時もそうでしたが、クライアントに問題があればコンサルごと送り込んで造らないといけないのかな・・・
    • by j_NY (14415) on 2003年03月13日 1時09分 (#277479)
      「同感です。」ってなんなんだ?レスするところ間違ってるし。
      わしみたいなのが、システム開発に携わってるから、動かないコンピュータが増えるんですな。
      吊るしかねーか・・・
      親コメント
  • バグを黙ってたなんて (スコア:2, おもしろおかしい)

    by megalith (4791) on 2003年03月13日 10時19分 (#277718)
    ACOSが「Anonymous Coward OS」の略かと思ってしまうよ。;-P
  • 恐るべき逆説 (スコア:2, すばらしい洞察)

    by SteppingWind (2654) on 2003年03月13日 12時07分 (#277808)

    今回は「バグを見つけていた」から責任が問われたわけで, 逆に見つけていなかったら責任が問われないとしたら(ユーザの受け入れ検証が完了していて, 瑕疵担保期間が過ぎていたとか), 一体どうなるんでしょうかね? 開発側では保証期間が過ぎたらコードを参照することは禁止なんてことになるのかな?

    航空機事故では責任を問わないことにして問題の公表を促すようにしているんですけど, コンピュータシステムでは知らぬ顔を通す方が無難ってことになっちゃうのかな?

  • by gonta (11642) on 2003年03月12日 22時52分 (#277356) 日記
    これ航空管制のプログラムだよね。最悪、飛行機が落ちたり
    衝突したりするわけですよね。以前も、航空管制の人的ミスで
    ニアミス起こすわ急激な高度変化で乗客に怪我が出たりしま
    したよね?

    私もコーディングしますが、研究のコーディングで多少バグっ
    たり対処後回ししたりします。今回のは人命にかかわること
    だと思うので・・・ずいぶん簡単に考えてたなぁ>>NEC
    --
    -- gonta --
    "May Macintosh be with you"
    • Re:でもさ・・・ (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2003年03月12日 23時04分 (#277366)
      >ずいぶん簡単に考えてたなぁ>>NEC

      ずいぶん簡単に考えていた、ではなく、簡単にその影響を調べることが
      できなかったのではないか、ということではないかと気になります。当
      のNECが影響の大きさを検証できていなかった、または、検証できる環
      境がなかったのではないか、と。ケアレスミスだった場合は、弁護の余
      地はありませんが。

      航空管制のハードっておそらく、そんな二つも三つも用意できるもので
      はないですよね?全く本番とハードウェア的にも、入力データについて
      も同じ環境構築を用意できないと、どれだけ単体テストをしても本番実
      施までみえないことがあります。特に、今回の件、システム間連携の部
      分がらみということで、評価がかなりやりにくいところだったのではな
      いでしょうか。

      また、NEC側の想定が甘かったとして、それを指摘できる人間が航空管
      制部側にいない、ということも問題のひとつだと思います。そして、そ
      れらを総合して、リスク管理のできていないNECと発注元の責任という
      のも、決して少なくないと思います。

      発注元がNECに対して損害賠償請求をしたりするのは勝手ですが、それ
      でことを済ませるのではなく自分の足下を見直すようにするべきでしょ
      う。
      # 別に関係ないといえば関係ないんだけどAC
      親コメント
      • by redmagic (6537) on 2003年03月12日 23時35分 (#277401) 日記
        読売新聞 [yomiuri.co.jp]によるとバグが混入した変更とは別件のプログラム変更により今回の件が発生した模様です。

        影響の想定が甘かったのかそうでなかったのかはわかりませんが、結果としてはバグの存在を全く報告しなかったのが問題のように思います。
        もしバグの存在が知られていれば、後者のプログラム変更と同時に該当バグを見つける試験項目を挙げることも、あるいはバグ修正も可能であったようにも思います。

        ま、バグを報告して修正しないままにするというのも難しいかもしれませんが。
        親コメント
        • by Anonymous Coward on 2003年03月13日 10時43分 (#277737)
          結果は変わらなかっただろうと思いますよ。

          仕様上あり得ない。事実、(他の部分の)仕様が変わるまでなかった。
          将来に渡ってあり得ないと断言できなくても、発生する可能性も断言できない。
          手を加えることのリスクとコストを考えれば、顕在可能性の低い穴は放置が基本。
          これはソフトに限らず、ハードでも、人事でも、何でもそうです。
          あり得そうにない事態に対処するために、必要かどうかもわからない
          冗長性を新たに追加するなんて、常識ではあり得ないことです。
          国土交通省に報告が行っていても、同じ判断になったでしょう。

          あり得そうにない事態を想定した時に起こる不具合なんてのは、いくらでもあります。
          そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
          NECが報告を上げてなかったと言っても、それが当然で、もしいちいち報告したら
          国土交通省の業務はそれだけでパンクするでしょうね。
          親コメント
          • 報告していれば、そして後直しで受け入れられれば、←まずないけど
            穴がある間、その周りを通る人は注意深くなります。

            今回と同じ結果になる確率はそれなりに下がるでしょう。

            >そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。

            それはただの言い訳ですな。
            親コメント
    • Re:でもさ・・・ (スコア:2, 参考になる)

      by Anonymous Coward on 2003年03月12日 23時29分 (#277394)
      「見つけたそのバグ」を直すのは5分で済むけれど、 他への影響が判らない内は、弄らないって場合も しばしばありますよね。デグレードは何より怖いし。 特に航空管制等重要業務であれば有るほどそう。
      親コメント
      • by tomatsu (2545) on 2003年03月13日 0時31分 (#277455)
        バグとしての挙動を正として動くコードがあると、泣きたくなりますね。

        #IEのCSSバグが直ると、バグを前提としたページが崩れる、みたいな。
        親コメント
      • 同意。この手の話は、本当にオープンソースとは対極の話だなぁと思う。

        オープンソースの場合:
        まず直す→不具合が出たらそこを直す→また不具合が出たらそこを直す→…

        大規模な基幹システムとかでこの手法を使ったら、
        一回のリリースごとに一人の首が飛んだりするのかなぁ…

        #屋上から飛ぶのに比べれば首が飛ぶほうがマシだとは思う
        --
        # mishimaは本田透先生を熱烈に応援しています
        親コメント
    •  読売の記事 [yomiuri.co.jp]をよく読むとわかりますが、今回のFDPシステムはあくまでも出発前に機長が提出するフライトプランを受付、すでに提出済みのフライトプランに支障がでないかのチェックのサポートと、全国の空港への周知を行うシステムです。

       将来的には飛行機の管制業務の自動化もあるかもしれませんが、現在のところは計画をデータベース化して閲覧しやすくするためのシステムにすぎません。

       すでに離陸した飛行機はフライトプランを承認され、計画通りに飛行する限りは安全を保証されているわけです。
       衝突の回避と緊急時の指示は、自動化できないため従来通りに管制官が行っているので、FDPの障碍で飛行中や着陸する飛行機が事故を起こすことはありません。

       ・・・だからといって、対処を後回しにしていいわけじゃないんですけどね。実際、離陸は中断され、由緒正しい手作業での確認を余儀なくされたわけですし。
      --
      --- どちらなりとご自由に --- --
      親コメント
      • by Anonymous Coward on 2003年03月13日 2時49分 (#277538)
        >飛行計画通りに飛行する限りは安全を保証されているわけです。

        でも、管制官向けのストリップは適宜最新状況を反映した
        ものが渡されるのだけど、FDPがとまるとこれができな
        くなるわけなんですよ。

        空港管制だった管制官の範疇に近いので管制官の技量でなん
        とかなるだろうけど、航路管制だと割り振りが難しいことに
        なりそうで、それが尾をひきそう。管制官のストレスにはな
        りそうで、ミス誘発とかありそう。

        # FADP関連のお仕事をむかしやっていたのでAC
        親コメント
        • by Minap (9371) on 2003年03月13日 15時04分 (#277950) ホームページ 日記
           最も飛行機が集中するのは、待合場所であり交差点でもある飛行場上空なので、空港管制からのバックアップが受けられます。

           途中の飛行経路は高度毎に進行方向を分けられた、一方通行の高速道路みたいなものですから、飛行計画が適正である限りは非常事態の発生や、パイロットが故意に高度・速度・進路を変更しなければニアミスは発生しません。

           そもそも途中経路は東京コントロールの管制下にある為、飛行計画承認の為に各空港から送られてきた最新情報が利用可能だと思います。

           一番の問題はレーダー画面上に便名が表示されなくなることですが、トランスポンダーから送信される高度や速度の情報は表示されているので、管制官本人がチェックを怠らなければニアミスは回避できます。

           当然、非常時に備えてレーダーと無線のみで全ての管制を行なう訓練は受けているはずですしね。それに、そもそも離陸中断で飛行中の期待の数は一定量以上に増えることなく、逆に減っていくわけですから。

           レーダーとラジオが生きていれば、管制官は管制業務を継続することができます。頼りのレーダーすら使えなくなる状況 [cinemakun.net]というのも、想定できるわけですから・・・。
          --
          --- どちらなりとご自由に --- --
          親コメント
      •  自己レス。

         すみません、読売だけじゃわからないですね。
         どこで資料を見かけたんだっけなー・・・。(w;
        --
        --- どちらなりとご自由に --- --
        親コメント
    • by dreambug (11354) on 2003年03月12日 23時43分 (#277410)
      「仕様上こないはずのデータパターンが来たら異常を起こす」
      などの場合は、正直いって「次回改修時にまとめて」といった 対策を取る事は多いんじゃないかと思います。
      たとえ1行の修正でも、単体テスト・複合テスト・変更申請・入れ替え・立会いと
      ものすごい手間とコストが掛かる場合がありますし
      「修正したことによって問題が発生する」事も多々ありますから・・・
      親コメント
  • by p00h3 (8309) on 2003年03月13日 11時04分 (#277758) 日記
    その当日私の乗る予定だった便が欠航したんですけど。
    航空--高橋主任 [nas.co.jp]、彼の言うとおり、
    「着陸した航空機をスムーズに誘導できなくなり、乗客の皆さんの乗降に支障をきたすなど、航空機の管制業務が混乱」
    しましたね。ええ、それはもう。
  • 9月に更新したプログラムにデータ読み込みを中断させる機能を追加する必要があることを1月の時点で発見したにも関わらず、それまで問題なく稼働していることを根拠に国土交通相に報告せず、バグ修正もしなかったらしい。
    バグじゃなくて、単なる手抜きでは?
    --


    # ACなのでAC
  • バグの報告で修正が必要、リリースが遅延、ってなったとき、その費用ってNEC持ちなんでしょうか?
    # もちろんって声が聞こえる...

    NECの見積が甘いだの、危機管理が甘いだのっていうけどさ、受注したのがNECだってことは、発注元が「H/Wベンダーの責任だろっ!」とかって喚いて買い叩いた可能性もあるよね。
    いくら精度の高い見積を出したって、ものをつくる、ってことの意味が判らない人たちが数字だけで「見積が高い」「納期が遅い」なんて文句を言ってくるのは最近当たり前のようになってるし。
    その金額じゃ出来ない、ってことを説明してもハナから理解しない人が多くありませんか?
    試験の工数ってバカにならないし、技術が判っていない人ほど「そんなに試験しなきゃならないほど技術レベルが低いのか!」って文句言うし。

    結局、金額が折り合わない -> 契約が遅延する -> リリース日は決まっているので開発期間が短くなる -> 問題発生! -> 現場のせいにする。
    こんなパターンを何となく想像してしまいます。
    # あぁ、完全にグチになってる...
  • by sakamoto (8009) on 2003年03月13日 14時38分 (#277935) 日記
    単に現場担当者が責任を逃れるために、NEC のミスを大々的にマスコミに 流しただけなんじゃないかな? 外注業者一社のちょっとしたミスでシステムが止まるなんて。 サイバーテロで簡単に飛行機が落せるってこと? あと、今回のバグは現場担当者も知っていたに一票。

    止まった直後に「管理体制の甘さ」と言わず「一局集中の弊害」というミスリード がマスコミに流れたりして、現場の責任者の顔が見えずに管理とは別の 原因ばかりマスコミが取り上げられている。 こんなニュースが流れるってことは、現場の担当者のマスコミ対策が うまく行っているだけなんじゃないかな?

    --
    -- 哀れな日本人専用(sorry Japanese only) --
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...