それはそいつがアホだからでは何も変われない。

何か問題がおきたとする。
その原因はやらかした奴がアホだからって理由を結論にしたらだめだと思う。

なぜ、彼はそうしたのか、そうしなければいけなかったのかを考えるべきだと思う。
一つの問題(インシデント)の裏には改善するべき問題が山のように積まれている。

たとえば、*.csv ファイルがhtdocs 以下に上がっていて情報漏えいとかよくある。
また、社内LANを利用してヒートランテストしたらネットワークに負荷がかかって他の人がwebを見れなくなったとか、
メール配信のバッチのテストをしていたら間違えてテスト用のメールをお客さんに送っちゃったとか。

どれもおきてほしくないイヤな問題だ。
これら問題でそれはやらかした本人のスキル不足、または配慮不足、、ようするにやらかした本人がアホだからという結論にしてはいけない。
なぜ彼らは、そうしてしまったのかを考えて制度や仕組みを変えるべきだと思ってる。

*.csv が htdocs以下に上がってしまうのはなぜか？
多分、置いた本人になぜ置いたのか聞けばこう答えるだろう。

そこにしか置く場所がなかったから。
どこにおけばよいか分からなかったから。

最初からデータを保存するときはここにおいてくださいねーってポリシーが決まっていれば、彼らはそれに従っただろう。
もしポリシーが定まっていて、彼らにそれが伝わって十分理解していなければ、htdocs以下に csv ファイルが上がることはなかったはずだ。

ポリシーが定まっていないのであれば、システム管理者の怠慢だし、それが伝わっていなければアピール不足だし、理解されていないのであればトレーニング不足だろう。

自由分理解してもらって、それでも間違いが発生したのであれば、作業フローや検収フローに問題があるか、、、あるいは悪意をもってそうしたかのどれかだろう。

こんなに改善するべき場所があるではないか。
これをそれはやった奴がアホだからの一言で片付けてしまっては何も変われないし、何度でもミスは繰り返すと思われる。

社内LANを利用してヒートランテストしたらネットワークに負荷がかかった事例はどうか。
何でそんなことしたの？って聞けば

それしかやりようがなかった。
他の方法がアナウンスされていなかった。

と答えるだろう。

これも上の理由とまったく同じで、事前にヒートラン環境が整備されていて、ちゃんとアナウンスして理解してもらっていればこんな問題はおきなかったと思われる。

最後のメール配信のバッチのテストをしていたら間違えてテスト用のメールをお客さんに送っちゃった問題はどうか。

これも同じくテスト環境の整備がされていない、バッチプログラムがテストされることを前提として設計されていないなどの問題が出てくるだろう。

これまた改善するべき問題はたくさんある。

余談だけど、私がバッチを作るときはディフォルトをデバッグモードにして、画面に表示するだけにし、データベースに書き込まなかったり(rollback)、メール送信を行わなかったりするようにしている。
オプションで非デバッグモードを指定したときだけが本番モードとして動作し、データベースへ書き込み(commit)や実際のメール送信を行うようにしている。
最近は now() や time() の代わりに外部から日付を注入できるようにしたりとデバッグすることを前提の設計を行っている(つもりw)。

問題がおきても、それはそいつがアホだからでは、隠された改善ポイントに気が付かないし、気づけないと思う。
なぜ彼らはそうしたのか？を考えることで問題の本質を改善できるのではないのかと思う。

#理由を考えた、、、そしたら、これはどうあがいても無駄と思うなら、
#すべてを破棄して逃げるというのも選択肢の一つのような気もするが。。。www