航空管制ダウンの原因はNECのバグ放置 114
ストーリー by Oliver
ダメと思ったら正直に申告を 部門より
ダメと思ったら正直に申告を 部門より
k3c 曰く、 "3月1日に発生した航空管制システムの障害は、NECがプログラムのバグに事前に気づいていながらこれを放置していたことが原因だったとのこと(Mainichi INTERACTIVE記事、asahi.com記事)。9月に更新したプログラムにデータ読み込みを中断させる機能を追加する必要があることを1月の時点で発見したにも関わらず、それまで問題なく稼働していることを根拠に国土交通相に報告せず、バグ修正もしなかったらしい。
アプリケーション開発の現場において、微細なバグを「問題なし」として放置することはたまにあることだと思いますが、バグの影響の範囲をどう判定するか、どこまでテストするのか、という判断の難しさを、今回の事象は改めて感じさせてくれます。"
「これを放置していた」と言うよりは…… (スコア:2, すばらしい洞察)
人員配備＆スケジュールになっていた」って言うのが正解のような気がするけどなぁ。
＃全然関係者じゃないので、AC。
Re:「これを放置していた」と言うよりは…… (スコア:2, 興味深い)
皆さんのまわりではいかがでしょう?
# 最近、試験不足が原因の事故、とっても多くないですか?
# 金が無いから、試験を削って、スキルの低い(=安い)人を使って、その他もろもろ。
# 品質はタダじゃないと思うんだけどなぁ。
# って、昔NASAの試験要員の予算が議会で問題になってませんでしたっけ。
IDでいいや。
Re:「これを放置していた」と言うよりは…… (スコア:2, 興味深い)
アポロ以前だったと思うけど、宇宙飛行士がコックピットに乗りこんでの感想として「アメリカ中の安物を寄せ集めたものが目の前にある」てなことを言ってませんでした?
……まだ「世界中」じゃなかったはず。
Re:「これを放置していた」と言うよりは…… (スコア:1)
であると上で判断したんでしょうか。
Re:「これを放置していた」と言うよりは…… (スコア:1, 参考になる)
で確率を小さく見積もりすぎたんじゃないかな。
で、結局は見積もりが甘すぎたと。
Re:「これを放置していた」と言うよりは…… (スコア:1)
例えば（問題が起きる前に）「潜在的な問題点を改修」という形で公になれば、対処の仕方や発表の仕方によっては、信頼性の向上に繋げる事も可能だと思います。
＃「上の判断」が、現場の、年だけソコソコのヘボSEの判断だったりすると、身近過ぎてイヤ～ン。
Re:「これを放置していた」と言うよりは…… (スコア:3, すばらしい洞察)
ほんとうに忘れたの？ (スコア:2, 興味深い)
の組み込みを忘れた」とありますが、機能検討や設計の段階でそのよ
うな機能は考えられておらず、元々仕様に無かったということはあり
えないでしょうか？
「確かに、『中断できたほうがいい』がそんな機能は後付けでもよい
だろう」というような意見で〆られていたりして。その時の打ち合わ
せ記録とかはどのように書いてあるのでしょう。
しかし、一般の人にとってみればNECは無責任としか映らない可能
性は高いです。現に、（真に受けすぎてはいけないと思う）投資の掲
示板では、『富士通が悪材料を出している時にNECは隠蔽をしていた
のか』といった感じの書き込みがありました。
だからといって、私はNECより富士通がマシとか比較するつもりはない
ですが。
誰が無責任なのか。 (スコア:2, 興味深い)
そうですね。一般の人の反応を考えれば、NECがとっても無責任、ですよね。
こんな風に官公庁の発注した事業で失敗した場合に、民間企業の名前が頻繁に取りざたされるようになったのって、いつからでしょう。
うまく動いている間は、さも、自分の業績のような顔をしている誰かが、情報公開を盾に責任逃れをしているように見えなくもないのですが。
少し気になりました。
Re:ほんとうに忘れたの？ (スコア:1, 興味深い)
スラドをROMってると、プログラマ及びプログラミングしている人たちの考え方と一般人の差は激しいなと思うことしばし。
購入する立場でしか無い人間の目から見ると不思議な仕様のソフト、としか映らないものを持って来られた事も何度かある。
プログラマの人たちにとっては『重要』もしくは『問題は少ない』と感じても、現場では意味不明だったり、今回のように大問題だったりするケースが結構ある気がする。
まあ今回のような海外までも問題を広げることは少ない、ってだけで。
何かこの差を埋めるようなシステムOR協議会、のようなものが出来てくれることを望んでいる。
Re:ほんとうに忘れたの？ (スコア:2, 興味深い)
その差は、プログラミングする側の中にもあるように感じています。つまり、何を重要とするか、に開きがあると感じています。プログラマ同士でも。おそらくですが、プログラミングの世界というのは、実は結構奥深いんですよ。それをひとくくりに「プログラミング」と言ってしまうものだから、問題の本質が見えにくくなっているのではないかと感じています。
でも、アジャイルな開発プロセスで試行錯誤するようになって、その奥深さがだんだんわかりやすく整理されつつあるように（私には）思えます。この段階が過ぎれば、きっとプログラミングの世界も、より的確な言葉（これまでになかった新しい言葉がいくつも作られる必要があるかもしれません）で語られるようになるのではないでしょうか。
そして、結果的に、システムの規模や複雑さを理解した開発体制とスケジュールが組まれるようになっていくのではないかと。。。期待しているのですが。。。。。
本題からはそれますが、プログラミングの世界って、実は、自然言語の世界に匹敵するくらい豊かな世界なんじゃないかと思っています。そういう新しい視点？意識空間？を、人間は今作っている最中なんじゃないでしょうかね。
Re:ほんとうに忘れたの？ (スコア:1)
>自然言語の世界に匹敵するくらい豊かな世界なんじゃないかと思っ
>ています。そういう新しい視点？意識空間？を、人間は今作っ
>ている最中なんじゃないでしょうかね。
人がさまざまな情報を組み合わせたり推論したりして保持する
データ量を減らしているのに対して、ソフトウエアの試験項目の作成をしていると、
「こうするとこうなる」という論理を無数に登録するという作業になっています。
脳とコンピュータでは構造が違うので、ソフトウエアの品質を上げることに多大な
コストがかかるのは当然だし、バグがないソフトウエアを作るのは非常に
困難だと感じてしまいます。
Re:ほんとうに忘れたの？ (スコア:1, すばらしい洞察)
そのためにSEが経営語と技術語の翻訳＆両者のエージェント
として存在するんじゃないのかと。まぁ仕事していると違う
っぽい人が多いですけど。。。
Re:ほんとうに忘れたの？ (スコア:1, 参考になる)
最近は分業化が進んでいるため、その役割はSEという肩書きの人ではなくコンサル(コンサルタント)と呼ばれる人がやってます。
ところが業務方面からやってきて技術方面のスキルが異様に低い人なんかも同じくコンサルと名乗ってて紛らわしいことが多いです。
依頼するお客にその辺の区別がつくはずもなく、受けた側もとりあえず仕事として片付けるので、結果として使い物にならないシステムが出来上がったり。
なんでコンサルなんて言葉が流行ったのかな。
昔あったSA(システムアナリスト)の方が分かりやすかったが…でも今だとシスアドと区別つかなくなるか。
やれやれ。
Re:ほんとうに忘れたの？ (スコア:1, 参考になる)
>の組み込みを忘れた」とありますが、機能検討や設計の段階でそのよ
>うな機能は考えられておらず、元々仕様に無かったということはあり
>えないでしょうか？
無かったんじゃないですかねぇ
というか、手入力の部分じゃないでしょうから間違わない事を前提で作られていたのでは？
で今回データーフォーマットが変わって、異なるフォーマットのデーターが混入->問題発生と
この部分でカードすることも必要ですが、実際はその前の段階で変換しフィルターを掛けるのが今回追加された処理だと予測すると、そこもバグってたんでしょうね
それを既存Bugというのならちょっとつらいかも
まぁどの部分にしてもBugはBugなんですが(苦笑)
私的には入力が絶対正常であることを前提にしたプログラムなんて
怖くて組めませんけど...
他人の作ったプログラムなんて信用できませんし、自分の作ったプログラムはもっと信用できないですから(まて(笑
想像ですが。 (スコア:2, 参考になる)
正直言ってここまではよくあることだと思います。
（例えばドコモが無茶苦茶なデータを送ったらほとんどの携帯が
ハングするんじゃないだろうか･･･）
で、今回の改修により「実運用上ありえない」パターンが発生
してしまいダウンしてしまったと。
「次回修正」とした項目を入れ忘れてしまった事がNECのミスでしょうね。
普通は誰かが覚えているはずなのですが、前回ミスしたのも
バグを発見したのも外注で今回は別の外注がやったとかも
ありえるし。(^^;)
#異常系の試験ってどうしても後回しになりますよね…；
実運用上あり得ない (スコア:2, 興味深い)
政治の場でも、セキュリティ対策でも、何でも。「あり得ない事」などと簡単に言い切ってしまって後になって痛い目にあう、という事を何度と無く目にしていると、とても正常な判断が出来る人間が説明する理由ではないなあ、と感じてしまうのです。
実際には、放置していて結果として何も問題が起きない事の方が「とても多い」でしょうけども、それが「事実上あり得ないという理由が真っ当なものである根拠」になるとは思えません……。
バグ改修の優先度 (スコア:1, すばらしい洞察)
バグ改修を行わない、のではなく、バグ改修の優先順位を下げる、という判断がなされただけではないかと思います。
バグ改修を行うためには、発注元の了解を取り付けることが必要になりますが、その際、リリース前に検証したにもかかわらず、なぜそんなことが発生したのだ、という議論だけが先行して、実際のバグ改修がなかなか始まらないことがあります。また、そういった理由から、いったんリリースしてしまった後のバグ改修はあまり回数を行うことができない、といった負のバイアスが現場にかかるのも事実です。
そのため、いそぎでないバグ改修であれば次のリリースに含めて対応しようとする方向になるのも不思議ではありません。また、このバグが発見されるのが、その次のリリースのための機能追加の最中だったりしたら、そんな時期に検証のリソースはさけないため、とりあえず次のリリースまでもってくれ、と祈ることになるのでしょう。
やれやれ、なんかやりきれないな。
Re:実運用上あり得ない (スコア:1)
今回は特にあと２ヶ月でバージョンアップすることは
決まっていたでしょうから。
現場の人間としてはなおせる物ならすぐになおしたいんでしょうが
会社間レベルとかになってくると「事を荒立てない」という要素が
一番強かったりする。。。。
インフラと電化製品を一緒にするなという声が聞こえてきそうですが
末端の外注、子会社レベルになると机を並べていたりするわけで。(^^;)
#書いててやるせなくなってきますが
#他コメントにもあるように現状はこんなもん；
Re:実運用上あり得ない (スコア:1)
プログラムの不具合やテスト条件の不備を指摘したときにとてもよく聞く台詞です。
実際には、その「あり得ない」ケースが実によく発生します。
手抜きの言い訳ぐらいにしかとらえていません。
Re:実運用上あり得ない (スコア:2, 参考になる)
あと類似ケースとしては、プログラムの一部を他のプロジェクトに流用してしまう人がいて、そのまま一人歩きしてしまい、思わぬ使われ方をした結果、トラブルが発生したこともあります。
そのため、無駄とわかっていても、関数単体レベルでどんな入力があっても致命的なエラー(ダウンするとか例外で落ちるとか)しないようにしたり、それができない場合はドキュメントに制約を明記したりするようにしています。
もっとも、他プロジェクトへの流用は、この問題の他にも、やり方によっては著作権や機密の問題も絡んでくるので、作った担当者と上司(場合によっては法務関連も)の許可制としている所もありました。
プログラマって２種類ありますよね (スコア:1)
どちらも現状は100%問題が発生しません。前者も後者もいろいろな意味で問題があるのでしょうけど。PGからPMまでの意思疎通がうまくいっていて、PMが立派な人だったら、こういった問題は減るんでしょうかね。
Re:プログラマって２種類ありますよね (スコア:1)
そうでない体制の場合、実際にバグであるとしてクレームがやってきたり責任を問われるわけで、クレーム防止のためにも後者を選んだ方がトータルでは短時間ですみます。(逆にそういう体制の場合は仕様変更になります)
そうなんでしょうけど、そんなPMは極少数しかいないですし。それに一人が把握できる範囲には限界もあるし。
あと、良くあるパターンとして、PGにシステムの全体像や背景が知らされていないため、仕様に対して違った解釈をされて、的外れなものを作っちゃったりとか。
Re:実運用上あり得ない (スコア:1)
「自動車を凶器として 人を傷つける」
「法と道路事情を無視した 速度で自動車を運行する」
前者ふたつはバグの話とはちょっと違うのではないかな。
ただ、最後の道路について言えば、路面整備の段階で穴や継ぎ目が残ってて高速で走行すると危険だと分かっていても、制限速度が低い道なら放っておきますね。「この道をそんな速度で走ることはありえない」って。
で、その後いろいろあって、その道の制限速度が引き上げられてしまったら?
今回のポイントは“ありえないから問題点を放っておいた”ことではなくて、状況が変わってありえるようになったときに問題点を“思い出せなかった”ことではないのかなぁ。
そういう問題点管理に手落ちがあるのは事実で責められても仕方がないんですが、責める点を間違うのは問題がぼやけてしまって良くないと思う。
Re:想像ですが。 (スコア:1)
参考というか茶々というか。Jargon file から"Can't happen" [jargon.net]
明日はわが身か・・・ (スコア:2, 参考になる)
全然根拠のない予想ですが、ある人のうっかりミスとかNECの企業体質の問題とか、そういうものではないような・・・
今のシステム開発の限界というか、うまく言葉にできませんが、現場の人間に話を聞けば、
「あんな現場じゃ起こって当たり前だよ」
とかいう言葉が返ってきそうで。
みずほの時もそうでしたが、クライアントに問題があればコンサルごと送り込んで造らないといけないのかな・・・
Re:明日はわが身か・・・ (スコア:1)
わしみたいなのが、システム開発に携わってるから、動かないコンピュータが増えるんですな。
吊るしかねーか・・・
Re:明日はわが身か・・・ (スコア:1)
>いうのでしょう？教えてほしいです。
うーむ。言葉が足りませんでした。
解りやすく言えば、ITコンサルを入れる必要ですね。
魚屋に魚屋の達人を送り込むってことではなく、魚屋にWebページの作りかたを教えてくれる、先生を送り込むってことです。
まぁ、それができないからここに書いてるわけです。
バグを黙ってたなんて (スコア:2, おもしろおかしい)
恐るべき逆説 (スコア:2, すばらしい洞察)
今回は「バグを見つけていた」から責任が問われたわけで, 逆に見つけていなかったら責任が問われないとしたら(ユーザの受け入れ検証が完了していて, 瑕疵担保期間が過ぎていたとか), 一体どうなるんでしょうかね? 開発側では保証期間が過ぎたらコードを参照することは禁止なんてことになるのかな?
航空機事故では責任を問わないことにして問題の公表を促すようにしているんですけど, コンピュータシステムでは知らぬ顔を通す方が無難ってことになっちゃうのかな?
でもさ・・・ (スコア:1)
衝突したりするわけですよね。以前も、航空管制の人的ミスで
ニアミス起こすわ急激な高度変化で乗客に怪我が出たりしま
したよね？
私もコーディングしますが、研究のコーディングで多少バグっ
たり対処後回ししたりします。今回のは人命にかかわること
だと思うので・・・ずいぶん簡単に考えてたなぁ＞＞ＮＥＣ
-- gonta --
"May Macintosh be with you"
Re:でもさ・・・ (スコア:2, すばらしい洞察)
ずいぶん簡単に考えていた、ではなく、簡単にその影響を調べることが
できなかったのではないか、ということではないかと気になります。当
のNECが影響の大きさを検証できていなかった、または、検証できる環
境がなかったのではないか、と。ケアレスミスだった場合は、弁護の余
地はありませんが。
航空管制のハードっておそらく、そんな二つも三つも用意できるもので
はないですよね？全く本番とハードウェア的にも、入力データについて
も同じ環境構築を用意できないと、どれだけ単体テストをしても本番実
施までみえないことがあります。特に、今回の件、システム間連携の部
分がらみということで、評価がかなりやりにくいところだったのではな
いでしょうか。
また、NEC側の想定が甘かったとして、それを指摘できる人間が航空管
制部側にいない、ということも問題のひとつだと思います。そして、そ
れらを総合して、リスク管理のできていないNECと発注元の責任という
のも、決して少なくないと思います。
発注元がNECに対して損害賠償請求をしたりするのは勝手ですが、それ
でことを済ませるのではなく自分の足下を見直すようにするべきでしょ
う。
# 別に関係ないといえば関係ないんだけどAC
Re:でもさ・・・ (スコア:1)
影響の想定が甘かったのかそうでなかったのかはわかりませんが、結果としてはバグの存在を全く報告しなかったのが問題のように思います。
もしバグの存在が知られていれば、後者のプログラム変更と同時に該当バグを見つける試験項目を挙げることも、あるいはバグ修正も可能であったようにも思います。
ま、バグを報告して修正しないままにするというのも難しいかもしれませんが。
Re:報告していても(でもさ・・・) (スコア:1, 興味深い)
仕様上あり得ない。事実、(他の部分の)仕様が変わるまでなかった。
将来に渡ってあり得ないと断言できなくても、発生する可能性も断言できない。
手を加えることのリスクとコストを考えれば、顕在可能性の低い穴は放置が基本。
これはソフトに限らず、ハードでも、人事でも、何でもそうです。
あり得そうにない事態に対処するために、必要かどうかもわからない
冗長性を新たに追加するなんて、常識ではあり得ないことです。
国土交通省に報告が行っていても、同じ判断になったでしょう。
あり得そうにない事態を想定した時に起こる不具合なんてのは、いくらでもあります。
そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
NECが報告を上げてなかったと言っても、それが当然で、もしいちいち報告したら
国土交通省の業務はそれだけでパンクするでしょうね。
Re:報告していても(でもさ・・・) (スコア:1)
穴がある間、その周りを通る人は注意深くなります。
今回と同じ結果になる確率はそれなりに下がるでしょう。
>そんなものをいちいち報告していたら、妄想癖のレッテルを貼られて病院送りです。
それはただの言い訳ですな。
Re:でもさ・・・ (スコア:2, 参考になる)
Re:でもさ・・・ (スコア:1)
＃IEのCSSバグが直ると、バグを前提としたページが崩れる、みたいな。
Re:でもさ・・・ (スコア:1)
オープンソースの場合：
まず直す→不具合が出たらそこを直す→また不具合が出たらそこを直す→…
大規模な基幹システムとかでこの手法を使ったら、
一回のリリースごとに一人の首が飛んだりするのかなぁ…
＃屋上から飛ぶのに比べれば首が飛ぶほうがマシだとは思う
# mishimaは本田透先生を熱烈に応援しています
効率的な離陸が出来なくなるだけですよ (スコア:2, 参考になる)
将来的には飛行機の管制業務の自動化もあるかもしれませんが、現在のところは計画をデータベース化して閲覧しやすくするためのシステムにすぎません。
すでに離陸した飛行機はフライトプランを承認され、計画通りに飛行する限りは安全を保証されているわけです。
衝突の回避と緊急時の指示は、自動化できないため従来通りに管制官が行っているので、FDPの障碍で飛行中や着陸する飛行機が事故を起こすことはありません。
・・・だからといって、対処を後回しにしていいわけじゃないんですけどね。実際、離陸は中断され、由緒正しい手作業での確認を余儀なくされたわけですし。
--- どちらなりとご自由に --- --
Re:効率的な離陸が出来なくなるだけですよ (スコア:2, 参考になる)
でも、管制官向けのストリップは適宜最新状況を反映した
ものが渡されるのだけど、ＦＤＰがとまるとこれができな
くなるわけなんですよ。
空港管制だった管制官の範疇に近いので管制官の技量でなん
とかなるだろうけど、航路管制だと割り振りが難しいことに
なりそうで、それが尾をひきそう。管制官のストレスにはな
りそうで、ミス誘発とかありそう。
# FADP関連のお仕事をむかしやっていたのでＡＣ
最も集中するところ (スコア:2, 参考になる)
途中の飛行経路は高度毎に進行方向を分けられた、一方通行の高速道路みたいなものですから、飛行計画が適正である限りは非常事態の発生や、パイロットが故意に高度・速度・進路を変更しなければニアミスは発生しません。
そもそも途中経路は東京コントロールの管制下にある為、飛行計画承認の為に各空港から送られてきた最新情報が利用可能だと思います。
一番の問題はレーダー画面上に便名が表示されなくなることですが、トランスポンダーから送信される高度や速度の情報は表示されているので、管制官本人がチェックを怠らなければニアミスは回避できます。
当然、非常時に備えてレーダーと無線のみで全ての管制を行なう訓練は受けているはずですしね。それに、そもそも離陸中断で飛行中の期待の数は一定量以上に増えることなく、逆に減っていくわけですから。
レーダーとラジオが生きていれば、管制官は管制業務を継続することができます。頼りのレーダーすら使えなくなる状況 [cinemakun.net]というのも、想定できるわけですから・・・。
--- どちらなりとご自由に --- --
Re:効率的な離陸が出来なくなるだけですよ (スコア:1)
すみません、読売だけじゃわからないですね。
どこで資料を見かけたんだっけなー・・・。（ｗ；
--- どちらなりとご自由に --- --
Re:効率的な離陸が出来なくなるだけですよ (スコア:2, 参考になる)
Re:でもさ・・・ (スコア:1)
などの場合は、正直いって「次回改修時にまとめて」といった 対策を取る事は多いんじゃないかと思います。
たとえ1行の修正でも、単体テスト・複合テスト・変更申請・入れ替え・立会いと
ものすごい手間とコストが掛かる場合がありますし
「修正したことによって問題が発生する」事も多々ありますから・・・
悪いのは高橋主任？ (スコア:1)
航空--高橋主任 [nas.co.jp]、彼の言うとおり、
しましたね。ええ、それはもう。
これって (スコア:1)
# ACなのでAC
発見したにも関わらず・・・放置？ (スコア:1)
# もちろんって声が聞こえる...
NECの見積が甘いだの、危機管理が甘いだのっていうけどさ、受注したのがNECだってことは、発注元が「H/Wベンダーの責任だろっ！」とかって喚いて買い叩いた可能性もあるよね。
いくら精度の高い見積を出したって、ものをつくる、ってことの意味が判らない人たちが数字だけで「見積が高い」「納期が遅い」なんて文句を言ってくるのは最近当たり前のようになってるし。
その金額じゃ出来ない、ってことを説明してもハナから理解しない人が多くありませんか?
試験の工数ってバカにならないし、技術が判っていない人ほど「そんなに試験しなきゃならないほど技術レベルが低いのか！」って文句言うし。
結局、金額が折り合わない -> 契約が遅延する -> リリース日は決まっているので開発期間が短くなる -> 問題発生！ -> 現場のせいにする。
こんなパターンを何となく想像してしまいます。
# あぁ、完全にグチになってる...
責任逃れ? (スコア:1)
止まった直後に「管理体制の甘さ」と言わず「一局集中の弊害」というミスリード がマスコミに流れたりして、現場の責任者の顔が見えずに管理とは別の 原因ばかりマスコミが取り上げられている。 こんなニュースが流れるってことは、現場の担当者のマスコミ対策が うまく行っているだけなんじゃないかな?
-- 哀れな日本人専用(sorry Japanese only) --
オープンな環境 (スコア:2, 参考になる)
は、PC/ATというオープンなプラットフォームが広く入手可能で
あり、TCP/IPのネットワーク環境が整備されていて、また、コン
パイラなどの開発環境が広く入手可能だからだと思います。多く
の人間が検証可能な環境を持っているから、その中から実際に検
証を行う人間が出てくるのだと思います。
航空管制に必要な、ハード・ネットワーク・開発環境を簡単にそ
ろえることができれば、「オープンソースにすれば」という意見
も現実味を帯びてくるとは思いますが、当事者ですら本番環境と
同じ評価ができてなかったわけですから、それは、望むべくもな
いのではないでしょうか。
Re:もしかしてJava? (スコア:2)
vyama 「バグ取れワンワン」