IT業界は鉄筋削減は当たり前
世間は建築業界の設計偽装問題で持ちきりだ。何でも，建物の耐震強度が低いらしい。組織的な偽装体質もあったみたいだし，ひどい話である。
ただ，不謹慎な言い方をあえてするならば，この問題においては一応震度5弱までは耐えられる。しかし，IT業界の問題は，ほとんどのシステムが，震度2なんてとても耐えられる代物ではない。鉄筋なんてないものだっていっぱいある。
「自分たちのシステムって，耐震強度はどうなんだろう？」と思った人は，ベンダーから提供された設計書やソースコードを見るといい。トーシローでも見抜けるような欠点はいくらでもあるのが現実だ。
public void updateEmployee(EmployeeModel model) { … EmployeeDao dao = …; try { dao.update(model); } catch(DivisionNotFoundException e) {} … }
例外を握りつぶしている。例外処理削減の術。このシステムを使っている企業は，組織改変という地震に耐えられない。このような例外は，異常系ではなく正常系として，業務設計で当たり前のように対処が考慮されていなければならない。
ロードバランサの意味がない。しかも，サーバノードに乗せている機能が限定されているために，どちらかに障害が発生したら，事実上システムは停止である。ハードの進化とロードバランサの高機能化が進んでいるのだから，フル機能を持つサーバを複数台並列に配置し，ロードバランサの設定次第で各サーバの機能に対する専門性を持たせればよい。「システムがクラッキングされた際に，管理者機能を使われないようにすれば，被害を最小限にできる」と言う人もいるが，クラッカーはアプリの機能目当てにクラックをすることは少なく，OSなどを乗っ取られたら，そもそも終わりだ。セキュリティレベルを上げるための観点がそもそもずれてる。
package hoge. service.logic; import org.apache.struts.util.*; … public List getEmployeeList() { EmployeeDao dao = …; List employees = dao.getAllEmployees(); List result = new ArrayList(); for (Iterator i = employees.iterator(); i.hasNext(); ) { Employee employee = (Employee)i.next(); result.add(new LabelValueBean(employee.getName(), employee.getId())); } return result; } …
ビジネスロジックがStrutsに依存している。このビジネスロジックをバッチが使用していたとしたら，バッチを動かすために，WebアプリケーションフレームワークのStrutsが必要ということになってしまう。「ここの電球には家庭用発電機が別途必要です」という感じだろうか。記述すべき場所を何も考えていない典型例だ。
ちょっと考えただけでも，いくらでもこのような例は浮かんでくる。考えられないかもしれないが，これがIT業界の現実だ。上記の例は，まだ可愛い方だ。もっと問題なのは，まともな開発ベンダーの見積もりを，無能な依頼元が考えもせずに希望額と違うという理由で切るケース。僕は，まともなベンダーが切られたあとの後釜にも，もちろん切られたベンダーにもいた経験がある。どちらも，依頼元の根拠がない理由でそういった状況になるので，結果として開発は失敗する。だからこそ，実際に開発を行うベンダーは，鉄筋を減らすことを考えるようになり，上記のような低品質なシステムができあがる。建築業界よりも，よっぽどひどい。
IT業界の人間，特に現場ではなく「偉い人たち」に問う。建築業界の今の問題，他の畑の火事だと思って見過ごそうなんて考えてないですよね？あなた達は，もっとひどい判断を下しているかもしれないことを，ちゃんと自覚していますか？
このIT業界で，僕，そして僕らは，きっと正しい道を作ることができるはずだ。
