障害が発生したらエンジニアに罰則

お客様のご予算の関係で、スケジュールの関係で、というような様々な理由でアーキテクチャーには飲み込まれた脆弱性が存在している。昔テレホンバンキングの延長線上のちょっとした取引形態としてスタートしたインターネットバンキングの仕組みも、今は社会の金融インフラとして重要な位置を占めるに至っている。しかし、予算やスケジュールというようなことで度重なるシステム更改でも抜本的な対策が行われず単純更改（ハードウェアとOSミドルウェアのバージョンアップのみ）が行われる。しかし、コンシューマーの動きも変化しトラヒックの制御も難しくなっているし、サイバーアタックのリスクも高まっている。予算やスケジュールという営業カレンダーを理由にして、システムの稼働を危険にさらすような単純更改のような判断はするべきではない。
しかし、単純更改の魅力は大きい。システムは稼働を続けることができるし予算も膨らむことはない。新しい技術は採用しないのでこれまで通りに設計運用することができる、お客様を説得する必要もないし、お客様だって一担当者だから面倒なことは先延ばしにしたい、そんな思惑にぴったり一致しているからだ。もちろんお客様の経営層やビジネス戦略担当はIT部門に新しい技術の要求はしているのだろうけれど、お客様の担当者はシステムに追加のコストもなく稼働し続けていることが大事なのである。ITベンダーの営業はどうしてもお客様の担当者から稟議をあげてもらうということから、予算とスケジュールの御用聞き営業になってしまう。
とあるところでは、設計や運用などのエンジニアリングの課題からシステム障害を引き起こした場合に、原因となった設計エンジニアや運用エンジニアに罰則を与えるべきというようなことが検討されている。システム障害などでコストオーバーランしても営業にペナルティはないのに、ひどい話だという面は置いておいて、これは技術サイドのある意味で良いチャンスだと思う。これまではどうしても営業カレンダーのプレッシャーに負けて、しょうもない設計だったり、動けばいい程度のアーキテクチャだったり、危険な単純更改だったりという要求を飲んできたが、これからはもう負けてはいけない。正しいアーキテクチャーでなければ設計しないし、安全性は後でというようなことは全く通用しない。リスクをベンダーが肩代わりするような提案はしないということだ。まあ、これで正常化したらいいと思うね。