アカウント名:
パスワード:
ファーストサーバー:担当者のマニュアル無視を容認、独自プログラムで更新 削除コマンド消し忘れ [itmedia.co.jp]
>報告書によると、同社のシステムメンテナンスは通常、社内マニュアルに沿って行われるが、不具合を起こした担当者だけは約10年前からマニュアルを無視し、自ら作成した更新プログラムを利用するなど独自方式でメンテナンスを行ない、上長もそれを容認していたという。
>何か問題が起きた時に解決するためのツールを開発する必要
地雷原というか、ソフトウェアの機能安全規格(ISO 26262、IEC 61508、IEC 62304など)からは真っ向から反目する流れですね。
最低限のプログラム能力もなければ、独自プログラムを書くことも出来ないから、安全だというものでも無いでしょう。
プログラム能力の有無に関わらず、担当者や管理者は大抵、失敗や大失敗の経験がある。
それでも惨事を広げないために、色々対策がなされていて、また失敗を繰り返さないためにマニュアルやルールが作られている。
件の事件は、マニュアル無視、上司の容認、システム設計不備、組織の下から上まで内在していた問題が連鎖して大惨事になったのです。
担当者レベルのプログラミング能力の有無に話を持って行くと、問題の本質を見失うと思われます。
ソフトウェアの安全規格というのは、プログラミング能力というより、バグを作りこまないためのプロセス管理規格のように感じます。
タレコミ文からプロセスを無視するような独自方法を編み出せという意図が感じられたのでそのように書きました。
天才的な能力に裏打ちされたのは、うまく行っている間は良いのですが、問題が起きたときに、重大な結果を招きやすいように感じています。バグの無いソフトウェアを天才が作り上げる時代は終わり、凡人がプロセス管理された状態で、一定以上のバグを作りこまないように進めるというのが、現在の主流に思います。
元記事の筆者も、IT忍者という言葉を使っているように、非正規軍的な活動が念頭にあるのでしょうね。
こういう気分のまま、機能安全規格を必要とするようなソフトウェアを開発するのは、危険だと思います。
しかし管理される対象も、安定運用が絶対のシステムから、日々改造されることが競争力の源泉になっているシステムとか、壊れても被害を許容できる代わりに費用も掛けたくないというシステムもある訳です。
またシステムの安全を確保するために、人的なコストを掛けるか、ハードにコストを掛けるかというバランスもあります。
この程度の危険思想あるいは退嬰的思想の管理者がいてもシステムに依っては良いと思われます。(私も、元記事の筆者も恐らくは、その程度のシステムの方が まだまだ大多数だと想像しています)
>真っ向から反目する流れですね。
そもそも存在する奔放な流れを制する為の規格ですからね。放置すればすぐ染み込んで来る危険な流れをいかに断つかということも「規格」の値打ちかと考えられます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
危険 (スコア:2)
ファーストサーバー:担当者のマニュアル無視を容認、独自プログラムで更新 削除コマンド消し忘れ [itmedia.co.jp]
>報告書によると、同社のシステムメンテナンスは通常、社内マニュアルに沿って行われるが、不具合を起こした担当者だけは約10年前からマニュアルを無視し、自ら作成した更新プログラムを利用するなど独自方式でメンテナンスを行ない、上長もそれを容認していたという。
>何か問題が起きた時に解決するためのツールを開発する必要
地雷原というか、ソフトウェアの機能安全規格(ISO 26262、IEC 61508、IEC 62304など)からは
真っ向から反目する流れですね。
Re:危険 (スコア:1)
最低限のプログラム能力もなければ、独自プログラムを書くことも出来ないから、
安全だというものでも無いでしょう。
プログラム能力の有無に関わらず、担当者や管理者は大抵、失敗や大失敗の経験がある。
それでも惨事を広げないために、色々対策がなされていて、また失敗を繰り返さない
ためにマニュアルやルールが作られている。
件の事件は、マニュアル無視、上司の容認、システム設計不備、組織の下から上まで
内在していた問題が連鎖して大惨事になったのです。
担当者レベルのプログラミング能力の有無に話を持って行くと、問題の本質を見失うと
思われます。
Re:危険 (スコア:1)
ソフトウェアの安全規格というのは、プログラミング能力というより、
バグを作りこまないためのプロセス管理規格のように感じます。
タレコミ文からプロセスを無視するような独自方法を
編み出せという意図が感じられたのでそのように書きました。
天才的な能力に裏打ちされたのは、うまく行っている間は良いのですが、
問題が起きたときに、重大な結果を招きやすいように感じています。
バグの無いソフトウェアを天才が作り上げる時代は終わり、
凡人がプロセス管理された状態で、一定以上のバグを作りこまないように
進めるというのが、現在の主流に思います。
Re:危険 (スコア:1)
元記事の筆者も、IT忍者という言葉を使っているように、
非正規軍的な活動が念頭にあるのでしょうね。
こういう気分のまま、機能安全規格を必要とするような
ソフトウェアを開発するのは、危険だと思います。
しかし管理される対象も、安定運用が絶対のシステムから、
日々改造されることが競争力の源泉になっているシステムとか、
壊れても被害を許容できる代わりに費用も掛けたくないという
システムもある訳です。
またシステムの安全を確保するために、人的なコストを掛け
るか、ハードにコストを掛けるかというバランスもあります。
この程度の危険思想あるいは退嬰的思想の管理者がいても
システムに依っては良いと思われます。
(私も、元記事の筆者も恐らくは、その程度のシステムの方が
まだまだ大多数だと想像しています)
>真っ向から反目する流れですね。
そもそも存在する奔放な流れを制する為の規格ですからね。
放置すればすぐ染み込んで来る危険な流れをいかに断つか
ということも「規格」の値打ちかと考えられます。