先日重大事故が
あり、メーカーが問題を認めたというニュースがあったのですが、
SEも同じように重大（何を重大とするかはシステムによりますが）インシデント発生時の行動はかなり文化や状況に影響されます。
もし、全部自責だった場合であっても公表されるとは限りませんから。
完全な愚痴なんで、うんうんって思う人もいれば、なんだこれア〇がかいてるのか？って思うかもしれませんが暇な人はお付き合いください。
- 作者: Andreas Zeller,中田秀基,今田昌宏,大岩尚宏,竹田香苗,宮原久美子,宗形紗織
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/22
- メディア: 大型本
- 購入: 4人 クリック: 184回
- この商品を含むブログ (8件) を見る
難しいのは
車やものを作っている人は分かると思うのですが、顧客（ユーザ）がどのようにつかっているかを正確に把握していないと、再現性がなかたり、作りてとしては意味不明な問題によくぶちあたります。
ユーザは体験してしまっているので問題だ！問題だ！賠償だ！賠償だ！ってなりますけどね。
でも、そんなことどうやったら起こせるの？っておもうこともあったり、あっ、あのバグ（懸念事項）が商用で出ちゃった？なんてことをを心の中でおもうこともあります。
一般的に大量生産の既製品の場合、一定の品質管理が行われ、保障も環境も充実している（と勝手に思っている）のですが、一品もの、受注生産物に関しては、その企業の要望、独特の文化などを反映することにより、思ってもみないインシデントが発生します。
辞めたから言えることですが、開発現場のSEが絶対そんなバグは出ない（ない）っていう言葉の裏の5割はウソです。
さらにいうと、即答える場合は8割嘘です。
（言っているのが営業の場合は単なる無知です。許してあげてください）
そして残りがマジでH/Wや他責によるバグです。一番つらいのはブラックボックスのH/Wバグです。
まだネットワーク機器等のFWはベンダーとの契約を実施していればまだ対応してくれるのですが、例えばCPUやメモリ等個別部品のバグを引いたり、H/Wの電気的揺らぎの影響をうけて発生してしまった場合はもうすげー大変です。
どうやったって二度と再現しないものも存在します。（可能性だけ考えるとH/Wがこううごけば、この問題が同時に起きた場合は発生する可能性があるよとか、、、いわれてもね、、おこせねーよ）
特に人命、大金が係わった時
人命は自分が係わったシステムで間接的に首きられて。。。みたいなのはあるかもしれませんが、X・・・XX円/秒*1の損失がでてるんだどうするんだ！っていわれたことはあります。
(感情的になっているので）マジ〇ね！の言葉が飛び交う会議も経験してます、私がターゲットじゃなかったのでよかったですが、、、くわばらくわばら。
あっ、逆はあるな( ´艸｀)、超理不尽な顧客で私の琴線に触れてまでも突っ込んできた人に、、、（その人の部下からその後ご丁寧な謝罪がありましたが）
それはおといて、そんなとき、あーうちのあそこが原因だって即判断できるときもあるわけですよ。（時間かかることが普通ですよ）、顧客との対策会議中絶対に分かっているとばれてはいけない緊張感。弊社関係者は分かっているけど絶対に言えない*2闇･･･
そういうのをサクッと認められないとき、胃が痛いです。
自分が医療関係のシステムや人命に直接かかわる可能性のあるシステムには絶対に近寄らないと決めているのは実際には起きなかったですが*3、想定で起きたら人が死ぬってのがわかった時如何に怖いかを身をもって体験しているからでもあります。
何重にもかけている保護システムが万が一作動しなければ･･･みたいな事です。
昔記事にもかきましたがとある場所に大震災、隕石が落ちてきたときどう復旧するか、どこまでなら耐えられるかまで机上確認してた時代もありますので。
A電源すらおちて、メカニカルな保護すらうごかなかったら、、みたいなのを普通に考える担当だった時に決意した事です。
100%バグなしリリースはない事
ぐらい顧客だってしっています、事前に既知バグや、可能性をまとめたリストを渡しそれでも稼働すると判断しているわけですから。
車とか既製品でいうと、こういう場合は誤作動するよ！てきな説明書を必ず書いておくみたいなことです。
で、そこに当てはまった場合は顧客もトーンが下がるので楽なのですが、今回のニュースのように人命が係わってしまうようなケースはどうしようもないですよね。
金で解決できないものの一つであります。
だってさ、他システムの電源やLANケーブルを掃除のおばちゃんに引っこ抜かれたのがトリガーでした、、、とかでも怒られる世界だったんですよ。施工業者にそういうところにケーブルやスイッチないようにつくってもらえよってかんじですよね。（高いのでやらなかったんですが）
それすら業務SEのバグなんですよおかしいでしょ。
せめて、想定通り動作しなかった。AS構成しているのにタイムラグがコンマ何秒想定より遅れた、、、トランザクションがいくつか見当たらない。
うーん、みあたらなくなる可能性あるよって言ったじゃん、ロールバックしてるからいいじゃん。的なものならまだ納得。。。できませんが言われて当然ですからね。*4
話はもどしてそれを公表する
エンドユーザに原因と対策を公表する勇気はすごいパワーがいります。規約にかいてるでしょ？で終わらせられる案件であってもそれを言ってしまうと企業としての信頼がなくなるとかね。そしてそんな問題だったのか？本当にそれが原因だったのか？
今の時代ネット検索や頭のいい人達が検証しようとしてしまいます。
小さいシステムならそんな暇人もいませんけどね。
大規模システム経験してると、マジいるんですよ一定数。
絶対個人でデバッグやってる奴が
こんな短時間に1契約（個人・端末）から操作はできないし、意味のない動きがLogからみえるんですよ。
そして、特にリリース後（Verが変わった時）顕著に増えます。
面白いのはそういうルートもあるのか？って次の試験項目に追加される事もあるんですけど( ´艸｀)
そして身近にあるものだと、公表すると必ず大勢の再現させてみよう、対策されているか確認しようという輩がいます。ジャーナリストとかそうですよね。
個人で完結するシステムならいいですが（たとえばネットにつながってないPCパーツとか）インフラに近い環境でもそれをする輩は必ずいます。
もちろん基本は対策しているので、ご苦労様です、、なんですけど、対処が甘いと、藪蛇になって違うインシデントが発生します。負の連鎖です。*5
なにかいているんだろう俺( ´艸｀)
単なる苦労話か？SIerの闇暴露か？
まとめ
企業理念がしっかりしていて、原因が明確であればさっさと公表して事後対応するのが好ましいのは当たり前なんですが、それが出来る出来ないはマジで状況によります。
一番怖いのは、お客様は神様です、仕様？規約？そんなのしったことじゃないがまかり通り（日本は多い）作り手が委縮し業界が成長しないことなんですよね。
問題・事故は起こさない事が第一ですが、起きる可能性は必ずあるのですから。
実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング
- 作者: Norman Matloff,Peter Salzman,相川愛三
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/06/08
- メディア: 大型本
- 購入: 10人 クリック: 199回
- この商品を含むブログ (31件) を見る
