世の中、信じられないことばかり

昨日は阪神淡路大震災から15年でしたね。

こういう天災ではなく人の手が入ったことによる人災の話は聞いてて脱力しちゃいますね。

何故防げなかったのか？とか何でまた同じ間違い繰り返してるの？って。

そういうアンチパターンって何故かパターン化して繰り返されるわけで。

業務システムのための上流工程入門―要件定義から分析・設計まで
	おすすめ平均 記述内容はとても良いが、モデリングが独自なのが気になる オブジェクト指向アプローチを学ぶ前に 上流工程のル―ル化促進を期待します システム屋にとって感動を呼ぶ本でした 上流工程の入門書 普段、開発やってる人間がどんなノリで開発してるのかなんて事を知るために良い本だと思います。 何故、それをやると失敗するのか？なんて事もさらっと書いてますし。

自分はソフトウエアの開発していますが大体の失敗するパターンって単純なミス、気持ちの緩み、何が大事かを考える習慣を持たない事から起きるんだと思ってます。

だから全てと言うわけではありませんが凡そソフトウエアで制御されているシステムに関しては50％も信頼していません。
たとえば、銀行、飛行機、新幹線 etc.

銀行ならATMで引き出した金額があってるか？残金はあってるか？
飛行機は自動操縦を正しく行っているか？
新幹線は線路の異常をリアルタイムに検知出来ているのか？ など等。

そられは全て人のすることだからミスもあるんじゃない？って前提に立ってて。

たとえばこういう例ならわかりやすいかもしれません。

ある会社が電車を作ることになりました。
その電車の仕様はこんな感じです。

１．100キロ以上の速度が出ると自動的に100キロにする。つまり100キロ以上は出ない。

これを忠実に守って電車を作ると作る環境によっては面白いことになります。それを単純な例で書くと。

仕様のあいまいさの問題
１００キロ以上出た時に100キロにするのですが定義があいまいなので速度が下がった時の仕様が明記がされていません。
普通考えたらわかるやん？って思われるかもしれませんが設計段階ではこの微妙なニュアンスは致命傷になります。

101キロ出た時点で100キロになりますが100キロから90キロになったら90キロにする仕様の明記がなされていません。
これって一旦、100キロ出たら二度と100キロ以下にならない電車になります。

これはほんとに極端な例なので一般の開発でこういう事が起きるとは思われません。でもそのプログラムを作ってる人が致命的に日本語が不自由な人だったら？ 起る可能性は十分にあります。

今はオフショア開発が盛んになりつつあるので設計書を用いて実際にソフトウエアを作る人が全て日本語に堪能と言うわけではない時代ですし。

開発環境に問題がある場合
もし開発した電車をテストしている環境が100キロ以上の速度が出るだけの電力を電車に送ることが出来ない環境で且つテスト担当者が自身のテスト環境の詳細を知らなかったら。若しくは気にしていなかったら。

こういう環境で電車のテストを行った場合、表向きその電車は100キロ以上速度が出ません。
だから仕様は満たしています。 で、テスト合格(^_^.)

そしてその電車が200キロ以上の速度が出る電力を供給することが出来る設備で運転されたら・・・・・

これまた極端な例ですが実際に発生したソフトウエア事故って笑ってしまうくらいにこれに近い単純なミスで発生していますよ。

こういう事なんです。僕がソフトウエアを介して制御されているシステムを信頼できないのは。

そしてソフトウエアだけでなく色んな部分で心配な事がたくさんあります。

先日こういう光景をみました。

生後間もないと思われる赤ちゃんを抱っこバンドにぶら下げたままで両手でマクドのトレーを持ってたお母さん。
もしその抱っこバンドが切れたらどうするの？って。
バンドのとめ具が劣化してて壊れたらどうするの？って。

自身でも病気かなぁ？って思ってしまいますが心配なんですよね。

だからそう言うバンド類は使用する前にかなり念入りに引っ張ったり留め具の強度を測るために繰り返し引っ掛けたり外したりを繰り返しします。
時々確認中に壊してしまったりするんですが（笑）
でもそんなときはやっぱり確認してて良かったぁ～なんて安心するんです（爆）

と言いつつ家族にはもっと違う事を気にしろ！！っていわれますが。
食品の賞味期限。 気にしていない人の名前と顔を覚えないこと。今しゃべってる内容とか。もしかしら僕が一番危ないのかも（笑）

独り言でした。